软件测试-缺陷

缺陷的类型：功能，界面，文档，软件包，性能，系统/模块接口

注意：需求分析，设计阶段，文档类型的缺陷多，集成测试阶段，一般接口类型的缺陷多一些，系统测试阶段，功能，界面类型的缺陷多一些，验收测试阶段更多的关注性能，一般在软件实施过程中，可能会遇见软件包的缺陷。

缺陷的严重程度：

缺陷的故障对软件的影响，一般有分类，每个公司的团队分类标准也是略有不同的。大体的等级划分以上图所示，作为判断依据。

缺陷的修复优先级，很大程度上取决与缺陷对测试工作的影响程度。

缺陷的状态：表示缺陷的处理进度。
发现缺陷是处理缺陷的前提，但是还没有进入缺陷的处理流程。
1.激活或打开（新建），由测试人员进行标注。
2.确认新提交的缺陷是一个真实有效的缺陷，由测试主管或者质量保证（QA）或产品经理进行确认，指派给相关人员进行处理。
3.已经修复或者改正，在缺陷被修复后，一般由开发人员进行修复。
4.关闭/非激活，缺陷被修复完后，经过测试人员的验证后没有问题。
5.重新打开，经过测试人员验证后，缺陷没有修复成功，需要重新打开进行再次处理和修复。
6.推迟，缺陷现在不能修复，推迟到下一个版本或者阶段，测试要跟开发或其他管理人员进行确认。
7.保留，缺陷暂时修复不了，一般也是由开发人员进行设定，也需要测试人员进行确认。
8.不能重现，开发按照缺陷的复现步骤却不能再次发现缺陷，一般闪退，崩溃的缺陷具有类似的特征，或者由于操作系统的差异，浏览器的缓存等信息，出现的问题。所以作为测试人员，提交bug之前，要进行再三确认。
9.需要更多信息，作为测试人员，提交bug的时候，要尽可能的把所有相关的文件一起提交。（图片，视频）
10.重复，测试中，一定要避免这种情况的出现。尤其在软件的某一个功能频繁的被多个模块（由不同的测试人员测试）调用的情况下。
11.不是缺陷，一定不要在测试人员的测试生涯中被开发标注缺陷状态为不是bug。
12.需要修改需求说明书，缺陷不是由于技术导致的，而是由于需求不明确或者设计不明确造成。


缺陷的起源，来源，根源：一般关注较多的是缺陷的来源，在测试总结的时候，关注缺陷的根源。

缺陷的生命周期：
1.发现缺陷：由测试人员发现。
2.提交缺陷：由测试人员提交。
3.确认缺陷：由测试主管或者产品经理或者质量保证（QA）进行确认。
4.分配缺陷：经理确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁去分配。分配的对象可能是开发，也可能是UI,也可能是产品经理。
5.修复缺陷：主要由开发进行修复，也有可能是产品经理进行修复问题，也有可能是UI修复问题。
6.验证缺陷：测试来验证问题有没有修复成功。
7.关闭缺陷：只能是测试人员进行，否则出了问题，测试不背锅。

缺陷的识别：
依据：需求文档，设计文档，产品原型，测试用例，都是客观的依据。
同行业的类似成熟软件，和开发人员进行沟通，跟有经验的测试人员进行沟通，同行业隐形需求，都是带有主观色彩的依据。
测试人员在识别软件缺陷的时候，要很灵活的对待。

缺陷报告：
1.缺陷编号：BUG_项目名称_模块名称_功能名称_0001
2.所属模块：一级模块，二级模块，三级模块
3.优先级：缺陷修复的紧急程度，p1>p2>p3>p4
4.严重程度：s1>s2>s3>s4
5.缺陷概述：用一句话描述缺陷的基本情况
6.缺陷的描述：将缺陷的复现步骤，预期结果和实际结果列出来
7.提交人：是谁就写谁的名字
8.备注：一半写产生该缺陷的特殊情况，将BUG的截图作为备注信息

缺陷报告的编写目的：1.展现缺陷的详细信息 2.展现缺陷的影响程度和方式
由于缺陷报告的读者很多：开发，质量管理，市场人员，运维人员
所以缺陷报告要写的很直白，清晰，明了。

缺陷描述的准则：
1.单一准确：绝大部分的缺陷都是如此，一小部分的很难复现（闪退，崩溃）
2.可以再现
3.完整统一
4.短小简练
5.特定条件
6.不补充完善
7.不做评价

缺陷报告本身要保证没有任何表述性的错误。

禅道在中小型企业用的较多，Bugfree被禅道收购了。