目录
一、软件测试的生命周期（重要）
🍑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和分析缺陷产生的原因，找出预防的对策。参加者一般是测试人员、开发人员和项目经理。
八月你好！
美好的一天又从清晨开始~🥰
1063
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
