敏捷开发笔记(第4章节)--测试

目录

1：PDF上传链接

4.1测试驱动的开发方法

4.1.1 一个测试优先设计的示例

4.1.2 测试促使模块之间隔离

4.1.3 意外获得的解耦合

4.2验收测试

4.2.1验收测试示例

4.2.2意外获得的构架

---

1：PDF上传链接

【免费】敏捷软件开发(原则模式与实践)资源-CSDN文库

4.1测试驱动的开发方法

        如果我们能够在设计程序前先设计测试方案，情况会怎么样？如果我们能够做到：除非缺乏某个功能将导致测试失败，否则就拒绝在程序中实现该功能，情况会怎么样？

        第一个也是最明显的一个影响，是程序中的每一项功能都有测试来验证它的操作的正确性。这个测试套件可以给以后的开发提供支援。无论何时我们因疏忽破坏了某些已有的功能，它就会告诉我们。有了这个流程，我们就可以更加自由的对程序进行改进。

        还有一个更重要但是不那么明显的影响，是首先编写测试可以迫使我们使用不同的观察点。我们必须从程序调用者的有利视觉去观察我们将要编写的程序。这样我们就会关注程序的功能的同时，直接关注它的接口。通过首先编写测试，我们就可以设计出便于调用的软件。

        此外，我们通过首先编写测试，我们就迫使自己把程序设计为可测试的。把程序设计为易于调用和可测试的，是非常重要的，为了易于调用和可测试，程序必须和周边环境解耦，这样首先编写测试迫使我们解除软件中的耦合。

        首先编写测试的另一个重要效果，是测试可以作为一种无价的文档形式。如果想知道如何调用一个函数或者创建一个对象，会有一个测试展示给你看。测试就像一套范例，他帮助其他程序员了解如何使用代码。这份文档是可编译、可运行的。它保持最新，它不会撒谎。

4.1.1 一个测试优先设计的示例

        

图4.1.1.1

4.1.2 测试促使模块之间隔离

        在编写产品代码之前，先编写测试常常会暴露程序中应该被解耦合的区域。例如图4.1.2.1展示的一个薪水支付应用的简单的UML图。

图4.1.2.1

        图4.1.2.2 展示了测试的意图

图4.1.2.2

4.1.3 意外获得的解耦合

        本书的大部分内容都是依赖性管理方面的设计原则。这些原则在解耦类和包方面提供了一些指导和技术。

4.2验收测试

        作为验证工具来说，单元测试是必要的，但是不够充分。单元测试是用来验证系统中个别机制的白盒测试。验收测试是用来验证系统满足客户需求的黑盒测试。

        验收测试是由不了解系统内部机制的人编写，客户可以直接或者和一些技术人员一起编写验收测试。，验收测试是程序，因此是可以运行的。

        验收测试行为对于系统的构架方面具有深远的影响，为了使系统具有可测试性，就必须要在很高的系统构架层面对系统进行解耦。

4.2.1验收测试示例

4.2.2意外获得的构架

4.3结论

        测试套件运行起来越来越简单，就会越频繁的运行它们，测试运行得越多，就会越快的发现和那些测试的任务背离。如果有一天多次运行所有的测试，那么系统失效的时间就绝不会超过几分钟，这是一个合理的目标，我们决不允许系统倒退，一旦它工作在一个确定的级别上，就决不能让它倒退到一个稍低的级别。