测试用例规范_第1页
测试用例规范_第2页
测试用例规范_第3页
测试用例规范_第4页
测试用例规范_第5页
免费预览已结束,剩余1页可下载查看

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、1. 概述1.1 目的统一测试用例编写的规范,为测试设计人员提供测试用例编写的指导,提高编 写的测试用例的可读性,可执行性、合理性。为测试执行人员更好执行测试,提高 测试效率,最终提高公司整个产品的质量。1.2 使用范围适用于对产品的业务流程、功能测试用例的编写。1.3名词解释系统测试: 是对已经集成好的软件系统进行彻底的测试,以验证软件系统的 正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一 项简单的任务,它被称为测试的“先知者问题” 。测试分析: 对重要业务、重要流程进行测试前的分析。业务流程测试用例: 关于产品业务、重要流程的测试用例。2. 测试用例编写原则2.1

2、 系统性1、对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系 统组成以及它们之间的关系;2、对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们 之间的关系;2.2 连贯性1、对于系统业务流程来说,各个子系统之间是如何连接在一起,如果需要接 口,各个子系统之间是否有正确的接口;如果是依靠页面链接,页面链接是否正确;2、对于模块业务流程来说,同级模块以及上下级模块是如何构成一个子系统, 其内部功能接口是否连贯;2.3 全面性1、应尽可能覆盖程序的各种路径2、应尽可能覆盖系统的各个业务3、应考虑存在跨年、跨月的数据4、大量数据并发测试的准备5、系统中各功能、业务的异常情

3、况2.4 正确性1、输入用户实际数据以验证系统是否满足需求规格说明书的需求。2、测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。2.5 符合正常业务惯例1、测试数据应符合用户实际工作业务流程2、兼顾各种业务变化的可能3、要符合当前业务行业法律,法规。2.6 仿真性人名、地名、电话号码等应具有模拟功能,符合一般的命名惯例。2.7 容错性(健壮性)程序能够接收正确数据输入并且产生正确(预期)的输出,输入非法数据(非 法类型、不符合要求的数据、溢出数据等) ,程序应能给出提示并进行相应处理。3. 测试用例设计方法1. 等价类划分法:将所有可能的输入数据(有效的和无效的)划分成若干个等价类

4、。2. 边界值分析法:指对输入的边界条件进行分析,设计出针对边界值的测试用例。3. 因果图法:就是利用图解法分析软件输入 (原因)和输出条件 (结果)之间的关系,以设计测 试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合,并最终生成 判定表,来获得对应的测试用例。4. 功能图法功能图是描述程序状态变化、转移的过程,因为软件运行或操作的过程可以看 作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来 的状态,即在满足输入 / 输出的一组条件下,软件运行是一系列有次序的、受控制 的状态变化过程。5. 错误推测法推测法主要依赖经验、直觉来作出简单的判断甚至是猜测,给出

5、可能存在缺陷 的条件、场景等,在找到缺陷后,设计出相应的测试用例。6. 正交实验设计方法主要步骤是:(1) 对软件需求规格说明中的功能要求进行划分 ( 层层分解与展开 ) ,分解成具 体的、相对独立的基本功能。(2) 根据基本功能的质量需求,找出影响其功能实现的操作对象和外部因素, 每个因素的取值可以看作水平,多个取值就存在多个水平。(3) 确定待测试软件中所有因素及其权值,这是测试用例设计的关键,确保全 面、准确。权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。(4) 加权筛选,生成因素分析表。(5) 利用正交表构造测试数据集,正交表的每一行,就是一条测试用例。考虑 交互作用不可

6、忽略的处理因素和不可混杂的原则,有交互作用的组合优先安排。利用正交实验设计方法设计测试用例,可控制生成的测试用例数量,覆盖率高且测试效率高。7. 接口间测试 测试各个模块相互间的协调和通信情况,数据输入输出的一致性和正确性。8. 数据库测试 依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关 系进行测试。9. 可理解(操作)性 理解和使用该系统的难易程度(界面友好性) 。10. 可移植性 在不同操作系统及硬件配置情况下的运行性。4. 测试用例编写规范4.1测试用例书写规则用例元素说明用例名称: 指明要测试的内容,如被测模块名称、业务流程名称等。 功能(业务)描述、规则、逻辑:

7、 对要进行测试的功能或业务进行简 要的描述。根据需求规格说明书、实际业务情况或其它相关文档列出 本用例的规则、逻辑关系或需求点。操作描述(输入 动作): 描述本条测试用例的输入步骤,首先简要描 述本条测试用例的测试点,再对本测试点进行详细步骤描述或输入数 据设置(需要详细进行描写) 。预期结果(输出):描述输入数据后程序应该输出的结果。前提条件 数据准备: 执行测试用例前需先要执行的操作或配置。最基本的要求1具有清晰名称、前提条件、操作步骤、期望结果的;2. 可被他人理解的;3. 可被他人执行的;具体元素要求1用例名称1)一定要包含测试的业务流程。(鉴于公司使用的TD在Test)2)名称简洁易

8、懂,不要包括具体操作步骤;2前置条件1)执行用例测试步骤前需要做的所有必备条件,原则上所有用例都有前 置条件;2)不可将其他用例作为前置条件,前置条件需要语言描述;3)完整清楚,包括入口、帐号类型、账号权限、数据准备等,具体要求 如下:3.1)入口 :覆盖所有功能入口,包含 URL直接访问;3.2)账号类型和权限:覆盖全部会员类型,注意业务权限控制,比如子账 号权限,disable会员权限;3.3)数据准备:数据准备完整正确,覆盖到线上环境的所有情况;标识出业务流程处于的条;件,写明数据库表字段值,如OFFER.status=TBD;对于复杂的数据准备,写清具体SQL3操作步骤1)操作步骤描述

9、清晰。如:在什么页面,点击什么链接或按钮;页面入 口、链接、按钮名称都要写清楚;2) 操作和结果是对应的,但操作中不要包含结果的检查;3)用例描述中不允许存在连词、介词,比如:而且,和,还(这种情况 可以拆分为多个点);4) 用例描述中不允许出现假设性词汇,比如:假如,或许,可能,的 时候等;5)用例描述中不允许出现二义性语句;4预期结果1)原则上每个用例必需要有预期结果,结果不能为空;2)结果中只能包含结果,不能有步骤;3)个结果有多个检查点时,确保检查点完整:3.1)结果含需要验证的所有结果输出,如页面检查、存储检查、消 息检查等;3.2)结果涉及页面,需明确页面提示结果、数据变化;3.3)结果涉及存储:需明确关键值变化、数据库具体的表和关键字 字段值变化;3.4)结果涉及消息:需明确关键查看内容;3.5)结果对应不同输入数据有差别时需分别对应描述清晰;用例维护规范测试用例编写完成后,应对测试用例进行持续的维护:1. 新项目需求变更,应及时对测试用例进行修改;2. 维护期项目,可根据项目组情况周期对用例进行维护;3. 所有发现的bug和故障,基于测试用例无法发

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论