一、方法简介

　　利用因果图来设计测试用例时， 作为输入条件的原因与输出结果之间的因果关系，有时很难从软件需求规格说明中得到。往往因果关系非常庞大，以至于据此因果图而得到的测试用例数目多的惊人，给软件测试带来沉重的负担，为了有效地，合理地减少测试的工时与费用，可利用正交实验设计方法进行测试用例的设计。

　　正交实验设计方法:依据Galois理论，从大量的（实验）数据（测试例）中挑选适量的，有代表性的点（例），从而合理地安排实验（测试）的一种科学实验设计方法。类似的方法有:聚类分析方法，因子方法方法等。

　　利用正交实验设计测试用例的步骤：

　　1.提取功能说明，构造因子--状态表

　　把影响实验指标的条件称为因子。而影响实验因子的条件叫因子的状态。利用正交实验设计方法来设计测试用例时，首先要根据被测试软件的规格说明书找出影响其功能实现的操作对象和外部因素，把他们当作因子，而把各个因子的取值当作状态。对软件需求规格说明中的功能要求进行划分，把整体的概要性的功能要求进行层层分解与展开，分解成具体的有相对独立性的基本的功能要求。这样就可以把被测试软件中所有的因子都确定下来，并为确定个因子的权值提供参考的依据。确定因子与状态是设计测试用例的关键。因此要求尽可能全面的正确的确定取值，以确保测试用例的设计作到完整与有效。

　　2.加权筛选，生成因素分析表

　　对因子与状态的选择可按其重要程度分别加权。可根据各个因子及状态的作用大小，出现频率的大小以及测试的需要，确定权值的大小。

　　3.利用正交表构造测试数据集

　　正交表的推导依据Galois理论（这里省略，需要时可查数理统计方面的教材）。

　　利用正交实验设计方法设计测试用例，比使用等价类划分，边界值分析，因果图等方法有以下优点:节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率。

　　二、 实战演习

　　暂无

一、方法简介

　　一个程序的功能说明通常由动态说明和静态说明组成。动态说明描述了输入数据的次序或转移的次序。静态说明描述了输入条件与输出条件之间的对应关系。对于较复杂的程序，由于存在大量的组合情况，因此，仅用静态说明组成的规格说明对于测试来说往往是不够的。必须用动态说明来补充功能说明。功能图方法是用功能图FD 形式化地表示程序的功能说明，并机械地生成功能图的测试用例。 功能图模型由状态迁移图和逻辑功能模型构成。状态迁移图用于表示输入数据序列以及相应的输出数据。在状态迁移图中，由输入数据和当前状态决定输出数据和后续状态。逻辑功能模型用于表示在状态中输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。测试用例则是由测试中经过的一系列状态和在每个状态中必须依靠输入/输出数据满足的一对条件组成。功能图方法其实是是一种黑盒白盒混合用例设计方法。

　　（功能图方法中，要用到逻辑覆盖和路径测试的概念和方法，其属白盒测试方法中的内容。逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计方法。该方法要求测试人员对程序的逻辑结构有清楚的了解。由于覆盖测试的目标不同，逻辑覆盖可分为:语句覆盖，判定覆盖，判定-条件覆盖，条件组合覆盖及路径覆盖。下面我们指的逻辑覆盖和路径是功能或系统水平上的，以区别与白盒测试中的程序内部的。）

　　1、功能图

　　功能图由状态迁移图和布尔函数组成。状态迁移图用状态和迁移来描述。一个状态指出数据输入的位置（或时间），而迁移则指明状态的改变。同时要依靠判定表或因果图表示的逻辑功能。例，一个简化的自动出纳机ATM的功能图。

　　2、测试用例生成方法

　　从功能图生成测试用例，得到的测试用例数是可接受的。 问题的关键的是如何从状态迁移图中选取测试用例。 若用节点代替状态，用弧线代替迁移，则状态迁移图就可转化成一个程序的控制流程图形式。问题就转化为程序的路径测试问题（如白盒测试）问题了。

　　3、测试用例生成规则

　　为了把状态迁移（测试路径）的测试用例与逻辑模型（局部测试用例）的测试用例组合起来，从功能图生成实用的测试用例，须定义下面的规则。在一个结构化的状态迁移（SST）中，定义三种形式的循环:顺序，选择和重复。但分辨一个状态迁移中的所有循环是有困难的。（其表示图形省略）。

　　4、从功能图生成测试用例的过程

　　1)生成局部测试用例:在每个状态中，从因果图生成局部测试用例。局部测试用例由原因值（输入数据）组合与对应的结果值（输出数据或状态）构成。

　　2)测试路径生成:利用上面的规则（三种）生成从初始状态到最后状态的测试路径。

　　3)测试用例合成:合成测试路径与功能图中每个状态中的局部测试用例。结果是初始状态到最后状态的一个状态序列，以及每个状态中输入数据与对应输出数据的组合。

　　5、测试用例的合成算法:采用条件构造树。

　　二、实战演习

　　暂无

一.方法简介

　　1. 定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

　　2. 与等价划分的区别

　　1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

　　2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

　　3. 边界值分析方法的考虑：

　　长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

　　使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

　　4. 常见的边界值

　　1) 对16-bit 的整数而言 32767 和 -32768 是边界

　　2) 屏幕上光标在最左上、最右下位置

　　3) 报表的第一行和最后一行

　　4) 数组元素的第一个和最后一个

　　5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次

　　5. 边界值分析

　　1) 边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。

　　例：测试计算平方根的函数

　　--输入：实数

　　--输出：实数

　　--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息"平方根非法-输入值小于0"并返回0；库函数Print-Line可以用来输出错误信息。

　　2) 等价类划分：

　　I.可以考虑作出如下划分：

　　a、输入 (i)<0 和 (ii)>=0

　　b、输出 (a)>=0 和 (b) Error

　　II.测试用例有两个：

　　a、输入4，输出2。对应于 (ii) 和 (a) 。

　　b、输入-10，输出0和错误提示。对应于 (i) 和 (b) 。

　　3) 边界值分析：

　　划分(ii)的边界为0和最大正实数；划分(i)的边界为最小负实数和0。由此得到以下测试用例：

　　a、输入 {最小负实数}

　　b、输入 {绝对值很小的负数}

　　c、输入 0

　　d、输入 {绝对值很小的正数}

　　e、输入 {最大正实数}

　　4) 通常情况下，软件测试所包含的边界检验有几种类型：数字、字符、位置、重量、大小、速度、方位、尺寸、空间等。

　　5) 相应地，以上类型的边界值应该在：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、 最短/最长、 空/满等情况下。

　　6) 利用边界值作为测试数据

项	边界值	测试用例的设计思路
字符	起始-1个字符/结束+1个字符	假设一个文本输入区域允许输入1个到255个 字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。
数值	最小值-1/最大值+1	假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的 数值来作为边界条件。
空间	小于空余空间一点/大于满空间一点	例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。

7) 内部边界值分析：

　　在多数情况下，边界值条件是基于应用程序的功能设计而需要考虑的因素，可以从软件的规格说明或常识中得到，也是最终用户可以很容易发现问题的。然而，在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

　　内部边界值条件主要有下面几种：

　　a) 数值的边界值检验：计算机是基于二进制进行工作的，因此，软件的任何数值运算都有一定的范围限制。

项	范围或值
位（bit）	0 或 1
字节（byte）	0 ~ 255
字（word）	0~65535（单字）或 0~4294967295（双字）
千（K）	1024
兆（M）	1048576
吉（G）	1073741824

　　 b) 字符的边界值检验：在计算机软件中，字符也是很重要的表示元素，其中ASCII和Unicode是常见的编码方式。下表中列出了一些常用字符对应的ASCII码值。

字符	ASCII码值	字符	ASCII码值
空 (null)	0	A	65
空格 (space)	32	a	97
斜杠 ( / )	47	Z	90
0	48	z	122
冒号 ( : )	58	单引号 ( ‘ )	96
@	64

　　c) 其它边界值检验

　　6. 基于边界值分析方法选择测试用例的原则

　　1) 如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

　　例如，如果程序的规格说明中规定："重量在10公斤至50公斤范围内的邮件，其邮费计算公式为……"。作为测试用例，我们应取10及50，还应取10.01,49.99,9.99及50.01等。

　　2) 如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。

比如，一个输入文件应包括1~255个记录，则测试用例可取1和255，还应取0及256等。

　　3) 将规则1）和2）应用于输出条件，即设计测试用例使输出值达到边界值及其左右的值。

　　例如，某程序的规格说明要求计算出"每月保险金扣除额为0至1165.25元"，其测试用例可取0.00及1165.24、还可取一0.01及1165．26等。

　　再如一程序属于情报检索系统，要求每次"最少显示1条、最多显示4条情报摘要"，这时我们应考虑的测试用例包括1和4，还应包括0和5等。

　　4) 如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例。

　　5) 如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

　　6) 分析规格说明,找出其它可能的边界条件。

　　二.实战演习

　　1.现有一个学生标准化考试批阅试卷,产生成绩报告的程序。其规格说明如下:程序的输入文件由一些有80个字符的记录组成,如右图所示，所有记录分为3组：

　① 标题：这一组只有一个记录，其内容为输出成绩报告的名字。

　　② 试卷各题标准答案记录：每个记录均在第80个字符处标以数字"2"。该组的第一个记录的第1至第3个字符为题目编号（取值为1一999）。第10至第59个字符给出第1至第50题的答案（每个合法字符表示一个答案）。该组的第2，第3……个记录相应为第51至第100，第101至第150，…题的答案。

　　③ 每个学生的答卷描述：该组中每个记录的第80个字符均为数字"3"。每个学生的答卷在若干个记录中给出。如甲的首记录第1至第9字符给出学生姓名及学号，第10至第59字符列出的是甲所做的第1至第50题的答案。若试题数超过50，则第2，第3……纪录分别给出他的第51至第100，第101至第150……题的解答。然后是学生乙的答卷记录。

　　④ 学生人数不超过200，试题数不超过999。

　　⑤ 程序的输出有4个报告：

　　a) 按学号排列的成绩单，列出每个学生的成绩、名次。

　　b) 按学生成绩排序的成绩单。

　　c) 平均分数及标准偏差的报告。

　　d) 试题分析报告。按试题号排序，列出各题学生答对的百分比。

　　解答：分别考虑输入条件和输出条件，以及边界条件。给出下表所示的输入条件及相应的测试用例。

　　输出条件及相应的测试用例表。

　　2.三角形问题的边界值分析测试用例

　　在三角形问题描述中，除了要求边长是整数外，没有给出其它的限制条件。在此，我们将三角形每边边长的取范围值设值为[1, 100] 。

　　

测试用例	a	b	c	预期输出
Test1 Test2 Test3 Test4 Test5	60 60 60 50 50	60 60 60 50 50	1 2 60 99 100	等腰三角形 等腰三角形 等边三角形 等腰三角形 非三角形
Test6 Test7 Test8 Test9	60 60 50 50	1 2 99 100	60 60 50 50	等腰三角形 等腰三角形 等腰三角形 非三角形
Test10 Test11 Test12 Test13	1 2 99 100	60 60 50 50	60 60 50 50	等腰三角形 等腰三角形 等腰三角形 非三角形

　　3.NextDate函数的边界值分析测试用例

　　在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为1912≤year≤2050 。

测试用例	mouth	day	year	预期输出
Test1 Test2 Test3 Test4 Test5 Test6 Test7	6 6 6 6 6 6 6	15 15 15 15 15 15 15	1911 1912 1913 1975 2049 2050 2051	1911.6.16 1912.6.16 1913.6.16 1975.6.16 2049.6.16 2050.6.16 2051.6.16
Test8 Test9 Test10 Test11 Test12 Test13	6 6 6 6 6 6	-1 1 2 30 31 32	2001 2001 2001 2001 2001 2001	day超出[1…31] 2001.6.2 2001.6.3 2001.7.1 输入日期超界 day超出[1…31]
Test14 Test15 Test16 Test17 Test18 Test19	-1 1 2 11 12 13	15 15 15 15 15 15	2001 2001 2001 2001 2001 2001	Mouth超出[1…12] 2001.1.16 2001.2.16 2001.11.16 2001.12.16 Mouth超出[1…12]

 

一.方法简介

　　1.定义

　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

　　2.划分等价类：

　　等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。

　　1)有效等价类

　　是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

　　2)无效等价类

　　与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。

　　设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。

　　3.划分等价类的标准：

　　1)完备测试、避免冗余;

　　2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;

　　3)并是整个集合：完备性;

　　4)子集互不相交：保证一种形式的无冗余性;

　　5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

　　4.划分等价类的方法

　　1)在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；

　　2)在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下,可确立一个有效等价类和一个无效等价类；

　　3)在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

　　4)在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。

　　例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。

　　5)在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；

　　6)在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

　　5.设计测试用例

　　在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

　　1)为每一个等价类规定一个唯一的编号；

　　2)设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；

　　3)设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

二.实战演习

　　1.某程序规定："输入三个整数 a 、 b 、 c 分别作为三边的边长构成三角形。通过程序判定所构成的三角形的类型，当此三角形为一般三角形、等腰三角形及等边三角形时，分别作计算 … "。用等价类划分方法为该程序进行测试用例设计。（三角形问题的复杂之处在于输入与输出之间的关系比较复杂。）

　　分析题目中给出和隐含的对输入条件的要求：

　　（1）整数 （2）三个数 （3）非零数 （4）正数

　　（5）两边之和大于第三边 （6）等腰 （7）等边

　　如果 a 、 b 、 c 满足条件（ 1 ） ~ （ 4 ），则输出下列四种情况之一：

　　1)如果不满足条件（5），则程序输出为 " 非三角形 " 。

　　2)如果三条边相等即满足条件（7），则程序输出为 " 等边三角形 " 。

　　3)如果只有两条边相等、即满足条件（6），则程序输出为 " 等腰三角形 " 。

　　4)如果三条边都不相等，则程序输出为 " 一般三角形 " 。

　　列出等价类表并编号

　　 覆盖有效等价类的测试用例：

　　a b c 覆盖等价类号码

　　3 4 5 （1）--（7）

　　4 4 5 （1）--（7），（8）

　　4 5 5 （1）--（7），（9）

　　5 4 5 （1）--（7），（10）

　　4 4 4 （1）--（7），（11）

　　覆盖无效等价类的测试用例：

2.设有一个档案管理系统，要求用户输入以年月表示的日期。假设日期限定在1990年1月~2049年12月，并规定日期由6位数字字符组成，前4位表示年，后2位表示月。现用等价类划分法设计测试用例，来测试程序的"日期检查功能"。

　　1)划分等价类并编号,下表等价类划分的结果

输入等价类	有效等价类	无效等价类
日期的类型及长度	①6位数字字符	②有非数字字符 ③少于6位数字字符 ④多于6位数字字符
年份范围	⑤在1990~2049之间	⑥小于1990 ⑦大于2049
月份范围	⑧在01~12之间	⑨等于00 ⑩大于12

　　2)设计测试用例，以便覆盖所有的有效等价类在表中列出了3个有效等价类，编号分别为①、⑤、⑧，设计的测试用例如下：

　　测试数据 期望结果 覆盖的有效等价类

200211 输入有效 ①、⑤、⑧

　　3)为每一个无效等价类设计一个测试用例，设计结果如下：

　　测试数据 期望结果 覆盖的无效等价类

95June 无效输入 ② 20036 无效输入③ 2001006无效输入 ④ 198912 无效输入 ⑥ 200401 无效输入 ⑦ 200100 无效输入 ⑨ 200113 无效输入 ⑩

　　3.NextDate 函数包含三个变量：month 、 day 和 year ，函数的输出为输入日期后一天的日期。 例如，输入为 2006年3月 7日，则函数的输出为 2006年3月8日 。要求输入变量 month 、 day 和 year 均为整数值，并且满足下列条件：

①1≤month≤12 ②1≤day≤31 ③1920≤year≤2050

　　1)有效等价类为：

　　

M1＝{月份：1≤月份≤12} D1＝{日期：1≤日期≤31} Y1＝{年：1812≤年≤2012}

　　2)若条件 ① ~ ③中任何一个条件失效，则 NextDate 函数都会产生一个输出，指明相应的变量超出取值范围，比如 "month 的值不在 1-12 范围当中 " 。显然还存在着大量的 year 、 month 、 day 的无效组合， NextDate 函数将这些组合作统一的输出： " 无效输入日期 " 。其无效等价类为：

M2＝{月份：月份<1} M3＝{月份：月份>12} D2＝{日期：日期<1} D3＝{日期：日期>31} Y2＝{年：年<1812} Y3＝{年：年>2012} 弱一般等价类测试用例 月份 日期 年 预期输出 6 15 1912 1912年6月16日

　　强一般等价类测试用例同弱一般等价类测试用例

　　注：弱--有单缺陷假设；健壮--考虑了无效值

　　(一)弱健壮等价类测

　　

用例ID 月份 日期 年 预期输出 WR1 6 15 1912 1912年6月16日 WR2 -1 15 1912 月份不在1～12中 WR3 13 15 1912 月份不在1～12中 WR4 6 -1 1912 日期不在1～31中 WR5 6 32 1912 日期不在1～31中 WR6 6 15 1811 年份不在1812～2012中 WR7 6 15 2013 年份不在1812～2012中

　　(二)强健壮等价类测试

　　

用例ID 月份 日期 年 预期输出 SR1 -1 15 1912 月份不在1～12中 SR2 6 -1 1912 日期不在1～31中 SR3 6 15 1811 年份不在1812～2012中 SR4 -1 -11912 两个无效一个有效 SR5 6 -1 1811 两个无效一个有效 SR6 -1 15 1811 两个无效一个有效 SR7 -1 -11811 三个无效

　　4.佣金问题等价类测试用例，它是根据佣金函数的输出值域定义等价类，来改进测试用例集合。

输出销售额≤1000元 佣金10％ 　　1000<销售额≤1800 佣金=100+(销售额-1000)*15% 　　销售额>1800 佣金=220+(销售额-1800)*20% 　　测试用例 枪机(45) 枪托(30) 枪管(25) 销售额 佣金

　　

1 5 5 5 500 50 2 15 15 15 1500 175 3 25 25 25 2500 360

　　根据输出域选择输入值，使落在输出域等价类内，可以结合弱健壮测试用例结合。

一. 方法简介

　　1. 定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

　　2. 错误推测方法的基本思想：

　　列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

　　1) 例如, 输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

　　2) 例如，前面例子中成绩报告的程序，采用错误推测法还可补充设计一些测试用例：

　　I.程序是否把空格作为回答

　　II. 在回答记录中混有标准答案记录

　　III.除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

　　IV.有两个学生的学号相同

　　V. 试题数是负数。

　　3) 再如，测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

　　I.输入的线性表为空表；

　　II. 表中只含有一个元素；

　　III.输入表中所有元素已排好序；

　　IV.输入表已按逆序排好；

　　V. 输入表中部分或全部元素相同。

　　二. 实战演习

　　 暂无

一. 方法简介

　　1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

　　2.因果图法产生的背景：

　　等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

　　如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

　　3.因果图介绍

　　1) 4种符号分别表示了规格说明中向4种因果关系。

　　2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

　　3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

　　4. 因果图概念

　　1) 关系

　　① 恒等：若ci是1，则ei也是1；否则ei为0。

　　② 非：若ci是1，则ei是0；否则ei是1。

　　③ 或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。

　　④ 与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

　　 2) 约束

　　输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

　　A.输入条件的约束有以下4类：

　　① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

　　② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

　　③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

　　④ R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

　　B.输出条件约束类型

　　输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

　　5. 采用因果图法设计测试用例的步骤：

　　1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

　　2) 分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

　　3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

　　4) 把因果图转换为判定表。

　　5) 把判定表的每一列拿出来作为依据,设计测试用例。

二. 实战演习

　　1. 某软件规格说明书包含这样的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息。

　　解答：

　　1) 根据题意，原因和结果如下：

　　原因：

　　1——第一列字符是A；

　　2——第一列字符是B；

　　3——第二列字符是一数字。

　　结果：

　　21——修改文件；

　　22 ——给出信息L；

　　23——给出信息M。

　　2) 其对应的因果图如下：

　　11为中间节点；考虑到原因1和原因2不可能同时为1，因此在因果图上施加E约束。

　　3) 根据因果图建立判定表。

　　表中8种情况的左面两列情况中，原因①和原因②同时为1，这是不可能出现的，故应排除这两种情况。表的最下一栏给出了6种情况的测试用例，这是我们所需要的数据。

　　2. 有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。其规格说明如下：若投入5角钱或1元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投入1元硬币并押下按钮后，饮料不送出来而且1元硬币也退出来；若有零钱找，则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还5角硬币。

　　1) 分析这一段说明，列出原因和结果

　　原因：

　　1.售货机有零钱找

　　2.投入1元硬币

　　3.投入5角硬币

　　4.押下橙汁按钮

　　5.押下啤酒按钮

　　结果：

　　21.售货机〖零钱找完〗灯亮

　　22.退还1元硬币

　　23.退还5角硬币

　　24.送出橙汁饮料

　　25.送出啤酒饮料

　　2) 画出因果图，如图所示。所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中间状态。中间结点：

　　11. 投入1元硬币且押下饮料按钮

　　12. 押下〖橙汁〗或〖啤酒〗的按钮

　　13. 应当找5角零钱并且售货机有零钱找

　　14. 钱已付清

　　3) 转换成判定表：

　　4) 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。

1. Myers提出了使用各种测试方法的综合策略：

　　1) 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。

　　2) 必要时用等价类划分方法补充一些测试用例。

　　3) 用错误推测法再追加一些测试用例。

　　4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

　　5) 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

　　2.测试用例的设计步骤

　　1) 构造根据设计规格得出的基本功能测试用例；

　　2) 边界值测试用例；

　　3) 状态转换测试用例；

　　4) 错误猜测测试用例；

　　5) 异常测试用例；

　　6) 性能测试用例；

　　7) 压力测试用例。

　　3.优化测试用例的方法

　　1) 利用设计测试用例的8种方法不断的对测试用例进行分解与合并；

　　2) 采用遗传算法理论进化测试用例；

　　3) 在测试时利用发散思维构造测试用例

一.方法简介

　　现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

　　基本流和备选流：如下图所示，图中经过用例的每条路径都用基本流和备选流来表示，直黑线表示基本流，是经过用例的最简单的路径。备选流用不同的色彩表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中（如备选流1和3）；也可能起源于另一个备选流（如备选流2），或者终止用例而不再重新加入到某个流（如备选流2和4）。

　　二.实战演习

　　1. 例子描述

　　下图所示是ATM例子的流程示意图。

　　2.场景设计：下表所示是生成的场景。

表3-8 场景设计

场景1——成功提款	基本流
场景2——ATM内没有现金	基本流	备选流2
场景3——ATM内现金不足	基本流	备选流3
场景4——PIN有误（还有输入机会）	基本流	备选流4
场景5——PIN有误（不再有输入机会）	基本流	备选流4
场景6——账户不存在/账户类型有误	基本流	备选流5
场景7——账户余额不足	基本流	备选流6

　　注：为方便起见，备选流3和6（场景3和7）内的循环以及循环组合未纳入上表。

3.用例设计

　　对于这7个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

表3-9 测试用例表

TC（测试用例）ID号	场景/条件	PIN	账号	输入（或选择）的金额	账面金额	ATM内的金额	预期结果
CW1	场景1：成功提款	V	V	V	V	V	成功提款
CW2	场景2：ATM内没有现金	V	V	V	V	I	提款选项不可用，用例结束
CW3	场景3：ATM内现金不足	V	V	V	V	I	警告消息，返回基本流步骤6，输入金额
CW4	场景4：PIN有误（还有不止一次输入机会）	I	V	n/a	V	V	警告消息，返回基本流步骤 4，输入 PIN
CW5	场景4：PIN有误（还有一次输入机会）	I	V	n/a	V	V	警告消息，返回基本流步骤 4，输入 PIN
CW6	场景4：PIN有误（不再有输入机会）	I	V	n/a	V	V	警告消息，卡予保留，用例结束

　　4.数据设计

　　一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

　　测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据，如表3-10所示。

　　表3-10 测试用例表

TC（测试用例）ID号	场景/条件	PIN	账号	输入（或选择）的金额（元）	账面 金额（元）	ATM内的金额（元）	预期结果
CW1	场景1：成功提款	4987	809-498	50.00	500.0	2 000	成功提款。账户余额被更新为450.00
CW2	场景2：ATM内没有现金	4987	809-498	100.00	500.0	0.00	提款选项不可用，用例结束
CW3	场景3：ATM内现金不足	4987	809-498	100.00	500.0	70.00	警告消息，返回基本流步骤6，输入金额
CW4	场景4：PIN有误（还有不止一次输入机会）	4978	809-498	n/a	500.00	2 000	警告消息，返回基本流步骤4，输入PIN
CW5	场景4：PIN有误（还有一次输入机会）	4978	809-498	n/a	500.00	2 000	警告消息，返回基本流步骤4，输入PIN
CW6	场景4：PIN有误（不再有输入机会）	4978	809-498	n/a	500.00	2 000	警告消息，卡予保留，用例结束

 

一、什么是SQL注入式攻击？

所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如：

⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。

⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子：站长资讯网：http://www.net118.com

System.Text.StringBuilder query = new System.Text.StringBuilder(
)`'E$j0x!K$p-f'Z7pb0N230007
m+apbo e230007"SELECT * from Users WHERE login = '")51Testing软件测试网T'Rs.{-H,QX)M
51Testing软件测试网*nN:j6D^Xz [
.Append(txtLogin.Text).Append("' AND password='")51Testing软件测试网LuE!l9{b/|+UI-X
51Testing软件测试网!f'Our5cH+`0Q)I!v
.Append(txtPassword.Text).Append("'");

⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。

⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。

⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。

⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。

如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。

系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。

二、如何防范？

好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。

⑴ 对于动态构造SQL查询的场合，可以使用下面的技术：

第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。

第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。

第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。

⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。

⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。

⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。

在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。

⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。

⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理

何时使用重构

　　新官上任三把火，开始一个全新的项目时，程序员往往也会燃起三把火：紧锣密鼓、脚不停蹄、加班加点，一支声势浩大的千军万"码"夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指"黄龙府"。

　　开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐恒公站在山顶上看到管仲训练的 队伍整齐划一地前进时，他感叹说"我有这样一支军队哪里还怕没有胜利呢?"。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大， 所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。

　　Kent Beck提出了"代码坏味道"的说法，和我们所提出的"队伍变形"是同样的意思，队伍变形的信号是什么呢?以下列述的代码症状就是"队伍变形"的强烈信号：

　　·代码中存在重复的代码

　　中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。

　　程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。

　　过大的类和过长的方法

　　过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国， 诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方 法时，需要想办法将其划分为多个小方法，以便于分而治之。

　　牵一毛而需要动全身的修改

　　当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。

　　类之间需要过多的通讯

　　A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。

过度耦合的信息链

　　"计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题"，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。

　　各立山头干革命

　　如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队成员协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。

　　不完美的设计

　　在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报 警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系 统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。

　　每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。

　　缺少必要的注释虽然许多软件工程的 书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释 往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生"提笔忘字，愈言且止"的情形。

　　曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。

 什么是重构

　　重构是在编写代码后在不更改代码的外部行为的前提下通过更改代码的内部结构来改进代码的过程。目的是提高其可理解性,降低其修改成本。

　　通俗的说法就是,程序的功能和结果没有任何的变化。重构只是对程序内部结构进行调整,让代码更加容易理解,然后更容易维护。

　　为什么要重构

　　至于为什么要重构，因本人才疏学浅，故特引用软件工程专家的一段话：

　　在不改变系统功能的情况下，改变系统的实现方式。为什么要这么做?投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢?

　　重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢?

　　对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。

　　考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。

　　这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越 来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。

　　重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。

　　通过重构可以达到以下的目标：

　　·持续偏纠和改进软件设计

　　重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。

　　·使代码更易为人所理解

　　Martin Flower在《重构》中有一句经典的话："任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。"对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢?

　　软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。

　　对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情!

帮助发现隐藏的代码缺陷

　　孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的"感冒"。当你也发生这样的情形时，通过重构代码可以加深对原设计的 理解，发现其中的问题和隐患，构建出更好的代码。

　　·从长远来看，有助于提高编程效率

　　当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。

　　改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。

Website Cookie Testing, Test cases for testing web application cookies?

Posted In | Cookie Testing, Web Testing

是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？

测试用例是否包含了所有单一的边界？

测试用例是否包含了所有的业务数据流？

是否所有的测试用例名称，ID都与测试工件命名约定一致？

测试用例评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员

3.2 用例库的更新维护

随着软件项目的开发，用例库的数据随着项目的进展动态变化也是需要维护的，主要包括：不合适用例的修改、冗余用例的删除、测试用例的增加，并对进行的操作在备注中署名修改者以及修改时间和改动原因。

4 测试用例实例

该测试案例是以一个B/S结构的登录功能点位被测对象, 该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。

功能描述如下：

1. 用户在地址栏输入相应地址，要求显示登录界面；

2. 输入用户名和密码，登录，系统自动校验，并给出相应提示信息；

3. 如果用户名或者密码任一信息未输入，登录后系统给出相应提示信息；

4. 连续3次未通过验证时，自动关闭IE。

表4-1 登录界面测试用例

用例ID		XXXX-XX-XX	用例名称		系统登录
用例描述		系统登录 用户名存在、密码正确的情况下，进入系统 页面信息包含：页面背景显示 用户名和密码录入接口，输入数据后的登入系统接口
用例入口		打开IE，在地址栏输入相应地址 进入该系统登录页面
测试用例ID	场景			测试步骤		预期结果	备注
TC1	初始页面显示			从用例入口处进入		页面元素完整，显示与详细设计一致
TC2	用户名录入－验证			输入已存在的用户：test		输入成功
TC3	用户名－容错性验证			输入：aaaaabbbbbcccccdddddeeeee		输入到蓝色显示的字符时，系统拒绝输入	输入数据超过规定长度范围
TC4	密码－密码录入			输入与用户名相关联的数据：test		输入成功
TC5	系统登录－成功			TC2，TC4，单击登录按钮		登录系统成功
TC6	系统登录－用户名、密码校验			没有输入用户名、密码，单击登录按钮		系统登录失败，并提示：请检查用户名和密码的输入是否正确
TC7	系统登录－密码校验			输入用户名，没有输入密码，单击登录按钮		系统登录失败，并提示：需要输入密码
TC8	系统登录－密码有效性校验			输入用户名，输入密码与用户名不一致，单击登录按钮		系统登录失败，并提示：错误的密码
TC9	系统登录－输入有效性校验			输入不存在的用户名、密码，单击登录按钮		系统登录失败，并提示：用户名不存在
TC10	系统登录—安全校验			连续3次未成功		系统提示：您没有使用该系统的权限，请与管理员联系！
…	…					…	…

http://www.51testing.com/?51504/action_viewspace_itemid_96819.html

一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

　　第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

　　我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

　　现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

　　最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

　　你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

　　我的体会：

　　１、测试用例要根据测试大纲来编写

　　２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

　　３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

　　４、熟悉系统，对编写测试用例很有帮助。

　　５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

　　今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可

　　第四步：执行测试

10. 您以往是否曾经从事过性能测试工作？如果有，请尽可能的详细描述您以往的性能测试工作的完整过程。

　　是的，曾经做过网站方面的性能测试，虽然做的时间并不久（2个月吧），当时呢，是有位网站性能测试经验非常丰富的前辈带着我一起做。

性能测试类型包括负载测试，强度测试，容量测试等

　　负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

　　强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况

　　容量测试：确定系统可处理同时在线的最大用户数  

　　在网站流量逐渐加大的情况下，开始考虑做性能测试了，首先要写好性能测试计划，根据运营数据得出流量最大的页面（如果是第一次的话，一般是首页，下载页，个人帐户页流量最大，而且以某种百分比），

　　Web服务器指标指标：

　　* Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

　　* Successful Rounds：成功的请求；

　　* Failed Rounds ：失败的请求；

　　* Successful Hits ：成功的点击次数；

　　* Failed Hits ：失败的点击次数；

　　* Hits Per Second ：每秒点击次数；

　　* Successful Hits Per Second ：每秒成功的点击次数；

　　* Failed Hits Per Second ：每秒失败的点击次数；

　　* Attempted Connections ：尝试链接数；　　

11. 您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

12. 您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？

13. 在您以往的工作中，一条软件缺陷（或者叫Bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（Bug）记录？

14. 您以往所从事的软件测试工作中，是否使用了一些工具来进行软件缺陷（Bug）的管理？如果有，请结合该工具描述软件缺陷（Bug）跟踪管理的流程。

15. 您认为在测试人员同开发人员的沟通过程中，如何提高沟通的效率和改善沟通的效果？维持测试人员同开发团队中其他成员良好的人际关系的关键是什么？

16. 在您以往的测试工作中，最让您感到不满意或者不堪回首的事情是什么？您是如何来对待这些事情的？

17. 在即将完成这次笔试前，您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会？（可以包括软件测试、过程改进、软件开发或者与此无关的其他方面）

18.你对测试最大的兴趣在哪里？为什么？

　　最大的兴趣就是测试有难度，有挑战性！做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章，是关于如何做好一名测试工程师。一共罗列了十一二点，有部分是和人的性格有关，有部分需要后天的努力。但除了性格有关的1、2点我没有把握，其他点我都很有信心做好它。

　　刚开始进入测试行业时，对测试的认识是从无忧测试网上了解到的一些资料，当时是冲着做测试需要很多技能才能做的好，虽然入门容易，但做好很难，比开发更难，虽然当时我很想做开发（学校专业课我基本上不缺席，因为我喜欢我的专业），但看到测试比开发更难更有挑战性，想做好测试的意志就更坚定了。

　　不到一年半的测试工作中，当时的感动和热情没有减退一点（即使环境问题以及自身经验，技术的不足，做测试的你一定也能理解）。

　　我觉得做测试整个过程中有2点让我觉得很有难度（对我来说，有难度的东西我就非常感兴趣），第一是测试用例的设计，因为测试的精华就在测试用例的设计上了，要在版本出来之前，把用例写好，用什么测试方法写？（也就是测试计划或测试策略），如果你刚测试一个新任务时，你得花一定的时间去消化业务需求和技术基础，业务需求很好理解（多和产品经理和开发人员沟通就能达到目的），而技术基础可就没那么简单了，这需要你自觉的学习能力，比如说网站吧，最基本的技术知识你要知道网站内部是怎么运作的的，后台是怎么响应用户请求的？测试环境如何搭建？这些都需要最早的学好。至少在开始测试之前能做好基本的准备，可能会遇到什么难题？需求细节是不是没有确定好？这些问题都能在设计用例的时候发现。

　　第二是发现BUG的时候了，这应该是测试人员最基本的任务了，一般按测试用例开始测试就能发现大部分的bug，还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息，补充测试用例，测试出bug。还有如何发现bug？这就需要在测试用例有效的情况下，通过细心和耐心去发现bug了，每个用例都有可能发现bug，每个地方都有可能出错，所以测试过程中思维要清晰（测试过程数据流及结果都得看仔细了，bug都在里面发现的）。如何描述bug也很有讲究，bug在什么情况下会产生，如果条件变化一点点，就不会有这个bug，以哪些最少的操作步骤就能重现这个bug，这个bug产生的规律是什么？如果你够厉害的话，可以帮开发人员初步定位问题。

19. 你的测试职业发展是什么？

　　测试经验越多，测试能力越高。所以我的职业发展是需要时间累积的，一步步向着高级测试工程师奔去。而且我也有初步的职业规划，前3年累积测试经验，按如何做好测试工程师的11，12点要求自己，不断的更新自己改正自己，做好测试任务。

20. 你自认为测试的优势在哪里？

　　优势在于我对测试坚定不移的信心和热情，虽然经验还不够，但测试需要的基本技能我有信心在工作中得以发挥。

21. 你以前工作时的测试流程是什么？

　　公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>想好测试策略，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接录制进TD）－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

22. 当开发人员说不是BUG时，你如何应付？

　　开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

23．你为什么想离开目前的职务？

　　因为公司运作情况并不理想，公司需要调整部门体系，公司考虑到缩减部门人员，所以大批量的裁员（有6，7个），这是我的第一份工作，对公司也有较深的感情，因为在这里我找到了职业理想（就是测试），所以公司需要精简人员，我自愿退出。虽然很舍不得，但我将会有新的发挥能力的舞台。

24：你对我们公司了解有多少？

25：你找工作时，最重要的考虑因素为何？

　　工作的性质和内容是否能让我发挥所长，并不断成长。

26：为什么我们应该录取你？

　　您可以由我过去的工作表现所呈现的客观数据，明显地看出我全力以赴的工作态度。

27：请谈谈你个人的最大特色。

　　我的坚持度很高，事情没有做到一个令人满意的结果，绝不罢手。

28.白箱测试和黑箱测试是什么?什么是回归测试?

29。单元测试、集成测试、系统测试的侧重点是什么？

30。设计用例的方法、依据有那些？

31。一个测试工程师应具备那些素质和技能？

32.集成测试通常都有那些策略？

33.你用过的测试工具的主要功能、性能及其他？

34.一个缺陷测试报告的组成

35.基于WEB信息管理系统测试时应考虑的因素有哪些？

36.软件测试项目从什么时候开始，？为什么？

37.需求测试注意事项有哪些？

38.简述一下缺陷的生命周期

39.测试分析测试用例注意（事项）？

测试环境 是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。毫无疑问，稳定和可控的测试环境，可以使测试人员花费较少的时间就完成测试用例的执行，也无需为测试用例、测试过程的维护花费额外的时间，并且可以保证每一个被提交的缺陷都可以在任何时候被准确的重现。

简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

 

一、规划测试环境——让环境为你服务

 

对于“金山词霸”这样的软件，大多数测试工作都可以在一台单独的电脑上完成，而对于一套电信系统，为了执行测试用例，你可能会需要搭建一个由多台计算机以及其他网络设备组成，采用集群和负载均衡技术，并且接驳到Internet的计算机网络。

不同的行业应用，不同的质量目标，都可能会影响到测试环境的规划。但从测试工作自身的要求来看，一条应当遵守的原则就是“尽可能的还原软件在用户那里最终实际运行的环境”——虽然在很多时候这是不现实的。^_^

通常来说，我们所需要搭建的环境，主要是用于被测应用的系统测试——单元测试和集成测试由开发人员在开发环境中进行，而验收测试则在用户的最终应用环境中进行，因此都可以暂不考虑。

为了确定测试环境的组成，我们需要明确以下问题：

1.         所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；

2.         部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3.         用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4.         用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

5.         是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

6.         测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；

7.         执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

8.         为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料；对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。当然，还有另外一个非常关键的问题：在测试过程中受到影响的数据如何恢复？

    明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。建议在搭建测试环境之前，把上面的问题做成一张CheckList，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。当然，如果时间或其他条件允许，应当做好应急预案，尽量保证在环境失效时不会对正常工作产生太大的影响。

 

二、管理测试环境——把变化掌握在手中

 

    测试环境搭建好以后不太可能永远不发生变化，至少被测应用的每次版本发布都会对测试环境产生或多或少的影响。而应对变化之道，不是禁止变化，而是“把变化掌握在手中”。下面的这些建议可以帮助你尽可能摆脱环境变化所带来的不利影响。

1.         设置专门的测试环境管理员角色

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：

ü         测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；

ü         记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

ü         完成被测应用的部署，并做好发布文档的编写；

ü         测试环境各项变更的执行及记录；

ü         测试环境的备份及恢复；

ü         操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

ü         当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

2.         明确测试环境管理所需的各种文档

一般来说，下面的几个文档是必需的，当然你也可以根据需要增加新的文档。

ü         组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

ü         组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

ü         被测应用的发布手册，记录被测应用的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测应用的发布情况，对版本差异进行描述；

ü         测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

ü         用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

3.         测试环境访问权限的管理

    应当为每个访问测试环境的测试人员和开发人员设置单独的用户名，并根据不同的工作需要设置不同的访问权限，以避免误操作对测试环境产生不利的影响。下面的要求可以作为建立“测试环境访问权限管理规范”的基础。

ü         访问操作系统、数据库、中间件、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

ü         测试环境管理员拥有全部的权限；

ü         除对被测应用的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限；

ü         除测试环境管理员外，其他测试组成员不授予删除权限；

ü         用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

4.         测试环境的变更管理

    对测试环境的变更应当形成一个标准的流程，并保证每次变更都是可追溯的和可控的。下面的几项要点并不是一个完整的流程，但是可以帮助你实现这个目标。

ü         测试环境的变更申请由开发人员或测试人员提出书面申请，由测试环境管理员负责执行。测试环境管理员不应接受非正式的变更申请（例如口头申请）；

ü         对测试环境的任何变更均应记入相应的文档；

ü         同每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

ü         对于被测应用的发布，开发人员应将整个系统（包括数据库、应用层、客户端等）打包为可直接发布的格式，由测试环境管理员负责实施。测试环境管理员不接受不完整的版本发布申请；

ü         对测试环境做出的变更，应该可以通过一个明确的方法返回到之前的状态。

5.         测试环境的备份和恢复

对于测试人员来说，测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。因此，应当在测试环境（特别是软件环境）发生重大变动（例如安装操作系统、中间件或数据库，为操作系统、中间件或数据库打补丁等对系统产生重大影响并难以通过卸载恢复）时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。并由测试环境管理员在相应的“备份记录”文档中记录每次备份的时间、备份人以及备份原因（与上次备份相比发生的变化），以便于在需要时将系统重新恢复到安全可用的状态。

另外，每次发布新的被测应用版本时，应当做好当前版本的数据库备份。而在执行测试用例或性能测试场景之前，也应当做好数据备份或准备数据恢复方案，例如通过运行SQL脚本来将数据恢复到测试执行之前的状态，以便于重复的使用原有的数据，减少因数据准备和维护而占用的工作量，并保证测试用例的有效性和缺陷记录的可重现。

1. 测试环境重要性及意义

1、稳定、可控的测试环境，可使测试人员花费较少时间完成测试用例的执行；

2、 可保证每一个被提交的缺陷被准确的重现；

3、经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

2. 测试环境搭建原则

测试环境搭建之前，需要明确以下问题：

1、所需计算机数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度等；

2、部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3、用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4、是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

5、测试中所需要使用的网络环境；

6、执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

7、测试数据的备份与恢复是否需要；

8、模拟实际生产环境或用户环境搭建。

3. 测试环境管理

一、设置专门的测试环境管理员

每条业务线或测试小组应配备一名专门的测试环境管理员，其职责包括：

ü 测试环境搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册编写；

ü 记录组成测试环境的各台机器硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

ü 完成被测应用的部署，并做好发布文档的编写；

ü 测试环境各项变更的执行及记录；

ü 测试环境的备份及恢复；

ü 操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

ü 当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

二、测试环境文档管理

需要维护如下文档是最新版本：

ü 组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

ü 组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

ü 被测软件或产品的发布手册，记录被测软件或产品的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测软件或产品的发布情况，对版本差异进行描述；

ü 测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

ü 用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

三、测试环境访问权限管理

按照如下要求维护测试环境权限：

ü 访问操作系统、数据库、中间件、WEB服务器以及被测软件或产品等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

ü 测试环境管理员拥有全部的权限；

ü 除对被测软件或产品的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限（user权限）；

ü 除测试环境管理员外，其他测试组成员不授予删除权限；

ü 用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

四、测试环境变更管理

确保每次变更是可追溯和可控：

ü 测试环境的变更申请由测试人员提出邮件申请，由测试环境管理员负责执行。测试环境管理员不接受非正式的变更申请（例如口头申请）；

ü 对测试环境的任何变更，测试负责人均应记入相应的文档；

ü 每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

ü 对于被测软件或产品的发布，开发人员负责打包、测试人员核对发布包。

五、测试环境备份与恢复

1、确保测试环境程序版本、数据是可恢复；

2、对于功能或性能测试，测试数据需定期进行备份或从生产环境导入测试数据；

3、通过备份软件工具备份数据，同时保障备份数据可快速恢复。

4. 测试环境维护执行流程附件

1、测试机器申请流程

2、测试机器维护列表格式

3、测试环境部署文档维护列表格式

4、发布手册维护列表格

测试人员主要是三个方面。
        第一，整体工作效率。第二，工作结果。第三，过程控制。（针对测试主管或组长）
        1.整体工作效率
        1.1有效工作时间
        主要check指标是每日实际工作时间，按照Ms的标准，一个测试工程师的每天的有效工作时间应该在70%以上。如果只有50%或以下的有效工作时间，那么不能成为好的测试工程师，因为他有能力做得更好。
        1.2是否在制定时间内完成工作任务
        主要check指标是进度偏离度。主要是和测试计划相比，有多少的延期。这个指标计算是：计划时间/实际需用时间。
        当然，本指标未考虑其他因素，如开发人员窝工导致的delay。
        2.工作结果
        2.1测试用例的数量和质量
        a，测试用例的数量
        主要考核指标是用例编写速度，考核办法是测试用例的个数/写用例所用时间。
        b，测试用例的质量
        主要考核指标是用例编写质量，用于考察文档是由有效的指导了测试工作。考核办法是来自用例的bug数目/总bug数目，应该是70%以上才算是质量比较好的用例。
        2.2bug的数量和质量
        a，bug提交的数量
        主要考核指标是提交bug的数量，这个指标根据项目不同而定，不好给出固定经验值。
        b，bug的质量
        主要考核指标是提交bug的质量，即提交的bug，严重程度和，发现路径的复杂程度
        c，发现bug的阶段
        主要考核指标是提交bug的时间段，具体执行是统计在测试的每个阶段，发现bug的比例，特别是严重的bug发现的早晚
        2.3是否及时验证关闭bug
        主要考核指标是验证关闭bug的及时度
        2.4测试自动化程度及收效
        主要考核指标是，测试中自动化运用的含量，也就是测试技术含量，成果如何？
        2.5所负责模块的产品总体质量以及用户反馈
        这个总体质量是产品发布之后一段时间才能得出结论，主要是市场，用户对产品的质量、稳定性、性能的反馈。
考核的主要指标是两个。
        a，根据市场反馈（由经理定性考核）
        b，根据测试人员提交的bug和用户反馈的bug之间的比例，比例越大，说明测试质量相对越高。当然前提是必须划清楚客户的新需求，或者对spec设计方面的抱怨。
        3.过程改进
        考核点，是纵向对比，相比上一个项目，在质量控制上和测试进度进程上有否进步。包括测试方法，提升质量的手段，测试数据记录，用例更新等等有没有改进。
        该项具体考核方法也是经理来根据测试组在过程中具体表现，来定性打分。
        还包括测试人员在测试过程中的学习能力。这个也是定性。
        4.考核注意事项
        4.1统计bug的注意事项
        5.其它注意事项
        作为考核者要注意以下比例，也许有些没有列入考核内容，但是如下这些点可以指导测试。
        a，测试团队发现的bug和所有bug之间的比例
        b，spec设计造成的bug
        c，重复或者误提交的bug所占的比例
        d，每周发现的bug的趋势图
        e，Bug严重等级的构成比例
        f，Bug从提交到解决的平均需要时间
        g，Bug从解决到关闭的平均需要时间

虚拟服务器技术被用在试生产环境，目的是节省资金、时间和人力，然而同样的工具如果未经检查就可能会导致结构复杂，资源浪费并使管理难度加大。

　　行业分析师和IT专业人士说，虚拟化技术解除了物理服务器测试环境的限制，实现了IT员工间的资源共享，这就使得测试工作更容易进行，但却需要进行严格的控制。

　　Forrester调查公司的高级分析师Carey Schwaber说，“在测试环境中采用虚拟化技术的一个缺陷是影像数量的增多，特别是在通过不同操作系统测试多个结构时。环境的控制工作必须认真进行，必须有相关政策来避免环境的过度增长或成为无用的资源。”

　　避免测试服务器的蔓延

　　Bowdoin学院的系统工程师Tim Antonowicz说，虚拟化测试使其团队实现了不需要构建新的操作系统或采用其他软件集成开发商的工作站即实现了软件测试。他虚拟化测试环境中有55个运行中的虚拟机。

　　Antonowicz说，“沙箱是我们测试和评估各种软件的基本虚拟机。如果我们希望尝试一些新的东西，如运行一个测试版本或者仅仅是采用一个新的理念，我们就会采用一个沙箱虚拟机。”

　　用这样一种方式——作为进行测试的一种工具——来利用虚拟化是很平常的。但是大多数IT企业尚未将其在测试中的虚拟化应用在业内标准化。不同的IT组不再运行其虚拟化服务器(通常不能恰当的管理或淘汰)。业内观察家争论在测试实验室中应用虚拟化技术的益处。

　　IDC公司的首席分析师Melinda Ballou说，“在测试时，整合很重要，IT环境需要一个全面的管理方法以确保物理服务器和虚拟资源相协调。”

　　为了帮助IT经理管理其测试资源，虚拟化测试实验室管理软件供应商开始研发新工具。

　　例如Akimbi(Vmware公司收购)、CollabNet、VMLogix和Surgient都在过去的两年中针对采用虚拟服务器工具的企业发布了相关产品，目的是快速建立并拆卸测试环境。产品包括追踪虚拟机和捕捉存放在数据库以备未来使用的结构数据的自动功能。

　　比如，Akimbi公司的Slingshot产品，当前Vmware的Vmware，使得IT经理建立一个软件测试基础设施以自动建立并拆卸多虚拟机环境。Surgient公司的Virtual QA/Test Lab Management System管理系统通过整合测试基础设施加速了测试流程，同时使自动建立和拆卸复杂的测试结构得以实现。

　　当Mercy Healthcare的IT员工意识到为一个工作站更新而升级24000个桌面将消耗人力资源而且不一定能得到期望的结果时，他们转而采用Vmware和Surgient公司的产品。

　　“我们有一个桌面更新循环——包括将企业所有计算机升级到相通的操作系统和相同的锁定程序。客户机工程经理Brian Boresi说，“我们有多个需要提速的IT环境，针对24000台工作站开展这一工作至少会造成人力和时间的紧张，因为我们必须遵循快速配置流程表来进行。”

　　IT团队意识到，对于如此大量的桌面系统发布，虚拟化是唯一现实的选择，Boresi说他知道他们也需要协助管理测试实验室。他们没有采取让一个IT员工实地访问每个桌面用户以确定其应用软件需求的方法，Boresi说Surgient使IT团队可以在测试实验室中将创建多结构的流程自动化，同时基于用户工作站环境来改变结构。

　　Boresi说，“我们当前支持600个应用软件，更新时间很短，发布流程表很紧。除了自动测试和配置这些应用软件，我们没有其他办法。”

一些人说，虚拟化测试实验室管理工具不足以阻止IT环境。IT企业需要明确什么是可以被测试的，然后开展实践，同时在产品发布前确保所有在虚拟机上测试的软件可同样运行于物理机上。

　　Mercy Healthcare采用一个虚拟化环境来进行一到三步的测试，同时在实际使用前在物理服务器上进行测试运行。

　　Neubauer说，“在测试阶段，我们给产品工作站配置了一个应用软件包。用这一方法我们确保了软件可以满足所有需求，并不会在物理服务器上运行时造成阻碍，而按照预期运行。”

　　Cars.com芝加哥公司的技术运行主管Edward Christensen说，他避免在虚拟测试环境下载或实施测试。他说，“我们限制了我们的虚拟化技术应用范围，只将其用于功能性和整合测试。除非你的产品环境也是虚拟化的，否则不该在这一环境对其进行性能测试。”

　　其他专业人士赞同Edward Christensen的说法，认为不该在虚拟测试实验室内开展性能测试，例如应用软件下载和有效性测试。

　　Forrester的Schwaber说，“通过应用软件在假设负载为10,000用户情况下的运行状态，你不能说服可能用户数目远远超出这一负载时的运行情况。虚拟机的确和物理服务器共享了部分资源，无论是多少，这保证了那些类型的性能测试结果准确。”

　　Yankee Group的高级分析师Gary Chen说，他鼓励用户应用虚拟化来进行环境测试，因为如果他们这样做，工作就会简单化，并可以花费更少资金。但是他也警告IT专业人士不要掉入虚拟化承诺的陷阱。

　　Chen说，“没有人可以完全依靠一个虚拟环境来进行测试。物理测试是必须的。”