测试用例编写规范.docx
- 文档编号:14267416
- 上传时间:2023-06-22
- 格式:DOCX
- 页数:11
- 大小:21.36KB
测试用例编写规范.docx
《测试用例编写规范.docx》由会员分享,可在线阅读,更多相关《测试用例编写规范.docx(11页珍藏版)》请在冰点文库上搜索。
测试用例编写规范
测试用例编写标准
技术部
赖文举
编写人
赖文举
编写日期
2021年3月1日
审核人
审核日期
批准人
批准日期
变更历史
序号
变更内容
变更页
变更类别
变更者
新建
/
/
/
引言
1.背景
为保证测试用例对需求的覆盖率,即对一个系统从整体功能到单个功能,都尽可能的高的覆盖。
而单个功能点主要强调的是不同的输入及其组合所带来的各种输入动作,系统是否都做了处理;
测试用例设计首先要明确该系统存在多少功能点,要通过各种常用的测试方法来保证用例的完好性,然后再对各功能点的边界范围进展考虑。
所以要保证测试用例的设计按照一种合理的构造组织进展,这样才可以更有效的保证系统所有功能点的覆盖率。
2.目的
为测试用例的质量负责,使测试工作能有序、合理化的进展,从而进步施行测试时对所测产品、系统或者模块的测试质量,也是作为各测试人员在设计用例时的一种标准,使之设计的用例能有效的被管理。
3.概念
是指为了施行测试而编写的一组有标准性、有据可依的输入数据与输出数据的组合,也指为了施行测试而向被测对象提供的一组输入、输出数据以及由各种执行条件和期望结果相组合的一个特定集合,以便测试某个程序途径或者来核实是否满足某个特定的需求。
4.适用范围
●本文档适用于测试人员
●本文档适用于系统进展测试时的测试案例设计
●本文档适用于案例补充时的测试案例
用例标准
用处
●指导测试工作有序进展,使施行测试的数据有据可依
●确保所实现的功能与客户预期的需求相符合
●完善软件不同版本之间的重复性测试
●跟踪测试进度,确定测试重点
●评估测试结果的度量标准
●增强软件的可信任度
●分析缺陷的标准。
设计根据
●需求说明书
●工程测试需求功能点
●所属行业的业务知识掌握程度
●测试工程师本人的理解程度〔个人经历〕
用例内容
1
用例实际内容
用例编号
唯一标识。
规那么“模块名-功能点-编写人-001,单词或中文首字母。
2
模块名称
模块名称
3
功能点
测试的功能点
4
用例标题
对测试项简短的描绘
5
用例级别
确定用例执行的级别[P0,P1,P2,P3]
6
前提条件
执行用例时需要的预置条件
7
操作步骤
执行该动作需要完成的操作,需要明确输入数据。
8
预期结果
执行完该动作后程序的表现结果
9
执行结果
执行状态
用例的执行结果[通过,失败,延后]
10
实际结果
实际输出的结果
11
问题描绘
执行该用例出现后系统显示的错误
12
BUG编号
填写bug库中对应此用例的BUG编号
13
执行人
按照该用例执行测试的人员
编写用例原那么
●系统性:
对系统业务流程要完好说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系;对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系
●连接性:
对系统业务流程要说明各个子系统之间是如何连接在一起,假设需要接口,各子系统之间是否有正确的接口,假设是依靠页面链接,那么页面的链接是否正确;对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统,其内部功能接口是否连接
●全面性:
应尽可能覆盖各种途径、尽可能覆盖各个业务点,并要考虑跨年、跨月的数据以及大数据量并发测试的准备
●正确性:
输入界面后的数据应与测试文档所记录的数据一致,而预期结果也应与测试数据发生的业务吻合
●符合正常业务规那么:
测试数据要符合用户实际工作中的业务流程,同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规、人名、地名、号码等应具有模拟功能,符合一般的命名惯例;不允许出现与知名人士、小说中人物名等雷同情况。
●可操作性:
测试用例中要写清楚测试的操作步骤,以及不同的操作步骤相对应的测试结果
编写用例标准
●测试案例编写应该制订统一的模板进展,并约定模板的使用方法;
●测试案例编写应当根据工程实际情况编写测试案例编写手册,包括案例编号规那么、案例编写方法、案例编写内容、案例维护等内容;
●案例编写应根据手册中约定的编写方法、内容等进展编写;
●案例编写要步骤明确,输入输出要素明晰,并且与需求和缺陷相对应;
●案例编写应严格根据需求规格说明书及测试需求功能分析点进展,要求覆盖全部需求功能点;
●注重案例的可复用性,即在以后相似系统的测试过程中可以重复使用,减少测试设计工作量。
用例设计步骤
测试需求分析:
从软件需求分析文档中,找出待测软件/模块的需求,通过自己的分析、理解,整理成为测试需求,要清楚被测对象详细包含哪些功能点。
业务流程分析:
对所在行业的业务知识要熟悉,然后对被测软件/模块的业务流程要进展全盘的整理出来〔可画简单的流程图作为参考〕,主要包含该业务流程的主流程、备选流程、数据流向、关键判断条件以及完成该操作的非必要条件。
测试用例设计:
测试用例设计的类型主要包括功能测试、边界测试、异常测试、性能测试、压力测试等,在设计用例时要尽量考虑边界、异常等情况。
测试用例评审:
由测试用例设计者发起,参加的人员需包括测试负责人、工程经理、开发人员及其他相关的测试人员。
测试用例完善:
测试用例编写完成之后需不断完善,软件产品新增功能或更新需求后,测试用例必须配套修改更新;
在测试过程中发现设计测试用例时考虑不周,需要对测试用例进展修改完善;
在软件交付使用后客户反应的软件缺陷,而缺陷又是因测试用例存在破绽造成,也需要对测试用例进展完善;
用例级别划分
P0:
确保系统根本功能及主要功能的测试用例
P1:
确保系统功能的完善方面的测试用例
P2:
关于用户体验,输入输出的验证;较少使用或辅助功能的测试用例。
P0〔优先执行〕:
即关键途径的测试用例,包括最常执行的功能、根本流程的输入以及界面数据有效性校验作为高级别的测试用例;假设该级别的测试用例完全执行通过,那么表示该软件功能渐趋稳定;
P1〔次级执行〕:
即可接收级测试的用例,包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例;假设该级别的测试用例完全执行通过,那么表示该软件可以进展发布了;
P2〔最后执行〕:
即建议执行的测试用例,也就是说该级别的测试用例不是不重要,而是该级别的用例在整个工程的生命周期内不是常常被运行,包括:
GUI、界面显示、错误信息提示不统一、可用性、压力和性能测试等。
备注:
对已有的用例级别说明,包括A-正常流程测试、B-异常流程测试、C-页面元素正常输入测试、D-页面元素异常输入测试、E-页面元素显示测试,可详细归类如下〔仅供参考〕:
P0:
A-正常流程测试、C-页面元素正常输入测试
P1:
B-异常流程测试、D-页面元素异常输入测试
P2:
E-页面元素显示测试
用例的维护
删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再合适被测系统,那么这些测试用例就会过时,需要对这些测试用例进展及时的删除,在删除过程中,不可以将整行的测试用例删除,应该将要删除的测试用例整行置灰,并将该行的用例计数器清为空;
当整个功能模块需要删除时,那么将整个SHEET状态置灰,并将用例计数器清空
修改的测试用例
随着软件工程的进展,测试需求可能会有局部变更,甚至大范围的变更,这个时候我们就会根据需求的变化相应的对测试用例进展维护,修改已经不符合目前需求的内容,并在备注栏中加以说明
删除冗余的测试用例
假如存在两个或更多测试用例对一组一样的输入和输入进展测试,那么需要对其进展删除,只需留下其中的一个
增添新的测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例,需要按照测试用例的设计标准进展增添,增加测试用例时,需要在相应功能模块的最下方插入新增的测试用例,并在备注栏中加以说明
用例设计方法
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
测试数据应该选用少量、高效的测试数据进展尽可能完备的测试;根本目的是:
设计一组发现某个错误或某类错误的测试数据,测试用例应覆盖方面:
等价划分:
将所有可能的输入数据〔有效的和无效的〕划分成假设干个等价类。
边界值分析法:
确定边界情况〔刚好等于、稍小于和稍大于和刚刚大于等价类边界值〕,针对我们的系统在测试过程中主要输入一些合法数据/非法数据,主要在边界值附近选取。
场景法:
通过运用场景来对系统的功能点或业务流程的描绘,从而进步测试效果的一种方法。
用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。
根本流:
是经过用例的最简单的途径〔无任何过失,程序从开场直接执行到完毕〕
备选流:
一个备选流可能从根本流开场,在某个特定条件下执行,然后重新参加根本流中,也可以起源于另一个备选流,或终止用例,不在参加到根本流中;〔各种错误情况〕
因果图:
利用图解法分析输入的各种组合情况,设计测试用例,检查程序输入条件的各种组合情况。
正交表:
在界面中有多个控件,控件之间有多种组合关系,假如组合的数量宏大〔一般超过20种〕,没有必要将所有组合都测试,可以通过正交排列法将组合中最优,最少的组合进展测试。
正确性测试:
输入用户实际数据以验证系统是满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。
容错性〔强健性〕测试:
程序可以接收正确数据输入并且产生正确〔预期〕的输出;输入非法数据〔非法类型、不符合要求的数据、溢出数据等〕,程序应能给出提示并进展相应处理。
把自己想象成一名对产品操作一点也不懂的客户,在进展任意操作。
完好〔平安〕性测试:
对未经受权的人使用软件系统或数据的企图,系统可以控制的程度,程序的数据处理可以保持外部信息〔数据库或文件〕的完好。
接口间测试:
测试各个模块互相间的协调和通信情况,数据输入输出的一致性和正确性。
数据库测试:
根据数据库设计标准对软件系统的数据库构造、数据表及其之间的数据调用关系进展测试。
压力测试:
输入10条记录运行各个功能,输入30条记录运行,输入50条记录运行,进展测试。
错误推测:
主要是根据测试经历和直觉,参照以往的软件系统出现错误之处。
效率:
完成预定的功能,系统的运行时间〔主要是针对数据库而言〕。
可理解〔操作〕性:
理解和使用该系统的难易程度〔界面友好性〕。
可移植性:
在不同操作系统及硬件配置情况下的运行性。
回归测试:
按照测试用例将所有的测试点测试完毕,测试中发现的问题开发人员。
比拟测试:
将已经发版的类似产品或原有的老产品与测试的产品同时运行比拟,或与已往的测试结果比拟。
兼容性测试:
操作系统的兼容性测试内容不仅包括软件的安装,还需对关键流程和功能点进展检查。
而需要测试哪些操作系统的兼容性,首先取决于软件用户文档上对用户的承诺,其次就需要对一些常用操作系统兼容的检查
历史版本兼容性测试:
某些功能存在新版本和历史版本数据显示、页面展示不一致的问题。
需要不同版本进展测试。
用例评审
评审原因
测试用例是软件测试的原那么,但由于软件人员对在需求理解、设计等理解程度不同等因素的影响,首次产生的测试用例质量难以防止会有不同程度的差异,故对编写的测试用例进展评审是很有必要的,其作用是测试用例的评审过程可以起到用例构造明晰化、场景覆盖全面化以及优先用例的合理化安排等。
评审内容
用例设计的构造安排是否明晰合理,是否高效的需求进展覆盖用例的优先级别是否安排合理
是否覆盖了测试需求的所有功能点,包括需求中的业务规那么、所有用户可能使用的流程或场景等
用例是否有很好的可执行性。
例如用例的前提条件、执行步骤、输入数据和期待结果是否明晰、正确
是否已经删除了冗余的测试用例
是否包含充分的负面测试用例是否简洁、复用性强、是否易于管理
评审过程
基于工程需求的测试方案完成之后,进展初审,主要是对测试范围和测试要点进展审查在测试用例的设计完成之后进展复审,主要是对测试用例的构造和覆盖率进展评审所有测试用例完毕后,主要是对测试用例的详细描绘是否有很好的可执行性,是否有冗余用例的存在进展评审
评审人员
部门评审:
测试部全体成员参与的评审
工程评审:
工程组全体测试人员与局部开发人员、产品人员等组成的小组
内部评审:
全部参与测试的人员
评审方式
会议评审〔包括内部评审及客户评审〕。
由设计该用例的人员进展讲解,参与会议评审的相关人员给出意见或建议,并记录评审的意见和建议
邮件评审邮件形式发给参与评审的相关人员,然后以邮件的形式把评审意见反应给评审发起人。
完毕标准
经评审的用例由用例设计者根据评审的建议或意见进展修改,更新用例,再次发起评审、修改、更新用例,反复评审后,直至用例到达要求。
〔反复评审时存在时间问题〕
用例执行
1、建立测试方案
2、建立对应的版本
3、添加测试用例到对应的测试方案中
4、分派测试用例给制定的测试人员
5、逐条执行测试用例,并及时更改用例状态,通过时,标记通过,当用例执行失败时,编写缺陷报告。
6、回归测试,阻塞和失败用例重新执行后,及时更改用例状态。
风险分析
●没有正式需求的测试用例。
●用例编写进度跟不上工程进度
●用例的评审只是走形式
●需求变更后未及时通知测试人员
●测试人员后期参加工程,对需求理解不透彻
●执行用例不彻
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 编写 规范
![提示](https://static.bingdoc.com/images/bang_tan.gif)