CMMI软件测试用例设计指南要点文档格式.docx
《CMMI软件测试用例设计指南要点文档格式.docx》由会员分享，可在线阅读，更多相关《CMMI软件测试用例设计指南要点文档格式.docx（14页珍藏版）》请在冰豆网上搜索。
3.2白盒测试方法8
3.2.1基本路径法8
3.2.2逻辑覆盖12
3.2.3程序插装12
4测试用例编写原则12
4.1全面性12
4.1.1数据库程序基本的增、删、改功能13
4.1.2对于无输入的操作13
4.1.3应考虑存在跨年、跨月的数据13
4.2正确性13
4.3符合正常业务惯例13
4.4仿真性14
4.5可操作性14
4.6可复用性14
1引言
1.1编写目的
设计好的测试用例是测试质量的关键。
本文档目的是指导开发人员、测试人员等在项目过程中设计测试用例所遵循的原则以及如何进行测试用例的设计，以有效、顺利地去实施、开展单元测试、集成测试、系统测试、性能（压力）测试、UAT测试等活动。
1.2适用范围
本文档适用于XX公司所有软件项目的测试工作。
1.3预期读者
测试经理、测试工程师、质量经理、质量工程师、开发工程师、业务测试人员等。
1.4参考文档
《软件测试规范实施指南》
1.5相关模版
无
2测试用例概述
软件测试发展到今天，测试工作已从简单的测试演变为包括：
编制测试计划、编写测试用例、准备测试数据、编写测试脚本、实施测试、测试评估等多项内容的正规测试。
测试方式也由单纯的手工测试发展为手工、自动化兼之。
测试用例设计的好坏将直接影响到软件产品的质量。
2.1测试用例是什么
测试用例也叫测试案例（Testcase），也就是说为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据。
比较通常的说法是：
指对软件产品一项特定的业务功能进行测试任务的描述，体现测试方案、方法、技术和策略，其内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
测试用例的管理是通过QC集中管理，分布实施。
我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试，一个好的测试用例是在于它能发现至今未发现的错误。
2.2测试用例的重要性
软件测试的重要性是毋庸置疑的。
但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的产品质量，则是每个公司探索和追求的目标。
每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法，而测试用例的设计一直是软件测试工作的重点和难点。
测试用例之所以很重要，原因有以下几方面。
⏹测试用例构成了设计和制定测试过程的基础。
在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率，令软件测试的实施重点突出、目的明确。
⏹测试的“深度”与测试用例的数量成比例。
由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。
⏹判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施或执行的测试用例的数量为依据的。
类似下面这样的说明：
“95%的关键测试用例已得以执行和验证”，远比“我们已完成95%的测试”更有意义。
⏹测试工作量与测试用例的数量成比例。
根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
⏹在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
⏹在发生人员变更的情况下，有了测试用例及自动化测试，无论是谁来执行，参照测试用例及测试脚本实施，都能保障测试的质量，可以把人为因素的影响减少到最小。
2.3测试用例设计基本步骤
测试用例设计步骤基本包括如下几个方面：
各类技术文档作为测试用例设计的依据；
分析被测对象的规格；
分析测试要素；
分析测试要素取值；
构建初始测试用例；
通过评审或其他方式确认测试用例；
在测试实现和执行的过程中修正测试用例。
具体流程如下所示：
3测试用例设计方法
3.1黑盒测试方法
黑盒测试是从用户观点出发的测试，它又称功能测试、数据驱动测试或基于规格说明书或用户手册的测试。
它所依据的是程序的外部特性。
黑盒测试是目前业界最流行的测试方法，
黑盒测试方法主要包括等价类划分法、边界值分析法、错误猜测法、因果图方法、判定表驱动分析方法等。
这里主要介绍一下常用的等价类划分法、边界值分析法和错误猜测法。
3.1.1等价类划分法
3.1.1.1划分等价类
等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。
每一类的代表性数据在测试中的作用等价于这一类中的其他值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能出现同样的错误。
使用这一方法设计测试用例，首先必须在认真分析需求规格说明书的基础上划分等价类，列出等价类表。
等价类也指一组输入条件的有效和无效状态，分为有效等价类和无效等价类；
有效等价类是指对程序的需求规格说明是有意义的、合理的输入数据所构成的集合；
无效等价类是指对产品的需求规格说明书是不合理的或无意义的输入数据所构成的集合。
每类中的一个典型值在测试中的作用与这一类中所有其它值的作用相同，可以从每个等价类中只取一组数据作为测试数据。
一些划分等价类的指导原则如下：
1、如果规定了输入值的范围且输入值为数值型，则可划分出一个有效的等价类（输入值在此范围内）、两个无效等价类（输入小于最小值或大于最大值）；
2、如果规定了输入数据的个数，则类似地也可以划分出一个有效的等价类和两个无效的等价类（如分别以最大、最小个数和稍小于最小、稍大于最大个数作为测试用例）；
3、在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类；
4、如果规定输入数据为一组确定的值，而且程序对不同输入值做不同处理，则每个允许的输入值是一个有效的等价类，此外还有一个无效的等价类（即任何一个不允许输入的值）；
5、如果规定了输入数据必须遵循的规则，则可以划分出一个遵循规则的有效等价类和若干个不遵循规则的无效等价类；
6、如果规定了输入数据为整型，则可以划分出正整数、零和负整数等三类等价类；
7、在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类；
8、等价类划分时应充分考虑边界条件、次边界条件、空值和无效数据。
项目中实际操作时，首先我们要对一个功能点的所有输入项进行分析，根据控制条件和结果筛选出对执行结果有影响的输入项（一般只考虑对本功能点结果有影响）。
对于每个输入项的类型一般有两种：
一般输入项和下拉选择项，我们根据以上指导原则就可以对这些输入项进行等价类划分。
3.1.1.2生成测试要素取值列表
按照测试要素顺序把对应的等价类填入测试要素取值列表，每个取值对应一个等价类。
列表模板如下所示：
功能点名称：
XXX
功能点编号：
XXXXXX
前置条件:
XXXXXX
优先级：
高/中/低
注：
XXXXXX
序号
要素名
L1
L2
L3
1
要素1
值1
值2
值3
2
要素2
3
要素3
3.1.1.3形成测试要素矩阵，设计测试用例
完成测试要素取值列表后，我们就可以根据以下原则生成测试要素分析矩阵。
通过设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；
通过设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。
测试要素分析矩阵的模板如下：
4
这里每个要素的取值仍是等价类，把每个等价类取值明确后，再添加上没有考虑进来的测试要素的取值后，表中的每一行就自然地转换成了一个测试用例。
3.1.1.4举例：
柜员登陆
输入项：
机构名（不输默认为总行），柜员（分为经办和复核），用户名，密码（6位）；
首先对以上四个输入项进行划分等价类，列表如下：
机构名
存在
空
不存在
柜员
经办
复核
用户名
密码
等于6位
小于6位
大于6位
由以上列表可看出：
共有6个有效等价类和4个无效等价类。
根据正交矩阵编写原则，可用2个测试例覆盖6个有效等价类，4个测试例覆盖4个无效等价类，只需6个测试例就覆盖了所有的测试条件。
具体矩阵如下表：
机构号
5
--
6
3.1.2边界值分析法
边界值分析方法是对等价类划分方法的补充。
3.1.2.1边界值分析方法的考虑
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
3.1.2.2基于边界值分析方法选择测试用例的原则
1、如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
例如，输入值的范围是-1.0～1.0，则可选取-1.0、1.0、-1.001和1.001作为输入数据。
2、如果输入条件规定了值的个数，则用最大个数,最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
例如，某个文件有1～255个记录，则可选取1个记录、255个记录、0个记录和256个记录的输入文件作为输入数据。
3、根据规格说明的每个输出条件，使用前面的原则1。
4、根据规格说明的每个输出条件，应用前面的原则2。
5、如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6、如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
例如，在程序中定义的数组下界为0，上界为100，则应选取0和100作为测试用例。
7、分析规格说明，找出其它可能的边界条件。
3.1.3错误推测法
错误推测法是一种基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。
错误推测方法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。
例如，在单元测试时曾列出的许多在模块中常见的错误。
以前产品测试中曾经发现的错误等，这些就是经验的总结。
还有，输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行。
这些都是容易发生错误的情况。
可选择这些情况下的例子作为测试用例。
3.1.4组合分析法
组合分析法是一种基于每对参数组合的测试技术，考虑参数之间的影响是主要的错误来源，并且大多数的错误起源于简单的参数组合。
组合分析法的优点是低成本实现，低成本维护，易于自动化，易于用较少的测试案例发现更多的错误和用户可以自定义限制；
缺点是需要专家领域知识，不能测试所有可能的组合，不能测试复杂的交互。
3.2白盒测试方法
白盒测试又称结构测试、逻辑驱动测试或基于程序的测试，一般多发生在单元测试阶段。
白盒测试方法主要包括逻辑覆盖法，基本路径法，程序插装等。
这里重点介绍一下常用的基本路径法，对于逻辑覆盖简单介绍一下覆盖准则。
3.2.1基本路径法
在程序控制流图的基础上,通过分析控制构造的环路复杂性，导出独立路径集合，从而设计测试用例，设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。
在介绍基本路径测试方法（又称独立路径测试）之前，先介绍流图符号：
图1
如图1所示，每一个圆，称为流图的节点，代表一个或多个语句，流程图中的处理方框序列和菱形决策框可映射为一个节点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头。
一条边必须终止于一个节点，即使该节点并不代表任何语句，例如，图2中两个处理方框交汇处是一个节点，边和节点限定的范围称为区域。
图2
任何过程设计表示法都可被翻译成流图，下面显示了一段流程图以及相应的流图。
注意，程序设计中遇到复合条件时（逻辑or,and,nor等），生成的流图变得更为复杂，如（c）流图所示。
此时必须为语句IFaORb中的每一个a和b创建一个独立的节点。
（c）流图
独立路径是指程序中至少引进一个新的处理语句集合，采用流图的术语，即独立路径必须至少包含一条在定义路径之前不曾用到的边。
例如图（b）中所示流图的一个独立路径集合为：
路径1：
1-11
路径2：
1-2-3-4-5-10-1-11
路径3：
1-2-3-6-8-9-10-1-11
路径4：
1-2-3-6-7-9-10-1-11
上面定义的路径1，2，3和4包含了（b）流图的一个基本集，如果能将测试设计为强迫运行这些路径，那么程序中的每一条语句将至少被执行一次，每一个条件执行时都将分别取true和false（分支覆盖）。
应该注意到基本集并不唯一，实际上，给定的过程设计可派生出任意数量的不同基本集。
如何才能知道需要寻找多少条路径呢？
可以通过如下三种方法之一来计算独立路径的上界：
1.V=E-N+2，E是流图中边的数量，N是流图节点数量。
2.V=P+1，P是流图中判定节点的数量
3.V=R，R是流图中区域的数量
例如，（b）流图可以采用上述任意一种算法来计算独立路径的数量
1.V=11条边-9个节点+2=4
2.V=3个判定节点+1=4
3.流图有4个区域，所以V=4
由此为了覆盖所有程序语句，必须设计至少4个测试用例使程序运行于这4条路径。
在采用基本路径测试方法中，获取测试用例可参考以下方式：
⏹通过非路径分析得到的测试用例；
⏹找到尚未测试过的路径并生成相应的测试用例；
⏹指定特定路径生成相应的测试用例。
⏹对程序中的循环作了执行了零次和一次的限制，这样程序路径的数目就是有限的。
⏹如果程序的数目有限，就可采用枚举法得到所有的路径。
⏹完成若干测试用例后，就可以知道所测路径是哪些，尚有哪些待测路径。
⏹在指出要测试的路径以后，可以自动生成相应的测试用例。
3.2.2逻辑覆盖
⏹语句覆盖：
在测试时，设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少执行一次。
⏹分支覆盖：
在测试时，设计若干测试用例，运行被测程序，使程序中的每个判断真假的分支至少遍历一次。
⏹条件覆盖：
在测试时，设计若干测试用例，运行被测程序，使程序中的每个条件的可能取值至少满足一次。
⏹条件分支覆盖：
在测试时，设计足够的测试用例，使得判断中每个条件的所有可能取值至少出现一次，并且每个判断本身的判定结果也至少出现一次。
3.2.3程序插装
程序插装是一种基本的测试手段。
它是在程序特定部位插入“探针”，以便把程序执行过程中发生的一些重要历史事件记录下来（如语句执行次数、某些变量值的变化情况等），只有借助于插装技术，才能了解程序执行时的语句覆盖、分支覆盖及路径覆盖等结构覆盖情况。
在被测程序中插入的操作（语句）称为“探测器”或“探针”。
4测试用例编写原则
4.1全面性
指编写的测试用例应该覆盖所依据设计文档描述的功能。
4.1.1数据库程序基本的增、删、改功能
增、改测试用例重点在于数据合法性、正确性的检验和提示信息的正确性的检验.输入的数据可能有无限种组合，此时可以采用等价类划分和边界值法。
删除的测试用例比较简单，只有操作没有数据的输入，但是应该在备注中注明，删除的限制条件，以及数据库中应该删除的表的情况。
有条件限制时，测试用例应该包含各种删除条件，必要时在添加或修改的测试用例后面或中间，紧跟删除的测试用例。
4.1.2对于无输入的操作
例如：
选择商品，可以通过多种途径进行，此时应具体描述程序从何处进入，通过何种操作，达到商品界面。
对于报表的测试用例，最好紧跟在输入数据的后面，并且应该给出报表输出的数据的界面图（含数据）。
对于不便书写测试用例的情况，应该在备注中说明，并写出可能的操作步骤，例如：
对于文件夹的拖动，说明左右拖还是上下拖，结果如何就可以了。
4.1.3应考虑存在跨年、跨月的数据
对于测试用例中涉及到需要数据准备的，应考虑系统对于跨年及跨月数据的处理。
4.2正确性
包括数据的正确性和操作的正确性。
首先保证测试用例的数据正确，其次预期的输出结果应该与测试数据发生的业务吻合。
操作的预期结果应该与程序发生的结果吻合。
4.3符合正常业务惯例
测试数据应符合用户实际工作业务流程。
实际就是测试用例的先后顺序，先新增，后修改或删除，不能将删除放在第一位。
4.4仿真性
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；
不应该随意填充任意字符等情况。
4.5可操作性
测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果不同。
达到的目的是，任何人，均可以根据测试用例，单独进行测试。
4.6可复用性
测试用例的层次性还表现在：
低层被测对象的测试用例或其部分内容可以复用在对高层被测对象的测试中。
如：
⏹单元测试阶段的功能确认类测试用例组可以复用在部件集成测试阶段中；
⏹部件确认测试阶段的测试用例组可以复用在配置项组装测试阶段和配置项确认测试阶段中；
⏹配置项确认测试阶段的测试用例组可以复用在系统测试阶段和系统验收测试中。
当然，每个测试阶段的对象和目标都不同，因此测试用例或其部分内容的复用通常有选择的、有限的和需更改的。
升级会员 