软件测试是实现软件或应用程序以识别bug或错误的过程。为了测试应用程序或软件，我们需要遵循一些原则来使我们的产品没有bug，这也有助于测试工程师用他们的精力和时间来测试软件。在这里，在本节中，我们将了解软件测试的七个基本原则。
让我们一一看看七种不同的测试原则：
- 测试显示存在bug
- 无法进行详尽测试
- 早期测试
- bug聚类
- 杀虫剂悖论（pesticide paradox）
- 测试依赖于上下文
- 错误谬论
测试显示存在bug
测试工程师将测试应用程序，以确保应用程序没有错误或bug。在进行测试时，我们只能确定应用程序或软件是否存在任何错误。进行测试的主要目的是借助各种方法和测试技术来识别未知错误的数量，因为整个测试应该可追溯到客户的需求，这意味着找到可能导致产品故障的任何bug以满足客户的需求。
通过对任何 应用程序，我们可以减少错误的数量，这并不意味着应用程序没有bug，因为有时软件在对其执行多种类型的测试时似乎没有错误。但是在生产服务器中部署时，如果最终用户遇到那些在测试过程中未发现的错误。 无法进行详尽测试
有时，在整个实际测试过程中，使用输入数据的有效和非有效组合来测试所有模块及其功能似乎非常困难。
因此，而不是执行详尽的测试，因为它需要无限的决心，并且大部分艰苦的工作都是不成功的。因此，我们可以根据模块的重要性完成这种类型的变化，因为产品时间表不允许我们执行此类测试场景。 早期测试
这里的早期测试意味着所有的测试活动都应该在软件开发生命周期的需求分析阶段的早期阶段开始，以识别bug，因为如果我们在早期阶段发现错误，它将在初始阶段本身得到修复，与测试过程的未来 阶段 相比，我们的成本可能要低得多。
要执行测试，我们将需要需求规范文档;因此，如果需求定义不正确，则可以直接修复，而不是在另一个阶段（可能是开发阶段）修复它们。 bug聚类
bug聚类定义了在整个测试过程中，我们可以检测与少量模块相关的错误数量。我们对此有多种原因，例如模块可能很复杂;编码部分可能很复杂，依此类推。
这些类型的软件或应用程序将遵循 帕累托 原则，该原则指出我们可以识别该近似值。80%的并发症存在于20%的模块中。借助此功能，我们可以找到不确定的模块，但是如果定期执行相同的测试，则此方法存在困难，因此相同的测试将无法识别新的bug。 杀虫剂悖论（pesticide paradox）
该原则定义，如果我们在特定时间内一次又一次地执行同一组测试用例，那么这些类型的测试将无法在软件或应用程序中找到新的错误。为了克服这些杀虫剂悖论（pesticide paradox），经常查看所有测试用例非常重要。并且需要编写新的和不同的测试来实现应用程序或软件的多个部分，这有助于我们找到更多错误。 测试依赖于上下文
测试是一个依赖于上下文的原则，说明我们有多个领域，如电子商务网站、商业网站等在市场上可用。有一种明确的方法来测试商业网站和电子商务网站，因为每个应用程序都有自己的需求、特性和功能。为了检查这种类型的应用程序，我们将借助各种测试，不同的技术，方法和多种方法。因此，测试取决于应用程序的上下文。 无错误谬论
一旦应用程序经过全面测试并且在发布之前没有发现错误，那么我们可以说该应用程序 99% 没有错误。但是，当应用程序在不正确的需求旁边进行测试，识别bug并在给定的时间段内修复它们时，有可能无济于事，因为测试是在错误的规范上进行的，这不适用于客户的需求。没有错误谬误意味着如果应用程序不切实际并且无法满足客户的需求和需求，识别和修复错误将无济于事。
|
