软件测试 第2版 §18 编写和跟踪测试用例

编写和跟踪测试用例

      

本章重点:

·         编写和跟踪测试用例为什么重要

·         测试设计说明书是什么

·         测试用例说明书是什么

·         如何编写测试程序

·         如何组织测试用例

§18.1           测试用例计划的目标

有条不紊地仔细计划测试用例，事达成目标的必由之路。这样做的重要性如下：

组织：正确的计划会组织好测试用例。以便全体测试员和其他项目小组成员有效地审查和使用。

重复性：有一定的回归测试。

跟踪

测试证实：哪些测试过，哪些没有测试过。

 

有条不紊地仔细计划测试用例，是达成目标的必由之路。四个原因：

1）组织

即使在小型软件项目上，也可能有数千个测试用例。正确的计划会组织好用例，以便全体测试员和其它项目小组成员有效的审查和使用。

2）重复性

在项目期间有必要多次执行同样的测试，以寻找新的软件缺陷。

3）跟踪：用于统计等。

4）测试（或者不测试）证实

软件测试小组必须证明确实执行了计划执行的测试。

特别测试：有一种软件测试称为特别测试（ad hoc testing），描述在没有实际计划下执行测试——没有测试用例计划，有时甚至没有高级测试计划。特别测试就是测试员坐在软件前面开始乱敲键盘。

§18.2           测试用例计划综述

分为测试设计说明（test design specification）,测试用例说明（test case specification）和测试过程说明(test procedure specification). 具体信息可以参考：IEEE Std 829-1998。建议把它作为指南，但不是标准。

 

创建测试计划过程比结果文档更重要。三个等级：

1）测试设计说明（test design specification）

2）测试用例说明（test case specification）

3）测试过程说明（test procedure specification）

离最高级测试计划越远，侧重点就越倾向于产生的书面文档，而不是创建过程。

最低要求是测试小组应该创建包含IEEE829大纲中所述信息的测试计划。

要紧的是完成工作后满足了测试用例计划的四个目标：组织、重复性、跟踪和测试证实。

 

＊     测试设计

IEEE 829 称测试设计说明为“提炼测试方法〔在测试计划中定义〕，明确之处设计包含的特性及其相关测试。如果要求完成测试海明确之处测试用例和测试的程序，制定特性通过/失败的规则。 ”

目的：组织和面熟针对具体特性需要进行的测试。不包含具体的用例或者测试步骤。部分内容如下：

        标识符：用于引用和标记测试设计说明的唯一标识符。

        要测试的特性：测试设计说明所包含的软件特性描述。指出作为辅助特性需要间接测试的特性。还要列出不被测试的特性。比如一些东东是自动化模拟的。

        方法：描述测试软件特性的通用方法。

        测试用例确认：对用于检查特性的具体测试用例的高级描述和引用。应列出所选的等价类划分，并提供测试用例的引用信息以及用于执行测试用例的程序。例如：

       

Check the highest possible value

 Test Case ID# 15326

 

Check the lowest possible value

 Test Case ID# 15327

 

Check several interim powers of 2

 Test Case ID# 15328

        通过/失败规则：描述测试特性的通过和失败由什么构成。哪些可以接受，哪些不可以接受。崩溃就是失败。

 

 

 

＊     测试用例

IEEE 829 称测试用例说明为“编写用于输入的实际数值和与其输出结果数值。测试用例还明确指出使用具体测试用例产生的测试程序的任何限制。 ”

       测试用例细节基本上应该清楚地解释要想软件发送什么值或者条件，以及预期结果。它可以一个或多个测试用例说明来引用，也可以引用多个测试程序。重要信息如下：

 

1）标识符：由测试设计过程说明和测试程序说明引用的唯一标识符。

2）测试项：描述被测试的详细特性、代码模块等。

3）输入说明：列举送到软件执行测试用例的所有输入内容或者条件。

4）输出说明：描述进行测试用例预期的结果。

5）环境要求：指执行测试用例必要的硬件、软件、测试工具、实用工具、人员等。

6）特殊过程要求：描述执行测试必须做到的特殊要求。

7）用例之间的依赖性

表述测试用例的其它选择有简单列表、大纲甚至诸如状态表或数据流程图之类的图表。

 

      

 

公司的用例举例。可见公司的用例的在环境要求和用例依赖方面还不足。

Path	MD redundancy test case set->Kill Standby MD process
Headline:	Kill Standby MD process
Index Code:	02	Test Type:	ST	Version:	1
Case Priority:	high	Case Severity:	high	Estimated Effort:	null
Review Status:	none	Create Time:	2006-06-22 12:51:49.0	Creator:
Test Purpose:	To verify that Active MD can work normally when kill processes of standby MD
Test Step:	1. Telnet standby MD and kill all processes (include monitor,nms_monitor,media_director) 2. Telnet active MD and check whether processes run normally 3. Play VOD/liveTV from MC and check whether these programs can be played normally. 4.  Load some contents from MEloader and check from MD 5. Play programs just loaded from MC and check whether these programs can be played normally. 6. Repeat step 1-5 few time to check the result
Test Preset Condition:	1. All server work normally 2. User can play programs from MC normally
Expect Result:	Active MD can work normally when kill processes of standby MD
Test Result:	N/A
Remark	N/A

 

IEEE 829中的标准过于详细，可以挑重点来写，否则写case需要大量时间。甚至可以用excel表来写case。

 

＊     测试程序

IEEE 829 称测试程序为“明确指出为实现相关测试设计而操作软件系统和实验具体测试用例的全部步骤 ”。

1）标识符：把测试程序与相关测试用例和测试设计捆绑在一起的唯一标识符。

2）目的：程序的目的以及将要执行的测试用例的引用信息。

3）特殊要求：执行程序所需的其它程序、特殊测试技术或者特殊设备。

4）程序步骤：执行测试的详细步骤：

（1）日志：指出用什么方式、方法记录结果和现象；

（2）设置：说明如何准备测试；

（3）启动：说明用于启动测试的步骤；

（4）程序：描述用于运行测试的步骤；

（5）度量：描述如何判断结果；

（6）关闭：说明由于以外原因挂起测试的步骤；

（7）重启：告诉测试人员重启测试；

（8）终止：测试正常停止的步骤；

（9）重置：把环境恢复到测试前的状态；

（10）偶然事件：处理计划之外的情况。

通常不太可能需要按照最细致的程度编写测试用例。

诀窍是找出最合适的详细程度。

       教材中的计算器实例暂略。

 

 

§18.3           测试用例组织和跟踪

计划执行哪些测试用例？

计划执行多少测试用例？需要多少时间

能否挑出test suites测试某些特性或者软件部分

在执行测试用例时，能否记录哪一个通过，哪一个失败？

在失败的测试用例中，哪些在最近的一次执行也失败了

最近一次执行测试用例时通过的百分比时多少？

 

 

管理和跟踪系统的方法：

1）凭脑子记；

2）书面文档；

3）电子表格；

4）自定义数据库。

跟踪测试用例的理想方法是使用测试用例管理工具（test case management tool），一种为处理测试用例而专门编程设计的数据库。