2007年测试经验总结之测试需求和测试用例

2007年测试经验总结51Testing软件测试网e)[|&x)JD/Ay)}

测试需求和测试用例51Testing软件测试网}S!Jp9j7z;Dv0p.o

 51Testing软件测试网*u0YF E9p$A~g

前言：2007年已经过去了，感觉有必要把2007年中每天日志中记录的测试经验进行下整理，于是产生了“2007年测试经验总结”日志系列，里面的内容基本上都是在日复一日的工作中体会到的，编写的主要目的也是方便自己的经验积累，反复的推敲和深入。51Testing软件测试网-h4qA,~*b,M

一．测试需求51Testing软件测试网 Wc1IQ%bf oB

1． 什么是测试需求？

测试需求就是指明哪些需要测试（哪些正确的规则下产生的正确结果是什么？这些规则包括：有效等价类的规则、算法的规则、可配置的规则、其他的限定条件、数值范围。这些规则点有部分是从需求文档中获得的，另外有部分是从代码或开发人员口中获取的，剩下的是被人们遗漏的或不明确或常识性的规则而被测试人员发现的。），颗粒程度为刚好能运用测试方法设计出对应的测试用例即可。所以，除了需求文档，还有设计中的一些规则也是需要测试的。但是设计规则要从开发文档中去寻找，如果没有，则我会从源代码注释中去挖掘设计上的测试需求（还有测试用例）。需求文档中写的每一句话并不是都可以成为测试需求，有些需求不需要测试（比如说设计模式已经满足了，或者是显而易见的界面需求，或者是以前就拥有的功能）。总之，测试需求主要来源于两个方面：用户需求、开发文档（或代码注释或从代码中挖掘）51Testing软件测试网9@$s;Z \&?Y\

 51Testing软件测试网S*e&q&lV6y-b1Y

2． 测试需求和测试用例的区别51Testing软件测试网d%Ov.K?m-wX8[

测试需求，以前我把它称之为规则点（还有人称之为测试点），测试需求和测试用例的区别在于，测试用例的设计就是在每个测试需求的基础上运用各种测试方法得出的。也就是说测试需求说明业务或设计中每个最小功能点（小到不能再细分为止）的每条规则要求，而测试用例则包括了符合或不符合这条规则的多种情况，一般来说，一个测试需求对应一个或多个测试用例，而每个测试用例有一条或多条测试数据。（注：像业务流程类的大功能，无法再细分成没有关系的更小的功能点，所以，业务流程的分支条件和其对应的流程处理逻辑规则就是测试需求了。）51Testing软件测试网?+t(h"DSK_H

 51Testing软件测试网z5u)p|-ub)G

3．测试需求、测试用例和测试策略的关系51Testing软件测试网k/B Q,Vb;sKCMN

测试需求是指明“测什么”，而测试用例则是指明“怎么测”。测试策略是一个大体的“测什么”和“怎么测”的框架，采用什么测试方法来回答“测什么”和“怎么测”。而测试需求和测试用例是将测试策略更细分了。测试一个任务时，一定要明确三个要素：“测什么”，“设计是如何实现的”，“怎么测”。51Testing软件测试网Vg'JS'WLC&K

4。其他51Testing软件测试网g&r1X1Uf

开发人员如果有心的话，会给你测试建议和测试范围，但是我们自己在设计测试用例的时候，一定要大于他们提供的范围，特别是测试需求一定要弄清楚。51Testing软件测试网 aw!PKt%OyC

 51Testing软件测试网
eB)G8Xvfz bMI

二．测试用例的设计和执行

1． 明确测试用例的输入和输出，不仅仅关注界面上的输入和输出。

相对与被测试的模块来说，除了界面上的输入和输出（键盘、鼠标、屏幕），还有文件、共享内存、网络上的输入和输出，这些都是，而且有很多严重BUG的发现都和这些界面上看不到的输入输出有关系（经验告诉我）。所以，我自己总结的测试用例一般包括四个元素：输入（或动作）、输出、参数、状态。参数和状态是指一些系统内部数据的输入，参数就例如某个配置项例如某个配置条件，状态就例如数据库中的某表中的相关数据。

输入、状态、参数、操作四者有的时候不容区分开来，但问题不是很大，将影响被测模块功能实现的输入和输出都考虑到就OK。51Testing软件测试网\2P
E8s,}1o

 51Testing软件测试网w;Z7S)|EQ_q

2． 根据程序的设计，去除多余或冗余的测试用例和测试数据51Testing软件测试网mB3[VZ*sC

我在设计和执行测试用例时，总是不断的思考着：哪些测试数据是多余的，一定不会有问题，哪些测试数据很有可能发现BUG，一定要执行，哪些测试数据和前面执行的测试数据并没有本质区别，经过的代码是一样的（也就是等价类），也不需要执行测试。到底是多余（没有覆盖到但一定不会出错）还是冗余（已经有等价的测试用例覆盖到），我会根据具体的代码实现而确定（暂时没办法总结，是种经验），如果不能确定是多余或冗余，就一定要执行测试。在回归测试过程中，这种方法更为重要，因为再一次测试时，你对所测系统更熟悉了，知道哪些测试用例是多余或冗余，不需要每个测试用例都执行一遍。总之，测试的原则是，以找出软件中的所有重要的缺陷为目的，要用最少的时间和最有效的测试用例去发现缺陷。

有的时候，某些测试用例要执行后才知道是不是冗余或多余，所以，在不确定的情况下，就要把它们列入测试用例范围。51Testing软件测试网1wQT/W1|j.C#G| m

3． 测试用例设计的时机

按照规范的流程走，需求规格说明书完成后,只能进行大概的测试需求分类,概要设计说明书完成后,可以进行测试需求的编写了,详细设计说明书完成后,可以进行测试用例的编写.至于可测试性的工作,从概要设计说明书完成后可以进行.

但在进行某个维护版本的测试时，我个人觉得还是在执行测试的时候编写测试用例比较好，当然会先编写再执行的，在测试版本提交之前，先把测试范围和测试需求整理好就可以了。因为我觉得测试用例的设计是需要参考详细说明书来设计的，如果没有详细说明书，很难写出完善（不完整是肯定的）的测试用例，对测试输出数据的准确性把握也不大，就连测试需求也需要补充。在理解设计的基础上，才好设计出针对性的测试用例，去发现设计上的问题。这个阶段应该想好测试的范围、重点和需求。在测试版本提交之后设计测试用例，测试的效率也会提高很多，在测试版本提交之前可以去做别的重要的事情。51Testing软件测试网h}8V'c Uc'`

 51Testing软件测试网d.v(G LBD9U J1{

4． 维护版本的测试，在没有需求和设计文档的情况下，如何编写测试用例？

在版本已经提交后，想要了解每个后台进程所做的事情，首先从系统设计文档中了解主要是什么作用，如果不够详细，则去查看源代码文件，因为基本源代码文件都有注释信息。51Testing软件测试网7NP.\&Y
O6x/[y

如果是某个测试需求的改动，先把功能点找出来，在寻找该功能点的测试需求，然后对所有有影响的测试需求进行测试。测试需求一定要从以前的文档或代码中挖掘，如果又没文档又看不到代码，测试质量将无法保证。

 51Testing软件测试网g'L#r'g
R JS~

5． 对测试用例进行优先级的分类

按照黑盒测试用例的设计方法，可以设计出非常非常多的测试数据来，但测试时间一般非常少，想要进行全面的测试是不现实的，一定会有所取舍，所以需要在范围（包括修改范围和影响范围）、重点（对用户来说什么是最重要的）、风险（如果出了问题，后果是很严重的，一般来说也是重点）、时间（测试时间和开发人员修改时间）四者之间进行权衡，得出最合适的测试用例。从测试用例设计的方法出发，根据优先级别的高低进行测试用例的设计和执行。优先级别高的包括：等价类测试用例、边界值分析、错误推断。优先级别较低的包括：非等价类测试用力、界面测试、程序内部其它重要逻辑覆盖及边界值分析、性能测试、其他测试方法等。51Testing软件测试网Kt*d~Gw*l

在执行测试用例的时候，执行顺序有讲究，先从优先级别高的用例开始执行，发现设计上的问题，然后再是从输入框中的数据边界和错误考虑，实际上输入框中的数据边界和错误测试数据也要看该功能的设计本身是否会受到很严重的影响来判断该类测试用例的重要性和优先级别。有些输入框处即使出了异常，对该功能的实现也不可能产生严重级别高的缺陷，这时候这类测试用例的重要性是非常低的。但是，如果像互联网类的应用程序，面向的用户群非常多，各种输入情况都有可能发现，选择最有可能出现严重缺陷的输入测试异常数据来进行测试，这类测试用例的重要性就非常高了。总之，输入数据的异常设计要根据功能实现本身来决定重要性和优先级，目的只有一个，尽早发现严重级别高的缺陷。

测试的优先级无论在什么情况下都需要明确的，这里的优先级是指哪部分测试内容需要最早测试，记得有一次接到的测试任务，有3个功能点需要修改，其中有一个测试过程很简单，整理环境的时间较长，最重要的是它的优先级高，因为开发人员认为这个功能没有问题，是客户的配置有问题，他并没有修改就直接交给我测试了，但是在我看来，如果测试完后发现是程序问题，开发人员再来修改的话，即使测试时间过长，对开发人员来说时间就被浪费了，所以我认为越早发现这个功能确实有问题，开发人员就能越早去修改，这个测试点的优先级最高（后来，实际结果发现是他的程序有问题，不是客户的环境问题）。

 51Testing软件测试网2y:M[kug

6． 测试中的优先级和重点的区别以及定义51Testing软件测试网;Z HY7ICv

优先级是指优先需要测试到的范围,根据测试类型的不同而划分.测试重点是指需要考虑更全面更深入更仔细测试的地方,根据对用户的重要性和软件设计的复杂性/易出错性而划分.测试优先级别高的不一定是测试重点,但测试重点一定是测试优先级别高的.我个人认为,功能点有优先级和重点;测试需求只有重点(在功能点的测试重点下再次细分重点);测试用例只有优先级(在功能点的优先级下再次细分优先级,优先级别低的某些测试用例需要优先基本高的测试用例执行通过才可进行).51Testing软件测试网ld0`j"p^2q

我自己认为有5个优先级:

最高(冒烟测试的范围)51Testing软件测试网l[ S&j d5g Z;z

偏高(确认测试的范围)

高(系统测试必须覆盖到的测试范围)

偏低(时间非常紧迫，可以不覆盖的测试范围)51Testing软件测试网0N3iGr }M

最低(时间不充足的情况下，可以不覆盖的测试范围)

测试重点级别分为3个:51Testing软件测试网
l4bi]*Sb$`6K []

测试重点(所有测试用例设计方法都需要用上:等价类划分/边界值分析/错误推测法/发散思维/对照程序逻辑)

测试偏重点(测试用例设计包括:等价类划分/边界值分析/错误推测法)51Testing软件测试网K$U)S:fs!M-~sfJ2n L-L

测试非重点(测试用例设计包括:等价类划分/边界值分析)

 51Testing软件测试网LgN
Xx

7． 测试用例记录的好处51Testing软件测试网
r._+K8P`}9u

有一次测试，某个功能点反复的修改，测试用例也跟着修改了3次，考虑的越来越全面，所以并没有感到重复测试的枯燥。而且在和开发人员之间的交流间，又获得了一些信息。所以测试用例也是不断优化的过程，测试是一个持续不断改进的过程。记录测试用例的好处是能看到当时测试时的需求是什么、测试用例是什么、实际结果是什么、修改过什么、修复的过程是什么，这些都是非常重要的记录，做为下次测试的基础和依据。真的是“好记性不如烂笔头”。51Testing软件测试网\W9vu\B2]+L:GQ/Wl

8． 测试时间非常短的情况下，可以不记录测试用例51Testing软件测试网1g2sz"s,t'_
e

测试任务紧急的情况下，就可以考虑不写测试用例了，主要将测试范围和测试需求在脑中整理一下，然后就可以开始执行测试了。测试流程和步骤是一样的，缺少的部分只是测试用例的记录。测试思路和方法并没有减少或改变。

9．测试用例的更新51Testing软件测试网ql+\*cdSV w9q!X

测试功能点是一样的，但是修改内容的不同，将会导致测试用例选择和测试通过标准的不同。

测试用例的版本更新时，最容易被修改的地方应该是测试用例的预期结果和测试通过标准,为了便于维护，测试用例写的粒度就不好把握。而且，测试方法的改变也能将测试用例修改较大，比如说第二次测试时用更快捷的步骤来达到测试目的，这个时候测试步骤就需要大的改动，但测试目的和预期结果可能没有改变。

随着测试次数的增加，对所测东西的熟悉程度增加，测试用例的完善和更新，自己的测试想法也不断冒出来，这正是总结测试经验的时机，所以不断的重复测试并不是什么坏事，要学会在重复测试中总结和提高。

 51Testing软件测试网*@r
PD R,x3L

10．执行测试用例的时候，补充测试需求和测试用例

在设计的时候要想清楚包含的测试需求、存在的边界值、各种组合情况、测试通过的标准、可能出现的错误等。可以试探性的执行测试的同时进行思考。我一般是设计好测试需求和测试用例之后，再执行测试，在执行测试的时候，把注意力集中在测试通过的标准是否正确（刚设计的时候已经思考好）和其它能看得到的地方（设计的时候没有在意，这个就需要细心，因为不是预期想到要检查的点）。51Testing软件测试网-A8Q2B[S},~VRn`E

 51Testing软件测试网7k$QC[{hD4f~h1y_T

11．其他

测试的目的是发现BUG，主要从3个方面考虑：需求本身是否存在问题，设计是否正确满足需求，设计本身是否存在问题。所以测试需求和测试用例的设计是根据后面两个方面而展开的。51Testing软件测试网9YSFm#[ljE'T7|