*报告软件测试错误注意点-总结

上一篇 / 下一篇  2012-11-05 14:12:11 / 个人分类:测试基础知识

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

1.描述(Descrīption),简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置。

描述要准确反映错误的本质内容,简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误,包含错误发生时的用户界面(UI)是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

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

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

  4. UI要加引号,可以单引号,推荐使用双引号
  UI
加引号,可以容易区分UI与普通文本,便于分辨、定位缺陷或错误。

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

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

  7.根据缺陷或错误类型,选择图象捕捉的方式
 
为了直观的观察缺陷或错误现象,通常需要附加缺陷或错误出现的界面,以位图的形式作为附件附着在记录的附件部分。为了节省空间,又能真实反映缺陷或错误本质,可以捕捉缺陷或错误产生时的全屏幕,活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置,通常要求附加中英文对照图。

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

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

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

  11.通用UI要统一、准确
 
错误报告的UI要与测试的软件UI保持一致,便于查找定位。

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

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

 以上概括了报告测试错误的规范要求,随着软件的测试要求不同,测试者经过长期测试,积累了相应的测试经验,将会逐渐养成良好的专业习惯,不断补充新的规范书写要求。此外,经常阅读、学习高级测试工程师的测试错误报告,结合自己以前的测试错误报告进行对比和思考,可以不断提高技巧。

 

 

 

有关界面测试经验总结

 

1.应验证界面显示内容的完整性:
a)报表显示时应考虑数据显示宽度的自适应或自动换行。
b)
所有有数据展现的界面(如统计、查询、编辑录入、打印预览、打印等),必须使测试数据的记录数超过一屏/一页,以验证满屏/页时其窗体是否有横向、纵向滚动条或换页打印,界面显示是否正常。

2.
应验证界面显示内容的一致性:
a)如有多个系统展现同一数据源时,应保证其一致性;

3.
应验证界面显示内容的准确性:

a)
对于报表中的所有字段值都应该有明确的定义,对于无意义的字段值,不应该显示空,应显示“--”“/”,表示该字段值无意义。

4.
应验证界面显示内容的友好性:
a)对统计的数据应按用户习惯进行分类、排序。
b)
某些重要信息在输入、修改、删除时应有确认提示信息;
c)
界面内容更新后系统应提供刷新功能。

d)
用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面;

5.
应验证界面提示信息的指导性:

a)在多个业务功能组成的一个业务流程中,如果各个功能之间的执行顺序有一定的制约条件,应通过界面提示用户。
b)
用户提示信息应具有一定的指导性,在应用程序正在进行关键业务的处理时,应考虑在前台界面提示用户应用程序正在进行的处理,以及相应的处理过程,在处理结束后再提示用户处理完毕。
c)
在某些数据输入界面,如果要求输入的数据符合某项规则,应在输入界面提供相应的规则描述;当输入数据不符合规则时应提示用户是否继续。
d)
在对任何配置信息修改后,都应该在用户退出该界面时提示用户保存(如果用户没有主动保存的情况下); 

6.
应验证界面显示内容的合理性:
a)在对某些查询功能进行测试时,应考虑查询条件的设置的合理性以及查询结果的互补性。如某些后台处理时间不应该作为查询条件。
b)
界面测试时,应考虑某一界面上按钮先后使用的顺序问题,以免用户对此产生迷惑。例如只能在查询成功后显示执行按钮。
c)
界面测试时,应验证窗口与窗口之间、字段与字段之间的浏览顺序是否正确;

7.
界面测试时,应考虑用户使用的方便性:

a)在某些对数据进行处理的操作界面,应考虑用户可能对数据进行处理的频繁程度和工作量,考虑是否可以进行批量操作。

8.
界面测试时,应考虑界面显示及处理的正确性:
a)界面测试时应验证所有窗体中的对象状态是否正常,是否符合相关的业务规则需要。
b)
应验证各种对象访问方法(光标移动和快捷键)是否可正常使用,并且在一个激活界面中快捷键无重复;


9.
界面测试时,应考虑数据显示的规范性:

a)确保数据精度显示的统一:如单价0元,应显示为0.00;
b)
确保时间及日期显示格式的统一
;
c)
确保相同含义属性/字段名的统一
;
d)
对所有可能产生的提示信息界面内容和位置进行验证,确保所有的提示信息界面应居中。


TAG:

 

评分:0

我来说两句

Open Toolbar