下载掌阅APP，畅读海量书库
立即打开
解构软件，检出错误，保证质量，是软件测试的核心目标，是软件测试的初心。基于系统规格和需求规格，在确定的运行环境及任务场景中，以正向思维方式，验证软件系统实现的正确性、符合性、一致性，是传统质检技术在软件测试中的自然延伸。基于现代质量观，一致性质量是一种狭隘、庸俗化的质量思维。
面对快速变化的用户需求，软件测试被赋予了新的使命，对持续改进软件过程、提高交付能力、降低使用风险、实现用户价值，发挥着越来越重要的作用，是缺陷工程、性能工程、质量工程、价值工程融合发展及软件质量革命的驱动器。
软件测试的充分性是指在确定的环境中、规定的时间内，完成约定测试，所有问题得到有效处置，实现规定的质量目标。基于时间、成本、资源约束，制定准出准则，确定测试充分性的阈值及风险，是制定测试充分性准则的基础。软件缺陷理论、失效机理、环境搭建、场景构建、输入组合、测量不确定性以及时间与资源等无一不是制约测试充分性的重要因素。下面给出了软件测试充分性保证的基本法则，供读者参考。
（1） 基于目标驱动的测试充分性： 以目标为导向，定义质量目标，确定质量目标测量、分析、评价要求和方法，如逻辑覆盖率、功能覆盖率、错误检出率等。根据确定的质量目标进行测试策划，制定测试充分性准则，驱动测试设计。
（2） 基于能力驱动的测试充分性： 基于被测系统的使命任务、系统架构、测试风险等，确定实现测试目标所需的人员、技术、工具、环境等能力需求，保证测试的充分性。
（3） 基于技术驱动的测试充分性： 基于确定的测试目的及质量目标，分析确定并应用特定的测试技术，确保测试的充分性。
（4） 基于用户体验的测试充分性： 邀请用户代表及相关方参与测试大纲、测试说明、就绪检查等评审，基于正向思维模式，深度挖掘功能需求，在各种可能不同的使用环境和测试场景中组织实施体验式测试，验证操作使用、运行模式、运行流程的正确性和有效性。
（5） 基于用例覆盖的测试充分性： 单元测试用例覆盖每一条语句，配置项及系统测试用例覆盖每一个接口输入参数的每种等价类，以及每个场景及系统的每一个运行流程及组合。覆盖每个场景是系统测试设计的基本要求。
建立从系统规格、需求规格、设计文档、测试项的正向和逆向追踪关系，确定测试可追溯性的范围、内容和过程，测试结束之后，分析确定追溯过程、追溯内容、追溯关系的正确性及一致性、完整性并进行评价，确保测试的充分性。
对于一个具有确定状态的软件系统，在其生命周期过程中，通过测试，能够检出绝大部分缺陷，使缺陷率下降至一个可以接受的水平。而事实上，软件生命周期过程中，任何阶段的任一过程活动，尤其是升级维护，可能因为需求调整、设计变更、代码更改、数据更新、环境变化等引入新的错误，即便是测试过程中的错误分类、错误隔离、错误排除等过程活动，也可能引入新的错误。软件生命周期过程中，软件缺陷率随变更而变化且呈如图2-7所示的变化态势。
图2-7 软件生命周期过程中软件缺陷率的变化态势
软件生命周期过程中的任一阶段，如果缺陷未能及时检出，会向下传递、蔓延并放大，具有传染性。任何用于防止或检出缺陷的工作，都会残留更为微妙的缺陷，且检出这类缺陷将更加困难，此乃软件测试中的“杀虫剂”效应。统计表明，如果一个需求错误未能及时检出，交付阶段检出该错误的成本将增长50～100倍。软件缺陷传递放大模型如图2-8所示。
图2-8 软件缺陷传递放大模型
假设模型中的缺陷放大因子为
α
，在开发过程中某个阶段，通过评审、测试等工作，缺陷检出率为
，所有被检出缺陷均能及时而彻底地被排除，那么在通过该阶段之后传递到下一阶段的软件缺陷数为
（2-1）
由此可见，软件测试不仅仅是基于开发模型的阶段产品验证以及最终产品的验证确认，也是基于软件质量风险及其传递的动态验证。
软件缺陷具有不均匀性、集群性等特征。例如，某编码人员总是对循环语句多做一次，而另一编码人员则总是在条件判断语句的布尔表达式上遗漏判断条件，形成不同的缺陷积聚性。统计表明：大约80％的软件缺陷存在于20％的代码行中，同80/20原则高度吻合，残留缺陷与检出缺陷率成正比。显然，这个“20％”就是高风险带，需要重点关注。受时间和资源约束，软件测试难以实现所有功能和路径遍历，所以不能将精力放在经过测试而没有发现错误的代码或功能点上，而应集中于关键功能模块以及已经发现错误的模块或功能点上，抓住质量风险这个“牛鼻子”。基于风险的测试策略正是缘于此。
软件测试是在未知错误的情况下，为检出错误所做的努力。软件调试是在已知错误或通过推测能够识别错误的情况下，发现、分析、修正错误，剔除失效根源的过程活动。其包括软硬件匹配、功能调整、性能调优、集成优化等工作。直到今天，测试与调试混同，重开发、轻测试，重调试、轻测试现象普遍存在。这是一种轻视质量的行为。开发与测试对立是根本性的。软件测试，成也萧何，败也萧何！
开发人员往往存在自我主观认同感，自我迷信，往往不会基于测试角度，以逆向思维方式分析和思考问题，难以发现自己所开发软件中存在的问题，更有甚者，忽视开发规范，忽视测试性设计，不希望自己开发的软件被别人发现错误，对自己的错误视而不见或拒绝承认。自测试过程中，发现错误的概率尤其是发现自身错误的概率相对较小，为了“程序正确”的自测试，可以休矣！为了达到测试目的，在编码实现阶段，应强化单元测试，倡导双人编程，这也正是结对编程不断受到推崇的根本原因；在集成测试、配置项测试、系统测试阶段，弱化自测试，推行交叉测试，强化三方测试，是测试独立、质量独立的基本观念。
深刻理解和正确认识软件测试和调试的概念、目的、流程和方法，采用问题代码片段引用及扫描结果截图等方式描述问题，提供问题描述的客观证据，减少二义性描述，增加沟通的可视性，有利于问题的分析处理，有利于二者的融合互进。基于全程测试及质量管理要求，推进测试左移与右看实践，实现团队诊断、敏捷度量、流程敏捷、文档敏捷、创新组织治理，是推进基于测试驱动的软件质量工程创新的基础实践。