构建安全体系

Written by - kok-s0s

C++

测试是一项技能，虽然这可能会让一些人感到惊讶，但这是一个事实。--- Mark Fewster and Dorothy Graham，《自动化软件测试》，1999W

POUT - Plain Old Unit Testing 普通的单元测试

TDD - Test-Driven Development 测试驱动开发

测试的必要性

因软件出错而导致的事故：

  1. 1962：NASA 的水手一号

  2. 1986：THERAC-25 医用加速器灾难

  3. AT&T 电话网络的崩溃事故

在复杂的系统，软件的质量是没有任何商量余地的，完全没有商量余地！

单元测试

没有测试的「 重构 」不能称之为重构，它仅仅只是到处移动垃圾代码。--- Corey Haines(@coreyhaines)，December 20，2013，on Twitter

C++ 单元测试框架：

关于 QA

QA - Quality Assurance 质量保证

我以前说过这个问题，现在我再说一遍，尽管你的公司可能有一个单独的 QA 小组来测试软件，但开发组的目标应该是 QA 没有发现任何缺陷。--- Robert C.Martin，《The Clean Coder》

交付 100% 无缺陷的软件是一个很难达到的目标。

QA 是安全体系的第二道防线。

良好的单元测试原则

  1. 单元测试的代码的质量

高质量地要求产品代码，同样高质量地要求单元测试的代码。

理论上，产品代码和测试代码之间不应该有任何区别 --- 它们生而平等。

  1. 单元测试的命名
  1. 单元测试的独立性

每个单元测试和其它的单元测试都必须是独立的。

  1. 一个测试一个断言

限制一个单元测试只使用一个断言。（有争议，开发者按实际情况自行判断）

  1. 单元测试环境的独立初始化

在运行所有单元测试时，每个单元测试都必须是应用程序的一个独立的可运行的实例，每个单元测试都必须完全自行设置和初始化其所需的环境，这同样适用于执行单元测试后的清理工作。

  1. 不对 getters 和 setters 做单元测试

这些函数太简单了，无需考虑测试。

不过还是看实际情况的。

  1. 不对第三方代码做单元测试

不使用那些没有自己的单元测试和质量可疑的库或框架，是一种明智的架构选择。

  1. 不对外部系统做单元测试

无视这些，只测试自己的代码，而不是别人的代码。

  1. 如何处理数据库的访问

我对这个问题的第一个也是最重要的建议是：能不使用数据库进行单元测试，就不使用数据库进行单元测试。--- Gerard Meszaros，xUnit Patterns

模拟数据库，只在内存中执行所有的单元测试。

如果系统中存在数据库的使用，在系统集成和系统测试级别会测试数据库。

  1. 不要混淆测试代码和产品代码

  2. 测试必须快速执行

  3. 测试替身

Top