零基础自学软件测试-测试用例执行和缺陷提交规范

QQ交流群：929262679

测试用例执行的几个注意点：

1)仔细检查软件测试环境

2)全方位的观察测试用例执行结果

3)注意测试用例的前提条件和特殊规程说明

4)一轮测试要求测试用例必须全部执行

5)要求定位软件出错的位置和原因

6)及时更新测试用例

测试用例执行的几个标准：

1.测试用例执行开始的标准

测试用例编写完成，并已通过评审

测试环境已搭建完毕

2.测试退出的标准

测试用例全部通过

存在的问题已得到合理的处理

3.测试停止的标准

近半数以上测试用例无法执行

测试环境与要求不符

开发中需求频繁变动

缺陷的概念：

任何背离需求、无法正确完成用户所要求的功能的问题，包括存在于组件、设备或系统软件中因异常条件不支持而导致系统的失败等都属于缺陷。

产生缺陷的原因：

1.工期短，任务大

2.文档的不完整 

3.程序设计错误 

4.需求不断变化 

5.软件的复杂性 

6.沟通交流不够

7.软硬件支持不完善

软件技术人员发现了问题，判断这个问题是否是缺陷的依据是什么？

1.通过参考文档来确认缺陷;需求规格说明书（SRS）;概要设计、详细设计;用户手册

2.通过了解软件行业标准、行业背景（或参考同类典型软件）来发现缺陷

3.通过沟通来确认和识别缺陷

缺陷的主要属性

1.Identifier：缺陷标识，标识缺陷的一组符号。每个缺陷必须有一个唯一的标识。

2.Type：缺陷类型，根据缺陷的自然划分的缺陷种类。

3.Severity：缺陷严重程度，指因缺陷引起的失效对软件产品的影响程度。

4.Priority：缺陷优先级，指缺陷必须被修复的紧急程度。

5.Status：缺陷状态，指缺陷通过一个跟踪修复过程的进展情况。

6.Origin：缺陷起源，指缺陷引起失效或事件第一次被检测到的阶段。

7.Source：缺陷来源，指引起缺陷的起因。

8.Root  Cause：缺陷根源，指发生错误的根本因素。

缺陷的其他属性

1.Summary：缺陷摘要，用一句话概要地描述缺陷的现象。

2.Description：缺陷描述，详细的描述缺陷重现环境，前置条件，步骤，期望结果，实际结果等。

3.owner/assignee：负责修复该缺陷的开发人员，在有的系统中也支持开发人员修复好缺陷修改其在缺陷跟踪系统中的 状态把它指定给相关测试人员。

4.found in：缺陷发现的版本。

5.fixed in：缺陷被修复的时候由开发人员填写。

6.resolution：解决办法，由开发人员修复的时候填写。

7.verified in：反映缺陷的修复在哪个版本被验证了。

8.attachment：附件，附加的屏幕截图，服务器或客户端日志等文件，便于开发人员定位缺陷的原因。

缺陷的严重等级划分：

1.Critical：致命，不能被修复/危及人身安全

2.Major：重要，没有相关的办法进行修正。

3.Minor：轻微，有合理的办法进行修正。

4.Cosmetic：表面，易用性不那么方便，但不影响其功能。

5.Other：其他错误。

缺陷状态的分类

1.New：新建缺陷   

2.open：被确认并分配相关开发人员处理。

3.Fixed：开发人员已确认修改，等待测试人员处理。

4.Rejected：拒绝修改缺陷。

5.Deferred：被确认，但延期修改缺陷。

6.Closed：缺陷已被修复。

缺陷报告准则：

1.保证重现缺陷：判断一个缺陷报告撰写好坏的简单方法：

  让非缺陷报告撰写者（技术人员）依据缺陷报告重现缺陷，如果能简单、迅速的重现缺陷，表明缺陷报告较好。

2.分析故障----使用最少步骤重现缺陷：减少开发人员重现缺陷的时间和使开发人员更准确的定位缺陷

3.包含所有重现缺陷的必要步骤

4.缺陷报告方便阅读

5.尽量简单----一个缺陷一个报告

6.语气要工整

7.值得注意的经验：统一缺陷严重度，不要夸大程序缺陷;报告小缺陷;及时报告缺陷

缺陷管理流程：