不同的人对于测试的构成略有不同，但以下是我对每个术语的含义的一些想法。请注意，这严重偏向于服务器端编码，因为这就是我倾向于做的:)
单元测试
单元测试应该只测试一个逻辑代码单元 - 通常是整个测试用例的一个类，以及每个测试中的少量方法。单元测试（理想情况下）很小且运行成本低廉。与依赖项的交互通常用一个隔离测试替身例如模拟、伪造或存根。
集成测试
集成测试将测试不同组件如何协同工作。外部服务（不属于项目范围的服务）仍可能被伪造以提供更多控制，但项目本身内的所有组件都应该是真实的。集成测试可以测试整个系统或某个子集。
系统测试
系统测试类似于集成测试，但也使用真实的外部服务。如果这是自动化的，通常系统会被设置为已知状态，然后测试客户端独立运行，像真实客户端一样发出请求（或其他任何内容），并观察效果。外部服务可以是生产服务，也可以是在测试环境中设置的服务。
探测测试
这就像系统测试，但一切都使用生产服务。它们定期运行以跟踪系统的运行状况。
验收测试
这可能是最不明确定义的术语——至少在我看来；它可能会有很大差异。它通常是相当高的级别，例如系统测试或集成测试。验收测试可以由外部实体（标准规范或客户）指定。
黑盒还是白盒？
测试也可以是“黑盒”测试，即只涉及公共 API，也可以是“白盒”测试，即利用一些额外的知识来使测试变得更容易。例如，在白盒测试中，您可能知道所有公共 API 方法都使用特定的内部方法，但更容易测试。您可以通过直接调用该方法来测试大量极端情况，然后使用公共 API 进行较少的测试。当然，如果你是设计对于公共 API，您可能应该将其设计为易于测试 - 但它并不总是这样。通常，能够与班级其他人隔离地测试一个小方面是件好事。
另一方面，黑盒测试通常比白盒测试更脆弱：根据定义，如果您只测试 API 在其合同中保证的内容，那么实现可以根据需要进行更改，而无需更改测试。另一方面，白盒测试对实现更改很敏感：例如，如果内部方法发生微妙的更改 - 或者获得额外的参数 - 那么您将需要更改测试以反映这一点。
这一切都归结为平衡，最终——测试级别越高，黑盒的可能性就越大。另一方面，单元测试很可能包括白盒测试的元素......至少根据我的经验。有很多人根本拒绝使用白盒测试，只是ever测试公共 API。对我来说，这感觉更教条而不是务实，但我也看到了好处。
开始
现在，至于下一步应该去哪里——单元测试可能是最好的开始。您可以选择在设计类之前（测试驱动开发）或大约在同一时间甚至几个月后编写测试（不理想，但有很多代码没有测试但应该进行测试） 。您会发现您的某些代码比其他代码更适合测试......两者crucial使测试可行的概念（IMO）是依赖注入（对接口进行编码并向您的类提供依赖项，而不是让它们自己实例化这些依赖项）以及测试双打（例如，让您测试交互的模拟框架，或者在内存中以简单方式完成所有操作的虚假实现）。
