测试要点和测试用例说明
-
1.
测试
CASE
的
理解
1.1.
事前条件
1.1.1.
事前条件的含
义
事前条件是测试式样书中每一条
CASE
的公共入口。
1.1.2.
事前条件的书写方法（建议）
在编写
事前条件时，如果需要进行多个动作，不要书写成
(
首先。
。
。
，然后。
。<
/p>
。
，最后。
。
。
)
，尽
量把所有动作按序号编排，这样
清晰明了，同样也美观。
例如：
1.2.
CASE
具有的特性
1.2.1.
完整性
每一条
CASE
应该是完整的、可操作的。
1.2.2.
独立性
CASE
与
CASE
之前没有依赖关系，每一条
CASE
都是独立的、可操作的。一条
CASE
的
成功与失败不应该影响另一条
CASE
的成功与失败
。
2.
测试观点的书写
2.1.
测试观
点很
简单
，不分
场
合
。
一句话就可以说明测试观点，不分场合，没有条件限制。
例如：
2.2.
测试观
点
< br>复杂
，
分场
合
< br>分别测试
。
例如：
上
图中要进行条件检索测试，但是条件检索检索出来的数据条数存在多种情况，所以要分别
测试到位，假如存在多个检索条件，检索条件之间是
OR
或
AND
的关系，还要进行相应的测
试，每个
检索条件还要进行特殊字符或乱码的测试，这些说明都应在测试观点的详细中写清
楚，这
样让测试人员在每条
CASE
的测试开始时就知道这条
CASE
测的是什么，不要等到测
试到最后看到
期待结果才知道测的是什么。
对测试观点的说明比较复杂时，
也要在详细中将数条说明按序号排列说明。如下图：
3.
CASE
中
[
操作
]
的书写
3.1.
基本原则
3.2.
操作中包含多个动作的情况
操作中包含多个动作的情况下还会有两种情况：
只有最后一个动作才会有需要测试确认的期待结果
此时，除了最后一个动作以外的所有的动作都是准备动作。如下图：
不仅仅是最后一个动作才有需要测试确认的期待结果
如下图：
4.
期待结果的书写
4.1.
基本原则
不要将几个确认结果写在一个
Excel
的单元格中，
下面分析两种写法。
比较粗糙的写法
比较细致的写法
一、目的与适用范围
1
、目的
软
件测试是软件工程的重要组成部分，测试工作的质量直接影响软件产品的生命力。测试工
作的标准化是软件质量保证
(Quality
Assuran
ce)
重要而且必须的环节。制定本标准的目的在
于使测试流程
更标准，测试过程更规范。从而使整个软件生产纳入更系统化、更专业化的轨
道。
2
、适用范围
<
/p>
本标准适用于软件测试流程的管理和测试的具体操作过程。本标准的使用者可以是企业内部
的测试人员和开发人员。
二、测试方法
软件测试的方法和技术
是多种多样的。以下将介绍比较常用的一些测试方法：
1
、静态测试
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的文法、结构、过程、接口等
来检查程序的正确性。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹
< br>配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用
和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
2
、动态测试
动态方法是指通过运行被测程序，检查运行结果与预期结果的
差异，并分析运行效率和健
壮性等性能，这种方法由三部分组成：构造测试实例、执行程
序、分析程序的输出结果。
3
、黑盒测试
黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测
每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑
< br>程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按
照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，
并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分
析、因
—
果图、错误推测等，主要用于软件确认
测试。
“
黑盒
”
法着眼于程序外部结构、
不考虑内部逻辑结构、
针对软件界面和软件功能进行测试。
“
黑
盒
”
法是穷举输入测试，只有把所有可能的输入
都作为测试情况使用，才能以这种方法查出程
序中所有的错误。实际上测试情况有无穷多
个，人们不仅要测试所有合法的输入，而且还要
对那些不合法但是可能的输入进行测试。
4
、白盒测试
白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产
品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序
< br>中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻
辑驱动、基路测试等，主要用于软件验证。
“
白盒
”
法全面了解程序内部逻辑结构、对所有
逻辑路径进行测试。
“
白盒
”
法是穷举路径测试。
在使用这一方案时，测试者必须检查程序的内部结构
，从检查程序的逻辑着手，得出测试数
据。贯穿程序的独立路径数是天文数字。但即使每
条路径都测试了仍然可能有错误。第一，
穷举路径测试决不能查出程序违反了设计规范，
即程序本身是个错误的程序。第二，穷举路
径测试不可能查出程序中因遗漏路径而出错。
第三，穷举路径测试可能发现不了一些与数据
相关的错误。
5
、
ALAC(Act-like-
a-customer)
测试
ALA
C
测试是一种基于客户使用产品的知识开发出来的测试方法。
A
LAC
测试是基于复杂的
软件产品有许多错误的原则。最大的受
益者是用户，缺陷查找和改正将针对哪些客户最容易
遇到的错误。
6
、单元测试方法
6.1
单元测试任务
单元测试任务包括：
u
模块接口测试；
u
模块局部数据结构测试；
u
模块边界条件测试；
u
模块中所有独立执行通路测试；
u
模块的各条错误处理通路测试。
模块
接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才
有
意义。
6.2
接口测试
测试接口正确与否应该考虑下列因素：
u
输入的实际参数与形式参数的个数是否相同；
u
输入的实际参数与形式参数的属性是否匹配；
u
输入的实际参数与形式参数的量纲是否一致；
u
调用其他模块时所给实际参数的个数是否与被调模块的形参
个数相同；
u
调用其他模块时所给
实际参数的属性是否与被调模块的形参属性匹配；
u
调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
u
调用预定义函数时所用参数的个数、属性和次序是否正确；
u
是否存在与当前入口点无关的参数引用；
u
是否修改了只读型参数；
u
对全程变量的定义各模块是否一致；
u
是否把某些约束作为参数传递。
如果模块内包括外部输入输出，还应该考虑下列因素：
u
文件属性是否正确；
u
OPEN/CLOSE
语句是否正确；
u
格式说明与输入输出语句是否匹配；
u
缓冲区大小与记录长度是否匹配；
u
文件使用前是否已经打开；
u
是否处理了文件尾；
u
是否处理了输入
/
输出错误；
u
输出信息中是否有文字性错误；
6.3
数据测试
检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部
< br>数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
u
不合适或不相容的类型说明；
u
变量无初值；
u
变量初始化或省缺值有错；
u
不正确的变量名（拼错或不正确地截断）
< br>；
u
出现上溢、下溢和地址异常。
除了局
部数据结构外，如果可能，单元测试时还应该查清全局数据（例如
FORTRAN
的公用
区）对模块的影响。
6.4
控制流测试
< br>在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至
少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造
成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误
包括：
u
误解或用错了算符优先级；
u
混合类型运算；
u
变量初值错；
u
精度不够；
u
表达式符号错。
比较判断与控制流常
常紧密相关，测试用例还应致力于发现下列错误：
u
不同数据类型的对象之间进行比较；
u
错误地使用逻辑运算符或优先级；
u
因计算机表示的局限性，期望理论上相等而实际上不相等的
两个量相等；
u
比较运算或变量出错；
u
循环终止条件或不可能出现；
u
迭代发散时不能退出；
u
错误地修改了循环变量。
6.5
出错处理测试
一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认
真测试，测试应着重检查下列问题：
u
输出的出错信息难以理解；
u
记录的错误与实际遇到的错误不相符；
u
在程序自定义的出错处理段运行之前，系统已介入；
u
异常处理不当；
u
错误陈述中未能提供足够的定位出错信息。
6.6
边界条件测试
边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失
效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。
7
、集成测试的基本方法
某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非
增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和
纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定
出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步<
/p>
一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集
成方法。
7.1
自顶向下集成
自顶向下集成是构造程
序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次
结构，以深度优先或
广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把
主控制路径上的模
块集成在一起，
至于选择哪一条路径作为主控制路径，
这多少带
有随意性，
一般根据问题的特性确定。
自顶向下集成测试的具体步骤为：
u
以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模
块替代；
u
依据所选的集成策略（深度优先或广度优先）
，每次只替代一个桩模块；
u
每集成一个模块立即测试一遍；
u
只有每组测试完成后，才着手替换下一个桩模块；
u
为避免引入新错误，须不断地进行回归测试（即全部或部分
地重复已做过的测试）
；
u
从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。
<
/p>
自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现
错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要
数
据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是
把某
些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模
块；第
三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于
定位和纠
正，
并且失去了在组装模块时进行一些特定测试的可能
性；第二种方法无疑要大大增加开销；
第三种方法比较切实可行。
7.2
自底向上集成
自底向上测试是从
“
原子
”
模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模
< br>块时，所需的下层模块功能均已具备，所以不再需要桩模块。
自底向上综合测试的步骤分为：
u
把低层模块组织成实现某个子功能的模块群（
cluster<
/p>
）
;
u
开发
一个测试驱动模块，控制测试数据的输入和测试结果的输出；
u
对每个模块群进行测试；
u
删除测试使用的驱动模块，用较高层模块把模块群组织成为
完成更大功能的新模块群；
u
从第一步开始循环执行上述各步骤，直至整个程序构造完毕。
自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块
加
入时才具有整体形象。
它与自顶向综合测试方法优缺点正好相
反。
因此，
在测试软件系统时，
应根据
软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，
上层
模块用自顶向下的方法，下层模块用自底向上的方法。
此外，
在集成测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①
对应
几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应
尽
早测试，并反复进行回归测试。
8
、确认测试的基本方法
8.1
确认测试标准
实现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应
规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是
否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，
文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力
和可维护性等）是否令用户满意。
确认测试
的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接
受；另
一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现