软件测试的生命周期
软件测试贯穿于软件的整个生命周期
软件测试的生命周期是指测试流程，这个流程是按照⼀定顺序执行的⼀系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的目标和交付产物。
需求分析：
**用户角度：**软件需求是否合理
技术角度：技术上是否可行，是否还有优化空间
测试角度：是否存在业务逻辑错误、 冗余、冲突等问题
测试计划：制定测试计划：什么时候开发测试，什么时候结束测试，耗时多久
测试设计与开发：参考需求文档、技术文档等编写测试用例
写测试文档，明确标注使用到的测试方法，测试工具，测试形式等
测试执行：充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖
测试评估：测试是否通过，本次测试是否有遗留的BUG，最终测试人员需要产出⼀个测试报告
上线：项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线并测试线上环境下软件的运行是否正确
运行维护：测试人员需要参与项目的实施⼯作。测试人员对项目产品的业务和操作非常了解，加上测试⼈员的沟通表达能力⼀般都比较强，所以测试人员可以参与用户使用软件的培训， 在试运行项目时收集问题并及时反馈给相关负责人
测试人员不仅要具备开发能力，测试能力，最好具备一定的产品分析能力。
测试执行结束后，不能认为项目一定没有问题了，问题不会全部被发现。
学习中，本地写的代码提交到码云上/部署到服务器上，可以成为上线(所有人可以看到)。实际上，要分为多个步骤：沙盒(企业内部的线上环境-供内部人员测试)，小流量(部分线上真实用户可以看到。测试人员要在线上手动测试，还要看到有没有错误日志--真实用户在使用中是否发现问题)，全流量(所有真实用户可以用)，全线上。
因为上线也可能会出现问题，线下没有问题，但是如果到线上就有可能有问题。线上和线下测试环境不一定相同，所以每一步都要测试。
BUG
BUG的概念
1.当且仅当规格说明(需求文档)是存在的并且正确，程序与规格说明之间的不匹配才是错误
2.当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。
描述bug的要素
bug描述：百度一下按钮不好看 按钮太大？颜色？形状？ 导致沟通效率低下，工作质量低下等问题
描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果
bug级别
通过定义bug的级别，能够明确看出问题的严重程度 。工作中开发人员通常需要按照bug的级别来分配优先级来处理bug ，除此之外，通过bug级别也能够体现出开发人员的开发质量。
A：一周内出现10个bug，2个严重，5个一般，3个次要；
B：一周内出现10个bug，2个严重，3个一般，5个次要；
显然A的能力强；
bug级别⼀般分为：崩溃、严重、⼀般、次要
**崩溃：**阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库 发生死锁、重要的⼀级菜功能不能使用等（该问题在测试中较少出现，⼀旦出现应立即中止当前版本测试）。
严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，⼀级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、 自动退出，关联程序间调用冲突，安全问题、稳定性等。 如：软件中数据保存后数据库 中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）。
**⼀般：**功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。 如：操作时间长、查询时间长、格式错误、边界条件错误， 删除没有确认框、数据库表中字段过多等 (该问题实际测试中存在最多）
**次要：****界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。**如：错别字、界面格式不规范， 页面显示重叠、不该显示的要隐藏，描述不清 楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）
bug的生命周期
测试人员在执行测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug生命起 源），创建好的bug需要被开发人员修复，以及测试人员的持续跟踪和测试。
与开发产生争执怎么办（高频考题）
bug的级别和bug的数量都会影响到程序员的年终奖，所以很多时候测试人员和开发人员都会争论。
在测试⼯作中，最常遇到的是和开发人员的PK，作为测试经理还会和项目经理、产品经理的PK进度、 质量。作为⼀名测试⼈员，⼀般会遇到以下几种情况： 
遇到争执不要怕，要理性的分析和反馈问题。
先检查自身，是否bug描述不清楚
如果能正确地、高质量地录入⼀个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug 的信息。但是总有"书难达意"的时候，这时就需要测试人员主动与开发人员进行沟通了。如果测试人员发现在写完⼀个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思， 而不要等待开发人员找自己了解更多的信息。也要看是否是自己的误操作导致的bug。
站在用户角度考虑并抛出问题
功能正常只是测试的一部分，还要考虑用户的使用感受。站在用户角度考虑问题应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问⼀句：如果你是用户，你可以接受么？
BUG定级要有理有据
将bug定级文档拿出来，BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。将bug定级文档拿出来
提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案
提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。在工作中，你会发现同⼀个bug，资深测试⼯程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试⼯程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第⼀反应，就是这是⼀个bug，而不是这是⼀个bug吗？注意：可以给出解决方案，但是不能喧宾夺主，命令式让开发⼈员按照自己的想法来修改。
bug评审
如果确实是bug，友好沟通不能解决问题，那么就召开bug评审。
bug评审主要解决两个问题：
- 决定如何处理bug
- 分析缺陷产生的原因，找出预防的对策(不能犯重复的错误)
bug评审至少需要项目组各个方面的代表参加：
- 测试代表：测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该⼀味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的⼯作量，如果时间比较紧迫，修改后剩余的时间若不足以做⼀次有效的回归测试，可能不修改是个明智的选择。
- 开发代表：开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、 可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
- 产品代表：产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见