品质管制及测试

一般原则

测试应该由与编写代码的人员不同的人员进行。
因此，测试是QC / QA工程师而非开发人员的责任。
QC工程师将编写自动测试，该测试将在每个请求请求进入主分支后运行。

测试金字塔

测试金字塔是一种思考方式，可以考虑使用各种自动测试来创建平衡的产品组合。关键点在于，通过GUI运行的高级BroadStackTests应该比高级UnitTests多得多。

在我的大部分职业生涯中，测试自动化意味着要通过用户界面驱动应用程序的测试。此类工具通常会提供便利来记录与应用程序的交互，然后允许您回放该交互，并检查应用程序是否返回了相同的结果。最初这种方法行之有效。记录测试很容易，并且测试人员可以在不了解编程的情况下进行记录。

但是这种方法很快就会遇到麻烦，变成了“冰淇淋蛋筒”。像这样通过UI进行测试很慢，从而增加了构建时间。通常，它需要安装测试自动化软件的许可证，这意味着只能在特定计算机上完成。通常，这些脚本无法轻松地在“无头”模式下运行，并且无法通过脚本进行监视，以将其置于适当的部署管道中。

单元测试

单元测试是在命名及其含义上得到更广泛接受的测试类别。它们是源代码附带的测试，可以直接访问它们。通常，它们是通过Unit framework或类似的库执行的。这些测试直接在源代码上运行，并具有所有内容的完整视图。测试了单个类/方法/功能（或该特定业务功能的最小可能工作单元），并且对其他任何事物进行了模拟/存根。

集成测试

集成测试（也称为服务测试，甚至是组件测试）专注于整个组件。组件可以是一组类/方法/函数，一个模块，一个子系统甚至是应用程序本身。他们通过传递输入数据并检查其产生的输出数据来检查组件。通常，首先需要某种部署/引导/设置。可以完全模拟，替换外部系统（例如，使用内存数据库而不是真实的数据库），或者可以根据业务情况使用实际的外部依赖关系。与单元测试相比，他们可能需要更专业的工具来准备测试环境或进行交互/验证。

第二类遭受模糊的定义，有关测试的大多数命名争议从此处开始。集成测试的“范围”也极富争议，尤其是访问应用程序的性质（黑盒或白盒测试以及是否允许模拟）。

作为基本经验法则

测试使用数据库
测试使用网络调用另一个组件/应用程序
测试使用外部系统（例如队列或邮件服务器）
测试读取/写入文件或执行其他I / O
测试不依赖源代码，而是使用应用程序的已部署二进制文件

…那么这是一个集成测试，而不是一个单元测试。

有了命名方式，我们就可以进入列表了。反模式的顺序大致遵循它们在野外时的外观。头等问题经常出现。

端到端（E2E）测试

即使使用单元测试和集成测试，您可能仍将需要少量的端到端测试来验证整个系统。为了在所有三种测试类型之间找到适当的平衡，最好使用的视觉辅助是测试金字塔。

您的大部分测试都是金字塔底部的单元测试。当您向上移动金字塔时，测试会变大，但同时测试的数量（金字塔的宽度）会变小。

作为一个很好的初步猜测，Google通常会建议采用70/20/10的比例：70％的单元测试，20％的集成测试和10％的端到端测试。每个团队的确切组合会有所不同，但通常，它应保持金字塔形状。尝试避免使用这些反模式：

**倒金字塔/冰淇淋锥。 **团队主要依靠端到端测试，很少使用集成测试，甚至更少的单元测试。
**沙漏。 **团队从大量的单元测试开始，然后使用端到端测试，应该使用集成测试。沙漏在底部有许多单元测试，在顶部有许多端到端测试，而在中间则没有集成测试。

就像常规金字塔往往是现实生活中最稳定的结构一样，测试金字塔也往往是最稳定的测试策略。

软件测试反模式

首先，请阅读Testing Anti-Patterns上的出色资源。

进行单元测试而不进行集成测试
进行集成测试而不进行单元测试
测试类型错误
测试错误的功能
测试内部实施
过度关注测试范围
具有片状或缓慢的测试
手动运行测试
将测试代码视为二等公民
不将生产错误转换为测试
将测试驱动设计（TDD）视为一种宗教
编写测试而不先阅读文档
出于无知而使不良声誉受到考验