用例编写方法及管理流程说明.docx
- 文档编号:8811778
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:33
- 大小:70.73KB
用例编写方法及管理流程说明.docx
《用例编写方法及管理流程说明.docx》由会员分享,可在线阅读,更多相关《用例编写方法及管理流程说明.docx(33页珍藏版)》请在冰豆网上搜索。
用例编写方法及管理流程说明
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.什么是测试用例
⏹所谓的测试用例就是将软件测试的行为活动,做一个科学化的组织归纳。
⏹软件测试是有组织性、步骤性和计划性的,而设计软件测试用例的目的,就是为了能
将软件测试的行为转换为可管理的模式。
⏹软件测试是软件质量管理中最实际的行动,同时也是耗时最多的一项。
⏹基于时间因素的考虑,软件测试行为必须能够加以量化,才能进一步让管理阶层掌握
所需要的测试过程,而测试用例就是将测试行为具体量化的方法之一。
⏹因为我们不可能进行穷举测试,为了节省时间和资源、提高测试效率,必须要从数量
极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
⏹目前研究室测试过程中,所有的测试用例都放在《测试大纲》中,使用测试大纲的好
处:
⏹保证测试功能不被遗漏;
⏹使得功能不被重复测试,合理安排测试人员;
⏹使得软件测试不依赖于个人;
3.测试用例的意义
使用测试用例的好处主要体现在以下几个方面:
⏹在开始实施测试之前设计好测试用例,可以避免盲目测试并提高测试效率。
⏹测试用例的使用令软件测试的实施重点突出、目的明确。
⏹在软件版本更新后只需修正少部分的测试用例便可展开测试工作,降低工作强度、缩
短项目周期。
⏹功能模块的通用化和复用化使软件易于开发,而相对于功能模块的测试用例的通用化
和复用化则会使软件测试易于开展,并随着测试用例的不断精化其效率也不断攀升。
⏹组织性-有利于测试的组织;
⏹功能覆盖-确保功能不被遗漏;
⏹重复性-有利于测试的重复;
⏹跟踪-有利于测试的跟踪;
⏹测试确认-在少数高风险的测试中,必须证明确实执行了计划执行的测试;
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.测试用例状态转换分析
以下测试用例生命周期图显示了一个典型测试用例的生命周期,依据不同类型和规模的项
目可以自行定制。
测试用例生命周期图
队列中( In Queue ) -- 测试用例在排队等待中;
进程中( In Progress ) -- 表示测试正在进行,并且可能会持续一段时间,如果一个测试
花费的时间少于一天或两天,只需将它显示在处于排队状态;
阻塞( 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)
以下为因果图建立的实例
A.。
根据因果图建立判定表。
按条件的各种组合情况产生对应的动作。
原因 1 和原因 2 不能同时成立,故可排除这种情
况。
从判定表可设计出测试用例:
6 个测试用例是所需的数据。
Ø 例如,有一个处理单价为 5 角钱的饮料的自动售货机软件测试用例的设计。
其规格
说明如下:
”
若投入 5 角钱或 1 元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出
来。
若售货机没有零钱找,则一个显示〖零钱找完〗的红灯亮,这时在投入 1 元硬币并押
下按钮后,饮料不送出来而且 1 元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红
灯灭,在送出饮料的同时退还 5 角硬币。
(1) 分析这一段说明,列出原因和结果
原因:
1.售货机有零钱找
2.投入 1 元硬币
3.投入 5 角硬币
4.押下橙汁按钮
5.押下啤酒按钮
建立中间结点,表示处理中间状态
11. 投入 1 元硬币且押下饮料按钮
12. 押下〖橙汁〗或〖啤酒〗的按钮
13. 应当找 5 角零钱并且售货机有零钱找
14. 钱已付清
结果:
21. 售货机〖零钱找完〗灯亮
22. 退还 1 元硬币
23. 退还 5 角硬币
24. 送出橙汁饮料
25. 送出啤酒饮料
B.画出因果图。
所有原因结点列在左,所有结果结点列在右边。
C. 由于 2 与 3 ,4 与 5 不能同时发生,分别加上约束条件 E。
D. 因果图
9.传统的测试用例文档编写有两种方式
一种是填写操作步骤列表:
将在软件上进行的操作步骤一步一步详细记录下来,包括所
有被操作的项目和相应的值。
另一种是填写测试矩阵:
将被操作项作为矩阵中的一个字段,而矩阵中的一条条记录,
则是这些字段的值。
10.评价测试用例的好坏有以下两个标准
① 是否可以发现尚未发现的软件缺陷?
② 是否可以覆盖全部的测试需求?
11.创建测试数据时主要考虑如下步骤。
① 识别测试资源
② 识别测试情形
③ 排序测试情形
④ 确定正确的处理结果
⑤ 创建测试事务
12.确定实际的测试数据时,必须说明处理测试数据的以下 4 个属性。
(1)深度
(2)宽度
(3)范围
(4)结构
13.辅助测试工具
做软件测试通常需要以下一些基本工具:
① 优秀的办公处理软件
② 秒表
③ 错误跟踪系统
④ 自动测试工具
⑤ 软件分析工具
⑥ 好的操作系统
⑦ 多样化平台
14. 执行测试
执行测试是执行所有的或选定的一些测试用例,并观察其测试结果的过程。
尽管为执行
测试所做的准备和计划工作会贯穿于软件开发生命周期之中,但是执行测试往往都会在软
件开发生命周期的末期,或者接近末期进行,即在编码完成之后进行。
由于测试过程一般
分成代码审查、单元测试、集成测试、系统测试和验收测试几个阶段,尽管这些阶段在实
现细节方面都不相同,但其工作流程方面却是一致
14.1 执行测试的过程由以下 4 个部分组成
① 输入。
要完成工作所必须的入口标准或可交付的结果。
② 执行过程。
从输入到输出的过程或工作任务。
③ 检查过程。
确定输出是否满足标准的处理过程。
④ 输出。
推出标准或工作流程产生的可交付的结果。
是
产品输入
执行测试
检查测
试工作
产品输出
工具
15. 评估测试
软件测试的主要评测方法包括测试覆盖和质量评测。
测试覆盖是对测试完全程度的评测,
它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。
质量评测是对测试对象
(系统或测试的应用程序)的可靠性、稳定性以及性能的评测,它建立在对测试结果的评
估和对测试过程中确定的变更请求(缺陷)分析的基础上。
16.覆盖评测
覆盖指标提供了“测试的完全程度如何”这一问题的答案。
最常用的覆盖评测是基于需求
的测试覆盖和基于代码的测试覆盖。
简而言之,测试覆盖是就需求(基于需求的)或代码
的设计/实施标准(基于代码的)而言的完全程度的任意评测,如用例的核实(基于需求的)
或所有代码行的执行(基于代码的)16.质量评测
测试覆盖的评估提供对测试完全程度的评测,在测试过程中已发现缺陷的评估提供了最
佳的软件质量指标。
17.性能评测
评估测试对象的性能行为时,可以使用多种评测,这些评测侧重于获取与行为相关的数
据,如响应时间、计时配置文件、执行流、操作可靠性和限制。
18.测试的成功经验
为了减少系统的开发费用,越早测试越好,这是多年来软件行业的一个成功经验,即在整
个软件开发生命周期中通过各种软件工程技术尽量早地完成各种软件测试任务。
首先,软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程
在软件开发生命周期中,软件是通过迭代来不断加以完善的。
在这种环境中,对于每个作
为测试目标的工作版本,测试的生命周期还都必须具有一种迭代方法。
对于针对每个工作
版本执行的测试,都做出了增补和改进,并累积为一个测试体,用于后续阶段
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 编写 方法 管理 流程 说明