测试用例管理.docx
《测试用例管理.docx》由会员分享，可在线阅读，更多相关《测试用例管理.docx（18页珍藏版）》请在冰豆网上搜索。
测试用例管理
1测试用例概述
测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例构成了设计和制定测试过程的基础,测试的“深度”与测试用例的数量成正比例,随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
测试用例是软件测试的核心,是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。
全面且细化的测试用例，不仅可以更准确地估计测试周期各连续阶段的时间安排，还能通过用例的覆盖率、通过率和执行测试用例的数量来有效评估软件质量和测试工作量。
测试用例是测试工作的指导，所以做好测试用例管理和运维优化尤其重要。
2测试用例设计
测试用例就是编写一组条件、输入，执行条件，预期结果并完成对特定需求或目标的测试，体现测试方案，方法，技术和策略的文档。
测试种类繁多，针对不同类型的测试，测试用例的设计方式完全不同。
如:
性能测试的用例中需设计大量的测试运行场景，准备相应的性能指标供测试人员填写，并进行数据分析。
本章着重探讨的是功能测试中使用的测试用例，为避免混淆，方便叙述，后续未说明的测试用例均指功能测试的测试用例，有特殊需要之处将进行特别说明。
2.1测试用例设计原则
测试用例设计应遵循以下原则：
1、全面性
Ø用例中的测试点应保证至少覆盖需求规格说明书中的各项功能
Ø应尽可能覆盖程序的各种路径
Ø应尽可能覆盖系统的各个业务
Ø应考虑存在跨年、跨月的数据
Ø应尽可能全面的考虑系统中各功能、业务的异常情况
2、正确性
Ø用户输入的数据应与测试文档所记录的数据一致，预期结果应与测试数据发生的业务吻合
Ø用户验证系统输入的实际数据应当满足需求规格说明书的需求
3、可操作性
Ø测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果
4、规范性
Ø所有测试案例的编写要求规范，对于所有被测的功能点，应用程序均应该按照需求说明书和相关技术规范中的给定形式，在规定的边界值范围内使用相应的工具、资源和数据执行其功能
5、符合正常业务惯例
Ø测试数据应符合用户实际工作业务流程
Ø兼顾各种业务变化的可能
Ø要符合当前业务行业法律，法规
6、连贯性
Ø对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确
Ø对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯
7、仿真性
Ø人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例，不允许出现与知名人士、小说中人物名等雷同情况
8、容错性（健壮性）
Ø程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理，尽量站在用户角度进行操作
2.2测试用例设计规范
测试用例是测试的核心，整个测试环节以及测试结果分析均以测试用例为准，所以规范的测试用例能保证测试工作的正常开展。
2.2.1测试用例命名规范
以功能模块和业务流程进行命名，一级目录使用个项目的顶级菜单名称来命名，二级目录使用顶级菜单下的二级菜单名称类命名，用具可根据名字判别该用例是测试那个模块的，各用例根据各用例的功能来命名，经理简介明了，同一目录下的用例名字字数最好相同。
2.2.2测试用例编号规范
测试用例采用以下编号约定方式：
Ø测试类型：
用一个字母代表，F代表功能性测试，NF代表非功能性测试；
Ø子系统：
用一个字母代表，一般以测试子系统名称的第一个字母进行命名（大写），若测试子系统名称比较长，可进行简写，一般简拼不超过5个字母。
Ø用例编号：
用五位数字代表，从00001顺序编号。
2.2.3模块功能测试用例划分
模块功能的测试用例在编写中采用树形目录来划分，树形目录按照模块功能来划分，第一级为系统名称，第二级为子系统名称，第三级为模块名称。
当模块中有多个TAB页时，可列在第四级，目录最深为四级，若有更深层次的页面可提升到第四级中。
2.2.4测试用例文档书写规范
1、测试用例模版
按常用测试用例模版，根据公司及项目需求设计出符合要求的统一标准的测试用例模版。
2、文档格式约束
文档模板：
文档编制应严格依据本文档模板的格式要求。
引用描述格式：
Ø《<资料名称>》<发布单位><发布日期>
Ø《<资料名称>》（<文号>）
Ø《<资料名称>》（<标准号>）
文字格式：
ØWord样式，正文首行缩进
Ø首行缩进2字符，宋体，小四，1.5倍行距，段前0，段后0
表格格式
Ø列标题，Word样式，表格标题
Ø列标题，首行缩进无，居中，宋体，五号，单倍行距，段前0，段后0
Ø列标题，重复标题行
Ø表格正文，Word样式，表格正文居左
Ø表格正文，首行缩进无，居左，宋体，五号，单倍行距，段前0，段后0
Ø表格正文中的序号，Word样式，表格正文居中
Ø表格正文中的序号，首行缩进无，居中，宋体，五号，单倍行距，段前0，段后0
图格式：
ØWord样式，图居中
2.2.5通用检查项
通用检查项列出一些包括页面功能、易用性、合理性等方面的内容，适合公司所有项目，供测试人员测试时参考。
2.3测试用例设计方法
黑盒测试的目的是检查功能是否实现或遗漏，交互界面是否出错，数据库读取，更新操作是否出错，性能和特性是否得到满足。
黑盒测试设计方法有等价类划分、边界值分析、因果图、判定表分析法、错误推测等方法，具体描述如下：
1、等价类划分法
把所有可能的输入数据（有效的和无效的）,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。
该方法是一种重要的,常用的黑盒测试用例设计方法。
2、边界值分析法
对输入或输出的边界值进行分析测试的一种黑盒测试方法。
通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
3、因果图法：
就是利用图解法分析软件输入（原因）的各种组合和输出条件（结果）之间的关系，以设计测试用例的方法。
因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。
4、判定表分析法
判定表是分析和表达多逻辑输入条件下系统执行不同操作的情况的工具。
它能够将复杂的逻辑问题和多种条件组合的情况按照各种可能的情况全部列举出来，简明并避免遗漏。
因此，利用判定表能够设计出完整的测试用例集合。
5、错误推测法
推测法主要依赖经验和直觉推测程序中所有可能存在和容易发生错误的特殊情况，来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，从而有针对性的设计测试用例的方法。
6、状态迁移法
许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上。
对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，可能不可能产生非法的状态转移等。
7、流程分析法
将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。
根据流程的顺序依次进行组合，使得流程的各个分支都能走到。
8、正交实验设计法
正交试验设计发是从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理的安排实验的一种科学的实验设计方法。
9、异常分析法
系统异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此实际测试用例。
主要针对系统的容错能力、故障恢复能力进行测试。
10、接口间测试
测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
11、数据库测试
依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
12、可理解（易操作）性
理解和使用该系统的难易程度（界面友好性）。
13、可移植性
在不同操作系统及硬件配置情况下的运行性。
2.4测试用例包含内容
测试用例是测试人员执行测试时的重要参照标准。
因此，测试用例必需使测试人员能够明确理解，并能够依据测试用例的描述执行测试。
为此，一个设计良好的测试用例应当包括如下几个关键字段：
1、用例编号（testcaseIndex），一个软件项目可能拥有数量庞大的测试用例。
应根据项目设计一个良好的用例编号体系，那么通过用例编号，便可对测试用例进行快速定位，查询时事半功倍。
2、用例名称（testCaseName），用例名称的编写应使用最精简的文字，描绘出用例的全貌。
编写良好的用例名称如同书籍的目录，能够帮助阅读者整理思路，定位用例。
3、前置条件（precondition），复杂工作流软件自动化测试方法的研究第二章软件测试理论与技术基础前置条件指测试执行者在执行测试用例的操作步骤前，必须完成的准备工作。
常见的前置条件有:
系统的配置、权限的设置、数据的准备、输入条件限制、前置工序的执行等。
4、测试步骤（Teststep），测试用例中，每个操作均可设计为一个步骤。
一个测试用例由一个或多个测试步骤组成。
常见可将测试步骤分为正常步骤和容错步骤。
正常步骤指普通用户为了实现正常功能，进行的普遍的、正确的、系统期待的操作。
正常步骤描述的操作通常在需求文档中会有明确的说明，也是程序需要实现的主要功能。
容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。
对此类错误操作，系统应有足够的容忍性，进行一些友好的提示、阻止或处理，而不是产生异常。
需求文档中，通常会对正常步骤进行明确定义。
因此，正常步骤是严谨的，甚至是唯一的，编写者的发挥空间非常狭小。
容错流程恰恰相反。
一个思维活跃、经验丰富的测试人员在编写容错步骤时，能够考虑到各类不同的容错步骤，其编写出的测试用例也是全面、广泛而又犀利的。
容错流程的编写深度与广度能够很好的反映编写者的技术实力。
综上，一个编写良好的测试用例中应该包括两部分内容：
描述准确的正常步骤，以及广泛深入的容错步骤。
5、步骤描述（Deseription），步骤描述是测试步骤的主体，是测试人员执行测试时的重要阅读对象。
因此，测试步骤必须表述详细，描述清晰，用语必须规范、严谨而又客观。
最基本的要求是能够使其他人理解，并能正确的执行编写者期望的操作。
6、期望结果（〔xpeetedRests），期望结果是执行测试时，测试者所进行比对的标尺，是一个测试步骤是否通过的标准答案。
期望结果必须要保证其正确性。
错误的期望结果带来的后果是严重的，不在此赘述。
7、实际结果（ActualResultS）实际结果供测试人员在运行测试时填写观察到的实际结果。
填写的内容同样需做到规范、严谨与客观。
8、测试结论（TestResult）与实际结果类似，测试结论供测试人员运行测试时填写。
若实际结果与期望结果两者一致，或虽然不一致，但在可接受范围内，则可以认为该步骤是通过的，测试结论应置为passed;若两者不一致，且无法接受，则应将结果置为Failed。
2.5测试用例设计注意事项
测试用例的设计过程繁杂而浩大，是一项耗时费力的工作，基于用例的重要性，我们必须认真耐心的完成。
由于它的繁杂性，设计测试用例时我们必须注意以下几点：
1、设计测试用例时，用户经常使用、关系到系统核心功能、优先级别较高的功能点，测试用例应该达到100%的覆盖率。
2、针对各个系统端到端的功能以及与其他系统的接口的测试应该达到100%覆盖率。
3、测试用例包括正常输入和正常业务流程测试，也包括对非法数据输入和异常处理的测试，且对系统非正常操作的测试用例占到总数的20%-30%。
4、测试用例中应包括中文特性及系统本地化测试，如中文信息的显示、录入、查询、打印和报表显示测试等。
5、功能测试用例设计首先考虑等价划分类，边界值共用，并用错误推测法补充；如果业务流程清晰可采用场景法设计；若程序有详细的因果关系，应该一开始就采用因果图法；如果是文件配置类型的测试，考虑功能图法。
6、集成测试用例设计要点按详细设计说明书来设计，测试用例数据来源于UC，内部逻辑结构分析按单元测试进行。
7、系统测试用例根据需求分析来检验软件是否满足功能，行为，性能，系统协调性等方面的要求。
使用的数据应具有代表性，并与真实数据的大小和复杂性相当。
8、验收测试用例设计应该在研发阶段测试用例基础上重新编写，而不能直接拿来使用。
需与客户需求相对应、面向客户，把握客户的关注点并适当展示软件的独特性。
9、回归测试用例设计不需要重复设计，只需选择以前的测试用例，针对最重要或最频繁使用的功能测试用例。
3测试用例级别
如何有效的维护和优化用例，就是需要前期明确的分类规划，根据分类的优先级一步一步地来完成就可以了，这样，我们也可以有效把控的测试覆盖度。
根据二八原则或者称数据统计，前20%的用例可以发现80%的重要BUG。
当设计测试用例时，分配优先级非常不容易，且这个优先级也不是固定不变的，常见用例优先级划分如下：
Ø最高
BVTs（BuildVerificationtests）也叫冒烟测试用例，一组你运行以确定这个build版本是否可测的测试用例。
Ø高
这种用例运行，能发现重要的错误，或者它能够保证软件的功能是稳定的。
俗称大的基本功能的测试用例。
Ø中
检查功能的一些细节，包括边界，配置测试。
Ø低
较少执行的测试用例，并不代表它不重要，而是说不是经常被运行。
例如压力测试错误信息等。
用例级别设置：
如果没有很多的时间来确定优先级，那么可以先大致的进行划分：
把所有功能性验证的用例标注为高；把边界值或错误能力的用例标注为中；把非功能性和易用性的标注为低。
提升和降级：
针对1描述的所有高级别的功能性用例划分为重要和不十分重要两种，然后重要的保持高，不十分重要的降级为中。
同理，对应中级别的用例，重要的进行升级，不十分重要的保持中。
对应低级别的，重要的升级，不十分重要的保持。
确定BVTs：
将高优先级的用例划分为严重和重要，严重的将升级为bvts，经过这个流程后，大致会控制bvt10%、高为25%、中55%、低10%，但具体还要结合具体的项目和质量目标确定。
一般，划分测试用例级别是我们会假设发现bug的严重程度和bug对应的测试用例的优先级是平行的，这样可以根据发现bug的程度来划分对应测试用例的级别。
4测试用例评审
测试用例评审流程规范主要为开展测试用例评审工作提供指引，规范测试用例评审管理工作。
测试用例评审流程内容：
1、前提
Ø测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写
2、流程输入
Ø测试用例
Ø需求规格说明
3、流程输出
Ø问题记录清单
Ø测试用例评审报告
4、参与评审人员
Ø项目经理、测试负责人、测试人员、需求分析人员、架构设计人员、开发人员
5、评审方式：
Ø召开评审会议。
与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录；
Ø通过邮件、及时通讯工具与相关人员沟通。
无论采用哪种方式，都应该在评审之前事先把需要评审的测试用例相关文档以邮件的形式发给参与评审的相关人员，同时在邮件中提醒参与评审的相关人员在评审前查阅一遍评审内容，并记录相关问题，以便在评审会议上提出，以节省沟通成本。
6、评审用例检查清单：
Ø测试用例是否按照公司定义的模板进行编写的
Ø测试用例的本身的描述是否清晰，是否存在二义性
Ø测试用例内容是否正确，是否与需求目标相一致
Ø测试用例的期望结果是否确定、唯一的
Ø操作步骤应与描述是否相一致
Ø测试用例是否覆盖了所有的需求
Ø测试设计是否存在冗余性
Ø测试用例是否具有可执行性
Ø是否从用户层面来设计用户使用场景和业务流程的测试用例
Ø场景测试用例是否覆盖最复杂的业务流程
Ø用例设计是否包含了正面、反面的用例
Ø对于由系统自动生成的输出项是否注明了生成规则
Ø测试用例应包含对中间和后台数据的检查
Ø测试用例应有正确的名称和编号
Ø测试用例应标注有执行的优先级
Ø测试用例包含相关的配置信息：
测试环境、数据、前置测试用例、用户授权等
Ø每个测试用例步骤应<=15Step
Ø自动化测试脚本必须带有注释（注释应包括：
目的、输入、期望结果等）
Ø非功能测试需求或不可测试需求是否在用例中列出并说明
7、退出标准
Ø评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过
Ø评审结束后，测试负责人出测试用例评审报告给到相关人员
Ø评审结果经项目经理同意确认
8、控制机制
Ø采用会议评审时，主持人应把握会议进度，尽量按时有效的完成评审工作
9、输出清单
Ø问题记录清单
Ø测试用例评审报告
5测试执行结果分析
软件测试执行结束后，测试活动还没有结束。
测试结果分析是必不可少的重要环节，“编筐编篓，全在收口”，测试结果的分析对下一轮测试工作的开展有很大的借鉴意义。
5.1测试用例执行结果
测试员执行测试用例后需要对执行的用例进行分类统计，一遍进行相关数据度量，这就需要一个分类标志，一般都是以执行结果来分：
Ø通过（Pass）
执行测试用例，实际结果与预期结果一致。
Ø不通过（Failed）
用户执行用例时，实际结果与预期结果不相符。
在记录执行结果不通过时应注明原因。
Ø未执行（unexecuted）
一些外界原因导致用例不能正常进行，导致此状态原因有时间不足，推迟缺陷，安装问题，超出范围，或由于其他缺陷导致不能执行用例等。
5.2测试用例相关度量
测试用例执行结果可以从覆盖率、执行率、通过率等几个方面进行分析和考察。
测试用例覆盖率是只测试用例覆盖的功能与测试需求功能的比值；测试用例执行率是指已执行的测试用例数与测试用例总数的比值；测试用例通过率是指成功执行的测试用例数与测试用例总数的比值。
测试用例相关度量：
Ø日平均产出用例数
日平均产出用例数是测试员平均每天能编写的用例数，用来衡量测试员的编写用例能力，测试负责人可以依据此来安排工作时间和分配工作任务，具体算法如下：
日平均产出用例数=用例总数/编写天数
Ø日平均执行用例数
日平均执行用例数是测试员每天平均能执行的用例个数，用来衡量测试员的执行用例能力，测试负责人可以依据此来安排工作时间和分配工作任务，具体算法如下：
日平均执行用例数=用例总数/执行用例天数
Ø用例覆盖率
用例覆盖率是用来度量目前已编写用例的需求占总需求的百分比，即测试用例编写完成的百分比，项目经理和测试负责人可以通过这个数据清除的知道测试用例编写完成的工作量及剩余工作量，通过完成工作量花费时间估算出剩余工作需要的工作时间，具体算法如下：
用例覆盖率=用例总数/需求总数*100%
测试用例的覆盖率需要达到100%，也就是说测试用例必须覆盖全部的测试需求，否则测试用例的设计则是不全面的，无法保证测试质量，需要补充或者重新设计相应测试用例。
Ø用例执行率
用例执行率用于度量目前已执行用例数的百分比，即完执行测试用例的工作中完成了多少的工作量，项目经理和测试负责人可以通过这个数据清楚的知道测试执行工作完成的工作量及剩余工作量，具体算法如下：
用例执行率=已执行的用例数/测试用例总数*100%
测试用例执行率是衡量测试效率的因素，一般说来，在测试完成时测试用例的执行率也需要达到100%，也可能因为某些特殊原因导致测试中断而没有全部执行测试用例，可针对具体的情况进行分析。
Ø用例通过率
用例通过率是测试员执行完所有用例后，执行通过的用例数与执行用例总数的百分比，项目经理和测试负责人可以通过此数据评估项目当前版本的质量，对后面工作计划有针对性的做出改进。
用例通过率=执行通过用例数/执行用例总数*100%
测试用例通过率是衡量用例本身设计质量和被测软件质量的因素，对于未能成功执行的测试用例，要分析是用例设计错误还是被测软件错误，导致用例无法顺利执行。
Ø用例有效率
用例有效率是用来衡量测试用例的设计则是否全面的重要依据，若值=1，说明用例设计合理、全面，无遗漏；值大于1时，说明测试用例设计不全面，值越大说明测试用例设计中遗漏需求越多。
用例有效率=总缺陷数/（执行用例总数-执行通过用例数）
6测试用例维护
软件产品的版本是随着软件的升级儿不断变化的，而每一次版本的编号都会对测试用例产生影响，所以测试用例集也需要不断地变更和维护，使之与产品的编号报错一致。
以下原因可能导致测试用例变更：
Ø软件需求变更，软件需求变更可能导致软件功能的增加、删除、修改等变化，应遵循需求变更控制管理方法，同样变更的测试用例也需要执行变更管理流程。
Ø测试需求的遗漏和误解，由于测试需求分析不到位，可能导致测试需求遗漏或者误解，相应的测试用例也要进行变更。
Ø软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。
一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。
软件的版本升级更新，测试用例一般也应随之编制升级更新版本。
7测试用例与需求和缺陷
测试用例与项目需求和缺陷都有紧密的关系，测试用例就想纽带一样将需求和缺陷连接了起来，测试员虽然根据测试用例找出缺陷，但测试用例是完全遵循项目需求说明分析而来，因此需求是根本，测试用例是需求的另类体现。
在一个完整的测试体系中，项目需求、测试用例与缺陷是密切相关，不可分割的，没有了项目需求，测试用例和测试缺陷就没有了目的和方向，所以需求是前提，任何一个项目必须在需求的基础上才能成功的开发和测试；而测试用例则是测试的一种手段，为了更完善全面的测试工作儿执行的，是测试工作的核心，没有测试用例就没有测试指导，测试工作将会乱作一团，毫无条理，最终导致整个测试工作也毫无意义；缺陷或bug是在需求的前提下对已完成功能的验证，也是测试工作的目的——找出bug，如何执行即需要测试用例的支持，根据测试用例可以轻松的完成一轮测试，当然，前提是测试用例的设计足够全面和细化。
下面是功能测试流程图，从该图中能清楚的体现出测试用例、需求和缺陷之间的关系：
从上图中可以看出，用例、需求和缺陷是紧密相关的，测试用例需要随着需求的变更不断的完善，缺陷则是个不稳定值，不随前两者变化而变化，但谁也不能准确的知道到底有多少，只能根据测试结果得出一个相对值。
8测试用例管理工具
常见测试用例管理工具比较
序号
工具名
综述
优点
缺点
备注
1
TestManager
Rational测试解决方案中推荐的测试用例管理工具。
1.功能强大。
2.文件夹形式的管理，可以对测试用例无限分级。
3.可以和Rational的测试工具robot、functional相结合。
4.有测试用例执行的功能，但必须先生成对应的手工或自动化脚本。
1.本地化支持不好。
汉字显示太小。
2.测试用例很多时不太稳定。
有时会造成测试用例的丢失。
3.必须安装客户端才可使用。
和开发人员交流不方便。
4.测试用例的展示形式单一。
2
Wiki
使用wiki做测试用例的管理工具。
1.Web界面形式，交流方便。
2.测试用例的展示形式多样，可以贴图。
可以进行格式化的编辑。
3.Wiki提供测试用例的版本控制、版本比较功能。
4.Wiki提供测试用例的添加注释（评论）功能，方便测试用例评审。
5.Wiki本身强大的全文索引功能。
6.可以任意为测试用例添加标签。
1.Wiki并不是专业的测试用例管理工具。
2.无法和其他测试工具集成。
3.测试用例
升级会员 