一.测试的分类
1.按代码分类
a.黑盒测试：测试对象看成黑色盒子，看不到内部结构，是对软件的一种功能性测试，即手工测试，是功能测试的一种形式
b.白盒测试：测试对象看成白色盒子，看得到内部结构，是针对程序内部代码的一种测试，是单元测试的一种形式
c.灰盒测试：介于黑白之间，测试工程师可以看开发的代码进行代码的走查和参与开发代码的评审
2.按编写代码分类
a.手工测试
b.自动化测试（ui自动化测试；接口自动化测试）通过工具或者代码的形式模拟人的操作，来对产品进行自动化测试的操作
二.软件的分类（测试的产品）
软件分类： B/S（WEB）的产品测试经验。app的测试经验 小程序的产品（依赖于微信&支付宝）
测试的产品：Web/APP/小程序
三.测试的术语
a.冒烟测试
开发把写好的程序转给测试的时候，测试首先需要的是针对转测的程序进行正常流程的测试，目的是验证正常程序可以执行通的情况下继续测试被测程序的其他功能。
b.探索性测试
根据主观意愿对产品进行发散思维的测试，强调测试人员主观能动性摒弃测试用例，在碰到问题时及时改变策略
c.安全测试
针对被测产品的安全考虑，主要使用渗透测试技术用代码测
d.回归测试
产品已经测试完成，在准备上线的情况下，针对产品进行第n次测试，大量自动化测试承担。
测试环境：系统已有功能的测试（自动化）
线上环境：系统已有功能的测试&针对本次上线新功能的 回归测试
四.软件测试需求分析
1.为什么要进行需求分析
- 软件测试需求是设计测试⽤例的依据。
- 有助于保证测试的质量和进度
- 软件测试需求是衡量测试覆盖率的重要指标
2.软件测试需求分析步骤
- 列出需求⽂档中的具有可测性的原始需求 对每⼀条需求进⾏细化分解；
- 形成可测试的分层描述的测试点 对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执⾏时需要实施的测试类型；
- 建⽴测试需求跟踪矩阵，对测试需求进⾏管理
3.测试点分析
- 通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）
- 各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）
- 考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况 （界⾯、易⽤性、兼容性、安全性、性能）
4.测试需求相关方的影响
开发约束
- 由于了解需求不明确，功能研发不合格导致很多BUG
- 对于BUG反复修改，影响进度和团队情绪
- 进度影响，很可能使公司产品失去市场先机
测试约束
- 与开发是相互制约的关系，如果不了解需求，会大部分时间都被开发牵着鼻子走
- 不能及时发现开发的偏差，影响进度和团队情绪
- 没办法保证测试质量
5.看需求文档的注意事项
【看需求文档抓住核心的东西：】
a、产品是给谁服务的？
b、产品的核心流程是什么？ 核心流程最好使用思维导图的模式把流程梳理出来
c、如果产品里面有专业术语（咨询产品或者是自己百度搜索）
d、梳理出产品哪些逻辑不是很清楚，梳理出来后，专门约产品经理或者是其他测试，让对方协助我们来讲解下这部分
五、测试用例的编写
1.测试用例编写步骤
拿到需求文档 -> 分析需求（画思维导图） -> 编写⽤例 -> 划分⽤例优先级
2..测试用例编写特征
⼀致性：主要包括用例模板⼀致；各同事的编写⼿法⼀致；以及用例的细腻度⼀致。
覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对哪些功能会产⽣影响的覆盖；对各种场景的覆盖等 。
可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。
执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行⼈对待执行用例的态度。不要因为用例简单或者⼀些外界的因素，导致部分用例未实际执⾏标为通过的情况。
持续更新：要及时不断的更新，要尽量减少用例库中失效的用例。
复用性：主要用例可以被不断的复用，从而减少维护成本。
3.测试用例编写的三种方式
a、思维导图，结构化看起来非常的好，但是不够细。
b、使用excel，特点是写起来非常浪费时间，但是非常细。
c、checklist 只考虑被测对象的大概的点。
4.测试用例的组成元素
⽤例ID； ⽤例名称； 测试⽬的； 测试级别； 参考信息； 测试环境； 前提条件； 测试步骤； 预期结果； 设计⼈员。
5.环境
- 测试环境：给测试使用的环境，指的是一个产品还没上线前测试的环境
- 预发布环境：介于测试环境与线上环境中间，但是它也是可以给客户使用的环境，一般不开放，只供研发内部人员使用
- 线上环境：给真实的用户使用的环境
