testing - 有哪些类型的测试？

Question

我一直独自工作，我的测试方法通常是经常编译，并确保我所做的更改正常工作，如果没有，则修复它们。但是，我开始觉得这还不够，我对那里的标准测试类型很好奇。

有人可以告诉我基本测试，每个测试的简单示例，以及为什么使用它/它测试什么？

谢谢。

Answer 1

不同的人对构成什么样的测试的想法略有不同，但这里有一些我碰巧认为每个术语的含义的想法。请注意，这严重偏向于服务器端编码，因为我倾向于这样做:)

单元测试

单元测试应该只测试一个逻辑代码单元——通常是整个测试用例的一个类，以及每个测试中的少量方法。单元测试(理想情况下)很小且运行成本低。与依赖项的交互通常用测试替身(例如模拟、假或 stub )隔离。

集成测试

集成测试将测试不同组件如何协同工作。外部服务(不属于项目范围的服务)可能仍然被伪造以提供更多控制权，但项目本身内的所有组件都应该是真实的。集成测试可以测试整个系统或某个子集。

系统测试

系统测试类似于集成测试，但也包含真正的外部服务。如果这是自动化的，通常系统会设置为已知状态，然后测试客户端独立运行，像真实客户端一样发出请求(或其他任何内容)，并观察效果。外部服务可能是生产服务，也可能是仅在测试环境中设置的服务。

探测测试

这就像一个系统测试，但一切都使用生产服务。它们会定期运行以跟踪系统的运行状况。

验收测试

这可能是定义最不明确的术语——至少在我看来；它可以有很大的不同。它通常是相当高的级别，如系统测试或集成测试。验收测试可以由外部实体(标准规范或客户)指定。

黑盒还是白盒？

测试也可以是“黑盒”测试，它只涉及公共(public) API，或者“白盒”测试，它利用一些额外的知识使测试更容易。例如，在白盒测试中，您可能知道所有公共(public) API 方法都使用特定的内部方法，但更容易测试。您可以通过直接调用该方法来测试许多极端情况，然后使用公共(public) API 进行较少的测试。当然，如果您正在设计公共(public) API，您可能应该将其设计为易于测试，但并非总是如此。通常，能够独立于类(class)其他人来测试一个小方面是很好的。

另一方面，黑盒测试通常不如白盒测试脆弱:根据定义，如果您只测试 API 在其契约(Contract)中保证的内容，那么实现可以随心所欲地更改，而无需更改测试。另一方面，白盒测试对实现更改很敏感:如果内部方法发生了微妙的变化——例如，或者获得了一个额外的参数——那么你需要更改测试以反射(reflect)这一点。

归根结底，这一切都归结为平衡——测试的级别越高，它就越有可能成为黑匣子。另一方面，单元测试很可能包括白盒测试的元素……至少在我的经验中是这样。有很多人根本拒绝使用白盒测试，只测试公共(public) API。对我来说，这感觉比务实更教条，但我也能看到好处。

出发

现在，至于下一步应该去哪里 - 单元测试可能是最好的开始。您可以选择在设计类之前(测试驱动开发)或大致同时，甚至几个月后编写测试(不理想，但有很多代码没有测试但应该) .你会发现你的一些代码比其他代码更适合测试......使测试可行(IMO)的两个关键概念是依赖注入(inject)(编码接口(interface)并为你的类提供依赖，而不是让它们实例化这些依赖自己)和测试替身(例如，让您测试交互的模拟框架，或在内存中以简单方式完成所有事情的假实现)。