测试类型(单元、集成、系统或手动测试)

单元测试
单元是系统的单个组件，例如类或单个方法。孤立地测试单元称为单元测试。
优点：速度快/易控/易写
缺点：缺乏现实性/无法捕获所有错误（例如与其他组件或服务的交互）
单元测试是一种非常有用的测试类型，但其本身往往是不够的。

Integration Tests集成测试
单独测试是不够的。 有时代码会“超越”系统边界并使用其他（通常是外部）组件——例如，数据库。集成测试测试我们的代码与外部各方代码之间的集成。
示例：测试通过 SQL 查询访问数据库的方法。 我们的方法是否从数据库中获取了正确的数据？
优点：
可以捕获集成错误； 比编写遍历整个系统的系统测试更简单，包括我们不关心的组件
缺点：
很难写，例如：
• 需要使用一个独立的数据库实例
• 使其进入测试预期的状态
• 之后重置状态

系统测试
为了更真实地了解软件，我们还应该对其进行更真实的测试——包括它的所有数据库、前端和其他组件。
我们不关心系统内部是如何工作的。 我们关心给定某些输入，系统提供某些输出。
优势：
现实（当测试与最终用户的表现相似时，我们就越有信心系统会为所有最终用户正常工作）
坏处：
• 慢的！
• 难以编写（需要考虑大量外部服务）
• 容易剥落 Prone to Flakiness

手动测试
并不是所有的事情都可以用自动化的方式轻松测试，尤其是在有定性判断的地方（例如，搜索引擎结果的质量）。
此外，我们可能需要探索真实的系统行为以了解要编写哪些自动化测试。
手动测试是由人手动执行的系统测试。
副词：
真实（测试人员作为最终用户，实际使用系统）
禁用：
• 耗时
• 难以复制
• 乏味

The Test Triangle

例子：
(1) 我测试一个网络应用程序。 我加载网页，自动填写表格，点击按钮，然后检查生成的网页。
系统测试
（2）我是一个自动化测试，检查一个方法的结果
单元测试
(3)I 本质上是人类输入终端的一系列输入。 我不检查答案，我把它留给我的人。 我并没有以任何有形的形式真正“存在”，但有些人把我写进了文件，这样他们就知道如何复制我。
人工测试
(4)我是一个自动化测试，直接与使用数据库的代码进行交互。
整合测试