现在的心情冰冷而平静。

周六晚上被爸爸气得哭了一场，很伤心，觉得自己很可怜。也许我本来就很可怜，只是现在才愿意承认。
这是为了同一件事被爸爸气哭的第二次，我很理解他的想法，但是他从来都没有在乎过我的心理。也许这就是无心伤害吧！

不曾体会父爱如山的感觉，他从来不会从心里去关爱家族里的每一个人。每次打电话就是询问工作情况，恨不得我每天升职又加薪，他不是爱钱的人，但是把名益看得比什么都重要。有一次妹妹试探地说，“我以后出国留学就不回来了”，爸爸说可以啊！不知道爸爸是怎么想的，他也许可以抱着有个女儿在国外工作的荣耀过上一生吧！（可笑）

爸爸是个自以为是的人，不管是什么事，他从来不觉得是自己错了，也不在乎别人心里的感受。有一种方法叫做沉默，因为无法交流，所以选择沉默！我想我只能这样！

心里难受，就当自己发泄一下，爸爸始终是爸爸啊！他确实对我们很好，只是他的方法有时难以接受！

   一.方法简介
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      -1       1912      两个无效一个有效
  SR5        6      -1        1811      两个无效一个有效
  SR6       -1      15       1811      两个无效一个有效
  SR7       -1      -1       1811      三个无效
 
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)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
  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——225
字（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] 。

3.NextDate函数的边界值分析测试用例
在NextDate函数中，隐含规定了变量mouth和变量day的取值范围为1≤mouth≤12和1≤day≤31，并设定变量year的取值范围为1912≤year≤2050 。

一.    方法简介

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；如果第二列字符不是数字，则给出信息M。

解答：

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

       原因：

          1——第一列字符是A；

          2——第一列字符是B；

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

       结果：

          21——修改文件；

          22 ——给出信息L；

          23——给出信息M。

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

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

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

<!--[endif]--> 

       表中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)转换成判定表：

<!--[endif]--> 

4) 在判定表中，阴影部分表示因违反约束条件的不可能出现的情况，删去。第16列与第32列因什么动作也没做，也删去。最后可根据剩下的16列作为确定测试用例的依据。
(本文节选自己开拖拉机上班《史上最全的测试用例设计方法总结》)

从未有足够的时间做所有我们需要做的事情，这是在软件项目，尤其在测试中的一个普通的话题。假使你在可用的有限时间内，你如何知道你的测试工作做的最好？你知道当应用程序发布时，总会有些遗漏的缺陷没有被发现。对于测试而言，目标是通过改进产品质量使风险减到最小，并且这可以部分的通过建造一套具体的测试用例来将应用程序按照它的速度完成等方法实现。
IEEE Standard 610 (1990)中定义测试用例为：
1.为一个为特定目标而开发一组测试输入，执行条件和的期望结果，例如测试某个程序路径或核实是否满足某个特定的需求。
2.指定输入，预期结果和一组测试项的执行条件的文档(IEEE Std 829-1983)。
当然，你将发现在项目的生命周期里的每一个应用程序的版本上执行你全部的测试用例是很困难的。但是你将如何知道哪个测试用例必须在每一个版本中执行，什么应该被执行，同时如果你有时间的话，什么又可以被执行？
给你的测试用例划分优先级别
你的应用程序不需要十全十美，但它必须迎合你目标用户的需求和期望。为了了解你项目的期望，你需要确定什么是应用程序中最重要的，目标和风险又是什么。
Sue Bartlett在“How to Find the Level of Quality Your Sponsor Wants”一文中详细的讨论了这个问题，她在文中注解到：“当我们在详细的计划，设计或编码之前沟通质量目标时，我们有一个更好的机会来避免在最后时刻的质量不匹配，那意味着迎合计划，弥补花费并且赢利将有一个更好的成功的机会。”
为了测试计划的目的，在你项目版本的进度下，测试执行的组织和安排你的测试用例将帮助达到这些目标。作为这种组织的一部分，我们要考虑每一个测试用例的优先级别。根据优先级别分组你的测试用例将帮助你决定不同类型的版本需要什么样的测试用例，因此计算需要的时间。如果你只有有限的时间，你可以查看什么是最合适。
Ross Collard在"Use Case Testing\"一文中说：“测试用例的前10%到15%可以发现75%到90%的重要缺陷”。
测试用例的优先级划分将帮助确定找出了这前10%到15%的测试用例。
如何划分测试用例的优先级别
你曾查看过多少次你的测试用例并且能够很容易的挑选出最重要的一个小的子集？这个答案可能是不经常。停止思考“所有的测试用例都是同等重要”这个问题是非常困难的。当设计测试用例时，分配优先级别是不容易，并且在项目期间里不一定是静止的。然而，我们可以通过构造一个划分优先级别流程的例子来开始处理划分测试用例优先级别的第一步。让我们假设你刚刚根据功能说明书，用例和其他一些关于你应用程序的目标行为和能力的信息源完成了建立测试用例。现在是时候来为每个测试用例分配一个优先级别了。
测试用例的优先级别
首先，你必须确定什么是你优先级别的类型和其暗示着什么。就我们的目的来说，我们将用一个假设开始，那就是我们可能发现的缺陷的严重程度和那些相应测试用例的优先级别之间是平行的。
1 –小版本确认测试（Build Verification Tests (BVTs)：也叫做“冒烟测试”，一组你想先运行的以确定这个给出的小版本是否可以测试的测试用例。如果你不能访问每一个功能区域或执行其他测试用例依赖的基本操作，那么在执行这个优先的测试用例之前，试图做其他任何的测试都是没有意义的，因为他们大多数肯定要失败。
2 –高（Highs）：最常执行以保证功能性是稳定的，目标的行为和能力可以正常的工作，和重要的错误和边界被测试的测试用例的集合。
3 –中（Mediums）：这是使给出的功能区域或功能变得更详细，检查功能的多数方面包括边界，错误和配置测试的测试用例
4 –低（Lows）：这是通常最少被执行的测试用例。但这并不意味着这些测试都不重要，只是说他们在项目的生命期间里不是常常被运行，例如GUI，错误信息，可用性，压力和性能测试。
我们将测试用例分成4类：BVTs，高，中和低。现在的问题是将测试用例分到不同的优先级别里。毕竟，优先级别将指出哪些测试用例被认为是需要更频繁的执行的，哪些又不是。
怎样着手分配优先级别
1)随意地分配：
基于如果你没有足够的时间测试却又至少要保证所有的产品需求已经被确认可以在设想的良好状况下象它们被期望的那样工作的想法，前面这3步将让你任意的分组测试用例，如果你也停下来思考每个测试用例的测试的内容，它们都将变的很重要。因此只需要：
I) 把你所有功能性验证（或基本路径（Happy Path））的测试标注为高优先级别
II) 把你所有错误和边界值或确认测试标注为中优先级别
III)把你所有非功能性的测试（例如性能和可用性）标注为低优先级别.
2)提升和降级：
并非所有的功能性测试都一样的重要，并且和边界和非功能性测试一样的重要。思考一下测试的重要性及相对于其他同等优先级别的测试，你想要检查这个功能的频率－考虑质量目标和你项目的需求。
I) 把功能性验证测试分为两组：重要和不是十分重要。
II) 将“不是十分重要”的能性验证测试降级为中优先级别
III)把错误和边界测试分成两组：重要和不是十分重要
IV)将“重要”的错误和边界测试升级为高优先级别
V)把非功能性测试分成两组：重要和不是十分重要
VI)把“重要”的非功能性测试升级为中优先级别
VII) 针对每组高，中和低优先级别的测试用例，重复划分和升级/降级流程直到你达到一个点，可以在不同优先级别之间移动的测试用例的数量到最小。
3)识别小版本验证测试用例（Build Verification Tests）：
现在，为了确保小版本是可以测试的并准备好给小组其他成员开始测试，哪些测试用例是必须在每个小版本中都检查呢？
I) 将好优先级别的测试用例分成两组：严重和重要的
II) 将“严重”的高优先级的测试用例升级为BVT优先级
注意：不要先识别BVT测试用例！BVT只是高优先级别测试用例的精选，它们已经被确定为对系统和测试是非常重要的。
在这个流程的最后，就是要检查优先级别的百分比分布情况是：BVT为10-15%，高为20-30%,，中为40-60%，低为10-15%。
在升级和降级测试用例时，需要考虑的方面是用户将要求这个功能或功能性的频率是怎样。同样的，对于用户日常的或月尾的活动而言，这种行为的严重性是如何。Robyn Brilliant在测试进度报告中提供了一个清单，你可以在考虑降级或升级测试用例的时候使用
使用从一到五的一个刻度，从最严重到最少的严重程度，量化可靠性风险如下：
I) 这个功能的失败将影响用户。
II) 这个功能的失败将给公司造成重大的影响
III)这个功能的失败将引起一个潜在的延期给客户
IV)这个功能的失败对公司将有较小的影响
V)这个功能的失败没有任何影响
这个和其相似的刻度可以帮助你达到你测试用例优先级别划分的最后一步。
总结
这是一个简化的划分测试用例优先级别过程的例子。然而，在快速组织测试用例和安排测试进度和工作量，及制订项目计划时需要完成哪些测试用例等方面，它可以给你很多帮助。
记住，你怎样给你的测试任务划分优先级和如何执行测试用例将取决于你在你的项目周期的位置。当你朝发布前进并通过调查和观察确定危险和缺陷出现的地方时，你可能会重新给你的测试用例划分优先级别。向上为每个阶段建立你的测试目标并保证他们在你的测试用例的优先级别上被反映，当它在解释并执行你的计划时，将使你的生活变得容易得多。
最后，拥有划分了优先级别的测试用例也为你潜在的，待定的自动化项目给出了一个好的起点。比如，自动化BVT中的测试用例，度量收益，改进测试自动化，自动化高优先级的测试用例等方面。

一、黑盒测试的测试用例设计方法
   1. 等价类划分方法
   2. 边界值分析方法
   3. 错误推测方法
   4. 因果图方法
   5. 判定表驱动分析方法
   6. 正交实验设计方法
   7. 功能图分析方法

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

 

1. 等价类的概念

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

 

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

 

无效等价类：与有效等价类的定义恰巧相反。

 

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

2. 划分等价类的方法

下面给出六条确定等价类的原则：
1) 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
2) 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可确立一个有效等价类和一个无效等价类。
3) 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。
4) 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
5) 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
6) 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

3. 设计测试用例

在确立了等价类后，可建立等价类表，列出所有划分出的等价类：
输入条件有效等价类无效等价类
。。。。。。。。。
。。。。。。。。。
然后从划分出的等价类中按以下三个原则设计测试用例：
1) 为每一个等价类规定一个唯一的编号。
2) 设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步。直到所有的有效等价类都被覆盖为止。
3) 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步。直到所有的无效等价类都被覆盖为止。

三、边界值分析法
边界值分析方法是对等价类划分方法的补充。

 

边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

基于边界值分析方法选择测试用例的原则：
1) 如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。
2) 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一，比最大个数多一的数作为测试数据。
3) 根据规格说明的每个输出条件，使用前面的原则1)。
4) 根据规格说明的每个输出条件，应用前面的原则2)。
5) 如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。
6) 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。
7) 分析规格说明，找出其它可能的边界条件。

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

 

错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。

五、因果图方法
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类，他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图（逻辑模型）。

因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

 

利用因果图生成测试用例的基本步骤：
1) 分析软件规格说明描述中，那些是原因(即输入条件或输入条件的等价类)，那些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。
2) 分析软件规格说明描述中的语义。找出原因与结果之间，原因与原因之间对应的关系。根据这些关系，画出因果图。
3) 由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。
4) 把因果图转换为判定表。
5) 把判定表的每一列拿出来作为依据，设计测试用例。
从因果图生成的测试用例（局部，组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况，构成的测试用例数目达到最少，且测试用例数目随输入数据数目的增加而线性地增加。

 

六、判定表驱动分析方法
前面因果图方法中已经用到了判定表。判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。

判定表通常由四个部分组成。
条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。
动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。
条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。
动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。
规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。

判定表的建立步骤（根据软件规格说明）：
1) 确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有n2种规则。

2) 列出所有的条件桩和动作桩。
3) 填入条件项。
4) 填入动作项。等到初始判定表。
5) 简化。合并相似规则（相同动作）。

Beizer 指出了适合使用判定表设计测试用例的条件：
1) 规格说明以判定表形式给出，或很容易转换成判定表。
2) 条件的排列顺序不会也不影响执行哪些操作。
3) 规则的排列顺序不会也不影响执行哪些操作。
4) 每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
5) 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。

察评定软件的易学易用性，各个功能是否易于完成，软件界面是否友好等方面进行测试，这点在很多类型的管

理类软件中是非常重要的。
通常对易用性有如下定义：易见Easy to discover：单单凭观察，用户就应知道设备的状态，该设备供选择可以

采取的行动。 易学Easy to learn：不通过帮助文件或通过简单的帮助文件，用户就能对一个陌生的产品有清晰

的认识。易用Easy to use：用户不翻阅手册就能使用软件。
对于易用性测试可遵循以下原则：
1、完成相同或相近功能的按钮用Frame 框起来，常用按钮要支持快捷方式。
2、完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3、按功能将界面划分局域块，用Frame 框起来，并要有功能说明或标题。
4、界面要支持键盘自动浏览按钮功能，即按Tab 键的自动切换功能。
5、界面上首先应输入的信息和重要信息的控件在Tab 顺序中应当靠前，位置也应放在窗口上较醒目的位置。
6、同一界面上的控件数最好不要超过10 个，多于10 个时可以考虑使用分页界面显示。
7、分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl Tab
8、默认按钮要支持Enter 操作，即按Enter 后自动执行默认按钮对应操作。
9、可输入控件检测到非法输入后应给出说明信息并能自动获得焦点。
10、Tab 键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
11、复选框和选项框按选择几率的高底而先后排列。
12、复选框和选项框要有默认选项，并支持Tab 选择。
13、选项数相同时多用选项框而不用下拉列表框。
14、界面空间较小时使用下拉框而不用选项框。
15、选项数较少时使用选项框，相反使用下拉列表框。
16、专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
17、对于界面输入重复性高的情况，该界面应全面支持键盘操作，即在不使用鼠标的情况下采用键盘进行操作。
对于易用性测试还可从以下几个方面入手：
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或

在不同的连接页面之间。通过考虑下列问题，可以决定一个应用系统是否易于导航：导航是否直观？系统的主要

部分是否可通过主页存取？系统是否需要站点地图、搜索引擎或其他的导航帮助？ 在一个页面上放太多的信息往

往起到与预期相反的效果。应用系统的用户趋向于目的驱动，很快地扫描一个应用系统，看是否有满足自己需要

的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉应用系统的结构,因此，应用系统导航帮助要

尽可能地准确。导航的另一个重要方面是应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭

直觉就知道应用系统里面是否还有内容，内容在什么地方。应用系统的层次一旦决定，就要着手测试用户导航功

能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个应用系统的图形可

以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。应用系统的图片尺寸要尽

量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验应用系统提供信息的正确性、准确性和相关性。欢迎光临！信息的正确性是指信息是可靠的还

是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否

有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"

功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中

的所谓"相关文章列表"。
4、整体界面测试
整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览应用系统时是否感到舒

适，是否凭直觉就知道要找的信息在什么地方？整个应用系统的设计风格是否一致？ 对整体界面的测试过程，其

实是一个对最终用户进行调查的过程。一般应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反

馈信息。对所有的可用性测试来说，都需要有外部人员（与应用系统开发没有联系或联系很少的人员）的参与，

最好是最终用户的参与。
界面是软件与用户交互的最直接的层面，界面的好坏决定用户对软件的第一印象。而设计优良的界面能够引导用

户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面

能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都

可能在用户的畏惧与放弃中付诸东流。目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，

无论那种风格，以下原则应该得到重视或参考。在测试人员进行测试过程中，也可参考以下原则对产品进行评价

。
1、规范性原则
通常界面设计都按Windows 界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷

菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢

。 规范性细则：
（1）常用菜单要有命令快捷方式。
（2）完成相同或相近功能的菜单用横线隔开放在同一位置。
（3）菜单前的图标能直观的代表要完成的操作。
（4）菜单深度一般要求最多控制在三层以内。
（5）工具栏要求可以根据用户的要求自己选择定制。
（6）相同或相近功能的工具栏放在一起。
（7）工具栏中的每一个按钮要有及时提示信息。
（8）一条工具栏的长度最长不能超出屏幕宽度。
（9）工具栏的图标能直观的代表要完成的操作。
（10）系统常用的工具栏设置默认放置位置。
（11）工具栏太多时可以考虑使用工具厢。
（12）工具厢要具有可增减性，由用户自己根据需求定制。
（13）工具厢的默认总宽度不要超过屏幕宽度的1/5。
（14）状态条要能显示用户切实需要的信息，常用的有：目前的操作、系统状态、用户位置、用户信息、提示信

息、错误信息、使用单位信息及软件开发商信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提

示。
（15）滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
（16）状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
（17）菜单和工具条要有清楚的界限；菜单要求凸出显示，这样在移走工具条时仍有立体感。
（18）菜单和状态条中通常使用5 号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
（19）右键快捷菜单采用与菜单相同的准则。
2、帮助设施原则
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。 帮助设施细则：
（1）帮助文档中的性能介绍与说明要与系统性能配套一致。
（2）打包新系统时，对作了修改的地方在帮助文档中要做相应的修改，做到版本统一。
（3）操作时要提供及时调用系统帮助的功能。常用F1。
（4）在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
（5）最好提供目前流行的联机帮助格式或HTML 帮助格式。
（6）用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
（7）如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
（8）在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
3、合理性原则
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意

利用这两个位置。合理性细则：
(1) 父窗体或主窗体的中心位置应该在对角线焦点附近。
(2) 子窗体位置应该在主窗体的左上角或正中。
(3) 多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
(4) 重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
(5）错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。

(6) 与正在进行的操作无关的按钮应该加以屏蔽。
(7) 对可能造成数据无法恢复的操作必须提供确认信息，给用户放弃选择的机会。
(8) 非法的输入或操作应有足够的提示说明。
(9）对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。 (10)提

示、警告、或错误说明应该清楚、明了、恰当并且应避免英文提示的出现。
4、美观与协调性原则
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。 美观与协调性细则：
（1）长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
（2）布局要合理，不宜过于密集，也不能过于空旷，合理的利用空间。
（3）按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
（4）按钮的大小要与界面的大小和空间要协调。
（5）避免空旷的界面上放置很大的按钮。
（6）放置完控件后界面不应有很大的空缺位置。
（7）字体的大小要与界面的大小比例协调，通常使用的字体中宋体9-12 较为美观，很少使用超过12号的字体。

（8）前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows 界

面色调。
（9）如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
（10）大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
（11）界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。 （12）

如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放

。
（13）对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
（14）通常父窗体支持缩放时，子窗体没有必要缩放。
（15）如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
5、菜单位置原则
菜单是界面上最重要的元素，菜单位置按照按功能来组织。菜单设置细则：
（1）菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows 风格。
（2）常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍

。
（3）下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
（4）一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
（5）没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头，不常用的靠后放置；重要的放在开头，

次要的放在后边。
（6）如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
（7）菜单深度一般要求最多控制在三层以内。
（8）对常用的菜单要有快捷命令方式，组合原则见7。
（9）对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式—即只有需要的菜单才显示—

最好。
（10）菜单前的图标不宜太大，与字高保持一直最好。
（11）主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
（12）主菜单数目不应太多，最好为单排布置。
6、独特性原则
如果一味的遵循业界的界面标准，则会丧失自己的个性。在框架符合以上规范的情况下，设计具有自己独特风格

的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。 独特性细则：
（1）安装界面上应有单位介绍或产品介绍，并有自己的图标或徽标。
（2）主界面，最好是大多数界面上要有公司图标或徽标。
（3）登录界面上要有本产品的标志，同时包含公司图标或徽标。
（4）帮助菜单的“关于”中应有版权和产品信息。
（5）公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应

该大体一致。
（6）应为产品制作特有的图标并区别于公司图标或徽标
7、快捷方式的组合原则
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些，在西文Windows 及其应用软件中快捷键

的使用大多是一致的。菜单中：
（1）面向事务的组合有：Ctrl-D 删除；Ctrl-F 寻找；Ctrl –H 替换；Ctrl-I 插入；Ctrl-N 新记录；Ctrl-S

保存Ctrl-O 打开。
（2）列表：Ctrl-R ，Ctrl-G 定位；Ctrl-Tab 下一分页窗口或反序浏览同一页面控件。
（3）编辑：Ctrl-A 全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z 撤消操作；Ctrl-Y 恢复操作。
（4）文件操作：Ctrl-P 打印；Ctrl-W 关闭。
（5）系统菜单：Alt-A 文件；Alt-E 编辑；Alt-T 工具；Alt－W 窗口；Alt－H 帮助。
（6）MS Windows 保留键：Ctrl-Esc 任务列表；Ctrl-F4 关闭窗口；Alt-F4 结束应用；Alt-Tab 下一应用；

Enter 缺省按钮/确认操作；Esc取消按钮/取消操作；Shift-F1 上下文相关帮助。
按钮中:可以根据系统需要而调节，以下只是常用的组合。
Alt-Y 确定(是）；Alt-C 取消；Alt-N 否；Alt-D 删除；Alt-Q 退出；Alt-A 添加；Alt-E 编辑；Alt-B 浏览；

Alt-R 读；Alt-W 写。这些快捷键也可以作为开发中文应用软件的标准，但亦可使用汉语拼音的开头字母。
8、排错性考虑原则
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地

考虑到各种可能发生的问题，使出错的可能降至最小。如应用出现保护性错误而退出系统，这种错误最容易使用

户对软件失去信心。因为这意味着用户要中断思路，并费时费力地重新登录，而且已进行的操作也会因没有存盘

而全部丢失。排错性细则：
（1）最重要的是排除可能会使应用非正常中止的错误。
（2）应当注意尽可能避免用户无意录入无效的数据。
（3）采用相关控件限制用户输入值的种类。
（4）当用户作出选择的可能性只有两个时，可以采用单选框。
（5）当选择的可能再多一些时，可以采用复选框，每一种选择都是有效的，用户不可能输入任何一种无效的选择

。
（6）当选项特别多时，可以采用列表框，下拉式列表框。
（7）在一个应用系统中，开发者应当避免用户作出未经授权或没有意义的操作。
（8）对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
（9）对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
（10）对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
（11）对错误操作最好支持可逆性处理，如取消系列操作。
（12）在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
（13）对可能造成等待时间较长的操作应该提供取消功能。
（14）特殊字符常有；；’”&gt;&lt;，｀‘：“［”｛、\|｝］ ="）-(_*&&^%$#@! ，。?/还有空格。
（15）与系统采用的保留字符冲突的要加以限制。
（16）在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
（17）有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
9、多窗口的应用与系统资源原则
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
（1）在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其

他窗口来显示该窗口。
（2）在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS 系统资源。
（3）关闭所有窗体，系统退出后要释放所占的所有系统资源，除非是需要后台运行的系统。
（4）尽量防止对系统的独占使用。

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。


　　经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”

　　分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”

　　经理觉得奇怪：“我不是刚告诉你我的需求了吗？”

　　分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”

　　经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”

　　分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”

　　经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”

风险躲在需求的迷雾之后

　　以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。

拨开需求分析的迷雾

　　像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：

　　·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

　　·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

　　·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

　　·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

　　·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。

　　前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。

　　下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。

　　经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。

　　在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。

　　优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。

　　由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。

客户的需求观

　　客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。

1、 分析人员要使用符合客户语言习惯的表达

　　需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。

2、分析人员要了解客户的业务及目标

　　只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。

3、 分析人员必须编写软件需求报告

　　分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、 要求得到需求工作结果的解释说明

　　分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5、 开发人员要尊重客户的意见

　　如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。

6、 开发人员要对需求及产品实施提出建议和解决方案

　　通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。

作词:何启弘 作曲:陈忠义 编曲:屠颖 制作人:张信哲/李汉群

高脚杯里 你的唇印 盖上冷漠刺青 是一张心碎证明
 
冷风过境 扫进心底 痛苦无力防御 手一摊就被占据

脱罪的话你可以说了千遍还不腻

听到的和感觉到的有差距

放过自己 放过压抑 放过整天附身的记忆

往事痛击 孤单侵袭 习惯就可以

感情的戏 我没演技 赢不了你温柔挑衅

只好丢弃 只好不回应 用沉默反击

逃生的路会在哪里 我要自由 不要窒息

曾经以为你就是氧气 原来只是闹剧

爱过一场输个彻底!

(原来歌词也很重要,一直以为旋律才是关键.很久前曾听一个人说过王菲唱的<<红豆>>的歌词写的何等的入木三分,当时只觉得很好听,写得是什么听不懂,渐渐发现身边有很多朋友关注歌词,有位友人说过王菲的**(不记得了)歌词写出了一个女人怎样释然的心怀,以前和一个同事一起捉弄另一个同事,笑她听不懂张学友的<<她来听我的演唱会>>,因为觉得她个性十分可爱,对这样忧伤的情歌没什么领悟!看懂一首歌,想必有些相似的经历或者其他...)

一点所思：现在越来越感觉古人的一些言论是多么的博大精深，“旁观者清、当局者迷”也许用在爱情中不太合适，但是专家、家人、过来人、朋友可能比当局者的人们更容易看清许多。。。
 感情可以培养出来，但是爱情是培养不出来的！（个人观点）

时间可以改变一切！这话不假，但是放在爱情里，你就得掂量掂量。如果你现在正在试图改变你们尴尬的局面，以下8种情况供你参考。没有结果的爱，该放手还是尽快吧。

　　一、你在乎对方比较多

　　你在谈恋爱，却不确定对方的想法;你觉得你们很合适，他好像不以为然;他不在

　　“二人若不同心，岂能同行呢?”有时候会有一方爱另一方较多的情形，若是在健全的感情中，会有交替的现象，两人轮流扮演追求和被追求的角色;但如果有一方总是扮演追求者，这样的感情不健全，长久下去，你会对爱饥渴，你会觉得受对方控制，你会感到愤怒、受骗、痛苦。

　　二、你爱的是对方的潜力

　　你爱的是对方的潜力，而不是对方真正的样子，你爱的是对方未来可能的样子，那他根本不是你的伴侣，而是你改造的对象。

　　我们每次作婚前辅导都会问，如果对方五十年内都不会改变，你会满意吗?如果你一直希望能改变对方，才觉得比较满意，那就不是爱，而是赌博，用双方的快乐当作赌注。

　　你跟一个人交往时，要爱和尊重对方的本相，而不是他未来的样子，你可以期望他继续成长，但你必须满意他现在的样子。

　　三、你想要帮助对方

　　你常觉得对方很可怜吗?你觉得自己有责任帮助对方振作起来吗?你会不会害怕如果离开对方，他会受不了打击?如果是，你恐怕是个“救难狂”。

　　“救难狂”不会去找一个合适的对象，而是找一个他所同情、可以帮助的对象。找一个受过创伤、脆弱、依赖、不被爱、委屈的人，你由怜生爱，他会对你心生感激，这样的感情像是一项救援任务，而不是健全、平衡的感情。

　　这里要牢记的关键是“尊重”，你爱的对象必须是你能够尊重的人，你必须以对方为荣，你的伴侣不要你的救援，而是要你真正了解他。

 

　　四、把对方当作崇拜的对象

　　年轻的女明星爱上导演、大学生爱上教授、秘书爱上老板……，爱上所崇拜的对象，这种感情很难维持正常，因为两人之间无法平等对待。

　　男女双方必须要平等对待，我不是指地位，而是态度，不能过度崇拜对方。会爱上所崇拜对象的人，通常自信心低落，他们觉得自己很糟糕。

　　五、你只是被对方外表吸引

　　每个人都会这样，对吗?如果你发现自己被对方的某个特质深深吸引，要问自己，若对方没有那双蓝色的大眼睛、磁性的声音……，若对方不是模特儿、不会打篮球……，我还会跟他(她)在一起吗?男人外表才是第一生产力。

　　六、短暂朝夕相处的机会

　　你和对方分担某个工作，常常要一起加班，于是你觉得爱上了对方……。你去度假三周，认识一个也来度假的男人，你觉得好象坠入情网……。短暂的朝夕相处，是指在特殊情况下凑在一块，并不是常规，这种感情不能持久，因为短时间的朝夕相处，无法使你完全了解对方的个性。

 

　　七、为了叛逆才选择这对象

　　父母老是跟你强调，要找个有钱的对象，偏偏你每个男朋友都是穷光蛋;从小父母就对你管教严格，偏偏你每个女朋友都很随便;从小父亲就耳提面命，传香火是最重要的事，偏偏你的女朋友不是不能生，就是不想生……

　　如果你所选的对象，老是令父母生气，很可能你只是想叛逆，你觉得一定要证明什么来反击，当你不能控制自己的选择，你并不是真心爱对方，这段感情注定没有结果。

　　
    八、对方不是自由身

　　我把这点留到最后，是因为这根本不能算是感情。选择终身伴侣的第一个前提是——对方是“自由身”。“自由身”就是可以自由和你交往，没有结婚、没有订婚、没有固定的交往对象、没有和别人上床、单身，只和你交往的人。

　　如果你爱上的那个男人答应会早点和另一个女人分手;或是他说他不爱那个女人，他爱的是你;或是他原来的对象接受你的存在，他们不打算分手，但他想跟你在一起一阵子;或是他刚分手，但可能破镜重圆……，这些都不是自由身。

　　别和已婚或有对象的人交往，不管是什么借口，结果都一样，你注定要心碎。别忘了，你只是接受了另一个人用剩的部分。

　　选择权在你手上，责任在你身上，你要选对人。如果你有交往的对象，而且你是上面谈到的八种感情之一，去找辅导，别浪费时间，还有更好的对象在等你。
 
 

1.   绪论
1.1. 软件危机和软件生存期
软件开发项目矛盾主要表现在：

  缺乏大型软件开发的经验和软件开发数据的积累，盲目制订开发工作计划；

  开发初期软件需求不够明确，开发开始未能和用户及时交流，问题隐藏；

  开发过程中无开发规范，开发人员间配合、约定不严密明确，文档不完整；

  缺乏严密有效的软件之路检测手段，交付软件质量差，不同程度严重后果。

软件生生存期：

  计划（Planning）

      主要任务：确定软件开发的总目标；

　             给出软件的功能、性能、可靠性以及接口方面的设想；

      输出物：问题解决方案；

　　　　      资源、成本、效益、开发进度的估计；

　　　    　  完成任务的实施计划。

  需求分析（Requirement Analysis）

      主要任务：详细定义开发软件可满足的需求并给予确切描述；

      输出物：软件需求说明书（Software Requirement Specification）或软件规格说明书；

　　　　      初步的用户手册（System User’s Manual）。

  设计（Design）

     主要任务：将已确定的各项需求转换成相应的体系结构，由功能明确的模块组成；

     输出物：概要设计（Preliminary Design）说明书；

　　　　     详细设计（Detail Design）说明书。

  编码（Coding）

       主要任务：将软件设计转换成计算机可接受的程序；

       输出物：源程序清单。

  测试（Testing）保证软件质量的重要手段

       主要任务：检验开发工作的成果是否符合要求；

       三步：单元测试（Unit Testing）；

　　　　  集成测试（Integrated Testing）；

　　　    确认测试（Validation Testing）。

   运行和维护（Run and Maintenance）

       主要任务：已交付用户的软件投入正式使用。

  1.2. 软件测试的意义

广义的测试概念：确认、验证、测试活动

　　　　　　　　（V，V&T-----Validation,Verification and Testing

确认 ≠ 验证

确认：如何决定最后软件产品是否正确无误（开发正确无误的软件产品）

　　　编写出的程序相对于软件需求和用户提出的要求是否符合；

　　　程序输出的信息是用户所要的信息吗？

　　　程序在整个系统的环境中能够正确稳定的运行吗？

　　　开发初期，在软件需求规格说明书中明确规定确认的标准。

验证：如何决定软件开发的每个阶段、每个步骤的产品是否正确无误，并且与开发阶段和开发步骤的产品相一致（开发的软件产品是否正确无误）

　　　　　确保软件能够正确无误地实现软件的需求

　　　　　开发过程中开展的一系列活动，确保软件能够正确无误地实现软件的需求。

　　确认+与开发阶段、开发步骤的产品一致＝验证

 软件生存期各阶段中确认、验证与测试活动包括：

 需求分析阶段

任务：制定V,V&T计划；

　　　确定V,V&T目标；

　　　安排V,V&T活动；

　　　选择采用的方法和工具；

　　　制定进度并做出预算。

     产物：基础的测试用例

     复审：需求的确保

 概要设计阶段

    任务：复审修订V,V&T计划；

    产物：针对要执行的逻辑功能生成测试数据；

　　　　　补充软件需求。

   复审：确保内部的一致性、完全性、正确性、清晰性；

　　　　　检验已进行的设计是否满足需求。

 详细设计阶段

    任务：设计功能测试数据；

    复审：确保内部的一致性、完全性、正确性、清晰性；

    检验详细设计是否对概要设计作出了正确无误的细化；

　　确认所做的设计满足需求。

  编码与测试阶段

     任务：完成测试用例规格说明；

     复审：是否遵循编码标准；

  自动或手工分析程序；

　　　运行测试用例，以保满足验收要求；

　　　产品验收。

   运行与维护阶段

      任务：软件评估；

　　　 软件修改评估；

　　　 回归测试。

1.3. 什么是软件测试

定义：使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

 相信绝大多数用户在使用电脑的过程中都会发现电脑越用越慢，而其中的大部分人会抱着“慢就慢点儿吧”的心理继续使用，殊不知这样一来弊端会越积累越多，最后导致更严重的问题发生，下面我们就简单的来看一下几种常见的电脑变慢的原因和解决办法，希望给广大用户一些提示。


　　1> 在开机时加载太多程序
　　电脑在启动的过程中，除了会启动相应的驱动程序外，还会启动一些应用软件，这些应用软件我们称为随即启动程序。随机启动程序不但拖慢开机时的速度，而且更快地消耗计算机资源以及内存，一般来说，如果想删除随机启动程序，可去“启动”清单中删除，但如果想详细些，例如是QQ、msn之类的软件，是不能在“启动”清单中删除的，要去“附属应用程序”，然后去“系统工具”，再去“系统信息”，进去后，按上方工具列的“工具”，再按“系统组态编辑程序”，进去后，在“启动”的对话框中，就会详细列出在启动电脑时加载的随机启动程序了!XP系统你也可以在“运行”是输入Msconfig调用“系统配置实用程序”才终止系统随机启动程序，2000系统需要从XP中复制msconfig程序。


　　2> 桌面图标太多会惹祸
　　桌面上有太多图标也会降低系统启动速度。很多用户都希光将各种软件或者游戏的快捷方式放在桌面上，使用时十分方便，其实这样一来会使得系统启动变慢很多。由于windows每次启动并显示桌面时，都需要逐个查找桌面快捷方式的图标并加载它们，图标越多，所花费的时间当然就越多。同时有些杀毒软件提供了系统启动扫描功能，这将会耗费非常多的时间，其实如果你已经打开了杀毒软件的实时监视功能，那么启动时扫描系统就显得有些多余，还是将这项功能禁止吧! 建议大家将不常用的桌面图标放到一个专门的文件夹中或者干脆删除!


　　3>把windows变得更苗条
　　与DOS系统相比，Windows过于庞大，而且随着你每天的操作，安装新软件、加载运行库、添加新游戏以及浏览网页等等使得它变得更加庞大，而更为重要的是变大的不仅仅是它的目录，还有它的注册表和运行库。因为即使删除了某个程序，可是它使用的DLL文件仍然会存在，因而随着使用日久，Windows的启动和退出时需要加载的DLL动态链接库文件越来越大，自然系统运行速度也就越来越慢了。这时我们就需要使用一些彻底删除DLL的程序，它们可以使Windows恢复苗条的身材。建议极品玩家们最好每隔两个月就重新安装一遍windows，这很有效。


　　4>桌面上不要摆放桌布和关闭activedesktop
　　不知大家有否留意到，我们平时一直摆放在桌面的壁纸，其实是很浪费计算机资源的!不但如此，而且还拖慢计算机在执行应用程序时的速度!本想美化桌面，但又拖慢计算机的速度，在这时，你是否会有一种"不知怎样"的感觉呢?还有一点，不知大家有否试过，就是当开启壁纸时，每逢关闭一个放到最大的窗口时，窗口总是会由上而下、慢慢、慢慢地落，如果有这种情况出现，你必须关闭壁纸!方法是:在桌面上按鼠标右键，再按内容，然后在“背景”的对话框中，选“无”，建议在“外观”的对话框中，在桌面预设的青绿色，改为黑色……至于关闭activedesktop，即关闭从桌面上的Web画面，例如在桌面上按鼠标右键，再按内容，然后在“背景”的对话框中，有一幅壁纸布，名为windows98，那副就是Web画面了!


　　5> 删除一些不必要的字体
　　系统运行得慢的其中一个原因，就是字体多少的关系。安装的字体越多，就占用越多的内存，从而拖慢计算机的速度!所以我们要删除一些不必要的字体。要删除一些不必要的字型，你可到控制面板，再进去一个叫“字体”的文件夹，便可删除字体，但是要怎样才知道，那些字体有用，那些字体没用呢?例如:如果你不常到ms_dos模式的话，就删除dos 字体!因为各个人都可能喜爱某种字型，所以我也不能确定要删除那些字体，不过在这里有个秘决教你，如果你有华康粗黑字型，且又有新细明体的字型，建议你删除华康粗黑字型，如果你有新细明体，且又有细明体，就删除细明体吧!


　　6>设定虚拟内存
　　硬盘中有一个很宠大的数据交换文件，它是系统预留给虚拟内存作暂存的地方，很多应用程序都经常会使用到，所以系统需要经常对主存储器作大量的数据存取，因此存取这个档案的速度便构成影响计算机快慢的非常重要因素!一般win98预设的是由系统自行管理虚拟内存，它会因应不同程序所需而自 动调校交换档的大小，但这样的变大缩小会给系统带来额外的负担，令系统运作变慢!有见及此，用家最好自定虚拟内存的最小值和最大值，避免经常变换大小。要设定虚拟内存，在“我的电脑”中按右键，再按内容，到“性能”的对话框中，按“虚拟内存”，然后选择"让自已设定虚拟内存设定值"，设定"最小值"为64，因为我的计算机是32mbram，所以我就设定为64，即是说，如果你的内存是64mbram，那在"最小值"中，就设为128。顺带一提，在"效能"的对话框中，选择"档案"，将原先设定的" 桌上型计算机"，改为"网络服务器"，是会加快系统运作的;还有，在"磁盘"的对话框中，不要选"每次开机都搜寻新的磁盘驱动器"，是会加快开机速度的!


　　7>彻底删除程序
　　大家都知道，如果想移除某些程序，可到"添加/删除程序"中移除，但大家又知不知道，它只会帮你移除程序，而不会帮你移除该程序的注册码和一些登录项目呢?这不是win98蠢，而是它在这方面不够专业，要彻底删除程序，要找回些“专业”删除软件来移除才成事!先前symantec公司出品的nortonuninstall(以下简称为nud)，因为有某部份破坏了某些删除软件的版权，故此全世界已停止出售，正因如此，symantec才出了cleansweep(以下简称为cs)，不过论功能上，还是nud更胜一寿!言归正传，其实除了这两个软件外，还有很多同类软件都能有效地移除程序，既然nud已绝版，那我就说cs吧。下载并安装后，如果你想移除程序，只要用cs来移除，它便会一拼移除该程序的登录项目和注册码!

1. 猪肉*菱角——肚子痛
2. 牛肉*栗子——引起呕吐
3. 羊肉*西瓜——伤元气
4. 狗肉*绿豆——会中毒
5. 兔肉*芹菜——脱发
6. 鸡肉*芹菜——伤元气
7. 鹅肉*鸡蛋——伤元气
8. 甲鱼*苋菜——会中毒
9. 鲤鱼*甘草——会中毒
10. 螃蟹*柿子——腹泻
11.白酒*柿子——会胸闷
12. 红薯*柿子——会得结石
13. 糖精（片）*鸡蛋——会中毒、重则死亡
14. 红塘*皮蛋——会中毒
15. 洋葱*蜂蜜——伤眼睛
16. 豆腐*蜂蜜——耳聋
17. 萝卜*木耳——得皮炎
18. 马铃薯*香蕉——面部生斑
19. 芋头*香蕉——腹涨
20. 花生*黄瓜——会伤身

QuickTest Pro 8.2 下载地址:
http://lib.verycd.com/2005/09/19/0000065551.html

LoadRunner 8.0下载地址：http://lib.verycd.com/2005/10/01/0000067173.html

LoadRunner 8.1下载地址http://blog.51testing.com/?48942/action_viewspace_itemid_2673.html

【摘要】 软件测试从哪里开始到哪里结束？中间要经过哪些环节以及各环节要注意哪些事项。本文就有关问题结合个人实际工作经验进行阐述，鉴于每个环节都可以做为一个专题来进行探讨，所以受篇幅和时间限制，本文对有关问题未做深入剖析，只做一个宏观上的介绍。

【关键词】测试流程、需求分析、测试用例、测试计划、缺陷管理

 

一、概述

 

一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：

需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

 

在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

说明：

1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

 

2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程中也要做到具体问题具体分析，具体解决。

 

二、测试流程

 

 

    

需求分析

 

需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。

可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！

 

一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

 

其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

 

既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。

 

总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

 

测试计划

  

测试计划（Test Plan）一般由测试负责人来编写。

 

   测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

 

1．  测试背景

a.       软件项目介绍；

b.       项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2．  测试依据

a.       软件需求文档；

b.       软件规格书；

c.       软件设计文档；

d.       其他，如参考产品等。

3．  测试资源

a.       测试设备需求；

b.       测试人员需求；

c.       测试环境需求；

d.       其他。

4．  测试策略

a.       采取测试方法；

b.       搭建哪些测试环境；

c.       采取哪些测试工具以测试管理工具；

d.       对测试人员进行培训等。

5．  测试日程

a.       测试需求分析；

b.       测试用例编写；

c.       测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．  其他。

 

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。

 

测试设计

 

测试设计主要包括测试用例编写和测试场景设计两方面。

 

一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

 

测试场景设计主要也就是测试环境问题了。

 

测试环境搭建

 

不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。

 

测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。

 

为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。

 

测试执行

   　

测试执行过程又可以分为以下阶段：

 

单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

 

从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？

 

从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：

1．  当测试人员测试的执行不到位、敷衍了事时该如何解决？

2．  测试效率问题，怎样提高测试效率？

3．  根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？

4．  当测试过程中遇到一些偶然性随机问题该怎样处理？

5．  当版本中出现很多新问题时该怎样对待？测试停止标准？

6．  ……

总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。

 

测试记录

 

缺陷记录总的说来包括两方面：由谁提交和缺陷描述。

 

一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。

 

在缺陷的描述上，至少要包括以下一些方面内容：

序号

标题

预置条件

操作步骤

预期结果

实际结果

注释

严重程度

概率

版本

测试者

测试日期

 

以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等。

 

另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。

 

缺陷管理

 

缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有Test Director、Bugfree等。

 

下图是一个bug从提出到close所经过的一些流程，其他比如keep No action\keep spec等一些状态流程都未包含在内，在此仅做示范说明。

 

 

注：软件缺陷和bug两者在含义上有着细微差别，本文统称缺陷。

 

软件评估

 

这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。

 

测试总结

 

每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。

 

测试维护

 

   由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。

1、 从测试功能上分
（1） 单元测试 : 针对不同语言，如JUNIT
（2） 功级测试
E—Test：功能强大，由于不是采用POST URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持），基本上可以应付大部分的WEB SITE。
MI公司的WINRUNNER
COMPUWARE的QARUN
RATIONAL的SQA ROBOT
（3） 压力测试
MI公司的WINLOAD
COMPUWARE的QALOAD
RATIONAL的SQA LOAD
（4） 负载测试
LOADRUNNER
RATIONAL VISUAL QUANTIFY
（5） WEB测试工具
MI公司的ASTRA系列
RSW公司的E—TEST SUITE等
（6） WEB系统测试工具
WORKBENCH
WEB APPLICATION STRESS TOOL（WAS）
（7） 数据库测试工具
TESTBYTES
（8） 回归测试工具
RATIONAL TEAM TEST
WINRUNNER
（9） 嵌入式测试工具
ATTOLTESTWARE。是ATTOLTESTWARE公司的自动生成测试代码的软件测试工具，特别适用于嵌入式实时应用软件单元和通信系统测试。
CODETEST是AppliedMicrosystemsCorp.公司的产品,是广泛应用的嵌入式软件在线测试工具。
GammaRay。GammaRay系列产品主要包括软件逻辑分析仪GammaProfiler、可靠性评测工具GammaRET等。
LogiScope是TeleLogic公司的工具套件，用于代码分析、软件测试、覆盖测试。
LynxInsure++是LynxREAL-TIMESYSTEMS公司的产品，基于LynxOS的应用代码检测与分析测试工具。
MessageMaster是ElviorLtd.公司的产品，测试嵌入式软件系统工具，向环境提供基于消息的接口。
VectorCast是VectorSoftware.Inc公司的产品。由6个集成的部件组成，自动生成测试代码，为主机和嵌入式环境构造可执行的测试架构。
（10） 系统性能测试工具
Rational Performance
（11） 页面链接测试
Link Sleuth
（12） 测试流程管理工具
Test Plan Control
（13） 测试管理工具
TestDirector 　　　　　　　　微创tcm
Rational公司的Test Manager
Compuware公司的QADirector
TestExpert：是Silicon Valley Networks公司产品的测试管理工具，能管理整个测试过程，从测试计划、测试例程、测试执行到测试报告。
（14） 缺陷跟踪工具
TrackRecord等
（15） 其他测试工具包
TestVectorGenerationSystem是T—VECTechnologies公司的产品。提供自动模型分析、测试生成、测试覆盖分析和测试执行的完整工具包，具有方便的用户接口和完备的文档支持。
TestQuestPro是TestQuest公司的非插入码式的自动操纵测试工具，提供一种高效的自动检测目标系统，获取其输出性能的测试方法。
TestWorks是SoftwareResearch.Inc公司的一整套软件测试工具，既可单独使用，也可捆绑销售使用。
2、 从测试的方法上分：
（1） 白盒测试工具
白盒测试工主要有：Numega、PuRe、软件纠错工具（Rational Purify）。
内存资源泄漏检查：
Numega中的BounceChecher
Rational的 Purify等
代码覆盖率检查：
Numega的TrueCoverage
Rational的PureCoverage
TeleLogic公司的LogiScope
Macabe公司的Macabe
代码性能检查：
Numega的TrueTime
Rational的Quantify等
代码静态度量分析度量检查工具：LogiScope和Macabe等
黑盒测试工具主要有：QACenter、SQATeamTest、Rational Visual Visual Test。
QACenter：QACenter帮助所有测试人员创建一个快速、可重用的测试过程。这些测试工具自动帮助管理测试过程、快速分析和调试程序，包括针对回归、强度、单元、并发、集成、移植，容量和负载建立测试用例，自动执行测试和产生文档结果。QACenter主要包括以下几个模块：
QARun：应用的功能测试工具。
QALoad：强负载下应用的性能测试工具。
QADirector：测试的组织设计和创建以及管理工具。
TrackRecord：集成的缺陷跟踪管理工具。
EcoTools：高层次的性能监测工具。