1. 测试只能显示存在缺陷
这不太直观,但这是个硬性事实。 这几乎与司法界的“恶魔证明”命题相同,因为要证明某个负面事件“存在”,必须找到其实例;但要证明“不存在”,则需要审查与该事件相关的所有方面。 此外,“缺陷”定义的无限广度(=错误、缺陷)也可以说是使这一原则成为可能的因素。
由于该原则无法通过技术或努力的应用“移动”,因此有必要让利益相关者知道,这将是一个测试计划,并在项目的早阶段(如合同和需求定义)基于该原则进行报告。 近年来,客户的识字能力有所提升,“不允许任何漏洞”的“不合理”态度也越来越少,但一些首次考虑引入IT系统的客户可能并不了解这些特征。 你绝不应该大声宣称,但IT系统存在缺陷是不可避免的,所以我想引入它。
2. 无法进行完整测试
即使在使用超级计算机的自动测试系统的情况下,也不可能在软件中测试所有可能的条件和输入条件组合。

前几天,日本新兴科学技术博物馆发布的一段名为《如何数鲨鱼》的视频在YouTube上引起了国内外的广泛关注。 这关乎从左上到右下要走多少条路径,关于由2x2等正方形组成的方格,并且在增加正方形数量的同时实际计数,但到了6x6时,已经超过了5亿种路径。 虽然这是路线搜索情境的一部分,但我认为你可以感受到使这一原则得以确立的环境因素。
针对这一原则,本网站将讨论的测试、分析和设计技术是直接的解决方案。 突然开始写代码后,你可能体验过无法匹配功能和错误处理的徒劳感。 在测试中,这种变化表现为组合数量的爆炸式增长。
明确检测区域、如何覆盖以及如何适当减少,是成功测试的第一步。
3. 初步测试
这里的“测试”不是指所谓开发测试的执行,而是指所有“测试活动”,包括分析、设计、实现、执行等。 使用所谓“测试用例”的测试假设已有可用的软件,但“测试活动”如测试分析、设计、实现和静态测试可以从定义需求和基础设计阶段应用。
事实上,“W模型”是将这一初始测试原则昇华为开发过程模型的体现。
4. 不均匀缺陷
软件测试中的“帕累托原理”是,某个模块中存在许多关键错误,从而阻碍发布。
这被称为经验法则,事实上,我多次以数据形式体验过这条定律。 错误被重新识别并出现是常见的,但提前预见并优化测试计划需要极高的技巧和勇气。 作为一种具体方法,我们在保持测试视角覆盖率的同时,提高整个定义测试软件的粒度,并以大约十分之一的工时进行采样和执行。 文中提到了一种从击中点开始减少颗粒度的方法。 然而,测试还包括确保物体质量,因此现在必须做出适当决定,是发现缺陷还是全面保证缺陷。
5. 农药悖论
这是一个非常直观且易于理解的规则:如果你继续对同一产品应用同样的测试,缺陷检测能力会下降。 同时,思考和作“我该怎么办?”也是一条非常困难且麻烦的法律。
一旦一套基于特定视角设计和实施的测试用例检测到某些缺陷,就必须重新利用它来检查这些变更是否影响了预期的领域,或重申应建立的质量。
6. 测试受条件约束
这里的“条件”并非ISTQB定义中的“测试条件”,而是指环绕项目或公司的整个环境。

什么是ISTQB测试条件?
“组件或系统中可通过测试用例验证的项目或事件,
如函数、事务、质量特征、结构元素等。”
根据项目状态和产品所属领域,测试分析和规划所能假设的质量、成本和时间线水平会有所不同。 例如,涉及人命财产的软件测试质量水平,以及限时发布的智能手机应用用于推广,其质量水平完全不同。 前者需要考虑测试分析、设计细节和准确性,以及软件创建方法本身和流程质量;但在后者中,如果你逐项目看流程质量,显然不值得付出成本。
这包括一些测试管理的专业知识,但也应牢记,我们原则上也呼吁不总是实现昂贵的测试。
7. “零号虫”的陷阱
缺乏漏洞就是高质量软件,这往往是一个陷阱。
证明没有漏洞,也就是说,高质量、完美的测试分析和完美的测试设计...... 诸如此类,你需要完美运行测试,报告、修复并发布。 到目前为止列出的那些东西,有没有什么是你可以自豪地说“完美”的? 作者犹豫了。

产品的价值不仅受到功能缺失(通常称为bug)的影响,还受性能和可靠性等指标的影响。 例如,很难经常使用那些功能清单完美完成但启动只需10分钟的软件。 我相信你会收到反馈说这是个bug,但不能接受。 此外,即使产品通过验收检查,如果产品在可用性和作性方面明显不佳,也将尽快进行续期。
为避免这种情况,必须在从测试分析阶段对“缺陷”范围及目标可能具备的质量特性进行广泛了解后,确定产品的价值。 不可能事事皆注视,所以优先考虑任何优质模型,优先考虑你的设计。 一旦我们能够在利益相关者中获得鸟瞰视角,我们应该能够达成共识:缺陷并非BTS上唯一容易被识别的缺陷,比如性能和安全。
你怎么看? 这七项原则是大多数测试、分析和设计技术的前提,它们在该领域仍然是个问题。 我希望那些将学习软件测试的人能始终铭记这些原则,这样他们才能顺利将技术引入该领域并取得成功,而不必重蹈前辈的覆辙。