七个软件测试原则：通过案例来学习研究 - 所有文章

背景

在不偏离测试目标的情况下进行软件测试，获得最佳测试结果非常重要。但是如何确定你正在遵循正确的测试策略呢？因此，您需要坚持一些基本的测试原则。

以下是软件行业中广泛使用的常见七种测试原则。

要理解这一点，请考虑案例: 将文件从文件夹A移动到文件夹B的测试方案。

想想你可以测试它的所有可能方法， 除了正常的场景，还可以测试以下场景

如果您要测试整个可能的组合项目，执行时间和成本将呈指数级增长，所以我们需要某些原则和策略来优化测试工作。

是的！彻底的测试是不可能的。

相反，我们需要基于应用程序的风险程度评估出最佳测试工作量。

关键的问题是： 你如何确定这种风险？

要回答这个问题，我们来做一个练习

在你看来，哪种操作最有可能导致操作系统失败？

我相信大多数人都会猜到，同时打开操作系统中10个不同的应用程序。

因此，如果你正在测试此操作系统，你会意识到在多任务活动中可能会发现缺陷并需要进行彻底测试，这种初步分析将使我们进入下一个原则缺陷聚集。

缺陷聚集，说明少量模块包含了能测试到的大多数缺陷。这是帕累托原则在软件测试中的应用： 大约80%的问题出现在20%的模块中。

根据经验，你可以识别出这些风险模块，但是，这种方法有其自身的问题。

如果一遍又一遍地重复着相同的测试，最终将发现不了新的问题。

在农业过程中重复使用相同的农药混合物来消灭昆虫会随着时间的推移导致昆虫对农药产生抗药性，从而使杀虫剂对昆虫无效。这同样适用于软件测试。如果进行相同的重复测试集，则该方法对于发现新缺陷将是无用的。

为了解决这个问题，需要定期检查和修改测试用例，添加新的和不同的测试用例来帮助发现更多Bug。

测试人员不能简单地依赖现有测试技术。他必须不断注意改进现有测试方法，使测试更有效。但即使这样，在测试过程中经历了汗水和辛苦工作之后，你仍然无法宣称你的产品没有Bug。为了证明这一点，我们可以看一下往年发布的Windows操作系统。

你认为像微软这样的公司不会彻底测试他们的操作系统吗？我们只看到他们的操作系统windows 98在公开发布期间大量崩溃而声誉受损！

因此，测试原则指出----测试只会讨论缺陷的存在，而不是讨论缺陷的缺失。即软件测试降低了软件中未发现缺陷的可能性，但即使没有发现缺陷，也不能证明其测试方向的正确性。

不管怎么样，你努力工作，采取所有预防措施并使软件产品99％无错误，但是该软件仍然有可能不符合客户的需求和要求。

这引出了我们的下一个原则，该原则指出 - 没有缺陷

如果系统仅仅针对缺陷进行彻底测试，99%无缺陷的软件仍有可能出现无法使用的这种情况。软件测试不仅仅是发现缺陷，还可以检查软件是否满足业务需求。缺少缺陷是一种误解，如果产品开发完成后不可用并且无法满足用户的需求和要求，则查找和修复缺陷也无济于事。

为了解决这个问题，来说说下一个测试原则，尽早测试。

尽早测试 - 测试应尽早在软件开发生命周期中开始。因此，在早期阶段捕获需求或设计阶段的任何缺陷。在测试的早期阶段修复缺陷所花费的成本要小得多。但是，应该多早开始测试？建议你在定义需求时就开始介入。

测试工作依赖于上下级测试对象，这基本上意味着您测试电子商务网站的方式将与您测试桌面应用程序的方式不同。所有开发的软件都不相同。您可以根据应用程序类型使用不同的方法，策略，技术和测试类型。例如，零售店的任何POS系统都不同于测试ATM机。

谬论：“原则仅供参考。在实践中很难真正用上它们。”

这种说话非常不靠谱。测试原则就是帮助你去输出更有效的测试策略以及编写发现更多Bug的测试用例。

学习测试原理就像是第一次学习驾驶汽车一样，

当你刚刚学会驾驶时，你会注意每一件事，比如换档，速度，离合器处理等等。但是根据实际经验，其实你只需要专注于驾驶其余部分。这样你甚至可以与车内的其他乘客进行对话。

测试原则也是如此，经验丰富的测试人员已将这些原则消化到他们的脑子当中并且可以不加思索的应用它们。因此，这些原则在实践中没有用的谬论当笑话听听就好。