软件测试的生命周期
需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估
软件测试&软件开发生命周期
需求阶段: 测试人员了解需求、对需求进行分解，得出测试需求
计划阶段: 根据需求编写测试计划/测试方案
设计阶段: 测试人员适当的了解设计，对于设计测试用例是很有帮助的，测试人员搭建测试用例框架，根据需求和设计 编写一部分测试用例
编码阶段: 测试人员一般是不需要编码的，但已经编码的模块，专业的白盒测试人员可以计划执行单元测试，完善、细 化测试用例以及调整测试计划和方案。
测试阶段: 测试阶段是软件测试人员最为重要的工作阶段，根据测试用例和计划执行测试，在执行的过程中记录、管理 缺陷，测试完成后编写测试报告。
运行维护: 测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达 能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相 关负责人。
如何描述一个bug
一个合格的bug描述应该包括以下几个部分：
1、发现问题的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析 每个版本的质量。
2、问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需 要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
3、错误重现的步骤
描述问题重现的最短步骤。
4、预期行为的描述
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故 障，能写明需求的来源是最好的。
要相信：测试人员是最懂需求的。
5、错误行为的描述
描述错误的现象。crash等可以上传log，UI问题可以有截图。
6、其他
某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严 重影响测试需要开发人员优先修改的，可以设置优先级为高。
7、不要把多个bug放到一起 在无法确认是同一段代码造成的故障时，不要将bug放在一起提交
如何定义bug的级别
1、Blocker（崩溃）：
阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能 丧失，基本模块缺失等问题。
2、Critical（严重）：
系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测 试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳 定性等。
3、Major（一般）：
功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
4、Minor（次要）：
界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等
bug的生命周期
因BUG与开发人员产生争执怎么办?
1、先检查自身，是否bug描述不清楚 如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是 总有“书难达意”的耐候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后， 好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关 的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。
2、站在用户角度考虑问题 应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极 地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
3、BUG定级要有理有据 BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别 的，需站在用户的角度定考虑定位级别。
4、提高自身的技术和业务水平. 不光要提出问题, 最好也能提出解决方案。提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的 差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一 反应，就是这是一个bug，而不是这是一个bug吗？
5、开发人员不接受时，不要争吵可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。Bug评审要注意的问题 缺陷的评审应该包括以下两个层面
● 决定如何处理Bug。
● 分析缺陷产生的原因，找出预防 的对策。