如何做好测试之--软件测试的系统性思维

人类已经进入一个智能的时代，不会思维就可能很快被这个社会所淘汰,需要强大的思维能力才能完成越来越复杂的工作。

测试人员需要从测试的基本思维到系统性思维、分析性思维（包括批判性思维）和发散性思维的训练

问题一软件测试像盲人摸象?只看到软件测试的某个方面，甚至眼中只有测试用例和缺陷?连Test Oracle、质量模型都不了解，对用户、业务、技术和开发关系等也关注不够?

 

test oracle是指“对测试执行结果是否通过测试的判断准则

如果不知道test oracle，如何做测试？

你的测试质量和效率怎样？缺陷命中率有多高（有多少缺陷误报）？有多少缺陷（非那种出错的功能缺陷，而是另一类缺陷，如易用性、合规性、合理性、一致性、潜在经济/健康的风险性等方面的问题）在你眼前被错过？交付的质量又如何？如果不知道产品质量模型和使用质量模型

如何评估一个软件产品的质量是否符合要求、是否能够上线？

 

会整体地、多角度地、多层次地分析问题,有不同的思考，就有不同的测试策略、测试方法，会决定我们是如何制定测试项的优先级、会影响我们的测试分析、设计与执行的某些活动。

有了系统性的思维，对测试结构、黑盒测试方法等会重新审视，这样可以把握测试自身、测试方法的精髓。我们就会关注测试的输入、输出，还会关注被测系统（ 延伸为“被测对象”）的所处环境、条件、接口等。针对输入，也不仅仅看到正常的输入数据，而且要考虑异常的数据输入、不同角色的用户操作等等。针对Test Oracle也不局限于Spec/标准等确定性的准则，还有不确定性的准则。

 

针对软件测试的目标、功能看，也不会仅局限于发现缺陷、验证功能特性的正确性等，会思考软件测试的其它价值，包括提供产品质量信息、完整地评估软件质量、不断地揭示软件产品的质量风险、测试能产生经济效益（投入产出分析，RoI）、增加管理者的信心等。

 

 

除了从不同维度测试软件产品，如进行不同的类型测试（功能测试、性能测试、安全性测试、兼容性测试......）和进行不同层次的测试（单元测试、集成测试、系统测试...）之外，借助系统性思维，会督促我们去全面了解做好测试的成功要素、影响我们做好测试的各种因素等，

软件测试五个要素：质量要求、人员、技术、资源、流程等。

软件测试的要素被概括为： 思想（流派）、方法、方式、技术、流程（过程）、管理等。当然，人、团队是做好测试的决定性的要素。除此之外，还要考虑项目中的范围、进度、业务领域、市场等因素的影响。

基于系统性思维，了解测试的成功要素、影响测试的各种因素等之后，还要确定它们之间的关系，能够将它们连接起来，而不是孤立地对待它们。只有了解它们之间的关系、相互影响，才能更准确地确定测试范围、采取更有效的测试方法（如组合测试），才能比较彻底地完成测试，即能从多个层次、多个维度来保证测试的充分性，这样的充分性才是客观、可靠的

 

 

• 业务需求决定了用户角色的需求，而这些会反映在系统功能上，或者说，功能需求是为了支撑业务需求（系统构成的依赖性）；

• 针对业务需求的验证就是传统意义上的验收测试，而系统测试是为了覆盖系统功能和非功能性需求，而集成测试、单元测试则是为了覆盖接口、代码层次等（系统构成的层次性）；

• 业务数据贯穿整个系统处理的过程，包括业务规则和流程，整个过程中如何保证数据的完整性、一致性、保密性等，确保数据和系统功能的和谐相处、有效协作（系统的交互性）。

• 测试分析是测试设计的基础，测试设计是执行的基础。反过来，测试执行、设计分别为设计、分析提供反馈，以帮助我们优化测试的分析、设计（系统的反馈性）；

• 站在更高的层次上，能够综合运用与管理测试方式、测试方法、、测试数据等（系统的全局性、综合性）；

• ......

所以系统性的思维不仅从整体上把握被测试对象，如采用黑盒方法着重考察在不同的上下文驱动下系统的输入/输出，考察系统的不同的应用场景、不同的运行平台之下的测试；而且，经常需要对系统进行分解、分层，考虑它们的相互影响，各个击破，并考虑风险与效率的平衡，例如，如何分配UI、API、单元的测试投入，达到质量和效率的最佳收益（虽然许多团队没这么去考虑）。针对更具体的软件测试计划、分析、测试设计等工作，系统性思维显得更重要， 总之，系统性思维能力才是普适的、终身受益的一种能力，需要在日常工作中去训练。有了系统性思维能力，测试工作不仅做得又快又好，还能感受软件测试之美（系统之美）。

 

 

 有些功能从软件实现上是正确的，但从系统任务角度是不达标的，系统思维很重要！

比如说，嵌入式系统包含很多模块，为提高安全性，要求各模块设计必须具备看门狗功能，软件跑飞后能够自动重启继续执行任务，但很多系统有很强的时序关系，单模块重启可能导致系统时序混乱，从单模块设计来讲都是正确的设计，但从系统的角度看是不合理的，典型的正确实现了不合理的任务！

 

很好的实例，只看到局部、保护了自己，没有考虑对其它模块、对系统的影响

十几年前刚入行做代码审查，指出了代码中大量缺少容错处理的地方，然后开发人员改了，在很多函数中对关键输入增加了很多判错后return的语句。结果交付使用后用户反映这个软件经常异常退出，不得不重启系统。开发人员查了后发现是实际运行环境里前端无可避免的会产生异常输入。软件中判错之后因为无法继续处理而return退出了，虽然保护了软件以及数据本身不产生致命后果，但是对系统造成了很大的使用障碍。这也是当时我和开发都缺乏系统性思维造成的不正确的容错

 

需要结合标准［国标，行标］，形成系统性思维

相对来说，国标、行标系统性比较强，作为一个标准，考虑的因素比较全面，结构合理、层次清楚，是学习的好材料，也是日常工作的指导性材料。只是标准言简意赅，有的标准没有实例，理解起来会比较困难，但也有的标准通过附录或使用指南来帮助大家理解。