持续集成：自动化测试篇

1、持续集成：自动化测试篇前言如果组件ABC的可靠性都为90%是否说明了 ABC组成的系统整体可靠性为90% ?其实不是，实际结果是90% * 90% * 90%* = 73%。大部分软件系统都由几百个甚至几 千个对象组成，如果包含了 100个组件的线性系统，每个组件的可靠性均为99%，那么整 个系统的可靠性只有37%。如果想要构建一个在服务层面承诺到达100%或接近100%的软件系统，则必须在单个 对象层面上确保可靠性。如果不能从最低层面确保并测量可靠性，就不可能在系统层面上达 到要求。这就要求我们在每当系统发生变更时测试都必须执行，并且这些测试不单单是单元型， 还应包括组件测试、系统测试等，在

2、日常的开发过程中，反复进行多种测试无疑是枯燥乏味 的，在CI系统中包含持续测试则能让你轻松解决这一烦恼。自动化单元测试单元测试是验证软件系统中所有小元素的行为，这些小元素通常都是一个类。有时 单元测试和被测试的类之间一对一的关系也会被放大，因为一些测试的类耦合程度较高。单元测试没有外部依赖关系，不会依赖于文件系统和数据库。因为编码和看到单元测试 之间的时间很短所以单元测试是一种有效的除错方法。在进行持续集成过程的单元测试时， 可以利用NUnit或JUnit单元测试框架，让单元测试自动化。真正的单元测试应该少于1秒的时间内完成。如果花费的时间较长就需要检查一下， 它是否失败了，或者它实际是一个组

3、件级测试。配置自动化测试需要一些代价，但是执行这 些测试的资源代价可以忽略不计。自动化组件测试组件测试或子系统测试验证的是系统的各个部分，可能需要安装整个系统或某 些外部依赖关系，如数据库、文件系统、网络终端等。典型的组件测试需要底层数据库支持甚至可能跨越架构边界这些测试涉及更多对象， 每个测试的代码覆盖率也更大，通常比单元测试需要花更长的时间，如果用到数据库可以使 用DbUnitNDbUnit实现自动化。组件测试执行的时间比较长，可以作为次级构建的一部分来执行或定期执行。自动化系统测试系统测试”允许整个软件系统，需要完整安装系统，系统测试比组件测试执行时间更 长，通常涉及多个组件。如果事先已

4、成功执行单元测试和组件测试，则已解决一些底层问题，只需要计划定期执 行这个耗时较长的测试就可以。也可以作为次级集成构建的一部分，在下班后或夜间执行。自动化功能测试功能测试也称为验收测试，从用户的角度测试应用程序，意味着测试将模仿用 户行为，通常是自动化测试套件中执行时间最长的。开发者测试分组通过将测试分组，按不同的时间间隔来执行较快（如单元测试）和较慢的（如组件测试） 测试，顺序可以设置为：单元测试、组建测试、系统测试、功能测试。可以告诉”以系统在恰当的时候执行每一类测试，构建次数完全可管理，测试定期 执行，而不是当它们需要很长时间执行时就抛弃它们。为缺陷编写测试开发者测试和CI可以减少缺陷发

5、生的频率，但是缺陷仍然会产生。我们通常在发现缺 陷时，会需要找出缺陷代码、隔离有问题的代码，并修复它。但是，一个可促进质量提升的 流程并不止于此。步骤应如下：1）编写一个会失败的测试用例，不断执行这个测试（在修复缺陷的过程中），直到测 试不在失败为止。2）在这种情况下，很难正确地使用一个断言编写将会失败的测试。因此，断言可能不 会加入，及时测试用例不再失败时，也不会加入断言。测试用例不一定是通过了，只是没有 失败而已。3）在这个过程的某个时刻，需要知道修复将怎样影响代码的行为，在尝试编写会失败 的测试时，需要猜想修复可能是怎样的。4）当被测试代码进行修复后，失败的测试可以工作了，蛋挞并没有真正验证行为的变 更。为了修复缺陷，我们需要破坏测试。5）直到被测试的代码确信已被修复，在执行测试，这次它会失败。6）在修复我们的测试用例时，我们断言新的行为。我们断言当无效的单词传递给 findword方法时，会返回null，我们需要断言不会抛出异常了。整个流程中，我们做了两件事：首先，缺陷被更正了；其次，我们有了一个回归测试， 真正地断言了修复后的正确行为，防止缺陷再次发生。根据新的缺陷编写测试，增加代码覆