软件测试基础

1. 软件测试的生命周期

• 需求分析：站在用户的角度查看需求逻辑是否正确，是否符合用户的需求和行为习惯。站在开发的角度思考需求是否可以实现，或者说实现起来难度高不高
• 测试计划：指定测试计划（包括不限于测试的工时，人力的安排等）
• 测试设计、测试开发：设计测试用例，经验丰富的白盒测试人员可以开始单元测试
• 测试执行：参考测试用例来执行测试
• 测试评估：测试人员需要记录测试、做好缺陷管理，然后进行测试评估

我们知道软件测试是贯穿于整个软件的声明周期的

软件测试的生命周期vs软件的生命周期?

回想一下软件的生命周期

• 需求分析
  • 测试也要对需求进行分析，分析需求逻辑是否合理，需求是否符合用户的行为习惯，站在开发人员的角度思考技术实现难度，针对技术难度来合理调整需求
• 计划
  • 根据需要编写测试计划/测试方案
• 设计
  • 测试人员适当的了解设计，合理的进行测试用例设计和调整
• 编码
  • 专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案
• 测试
  • 参考测试用例来执行测试
• 运行维护
  • 测试往往是最了解需求的人。测试人员通常来进行产品的演示和功能的介绍(演示会议)，期间记录下来大家反馈的建议，反馈给产品经理，成为以新的用户需求。

2. 如何描述一个Bug?

一个合格的$bug$应该需要包含以下几点

1. 发现问题版本

   开发需要知道是哪个版本出现了问题，才能获取到对应版本的代码来重现出问题。并且说明版本也有利于统计和分析每个版本的质量。

2. 出现问题的环境

   环境分为硬件环境和软件环境，如果是一个web项目，则需要提供浏览器版本，出现问题的操作系统版本等，如果是一个手机app项目，就需要描述出现问题的机型、分辨率、操作系统版本等等，详细的描述出现问题的环境更有利于问题的定位。

3. 重现出现错误的步骤

   以最短的不走描述能重现问题的步骤。

4. 预期行为的描述

   要让开发人员知道怎么样才是正确的，尤其哟啊已用户的角度来描述程序的行为到底是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。（要坚信测试是最懂需求的！）

5. 错误行为的描述

   描述出现错误的现象，奔溃等问题可以上传日志，如果是UI有问题可以截图

6. 其它

   有些公式可能对故障进行分类或者是优先级进行分类，严重影响测试的故障需要开发修改的，可以设置高的优先级

7. 不要把多个bug放到一起

   如果是无法确定是同一段代码照成的故障，不要把bug放在一起！

示例：

标题：通过谷歌浏览器登录进入首页后，导航栏的信息有两行文字重叠
发现bug版本：Chrome版本: 113.0.5672.93（正式版本） （64 位）
发现bug环境：win10 Chrome
发现bug步骤：通过win10打开Chrome浏览器打开登录页面直接登录跳转首页
期望结果：跳转后首页右下角的两行文字正常间距展示
实际结果：跳转后首页的右下角的两行文字出现重叠
其它：(bug类型：前端问题，bug等级：次要)

3. Bug的级别

bug的定义不同的公司都不一致，在定义级别之前需要查看公式的规范

举几个列子：

1. Blocker（奔溃）

   阻碍开发或者测试工作的问题，照成系统奔溃、死机、死循环甚至数据丢失，连接数据库出错，主要功能丧失，基本模块缺失等。比如：代码错误或者是发生死循环、死锁等，重要的一级菜单不能使用。不过这种问题在测试中是很少出现的，一般在开发阶段就会发现，但是如果一旦出现就应该立即终止当前版本测试。

2. Critical（严重）

   系统主要功能部分丧失、数据库保存数据调用错处、用户数据丢失，一级功能菜单不能使用但是不影响其他功能测试。功能设计与需求严重不符，模块无法调用或者启动，程序自动重启或退出，关联程序调用冲突、安全问题、稳定性等。比如：软件中数据保存后数据库中显示出错，用户所要求的功能缺失，程序的接口错误，数值计算统计错误等。（该类问题如果出现，在不影响其它功能测试的情况下可以继续测试该版本）。

3. Major（一般）

   功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。比如：操作反应慢、查询数据时间长、格式有点问题、删除没有确认框，数据库表中字段多等（该问题在测试中存在是最多的）

4. Minor（次要）

   界面或者是性能有缺陷，建议类问题，不影响功能的执行，可以优化性能的方案等。比如：错别字。界面根式不规范、页面显示重叠、不该显示的要影藏、描述不清楚。提示语丢失，文字排列不整齐，光标位置不正确、用户体验感受不好，就是一些优化建立类的问题。(这类问题在测试初期较多，优先级程度较低，在测试后期出现较少，应及时处理)

4. Bug的生命周期

不同的公司、不同的工具对bug生命周期的定义都是不一致的

下面是比较常见的bug生命周期的列子

• NEW：发现新Bug，为经评审决定是否指派给开发人员进行修改
• Open：确认是Bug，并且认为需要进行修改，指派个相应的开发人员修改
• Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
• Rejected：如果认为不是Bug，则拒绝修改
• Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改
• Closed：修改状态的Bug经测试人员的回归验证并验证通过，则关闭Bug
• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改

5. 测试模型

1) 软件测试V模型

其实软件测试模型和瀑布模型也是非常类似的。

软件测试V模型从上到下是一个开发模型，而从下到上则是一个测试模型。

• 概要设计一般设计整体架构、框架
• 详细设计一般设计的是模块和模块之间的详细设计
• 单元测试和继承测试通常由开发人员完成

其实这个软件测试V模型是有对应关系的，单元测试一般是参照详细设计进行的，继承测试是参照概要设计进行的，系统测试则是参照需求分析和系统进行的，最后的验收一般是有用户来验收的。

软件测试V模型的特点：

• 明确标注了测试的类型
• 明确标注了阶段和开发阶段之间的对应关系

明显的缺点：就是测试被后置了，和瀑布开发模型有点类似，风险被推迟到测试时才发现，导致测试没有时间即时发现Bug导致Bug最后遗留给用户

2) 软件测试W模型(双V模型)

W模型又可以叫做双V模型，由两个V组成，一个是开发模型一个是测试模型。

W模型的优点: 测试从需求开始阶段就介入了

缺点：

• 上一个阶段完成之后下一个阶段才能开始
• 开发模型和测试模型也保持这一种前后的线性关系，看图可以看出只有等用户需求完成之后才能做验收做测试准备，需求分析完成后才能做系统测试准备，只有等编码完成之后才能开始单元测试等…

可以看出W模型也是重文档、重过程的一个模型，也就是说W模型是不支持敏捷模式的。

6. 合理判断性思维

避免和开发发生争执

1. 具有批判性思维，多反思自己是不是bug描述的不清楚(无效的bug)
2. bug的等级要有依据
3. 合理友好的沟通，并站在用户的角度反问：如果你是用户你能接受这样吗?
4. 不仅要提出问题，最好能够给出解决问题的方案