软件测试思维总结（2）-----跳跃性思维：不按套路出牌

【回顾】

上一章节聊到了，测试人员安身立命的核心能力和价值，以及比较思维，本章继续聊测试探索中的思维：跳跃性思维。

回想起十年之前，还在HW做测试的时候，测试团队墙壁上挂着这样一个标语至今令我记忆犹新：

用户想咋用咋用、用户爱咋测咋测…”

这表现了对产品质量的极高最求和自信…,华为对质量的高要求助力着企业的高速发展。

反观“敏捷”大行其道的今天，我们打着需求实例化、快速迭代的幌子…实则是对质量的漠视。

Later is Never…请保持对质量的敬畏之心，守护测试人员的尊严…当特斯拉这样互联网思维的企业在用快速迭代的方式堂而皇之向用户交付缺陷产品时，“刹车门事件”信任他的用户正在用生命为他的迭代在买单…

敏捷不应该成为对低质量产品的台阶和理由…

1.2跳跃思维：不按套路出牌：

迫于思维习惯、交付压力等诸多因数，开发人员总寄希望于用户会以一个固定的流程、标准化的的动作去使用交付的软件。**“用户不会这么去用的…”**是开发人员和测试人员PK的常用话术，但他是否真的认真做过有效的用户画像呢？

而测试人员就应该把三类九等的习惯都充分考虑:

有的用户习惯于页面鼠标点击、有的用户习惯快捷键，更甚者可能习惯用命令行…

访问同一个功能不同用户会有不同的导航路径，而一个黑客甚至会考虑跳过或者绕过…

是的，为了省事，开发人员可以为软件和功能考虑大量的操作约束和条件，然而约束本身也是代码逻辑它也会存在BUG。另外过多、过复杂的使用约束会直接影响用户体验，更何用户体验在移动互联网时代不可小觑。同质化竞争的今天，一个用户体验差的产品，3分钟内就会Say Good bye.

那么测试中我们应该如何采用跳跃思维，探索不预期的交互顺序呢？请看下文：

1.2.1绕过/跳过：

例如：**“未授权访问”**是渗透性测试中的常见漏洞类型，它就是一种典型的跳过：

开发人员预计用户在正常登录后才能跳转去访问系统的某块资源，而黑客在提前做信息收集之后预先知道被访问资源的URL及数据提交格式，在未登录认证的情况下直接去访问该资源，在鉴权考虑疏忽的情况就有可能产生信息泄露的风险。

1.2.2重复：

例：在网络和协议测试中，我们常采用报文重放的方式来测试协议的功能和健壮性：报文统计功能、丢弃策略及窗口机制、对于被测系统资源的消耗(拒绝服务，健壮性测试)、重复报文处理的代码逻辑缺陷/漏洞…

又如针对Web应用的HTTP接口的测试时，也可以尝试重放的方式进行测试，考虑但不限于如下测试Idea：HTTP接口访问的鉴权（黑客/攻击者有可能重放正常用户的业务请求）、CC攻击（Web应用单URL反复进行GET/POST请求后的可靠性）、重复请求处理的逻辑缺陷/漏洞。

1.2.3意外：

例1：

在网络和协议测试中，针对有状态的复杂协议，通常都会有一个状态机的概念。协议的实现中会定义在不同状态下接受不同类型的消息的处理逻辑。测试中仅仅去覆盖状态基于消息的正常迁移逻辑是不够的，那么，测试中应主动扰乱交互顺序，构造本不属于当前状态下的意外消息，试图将程序引向一个异常的处理流程也是测试人员应该去做的。

例2：

XX系统设备产品的对于IPSec特性的新增配置 “先分片后加密”（该功能对于硬件B是支持的，对于硬件A并不支持）：

该功能的预期配置顺序如下：

物理单板(硬件A)—>物理层端口（引用硬件A）----->Ethernet层---->IP层---->IPSec----->“先分片后加密”---->保存配置---->错误提示

测试时意外的配置顺序：

物理单板(硬件B)—>物理层端口（引用硬件B）----->Ethernet层---->IP层----->IPSec---->“先分片后加密”---->保存配置----->修改硬件B为硬件A—>保存配置—>没有错误提示，设备工作异常

由于开发在设计时，预设了用户的正常的操作流程，却没有充分的考虑产生问题的可能性。而作为测试人员除了预期的需求场景实例，应该进行充分发散，主动思考和创造可能出问题的测试场景。

1.2.4随机导航

一个事务型的功能，可能预设有清晰的流程。开发者预期用户按照流程的顺序Step by Step访问软件。但总会有一些“懒”用户或别有用心的用户，它不会去Care或者故意不遵照说明或者文档中的要求，跳跃性的去访问，这样有可能会导致产品功能约束失效或者产品运行异常。

跳跃性思维发现问题的根因：

迫于交付压力，开发人员往往更倾向于基本的、典型的使用方式和场景…方案设计考虑遗漏。

未完待续…