BUG描述规范

一、 目的与适用范围

1.1 目的

报告软件测试错误的目的是为了保证修复错误的人员可以明确报告的错误,从而有利于分析错误产生的原因,定位错误,然后修正之。因此,报告软件测试错误的基本要求是准确、简洁、完整、规范。

1.2 适用范围

本规范适用于测试过程中对BUG描述的规范与约束。

二、 BUG描述规范

1. 描述:简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置 描述要准确反映错误的本质内容,简短明了。为了便于寻找指定的测试错误,描述中要包含错误发生时的用户界面(UI)。例如记录对话框的标题、菜单、按钮等控件的名称。

2. 明确指明错误类型:布局、翻译、功能等 ;

根据错误的现象,总结判断错误的类型。例如,布局错误、翻译错误、功能错误、双字节错误,这是最常见的缺陷或错误类型,其他形式的缺陷或错误也从属于其中某种形式。

3. 短行之间使用自动数字序号,使用相同的字体、字号、行间距;   短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。

4. UI要加引号,可以单引号,推荐使用双引号;

UI加引号,可以容易区分UI与普通文本,便于分辨、定位缺陷或错误。

5. 每一个步骤尽量只记录一个操作;   保证简洁、条理井然,容易重复操作步骤。

6. 确认步骤完整,准确,简短;

保证快速准确的重复错误,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。

7. 根据缺陷或错误类型,选择图象捕捉的方式;

为了直观的观察缺陷或错误现象,通常需要附加缺陷或错误出现的界面,以位图的形式作为附件附着在记录的“附件”部分。为了节省空间,又能真实反映缺陷或错误本质,可以捕捉缺陷或错误产生时的全屏幕,活动窗口和局部区域。

8. 附加必要的特殊文档、个人建议和注解;

如果打开某个特殊的文档而产生的缺陷或错误,则必须附加该文档,从而可以迅速再现缺陷或错误。有时,为了使缺陷或错误修正者进一步明确缺陷或错误的表现,可以附加个人的修改建议或注解。

9. 检查拼写和语法错误;

在提交每条缺陷或错误之前,检查拼写和语法,确保内容正确,正确的描述错误。

10. 尽量使用业界惯用的表达术语和表达方法;

使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。

11. 通用UI要统一、准确;

错误报告的UI要与测试的软件UI保持一致,便于查找定位。

12. 尽量使用短语和短句,避免复杂句型句式;

软件错误管理数据库的目的是便于定位错误,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。

13. 每条错误报告只包括一个错误;

每条错误报告只包括一个错误,可以使错误修正者迅速定位一个错误,集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。

时间: 2024-12-11 11:35:23

BUG描述规范的相关文章

UseCase事件流描述规范

文/fasiondog 整理需求用例的编写规范,分享部分UseCase事件流描述规范.其中,准则5~10.12来自<编写有效用例>([美] Alistair Cockburn 著)一书,其它为自身实践和要求. 事件流包含正常事件流.可选事件流.异常事件流程,前述三者合在一起的本质就是用文字描述的流程.事件流由文字描述的步骤组成,写作过程中应遵循以下准则,这些准则是对用例写作过程中的常见问题和最佳实践的总结.下述规范中如没有特殊说明,事件流同时指正常事件流.可选事件流.异常事件流. 准则1:文字

bug管理规范

资源来自:http://wenku.baidu.com/view/ae55b3b565ce05087632132b.html

记录一次bug解决过程:规范变量名称和mybatis的使用以及代码优化

一.总结 Mybatis中当parameterType为基本数据类型的时候,统一采用_parameter来代替基本数据类型变量. Mybatis中resultMap返回一个对象,resultType返回一个Map简单数据类型(由于需要缓存到JVM中)的映射关系. String类型转Integer类型:String类型转int类型用到的方法是不一样的. 方法入口处第一行写new Date(),防止时间在23:59:59跨界对逻辑带来影响. 考虑到上线app_resource表忘记配置供应商比例,在

测试指南(适用于Feature/promotion/bug)

1.提前了解需求,在需求的业务基础和开发的架构基础上分析测试关键点,给出测试策略,甚至需要准备测试数据: 2.分析需求时不要受开发影响,要有自己的分析和判断,包括测试范围,测试时间: 3.在开始测试之前,根据之前的分析准备 qa checklist for every feature/promotion/bug fix,如果时间允许可以写scenario/checklist,甚至test case; 4.在开发提测后,先把整个业务最关键的逻辑测试一遍,然后报第一轮bug,目的有两个,一是发现关键

Bug管理那些事_20160910

1.bug由来 虫子爬进主机引起继电器短路,导致机器故障.真正的缺陷是:主机散热孔少装了块金属丝,这样才能防止虫子爬到主机. 2.什么是bug? bug是缺陷的一种表现形式,而一个缺陷是可以引发多种bug的.软件测试,为了发现软件中的错误而运行软件的过程. Bug评判点 1)软件未达到客户需求文档 的功能和性能 2)软件出现客户需求不能容忍的错误 3)软件的使用未能符合客户的习惯和工作环境(易用性兼容性) 4)软件超出需求文档的范围(需求bug) Bug分类: Defect,缺陷:存在于软件中的

浅谈软件测试团队规范建设

一些已经从事测试工作三到五年的朋友正在积极的向QA Manager 角色转型,他们对于将来的发展方向也很一致,普遍观点大都是组建一支出色高效的测试团队.最近我也想了一些团队规范和成为具有出色团队称号的必要条件,自己从事测试工作也接近四年了,有些是我在原先工作中遇见并且总结出来的,写的我认为还谈不上全面以后还会逐渐补全. 条件: 缺陷管理 首先正规测试团队至少会有一个缺陷管理系统,不管是Bugzilla还是Mantis 或是其它系统,因为软件测试过程本身就是围绕着缺陷进行的,这也是测试工作的一个重

问题单提单和回归规范

问题单是版本测试过程中发现问题问题,也可以称作为bug.缺陷.提单是每一个测试人员必备技能之一.但是并不是所有的测试人员都会很好的完成这一项工作.当发现问题时如何提单.如何确保自己提单内容合理,可以减少与开发沟通工作量,甚至后续测试人员重新验证该同步单时可以直接从问题单中获取到有效信息.本文主要从问题单提单规范.提单内容规范和回归问题单内容规范这三个方面来描述. 问题单提单规范 1.提单正确性.当版本测试过程中,发现疑似问题时,需要自己分析问题根因.如果分析不出来,也需要找开发定位确认问题.不能

BUG YII2.0 cURL error 6: Could not resolve host:

BUG描述:登录直接显示 原因:服务器设置端口权限,或者DNS毛病 解决方案:只能去服务器端设置,配置端口 DNS: 修改dns 114.114.114.114 或者 8.8.8.8

BUG YII2.0 $ is not defined

BUG描述:$ is not defined 没有加载jquery成功 原因:Yii2.0将JS代码默认加载页面加载后 解决方案: 第一种方案:最简单方法是在 assets\AppAsset.php 中加上,页面前加载 public $jsOptions = array( 'position' => \yii\web\View::POS_HEAD ); 第二种方案:But in production you usually want the scripts to load last, and i