【测试开发】测试的基础知识二

接上一篇测试的基础知识。

一、软件测试的生命周期

二、如何描述一个BUG

案例：

提交了如下bug：
1、在短信列表，选择一条短信，进行删除，删除失败
2、在短信列表，选择一条短信，进行查看，在查看页面，进行删除，删除失败
故障发现版本：VPS20180226_01
故障类别：兼容性
故障优先级：中
故障标题:ie下界面显示异常，界面文字有重叠
故障描述：
测试环境：win7+IE8
测试步骤：1、打开vps首页，点击“通知”链接，进入通知页面
预期结果：通知页面显示正确，一页显示10条通知，按时间顺序倒序排列
实际结果：页面显示10条通知，通知顺序正确，但是页面文字有重叠
附件：上传截图

三、如何定义BUG的级别

四、BUG的生命周期

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
无效的bug：open->closed open-rejected-closed

五、如何开始测试？

六、测试的执行和BUG管理

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

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

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

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

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

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

能让开发人员解决最多 Bug 的测试人员是最优秀的测试人员

在测试工作中，最常遇到的是和开发人员的 PK ，作为测试经理还会和项目经理、产品经理的 PK 进度、质量。

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

这不是 bug

这个 bug 的级别太高了

bug 影响不大，暂不修改

遇到争执不要怕，记住批判性思维：清楚 -- 准确、切题 -- 深刻，有意义，有逻辑性 -- 公正、全面

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

如果能正确地、高质量地录入一个 Bug ，那么基本上已经成功地与开发人员沟通了一大半的关于 Bug 的信息。但是总有“ 书难达意 ” 的耐候，这时就需要测试人员主动与开发人员进行沟通了。 如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug 的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug 后，马上找相关的程序员解释刚才录入的 Bug ，确保程序员明白 Bug 描述的意思，而不要等待开发人员找自己了解更多的信息。

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

例如：需求要求可以上传图片作为头像，但是没有定义格式。开发人员在上传时限制为只能传png格式的。
站在用户角度考虑一下：png，jpg那种格式更多？是否要用户自己进行格式转换再上传？

如下图，当选择了 1.png ， 2.png ， 2-2.png, 时，任意点击一个删除按钮，所选的三个都被删除

案例：
某网站经常隔几天访问时会出现500错误，但是之后就不会复现。
测试人员会提出问题：网站偶发性出现500错误。
开发人员回答：不常见，不影响使用，暂不修改
资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改
连接池配置定期校验连接
开发人员处理：修改xml，增加校验配置项

七、测试BUG的演示

比如我们测试一个网站能否正常进入，当长时间处于加载界面时，我们就可以按照下面的格式来写一个测试报告：

版本：v1.0
环境：win10,XP,win11
操作步骤：直接输入网址
执行结果：长时间处于加载界面
预期结果：显示前端页面
优先级：P0