✏️作者：银河罐头
?系列专栏：JavaEE

?“种一棵树最好的时间是十年前，其次是现在”

软件测试的生命周期

软件测试的生命周期： 需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

需求分析：需求是否完整，需求是否正确。

测试计划：确定软件由谁测试，什么时候开始测试，什么时候结束测试，测试哪些模块。

测试设计、测试开发：写测试用例(手工测试用例，自动化测试用例)，编写测试工具。

测试执行：执行测试用例。

测试评估：测试人员产生测试报告。

如何描述一个bug

一个合格的bug描述应该包括以下几个部分：

1、发现问题的版本 开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于 统计和分析每个版本的质量。

2、问题出现的环境 环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是 app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3、错误重现的步骤 描述问题重现的最短步骤。

4、预期行为的描述 要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需 求提出的故障，能写明需求的来源是最好的。 要相信：测试人员是最懂需求的。

5、错误行为的描述 描述错误的现象。crash等可以上传log，UI问题可以有截图。

6、其他 某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级 的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高。

7、不要把多个bug放到一起 在无法确认是同一段代码造成的故障时，不要将bug放在一起提交。

如何定义bug的级别

bug的定义每个公司都不一致，在定义级别之前需要查看公司规范。

以下为样例：

1、Blocker（崩溃）：阻碍开发或测试工作的问题。如：代码错误、死循环、数据库发生死锁…

2、Critical（严重）：系统主要功能部分丧失、数据库保存调用错误。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失…

3、Major（一般）：功能没有完全实现但是不影响使用。如：操作时间长、查询 时间长…

4、Minor（次要）：界面、性能缺陷，建议类问题，不影响操作功能的执行。如：错别字、界面格 式不规范，页面显示重叠…

如果是崩溃级别的 bug，那么此时就需要停止测试，测试打回。

接下来开发就需要修复，修复完之后自己得仔细地测试一下。

bug的生命周期

BUG状态转换图:

产生争执怎么办（处理人际关系）

作为测试人员：

前提：一定不能吵架。

1.确保操作没有问题

2.讲究话术，语气。

3.站在用户角度考虑问题。

4.不光要发现问题，提出解决问题的方案。

5.第三方会议：

开会之前：一定要明确问题产生的原因，问题是什么，解决方案是什么。

开会之后：问题要不要解决，什么时候解决，怎么解决。

如何开始第一次测试

1.充分理解需求

文档(产品文档 + 技术文档)

项目功能问题问产品。

模块底层如何实现问开发。

2.确定测试计划

3.执行测试

bug 开发修复了之后一定要验收

4.项目上线 + 维护

如何发现更多的bug？

1、软件测试同样存在二八原则，80%的故障集中于20%的模块，如果某部分问题较多，加强测试广度 和深度！

2、开发人员也存在二八原则，80%的故障集中于20%的开发人员，如果某些开发人员的bug较多，加强 他开发模块的测试广度和深度！

3、多进行逆向思维和发散性的思维

4、不要局限于用例和需求文档

5、尽早介入项目, 不要等到开发的差不多了再介入项目