用例编写方法及管理流程说明Word文件下载.doc
《用例编写方法及管理流程说明Word文件下载.doc》由会员分享，可在线阅读，更多相关《用例编写方法及管理流程说明Word文件下载.doc（19页珍藏版）》请在冰点文库上搜索。
n软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。
n基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。
n因为我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。
n目前研究室测试过程中，所有的测试用例都放在《测试大纲》中，使用测试大纲的好处：
n保证测试功能不被遗漏；
n使得功能不被重复测试，合理安排测试人员；
n使得软件测试不依赖于个人；
3．测试用例的意义
使用测试用例的好处主要体现在以下几个方面：
n在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
n测试用例的使用令软件测试的实施重点突出、目的明确。
n在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
n功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。
n组织性－有利于测试的组织；
n功能覆盖－确保功能不被遗漏；
n重复性－有利于测试的重复；
n跟踪－有利于测试的跟踪；
n测试确认－在少数高风险的测试中，必须证明确实执行了计划执行的测试；
4．如何设计测试用例
测试用例一般指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
值得提出的是，测试数据都是从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的。
测试用例是软件测试系统化、工程化的产物，而测试用例的设计一直是软件测试工作的重点和难点。
设计测试用例即设计针对特定功能或组合功能的测试方案，并编写成文档。
测试用例应该体现软件工程的思想和原则
测试用例应由测试人员在充分了解系统的基础上在测试之前设计好，测试用例的设计是测试系统开发中一项非常重要的内容。
集成测试阶段测试用例的设计依据为系统需求分析、系统用户手册和系统设计报告等相关资料的内容，而且测试人员要与开发人员充分交互。
另外有一些内容由测试人员的相关背景知识、经验、直觉等产生
测试用例的设计需要考虑很周全。
在测试系统功能的同时，还要检查系统对输入数据（合法值、非法值和边界值）的反应，要检查合法的操作和非法的操作，检查系统对条件组合的反应等。
好的测试用例让其他人能够很好地执行测试，能够快速地遍历所测试的功能，能够发现至今没有发现的错误。
所以测试用例应该由经验丰富的系统测试人员来编写，对于新手来说，应该多阅读一些好的测试用例，并且在测试实践中用心去体会。
在编写测试用例之前，应该给出测试大纲，大纲基本上是测试思路的整理，以保证测试用例的设计能够清晰、完整而不是顾此失彼。
测试大纲可以按照模块、功能点、菜单和业务流程这样的思路来策划
5．测试用例分析
关于测试用例的分析，通常包括以下的内容：
计划了多少个测试用例，实际运行了多少？
有多少测试用例失败了？
在这些失败的测试用例中，有多少个在错误得到修改后最终运行成功了？
这些测试平均占用的运行时间比预期的长还是短？
测试覆盖了所有影响系统性能的重要事件吗？
等等。
这些问题都可以从相关的测试用例的设计和测试问题记录中找到相应的答案。
当然，如果使用了数据库，这些问题就更能轻松地被解答了。
测试用例的分析报告可以以多种形式体现出来：
文字描述、表、图等。
用例编写方案
测试工作和开发通常一同进行，所以在完成测试计划编写后，就可以进行用例的编写工作。
测试和开发相对应的关系如表：
开发阶段
依据文档
编写的用例
需求分析结束后
需求文档
系统测试对应的用例
概要设计阶段结束后
概要设计、体系设计
集成测试对应的用例
详细设计阶段
详细设计文档
单元测试对应的用例
测试用例各栏目列表如下：
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）
以下为因果图建立的实例
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．评价测试用例的好坏有以下两个标准
① 是否可以发现尚未发现的软件缺陷？
② 是否可以覆盖全部的测试需求？
① 识别测试资源
② 识别测试情形
③ 排序测试情形
④ 确定正确的处理结果
⑤ 创建测试事务
（1）深度
（2）宽度
（3）范围
（4）结构
13.辅助测试工具
做软件测试通常需要以下一些基本工具：
① 优秀的办公处理软件
② 秒表
③ 错误跟踪系统
④ 自动测试工具
⑤ 软件分析工具
⑥ 好的操作系统
⑦ 多样化平台
14.执行测试
执行测试是执行所有的或选定的一些测试用例，并观察其测试结果的过程。
尽管为执行测试所做的准备和计划工作会贯穿于软件开发生命周期之中，但是执行测试往往都会在软件开发生命周期的末期，或者接近末期进行，即在编码完成之后进行。
由于测试过程一般分成代码审查、单元测试、集成测试、系统测试和验收测试几个阶段，尽管这些阶段在实现细节方面都不相同，但其工作流程方面却是一致
14．1执行测试的过程由以下4个部分组成
① 输入。
要完成工作所必须的入口标准或可交付的结果。
② 执行过程。
从输入到输出的过程或工作任务。
③ 检查过程。
确定输出是否满足标准的处理过程。
④ 输出。
推出标准或工作流程产生的可交付的结果。
15．评估测试
软件测试的主要评测方法包括测试覆盖和质量评测。
测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。
质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。
16．覆盖评测
覆盖指标提供了“测试的完全程度如何”这一问题的答案。
最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。
简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）16.质量评测
测试覆盖的评估提供对测试完全程度的评测，在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。
17.性能评测
评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。
18.测试的成功经验
为了减少系统的开发费用，越早测试越好，这是多年来软件行业的一个成功经验，即在整个软件开发生命周期中通过各种软件工程技术尽量早地完成各种软件测试任务。
首先，软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程
在软件开发生命周期中，软件是通过迭代来不断加以完善的。
在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。
对于针对每个工作版本执行的测试，都做出了增补和改进，并累积为一个测试体，用于后续阶段的回归测试。
19.测试种类
阶段和用例关系具体的关系如表所示：
测试阶段
测试类型
执行人员
单元测试
模块功能测试，包含部分接口测试，路径测试
开发人员
集成测试
接口测试、路径测试、含部分功能测试
开员人员，如果测试人员水平较较高的可以由测试人员执行
系统测试
功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试
测试人员
验收测试
对于实际项目基本上同上，并包含文档测试，对于软件产品主要测试相关技术文档。
测试人员，可能包含用户
20．测试用例版本管理
版本管理是用例管理的核心部分，建议用Visualsourcesafe对用例进行控制。
（流程如下）
20．1编写用例：
测试工程师根据需求规约、概要设计，详细设计等文档编定测试用
20．2用例评审：
原则上用例象程序一样，要经过多次的修改才可以通过，实际工作中通常进行一次。
20．3用例修改：
评审结束后，需要根据评审意见进行修改，修改后通常不再进行评审。
如果时间和人力充裕的情况下，对用例的评审就象测试开发部门的产品一样，要经过反复的评评审和修改，然后正式投入使用，因为每次评审都可能有新的发现。
20．4使用用例：
在执行任务时版本按制库取出用例，执行用例时建试超拔接在用例记录上记录测试结果，这样做有两个好处：
首先是下次测试时可以看见上次测试结果，可以起一个提醒的作用，其次，可以统一把发现的缺陷输入到数据中，在输入时可以进行分析，同时避免输入重复的缺陷，每次使用后送入版本控制库，进行版本控制。
20．5用例升级/维护：
随着软件的不断修改、升级，对应的用例也需要升级维护。
针对同一个项目，可以根据需求的变更不断进行维护，对于软件测试用例来说，就随着软件版本的升级而用例的维护版本也要升级，测试用例和版本要做到一一对应。
22．软件测试结果统计分析
软件问题统计与分析，在对软件产品测试过程中发现的问题进行充分分析、归纳和总结的基础上，由全体参与测试的人员完成“软件问题倾向分析表”，对该软件或该类型系统软件产品在模块、功能及操作等方面出错倾向及其主要原因进行分析。
软件问题倾向分析表将为以后开发工作提供一个参考，使开发人员根据软件问题倾向分析表明确在开发过程中应注意和回避的问题。
该表也可为以后的测试工作明确测试重点提供依据。
按版本统计结果图表达的是软件的不同版本在测试时检测出的缺陷（Bug）数的对应关系。
这里的版本指的是同一软件经过不同的测试阶段并修复Bug及作必要的调整后所产生的软件产品。
显然，该图所表达的测试结果的变化是非常理想的。
日期统计结果表达的是在一个测试阶段所发现的缺陷数与测试日期之间的对应关系。
测试过程中所发现的缺陷是随着时间的推移而增多的，但一段时间后，测试所发现的缺陷增加会渐缓，甚至没有增加，如果测试还在进行，那么表明，在现有测试用例、软硬件环境及相关条件下已经很难再发现新的缺陷了（虽然可以肯定系统中仍然存在缺陷），那么这个测试阶段应该考虑停止了。
按等级统计图表达的是测试中所发现的不同等级的缺陷的数目。
关于A、B、C、D等级（或者还有E、F、G、…）所表达的不同含义由相关测试和开发人员来制定，而这种按等级的统计结果可以清楚地反映开发工作中的薄弱之处
按原因统计结果：
表达的是测试所发现的缺陷数目与究其原因缺陷所属的软件工程的不同阶段之间的关系。
这个图表会又一次验证软件工程的任何阶段都会有导致程序中产生错误的因素，只是程度和数目不同而已。
通过该图表的分析，可以清楚地看到，软件工程中的哪个阶段更应该加强控制。
按模块统计：
表达的是程序的不同模块与在其中所发现的缺陷数目之间的关系。
缺陷的产生有多方面的原因，但也可以从该图中反映出哪些程序员所开发的模块中Bug很多，而另一些程序员的则很少，那么在相同的系统设计和工作条件下，这也反映了程序员的工作能力或者责任感的不同
按公开关闭日期统计：
表达的是在测试过程中每日发现的错误报告公开、关闭的对应关系图。
公开是指错误被发现并被公告，关闭则指错误已被处理完毕的状况。
图中中间两条粗线反映的是错误累计公开和累计关闭的实际状况。
随着时间的推移，累计公开和累计关闭的错误数目都是渐增的，但到某个时间点，两条曲线会会合，即累计公开的数目等于累计关闭的数目，那就是说所有发现的错误都得到了处理。
错误原因根本分析：
表达的是错误原因分析，其中纵轴表达的是每类测试发现错误占所有错误的百分比。
可以看出，只有每个错误都被明确细致地归类后才能得到这样的分析图表，也才能知道该从哪里去控制以减少错误的产生。
23．α、β测试
软件开发设计人员在软件开发设计时，不可能完全预见用户实际使用软件系统的情况。
另外，一个软件产品可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以发现那些似乎只有最终用户才能发现的问题。
α测试是在软件开发公司内模拟软件系统的运行环境下的一种验收测试，即软件开发公司组织内部人员，模拟各类用户行为对即将面市的软件产品（称为α版本）进行测试，试图发现并修改错误
经过α测试调整的软件产品称为β版本。
紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况，提出批评意见。
然后软件开发公司再对β版本进行改错和完善。
所以，一些软件开发公司把α测试看成是对一个早期的、不稳定的软件版本所进行的验收测试，而把β测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。
24．回归测试
回归测试是指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试。
每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。
24.1回归测试技术和测试数据
回归测试一般采用黑盒测试技术来测试软件的高级需求，而无须考虑软件的实现细节，也可能采用一些非功能测试来检查系统的增强或扩展是否影响了系统的性能特性，以及与其他系统间的互操作性和兼容性问题。
错误猜测在回归测试中是很重要的。
错误看起来像是通过直觉发现软件中的错误或缺陷，实际上错误猜测主要来自于经验，测试者是使用了一系列技术来确定测试所要达到的范围和程度，这些技术主要有：
① 有关软件设计方法和实现技术；
② 有关前期测试阶段结果的知识；
③ 测试类似或相关系统的经验，了解在以前的这些系统中曾在哪些地方出现缺陷；
④ 典型的产生错误的知识，如被零除错误；
⑤ 通用的测试经验规则。
设计和引入回归测试数据的重要原则是，应保证数据中可能影响测试的因素与未经修改扩充的原软件上进行测试时的哪些因素尽可能一致，否则要想
升级会员 