我一直独自工作，我的测试方法通常经常进行编译，并确保我所做的更改能够很好地工作，如果不这样做就能解决问题。但是，我开始觉得这还不够，我对标准的测试类型感到好奇。
有人可以告诉我有关基本测试的信息，每个测试的简单示例，以及使用它/测试的原因吗？
感谢。
答案 0 :(得分：19)
不同的人对于什么样的测试构成了一些略有不同的想法，但这里有一些关于我认为每个术语的含义的想法。请注意，这很大程度上偏向于服务器端编码，因为我倾向于这样做：）
单元测试
单元测试应该只测试一个逻辑单元代码 - 通常是整个测试用例的一个类，以及每个测试中的少量方法。单元测试（理想情况下）小而且便宜。与依赖项的交互通常使用 test double 隔离，例如mock，fake或stub。
整合测试
集成测试将测试不同组件如何协同工作。外部服务（不属于项目范围的部分）可能仍然被伪造以提供更多控制，但项目本身内的所有组件都应该是真实的。集成测试可以测试整个系统或某个子集。
系统测试
系统测试就像集成测试，但也有真正的外部服务。如果这是自动化的，通常将系统设置为已知状态，然后测试客户端独立运行，发出类似真实客户端的请求（或其他），并观察效果。外部服务可以是生产服务，也可以是仅在测试环境中设置的服务。
探测测试
这就像一个系统测试，但是使用生产服务来处理所有事情。它们会定期运行以跟踪系统的运行状况。
验收测试
这可能是最不明确的术语 - 至少在我看来;它可以有很大的不同。它通常是相当高的级别，如系统测试或集成测试。验收测试可以由外部实体（标准规范或客户）指定。
黑匣子还是白盒？
测试也可以是“黑盒子”测试，它只接触公共API，或“白盒子”测试，利用一些额外的知识使测试更容易。例如，在白盒测试中，您可能知道所有公共API方法都使用了特定的内部方法，但更容易测试。您可以通过直接调用该方法来测试许多极端情况，然后使用公共API执行更少的测试。当然，如果您正在设计公共API，您可能应该将其设计为易于测试 - 但它并不总是那样。通常能够独立地测试一个小方面是很好的。
另一方面，黑盒测试通常不如白盒测试脆弱：根据定义，如果你只测试API在合同中保证的内容，那么实现可以在没有测试的情况下尽可能多地改变改变。另一方面，白盒测试对实现更改很敏感：如果内部方法发生微妙变化 - 或者例如获得额外参数 - 那么您需要更改测试以反映这一点。
这一切都归结为平衡，最终 - 测试水平越高，黑盒子的可能性越大。另一方面，单元测试可能包括白盒测试的元素......至少在我的经验中。有很多人拒绝使用白盒测试，只有曾测试公共API。对我来说，这对我来说比较务实，但我也能看到它的好处。
开始
现在，至于你应该去哪里 - 单元测试可能是最好的开始。您可以选择在设计课程之前编写测试（测试驱动开发），或者在大致相同的时间，甚至几个月后编写测试（不理想，但是有很多代码没有测试但是应该） 。你会发现你的一些代码比其他代码更容易进行测试......使测试可行的两个关键概念（IMO）是依赖注入（编码到接口并为你的类提供依赖，而不是让它们自己实例化那些依赖项）和测试双精度（例如，模拟框架可以让你测试交互，或虚假的实现，它们在内存中以简单的方式完成所有事情）。 / p>
答案 1 :(得分：1)
我建议至少阅读有关这方面的书，因为这个领域非常庞大，书籍往往会综合出更好的概念。 例如。一个非常好的基础可能是：Software Testing Testing Across the Entire Software Development Life Cycle (2007)
我认为这样一本书可能比我们在这里发布的一些脱离背景的例子更能解释一切。
答案 2 :(得分：1)
嗨......我想补充一下Jon Skeet Sir的答案。 基于白盒测试（或结构测试）和黑盒测试（或功能测试），以下是各个类别下的其他测试技术：
压力测试
这用于测试系统上的大量数据。不仅仅是系统通常需要的东西。如果一个系统可以承受这些卷，它肯定能很好地取正常值。
<强> E.g。
可能是您可以采取系统溢出条件，例如尝试提取超过您的银行余额中的可用余额不应该工作，并且撤销到最大阈值应该有效。
在
时使用这主要用于我们您不确定系统可以处理的卷。
执行测试
完成以检查系统的熟练程度。
例如
计算交易的周转时间。
在以下情况下使用： 在开发过程的早期阶段，看看是否符合性能标准。
恢复测试
查看系统是否可以在失败后恢复原始状态。
<强> E.g。
非常常见，例如在日常生活中是Windows操作系统中存在的系统还原。 人们都知道，它们具有用于恢复的恢复点。
在以下情况下使用：
当用户认为对他/她来说至关重要的应用程序已经停止工作并且应该继续工作时，他会执行恢复。
您可以使用的其他类型的测试包括： -
运营测试
合规性测试
安全测试
需求测试
回归测试
错误处理测试
手动支持测试
系统间测试
控制测试
并行测试
质量保证协会（QAI）的William Perry有一本非常好的书，名为“软件测试的有效方法”，如果你想深入了解，我认为这是必读的。软件测试。
本书中肯定会提供有关上述测试类型的更多信息。
还有另外两个非常广泛的测试类别，即
手动测试：这是针对用户界面完成的。
自动化测试：测试基本上涉及白盒测试或测试完成 通过Load Runner，QTP等软件测试工具。
最后，我想提一下名为
的特定类型的测试穷举测试
在这里，您尝试测试每个可能的条件，因此名称。由于测试条件的数量可能是无限的，因此人们会注意到这是不可行的。
答案 3 :(得分：0)
首先，可以执行各种测试。问题是如何组织它。测试是一个巨大的＆amp;享受过程。
开始测试 1.Smoke测试。一旦通过，继续进行功能测试。这是测试的主干。如果功能正常，那么80％的测试是有利可图的。
2.现在进行用户界面测试。有时，用户界面吸引客户的不仅仅是功能。这是外观＆amp;觉得客户对它更感兴趣。
3.现在是时候看看化妆品漏洞了。通常，由于时间限制，这些错误被忽略。但这取决于它所找到的页面，它们起着重要作用。在启动画面或您的登录页面或应用程序名称本身上找到拼写错误时会变为重大错误。因此，这些也不容忽视。
4.进行兼容性测试。我，各种浏览器的测试＆amp;浏览器版本。可能是设备＆amp;响应式应用程序的操作系统。
快乐测试：）