2.1.测试本身更有可能成为一项繁忙的任务。
2.2.糟糕的测试会增加开发人员的开销，而不会提供价值，并且还会增加测试套件的不稳定性。
3.1.该测试可以检查**是否正常工作。
3.1.1.测试本身可以验证软件的行为是否符合预期。
3.1.2.意外的软件行为可能会给用户、开发人员和操作员带来很多困惑。
3.1.3.测试此过程可以证明**已按规定生效。
3.2.保护**将来不会受到这些无意更改的影响。
3.2.1.测试可保护现有行为免受新更改的影响。
3.3.鼓励提神**。
3.4.迫使开发人员尝试自己的 API
3.4.1.编写测试还迫使开发人员考虑其程序的接口和实现。
3.4.2.编写测试还可以迫使开发人员通过分别改进关注点分离和减少紧密耦合来确保它们构造良好。
3.5.记录组件之间的交互方式。
3.5.1.测试实际上是另一种形式的文档，它说明了它们是如何交互的。
3.6.作为实验的“游乐场”
3.7.测试驱动开发。
3.7.1. test driven development，tdd
3.7.2.TDD 是指在编写测试之前编写测试的做法，如果测试在编写后无法运行测试，则编写测试以通过。
4.1.成功的项目在现实世界中做出务实的测试决策。
4.2.单元测试。
4.2.1.验证 ** 的“单位”
4.2.2.通常指单个方法或行为。
4.2.3.单元测试应该快速、简短且集中。
4.2.3.1.消除外部依赖关系可以使单元测试快速而集中。
4.2.4.模拟远程系统允许测试绕过网络调用，简化设置并避免缓慢运行。
4.2.5.模拟方法和对象允许开发人员编写集中式单元测试，这些测试只能完成一个特定的行为操作。
4.3.集成测试。
4.3.1.验证多个组件在集成在一起时是否正常工作。
4.3.2.如果你发现自己在测试中实例化了多个交互对象，那么你可能正在写关于集成测试的文章。
4.3.3.开发人员运行集成测试的频率较低，因此反馈周期较长。
4.3.4.您可以找到通过单独的单元测试难以发现的问题。
4.4.系统测试。
4.4.1.验证整个系统的整体运行情况。
4.4.2.端到端 （e2e） 工作流旨在模拟系统在预生产环境中与真实用户的交互。
4.5.性能测试。
4.5.1.监控不同配置下的系统性能。
4.5.2.负载测试可以监视不同负载级别的性能。
4.5.3.压力测试将系统上的负载推到崩溃的地步。
4.5.3.1.压力测试准确揭示了系统能够加载多少，以及在负载过大时会发生什么。
4.5.4.对于容量规划和 SLO 定义很有用。
4.6.验收测试。
4.6.1.指由客户或其**进行的测试，以验证交付的软件是否符合验收标准。
4.6.2.正式的验收测试和验收标准被指定为昂贵合同的一部分。
4.6.3.国际标准化组织 （ISO） 要求通过验收测试来验证明确的业务需求，作为其安全标准的一部分。
4.6.3.1.ISO认证审核委员会要求提供要求和相应的测试文件证据。
5.1.用于编写测试用例的工具。
5.1.1.例如，模拟库可以帮助您编写干净高效的测试。
5.1.2.模拟库通常用于单元测试，尤其是在面向对象的库中。
5.1.3.模拟库还可以防止应用程序的 ** 被特定于测试的方法、参数或变量所干扰。
5.1.4.模拟库可帮助开发人员访问受保护的方法和变量，而无需修改规范。
5.1.5.对模拟库的过度依赖是一种异味，表明紧密耦合。
5.2.测试框架。
5.2.1.通过模拟测试的生命周期（从设置到拆卸），促进测试的运行。
5.2.1.1.管理测试设置和拆卸
5.2.1.2.管理测试执行和编排。
5.2.1.2.1.您可以通过编排测试过程来帮助控制测试的速度和隔离。
5.2.1.2.2.串行测试是一个接一个地执行的，一次执行一个测试更安全，因为测试相互作用的可能性较小。
5.2.1.2.3.并行执行速度更快，但由于共享状态、资源或其他污染，它更容易出错。5.2.1.3.生成测试结果报告。
5.2.1.3.1.帮助开发人员调试那些失败的生成任务。5.2.1.4.提供扩展断言方法等工具。
5.2.1.5.与 Coverage 工具集成。
5.2.2.还可以保存测试结果，与构建系统集成，并提供其他可访问性功能。
5.3.* 质量工具。
5.3.1.用于执行质量规则的工具称为 linter，linter 可以运行静态分析并执行样式检查。
5.3.2.对质量检验不合格者，要务实。
5.3.3.不要让事情变得更糟，但也要避免以破坏性地停止一切的方式清理项目。
5.3.4.用于分析覆盖率和复杂性。
5.3.4.1.* 复杂度工具可用于计算圈复杂度。
5.3.4.1.1.大致按路径数量来防止过于复杂的逻辑。
5.3.4.1.2.复杂性越高，测试难度越大，包含错误的可能性就越大
5.3.4.1.3.圈的复杂度通常随着库的大小而增加，因此高总分并不一定是坏事。5.3.4.2.覆盖率工具用于测量测试套件已执行的行数。
5.3.4.2.1.如果修改较低的覆盖率，则应编写更多测试用例。
5.3.4.2.2.确保可以针对您所做的任何新更改验证测试用例，并以合理的覆盖率为目标。
5.3.4.2.2.1.经验在65%到85%之间。
5.3.4.2.3.覆盖率本身并不能衡量测试质量。
5.3.4.2.3.1.无论是在高覆盖率还是低覆盖率时，它都可能非常具有误导性。
5.3.4.2.3.2.为了 100% 的覆盖率而痴迷于创建单元测试并不能保证您的测试能够安全地集成。5.3.5.通过静态分析查找错误
5.3.6.检查样式错误。
5.3.6.1.样式检查工具可确保所有源的格式都相同。
5.3.6.2.每行最大字符数、骆驼命名法和蛇形命名法、适当的缩进。
5.3.6.3.一致的风格有助于多个程序员在共享库上进行协作。
5.3.6.4.强烈建议您设置 IDE，以便可以自动应用所有样式规则。
5.3.7.它通常作为生成或编译步骤的一部分运行。