测试驱动开发课件

测试驱动开发

.

1

大纲

.测试驱动开发介绍

2.单元测试

❖3.测试工具

。4.当前面临的问题

。5.相关资料

1.测试驱动开发介绍

1.背景

测试驱动开发(TestDrivenDevelopment,英文缩写

TDD)是极限编程的一个重要组成部分，它的基本思想就是

在开发功能代码之前，先编写测试代码。也就是说在明确要

开发某个功能后，首先思考如何对这个功能进行测试，并完

成测试代码的编写，然后编写相关的代码满足这些测试用例。

然后循环进行添加其他功能，直到完成全部功能的开发。代

码整洁可用(cleancodethatworks)是测试驱动开发所追求

的目标。虽然TDD光大于极限编程，但测试驱动开发完全可

以单独应用。

1.测试驱动开发介绍

2.极限编程

极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件

的开发设计，保证变化的需求及时得到修正。要让客户能方便地与开发人员沟通,

一定要用客户理解的语言，先测试再编码就是先给客户软件的外部轮廓，客户使

用的功能展现，让客户感觉到未来软件的样子，先测试再编码与瀑布模型显然是

背道而驰的。同时，极限编程注重用户反馈与让客户加入开发是一致的，让客户

参与就是随时反馈软件是否符合客户的要求。有了反馈，开发子过程变短，迭代

也就很自然出现了，快速迭代，小版本发布都让开发过程变成更多的自反馈过

程。

1.测试驱动开发介绍

♦：♦3.测试驱动开发的优点)

跟测试后进行的开发方式相比，它有如下好处：

。(1)测试驱动开发最重要的功能还在于保障代码的正确性，能够迅速发现、定

位bug。针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位.

bug提供了条件。

。(2)痛过翁写i弋码的测试用例，对其功能的分解、使用过程、接口都进行了设

计。而且这种从使用角度对代码的设计通常更符合后期开发的需求。可测试的要

求，对代码的内聚性的提高和复用都非常有益。因此测试驱动开发也是一种代码

设计的过程。(

*(3)写单元测试的时候，很容易就可以为一个行为写一个测试用例，让它通过，

然后为另一种行为写另一个测试用例。也就是说，整个任务会械划分成很多小的

任务，独立完成。如果我们不用TDD而直接实现的话，我们很容易就会同时把所

有的行为都实现了。这样花的时间长，而且在这相当长的时间里面，写的代码都

是没有测试过，不能保证准确性的。相反的，用TDD的话，我们只实现要测的

行为的代码。它只花费很少的时间(几分钟)，而且可以马上测试。

1.测试驱动开发介绍

。（4）为了更容易的写单元测试，我们会广泛的使用接口。这个会让单

元测试代码很容易读跟写，因为测试代码里面没有多余的数据。如果我

不用TDD而是直接写实现的话，我们经常会使用现成的类，测试为了

调用现成的类，就不得不创建很多多余的数据，创建很巨型的对象。

。（5）因为广泛的使用接口，我们的类之间就不会藕合，因此重用性更

好。

。（6）发现比传统测试方式更多的Bug。

。（7）完工时完工。表明我可以很清楚的看到自己的这段工作已经结束

了，而传统的方式很难知道什么时候编码工作结束了。

1.测试驱动开发介绍

♦：♦4.测试驱动开发的过程

♦：♦1）明确当前要完成的功能。可以记录成一个TODO列表。

。2）快速完成针对此功能的测试用例编写。

。3）测试代码编译不通过。

。4）编写对应的功能代码。

。5）测试通过。

。6）对代码进行重构，并保证测试通过。

。7）循环完成所有功能的开发。

可参考《测试驱动开发》第175页

1.测试驱动开发介绍

♦5.原则)

❖(1)测试隔离。不同代码的测试应该相互隔离。对一块代码的测试只考虑此代

码的测试，不要考虑其实现细节(比如它使用了其他类的边界条件)。

。(2)一顶帽子。开发人员开发过程中要做不同的工作，比如：编写测试代码、

开发功能代码、对代码重构等。做不同的事，承担不同的角色。开发人员完成

对应的工作时应该保持注意力集中在当前工作上，而不要过多的考虑其他方面的

细节，保证头上只有一顶帽子。避免考虑无关细节过多，无谓地增加复杂度。

(3)测试列表。需要测试的功能点很多。应该在任何阶段想添加功能需求问题

时，把相关功能点加到测试列表中，然后继续手头工作。然后不断的完成对应；

的测试用例、功能代码、重构。一是避免疏漏，也避免干扰当前进行的工作。

❖(4)测试驱动。这个比较核心。完成某个功能，某个类，首先编写测试代码，

考虑其如何使用、如何测试。然后在对其进行设计、编码。

*(5)先写断言。测试代码编写时，应该首先编写对功能代码的判断用的断言语’

句，然后编写相应的辅助语句。

1.测试驱动开发介绍

(6)可测试性。功能代码设计、开发时应该具有较强的可测试性。其实遵循比

较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖

于接口等。

(7)及时重构。无论是功能代码还是测试代码，对结构不合理，重复的代码等

情况，在测试通过后，及时进行重构。

(8)小步前进。软件开发是个复杂性非常高的工作，开发过程中要考虑很多东

西，包括代码的正确任、可扩展性、性能等等，很多问题都是因为复杂性太大寻日

致的。极限编程提出】个非常好的思路就是小步前进。把所有的规模大、复杂

性高的工作，分解成小的任务来兀对于一人类来说，一个功能一个功能的完

成，如果太困难就再分解。每个功能的完成就走测试代码一功能代码一测试一重

构的循环。通过分解降低整个系统开发的复杂性。这样的效果非常明显。几个小

的功能代码完成后，大的功能代码几乎是不用调试就可以通过。一个个类方法的

实现，很快就看到整个类很快就完成啦。本来感觉很多特性需要增加，很快就会

看到没有儿人啦。你甚至会为这个速度感到震惊。(我理解，是大幅度减少调

试、出错的时间产生的这种速度感)

1.测试驱动开发介绍

❖6.测试范围、粒度

对哪些功能进行测试？会不会太繁琐？什么时候可以停止测试？这些问题比较常见。按大

师KentBenk的话，对那些你认为应该测试的代码进行测试。就是说，要相信自己的感觉，；

O感到疲劳就应该停下来休息

一下。嘱赢梭噜鳏僵髓点测试。

测试驱动开发强调测试并不应该是负担，而应该是帮助我们减轻工作量的方法。而对于何

时停止编写测试用例，也是应该根烤你的经验，功能复杂、核心功能的代码就应该编写更

全面、细致的测试用例，否则测试流程即可。

测试范围没有静查的标准，同时也应该可以随着时间改变。对于开始没有编写足够的测试

的功能代码，朗着bug的出现，根据bug补齐相关的测试用例即可。

小步前进的原则，要求我们对大的功能块测试时，应该先分拆成更小的功能块进行测试，

比如一个类A使用了类B、C,就应该编写到A使用B、C功能的测试代码前，完成对B、C

的测试和开发。那么是不是每个小类或者小函数都应该测试哪？我认为没有必要。你应该

运用你的经物验,，对那些可能出问题的地方重点测试，感觉不可能出问题的地方就等它真正

出问题的时族再补测试吧。

1.测试驱动开发介绍

。7.怎么编写测试用例

Y测试用例的编写就用上了传统的测试技术。

9操作过程尽量模拟正常使用的过程。

力全面的测试用例应该尽量做到分支覆盖，核心代码尽量做到路径覆盖。

9测试数据尽量包括：真实数据、边界数据。

9测试语句和测试数据应该尽量简单，容易理解。

力为了避免对其他代码过多的依赖，可以实现简单的桩函数或桩类(Mock

Object)。

《如果内部状态非常复杂或者应该判断流程而不是状态，可以通过记录日志字

符串的方式进行验证。

2.单元测试

❖1.概述

i单元测试的目标:确保模块被正确地编码。

力由谁去做:通常由开发人员执行。

《怎样去测试:功能测试可以用黑盒测试方法，代码

测试可用白盒测试方法。

小什么时候停止:当开发人员感到代码没有缺陷时。

2.单元测试

2.单元测试的重要性

《一个尽责的单元测试方法将会在产品开发的某个阶段发现很多的Bug,

并且修改它们的成本也很低。

&系统开发的后期阶段，Bug的检测和修改将会变得更加困难，并要消

耗大量的时间和开发费用。

力无论什么时候做出修改都要进行完整的回归测试，在生命周期中尽

早的对产品代码进行测试将是效率和质量得到最好的保证。

力在提供了经过单元测试的情况下，系统集成过程将会大大的简化。

开发人员可以将精力集中在单元之间的交互作用和全局的功能实现

上，而不会陷入充满很多Bug的单元之中不能自拔。

力使测试工作的效率发挥到最大化的关键在于选择正确的测试策略，

这包含了完全的单元测试的概念，以及对测试过程的良好的管理，

还有适当的使用好工具来支持测试过程。

2.单元测试

3.为什么要进行单元测试

(1)单元测试是不是太浪费时间了？

不经过单元测试，直接进入集成测试，系统正常工作的可能性非常低，大量的时

间被花费在跟踪那些简单的BugI:,会导致集成为一个系统时增加额外的工期。

』编写完整计划的单元测试和编写实际的代码所花费的精力大致相同。但是，一旦

完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的

加件的情况下，开发人员能够进行更高效的系统集成工作，这才是真正意义上的

进步。

位调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

(2)单元测试仅仅是为了证明这些代码作了什么吗？

』这是那些没有首先为每个单元编写一个详细设计文档而直接跳到编码阶段的开发

人员提出的一条普遍的抱怨。这样的测试完全基于已经写好的代码，这无法证明

任何事情。।

工单元测试基于详细设计文档，这样的测试可以找到更多的代码错误，甚至是详细］

设土的错误。

4因此，高质量的单元测试需要高质量的详细设计文档。

2.单元测试

(3)我是一个很棒的程序员，是不是可以不进行单元测试呢?

工每个人都可能犯错误。

4真正的完整的系统往往是非常复杂的，不能寄希望于没有进行广泛

的测试和Bug修改过程就可以正常工作。

(4)有集成测试就够了，集成测试将会抓住所有的Bug。

工系统规模愈来愈大，复杂度愈来愈高，没有单元测试，开发人员很

可能会花费大量的时间仅仅是为了使该系统能够运行。

4任何实际的测试方案都无法执行。

工在系统集成阶段，对单元功能全面测试的负载程度远远的超过独立

进行的单元测试过程。

工最后的结果是测试将无法达到它所应该有的全面性，一些缺陷将被

遗漏，弃且很多Bug蒋斌忽略过去。

2.单元测试

(5)单元测试的成本效率不高？

无论什么时候做出修改都要进行完整的回

归测试。

在生命周期中尽早的对产品进行测试将使

越早测试付出代价就越低

效率和质量得到最好的保证

Bug修改越晚，费用就越高，单元测试是

一个在早期抓住Bug的机会。

成本

相比后阶段的测试，单元测试的创建更简

单，维护更容易，并且可以更方便的进行

重复。开发部署

从全程的测试费用来考虑，相比复杂且旷阶段需求设计编照单元测试验收测试交付后维护

日持久的集成测试，或是不稳定的系统，到正费/p>

单元测试所需的费用是最低的。

2.单元测试

♦4.单元测试的策略

。单元测试最核心的并不是工具的使用，而是测试的策略和方法。工具也

好，实现手段也好，只是开展单元测试的必需品。

。以下是单元测试常采用的策略：

。1）哪些是重点模块？

2）哪些程序是最复杂、最容易出错的？

。3）哪些程序是相对独立，应当提前测试的？

。4）哪些程序最容易扩散错误？

。5）哪些程序是开发者最没有信心的？

。6）80・20原则：80%的缺陷聚集在20%的模块中，经常出错的模块改错

后还会经常出错，这种应该列入测试重点。

2,单元测试

♦5.测试用例的设计

♦：♦单元测试的核心是测试用例的设计，测试用例的核心是测试

数据的设计。

。测试用例的设计主要从两方面考虑：

。(1)功能。我们为了验证一个函数是否实现了它的功能，

通常采用黑盒测试的方法。常用的方法有边界值、等价类、

因果图，关于黑盒测试方法的详细介绍，参见《测试用例设

计白皮书.doc》。

(2)逻辑结构。通常采用白盒测试的方法。常用的方法有

判定覆盖、条件覆盖、条件判定组合覆盖，关于白盒测试的

方法的详细乔绍，参见《白盒测试方法.pdf》。

2,单元测试

*6,TDD与单元测试的区别

TDD是一种设计手段，而不仅仅是测试手段。

TDD的原则是“只做必要的事，不做多余的

事”。TDD其实并不是单纯强调测试，它首

先是需求分析和设计技术。

3.测试工具

❖1.概述

。为了完成测试驱动开发以及单元测试，我们

需要相应的工具。

❖针对C++的单元测试工具是CppUnit

针对c#的单元测试工具是NUnit

3.测试工具

❖2.NUnit介绍

。NUM是一个单元测试框架，专门针对于.NET来写的.其实在前面有

JUEt(Java),CPPUEt(C++),他们者B是xllnit的一员.最初，它是从JUMt而来.

现在的版本是248.

NUn4最初是由JamesW.Newkirk,AlexeiA.Vorontsov和PhilipA.

Craig,后来开发团队逐渐庞大起来.在并发过程中，KentBeck和Erich

Gamma2位牛人也提供了许多帮助.看来对于NUnit还真是下了一番力气

T.J

。NUM是xUM家族种的第4个主打产品,完全由C#语言来编写，并且编写时

充分利用了许多.NET的特性，比如反射，客户属性等等.

。最重要的一点是它适合于所有.NET语言.

如果你还没有下载，可以到/去下载.

3.测试工具

❖3.NUnit的安装

免费，开源的单元测试软件。

安装只要运行安装程序，按所有缺省设置即可。

NUNIT：www.nunit.org

NUNITADDIN：

http://sourceforge.net/projects/mmitaddin/

VisualStudio2005的一个用来集成Nunit单元测试工具的插

件。

NUNIT的中文文档：/nun巾index.html

3.测试工具

❖4.如何在项目中应用NUnit

参见《NUnit2.0详细使用方法.doc》第8页

3.测试工具

5.NUn让的常用属性

(1)TestFixture

(2)Test

(3)SetUp/TearDown

(4)TestFixtureSetUp/TestFixtureTearDown

(5)ExpectedException

(6)Ignore

(7)Category

(8)Explicit

(9)ExpectedException

(1)至(2)参见《NUrdt2.0详细使用方法.doc》第5页

(3)至(8)参加《NUnit2.0详细使用方法.doc》第13页

3.测试工具

6.NUrdt的各种断言

断言用于帮助你确定某个被测试函蒙是否工作正常，通常一个测试方法中会有多个断言,

当一个断言失败时，该测试方法就会终止。Assert类下面有如下几个断言函数：

(1)AreEquals(expected,actual[,stringmessage])

Expected是被测试代码的期望值，actual是被测试代码的实际值，message是一个可选的消息,

在二个值不一