以下内容均为本人学习笔记，如有不当，感谢指出
一、软件测试的生命周期
软件测试是与软件开发如何实施息息相关的
1.软件开发的生命周期
| 需求阶段–>计划阶段–>设计阶段–>编码阶段–>测试阶段–>运行维护 |
2.软件测试的生命周期
| 需求分析–>测试计划–>测试设计（测试开发）–>测试执行–>测试评估 |
3.测试人员在软件开发阶段的工作
1. 需求阶段
测试人员了解需求，对需求进行分解，得出测试需求
2. 计划阶段
根据需求编写测试计划/测试方案
3. 设计阶段
测试人员适当了解设计，搭建测试用例框架，根据需求和设计编写一部分测试用例
4. 编码阶段
测试人员及进行单元测试，细化测试用例
编写测试用例也是对需求的测试（验证需求是否有问题）
5. 测试阶段
根据测试用例和计划执行测试，在执行阶段记录、管理缺陷，测试完成后编写测试报告
6. 运行维护
参与项目实施工作，参与用户软件使用培训
二、如何看待BUG
如何描述一个BUG
1. 发现问题版本
2. 问题出现环境
3. 错误重现的步骤
4. 预期行为描述
5. 错误行为描述
6. 问题图片其他信息附件
7. 不要将多个BUG放在一起
如何定义BUG级别
| 1.Blocker（崩溃） 阻碍开发或测试工作的问题，造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能 丧失，基本模块缺失等问题。例如代码错误，死循环等。 2.Critical（严重） 系统主要功能部分丧失、数据库保存丢失、一级功能菜单不能使用但是不影响其他功能的测试。 3.Major（一般） 不影响使用，功能菜单存在缺陷，例如操作时间长、查询时间长等 4.Minor（次要） 界面、性能缺陷，建议问题，不影响功能执行，例如错别字、界面格式等 |
BUG的生命周期
无效的BUG:open到closed open到Rejected 到closed
三、具体的测试方法
1.根据需求设计测试用例
是基于需求的测试方法，会使测试用例更加有效，因为它是测试专注于质量问题产生的根源，即需求。
基于需求的测试是一种最根本的软件测试，重点关注以下两大问题
（1）验证需求是否正确、完整、无二义性，并且逻辑一致
（2）需要从黑盒的角度，设计出充分必要的测测试用集，以保证设计和代码都能完全符合需求。
2.等价类
依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
有效等价类
对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。
无效等价
根据需求说明书，不满足需求的集合。
3.边界值法
通常边界值分析法是作为对等价类划分法的补充，这种测试用例来自等价类的边界。
下面举例几种边界值法测试
1.对于前闭后闭区间
[20 , 40] ——>19 , 20 , 40 , 41
2.对于前开后开区间
(20 , 40) ——>20 , 21 , 39 , 40
3.对于前闭后开区间
[20 , 40) ——>19 , 20 , 39 , 40
4.对于前开后闭区间
(20 , 40] ——>20 , 21 , 40 , 41
4.因果图
案例一：
假设业务单据的处理规则为：“淘宝618活动，提单已提交，订单合计金额大于300元或有红包，则进优惠”。
1. 对于这条业务规则，首先通过分析所有可能的输入和可能的输出，可以得到如下结果：
● 输入：订单已提交、金额大于300、有红包。
● 输出：优惠、不优惠。
2. 然后，进行第二步，找出输入与输出之间的对应关系。通过分析，可以看出有以下的对应关系。
(1)订单已提交，订单金额小于300元并且没有红包，不优惠。
(2)订单已提交，订单金额小于300元但是有红包，优惠。
(3)订单已提交，订单金额大于300元并且没有红包，优惠。
(4)订单已提交，订单金额大于300元并且有红包，优惠。
(5)订单未提交，不优惠。
3. 为了方便画出因果图和判定表，需要对所有输入和输出编号，现在编号如下。
（11）订单已提交
（12）订单金额大于300元
（13）有红包
（21）优惠
（22）不优惠
4. 画因果图
5. 画判定表：有3个条件,每个条件有2个取值，所以表的列数为2x2x2=8
| 条数 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
|---|---|---|---|---|---|---|---|---|---|
| 条件1 | 订单已提交 | y | y | y | y | n | n | n | n |
| 条件2 | 金额大于300 | y | y | n | n | n | y | y | n |
| 条件3 | 有红包 | y | n | y | n | y | n | y | n |
| 中间结果 | 中间结果 | y | y | y | n | y | y | y | n |
| 动作1 | 优惠 | y | y | y | n | n | n | n | n |
| 动作2 | 不优惠 | n | n | n | y | y | y | y | y |
6.有效的测试用例 1，2，3，4 ，5
5.正交表
如果因果法设计的用例太多，此时就不太合适了
正交法的目的是为了减少用例的数目，用尽量少的用例覆盖输入的两两组合
| 正交测试是根据正交性，由试验 因素的全部水平组合中挑选出部分有代表性的点进行试验，通过对这部分试验结果的分析了解全面试验的情况，找 出最优的水平组合。正交试验设计是一种基于正交表的、高效率、快速、经济的试验 |
正交表的因素
行数：正交表中行的个数，即测试用例的次数，用N代表
因素数：正交表中列的个数，用C代表
水平数：任何单个因素都能取得到的最大个数。包含的值为从0到(水平数-1)或者从1到水平数
正交表的表示形式：L=行数(水平数 * 因素数) 即 L=N(TC)
正交表的两条性质
每一列中各数字出现的次数都一样多。
任何两列所构成的各有序数对出现的次数都一样多
案例：
继续以注册为例（类似工具可以使用微软的PICT工具）： 1、因素：姓名、邮箱、密码、确认密码、验证码
2、水平：填写、不填写
3、表中的因素数>=5 ,水平数 >=2 ，则行数 = 5 *(2 -1) + 1 = 6
正交表的表示为 L = N(TC) = 6(25)
4、生成测试用例
因素取值为填写时，正交按取值个数进行排列，实验次数不够用则继续往上加，但要满足正交性质
| 所在列 | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|
| 因素 | 姓名 | 密码 | 确认密码 | 验证码 | 实验结果 | |
| 实验1 | 不填写 | 填写 | 不填写 | 填写 | 不填写 | |
| 实验2 | 填写 | 不填写 | 填写 | 不填写 | 填写 | |
| 实验3 | 不填写 | 不填写 | 填写 | 填写 | 不填写 | |
| 实验4 | 填写 | 填写 | 不填写 | 不填写 | 填写 | |
| 实验5 | 不填写 | 填写 | 填写 | 不填写 | 不填写 | |
| 实验6 | 填写 | 不填写 | 不填写 | 填写 | 填写 |
5、增补测试用例
我们发现上面的测试用例很明显没有全面的包含我们的测试情况，这时候就需要我们进行增补测试用例
例如在上面的测试用例中，我们规定5个因素必须都是必填选项时，就需要加上一条测试用例 为全部填写项
6.场景设计法
现在的软件几乎都是用事件触发来控制流程，事件触发的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的场景，有利于测试设计者设计测试用例，是测试用例更容易理解和执行。
想象主次场景来设计用例，这与根据业务流程来设计差不多。主要是想象各种业务流来设计用例。
7.错误猜测法
基于经验和直觉，找出程序中你认为可能出现的错误，有针对性的设计测试用例
以注册为例：
1.校验张特殊字符空格的处理（例如，在输入用户名时，空格在用户名后面或者前面则希望截取掉，若出现在中间则不希望截取）
2.密码校验中的大小写
3.姓名中的特殊字符
4.密码发送是否明文
测试用例的有效性
无效测试用例
1.测试用例对应的功能已经删除
2.执行一条测试用例未发现BUG，实际该处有BUG
有效测试用例
3.执行一条测试用例发现BUG
4.执行一条测试用例未发现BUG，实际该处BUG已经修改（验证满足）
测试用例的粒度和评价
好的测试用例是一个不熟悉业务的人也能依据用例很快进行测试
但是并不适合 敏捷（轻文档） 方式的测试
粒度：指测试用例编写的详细程度
测试用例的评价
同行评审
用户检查
项目组评审
完。