用例编写方法及管理流程说明.doc
- 文档编号:335294
- 上传时间:2022-10-09
- 格式:DOC
- 页数:19
- 大小:430KB
用例编写方法及管理流程说明.doc
《用例编写方法及管理流程说明.doc》由会员分享,可在线阅读,更多相关《用例编写方法及管理流程说明.doc(19页珍藏版)》请在冰豆网上搜索。
目录
1.测试用例是软件测试的核心 2
2.什么是测试用例 2
3.测试用例的意义 3
4.如何设计测试用例 3
5.测试用例分析 4
6.有没有跳过一些测试?
如果有,为什么?
4
7.测试用例状态转换分析 5
8.黑盒测试的测试用例设计 7
9.传统的测试用例文档编写有两种方式 8
10.评价测试用例的好坏有以下两个标准 9
11.创建测试数据时主要考虑如下步骤。
9
12.确定实际的测试数据时,必须说明处理测试数据的以下4个属性。
9
13.辅助测试工具 9
14.执行测试 10
15.评估测试 10
16.覆盖评测 10
17.性能评测 11
18.测试的成功经验 11
19.测试种类 11
20.测试用例版本管理 11
21.软件测试流程:
12
22.软件测试结果统计分析 13
24.回归测试 16
25.测试策略 17
测试用例编写方法写及其管理流程
1.测试用例是软件测试的核心
Ø如何以最少的人力、资源投入,在最短的时间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标。
Ø测试用例是测试工作的指导,是软件测试的必须遵守的准则。
更是软件测试质量稳定的根本保障。
2.什么是测试用例
n所谓的测试用例就是将软件测试的行为活动,做一个科学化的组织归纳。
n软件测试是有组织性、步骤性和计划性的,而设计软件测试用例的目的,就是为了能将软件测试的行为转换为可管理的模式。
n软件测试是软件质量管理中最实际的行动,同时也是耗时最多的一项。
n基于时间因素的考虑,软件测试行为必须能够加以量化,才能进一步让管理阶层掌握所需要的测试过程,而测试用例就是将测试行为具体量化的方法之一。
n因为我们不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
n目前研究室测试过程中,所有的测试用例都放在《测试大纲》中,使用测试大纲的好处:
n保证测试功能不被遗漏;
n使得功能不被重复测试,合理安排测试人员;
n使得软件测试不依赖于个人;
3.测试用例的意义
使用测试用例的好处主要体现在以下几个方面:
n在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。
n测试用例的使用令软件测试的实施重点突出、目的明确。
n在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩短项目周期。
n功能模块的通用化和复用化使软件易于开发,而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。
n组织性-有利于测试的组织;
n功能覆盖-确保功能不被遗漏;
n重复性-有利于测试的重复;
n跟踪-有利于测试的跟踪;
n测试确认-在少数高风险的测试中,必须证明确实执行了计划执行的测试;
4.如何设计测试用例
测试用例一般指对一项特定的软件产品进行测试任务的描述,体现测试方案、方法、技术和策略。
值得提出的是,测试数据都是从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的。
测试用例是软件测试系统化、工程化的产物,而测试用例的设计一直是软件测试工作的重点和难点。
设计测试用例即设计针对特定功能或组合功能的测试方案,并编写成文档。
测试用例应该体现软件工程的思想和原则
测试用例应由测试人员在充分了解系统的基础上在测试之前设计好,测试用例的设计是测试系统开发中一项非常重要的内容。
集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容,而且测试人员要与开发人员充分交互。
另外有一些内容由测试人员的相关背景知识、经验、直觉等产生
测试用例的设计需要考虑很周全。
在测试系统功能的同时,还要检查系统对输入数据(合法值、非法值和边界值)的反应,要检查合法的操作和非法的操作,检查系统对条件组合的反应等。
好的测试用例让其他人能够很好地执行测试,能够快速地遍历所测试的功能,能够发现至今没有发现的错误。
所以测试用例应该由经验丰富的系统测试人员来编写,对于新手来说,应该多阅读一些好的测试用例,并且在测试实践中用心去体会。
在编写测试用例之前,应该给出测试大纲,大纲基本上是测试思路的整理,以保证测试用例的设计能够清晰、完整而不是顾此失彼。
测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划
5.测试用例分析
关于测试用例的分析,通常包括以下的内容:
计划了多少个测试用例,实际运行了多少?
有多少测试用例失败了?
在这些失败的测试用例中,有多少个在错误得到修改后最终运行成功了?
这些测试平均占用的运行时间比预期的长还是短?
6.有没有跳过一些测试?
如果有,为什么?
测试覆盖了所有影响系统性能的重要事件吗?
等等。
这些问题都可以从相关的测试用例的设计和测试问题记录中找到相应的答案。
当然,如果使用了数据库,这些问题就更能轻松地被解答了。
测试用例的分析报告可以以多种形式体现出来:
文字描述、表、图等。
用例编写方案
测试工作和开发通常一同进行,所以在完成测试计划编写后,就可以进行用例的编写工作。
测试和开发相对应的关系如表:
开发阶段
依据文档
编写的用例
需求分析结束后
需求文档
系统测试对应的用例
概要设计阶段结束后
概要设计、体系设计
集成测试对应的用例
详细设计阶段
详细设计文档
单元测试对应的用例
测试用例各栏目列表如下:
6.1用例ID—用于唯一标识测试用例号,可根据自身需要定义规则,最好易于跟踪和维护;
6.2版本:
软件版本号
6.3作者:
编写测试用例的人
6.4测试时间:
测试一条测试用例的相对时间
6.5用例级别:
按ABC三个等级定义
6.6功能项:
列出所测的功能项目
6.8预置条条:
列出用例的预置条件
6.9测试目的:
用例的测试目的
6.10测试步骤:
描述测试的过程、步骤或状态
6.11预期结果:
预料中与规格相符的正确结果
6.12执行结果:
实际测试结果
6.13.测试结论:
对测试作最终结论
6.14.问题ID
6.14.测试日期
6.15测试人
6.16备注
测试用例各阶段方法描述:
第一阶段:
冒烟测试,即版本确认测试,每个测试版本需通过所有该级测试用例,否则拒绝继续测试;(至顶向底的测试方法)
第二阶段:
关键路径测试,每个测试版本需执行该级测试用例,若该级测试用例均通过,意味着软件功能趋于稳定;(至底向顶的测试方法)
第三阶段:
可接受级测试,该级测试用例只要执行一次通过即可,该级测试用例通过意味着可以准备发布了(验收测试,如果有时间,最好执行该级测试用例)
测试用例执行结果—执行时填写,分为通过、失败、警告、阻塞、忽略
测试用例覆盖率分析报告
7.测试用例状态转换分析
以下测试用例生命周期图显示了一个典型测试用例的生命周期,依据不同类型和规模的项目可以自行定制。
测试用例生命周期图
队列中(InQueue)--测试用例在排队等待中;
进程中(InProgress)--表示测试正在进行,并且可能会持续一段时间,如果一个测试花费的时间少于一天或两天,只需将它显示在处于排队状态;
阻塞(Block)--一些外部条件—如缺少部分功能—将无法执行测试;
忽略(Skip)--已经决定(或被告知)跳过这个测试用例;
通过(Pass)--终点状态,没问题;
失败(Fail)--测试用例执行出错;
警告(Warn)--结果处于Pass和Fail之间,错误严重性等级较轻,不影响功能和性能;
关闭(Closed)--以前识别出的错误都已经被修正。
实际项目中,一个测试用例有多个执行步骤,每个步骤可能有不同结果,如步骤1通过,步骤2失败,步骤3被步骤2中的失败所阻塞,那么该测试状态如何?
单纯指出这个测试用例阻塞或失败都将遗漏重要的信息。
因此必须指定双重状态,如:
阻塞/失败,阻塞/警告,忽略/通过,忽略/关闭等。
然而,如果显示十几个状态,则测试结果可能更难以解释。
如何使结果明了又能精确反映实际结果,需要精明选择包括哪些状态。
(举例:
多媒体播放测试用例ID1—29(播放状态如下图)ID158、ID232、ID233)
8.黑盒测试的测试用例设计
目前黑盒测试的测试用例设计方法有4~5种:
8.1等价类划分
等价列划分设计方法是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少量具有代表性的数据作为测试用例。
等价类是指某个输入域的子集合。
在该子集合中,各个输入数据对于揭露程序中的错误都是等效的。
并合理地假定:
测试某等价类的代表值就等于对这一类其他值的测试。
等价类划分有两种不同的情况:
有效等价类和无效等价类。
设计时要同时考虑这两种等价类。
干个无效等价类(从不同角度违反规则)。
6.在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进等价类中按以下的3个原则设计测试用例:
为每一个等价类规定一个唯一的编号
设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止。
设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止。
(举例多媒体测试用例ID158…:
关于文件名的显示用例类:
有效文件名、无效文件名、文件名长度等)
8.2边界值分析法
使用边界值分析方法设计测试用例,首先:
应确定边界情况。
通常输入和输出等价类的边界,就是应着重测试的边界情况。
其次,应但选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
基于边界值分析方法选择测试用例的原则:
1、 如果输入条件规定了值的范围,应取刚达到这个范围的边界值,以及刚刚超过这个范围边界的值作为测试输入的数据。
2、 如果输入条件规定了值的个数,应用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。
3、 根据规格说明的每个输出条件,使用前面的原则1。
4、 根据规格说明的每个输出条件,使用前面的原则2。
5、 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例数据。
6、 如果程序中使用了一个内部数据结构,应当选择这个内部数据结构边界上的值作为测试用例。
7、 分析规格说明,找出其他可能的边界条件。
(例如多媒体测试用例ID161)
8.3错误推测法
错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误,从而有针对性地设计测试用例的方法。
基本思路:
列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
例如:
输入数据和输出数据为0的情况。
下表为输出条件及相应的测试用例表。
(媒体播放器测试用例ID224、ID225、ID226)
8.4因果图法
因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。
利用因果图生成测试用例的基本步骤:
8.41.1 分析软件规格说明描述中那些是原因,那些是结果,并给每个原因和结果赋予一个标识符。
8.4.2 分析软件规格说明描述的语义。
找出原因和结果之间、原因和原因之间的关系,根据这些关系,画出因果图。
8.4.3 在因果图上用一些记号表明约束或限制条件。
8.4.4 把因果图转换为判定表。
8.4.5 把判定表的每一列拿出来作为依据,设计测试用例。
(例如多媒体测试用例ID108--140)
以下为因果图建立的实
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 编写 方法 管理 流程 说明