软件测试BUG篇

软件测试生命周期

软件测试贯穿于软件的整个生命周期

需求分析	测试计划	测试设计与开发	测试执行	测试评估	上线	运行维护
用户角度:软件需求是否合理技术角度:技术上是否可行，是否还有优化空间测试角度:是否存在业务逻辑错误、冗余、冲突等问题	制定测试计划:什么时候开发测试，什么时候结束测试，耗时多久	参考需求文档、技术文档等编写测试用例写测试文档，明确标注使用到的测试方法:测试工具，测试形式等等	充分利用测试用例和测试工具对项目尽可能做到全方面的测试覆盖	测试是否通过，本次测试是否有遗留的BUG，最终测试人员需要产出一个测试报告	项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线并测试线上环境下软件的运行是否正确	测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解，加上测试人员的沟通表达能力一般都比较强，所以测试人员可以参与用户使用软件的培训，在试运行项目时收集问题并及时反馈给相关负责人

• 测试人员不仅要具备开发能力、测试能力，最好具备一定的产品分析能力
• 测试执行结束后，不能认为项目100%的问题都被发现了。问题是不可能被完全发现
• 测试人员一般是最了解需求的人
• 演示会议：由测试人员来演示产品/软件
• 上线要分成多个步骤:沙盒、小流量、全流量、全线上（上线的过程中也可能会存在问题，线下测试没有问题，如果直接推到线上可能会发现问题）

• 沙盒：企业内部的线上环境可以供内部人员进行测试
• 小流量：部分线上真实的用户可以使用到测试人员要在线上手动测试，还要观察有没有错误日志（真实用户在使用过程中是否发现了问题）
• 全流量：所有的真实用户都可以使用到

线上环境和线下测试环境并不是完全一样的，因此每一步都需要跟进测试

BUG

概念

1. 当且仅当规格说明（需求文档）是存在的并且正确，程序与规格说明之间的不匹配才是错误。
2. 当需求规格说明书没有提到的功能，判断标隹以最终用户为准:当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

描述BUG

描述bug的基本要素:问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果（包括但不限于，这些只是必须的）

BUG的级别

• 意义：1.评估程序猿的开发能力2.年终奖3.给bug修复顺序排序
• bug级别一般分为:崩溃、严重、一般、次要(基础的定义)

崩溃	严重	一般	次要
阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题在测试中较少出现，一旦出现应立即中止当前版本测试)。	系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他 功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用 冲突，安全问题、稳定性等。如:软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)。	功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)	界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如:错别字、界面格 式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等(此类问题在测试初期较多，优先程度较低;在测 试后期出现较少，应及时处理)

入职之后，公司/团队会提供“bug级别描述文档”

BUG的生命周期

与开发人员争执怎么办

1. 先检查自身，是否bug描述不清楚

反省自己:是不是在测试的时候出现了误操作、bug描述是不是没有写清楚

2. 站在用户角度考虑并抛出问题

功能正常只是测试的一部分，还需要考虑用户的使用感受

3. BUG定级要有理有据

bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序猿

4. 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案

测试小白:更多的是提出问题(bug)
测试大牛:除了提出问题也能够定位到问题，给出解决方案
一定不要以命令的方式要求

5. 开发人员比较犟，怎么说都不听的情况下，就需要进行bug评审

bug评审需要有三个代表:测试代表、开发代表、产品代表
bug评审主要解决两个问题:
1)决定如何处理bug
2)分析缺陷产生的原因，找出预防的对策