从测试角度对测试驱动开发的思考【转】

测试驱动开发(TDD)是极限编程的重要特色，它以不断的测试推进代码的开发，既简化了代码，又保证了软件质量。本文主要从测试角度出发，从需求分解等四个阶段阐述了测试人员在测试驱动开发中所发挥的促进做用

    你们都知道，软件生命周期通常分为六个阶段：制定计划、需求分析、设计、编码、测试、运行和维护。在软件工程中，这个复杂的过程用软件开发模型来描述和表示，常见的软件开发模型有：瀑布模型、螺旋模型、V模型、W模型等。而这些传统的开发模型都以开发为主，测试经常扮演的是一个亡羊补牢的配角，这类开发模型已渐渐的不能知足如今项目组的须要。从而诞生了比较实用的、高效的、以测试为中心的软件过程开发方法—测试驱动开发（TDD）。

    测试驱动开发，其基本思路就是经过测试来推进整个开发过程。在整个软件开发流程中，让测试先行，如将测试方案设计工做提早、将编写一小段的测试代码或产品代码提早、同时将测试方案看成开发行为的准绳，而后在软件后续的开发过程当中实时进行验证，最终实现软件开发过程的“小步快走”。

    且看下面两个泥瓦匠的工做方法：

　　工匠1：先拉上一根水平线，砌每一块砖时，都与这根水平线进行比较，使得每一块砖都保持水平；

　　工匠2：先将一排砖都砌完，而后拉上一根水平线，看看哪些砖有问题，再进行调整。

做为旁观者，你确定也会以为工匠1的方法要科学一些，的确如此。在软件项目中，在“砌砖”时以“水平线”为标准，是否是会下降开发与需求理解的误差、下降开发过程当中的缺陷率、并还会提升bug定位速度呢？答案固然是确定的。

在软件整个过程当中融入测试驱动开发，那到底从哪些阶段去驱动呢，从测试角度来看，我我的认为能够从需求分解、单元测试、集成测试、系统测试四个阶段来进行。

1、需求分解阶段

需求是软件开发的源头，不管是新开发项目仍是持续迭代更新的项目，开发人员在开发功能和测试人员在进行测试的时候，都须要最早肯定需求。

在需求发布到需求分析、需求理解及需求确认这一过程当中，每每会出现如下现象：

（1）需求常常变动，在正在开发过程当中忽然需求又变了；

（2）需求理解误差，开发或测试对需求理解的角度不一样，会出现各类理解误差；

（3）需求描述模糊或过于简单，开发人员和测试人员会分别花费较多时间去找产品人员确认需求；

    （4）测试人员每每对需求的理解只停留在用户的角度，未深刻从代码的角度去

思考，如该功能包含的边界范围、接口、异常状况、对其余函数或类的影响等等；

    试想，若是能尽量的避免上述现象的发生，那不就打响了测试驱动开发的“第一炮”了么？我认为从如下几个方面来进行，或许有些效果：

（1）测试人员、开发人员和产品共同参与需求的评审、更改、确认；

（2）测试人员对较大的需求（非简单的页面展现）进行分解成一个个小的功能点，编写成一个个小的产品代码（即所谓的测试用例），从而避免由于需求理解不一致致使误差的问题；

（3）明确需求后，先预估本次需求对系统其余功能有没有附做用，把风险降到最低；

 

2、单元测试阶段

测试驱动开发的基本思想就是在开发功能代码以前，先编写测试代码。这是一个很是精典的理论，可是在实际项目过程当中，这样实现可能会有必定的难度。既然有难度，那你还写这篇文章干吗？请不要这样问我，我会很无奈，由于我只是一个菜鸟，菜鸟所理解的测试驱动开发确定不能和专家的观点相提并论。

在此，咱们仍是先来回顾下软件开发模型中的W模型：

   

 

    由图能够看出，W模型的主要特色是测试伴随着整个开发的生命周期，但其缺点就是把软件的开发视为需求、设计、编码等一系列串行的活动，没法支持迭代、自发性以及变动调整。

这种自上而下的只适合那种比较稳定、需求变动较少的大型项目（如军工项目、第三方测试机构测试项目），而不适用于需求变动频繁、迭代较快的航空B2C项目，以海航B2C项目为例，产品人员提供需求后，就会快速进入编码实现阶段，其中会省略了概要设计和详细设计两步。

那经过什么方式能够替代概要设计和详细设计两阶段？

试想一下，测试人员经过下面两种方式来进行弥补，是否有利于测试驱动开发呢？

步骤1：编写单元测试计划，明确测试目标

测试计划主要内容包括：

* 主要功能模块，及实现功能定义

* 测试时间、人员分配

* 每一个模块包含哪些测试类型、测试方法

* 明确每一个功能模块所属的类名、函数名和新添加字段（由开发完成）

* 测试用例（需求分解阶段的产品代码）

    步骤2：测试人员在开发编码完成后进行单元测试

前提：

（1）测试人员与开发人员对接

    （2）测试人员搭建开发环境，并熟悉代码结构

    （3） 步骤1中的测试计划，都得测试人员和开发人员共同评审经过，并做为测试的标准

单元测试检查点：

    （1）静态测试：检查代码语法、每一个类代码行数等是否符合研发规范

    （2）动态测试：运用junit测试框架，根据测试用例，检查每一个函数输入输出的

正确性、代码分支覆盖率、异常处理等等

 

    3、集成测试阶段

    集成测试，便是对代码进行封装以后，对每个功能模块进行的测试。

    对于测试人员来讲，在集成测试阶段又如何能发挥本身的做用，有效的作到测试驱动开发呢？

先来看下集成测试前提条件：编码完成—>单元测试经过—>发布代码，部署成功—>集成测试。

因此测试人员在进行集成测试阶段，如下几方面我认为有利于测试驱动开发： 

（1）测试人员熟悉开发环境，熟悉代码内部结构，能运用测试思惟，提早预估风险，规避部分测试风险；

    （2）对部分难模拟场景，测试人员能够本身经过更改代码或配置，模拟相应测

试场景，喊少开发的工做量；

    （3）测试人员在测试过程当中发现bug以后，能快速定位bug，并能初步判断bug

引发缘由，对开发更改bug减小跟踪时间；

     

    4、系统测试阶段

    系统测试，便是经过全部功能模块的相互链接，对整个系统进行连调测试。

在系统测试阶段，测试人员在测试驱动开发中又起到一个什么样的促进做用呢？

由于在前几个阶段，测试人员逐步参与需求理解、开发环境搭建、单元测试、集成测试，全部在系统测试阶段，测试人员有如下几个优点：

（1）对整个系统内部结构比较明了，对功能也很熟悉，能用较少的时间完成测试

（2）对不一样功能之间调用的接口比较熟悉，在对系统进行接口方面的测试时有必定的优点

（3）若在测试过程当中出现了环境问题，做为测试人员也会快速找到问题或解决方案

    （4）测试人员可针对系统特定的功能点，精准的编写和优化自动化测试框架，

从而在之后的系统测试阶段，更加节约了人力成本和发现bug的效率

（5）经过对系统的理解，能在系统须要进行安全测试、压力测试时快速展开工做

 

    以上几个测试阶段即是我的从测试角度对测试驱动开发的理解，本文所理解的测试驱动开发与Kent Beck所著的《Test-Driven De velopment》中的测试驱动开发有必定区别，仅供参考！