1. 软件测试的生命周期
需求分析 → 测试计划 → 测试设计/测试开发 → 测试执行 → 测试评估
类似软件开发的生命周期（需求 → 计划分析 → 设计→ 编码 → 测试 → 运行）
需求分析：对需求进行验证和细化，为后续写测试用例做准备工作。
测试计划：时间，人员，工具。
测试设计：根据需求写测试用例。
测试执行：软件基本开发完成，测试人员执行测试用例，发现Bug，并且记录Bug。
测试评估：把本次迭代的测试情况形成测试报告，总共有多少测试用例，执行了多少测试用例，产生的Bug和修改的Bug数，遗留的Bug数以及处理方式。
2. 如何描述一个Bug
一个合格的bug描述应该包括以下几个部分：
1. 发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
2. 问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3. 错误重现的步骤
描述问题重现的最短步骤。
4. 预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。要相信：测试人员是最懂需求的。
5. 错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6. 其他要求
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。
7. 不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。
（1）发现Bug的版本（代码所在的版本号）
（2）测试平台（系统运行的平台）
如：web、浏览器 、Chrome、FireFox 、IE 、edge、360等；APP、ISO 、Android （具体到手机的系统版本、 机型）
（3）测试步骤，测试数据
（4）测试实际结果
（5）预期结果
（6） 附件（如错误截图，log日志）
3. Bug的级别
bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。
（1）崩溃（Blocker）
系统无法正常运行，已经严重阻碍了开发人员或者测试人员的工作。如果线上出现这种情况，立刻回退版本到一个系统稳定的状态。
（2）严重 （Critical）
系统还可以运行，但是已经不稳定了，如果继续运行下去，会产生严重的后果。
（3）一般 （Major）
系统可以稳定地运行，但是会影响用户的操作。
（4）次要（Minor，建议性的）
建议型的Bug，页面问题，排版，字体大小，有弹出框但是没有确定按钮，图片显示等问题。
4. Bug的生命周期
每个公司、每一个工具对bug生命周期的定义都是不一致的。
下面仅是一个常见的例子。
测试人员应该跟踪一个Bug的整个生命周期，从Open到Closed的所有状态。
Bug状态转化：
● New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open —> closed open — rejected — closed
缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。
Bug的跟踪以及状态变更应该遵循一些基本原则：
●测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
●对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人）的评审。
5. 如何发现更多的Bug
- 软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度和深度！
- 开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强他开发模块的测试广度和深度！
- 多进行逆向思维和发散性的思维。
- 不要局限于用例和需求文档。
- 尽早介入项目, 不要等到开发的差不多了再介入项目。
6. 冲突问题
能让开发人员解决最多Bug的测试人员是最优秀的测试人员。
如果因为一个Bug和开发人员产生冲突怎么办？
（1）首先检查自身，看Bug的描述是否清楚；
（2）和开发人员进一步沟通，了解原因，并且尽量从用户的角度去劝说开发人员；
（3）Bug定级要有理有据，查看Bug的定级有没有符合公司的规范；
（4）要不断提高自己的业务水平和技术水平；
（5）可以和产品经理商量开Bug评审，讨论这个Bug有没有修改的必要以及它的解决方案。