测试用例编写规范

一、测试用例编写准备

从配置管理员处申请软件配置:《需求规格说明书》和《设计说明书》;根据需求规格说明书和设计说明书,详细理解用户的真正需求,并且对软件所实现的功能已经准确理解,然后着手制订测试用例。

二、测试用例制定的原则

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试;基本目标是:设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面:

1、    正确性测试:输入用户实际数据以验证系统是满足需求规格说明书的要求;测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。

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

3、    完整(安全)性测试:对未经授权的人使用软件系统或数据的企图,系统能够控制的程度,程序的数据处理能够保持外部信息(数据库或文件)的完整。

4、    接口间测试:测试各个模块相互间的协调和通信情况,数据输入输出的一致性和正确性。

5、    数据库测试:依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

6、 边界值分析法:确定边界情况(刚好等于、稍小于和稍大于和刚刚大于等价类边界值),针对我们的系统在测试过程中主要输入一些合法数据/非法数据,主要在边界值附近选取。

7、 压力测试:输入10条记录运行各个功能,输入30条记录运行,输入50条记录运行。。。进行测试。

8、等价划分:将所有可能的输入数据(有效的和无效的)划分成若干个等价类。

9、错误推测:主要是根据测试经验和直觉,参照以往的软件系统出现错误之处。

10、效率:完成预定的功能,系统的运行时间(主要是针对数据库而言)。

11、可理解(操作)性:理解和使用该系统的难易程度(界面友好性)。

12、可移植性:在不同操作系统及硬件配置情况下的运行性。

13、回归测试:按照测试用例将所有的测试点测试完毕,测试中发现的问题开发人员 已经解决,进行下一轮的测试。

14、比较测试:将已经发版的类似产品或原有的老产品与测试的产品同时运行比较,或与已往的测试结果比较 。

说明:针对不同的测试类型和测试阶段,测试用例编写的侧重点有所不同。

1、  其中第1、2、6、8、9、13项为模块(组件、控件)测试、组合(集成)测试、系统测试都涉及并重点测试的方面。

2、  单元(模块)测试(组件、控件)测试:重点测试第5项。

3、  组合(集成)测试:重点进行接口间数据输入及逻辑的测试,即第4项。

4、  系统测试:重点测试第3、7、10、11、12、14项。

5、  其中压力测试和可移植性测试如果是公司的系列产品,可以选用其中有代表性的产品进行一次代表性测试即可。

6、  GMPS基础测试用例设计完成后,其他的测试项目只编写设计与之不同部分的测试用例。

7、  对于每个测试项目测试的测试用例不是一成不变的,随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时,可以不断的补充完善测试项目的测试用例。

三、测试用例的填写

一个软件系统或项目共用一套完整的测试用例,整个系统测试过程测试完毕,将实际测试结果填写到测试用例中,操作步骤应尽可能的详细,测试结论是指最终的测试结果(结论为:通过或不通过)。

时间: 2024-10-10 11:11:12

测试用例编写规范的相关文章

网上看到的,关于测试用例编写粒度准则

一.界面规范1.是否整个软件的字段的字体.大小.颜色.排列一致2.是否整个软件的字段后都有冒号(如果有,是否都属于同一种字体) 二.用例编写粒度准则1.对于不作为一个完整业务流的操作,如增.删.改等,每个操作(比如增加)作为一个用例.2.对于完整的业务功能实现的操作,把实现一个业务功能的目的作为一个用例.3.对于紧密关联的业务功能,把关联的业务功能实现作为一个用例.4.对于异常情况下的操作,作为一个用例.5.对于在异常情况下的操作的数据处理,作为一个用例. 网上看到的,关于测试用例编写粒度准则,

测试用例编写思路

    测试用例的编写可不简单呢,写一份专业的测试用例,是所有测试工作者考虑的内容,其实用例的编写是可以通过一些思路来进行,不少比较成熟的公司为了提升用例的专业性,就会有自己的用例库,包括流程.关注点,以及自己定义的模板. 今天作为测试老鸟的我经过几年的经验沉淀总结出来的一套测试用例编写思路,该思路累计共有八步,经验过验证几乎所有功能性测试都可以依据该架构思路来进行,将最大限度提升用例设计的专业程度 第一步.UI体验测试 1.风格.样式.颜色是否协调 2. 界面布局是否整齐.协调(保证全部显示出

Java学习---Java代码编写规范

编码规范 1 前言为确保系统源程序可读性,从而增强系统可维护性,java编程人员应具有基本类似的编程风格,兹制定下述Java编程规范,以规范系统Java部分编程.系统继承的其它资源中的源程序也应按此规范作相应修改. 2 适用范围本文档将作为java编程人员软件开发的编程格式规范.在项目Java部分的编码.测试及维护过程中,要求严格遵守. 3 命名规范定义这个规范的目的是让项目中所有的文档都看起来像一个人写的,增加可读性,减少项目组中因为换人而带来的损失. 3.1 Package 的命名Packa

Postman接口测试脚本编写规范

Postman接口测试脚本编写规范 1.前言 2.名词解释 3.接口测试脚本规范 3.1接口测试脚本编写的规范 3.2 Postman使用规范 4.单个接口测试 5.整个流程的开发过程 1.前言 本规范的目的是保证测试部成员编码的统一. 本规范的核心规则就是接口测试脚本命名规则. 2.名词解释 业务流程测试用例:关于产品业务.重要流程的测试用例. 3.接口测试脚本规范 3.1接口测试脚本编写的规范 1)基本信息 在每个脚本模块的最上面,必须写上脚本编写人(使用英文名或中文拼音缩写).脚本创建时间

linux驱动模块编写规范以及Makefiel文件的编写规范

内核驱动模块的编写规范 驱动模块一般涉及的必用的头文件: <linux/init.h><linux/module.h><linux/kernel.h> 驱动模块的入口函数的规范: int __init entry_name(void){ /*xxx*/ return 0;} module_init(entry_name); 驱动模块的出口函数规范: void __exit exit_name(void){ } module_exit(exit_name); 模块的信息的

存储过程编写规范

--******************************************************** --* 存储过程名:EXP_TO_BATCH --* 版本:1.0 --* 用途:批量导入报销(支持日常.加班.差旅.报销) --* 参数:当前用户ID 批号 --* 输出:O_STATE:0成功 1:失败 O_MSG:成功或失败信息 --* --* 作者:humeng 时间:2013-07-18 --***************************************

为什么谷歌要执行严格的代码编写规范(转)

我们在谷歌所做事情中另外一个让我感到异常有效.有用的制度是严格的编码规范. 在到Google工作之前,我一直认为编码规范没有什么用处.我坚信这些规范都是官僚制度下产生的浪费大家的编程时间.影响人们开发效率的东西. 我是大错特错了. 在谷歌,我可以查看任何的代码,进入所有谷歌的代码库,我有权查看它们.事实上,这种权限是很少人能拥有的.但是,让我感到惊讶的却是,如此多的编码规范-缩进,命名,文件结构,注释风格-这一切让我出乎意料的轻松的阅读任意一段代码,并轻易的看懂它们.这让我震惊-因为我以为这些规

20151009 C# 第一篇 程序编写规范

20151009 程序编写规范 1. 代码书写规则: 1).尽量使用接口,然后使用类实现接口. 2).关键语句写注释 3).避免写超过5个参数的方法,如果要传递多个参数,则使用结构 4).避免代码量过大的try…catch…模块 5).避免在同一个文件中放置多个类 6).switch 语句一定要有default语句处理意外情况 7).生成和构建一个长字符串时,一定要使用StringBuilder类型(可变字符序列),而不使用string 8).if 语句应该使用{}包含起来. 2. 命名规范 1

非计算机专业的码农C#学习笔记 二、C#程序编写规范

二.C#程序编写规范 1.代码书写规则: 代码书写规则呢,是相对初学者来说需要了解一下的东西.因为我们还嫩,暂时不追求什么代码审美.规范.专业还有逻辑审美这类的,不会乱成一套就好了.所以,我也不全死记烂背规则,就注意一下代码整洁这个问题.有时候,经理或者需求发布人需要我们解说一下,代码不整洁,连我们自己都找不到那可怎么办.还是记住几个: (1)记住ctrl+K+F这个快捷键,自动帮你整理选中的代码,看起来整洁吧: (2)项目时间长,分阶段写的代码最好还是#region一下,能够很好帮你回忆: (