下载掌阅APP，畅读海量书库
立即打开
所谓软件测试思维，是指在测试实践中的方法创新、经验积累、认知演进、文化积淀，是一种最佳实践方法论。例如，微软的两类测试方法、IBM的RUP测试方法、Parasoft的AEP自动错误预防测试方法等。软件测试思维需要通过长期摸索、训练和培育养成。第一方面，建立完备或独具特色的测试技术体系与创新体系，突破相应的重大关键引领技术和特色技术，推进基于技术创新驱动测试实践主体创新，创新决定思路。第二方面，对技术储备、测试能力、资源配置、资产积累等进行系统分析，将测试资产转化为知识，知识决定思维。第三方面，以测试能力提升为导向，将分析性思维、发散性思维、系统性思维融合，有针对性地开展思维方式训练，推进软件测试思维方式的持续转变，形成独具特色的思维方式。
对于一名优秀的测试人员或一支优秀的测试团队，需要具有独特的视角和思维方式，才能应对纷繁的测试需求，高屋建瓴、匠心独运、创新超越、精准设计、庖丁解牛、火眼金睛、秋毫不放，直下城池。我们之所以在软件测试过程中，探索并应用不同的思维方式，是希望从不同视角，以独特的思维模式，促进软件测试最佳实践。
系统思维将软件系统作为一个整体，从全局和总体出发，多角度、多层次、多维度分析软件系统与各要素及各要素之间的关系，关注测试生命周期管理，关注测试过程改进与过程能力提升，是原则性与灵活性有机结合的基本思维方式。系统思维能力是普适的、终身受益的一种能力，需要在软件测试最佳实践中进行不断探索、不断积累、不断创新、不断改进。
人们往往会依赖于长期形成的习惯，形成思维定式和路径依赖。比如，一些测试组织，基于实验室管理体系，制定了标准测试流程，要求测试人员按照作业模板进行程序化操作，但却忽视了测试的系统性及对客户反馈的持续响应，妨碍基于客户需求及变化的持续迭代测试。又如，测试人员可能重点关注代码的静态特性及需求的符合性，但却可能忽视基于不同使用环境和任务场景，对系统运行流程、操作使用、系统能力的验证，难以对系统的总体目标和整体效能做出评价。再如，基于缺陷驱动的测试，关注系统的缺陷行为，忽视故障模式及影响分析，难以从根源上实现问题归零，也难以基于质量工程视角审视并规避系统质量风险，抓住了点和线，忽视了面和体，重视了局部，忽视了整体，只见树木不见森林。软件测试过程中，以系统工程思想为指导，将软件系统视为一个不同要素相互作用、动态熵增、开放融合的整体，将软件测试过程视为一个持续迭代的系统工程过程，将软件测试作为一个基于错误检出、用户体验、开发聚合于一体的系统解析、分析评价过程活动，深入思考如何从系统和要素、要素和要素、系统和环境的相互关系和相互作用分析问题、发现问题、解决问题，面向总体，抓住要害，避免用线性的思维方式解决非线性问题，避免片面地追求单个目标，避免被表象所迷惑而看不到问题的本质，避免忽视软件测试的过程风险和被测系统的质量风险。
系统思维具有整体性、结构性、立体性、动态性、综合性等特征。整体性是系统思维的核心，是在对软件系统解析、理解和把握的基础上，确定测试目标和风险，制定基于整体目标最优化的测试策略；结构性是基于系统结构理论，解剖软件系统结构，发现结构性问题；立体性是将软件系统置于纵向及横向思维的交点，从纵向把握系统特征、系统行为及其演化发展规律，从横向重用相似系统的测试资产，对系统进行比较和评价，即从纵向和横向两个维度，立体性地对被测系统进行测试和分析评价，这是软件测试系统思维的本质；动态性就是破除线性单值机械决定论的影响，树立非线性思维统计决定论的思想，根据被测系统开发—变更—发布—变更—升级的循环演化，制定并适时调整测试策略，实施最佳测试实践，确保被测系统向演化目标方向发展；综合性是从总体和全局出发，将文档、代码、数据、开发环境、运行环境等视为实现特定目标的综合体，从不同的侧面、多因果、多功能、多角度、多层次、多效能上把握测试目标，管控测试风险。
系统思维能够从整体上支撑测试策划，优选测试方法，防控测试风险，保证测试质量和效率，改进测试过程。例如，基于数据驱动的测试，对系统架构及各元素之间的相互关系和影响进行综合分析，对系统进行分解、分层，针对不同上下文驱动的系统输入/输出，在不同使用环境、不同应用场景下，通过UI、API、软件单元测试投入的有效分配执行测试，实现风险与效率平衡、质量与进度协调。
基于系统思维的软件测试，是以目标为导向，基于资源、时间、成本等约束条件，全盘掌控软件测试的目标、要素及系统与要素、要素与要素之间的关系，从正向、逆向、狭义、广义等不同视角，对测试策略、测试设计、测试结构、测试方法、测试环境等进行系统审视，全面把握测试过程，灵活应对测试过程中出现的问题和风险，支撑测试过程活动调优。例如，基于数据驱动测试，不仅要关注测试的输入/输出，而且需要关注被测系统所处的环境、条件、接口等。针对测试输入，不仅要关注正常输入，而且要考虑异常输入及不同角色的用户操作。针对Test Oracle，不仅局限于标准规范确定的准则，还包括不确定性等准则。基于系统思维的软件测试流程如图4-22所示。
图4-22 基于系统思维的软件测试流程
基于系统思维的软件测试，引导测试人员或测试团队从全局、全过程关注制约软件测试的各种要素。同济大学朱少民教授在《完美测试：软件测试系列最佳实践》中，构建了一个软件测试金字塔，给出了质量、人员、技术、资源、流程五个确保测试效率和质量的要素及其基于系统思维的软件测试视图，并将软件测试要素概括为思想、方法、方式、流程和管理。团队是测试成功的决定性因素，项目范围、进度、业务领域、市场则是重要的影响因素。图4-23给出了一个基于系统思维的软件测试要素及关系图。
图4-23 基于系统思维的软件测试要素及关系图
基于系统思维，分析确定影响测试风险的要素及其关系，科学准确地制定测试策略，精准施策，从不同层次、不同维度保证测试的充分性。这里给出如下基于系统思维的测试原则：
（1）业务需求决定使用需求，使用需求决定用户角色需求，使用质量决定外部质量，外部质量规定内部质量，功能需求是为了支撑业务需求，是软件系统构成的依赖关系。软件测试不仅是基于需求的符合性验证，而且更加需要从用户需求和使用出发，进行总体策划，对系统效能及交付能力进行测试验证。
（2）针对业务需求的测试是传统意义上的验收测试，系统测试是为了覆盖系统功能和非功能性需求及明示和隐含需求，集成测试、单元测试则是为了覆盖接口、代码层次等，针对的是系统构成的层次性。
（3）业务数据贯穿于系统运行过程，包括业务规则和流程。在整个过程中，如何保证数据的完整性、一致性、保密性，确保数据和系统功能和谐相处、有效协作是完备性测试的基础。
（4）测试分析是测试设计的基础，测试设计是测试执行的基础，反过来，测试执行、测试设计分别为设计、分析提供系统反馈，支撑测试分析和测试设计优化改进。
（5）软件测试应站在更高的层面和高度上，面向系统的全局性和综合性，基于软件生命周期过程，综合运用与管理测试流程、测试模式、测试方法及测试数据。
分析思维是指经过仔细研究、逐步分析，得出明确结论的思维方式，即根据系统的构成逻辑，收集、分析、比较不同来源的信息，使用归纳推理、演绎推理、逻辑证明等方法，确定问题，制定解决方案，逐步逼近问题的本质，是系统思维的逆向过程，是一种循序渐进的思维方式，也是一种纵向思维方式，是分解和剖析问题的重要方式。
康奈尔大学R.J.Sternberg教授对人类认知的研究表明：人的认知能力主要源于分析性、创造性、实用性思维。基于认知层次，分析能力的层次较高，处于记忆、理解、应用之上。综合和评价离不开分析思维，创造性思维得益于批判性思维，批判性思维是分析思维的一种方式。传统软件测试就是基于分析思维的过程活动，分析流派是最早出现的软件测试流派之一。
目前，业界已构建符合科学逻辑、结构化的软件测试知识体系，可以进行度量和定量分析。基于这个视角，通过推理分析，能够发现软件需求、软件设计及软件实现缺陷；通过比较分析，能够完整地理解软件，验证软件需求、软件设计和软件实现的一致性；通过综合分析，依据功能实现情况、性能指标达标情况及软件缺陷率、质量度量数据等评价软件质量。
分析思维遵循严密的逻辑规则，通过逐步推理得到符合逻辑的正确答案或结论。因此，根据“定义问题—分析问题—解决问题—评估模型—方案选择—制订计划—实施方案—实施计划—分析评估—总结反思”的分析思维，建立并维护软件测试过程模型，是一种自然的选择。本书3.1.3节讨论的基于流程的测试过程模型同基于分析思维的软件测试流程具有高度的一致性。基于分析思维的软件测试流程如图 4-24所示。
图4-24 基于分析思维的软件测试流程
基于分析思维的软件测试是指面对测试问题，理性、科学、逻辑地构建测试过程模型、数据模型及价值模型，确保测试工作有效展开。没有分析思维或许根本无法构造出软件测试过程模型。其他流派的软件测试可能强调标准规范、质量模型、上下文等，但终究离不开分析过程，除非完全对照标准进行测试，或者具有一种测试工具能够完全自动地完成测试策划、测试设计及测试执行和分析评价。至少到目前为止，还无法将用户需求直接输入到测试平台，获得测试结果。而事实上，也许根本不存在这样的测试平台。何况，软件系统千差万别，纷繁复杂，产品需求、客户期望等需要经过分析整理，才能转化为测试需求，测试输出同样需要进行分析比对，才能确定究竟如何影响软件系统的整体质量及其属性。
结构化思维是基于一定范式、流程顺序及整体视角，遵循启发式原则，以假设为先导，利用固有认知，分析界定问题，枚举问题的构成要素并进行分类，排除非关键要素，确定重点要素，制定对策和行动计划，循序渐进，逐步求精的思维方式，具有视角多元性、影响跨期性及层级互适性等特征。
在日常生活和工作中，人们会自觉或不自觉地使用结构化思维方式。总—分—总结构就是一种最简单的结构化思维方式。结构化软件开发方法中的自顶向下结构即是典型的结构化思维应用。
结构化思维启动的前提是已具备一个可以度量的目标，若目标不明确，则应先行挖掘问题，将陌生问题转化为熟悉问题，将抽象问题转化为具体问题，实现系统目标转化。比如，测试策划时，不能笼统地要求性能测试，而是将性能需求转化为可以度量的测试需求，如常见的响应时间、吞吐量、作用距离、解算精度等，不仅要根据具体指标，量化测试目标，而且还要确定性能指标的余量、容量、强度等测试需求。
目标确定后，对问题进行分解，然后以相互独立、完全穷尽（Mutually Exclusive Collectively Exhaustive，MECE）为原则，基于宏观、微观、外因、内因等不同角度，将一个问题分成若干个类，并确保其相互不重叠，无遗漏，捕捉到问题的核心，从中得到有效的解决方案。基于MECE原则的问题分类，有利于从不同视角审视问题，有利于将复杂问题简单化。比如，当测试时间不充分时，就可以按照重要程度、质量风险等，将测试用例按照优先级分类，并按照优先级从高到低的次序依次执行，降低测试风险。
在目标确定且分类完成之后，尽管其结构比之前清晰得多，但依然可能是一个塞满信息的结构。因此，需要继续为这个结构补充相关信息。基于卓越绩效及持续改进思想，结构的完善和优化是一个持续的过程。其实，这是一个从思维模式构建、应用、评估到改进循环反复而又不断螺旋上升的优化过程。
软件测试的最终目标是获得软件系统中所有产生数据的用户行为或模拟用户行为的性能表征，如果测试过程中遇到与现实差距巨大或不能具象化、定量化的目标，首要任务就是将性能需求的歧义指标转变为可例证化的指标，将模糊指标清晰化和具象化，将非量化指标转化为量化的可执行目标。例如，某综合保障系统，其性能需求包括并发能力、响应速度、资源利用率、性能调优。在确定系统性能目标的基础上，我们对该综合报账系统梳理出了198个业务类型，其目标就是要获取这198个业务类型的功能需求及性能表现，即每一个业务的并发支持及响应时间。进一步梳理这198个业务类型，将复杂业务按结构进行分解，直至获得典型业务的性能表现形式。但由于这198个业务类型整合了不同终端、不同业务类型，无法再进行分割和分类，同时，由于受硬件资源、多系统协调、成本控制等因素制约，无法搭建完备的测试环境，而是采用某些程序模拟部分测试环境，不再关注被模拟程序隔离的真实测试环境。工程上，通过挡板程序可以将业务按层进行结构分割。这些业务流独立地在每一层上存在重复，通过这样的黑盒化，只需要关心输入和输出是否符合预期即可，而无须过分关注业务，从而这198个业务类型就可以继续进行分割和分类。
制定测试策略时，需要重点关注的是关键性能指标的测试验证。对于前述示例，首先，确定系统是否在负载并发能力上达到了业务性能需求；其次，通过负载加压获得系统最大的并发能力，以及通过负载压力测试验证目标。此外，在不同负载条件下，系统响应速度是否达到业务性能需求？首先完成基准测试，然后在不同负载级别上获得加权的系统响应速度。显然，对于资源利用率、设备优配，就是建立测试模型、明确目标、如何分类、怎么确保分类的合理性，测试方案呼之欲出，剩下的无非就是测试环境搭建、工具准备、数据准备等工作。