测试与软件生命周期

提示：看这篇文章之前需要有一些UML与RUP开发模式的知识

测试介绍

测试是什么，就是在开发快完成时对程序进行找错吗？其实不然，就好像捕鱼一样，讲就季节，阳光，水流，甚至鱼网洞的大小的使用都直接影响到捕鱼的效果。测试也是一样，不仅仅只是找错而已，还需要有计划的进行，同时大家都知道发现软件缺陷越早，修改的成本就越低。那么怎样才能准确而又及时的发现软件缺陷，这首先要从软件的生命周期讲起。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

软件的生命周期

软件的生命周期将软件开发分为若干个阶段，主要有需求，分析，设计，编码，测试几个主要的阶段，同时在RUP的开发过程中除了这几个主要阶段外，还对这些阶段进行迭代式的开发。但是我有几点疑问，测试难道就必需在开发后期进行吗。在早期的开发过程中也许是可以的，但是现在的软件开发逐渐由小作坊式的开发进入大规模的团队开发，早期介入测试有助于提早发现问题，同时大幅度的降低项目风险有很大的好处。不过如何在早期介入测试则是一个很值的讨论的问题。下面我们从软件生命周期详细的叙述一下如何介入软件测试。

需求，分析阶段测试的结合

首先我们从软件生命周期的各个阶段进行分析。在需求，分析阶段，需求人员会对用户的需求进行详细的分析，形成产品说明书，如果更好的可以细化到用例图，活动图。可能大家对UML不是很熟悉，我这里作一下简单的说明。用例是用来描述一个参与者（可以理解为一个外部系统用户，可以是人或外部系统）使用系统完成某一个过程的事件发生的顺序，是系统的使用过程。用例图则是系统的一组用例，用例的参与者（角色）以及用例与参与者之间的关系图。下面就是一个简单购物系统的用例图。

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /><shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></shapetype><shape id="_x0000_i1025" style="WIDTH: 353.25pt; HEIGHT: 297pt" type="#_x0000_t75" o:ole="" o:bordertopcolor="this" o:borderleftcolor="this" o:borderbottomcolor="this" o:borderrightcolor="this"><img src="/Develop/ArticleImages/20/20902/CSDN_Dev_Image_2003-9-61302140.png" o:title=""><?xml:namespace prefix = w ns = "urn:schemas-microsoft-com:office:word" /><bordertop type="thinThickSmall" width="24"></bordertop><borderleft type="thinThickSmall" width="24"></borderleft><borderbottom type="thickThinSmall" width="24"></borderbottom><borderright type="thickThinSmall" width="24"></borderright></shape>

如图1

从图中我们可以发现三个系统的功能，1购买商品，2安全验证，3退还商品。这时我们测试人员可以知道这个系统有三个功能块组成，这时可以在测试计划书中结合产品说明书对这三个功能块的测试目标进行详细的描述，从而保证系统没有重要功能块的覆盖面，后面有经验的案例设计人员会通过测试计划书设计出合理的案例对功能进行测试。这时我们测试人员还可以起到另一个作用，对需求的审核，比如这里对用户是否要登陆，大家有不同的看法，这时可以让需求人员进一步确认用户是否需要使用登陆功能块。不同系统的产品说明书与用例图总是不同的，不过在我们测试人的眼里，它可是用来确定产品是否可以满足用户需求的主要标准，一个用例就可以对应一个或是多个功能点，通过它可以明确的写出测试的功能目标书，我称为测试计划书。这里主要描述产品需要达到的功能，性能要求，稳定性要求。也就是说我们在早期的需求分析阶段就可以介入测试，确定后期测试的目标，如果要求更高点可以进一步的进行需求测试，论证需求是否可以满足用户的要求,从而减少需求风险。

设计阶段与测试的结合

进入设计阶段，设计组成员会提供详细的设计文档，其中主要有时序图，协作图(状态图)，类图等等。时序图向我们展示了用例事件发生的过程中与系统直接发生交互的处部参与者，系统（可以看作一个黑盒）。这时可以提取出有哪些系统是要进行测试的，可以明确我们黑盒测试的目标，而不是在最后再找有哪些系统是要进行测试的。协作图可以详细的描述出系统状态的变化。为一个大型软件产品建立状态图是艰苦的事情，既然有大家的劳动成果为什么我们测试不利用呢？前面进行的测试需求是捕捉的都是静态的需求，但这里我们可以清晰的看到软件状态的变化，这时我们就可以针对各种状态分析要测试的状态转换和主要的程序流程来设计测试案例，同时状态的变化有时也是对系统接口的交接，这时设计的案例则主要针对接口优先的原则，保证了接口在挂接过程中得到有效的测试。下面就是一个状态图：

<shape id="_x0000_i1026" style="WIDTH: 395.25pt; HEIGHT: 260.25pt" type="#_x0000_t75" o:ole="" o:bordertopcolor="this" o:borderleftcolor="this" o:borderbottomcolor="this" o:borderrightcolor="this"><img src="/Develop/ArticleImages/20/20902/CSDN_Dev_Image_2003-9-61302142.png" o:title=""><bordertop type="thinThickSmall" width="24"></bordertop><borderleft type="thinThickSmall" width="24"></borderleft><borderbottom type="thickThinSmall" width="24"></borderbottom><borderright type="thickThinSmall" width="24"></borderright></shape>

图2

从图中我们可以看到系统如何从进入post进行操作的过程，通过消息使系统发生了功能性变化，比如从购买（sale）到付费（payment）这个状态的变化是由create的消息进行的，不过我们不需要关心这个，这个是设计人员与开发人员关注的，测试人员关注的是系统有那些状态的变化，我们的测试案例是否可以测度这些状态的变化。于是我们的测试案例就有补充，刚刚我们从用例图中发现的都是静态的功能需求比如上面的购买商品功能，而现在则可以看到实现购买功能系统进行状态的变化的过程,这时测试案例就要对这种状态的变化进行补充，从而让案例可以覆盖动态的变化，从而保证系统重要功能流程的测试,同时你们看到消息的变化就是接口的变化，从而也保证了接口得到充分的测试。而类图的作用就更显而易见了，下面就是一个类图。

<shape id="_x0000_i1027" style="WIDTH: 275.25pt; HEIGHT: 183.75pt" type="#_x0000_t75" o:ole="" o:bordertopcolor="this" o:borderleftcolor="this" o:borderbottomcolor="this" o:borderrightcolor="this"><img src="/Develop/ArticleImages/20/20902/CSDN_Dev_Image_2003-9-61302144.png" o:title=""><bordertop type="thinThickSmall" width="24"></bordertop><borderleft type="thinThickSmall" width="24"></borderleft><borderbottom type="thickThinSmall" width="24"></borderbottom><borderright type="thickThinSmall" width="24"></borderright></shape>

图3

从类图中你可以清晰的了解到这个系统有哪些实体类,比如这里有Post实体类与Sale实体类，还有类内部的变量，函数，并且可以看到变量和函数的级别(public,private等等)。这样你就可以有效的针对这些设计相应的测试案例。特别在国内无法达到像微软这样一对一的白盒测试时，针对函数的测试有助于较早期的发现问题，将软件缺陷消灭在开发早期。

编码阶段实施测试

到达编码阶段时，怎样在早期就可以介入测试，这要从每日编译说起，在可能的情况下对已开发的功能进行每日编译，形成可测试的版本，从而让测试人员进行测试，这时前期的工作并没以白做，这时我们已经有了测试需求说明书，测试计划书与重要的案例，可以对它进行分配并测试，这时至少重要的功能在早期就得到了保障。同时随着系统的不断完善，可以让各个功能模块的测试人员增加测试案例，保证测试的完备性。每日编译还有个好处，就是测出的软件缺陷可以在当天就可以处理，从而保证了把缺陷消灭在早期。这时测试与开发已经完美的结合起来，做到测试与开发的同步，并且不相互冲突。

后期测试

开发后就是测试，说到现在这时你才感到轻松，由于测试与开发是同步进行的，所以这时我想你主要进行的就是对开发过程中发现的问题的回归测试。甚至你可以喝喝咖啡了J,因为在编码阶段软件缺陷就发现差不多了，这时主要的精力放在集成测试，性能测试，兼容性测试等一些测试上来，而且这些测试的标准在需求分析时就有了，比如性能测试，它要求的数据在需求时我们就关注过，有了这些有效的目标我们还做不好吗。

总结

测试如果与软件生命周期结合，可以有效的保证测试的目标和覆盖率，，同时可以充分利用需求人员，设计人员的力量来指导我们的测试，不过也带来一些问题，就是实施的难度，必需要求整个开发团队使用RUP或是类似于RUP的适合自己的开发过程，同时高级测试人员对此要有一定的了解才可能实施，不过它的好处还是显而易见的，我们为什么不尝试着做一下呢J,最后祝大家好运，多多发现问题，早早发现问题，写出高质量的软件。