软件测试用例规范

  • 格式:doc
  • 大小:34.50 KB
  • 文档页数:4

下载文档原格式

  / 7
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

用例书写规范

测试用例是执行测试工作的依据,不仅能有效的保障知识传递和测试的管理;更重要的是能确保测试的系统性和全面性。我们写测试用例就是为了在测试中尽可能多的发现软件存在的问题,尽可能的减少缺陷的遗漏,通过事前预防保障软件的质量。

该规范的目的是为用例设计人员提供测试用例编写的指导,提高编写的测试用例的可读性、合理性,及可执行性。使测试人员可以更好的执行测试,进而提高软件的质量。

一、用例写作要点

1、用例编号

测试用例编号是由字母和数字组合而成的,用例的编号应该具有唯一性,易识别性,比如可以采用统一的约定,产品编号_ST_系统测试项名_系统测试子项名_编号。这样看到编号就可以知道是做的什么测试,测试的对象是什么,也方便维护。

例如CMP系统中登陆模块的功能测试用例命名为:CMP_ST_GN_login_001。

2、测试项目

你现在这个测试用例所测的项目名,可以是测试用例所属的大类,被测需求,被测的模块,或者是被测的单元。

例如:权限管理模块

3、用例标题

测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复,因为每个测试用例的测试点事不一样的。

例如:手机在没有SIM卡的情况下,拨打119.

4、重要级别

重要级别分为高中低三等:

高:保证系统基本功能、重要特性、实际使用频率比较高的用例;

中:重要程度介于高和低之间的测试用例

低:实际使用频率不高,对系统业务功能影响不大的模块或功能的测试用例。

注意:一般情况下,重要级别为高的测试用例,一个测试子项里有且仅有一个,大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试项,如果重要级别为高的太多,则就失去了预测试的实际意义。

5、预置条件

就是执行当前测试用例的前提描述,如果不满足这些条件,则无法进行测试。

例如要进行CMP的登录测试:预置条件应该有:网络正常,系统正常,数据库连接成功,服务器环境已经启动成功

6、测试输入

测试用例执行时,需要输入的外部信息。

例如:某一个文件,数据记录等

7、操作步骤

执行当前测试用例所要经过的操作步骤,需要给出每一步操作的详细描述,测试人员根据测试用例操作步骤,完成测试用例的执行

例如要进行CMP的登录测试的测试步骤:

1、打开火狐浏览器

2、在浏览器URL中输入地址:http://192.168.30.142:18080/cmp

3、在用户名文本框中输入:super

4、在密码文本框中输入:super

5、点击登录按钮或者按回车键

8、预期结果

当前测试用例的预期输出结果,用来与实际结果比较,如果相同则该测试用例通过,否则该测试用例失败。

例如:成功登录系统,界面元素正确

9、作者:谁写的

10、创建日期:写用例的日期

11、修改日期:最后一次修改用例的日期

12、测试结果:执行用例后的结果Pass、Fail、Block

最主要必不可缺的事前8个写作要点,需要融汇掌握

二、用例分类

用例计划分为三类:业务流程用例、单功能用例、集成测试用例。

业务流程用例

业务流程用例是为了测试软件是否能完成用户正常的业务处理流程,及对异常业务流程的控制处理是否完善而设计的用例。

此类用例要求覆盖到用户所有可能的业务流程,并且需要尽可能多的设计一些实际中因为误操作或不熟悉业务而出现的异常的业务流程。梳理出流程后,为每个流程编写一个测试用例。一个业务的所有流程构成该业务的流程测试用例文档。

单功能用例

单功能用例针对某一个单独的功能编写,是为了测试功能对正常数据、异常数据、空数据的处理控制存储是否正确而设计的用例。

此类用例是根据等价类划分法、边界值分析法、错误推测法等方法确认出测试数据,进

而设计出相对完备的测试用例的过程。此类用例的测试数据要求覆盖正常数据范围、异常数据范围、及空数据;每个单独的功能都要编写一个测试用例。一个页面所有功能构成一个单独的功能测试用例文档。

集成测试用例

集成测试用例是为了测试不同开发组提交的程序之间模块接口及数据传输处理是否正确而设计的测试用例。

此类用例主要用来测试维护数据的模块对被主功能模块使用的数据的维护控制是否正确,同时测试主功能模块对基础模块准备的数据的调用处理是否正确。此类用例要求覆盖所有的调用接口,及所有的基础数据状态。每个需要集成测试的功能单独构成一个集成测试用例文档。

三、用例编写原则

A、功能或流程划分时,一定要简单、清晰,一个测试用例只检查一个功能点或一个流程;否则测试用例会比较混乱,降低了可读性。

B、测试用例要有一个简单直观的名字,有助于读者对测试用例的理解。

C、测试用例的步骤描述要简单、清晰,一步就是一步。比如:第一步,用户登陆;第二步,用户点击“用户信息”;第三步,用户修改姓名为“张&三”;第四步,用户点击保存。这有利于提高用例的可操作性。

D、测试用例的数据要明确,特别是输入数据和期望结果。比如,测试准备数据:用户:张三,李四,王二。在排序后用例的预期结果为:李四,王二,张三。这样,用例在执行时,很清晰,有很高的可操作性,执行者对于执行结果是否正确也非常清楚。

E、测试用例需要保障唯一性,即功能用例之间不存在重叠,流程用例不存在包含关系。没有重复、冗余的测试用例,满足相应的行业标准。

F、描述要清晰、包括特定的场合、对象和术语,没有含糊的概念和一般性的描述。应尽量避免不确定的用词,如:如果、若、否则、大概、可能等。

G、测试用例中保证异常用例的比例达到75%以上。

H、测试用例应确保覆盖详细设计中的所有功能。单功能用例要覆盖所有数据操作处理的功能点;流程用例要尽可能的覆盖程序的各种路径,考虑存在跨年、跨月的数据,兼顾各种业务变化的可能。

I、对于无输入的操作,应该详细描述其具体的操作步骤和结果.。

J、测试用例需要保障数据的正确性和操作的正确性.首先保证测试用例的数据正确,其次预期的输出结果应该与测试数据发生的业务吻合.操作的预期结果应该与程序发生的结果吻合。

K、容错性(健壮性)测试:程序能够接受正确数据输入并且产生正确(预期)的输出,输入非法数据(非法类型、不符合要求的数据、溢出数据等),程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂得客户在进行任意操作。