构建与崩塌之软件测试七大原则在研发流程实践中的思考

软件测试七大原则

3.1      测试要展现缺陷，而不是证明软件没有问题 Testing shows presence of defects

测试的过程要尽可能的揭露更多的缺陷，而不是证明软件是ok的。这其实是一个心理学问题，因为人更倾向于事情朝着自己预期的方向发展。因此，当你抱着验证软件没有问题的心态去测试时，就容易把一些问题遗漏掉。

3.2      不可能执行穷尽测试 Exhaustive testing is impossible

很多情况下测试的组合是大量或者无穷的，所以要结合需求和实际资源，去设计最小用例覆盖需求，也就是我们通常说的进度把控。每个发布版本是有明确的发布时间路标的。因此我们需要在有限的时间内，基于版本发布的质量目标，通过覆盖完备的测试设计和合理的人员分工，让产品的质量满足目标。

3.3      测试活动应该尽早开始 Testing early

测试要从需求分析和特性设计阶段开始介入，而不是等待开发转测后再开始。在软件研发的流程中，问题发现的越早，解决的成本越低，对于版本发布的风险越小。因此，一定要把测试活动尽量往前排，例如能够帮助广覆盖且低人力投入的自动化测试用例，可以提前开发调试。尽可能早的暴露对版本发布有影响的问题。

3.4      缺陷存在群集效应(二八定律) Defect clustering

即80%的功能问题存在于20%的模块。尤其需要注意的是复杂度与设计耦合性高的模块。‌高复杂度模块（如核心算法、多接口交互组件）逻辑复杂性强，开发过程中更易引入隐蔽错误；同时模块间紧密耦合会导致局部缺陷扩散到依赖模块，形成缺陷密集区。例如ROACH工具中的细粒度备份和容灾，通常缺陷密度显著高于集群级备份和容灾功能模块。因为细粒度的备份，在获取对象定义及数据，以及保证数据一致性上需要更加复杂的机制实现。且细粒度备份对每一种数据库对象都需要单独分析处理，极容易受对象存储机制变更的影响。

3.5      杀虫剂悖论 Pesticide Paradox

随着问题的修复，同样的测试用例能够发现问题的能力会逐渐降低，就像虫子逐渐会对同一种杀虫剂产生免疫。因此，在实际测试活动中，尤其是集成测试和专项测试这种每日看护的自动化用例，相关测试责任人要时刻保持危机感。长时间没有变化的自动化看护，往往意味的对问题的持续漏测。所以，每个版本一定要根据新需求和现网问题RCA以及业界测试技术的发展，不断改进补充自动化用例和自动化的运行方式，才能持续挖掘产品的问题。

3.6      测试活动依赖测试内容 Testing is context dependent

简单地说，测试要在熟悉业务的基础上进行。因此，对于测试产品的了解程度越深入，我们在做测试设计时，才能更全面，更精准。除了测试技术的迭代，对于业务知识，尤其是数据库这种高度复杂的系统。一定要由点及面，由浅入深，建立自己系统化，结构化的业务知识体系。

3.7      没有错误的谬论 Absence of error - fallacy

无论执行多少用例，多长时间的测试，都不存在没有bug的软件。而我们测试的目的也不是让软件没有bug，而是在满足版本质量需求的情况下，修复不能接受的bug。所以大家经常被问到的这些问题，例如，版本发布前哪些问题单必解。哪些问题单可以遗留，版本受限发布。是否需要提供客户可接受的临时方案或者在未来哪个补丁彻底解决，等等都是围绕版本的质量目标来做决策的。

总结：

测试人员不能只关注业务和技术层面，因为测试技术和缺陷发掘，只是测试的手段，而不是测试的目的。在商业化的软件研发流程中，只有最终对用户有价值的产品，才是我们的目标产品！！！如果用业界另一种对测试人员的称呼“QA“——Quality Assurance，即质量保证。大家更容易明白，一切的测试活动，都是围绕基于测试活动产生的数据(测试用例覆盖，缺陷分布和解决情况)，得出产品当前的质量状态(能力，规格约束)，对比预期的质量目标(软件能力上的需求和隐形的用户需求如上线时间等)，做出最终的版本决策(批量商用，受限商用，POC，延迟发布)。