为什么集成测试比单元测试更重要

标签: 集成测试 单元测试 | 发表时间:2013-03-18 01:55 | 作者:HorkyChen
出处:http://blog.csdn.net

单元测试很棒。在假定一些数据的环境下,能顺利通过测试的系统就可算是一个好系统。

不过,现在可以直连外部资源的集成测试才让程序更有价值。谁知道那些内容商(供应商,vendor)会做出什么傻事来!



很多人一直尝试着让测试达到100%的代码覆盖率,这是很棒的想法,但我倒觉得它有些基本概念上的问题。 LosTechiesRyan Svihla 提出了"反模式(anti-pattern", 有个有趣的观点: “多数应用都需要与外部资源交互”。他们有许多不错的论点,比如:

  大多数的单元测试都需一个运行着的数据库、网页或应用服务器。

确实如此。

全是同数据和外部系统相关的

我下面将要证明多数Bug并不来源于程序本身,而是由从外部输入的数据所引起的。


为什么? 因为通常Bug出现在实际的工作环境中,我们的程序总会处理不好那些外部系统输入的原始数据,或者程序输出到外部系统中的数据。而"单元测试"或TDD中所强调的是提供一组假定的数据,检验程序是否能够按照预期的方式运行。也就说整个测试是在一个假定环境下进行的。这就是为什么接口总是如此轻易就成功运行了。在这之上还可以达到自动化,预测试性,以及可重复的测试。但是仍有很多系统无法解决现实的问题。

因为这样的测试方式所能解决的仅是软件开发要面对的问题中的一部分。如何才能发现真正的问题?最终还是要让你的软件与它的外部资源连接起来运行才能发现。

举个略为抽象的例子:

 1) 一些来自外部系统的数据.

 2) 应用程序开始处理这些数据.

 3) 应用程序将处理后的数据发送到外部资源中 (一般是与第1步不同的数据)

 4) 外部数据拿到第3步的数据,在处理后再发送到应用程序.

 5) 再次接收到数据,并加以处理.

如此反复。


我们常用mocks/stubs或者类似的程序来产生第1步的数据来进行第2步的测试,而测试第5步时所使用的数据也是使用类似的方式产生的。其中第1步和第4步是不可靠,也是不可预计的,因为你根本不知道外部系统会给你什么数据。

第1步和第4步是程序在上线环境下要面对的,所以它们才是最需要关注的。

外部系统都很挑剔( External systems are finicky mean things)

对于一些e-Commerce系统,或者财务系统,各式的接口,各式的数据在各个系统间流转。


我们来谈一些高层次的问题:

1)理想情况下,当外部系统更改了要发送的数据,无论是是格式(format)或模式(schema),你希望会提前知道。这有些一厢情愿了。最近我曾与一个电子商务系统,外部数据系统的税务信息增加了一栏,同时需要应用程序调整内部逻辑。就是外部数据系统已经开始发送数据了,我们才知道的。


2)理想情况下,当外部系统声称支持新的API,你应该改变应用程序的内部逻辑,并且发送新数据。最后,你会发现,他们支持新的API,要么在他们的UAT(User Acceptance Test)环境而不在上线(PRODUCTION)的环境,或者只在上线环境中而不在UAT环境中。


3)你的程序已使用关于国内资产的采购信息很顺畅了,外部系统和程序的配合也很好。然后开始加入一些国际资产信息时,你可能并不能及时地发现数据已完全变了。

这些都是我曾遇到的场景。我要说就是你在单元测试中根据无法了解到未来面对的环境,只有实际运行时才有办法。更悲哀的是那些在凌晨3点把你叫起来的问题通常都这样产生的。

如何完善测试规格(How to setup your Specs)

我做设计也是从规格文档开始的。规格(specification)其实就是另一种测试(well-crafted tests)。我会区分规格中的单元和集成,并写不同的代码。

所谓“单元”的测试规格是测试内部的业务逻辑,看看有没有把东西都串起来了。就是在测试时提供一些场景,确保程序执行正确的逻辑,输出期望的结果。

而集成(Integration)的测试规格则和外部资源有关。直接提供一组外部资源数据,以及要返回的数据。这些是集成测试中实际关心的东西。 和外部资源的交互才能真正确定程序是否可以正常工作。

[只译出主要概念,详细内容请阅读原文!]
转载请注明出处: http://blog.csdn.net/horkychen
作者:HorkyChen 发表于2013-3-18 1:55:42 原文链接
阅读:151 评论:0 查看评论

相关 [集成测试 单元测试] 推荐:

为什么集成测试比单元测试更重要

- - CSDN博客研发管理推荐文章
在假定一些数据的环境下,能顺利通过测试的系统就可算是一个好系统. 不过,现在可以直连外部资源的集成测试才让程序更有价值. 谁知道那些内容商(供应商,vendor)会做出什么傻事来. 很多人一直尝试着让测试达到100%的代码覆盖率,这是很棒的想法,但我倒觉得它有些基本概念上的问题. LosTechies,  Ryan Svihla 提出了"反模式(anti-pattern", 有个有趣的观点: “多数应用都需要与外部资源交互”.

Android单元测试

- - CSDN博客推荐文章
    单元测试不管对于初学编程还是已经工作了很久的开发者来说,都不乐意花时间去写认为没用的代码进行测试,只要交给测试人员就行了,虽然这样也能把软件改出来,但也许你要花上几倍的时间去修改问题,如果在开发的过程中花点时间去写单元测试代码,把尽可能出问题的地方都测试一遍,把问题扼杀在最开始的地方,这样你就不必为后来找问题出处而烦恼.

Android集成测试

- - 百度质量部 | 软件测试 | 测试技术 | 百度测试
  Android集成测试主要是在单元测试的基础上测试接口访问或者异步任务是否正确,在. 移动凤巢系统中,大概有30+个接口需要测试,他们都遵循一个特定的访问模式:前台的. Activity获取到触发事件后,将它传给这些接口,这些接口都是AsyncTask的实现——即后台. 异步线程执行某个任务(一般是发送http请求到后端服务或者执行存取数据库等耗时操作),.

Hadoop之MapReduce单元测试

- - ITeye博客
通常情况下,我们需要用小数据集来单元测试我们写好的map函数和reduce函数. 而一般我们可以使用Mockito框架来模拟OutputCollector对象(Hadoop版本号小于0.20.0)和Context对象(大于等于0.20.0). 下面是一个简单的WordCount例子:(使用的是新API).

springboot单元测试技术

- - 海思
整个软件交付过程中,单元测试阶段是一个能够最早发现问题,并且可以重复回归问题的阶段,在单元测试阶段做的测试越充分,软件质量就越能得到保证. 具体的代码参照 示例项目 https://github.com/qihaiyan/springcamp/tree/master/spring-unit-test.

“单元测试要做多细?”

- - 酷壳 - CoolShell.cn
这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests?”. 一个有13.8K的分的人( John Nolan)问了个关于TDD的问题,他说——. “TDD需要花时间写测试,而我们一般多少会写一些代码,而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了,这会不会太过分了.

文章: Android中的单元测试

- - InfoQ cn
随着Agile的普及,以及开发人员对测试重要性的认识逐步加深,单元测试已经成了越来越多软件项目开发中不可缺少的一部分. 无论项目是不是采用TDD的形式来进行开发,单元测试都能够为项目的修改和重构提供一定的保障. 有奖参与:天翼伦敦会,上传应用,为中国队加油. QClub七月技术沙龙(太原/北京/上海/厦门/西安 7月21/28/29日 免费报名中.

迈出单元测试的第一步

- - 酷勤网-挖经验 [expanded by feedex.net]
单元测试不仅是软件行业的最佳实践,在敏捷方法的推动下,它也成为了可持续软件生产的支柱. 年度敏捷调查,70%的参与者会对他们的代码进行单元测试. 单元测试和其他敏捷实践密切相关,所以开始编写测试是组织向敏捷转型的踏脚石. 我将在本文介绍符合要求的小技巧,以及在开发周期里进行单元测试的步骤. 没有自动化,单元测试的习惯也不会持续太久.

iOS开发进阶之单元测试

- - 博客园_首页
本文侧重讲述如何在iOS程序的开发过程中使用单元测试. 使用Xcode自带的OCUnit作为测试框架. 单元测试作为敏捷开发实践的组成之一,其目的是提高软件开发的效率,维持代码的健康性. 其目标是证明软件能够正常运行,而不是发现bug(发现bug这一目的与开发成本是正相关的,虽然发现bug是保证软件质量的一种手段,但是很显然这与降低软件开发成本这一目的背道而驰).

Java 单元测试利器之 Junit

- - 博客园_首页
          因为工作和学习的需要,在代码中查错的时候,第一步就是想知道这个错误具体发生在一个位置,进行一个准确的定位. 而这个定位的工作交给谁来做了呢. 不难猜出也就是这篇博客的主题---Junit. junit是一个开源的框架,也是java这一块的测试工具之一. 想了解详细请上官网,下面用代码来跟大家解释.