测试用例设计_指南



Document number 文档编号	Confidentiality level 密级
VIT-SZP-Guide-TCD-01	内部公开
Document version 文档版本	Total 23 pages 共 23 页
V 2.00

Test Case Design Guide

测试用例设计指南

Prepared by 

拟制	杨涛	Date 日期	2010-04-02
Reviewed by  评审人	黄孙超，鲁明丽	Date 日期	2010-08-01
Approved by 批准	赵广谱	Date 日期	2010-11-16

Revision Record 修订记录

Date

日期	Revision Version 修订版本	Sec No. 修改章节	Change Description 修改描述	Author 作者
2010-4-2	V0.10	全部	创建	杨涛
2010-4-14	V0.20	全文	按评审意见修改	王斌
2010-4-19	V0.30	全文	按评审意见修改	王斌
2010-8-01	V0.40	全文	按评审意见修改	熊静
2010-8-13	V1.00	全文	版本发布	赵新蔚
2010-10-14	V1.10	全文	1、去掉敏捷字样，作为敏捷和V模型通用的指南 2、增加4.1 测试依据章节	冯伟敏
2010-11-16	V2.00	全文	版本发布	冯伟敏
2011-09-30	V2.10	全文	成都文思发布	罗丽莎

Contents 目录

 Table List 表目录

Figure List 图目录

1Purpose 目的

为确保文思创新软件技术有限公司（以下简称文思创新）在软件测试设计中的工作产品质量稳定，对测试用例设计指南进行规范化描述，特制定本文档。

2Scope 范围

本文档适用于文思创新所有的软件开发项目。文档读者为项目的测试人员以及参与测试活动的相关人员。

3Abbreviations and Acronyms 术语和缩略语

无

4Guide Description 指南描述

4.1测试依据

模型	测试类别	测试对象	测试依据
V模型	UT	代码	需求设计
	ST	组件	需求设计
	SDV	产品	FRS+技术规格
敏捷	UT	代码	设计书+user story简单设计
	SDV	产品	FRS+技术规格+user story

4.2测试用例粒度划分

一般而言，用户需求叶子节点与测试用例的对应关系为1:1。

4.3测试用例设计思路

4.3.1从软件开发的角度进行思考

4.3.1.1用户故事/技术规格

用户故事中指出用户要求制作一款软件的目的，从而分析出在这款软件中，用户想要什么样的功能，什么样的缺陷不能在软件中存在，什么样的缺陷是用户不能容忍的。软件开发过程中的用户故事编写阶段就是为了及时和用户沟通，避免设计中存在和用户需求不一致的情况发生，否则，即使设计的软件再完美，也不是用户需要的。

4.3.1.2软件特征

目前的软件系统和应用软件是比较复杂的，客户端／服务器、浏览器／服务器、数据通信、巨大的关系数据库技术的利用以及规模庞大，所有这一切都让系统/软件的复杂性提高，以至于没有一定基础的人是不可以全面地掌握它。系统/软件本身的复杂性和相互之间频繁的交互使软件的出错概率提高，也使测试的难度提高，给工程师的素质提出更高的要求。广阔的技术领域和熟练的基础知识是设计高质量测试案例的必备条件。

4.3.1.3编程错误

编程的错误是造成软件功能错误和性能不能满足需求的主要因素，另外，软件开发工具例如：类库、编译器、编辑工具等等，都会把本身的故障引入，从而导致更多故障的产生。和所有的人一样，程序员也会犯错误，而且对于自己的错误经常视而不见，因此要求软件测试工程师在测试设计的时候，多从编程的角度设计一些具有特殊场景（比如 逻辑方面等）的测试案例，来挖掘哪些存在于代码里面的隐性问题。

4.3.1.4需求变化

由于客户在前期定制需求时，因为考虑的不够全面，所以在项目中期会频繁出现需求变更的要求，再加上频繁变更的需求会导致项目延期、进度紧张、人员工作压力大、前期所做的工作需要全部返工、版本质量下降，缺陷率过高等风险问题的出现。所以当项目遇到需求变更时，项目经理需要及时做好变更需求的管理工作（比如  变更需求的分析、跟踪、确认）、风险的分析、工作量的重新评估、项目计划的重新调整、项目组内需求的告知等。

4.3.1.5人为因素

人们通常喜欢这样说：“没问题”、“太简单”、“修改老代码是不难的事” 、“我用很短的时间就能完成”，而不是说：“我们没有太多把握”、“新增加的工作很复杂，可能会出现无法预料的错误”、“我们不能估计修改旧代码是否能成功”、“我在实际工作之前，无法估计需要多长时间完成”。忠言虽然逆耳，但太多的“没问题”，必然会出问题。测试案例的设计多从细小、经常被大家“不放在眼里”的问题考虑，经常会发现意想不到的错误。

4.4测试用例设计方法

4.4.1功能测试用例的设计

4.4.1.1功能测试基本概念

功能测试主要针对技术规格/需设/US的测试，主要是验证功能是否符合需求，包括原定功能的检查、是否有冗余功能、遗漏功能；逻辑是否正确。

对测试对象的功能测试应侧重于所有可直接追踪到测试用例或业务功能和业务规则的用户故事测试点。这种测试的目标是核实数据的接收、处理和检索是否正确、完整，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

比如一个电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。

4.4.1.2有多级权限设置的功能测试

在很多系统中，都有多种用户权限，依据拥有不同的功能权限，针对此类功能如何进行测试，以下举例说明：

在某一个系统中，有这样的权限说明：

⏹用户A1、A2、A3：录入权限

⏹用户B1、B2、B3：普通管理权限

⏹用户C1、C2、C3：高级管理权限

系统功能：

⏹用户在进入系统中添加留言信息，提交给管理员回复审核。（未回复）

⏹普通管理员可以对留言进行回复，但是必须经过高级管理员审核才能最终回复。（回复提交）

⏹普通管理员可以对留言直接进行拒绝。（退回）

⏹高级管理员可以对留言回复进行授权发布。（已回复）

⏹高级管理员可以驳回留言回复。（回复驳回）

⏹用户A只能看到自己的留言信息。

⏹用户B可以看到所有用户A的留言信息。

⏹用户C可以看到所有用户B回复的信息。

设计测试用例：

按功能设计测试用例：

⏹添加留言信息：留言状态。

⏹留言回复：留言状态。

⏹留言拒绝：留言状态。

⏹留言回复授权：留言状态。

⏹留言回复驳回：留言状态。

按用户权限设计测试用例

⏹录入员添加新留言：可以正确添加新的留言。

⏹录入员查看新留言：可以查看哪些状态的留言。

⏹普通管理员回复、拒绝留言：普通管理员可以对哪些状态的留言进行查看并且能正确进行留言的回复或者拒绝操作。

⏹高级管理员授权、驳回留言回复：高级管理员可以对哪些状态的留言进行查看并且能正确进行留言的授权或者驳回操作。

4.4.1.3安装卸载的测试用例的设计

安装测试主要检查软件是否可以安装、卸载、安装文件的各项设置是否有效以及安装完后，是否能与系统兼容，能正常的使用。卸载是逆过程，测试是否删除干净，是否会影响影响程序的再安装等。

安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况下能进行安 装：例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况主要指磁盘空间不足、缺少目录创建权限等情况下进行安装失败后，能否进行重安装或者继续安装。第二个目的是验证软件在安装后可立即进行使用。这通常是为功能测试而制定的测试。安装测试包括测试安装代码以及安装手册。安装手册是用来指导用户正确进行软件的安装和卸载，安装代码提供安装一些程序能够运行的基础数据。

4.4.2功能测试方法的选择

功能测试法主要注重测试软件的功能需求，试图发现下列几类错误：

⏹功能不对或者遗漏

⏹界面错误

⏹数据结构或外埠数据库访问错误

⏹性能错误

⏹初始化和终止错误

具体的功能测试方法包括等价类划分、因果图、正交试验设计法、边界值分析、判定表驱动发等。

4.4.2.1等价类划分

等价类划分是一种典型的黑盒测试方法，用这一方法设计测试用例完全不考虑程序的内部结构，只根据对程序的要求和说明，即《需求规格说明书》。必须仔细分析和推敲说明书的各项需求，特别是功能需求。把说明中对输入的要求和输出的要求区别开来并加以分解。

等价类划分的办法是把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据当作测试用例。每一类的代表性数据在测试中的作用等价于这异类中的其它值，也就是说，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误；反之，如果某异类中的一个例子没有发现错误，则这一类中的其他例子也不会查出错误。

在考虑等价类划分时，先从程序的功能说明中找出各个输入条件，然后为每个输入条件划分两个或更多等价类。等价类可以分为两种情况：有效等价类和无效等价类。有效等价类是指对程序的规格说明是有意义的、合理的输入数据所构成的集合。无效等价类是指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。

⏹如果输入条件规定了取值的范围或值的个数，则可确定一个有效等价类和两个无效等价类。如数据值是从1到99，则可以划分一个合理等价类（大于1而小于99）和两个无效等价类（小于1的数，以及大于99的数）

⏹如果一个输入条件说明了一个“必须成立”的情况（如变量名必须以字母开头），可划分一个有效等价类（第一个字符是字母）和一个无效等价类（第一个字符不是字母）

⏹如果输入条件规定了输入数据的一组可能的值，而且程序是用不同的方式处理每种值，则可以为每一种值划分一个有效等价类，并划分一个无效等价类。

⏹如果我们确知，已划分的某等价类中的各元素在程序中的处理方式是不同的，则应据此将此等价类进一步划分成更小的等价类。

4.4.2.2边界值分析

边界值分析是一种补充等价划分的测试用例设计技术，他不是选择等价类的任何元素，而是选择等价类边界的测试用例。实践证明，在设计测试用例时，对半截附近的处理必须给予足够的重视，为检验边界附近的处理专门设计测试用例常常取得良好的效果。

⏹如果输入条件规定了取值范围，应以该范围的边界内及刚刚超过范围的边界外的值作为测试用例。如以a和b为边界，测试用例应当包含a和b、略大于a、略小于b的值。

⏹若规定了值的个数，分别以最大、最小个数及稍小于最小、稍大于最大个数作为测试用例。

⏹针对每个输出条件使用前面的第一和第二条原则

⏹如果程序规格说明书中提到的输入或输出域是个有序的集合、顺序文件、表格等就应该有意选取有序集的第一个和最后一个元素作为测试用例。

⏹分析规格说明，找出其他的可能边界条件。

4.4.2.3因果图

采用因果图方法的思路是，从用自然语言书写的程序规格说明书的描述中找出因（输入条件）果（输出或程序状态）的改变，通过因果图转换为判定表。

⏹分析程序规格说明的描述中，那些是原因，那些是结果，原因常常是输入条件或者输入条件的等价类。而结果是输出条件。

⏹分析程序规格说明的描述中语义的内容，并将其表示成连接各原因与各个结果的因果图。

⏹由于逾分或环境的，有些原因和结果的组合情况是不可能出现的，为表明这些特定的情况，在因果图上使用若干个特殊的标号标明约束条件。

⏹把因果图转换成判定表

⏹为判定表中每一列表示的情况设计测试用例。

以中国象棋中走马的测试用例设计为例

一、分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明）：

1.如果落点在棋盘外，则不移动棋子；

2.如果落点与起点不构成日字型，则不移动棋子；

3.如果落点处有自己方棋子，则不移动棋子；

4.如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；

5.如果不属于1-4条，且落点处无棋子，则移动棋子；

6.如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；

7.如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。

二、根据分析明确原因和结果

(一)原因：

1.落点在棋盘上；

2.落点与起点构成日字；

3.落点处为自己方棋子；

4.落点方向的邻近交叉点无棋子；

5.落点处无棋子；

6.落点处为对方棋子（非老将）；

7.落点处为对方老将。

(二)结果：

1.不移动棋子；

2.移动棋子；

3.移动棋子，并除去对方棋子；

4.移动棋子，并提示战胜对方，结束游戏。

添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表：

图1 因果图

考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7不能同时发生，所以对其施加异约束E。

三、根据因果图建立判定表：(分为两表)

		1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16
原因	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1
	2	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1
	3	0	0	0	0	1	1	1	1	0	0	0	0	1	1	1	1
	4	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1
结果	11	0	0	0	0	0	0	0	1	0	0	0	0	0	0	0	0
	21	1	1	1	1	1	1	1	0	1	1	1	1	1	1	1	1
测试用例

		1	2	3	4	5	6	7	8	9	`0	11	12	13	14	15	16
原因	11	0	1	0	1	0	1	0	1	0	1	0	1	0	1	0	1
	5	0	0	1	1	0	0	1	1	0	0	1	1	0	0	1	1
	6	0	0	0	0	1	1	1	1	0	0	0	0	1	1	1	1
	7	0	0	0	0	0	0	0	0	1	1	1	1	1	1	1	1
结果	22	0		0	1	0	0			0	0
	23	0		0	0	0	1			0	0
	24	0		0	0	0	0			0	1
测试用例

注：

1、以上判定表中由于表格大小没有列出最后所选的测试用例；

2、第2表中部分列被合并表示不可能发生的现象；

3、通过中间节点将测试用例的判定表简化为两个小表。减少工作量。

四、根据判定表，写测试用例表

4.4.3性能测试用例的设计

在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统 事务的响应时间、用户并发量以及系统的吞吐量。它和通常所说的强度、压力/负载测试有密切的关系。所以压力测试、负载测试以及稳定性测试作为性能测试的方法，被重点关注。

例子：针对一个网站进行测试，模拟10到50个用户进行数据的新增、更新、查询

压力测试：模拟10到50个用户进行数据的新增、更新、查询

负载测试：模拟50以上的用户进行数据的新增、更新、查询    

稳定性测试：就是模拟50个用户长时间交叉进行数据的新增、更新、查询操作，是否会引起系统发生内存泄露问题，以此来验证系统的可靠性和容错性。

性能测试主要测试软件的性能，包括压力测试、负载（强度）测试、稳定性测试。

4.4.4测试用例场景的设计

4.4.4.1测试用例场景设计基本概念

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

为什么场景法能如此清晰的描述整个事件？因为，现在的系统基本上都是由事件来触发控制流程的。如：我们申请一个项目，需先提交审批单据，再由部门经理审批，审核通过后由总经理来最终审批，如果部门经理审核不通过，就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。

下图中经过测试用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过测试用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止测试用例而不再重新加入某个流（备选流 2 和 4）。

图2 使用测试用例场景进行分析

在这个图中，有一个基本流和四个备选流。

每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景 1 基本流

场景 2 基本流 备选流 1

场景 3 基本流 备选流 1 备选流 2

场景 4 基本流 备选流 3

场景 5 基本流 备选流 3 备选流 1

场景 6 基本流 备选流 3 备选流 1 备选流 2

场景 7 基本流 备选流 4

场景 8 基本流 备选流 3 备选流 4

从上面的实例我们就可以了解场景是如何利用基本流和备用流来确定的。

基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）。

备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不再加入到基本流中。

下面是场景法的基本设计步骤

1.根据说明，描述出程序的基本流及各项备选流 

2.根据基本流和各项备选流生成不同的场景 

3.对每一个场景生成相应的测试用例 

4.对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一　个测试用例确定测试数据值

4.4.4.2测试用例场景设计实例

有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。

第一步我们来确定基本流和备选流：

第二步我们根据基本流和备选流来确定场景：

第三步我们来设计用例：

对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。

下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。

本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

第四步我们来设计数据，把数据填入上面的用例表中：

4.5测试用例的设计步骤

测试设计由设计规格说明书所驱动，测试用于验证模块单元实现了模块设计中定义的规格，一个完整的测试说明应该包含正面测试和负面测试。正面测试验证程序应该执行的工作，负面测试验证程序不应该执行的工作。

4.5.1使被测单元运行

任何测试都是在先保证系统能跑的起来下执行的，所以我们在设计测试用例的时候，首先会先验证功能是否实现，其次才看实现的功能是否与需求一致，确认软件至少能做什么？

这个阶段适合的技术有：对等区间划分、模块设计导出、冒烟测试、通过测试的测试。

4.5.2正面测试

正面测试主要根据需求，功能说明书，设计文档等相关参考文档来执行测试，测试系统是否完成了它应该完成的工作。形象一点，正面测试就像一个毕恭毕敬的小学生，老师叫我做什么，我就做什么。

适合的技术：

设计说明导出的测试，对等区间划分，状态转换测试。

4.5.3负面测试

负面测试主要是根据错误猜测，逆向思维来测试系统，一定程度上依赖测试人员的经验积累。形象一点说负面测试就像一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。

执行负面测试时，不单单要测试系统是否处理了用户的异常操作，还要检查系统对于这些异常操作是否给予了正确的错误提示。它是系统对用户进行继续正确操作的指引。

适合的技术：

错误猜测，边界值分析，内部边界值测试，状态转换测试。

4.5.4其它测试特性测试用例设计

如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。

在有安全保密需求的情况下，重视安全保密分析和验证是方便的，针对安全保密问题的测试用例应该在测试说明中进行标注。同时应该加入更多的测试用例测试所有的保密和安全冒险问题。

适合的技术：

设计说明导出的测试。

4.5.5覆盖率测试用例设计

应该或已有测试用例所达到的代码覆盖率。应该增加更多的测试用例到单元测试说明中以达到特定测试的覆盖率目标。一旦覆盖测试设计好，就可以构造测试过程和执行测试。覆盖率测试一般要求语句覆盖率、判断覆盖率。

适合的技术：

分支测试，条件测试，数据定义－使用测试，状态转换测试。

4.5.6测试执行

使用上述5个步骤设计的测试说明在大多数情况下可以实现一个比较完整的测试。到这一步，就可以使用测试说明构造实际的测试过程和用于执行测试的测试过程。该测试过程可能是特定测试工具的一个测试脚本。

测试过程的执行可以查出模块单元的错误，然后进行修复和重新测试。

5Reference Materials 参考文献

《测试流程管理》，(美) Black B.，北京大学出版社，2001

6Appendix 附录

6.1设计参考

6.1.1接口测试用例设计参考

表1 接口测试用例设计参考表

接口A的函数原型
输入/动作	期望的输出/相应	实际情况
典型值
边界值
异常值

6.1.2路径测试设计参考

表2 路径测试设计参考表

检查项	结论
数据类型问题 （１）变量的数据类型有错误吗？ （２）存在不同数据类型的赋值吗？ （３）存在不同数据类型的比较吗？
变量值问题 （１）变量的初始化或缺省值有错误吗？ （２）变量发生上溢或下溢吗？ （３）变量的精度不够吗？
逻辑判断问题 （１）由于精度原因导致比较无效吗？ （２）表达式中的优先级有误吗？ （３）逻辑判断结果颠倒吗？
循环问题 （１）循环终止条件不正确吗？ （２）无法正常终止（死循环）吗？ （３）错误地修改循环变量吗？ （４）存在误差累积吗？
内存问题 （１）内存没有被正确地初始化却被使用吗？ （２）内存被释放后却继续被使用吗？ （３）内存泄漏吗？ （４）内存越界吗？ （５）出现野指针吗？
文件I/O问题 （１）对不存在的或者错误的文件进行操作吗？ （２）文件以不正确的方式打开吗？ （３）文件结束判断不正确吗？ （４）没有正确地关闭文件吗？
错误处理问题 （１）忘记进行错误处理吗？ （２）错误处理程序块一直没有机会被运行？ （３）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。 （４）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。
…

6.1.3功能测试用例设计参考

表3 功能测试用例设计参考表

功能A描述
测试用例目的
前提条件
输入/动作		期望的输出/相应	实际情况
示例：典型值
示例：边界值
示例：异常值

6.1.4容错能力/回复能力测试用例设计参考

表4 容错能力/回复能力测试用例设计参考表

异常输入/动作	容错能力/恢复能力	造成的危害、损失
示例：错误的数据类型
示例：定义域外的值
示例：错误的操作顺序
示例：异常中断通信
示例：异常关闭某个功能
示例：负荷超出了极限

6.1.5性能测试用例设计参考

表5 性能测试用例设计参考表

性能A描述
测试用例目的
前提条件
输入数据		期望的性能（平均值）	实际性能（平均值）

6.1.6用户界面测试设计参考

表6 用户界面测试设计参考表

检查项	测试人员的类别及其评价
窗口切换、移动、改变大小时正常吗？
各种界面元素的文字正确吗？（如标题、提示等）
各种界面元素的状态正确吗？（如有效、无效、选中等状态）
各种界面元素支持键盘操作吗？
各种界面元素支持鼠标操作吗？
对话框中的缺省焦点正确吗？
数据项能正确回显吗？
对于常用的功能，用户能否不必阅读手册就能使用？
执行有风险的操作时，有“确认”、“放弃”等提示吗？
操作顺序合理吗？
有联机帮助吗？
各种界面元素的布局合理吗？美观吗？
各种界面元素的颜色协调吗？
各种界面元素的形状美观吗？
字体美观吗？
图标直观吗？

6.1.7信息安全测试设计参考

表7 信息安全测试设计参考表

假想目标A
前提条件
非法入侵手段		是否实现目标	代价－利益分析

6.1.8可靠性测试用例设计参考

表8 可靠性测试用例设计参考表

任务A描述
连续运行时间
故障发生的时刻	故障描述
统计分析
任务A无故障运行的平均时间间隔	（CPU小时）
任务A无故障运行的最小时间间隔	（CPU小时）
任务A无故障运行的最大时间间隔	（CPU小时）

6.1.9安装/反安装测试用例设计参考

表9 安装/反安装测试用例设计参考表

配置说明
安装选项	描述是否正常	使用难易程度
全部
部分
升级
其它
反安装选项	描述是否正常	使用难易程度