持续集成：自动化测试篇

　　前言

　　如果组件A\B\C的可靠性都为90%，是否说明了A\B\C组成的系统整体可靠性为90%？其实不是，实际结果是 90% * 90% * 90%* = 73%。大部分软件系统都由几百个甚至几千个对象组成，如果包含了100个组件的线性系统，每个组件的可靠性均为99%，那么整个系统的可靠性只有37%。

　　如果想要构建一个在服务层面承诺到达100%或接近100%的软件系统，则必须在单个对象层面上确保可靠性。如果不能从最低层面确保并测量可靠性，就不可能在系统层面上达到要求。

　　这就要求我们在每当系统发生变更时测试都必须执行，并且这些测试不单单是单元测试，还应包括组件测试、系统测试等，在日常的开发过程中，反复进行多种测试无疑是枯燥乏味的，在CI系统中包含持续测试则能让你轻松解决这一烦恼。

　　自动化单元测试

　　“单元测试”是验证软件系统中所有小元素的行为，这些小元素通常都是一个类。有时单元测试和被测试的类之间一对一的关系也会被放大，因为一些测试的类耦合程度较高。

　　单元测试没有外部依赖关系，不会依赖于文件系统和数据库。因为编码和看到单元测试之间的时间很短，所以单元测试是一种有效的除错方法。在进行持续集成过程的单元测试时，可以利用NUnit或JUnit单元测试框架，让单元测试自动化。

　　真正的单元测试应该少于1秒的时间内完成。如果花费的时间较长就需要检查一下，它是否失败了，或者它实际是一个组件级测试。配置自动化测试需要一些代价，但是执行这些测试的资源代价可以忽略不计。

　　自动化组件测试

　　“组件测试”或“子系统测试”验证的是系统的各个部分，可能需要安装整个系统或某些外部依赖关系，如数据库、文件系统、网络终端等。

　　典型的组件测试需要底层数据库支持，甚至可能跨越架构边界，这些测试涉及更多对象，每个测试的代码覆盖率也更大，通常比单元测试需要花更长的时间，如果用到数据库可以使用DbUnit\NDbUnit实现自动化。

　　组件测试执行的时间比较长，可以作为次级构建的一部分来执行或定期执行。

　　自动化系统测试

　　“系统测试”允许整个软件系统，需要完整安装系统，系统测试比组件测试执行时间更长，通常涉及多个组件。

　　如果事先已成功执行单元测试和组件测试，则已解决一些底层问题，只需要计划定期执行这个耗时较长的测试就可以。也可以作为次级集成构建的一部分，在下班后或夜间执行。

　　自动化功能测试

　　“功能测试”也称为“验收测试”，从用户的角度测试应用程序，意味着测试将模仿用户行为，通常是自动化测试套件中执行时间最长的。

　　开发者测试分组

　　通过将测试分组，按不同的时间间隔来执行较快（如单元测试）和较慢的（如组件测试）测试，顺序可以设置为：单元测试、组建测试、系统测试、功能测试。

　　可以“告诉”CI系统在恰当的时候执行每一类测试，构建次数完全可管理，测试定期执行，而不是当它们需要很长时间执行时就抛弃它们。

　　为缺陷编写测试

　　开发者测试和CI可以减少缺陷发生的频率，但是缺陷仍然会产生。我们通常在发现缺陷时，会需要找出缺陷代码、隔离有问题的代码，并修复它。但是，一个可促进质量提升的流程并不止于此。步骤应如下：

　　1）编写一个会失败的测试用例，不断执行这个测试（在修复缺陷的过程中），直到测试不在失败为止。

　　2）在这种情况下，很难正确地使用一个断言编写将会失败的测试。因此，断言可能不会加入，及时测试用例不再失败时，也不会加入断言。测试用例不一定是通过了，只是没有失败而已。

　　3）在这个过程的某个时刻，需要知道修复将怎样影响代码的行为，在尝试编写会失败的测试时，需要猜想修复可能是怎样的。

　　4）当被测试代码进行修复后，失败的测试可以工作了，蛋挞并没有真正验证行为的变更。为了修复缺陷，我们需要破坏测试。

　　5）直到被测试的代码确信已被修复，在执行测试，这次它会失败。

　　6）在修复我们的测试用例时，我们断言新的行为。我们断言当无效的单词传递给findword方法时，会返回null，我们需要断言不会抛出异常了。

　　整个流程中，我们做了两件事：首先，缺陷被更正了；其次，我们有了一个回归测试，真正地断言了修复后的正确行为，防止缺陷再次发生。根据新的缺陷编写测试，增加代码覆盖率，确保缺陷不会再次出现。

　　组件测试可重复

　　利用数据库测试框架确保数据处于“已知状态”，有利于组件测试可重复。

　　测试用例限制断言

　　将测试用例限制为一个断言，减少追踪测试失败原因花费的时间。