1.软件测试的生命周期
在上篇文章【软件测试基本概念4】中，我们认识到了软件的生命周期，即需求分析、计划、设计、编码、测试、运行维护，因为软件测试需要贯穿软件的整个生命周期，所以软件测试也有与软件生命周期对应的周期。
软件测试的生命周期如下图所示：
测试人员需要在上图中所展示的各个阶段做以下的事情：
- 需求分析阶段：
- 站在用户的角度，查看需求逻辑是否正确，是否符合用户的需求和行为习惯。
- 还需要站在开发人员的角度，思考需求是否可以实现，或者实现起来难度大小。
- 测试计划阶段：
- 制定测试计划（包括但不限于测试的工时，人力的安排）
- 测试设计、测试开发阶段
- 设计测试用例，经验丰富的白盒测试人员可以开始单元测试
- 测试执行阶段：
- 参考测试用例来执行测试
- 测试评估阶段
- 测试人员需要记录测试，做好缺陷管理，然后进行测试的评估
2.再谈bug
2.1 如何描述一个bug？
提bug并不是简简单单的指出错误，需要有完整的体系来指出一个bug，通常描述一个bug应该具备以下内容：
- 发现bug的版本
- 发现bug的环境
- 发现bug的步骤
- 期望的结果
- 实际的结果
- 其他（bug类型、bug等级）
下边我们来具体提出一个bug：
标题：微软浏览器打开首页后，在缩放为110%时，第一个banner页上面的二维码被登录注册控件遮蔽住，导致无法扫描
发现bug的版本：Microsoft Edge版本 107.0.1418.56 (正式版本) (64 位)
发现bug的环境：win10 Microsoft Edge
发现bug的步骤：1.打开Edge浏览器，访问首页链接https://www.101eduyun.com/sunrise/login/login.do
2.调整页面缩放
期望的结果：首页的第一个banner上的二维码清晰可见，可以通过手机扫描
实际的结果：首页的第一个banner上的二维码被登录注册控件遮蔽住了，导致手机扫描二维码失败。
其他：（bug类型：前端/后端问题，bug等级：次要…）
2.2 bug的等级
bug的定义每个公司都不一致，在定义级别执行前都需要查看公司规范。
以下为样例：
1.崩溃：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。
这种级别的bug很少见，基本不可见
2.严重：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。
这种级别的bug也比较少见
3.一般：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
4.次要：
主要就是一些优化建议类的问题。
一般和次要的bug更为常见
2.3 bug的生命周期
以下是bug的生命周期图：
- New：新发现的bug，未经评审决定是否指派给开发人员进行修改。
- Open：确认是bug，并且认为需要进行修改，指派给相应的开发人员。
- Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
- Rejected：如果认为不是bug，则拒绝修改
- Delay：如果认为暂时不需要修改或者暂时不能修改，则延后修改。
- Closed：修改状态的bug经测试人员的回归测试验证通过，则关闭bug。
- Reopen：如果经验证bug仍存在，则需要重新打开bug，开发人员重新修改。
3.常见面试题
3.1 软件测试和软件开发的区别
- 软件测试的工作主要是保障产品质量
- 软件开发的工作主要是编写业务代码
软件测试还分为纯测试和测试开发两个方向，两个方向的主要工作都是保障产品质量，但测试开发方向还需要开发一些测试效能的工具，来提升测试效率。
3.2 走测试岗位为什么还需要学习开发的知识？
测试人员也需要进行代码的编写，如自动化测试、性能测试、效率工具等等。测试人员能够看懂代码，了解框架、代码中的数据走向，才能够更好的从代码层去发现问题。
学好开发知识能够提高测试质量。
3.3 为什么不走开发岗位而走测试岗位？
从以下三方面来展开：
1）个人兴趣爱好
2）对测试的理解
3）为什么走测试还需要学习开发知识
3.4 测试人员需要具备哪些素质？
综合能力：
表达能力 ：不管什么方向，都应该具备良好的表达能力（也是情商的体现）
文字能力：测试人员需要编写测试用例（测什么、怎么测）；测试人员需要提bug（描述一个bug）；写测试报告
开发能力：开发能力掌握的越好，越能够更好的协助提高测试质量
快速学习的能力：更快的上手干活
探索性思维、兴趣、责任感和压力
优秀的测试用例设计能力：
测试用例是测试人员执行测试的工作的重要依据。
掌握自动化测试技术：
自动化测试是中大厂企业必不可少的技术事务之一。
3.5 和开发产生争执怎么办？
这个问题是经常会出现的面试题。
1.应该具有批判性思维，多反思自己是不是bug描述的不清楚（无效的bug）
2.bug等级一定要有理有据（提出了一个bug是严重级别，开发不认可）
3.合理友好的沟通，站在用户的角度反问：如果你是用户，你能接受这样吗？
(开发对你说bug可不可以不改，小问题)
4.不仅仅能够提出问题，最好也能够给出解决方案。
5.组织bug评审
邀请代表参加bug评审：产品代表、开发代表、测试代表，进行以下工作：
1）如何解决bug？
2）如何预防类似的bug？
