软件测试思维总结（1）-----比较思维：利用好可参照的资源

【背景】

又到一年跳槽季，最近手机脉脉、BOSS直聘消息框闪烁的也特别频繁…茶余饭后也在翻看一些招聘信息,寻思着如果选择离开承载我的下一艘客船在哪里？我的“船票”是什么？

“测试已死” 喊了这么多年，似乎“测试开发”似乎成为测试人员的救命稻草…却慢慢遗忘了你的价值究竟是测试还是开发？你开发又是为了什么？是为了当年没有走上开发岗位寻求的安慰吗？当招聘广告中满是 QTP、LoadRunner、Jmeter…的时候，你靠什么安身立命？工具总有一天会失宠，而你靠什么一直骄傲下去？

你还记得你提交过的最得意的一个BUG是什么吗？多久没有尝试过掘地三尺，俘获一个深藏的BUG之后那种开怀大笑的感觉？Title从Tester到QA、测试开发越来越时髦，但快乐越来越少、认同越来越少…测试人员丢失的是自己的定位、自己的视角、忽略的是自己核心能力的修炼。

互联网行业浮躁发展10年之后，如同我们广泛认同开发的核心不是C/C++ 、Java等编程语言，而是对业务和代码超强的抽象能力一样，测试人员的安身立命最重要“船票”依然是他的独立视角和测试思维能力，从而去帮助组织去实现它的质量目标…

一年跳槽季也是总结与收获的季节，我想在此总结一下，测试人员常用到的测试思维…

本文我准备从测试探索中的思维、测试策略中的思维及通用行为方式三个层面去总结我认为的测试思维：

一、测试探索中的思维：

一个测试任务仅仅依靠工具、自动化测试这种去Checking已知域是无法满足高质量的交付要求的。我们更需要根据项目所处阶段去开站探索性测试。主动去挖掘测试项目中的灰色地带。

James Bach等测试专家就定义过：已测试=已检查+已探索

其实每个人在测试中都或多或少应用过一些测试思维，提炼总结后才能升华…

1.1比较思维：利用好可参照的资源：

我们在做测试探索的时候，常常会不经意的发现被测对象的某种行为比较可疑。这种可疑的感受源于你的Test Oracle，源于你对被测对象的测试经验和认知的积累。然而我们能否认定这种可疑行为是否为缺陷，我们需要借助一定的参照物。

1.1.1横向参照资源：

任何一款产品的研发我们需要考虑用户习惯、需要考虑与同行竞品的对标。这样才能被用户所接纳…

以网络设备产品为例，你的配置、日志、操作维护等手段需要对标业绩其他头部产品的呈现方式，因为他们代表了行业用户的普遍认知和习惯。苹果手机的触屏是一次成功的叛逆，而今特斯拉汽车的“单踏板模式”在引入大量安全问题之后又普受争议…所以在没有乔布斯这样洞察力超强的产品经理的前提前下，违背行业普遍认知的研发风险太大。

同样以网络设备产品为例，有时这种行业的普遍认知是规范和协议，它的存在确保不同供应商的设备能够在网络中互通、互操作…从这个角度来保证设备遵循业界的习惯、规范是一件势在必行的事情…

测试中怎么做？

a.不同公司，相同产品之间的比较：

例如在测试路由器的OSPF路由特性时，你怀疑它的某一个行为，但是在设计方案、取需求文档中没有明确的定义时，你不妨找找华为的路由器、Cisco路由器…这类业界头部企业相同定位来做比较。比较产品相同特性的行为是否一致,若不一致则很有可能是一个BUG…

b.不同产品，相同特性之间的比较：

例如当你测试“基站产品”的IPSec特性时，怀疑它的TimeLife秘钥更新的实现有问题时，不妨拿本公司或其他公司防火墙、路由器的实现做比较。如果基站的产品的实现和其他产品的实现都不一致，可以初步认定有BUG的。因为基站产品应用在网络中，是需要考虑网络互通、互操作的，不能自娱自乐…

1.1.2纵向参照资源的比较：

同一个特性在不同的发布版本之间应该具有一致性。即：如果没有明确的需求变更，一个特性在版本迭代之后它的对外呈现特征不应该产生影响用户满意度的变化。版本迭代可能存在如下情况：

a.正常需求合入的迭代；

b.软件代码重构、重写；

c.换代、结构调整，比如切换底层平台。

d.硬件迭代，如更换、引入性能更好的硬件单板。

另外影响用户满意度的变化不仅仅是功能，可用性用户体验、易用性等非功能属性往往是容易被忽视的。也是Checking手段进行回归的短板。

测试中怎么做？

在验收测试最新发布的软件版本时，不妨拿产品的历史版本做比较。当同一个特性对外呈现的特征产生较大差异时，请警惕软件缺陷的产生。

1.1.3内在一致性比较：

为了应对不用客户的特化的需求，在同一个产品内可能会存在作用相同或相近的特性。那么这些特性不该出现自相矛盾的对外呈现。如果某基站产品，它支持基于TWAMP协议的网络质量的检测，同时它也支持基于ICMP协议的网络质量检测。那么在同一时间段对于相同网络的检测结果不应该出现较大的偏差（比如一个测量到的网络时延10ms、一个测量到的网络时延7ms），否者TWAMP网络质量检测和ICMP网络质量检测特性，必然有一个存在BUG。

测试中怎么做？

仔细分析和研究被测对象，发现可以做内在一致性比较的多个功能特性。在验收标准没有那么清晰和明确的情况下，不妨采用自相矛盾的方法来发现软件中存在BUG。

1.1.4 其他一致性检查：

对于行业规范的一致性检查、网络协议的一致性检查、用户特化、合同契约…的一致性检查，也是测试中常见的对于对比思维…

测试中怎么做？

基于对于可靠性、互操作、合规性…等等一系列非功能性需求。我们可以在普通功能Checking（如自动化验收、回归）的基础上安排协议一致性测试、规范一致性测试等等…

1.1.5比较思维发现缺陷的根因归纳：

1.开发人员的视野局限：

开发人员入职大公司一个项目之后，往往都是螺丝钉的存在，可能3年-5年都紧张而忙碌的维护同一份代码、同一个模块，往往无暇的扩展视野去看看行业中其他公司的产品是如何设计的。

2.研发项目的价值取向：

敏捷的大背景下，往往将需求交付量、交付效率放在首位日渐内卷而浮躁…在功能快速迭代的情况下并没有解决好对于非功能性需求的迭代（这是当前我的感受，当然可能有做的好的公司，欢迎拍砖）。

未完待续…