一、软件测试的生命周期（重要）

🍑1、软件的生命周期？

需求分析——>计划——>设计——>编码——>测试——>运营维护

（1）需求分析：分析需求是否正确，是否完整？需求量大不大？技术上能否实现或者说实现的难度？

（2）计划：项目什么时候开发？项目由谁做？什么时候测试？项目什么时候上线等？

（3）设计：

开发人员设计项目底层如何实现，输出一个技术文档（详细的记录了软件技术上如何实现，接口，库表，定时任务等）；
测试人员设计测试用例；
UI设计师：将需求文档转化为图片，UI视觉稿等；

（4）编码：开发人员参考需求文档和技术文档进行功能代码的编写，开发软件；测试人员设计测试工具，设计测试用例；

（5）测试：测试人员参考测试用例来执行测试，测试软件是否有BUG（注意测试用例是在测试前就编好的，要知道我们的测试是贯穿软件的整个生命周期）；

（6）运行维护：将项目推到线上环境，如果发现线上Bug，此时需要修复，重新上线。

🍑2、软件测试的生命周期？

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估。

（1）需求分析：测试人员了解需求，对需求进行分解，得出测试需求；

（2）测试计划：测试人员也要编写测试计划文档：由谁测试，用什么工具测试，什么时候开始测试，什么时候结束测试等；

（3）测试设计与开发：测试人员根据需求文档和技术文档来设计测试用例，开发测试工具，开发自动化测试用例；

（4）测试执行

此时开发已经完成，执行测试用例验证功能。在验证功能的过程中，可能会遇见软件功能与需求不相符的情况，也就是有BUG存在，这个时候测试人员就会将BUG交给开发人员，等到开发人员处理好之后，测试人员又继续对其验证。

（5）测试评估

产出测试报告：

写了多少测试用例，执行了多少测试用例？剩余的测试用例为什么不执行完？
BUG的数量？已经解决的BUG数量？遗留的BUG数量以及解决方案？
还有此次测试的范围和测试功能等；
prd：软件规格说明书；

二、关于BUG

🍑1、如何描述与定义一个BUG？（了解）

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

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

（3）错误重现的步骤：描述问题重现的最短步骤。
（4）预期行为的描述：要让开发人员知道怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

（5）错误行为的描述：描述错误的现象。可以上传log，截图等。

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

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

举个栗子：

🍑2、BUG的级别？

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

🍑3、BUG的生命周期？（重要）

无效的bug：open->closed 或 open-rejected-closed。

注意：Rejected和delay的BUG，必须要让相关负责人知道！

🍑4、产生争执怎么办？（重要）

作为一名测试人员，一般会遇到以下几种情况：

这不是bug
这个bug的级别太高了
bug影响不大，暂不修改

（1）先检查自身，是否bug描述不清楚；

（2）站在用户角度考虑问题应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受吗？

（3）BUG定级要有理有据，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别；

（4）提高自身的技术和业务水平，不光要提出问题，最好也能提出解决方案；
（5）开发人员不接受时，不要争吵。

可能你已经经过了多轮沟通，但是开发人员仍然拒不接受，此时可以发起Bug评审。Bug评审应该包括以下两个层面：决定如何处理BUG，到底要不要修复BUG和分析缺陷产生的原因，找出预防的对策。参加者一般是测试人员、开发人员和项目经理。