有哪些类型的测试? [英] What kinds of tests are there?

问题描述

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

I've always worked alone and my method of testing is usually compiling very often and making sure the changes I made work well and fix them if they don't. However, I'm starting to feel that that is not enough and I'm curious about the standard kinds of tests there are.

谁能告诉我基本测试、每个测试的简单示例，以及为什么使用它/它测试什么?

Can someone please tell me about the basic tests, a simple example of each, and why it is used/what it tests?

谢谢.

推荐答案

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

Different people have slightly different ideas about what constitutes what kind of test, but here are a few ideas of what I happen to think each term means. Note that this is heavily biased towards server-side coding, as that's what I tend to do :)

单元测试

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

A unit test should only test one logical unit of code - typically one class for the whole test case, and a small number of methods within each test. Unit tests are (ideally) small and cheap to run. Interactions with dependencies are usually isolated with a test double such as a mock, fake or stub.

集成测试

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

An integration test will test how different components work together. External services (ones not part of the project scope) may still be faked out to give more control, but all the components within the project itself should be the real thing. An integration test may test the whole system or some subset.

系统测试

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

A system test is like an integration test but with real external services as well. If this is automated, typically the system is set up into a known state, and then the test client runs independently, making requests (or whatever) like a real client would, and observing the effects. The external services may be production ones, or ones set up in just a test environment.

探索性测试

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

This is like a system test, but using the production services for everything. These run periodically to keep track of the health of your system.

验收测试

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

This is probably the least well-defined term - at least in my mind; it can vary significantly. It will typically be fairly high level, like a system test or an integration test. Acceptance tests may be specified by an external entity (a standard specification or a customer).

黑盒还是白盒?

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

Tests can also be "black box" tests, which only ever touch the public API, or "white box" tests which take advantage of some extra knowledge to make testing easier. For example, in a white box test you may know that a particular internal method is used by all the public API methods, but is easier to test. You can test lots of corner cases by calling that method directly, and then do fewer tests with the public API. Of course, if you're designing the public API you should probably design it to be easily testable to start with - but it doesn't always work out that way. Often it's nice to be able to test one small aspect in isolation of the rest of the class.

另一方面，黑盒测试通常不如白盒测试脆弱:根据定义，如果您只测试 API 在其合同中保证的内容，那么实现可以在没有测试的情况下随意更改改变.另一方面，白盒测试对实现更改很敏感:如果内部方法发生了微妙的变化——例如，或者获得了一个额外的参数——那么你需要更改测试以反映这一点.

On the other hand, black box testing is generally less brittle than white box testing: by definition, if you're only testing what the API guarantees in its contracts, then the implementation can change as much as it wants without the tests changing. White box tests, on the other hand, are sensitive to implementation changes: if the internal method changes subtly - or gains an extra parameter, for example - then you'll need to change the tests to reflect that.

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

It all boils down to balance, in the end - the higher the level of the test, the more likely it is to be black box. Unit tests, on the other hand, may well include an element of white box testing... at least in my experience. There are plenty of people who would refuse to use white box testing at all, only ever testing the public API. That feels more dogmatic than pragmatic to me, but I can see the benefits too.

开始

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

Now, as for where you should go next - unit testing is probably the best thing to start with. You may choose to write the tests before you've designed your class (test-driven development) or at roughly the same time, or even months afterwards (not ideal, but there's a lot of code which doesn't have tests but should). You'll find that some of your code is more amenable to testing than others... the two crucial concepts which make testing feasible (IMO) are dependency injection (coding to interfaces and providing dependencies to your class rather than letting them instantiate those dependencies themselves) and test doubles (e.g. mocking frameworks which let you test interaction, or fake implementations which do everything a simple way in memory).

这篇关于有哪些类型的测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！