软件测试的七项原则
你好！👋
我是卢卡斯，一名巴西QA工程师，这是另一篇没人要求我写的QA内容（但我还是写了😂）。我写这个博客的目的是用我自己的方式谈论QA领域相关的话题，分享我的观点和看法。如果你喜欢，请关注我，我会发布更多类似的文章！
今天我想谈谈CTFL教学大纲第一章涵盖的一个主题。
诫命软件测试原则。（如果你没听懂，这是个关于摩西的双关语。）不再玩双关语了。
目前让我们一起打开这片知识的海洋吧！
1️⃣ 测试结果只能显示缺陷的存在，而不能显示缺陷的不存在。
许多质量保证工程师可能都遇到过以下情况：产品负责人甚至客户说你的工作是保证冲刺交付物没有缺陷。
测试是一种破坏性活动，其目的是使软件出现故障。测试人员编写测试用例的目的是为了发现缺陷，而不是为了证明软件没有缺陷。
因此，该原则指出，不可能保证测试对象完全没有缺陷。
需要注意几点：非QA人员可能会误解这条原则，将其视为QA人员工作不力的借口。另一方面，QA人员也可能滥用这条原则，为自己未能发现本应轻易发现的bug辩解。我个人认为，这条原则并非旨在为已进入生产环境的bug开脱，而是为了避免对产品和QA工作产生不切实际的期望。
2️⃣ 进行全面测试是不可能的
作为质量保证人员，你可能永远没有时间测试软件的每一个可能场景。
想象一个包含 3 个下拉选择框的小表单，每个选择框有 10 个选项。要测试所有可能的情况，需要 10³ = 1000 个测试用例。
我们可以使用一种称为等效分区的黑盒测试技术。简而言之，它将测试数据划分为多个分区，使得同一分区内的所有数据都以相同的方式进行处理。
甚至可能出现时间紧迫的情况。在这种情况下，更建议进行风险分析，并根据对业务风险的高低来优先安排测试。
3️⃣ 早期检测可节省时间和金钱
这一原则很可能是目前流行的左移测试方法的源头。它指出，测试活动应该在项目启动之初就尽快开始。
测试活动不仅限于在功能开发完成后执行或自动化端到端测试。测试人员还可以审查文档和需求，以防止错误和疏漏进入软件开发生命周期的后期阶段。记住，问题发现得越晚，修复成本就越高。
4️⃣ 缺陷聚集在一起
这条原则是帕累托原则的应用。也许你不知道它的名字，但你可能在某个地方听说过它。以下是它的简要介绍：
许多结果的产生，大约80%的后果是由20%的原因造成的。
在软件测试中，80% 的问题很可能存在于 20% 的模块/组件中。因此，当你发现一个 bug 时要格外小心，因为同一个功能中可能还隐藏着更多 bug。
5️⃣ 警惕杀虫剂悖论
为了解释这一点，我将借用 Guru99 一篇关于测试 7 个原则的文章中的一段话（您可以在下面的参考资料部分找到链接）。
在农业生产中反复使用同一种杀虫剂混合物来消灭害虫，时间长了会导致害虫对该杀虫剂产生抗药性。
因此，如果反复执行相同的测试用例，其有效性很可能会降低（有效的测试用例是指发现缺陷概率更高的用例）。正因如此，作为质量保证人员，您需要经常审查测试方法和测试用例。在需求频繁变化的敏捷项目中，这一点尤为重要。
6️⃣ 测试取决于上下文
这一原则阐述了不同的情境如何以不同的方式影响测试结果。
由于发布周期不同，敏捷项目中的测试方式与瀑布式项目中的测试方式不同。
由于涉及的风险不同，电子商务系统的测试方法与网上银行系统的测试方法也不同。
选择合适的回归测试自动化工具很大程度上取决于具体情况。随着经验的积累，你对所处环境的理解会越来越深入，从而更好地规划你的QA工作。
7️⃣ 没有错误是一种谬误
正如我们在原则二中所看到的，测试只能发现缺陷的存在，而不能证明缺陷的不存在。这条原则表明，无论你或你的团队在测试活动上投入多少精力，单靠测试本身永远无法保证软件完全没有错误。
软件并非只有当某些功能未按预期运行时才被认为存在错误。对用户而言过于复杂（可用性差）或无法满足用户需求（建模不佳）的系统也被视为存在错误。
💰奖励
为了检验你对以上七项测试原则的理解，请尝试解答以下来自 CTFL 2018 模拟考试的题目：
🤔 （样题 C，第 4 题）：产品负责人说，你在敏捷团队中作为测试人员的职责是在每次迭代结束前找出所有缺陷。以下哪项测试原则可以用来反驳这一（错误的）说法？
a) 缺陷聚类
b) 测试表明存在缺陷
c) 不存在错误谬误
d) 根本原因分析
答案如下。
如果你读到这里，希望这些内容对你有所帮助。如果没有，请记住：这只是又一篇普通的问答文章而已😬。
🍀 再见！
❗ 附加题答案
b是正确的。测试可以显示缺陷的存在，但无法证明缺陷不存在，因此无法确定是否已发现所有缺陷。此外，由于不可能进行穷举测试，因此也无法发现所有缺陷。
🔍 参考资料
CTFL 2018 课程大纲
Guru99
Geek for Geeks