51Testing独家连载:程序开发人员测试指南

发表于:2018-5-03 09:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:51Testing    来源:51Testing软件测试网原创

分享:
  【前 言】
  4年前开始写这本书的时候,我已经明确了本书写什么内容,面向的是哪些读者。4年是相当长的时间,期间我已经修正了我的某些想法和假设,这既是出于对本领域其他工作的呼应,也是由于对这个课题更深入的思考。近年来这个课题最明显的变化就是,关于它的争论变少了。最近出版的好几本书都与本书持有类似的观点,这让我感到宽慰,我认为这些观点都是朝着正确方向发展。
  为什么写这本书
  我写这本书,是因为我在10年前就想读到这样的一本书!10年是一个相当长的时间,但是,无论你信或不信,今天我仍然需要这本书--尽管是出于不同的原因。
  大约10年前,我开始了软件质量的研究旅程。那时我并不理解软件质量,我只知道我和我的同事们写的代码中充斥着缺陷,这些缺陷让我们沮丧,让客户不满。我相信,测试人员对我们的软件所做的、手工的常规检查,并不能显著提高产品的质量--时间也证明了,我是对的。于是,我开始读所有我能找到的关于软件匠艺(craftsmanship)和软件测试的书,从中我有两个主要的发现。
  首先,让我吃惊的是,这些书常常把课题完全割裂开来讨论!关于编写软件的书中,极少有关验证的内容。也许会提到一两种测试方法,但是却没有介绍相关的思想和概念框架,而这些内容对于"在不同情境下怎样使开发和测试开展有效协作"是必要的信息。至少,这些是我的印象。另一方面,与测试相关的书籍,常常从测试流程入手。类似地,测试驱动开发(TDD)的书,只聚焦于TDD如何应用于开发。不仅是书籍,博客和其他在线资料也是一样。
  其次,写出可测试的代码比我们最初想象的要难,更别提改造遗留代码使之变得可测试了。为了真正了解软件测试,我花了大量精力,深入思考、学习了软件开发技术、重构、遗留代码、TDD以及单元测试。
  基于这些研究和我积累的经验,我将本书的目标设定为以下几项。
  ·  让软件测试的基础知识更容易被开发人员理解,这样,他们就能够为即将发布的代码选择最合适的验证类型和级别。在我的经验中,许多开发者不会去读测试类的书或博客,尽管他们总是在问自己:测试是否足够?需要写多少测试用例?应该测试什么?我希望他们读完这本书会使这些问题变得十分容易。
  ·  演示测试的思维模式和技术如何帮助软件开发的日常工作,并展示如何使之成为开发者的第二特质。
  ·  为写出可测试的代码构建简单且足够好的知识和技术体系。我意识到这样的工作是非常难以被理解的,尤其是我还要保持这个体系的简洁,但是我仍希望建立一个足够完整的体系,将读者从成千上万的相关书籍和在线资料中解救出来。如果你想要的话,我会提供一份"领域知识地图"。
  这些就是写这本书的目的,这些想法10年前就有了,但是今天呢?难道这世界没有变化吗?工业界难道没有进步吗?真正令人感兴趣之处在于这本书和10年前一样适用。原因之一是本书的内容相对而言与技术无关,尽管仍有大量代码采用过程式编程,但面向对象编程已被广泛采用,也有一些代码采用的是函数式编程。另一个原因是本书所涵盖的这个领域,并没有像其他领域那样,取得令人激动的进步。的确,时至今日,许多开发者已经掌握了基础的测试能力,流行的架构和库中也鲜有完全不考虑可测试性的。然而我仍然认为,找到一个会用同构的JavaScript写前端、用在云平台上的NoSQL数据库做后台的开发者非常容易,而找到一个会做单元测试和重构,特别是在来自主管、同伴的进度压力下仍能坚持实践开发者测试的开发人员则难得多。
  作为一个专注于软件开发、培训和指导的顾问,我有幸参与了许多软件开发团队的工作,也观察过其他团队的工作。基于这些经验,我发现无论是开发团队还是开发人员,在质量保证上都经历了非常类似的学习曲线。本书的内容组织也符合这条学习曲线,而我则尽最大努力帮助读者克服困难,尽快取得进步。
  目标读者
  本书不适用于初学者,本书确实介绍了许多基本概念和基础技术,但是我们假设读者已经知道怎样在自己的开发环境下完成工作、构建系统,对于持续集成及其相关工具如静态检查、代码覆盖,也不陌生。本书最适合有3年以上专职软件开发经验的开发者,这样,读者在阅读的时候会发现其中的一些对话很熟悉,也能够将代码示例与这些对话联系起来,这些代码示例都是来自于真实产品,而非凭想象编写。
  最后希望本书的读者动手去做一做,尽管我的理想是让这些信息都唾手可得,但我仍将知识整合的工作留给读者自己完成,毕竟这不是一本烹饪手册。
  关于案例
  本书包含大量源代码,然而,我的目的并不是写一本编程的书,本书的重点是原理和实践。因此,这些从真实产品中提取的代码示例,采用的是各不相同的编程语言。尽管如此,我仍尽量采用各种语言通用的结构和语法习惯,因为我也不希望读者被某种特定语言或架构的某种特殊细节难住。也就是说,我尽量使这些案例有足够的普遍性,以便有一定经验的开发者都能够读懂。但是有时候这样做也很困难,一些特定的结构只有某种架构和语言能很好地实现。另一些时候,我无法判断哪种写法更普遍,这种情况下,可以在附录中找到其替代实现方案。本书中的源代码和其他相关代码,可以在本书的配套网站下载,网站地址为http://developertesting.rocks。
  如何阅读本书
  本书是为一群特定的读者所写:他们是背负进度压力的开发者,他们需要为特定的问题找到实用信息,他们不希望为此翻阅大量的文章、博客和书籍。因此,这里的潜台词就是,每个章节只需花不到一个小时就能读完,读者最好可以在工作间隙读完一章。相应地,每章节的内容各不相关,读者可以只读其中某些章节。尽管如此,仍建议先读完前四章,因为这几章是其他章节的基础。各章简介如下。
  第1章:开发者测试。开发人员在编码和验证环节中,事实上已经从事了很多测试活动,不管开发人员称不称之为测试。本章还给出了开发者测试的定义。
  第2章:测试的目的、方式和角色。介绍了不同的测试方法。解释了批判型测试与支持型测试的不同。本章第二部分是关于传统测试、敏捷测试,以及各种版本的行为驱动开发。开发者测试作为一种支持型软件测试的活动,更适合敏捷开发模式。
  第3章:测试术语。本章可以视为一个大的词汇表。本章解释了测试领域使用的术语,给出了一些常用模型,例如测试级别和测试类型矩阵、敏捷测试四象限。所有的术语都是以开发者的视角来解释的,对于有歧义或有不同解释的术语则给出了其各种解释。
  第4章:开发者眼中的可测试性。为什么开发者需要关注可测试性?本章给出了具备良好可测试性的软件实例,并明确了可测试性带来的好处。可测试性质量属性被分解为可观察性、可控制性、小规模,并对它们做了进一步说明。
  第5章:契约式编程。本章介绍了在软件开发中采用契约式编程的好处,无论在编码前是否先写出了用例,这种好处都是存在的。这种技术在被调用代码和调用代码之间约定了正式的责任和义务,这对于写出可测试性好的软件是很重要的。本章还介绍了断言的概念,在所有的测试框架中,断言都是核心概念。
  第6章:可测试性的驱动者。一些代码结构对可测试性就有很大的影响,因此,能够发现并辨别出这些结构就显得很重要。本章介绍了显性和隐性输入/输出、状态、时序耦合和域-值比率。
  第 7 章:单元测试。本章首先介绍了xUnit测试框架的基础知识。然后切入到单元测试更深入的话题,例如构建用例并为其命名、正确使用断言、基于约束的断言,以及单元测试的其他技术。
  第8章:基于规格说明的测试。这是测试的常规内容。本章从开发者的视角解释了基本的测试技术。了解这些,才能够回答"我需要写多少测试用例?"。
  第9章:依赖关系。类、组件、层之间的依赖关系,都会以不同的方式影响到可测试性。本章讲解了每种依赖关系及其影响,以及如何处理相应的问题。
  第10章:数据驱动与组合测试。本章介绍了如何利用参数化用例的方法和思想,处理那些看起来类似的测试用例。本章还介绍了比参数化用例更进一步的技术--生成式测试。最后,本章还介绍了一些测试工程师用来解决组合测试中用例数量暴增问题的相关技术。
  第 11 章:准单元测试。本书所指的单元测试,不包含那些运行起来几乎和单元测试一样快,但并不叫"单元测试"的测试方法。为了显性地区别两者,将后者称为"快速媒介测试"。这类测试最典型的是构建轻量级的服务器,例如servlet(小服务程序)容器、邮件服务器、内存数据库。本章就是介绍这些测试方法。
  第12章:测试替身。本章介绍典型的测试替身,例如桩对象(stub)、模拟对象(mock)、伪对象(fake)、哑对象(dummy)。本章的重点是理解测试替身的概念,无需理解任何一种mocking或其他技术的框架。本章还介绍了基于状态的测试与基于交互的测试之间的区别。
  第13章:模拟框架。本章具有很好的可操作性,文中应用模拟对象框架Moq、Mockito,以及测试替身工具Spock,为不同的场景、满足不同的需要而创建测试替身--主要是桩对象和模拟对象。本章还介绍了应用模拟框架时的陷阱与反模式。
  第14章:测试驱动开发--经典风格。本章基于一个完整的案例介绍了经典的测试驱动开发(TDD)。这个案例中展示了该技术的各种细节,如用例的编写顺序、测试执行的策略等。
  第15章:测试驱动开发--Mockist风格。TDD不止一种途径,本章就介绍了另一种TDD风格。与在一个具体的类或者组件的实现过程中应用TDD相比,测试驱动系统设计更为重要,本章用一个实例证明了这一点。
  第16章:复制。本章解释了为什么代码复制不利于可测试性,但是有时候为了独立性和开发效率的考量,复制又不可避免。本章介绍了两类复制形式:机械复制和知识复制。
  第17章:使用测试代码。本章包含了关于写测试代码前需要做的准备,以及何时删除测试代码的一些建议。
  第18章:超越单元测试。单元测试是开发者测试的基础,但这仅仅是测试工作的一小部分。时至今日,软件系统日趋复杂,因而需要不同抽象层次、不同粒度的测试,集成测试、系统测试,以及端到端测试应运而生。本章通过一系列案例介绍这些测试活动及其特征。
  第19章:测试思想与启发式。这是最后一章,在附录之前,将本书中的测试思想和启发式进行汇总。

51Testing软件测试网将在近期对本书部分章节进行独家连载,敬请关注
查看更多《51Testing软件测试网作品系列》:http://www.51testing.com/html/36/category-catid-136.html
54/5<12345>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号