wangwencong-CSDN博客

原创 ETDD过程——可视化

下面用一个简单示例，展示ETDD一般过程，使用的工具是Visual Unit。我们要编写一个函数，其功能是删除字符串左边空格。步骤一，编写函数框架，能通过编译就行：char* strtrml(char *str) { return str;} 步骤二，明确代码的最基本功能，就是确定程序最普通的输入是什么，应该产生什么输出。下

2013-01-18 15:04:15 5345

原创易行版TDD(ETDD)

TDD具有明确需求、明确设计、测试即文档、代码质量可控、提高开发效率等优点，但也具有不自动化程度低、资源利用不充分、干扰编程思维等缺点，难以推广、难以长期坚持。 ETDD(Easy TDD)，即易行版TDD，是TDD的改进和升级。ETDD继承了TDD的优点，克服了TDD的缺点。改进可归纳为“三化”：可视化、自动化、现实化。可视化：开发过程中，程序行为可视。可视化

2013-01-11 13:51:50 2229

原创 TDD的不足之处

TDD有很多优点，但也有可改进之处，主要在三方面：自动化程度低、对资源利用不充分、干扰编程思维。 1.自动化程度低 TDD要求先编写测试代码再编写产品代码，这个编码顺序决定了难以利用工具来生成测试代码。当然，工具也不可能根据测试代码来生成产品代码。如果首先编写产品代码，工具则可以自动生成大部分测试代码，人工一般只需要设定用例的输入输出就可以了。测试代码的编写工作量是很大的。

2013-01-05 15:53:14 1801

原创 TDD原则

独立测试：不同代码的测试应该相互独立，一个类对应一个测试类（对于C代码或C++全局函数，则一个文件对应一个测试文件），一个函数对应一个测试函数。用例也应各自独立，每个用例不能使用其他用例的结果数据，测试结果也不能依赖于用例执行顺序。一个角色：开发过程包含多种工作，如：编写测试代码、编写产品代码、代码重构等。做不同的工作时，应专注于当前的角色，不要过多考虑其他方面的细节。

2012-12-28 16:05:13 1424

原创 TDD过程

一.TDD三条军规Object Meentor公司总裁，极限编程领域资深顾问Robert C. Martin提出了TDD三条军规：1.除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。2. 只允许编写刚好能够导致失败的单元测试（编译失败也属于一种失败）。3. 只允许编写刚好能够导致一个失败的单元测试通过的产品代码。这三条军规简单明了地阐述了TDD过程，下面举例说明。

2012-12-24 16:44:13 2016

原创测试驱动开发(TDD)

什么是TDD TDD是Test-Driven Development的缩写，即测试驱动开发。TDD的基本思路是利用测试来推动开发的进行，并不是单纯的测试过程。TDD是极限编程的核心之一，但TDD也可以单独运用。 TDD的优势明确需求：在软件开发过程中，需求常常是易变且不易描述的。项目的整体需求最终会细化为代码的需求，即每个代码单元都有其具体的功能要求。

2012-12-19 14:17:28 1829

原创用局部数据模拟进一步解决单元测试的内部输入

局部数据模拟是底层模拟的扩展，可以对局部变量、代码片断实施模拟，以便在用例中设定需要的数据；也用以在底层模拟不支持的情形下代替底层模拟。利用局部数据模拟可以视需要在测试过程中修改被测试代码，而不修改产品代码，实现对任意数据的模拟和控制。局部数据模拟一般支持以下应用：模拟"="号右边的数据将"="右边替换为调用一个自动生成的函数，通过在用例中设定该函数的返回值，模拟

2012-12-12 10:42:36 1297

原创用底层模拟解决单元测试中的内部输入

底层模拟就是在用例中模拟、控制子函数的行为，使底层函数产生的数据像参数一样可以在用例中设置。底层模拟的特点 1）在用例中用例设定子函数的输出，使子函数的输出可以与参数等输入放在一起，实现真正意义上的内部输入； 2）无论子函数是否打桩，都可以使用底层模拟，即用户不需要考虑调用的是桩代码还是实际代码； 3）对于一个子函数，如果某个用例使用了底层模

2012-12-03 14:56:34 2458

原创用桩解决单元测试中的内部输入

我前面的文章有介绍过，桩有三个功能：隔离、补齐，控制。其中，控制功能就是用于解决内部输入的，因此，打桩并手工修改桩代码，是解决内部输入的方法之一。关于编写桩的方法，已在第4章介绍过，这里不再重复。关于如何让桩与用例匹配，请阅读第9章。遗憾的是，编写桩代码不但增加工作量，而且不能解决所有的内部输入，下面对内部输入分类分析：自然输入：自然输入调用实际代码

2012-11-30 16:08:58 3867

原创单元测试中内部输入的六种情形

1 自然输入自然输入是指对底层函数的正常调用即可获得的内部输入。代码一中Compare()函数内，int a1 = GetArea(r);可以自然取得外接正方形的面积。如果外接正方形面积a1要得到某个预期的值，要传递合适的半径r，半径r称为间接输入。间接输入需根据自然输入及底层函数的功能来倒推，要获得符合预期的自然输入有三个条件：一是底层函数存在，二是底层函数正确，三是间接

2012-11-28 16:29:59 3412

原创单元测试的关键难题——内部输入

只有深刻理解内部输入，才能真正理解单元测试。单元测试是针对代码单元的独立测试，一个函数，在调用了底层函数的情况下(底层函数可能不存在、不可控、不得不隔离、甚至有错误)，如何能够独立测试？正是因为底层函数的输出，可以视为被测函数的内部输入，才能真正进行独立测试。为了理解内部输入，这里用两组功能完全一样代码来进一步解释（差异部分用粗体标出）：代码一：//计算圆的外接正方形的面积，参数r为圆

2012-11-26 16:05:08 1317

原创认识单元测试中的覆盖输入

单元测试的目标是覆盖代码单元的功能逻辑，要做到覆盖功能逻辑，就要覆盖输入的所有分类。一个函数，输入包括两方面：外部输入，内部输入。外部输入就是函数外部可以设定的输入，包括参数，全局变量，成员变量，设定这些输入相对比较容易，关键问题是内部输入。一个函数，对于调用底层函数获得的数据，是如何处理的呢？跟参数一样，也是分类处理，如下图。所以，测试时也要分类

2012-11-23 15:34:32 1662

原创单元测试中的独立运行

单元测试是针对代码单元的独立测试。要测试代码单元，首先要其使能够独立运行。项目中的代码具有依赖关系，例如，一个源文件可能直接或间接包含大量头文件，并调用众多其他源文件的代码，抽取其中的一个或一组源文件，一般是无法独立编译运行的。这就要用技术手段进行隔离，即将测试任务与其他代码隔离，必要时还要与依赖系统隔离。此外，并行开发过程中，边开发边测试，还需补齐尚未实现但需调用的代码。

2012-11-22 16:06:28 2025

原创单元测试中的“可测性”

单元测试效益特别高，方法也很简单，但却尝试的企业很多，成功实施的企业很少，为什么呢？主要原因就是难于突破可测性问题。“可测”这个词，意思很明白，如果不“可测”的话，那就是不能测，没法测，就是做不下去，或者困难太多，成本太重，热情被逐渐消磨，最后不得不放弃。所以可测性问题是单元测试的关键阻碍，是我们首先要解决的。可测性问题是指代码的可测性很差，导致测试很困难。为什么代

2012-11-19 17:29:18 1778

原创单元测试中有人工介入的用例生成

生成用例代码这种技术大量减少用例代码的编写，提高了测试工作效率，但只需生成一个用例，手工完善后再拷贝修改。自动生成很多用例再分别修改是低效的，因为每个用例都需从头修改，造成大量重复工作，如果生成的用例代码不完整（例如缺少对全局变量和成员变量的初始化和判断，缺少前置或后置操作），重复工作量更大且令人厌烦。如果只生成一个用例，手工完善后再拷贝修改，由于不同用例之间通常只有一两个

2012-11-19 16:57:00 1168

原创单元测试中自动用例的局限和价值

自动用例的局限即使技术再成熟，完全自动生成的用例也是与功能无关的，即使覆盖所有路径，其效果不会比“跟着代码走”强，因此，主要依靠完全自动生成的用例来测试是不现实的，例如，TrimLeft(char*)(删除字符串左边空格)与CheckUserName(char*)(检查用户名的合法性并删除非法字符)，输入都是字符串，用例是完全不同的，工具不可能自动了解这种基本区别。多数自动

2012-11-19 16:51:34 1221

原创单元测试的自动用例生成方法

自动生成用例是所有测试人员的期盼，好消息是这种技术早就有了，坏消息是完全自动生成的用例作用很小。完全自动生成用例的方法主要有两种：根据输入自动生成、根据路径自动生成。一.根据输入自动生成一般是根据参数生成，这是一种简单的技术：任何数据类型都可以分解为基本数据类型，预先为各种基本数据类型设定一些值，组合一下就可以生成了，如函数int func(int arg, co

2012-11-19 16:48:24 9821 1

原创实现完整单元测试的思路和方法

在这里提出用“三步法”尽可能实现单元测试的完整测试，让大家参考一下。第一步：基本功能测试程序的功能是人为的规定，工具不可能自动了解，因此，针对基本功能的测试用例需要人工来建立，这是无可躲避的。根据程序的设计要求，基本功能用例通常不难设计，把程序功能细化、明确化，列成“什么输入，应产生什么输出”的形式，就是测试用例。程序员准备编码时和编码过程中，是建立基本

2012-11-19 16:42:34 2178

原创单元测试中测试用例的设计方法

1. 用于语句覆盖的基路径法基路径法保证设计出的测试用例，使程序的每一个可执行语句至少执行一次，即实现语句覆盖。基路径法是理论与应用脱节的典型，基本上没有应用价值，读者稍作了解即可，不必理解和掌握。基路径法步骤如下： 1）画出程序的控制流图控制流图是描述程序控制流的一种图示方法，主要由结点和边构成，边代表控制流的方向，节点代表控制流的汇聚处，边和

2012-11-16 14:49:59 30302

原创什么是测试用例

执行测试前，需要设定一些初始数据，称为输入。如何知道程序功能是否正确？通常的办法是预先设定正确的结果值，称为预期输出，执行测试后，自动对比实际输出和预期输出是否相符。输入和预期输出就构成了测试用例。输入有哪些？凡是被测代码可能读取的数据都是输入，对于一个函数，输入有参数、全局变量、成员变量、内部输入。内部输入是函数内部获得的输入，包括调用子函数获得的输入、局部静态变量、中断产生的

2012-11-16 13:36:39 5338

原创认识单元测试中的插装

什么是插装插装是指在被测代码中插入具有特定功能的代码，用以监视代码的执行过程。插装的主要目的是统计测试覆盖率。插装的基本要求如何插装插装工作由人工完成是很烦琐、不现实的，一般由工具完成，因此，这里不介绍人工插装方法，只简要介绍插装的基本原理。测试工具分析代码，找出需要插装的位置，并插入相应代码。例如：if(ret >

2012-11-16 10:48:25 3353

原创打桩步骤与难点解决

为了让测试代码正确链接到桩函数，一般来说，要让函数具有与原函数相同的原形，这样就产生了一个问题：原函数与桩函数冲突。打桩过程中必须解决这个问题。在实际工作中，打桩可以分两步来完成：一、隔离测试任务，补齐未实现代码。可以利用IDE的链接错误来判断哪些函数需要打桩。例如，一个项目有1000个源文件，某位工程师需要测试其中的50个源文件，可以用IDE建立一个工程，将这50个源文

2012-11-16 10:39:18 8923

原创认识单元测试中的打桩

什么是桩桩，或称桩代码，是指用来代替关联代码或者未实现代码的代码。如果函数B用B1来代替，那么，B称为原函数，B1称为桩函数。打桩就是编写或生成桩代码。打桩的目的打桩的目的主要有：隔离、补齐、控制。隔离是指将测试任务从产品项目中分离出来，使之能够独立编译、链接，并独立运行。隔离的基本方法就是打桩，将测试任务之外的，并且与测试任

2012-11-16 10:27:16 46826 2

原创单元测试的肥肉与骨头

无处不在的80-20规则，在软件开发中也同样存在，例如，80%的错误存在于20%的代码中，80%的项目时间消耗在20%的代码上，当然这只是粗略的估计，不同的项目，比例可能有所不同。那么，这20%是哪些代码呢？是功能逻辑复杂的代码，也就是算法密集的代码。一个算法密集的函数，通常要对数据仔细分类，一个判定就是一次分类，嵌套的判定更使分类次数翻番，要做到分类正确完整且处理无误，是很困难的事。遗漏一个

2012-11-15 11:27:51 1794 3

原创如何防止单元测试实施中因小失大

“独立”状态下易以发现的错误，才是单元测试的目标；集成后才易以发现的问题，应该留待系统测试。具体来说，代码单元本身的功能逻辑错误都是单元测试的目标，而设计错误、性能问题难于在最小单元内测试，不是单元测试目标。性能问题是指时间性能（如执行速度）和空间性能（如存储空间大小、内存泄漏）。单元测试也不考虑平行和向上依赖关系，并把向下依赖抽象为内部输入，例如，测试一个函数时，不考虑这个函数在项目中是被普

2012-11-15 11:04:48 817

原创浅谈单元测试的优势与不足

单元测试是针对代码单元的独立测试，核心是“独立”。因为“独立”，所以可以做到针对代码单元，设计完整的测试数据，覆盖代码单元的所有功能逻辑，做到“不管其他代码怎么样，我总是对的”（这个“我”是指当前正在编写或测试的代码单元），从而在根本上保证代码单元的质量。因为“独立”，所以每个程序员都可以在编写或修改代码的同时进行单元测试，即使项目刚刚开始编码，还不能构成一个可以运行的“系

2012-11-12 15:21:18 3139

原创如何编写测试代码

本文通过介绍简单测试代码的编写来进一步阐述单元测试的基本原理和方法，在实际工作中，测试代码可以由工具生成。下面用最容易理解和测试的加法函数来介绍测试代码的编写，函数代码如下：int add(int a,int b){return a + b;}测试代码如下：void test_add(){//设定输入int a = 1;int b = 1;//执

2012-11-12 15:10:40 16245

原创单元测试的四大具体效益

单元测试是高效的开发过程质量控制机制，帮助企业保证产品质量、降低成本、提高生产率、缩短开发周期、赢得市场先机，提升竞争力。 1保证代码质量仅依靠系统测试会存在大量未覆盖的“死角”，单元测试可以对各个代码单元彻底测试，保证代码质量。针对一个函数，单元测试可以覆盖输入数据的所有分类，做到不管输入什么数据，函数本身的处理都符合设计，从而全面检测其功

2012-11-09 16:56:15 1348

原创单元测试的基本方法

下图示出了单元测试的基本方法。程序执行之前的条件，称为输入，程序执行之后的结果，称为输出。通常，这些输入都是可以分类的，每类对应一个功能点。如何检测功能是否全面？把各个功能点都列出来；如何检测功能是否正确？把各个功能点对应的正确输出也列出来，由工具自动判断实际输出是否相符。这就是单元测试的基本方法：设定输入，执行程序，自动判断输出是否正确。每种输入及其对应的正确输出就是一个测试用例。

2012-11-09 16:38:34 862

原创广义单元测试方法

从测试的主体来说，单元测试可以分为两类，一是自动，靠工具自动完成；一是人工（人工介入测试过程）。从测试的方法来说，单元测试可以分为两类，一是静态（分析代码），一是动态（执行代码）。这样我们可以组合出四种测试的方法：人工静态分析：通过人工阅读代码来查找错误，一般是交叉阅读，即代码走查。自动静态分析：用工具自动扫描代码中的

2012-11-09 16:33:45 845

原创代码错误分类

代码错误可以分为两个方面：性能问题，功能错误。性能问题又可以分为时间性能和空间性能。时间性能就是执行效率不符合预期。空间性能就是所占用的资源超出预期。由于单元测试面对的测试目标是比较小的代码单元，时间性能和空间性能比较难于衡量，所以单元测试一般不测试性能问题。性能问题应该在系统测试或者性能测试的时候来完成。单元测试主要测试代码的功能错误。功能错误就是程序没有实

2012-11-09 16:28:45 3036

原创从代码特性看单元测试的必要性

代码有一个基本特性：对数据分类处理。一个判定，就是一次分类；如果判定又嵌套了判定，则分类的次数翻倍。一个分类遗漏，或一个分类的处理不正确，就会造成错误。一个函数无错误，要做到：对数据的分类完整，即各种可能输入要考虑全面；每个分类的处理要正确。对数据的分类和处理，就是代码的功能逻辑。如何才能检测代码功能逻辑是否正确？调试，是临时性的，数据通常由“拦截”

2012-11-09 16:18:41 742

原创什么是单元测试

传统工业普遍重视“单元测试”。组装一台电视机之前，会对每个元件进行测试，这是保证质量，降低成本，提升竞争力的需要。不做“单元测试”，只测试整机可不可以？当然可以，但是，只测整机无法检验每个元器件在各种条件下是否工作正常，会有很多“死角”难于覆盖，从而造成整机质量低下，并且修复成本更高。软件的单元测试具有更重要的意义，因为代码由人工编写，并非流水线上按相同材料统一规格制作，包含的缺陷更多，

2012-11-09 15:52:27 690

原创单元测试的效益

单元测试是针对代码单元，特别是算法密集的代码单元的独立测试，可以完整覆盖代码单元的功能逻辑，保证代码质量、降低成本、提高生产率、缩短开发周期、赢得市场先机、提升产品竞争力。单元测试分为静态和动态，静态方法只能发现小部分错误，例如，加法函数int add(int a, int b){return a-b;};,加号写成了减号，这种最简单代码中的最简单错误，任何静态工具都无法发现

2012-11-09 15:40:52 843

wangwencong的专栏