缺陷书写规范

Posted 2021-10-25 zp0923

1、标题：应保持简短、准确、提供缺陷的本质信息。

　　-尽量以缺陷发生的原因与结果的方式相结合的放式书写；

　　-尽量避免使用模糊不清的词语，例如：“功能中断”、“功能不正确”、“行为不起作用”等，应该使用具体文字说明缺陷的症状；

　　-为了便于他人理解，尽量避免是用俚语或过分具体的测试细节；

2、复现步骤：应该包含如何使用别人很容易理解缺陷的复现步骤。

　　-为了达到这个要求，书写的测试步骤应当是完整的、简介的、准确的、可复现的，

　　常见问题：包含了过多冗余步骤，且句子结构混淆、可读性差、难以理解；包含的操作步骤过少，缺少必要的复现步骤；

3、期望结果：描述应与实际结果的描述方式相同、，通常列出产品达到什么样的功能或效果；

4、附件：对缺陷的补充说明，例如缺陷的截图、测试使用的数据等；

5、其它：选择合适的缺陷严重属性；按相应的规定，填写相应的字段；

二、避免常见错误：

1. 避免使用情绪化的语言，和强调的标点符号；
2. 避免使用模糊的词语，
3. 避免使用自认为幽默的语言，直接描述缺陷即可，
4. 避免体交不确定的缺陷

三、缺陷的跟踪

新提交的缺陷为‘新建’状态，在确认有效之后为‘打开’状态‘，开发人员修改后为’已修复‘状态，此时测试人员需要回测，如果已解决，状态为’已修复‘，如果问题未修复，bug状态为‘打开’如果开发人员认为此缺陷可以延期，项目负责人同意后，状态改为‘延期’，，延期后标明具体修改日期，否则为打开；

四、缺陷密度：

1、每千行代码的缺陷数

　　缺陷密度=1000*缺陷个数/代码行数

2、缺陷数据分析关注的问题：

　　-正在测试的软件哪个模块问题最多

　　-测试人员中谁报告的软件缺陷最多

　　-各类缺陷所占的所占百分比分别是多少

　　-开发人员能及时修复缺陷嘛

　　-开发人员一次正确修复缺陷的百分比是多少

　　-正在开发的软件能否在计划的时间内正常发布

3、缺陷分析的重要性；

　　-统计未修复的bug数目（特别是严重性高的缺陷），预计软件是否如期发布；

　　-分析缺陷的类型发布，发现存在较多缺陷的模块，找出原因，进行软件程序开发过程改进，

　　-跟就测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能；

　　-根据缺陷的修复是否及时，改进软件开发与测试的关系，是测试与开发更有机的配合，

4、常用的寻找缺陷的方法：

　　-页面大小：当页面中的元素过多时，未作精简，需要较长的加载时间，增加了服务器的压力，容易引起客户的反感；

　　-界面文字：页面信息描述不清楚、有语病、错别字、简单语言复杂化、描述不正确、不符合当前页面，错误的帮助信息、乱码；

　　-容错处理：指容忍犯错的能力，当用户操作过程中出现错误时，软件应能给出引导信息，指导客户进行正确的操作；

　　-数据转换;

　　-性能缺陷：