介绍软件测试7个基本原则，每个专业软件人员和QA专业人员都应该知道的。
一、背景
在不偏离目标情况下进行软件测试时，获得最佳测试结果是非常重要的。但是你如何确定你正在遵循正确的测试策略？为此，您需要坚持一些基本的测试原则，以下是软件行业中广泛使用的常见的七种测试原则。
要理解这一点，请考虑将文件从文件夹A移动到文件B的方案。
想想你可以测试它的所有可能方法
除了通常的场景，您还可以测试以下条件
尝试在文件打开移动文件
您没有将文件粘贴到文件B中安全的权限
文件夹B位于共享驱动器上，存储容量已满。
文件夹B已经有一个同名的文件，实际上列表是无穷无尽的
或者假设您有15个输入字段要测试，每个输入字段有5个可能的值，要测试组合数量为5 ^ 15
如果您要测试整个可能的组合项目，执行的时间和成本将成指数级增长。我们需要某些原则和策略来优化测试工作。
二、7条原则：
1）彻底的测试是不可能的
是的 ！彻底的测试是不可能的，相反，我们需要基于应用程序风险评估的最佳测试量。
百元美元问题是，你如何确定这种风险？
要回答这个问题，我们来做一个练习
在您看来，哪种操作最有可能导致操作系统失败？
我相信大多数人都会猜到，同时打开10个不同的应用程序。
因此，如果您正在测试此操作系统，您会意识到在多任务活动中可能会发现缺陷并需要进行彻底测试，这将使我们进入下一个原则缺陷聚类
2）缺陷聚类
缺陷聚类，表明少量模块包含检测到的大多数缺陷。这是帕累托原则在软件测试中的应用：大约80％的问题出现在20％的模块中。
根据经验，您可以识别出这些风险模块。但这种方法有其自身的问题
如果一遍又一遍地重复相同的测试，最终相同的测试用例将不再发现新的错误。
3）农药悖论
在农业过程中重复使用相同的农药混合物来消灭昆虫会随着时间的推移导致昆虫对农药产生抗药性，从而使杀虫剂对昆虫无效。这同样适用于软件测试。如果进行相同的重复测试集，则该方法对于发现新缺陷将是无用的。
为了解决这个问题，需要定期检查和修改测试用例，添加新的和不同的测试用例以帮助发现更多缺陷。
测试人员不能简单地依赖现有的测试技术。他必须不断注意改进现有方法，使测试更有效。但即使在测试过程中经历了这些汗水和辛苦工作之后，您仍然无法宣称您的产品没有错误。为了推动这一点，让我们看一下Windows 98公开发布的视频
您认为像MICROSOFT这样的公司不会彻底测试他们的操作系统，并且只会看到他们的操作系统在公开发布期间崩溃而冒着声誉的风险！
4）测试显示存在缺陷
因此，测试原则指出 - 测试会讨论缺陷的存在，而不是讨论缺陷的缺失。即软件测试降低了软件中未发现缺陷的可能性，但即使没有发现缺陷，也不能证明其正确性。
但是，如果你努力工作，采取所有预防措施并使你的软件产品99％无错误。该软件不符合客户的需求和要求。
这引出了我们的下一个原则，该原则指出 - 缺少错误。
5）没有错误
99％无错误的软件仍有可能无法使用。如果系统针对错误的要求进行了彻底测试，则可能出现这种情况。软件测试不仅仅是发现缺陷，还可以检查软件是否满足业务需求。缺少错误是一种谬误，即如果系统构建不可用并且无法满足用户的需求和要求，则查找和修复缺陷无济于事。
为了解决这个问题，下一个测试原则表明早期测试
6）早期测试
早期测试 - 测试应尽早在软件开发生命周期中开始。因此，在早期阶段捕获需求或设计阶段的任何缺陷。在测试的早期阶段修复缺陷要便宜得多。但是，应该多早开始测试？建议您在定义需求时开始查找错误。在稍后的培训教程中更多关于此原则。
7）测试依赖于上下文
测试依赖于上下文，这基本上意味着您测试电子商务网站的方式将与您测试商业现成应用程序的方式不同。所有开发的软件都不相同。您可以根据应用程序类型使用不同的方法，方法，技术和测试类型。例如，零售店的任何POS系统都不同于测试ATM机。
七项测试原则摘要
|
原则1 |
测试显示存在缺陷 |
|
原则2 |
彻底的测试是不可能的 |
|
原则3 |
早期测试 |
|
原则4 |
缺陷聚类 |
|
原则5 |
农药悖论 |
|
原则6 |
测试取决于上下文 |
|
原则7 |
没有错误 - 谬误 |
神话：“原则仅供参考。我不会在实践中使用它们。”
这非常不真实。测试原则将帮助您创建有效的测试策略并起草错误捕获测试用例。
但学习测试原理就像是第一次学习驾驶一样。
最初，当你学会驾驶时，你会注意每一件事，比如换档，速度，离合器处理等等。但是根据经验，你只需要专注于驾驶其余部分。这样你甚至可以与车内的其他乘客进行对话。
测试原则也是如此。经验丰富的测试人员已将这些原则内化到他们即使不加思索地应用它们的水平。因此，这些原则在实践中没有被使用的神话根本就不是真的。