测试超限战：论全维度测试

前前言

本文不代表 coding 官方观点，仅代表个人( @ciwang )观点。

前言

刚开始做测试的时候，我以为只要确保验证产品功能的每一个细节正常就行了。直到有一天，突然意识到，如果需要验证的功能并不是用户所需要的，或者说操作起来体验很差。那么，确保这些功能正常又什么意义呢？细想之后，我写了一篇博客《测试应介入需求分析和产品功能设计》。在这之后，我愈发觉得测试与产品策划，设计，开发，运维，甚至是运营都是息息相关。我认为应该用一种全局的视角，重新审视测试在整个产品生命周期所扮演的角色才能让测试的效用变得最大。
本文正是按照这样的思路来探讨一种全新的测试理念，全维度测试 。

对，不一定是对

什么是测试？在我看来，测试就是验证实际情况是否符合计划预期的活动。简单来说，确保产品是对的。
那什么是对的？传统意义上来说，通过测试用例，符合需求文档的设定就是对的产品。
但是，需求文档就一定是对么？如果有可能不是，那么什么是对的需求文档？什么是对的功能？有人说，有价值的功能的标准很主观。最常见的论调莫过于，你需要的不一定是别人所需要的，我想想也是醉了。所以，如果要做需求测试，最好还是多和用户交流，无关痛痒的人总是站着说话不腰疼。因此，测试人员要善于倾听用户 的痛点。多思考产品对于用户的价值和自身的使命。想明白了这些，你做起一些决策就会清晰很多。比如，把有限测试的精力集中到核心功能上，那些鸡肋功能先晾在一边，这样可以极大的提高测试效率。

所以，测试的含义可以重新定义为确保有价值的功能正常运行，而非所有功能。

同样，我也不认为设计文档一定正确。年初，微信和支付宝开始“红包大战”。根据事后的统计，微信的数据要比支付宝好的多。其中一个重要的原因在交互设计上，微信的红包摇一摇，直接发送就行了。而支付宝的红包却要点击屏幕中小小的红包图标，然后输入口令。想想就挺烦。一般人都会选择简单的操作。从“事后诸葛亮”的角度来说，这是一场注定要输的竞赛。从交互设计上就输了，不管支付宝的测试和开发有多努力。

Believe it or not, 客观的真理是一定存在的，也就是说对的需求和对的设计的标准一定是客观存在的，但凡人的智慧有限，无法一下子发现。因此，不断的尝试，观察，反思总结，不断地去趋近和发现这些标准。而测试应该做的就是发现这些对的标准，然后评估实际情况是否达到了这个标准。比如，简约设计应该是 UI 设计的一个共识，页面上面尽然不要太多文字说明，不要有太多专业术语。测试人员要能识别出，哪些文字是多余的，哪些文字有歧义。

不是全栈，也不是全干，是全测

有些人会说，你说的全栈工程师吧。不是的，我说的是全测工程师。全栈工程师和全测工程师最大区别在于思考的侧重点。全栈工程师会思考，开发什么样的功能，如何设计，如何实现？而全测设计师思考的问题是，开发这样的功能，能给用户带来多大的好处？这样的设计是否足够简约？这样实现方式是否足够便捷? 当然，全栈工程师也会思考这样的问题，但是，人难免会有疏忽的时候，需要有个人来检查下。这就是全测工程师的意义。

尽早测试，经常测试，自动化测试

• 尽早测试
  等需求文档写好，再去想测试用例怎么写那就太晚了。测试用例和需求文档应该同时写，测试人员要在不断完善测试用例的同时，不断地“质疑”这份文档。Kent 在极限编程中提出的先写测试，再写代码也是尽早测试的一种体现。写测试的时候，你会去思考这个产品做出来是什么样的，用户怎么去操作它。如果照着文档来写用例，相当于跳过了需求测试，默认需求完全正确。
• 经常测试
  每次需求和设计的变动，都需要测试。这就好比代码重构的时候，跑一遍单元测试是同样的道理。如果时间和精力许可，测试人员可以就这些变动中一些“迷惑”的地方，主动去询问设计师或产品经理。类似于代码评审，设计和需求也应该评审。
• 自动化测试
  自动化测试解放测试人员，使其能有精力去关注更高级业务。鄙人“有幸”做了 5 天的人肉测试。。。。生不如死

全局测试的成本

• 对测试人员的知识和经验积累是极大的考验
  相对于以前只负责测试用例的编写，全维度测试要求测试人员对需求分析，产品设计，系统架构，甚至是对运营的文案对产品功能介绍是否恰当，是否突出产品亮点，都要有一定的认识。
• 争执和讨论的时间成本
  这个应该是最大的成本，很多次，别人都会说。讨论需求和设计就是浪费时间，设计师想了半天的事，一个傻逼上来就说，这个颜色，字体，或文案不对。还要解释半天，然后那个傻逼也没提出像样的方案，白白浪费了半天。当然，这和那位提意见者的经验和学识有关。但是，我想，很多时候，这个所谓的傻逼就是我们的用户。会说这样的话的团队，大多也没有时间好好和用户交流。Anyway，讨论还是有必要的，没准就是设计师突然秀逗了。就像写程序的时候，以为百分百正确的代码，调试起来还是很多 bug 一样。
  如果当心讨论会浪费时间，那就设定讨论的时限，超出这个时限，产品经理说了算。现实的情况是，为了省一天的讨论时间，傻逼的开发了半个月，然后，做出一个傻逼功能。浪费了半个月的时间。
  也有人会说，过多的讨论导致行动力下降，还不如先开始做，然后再慢慢讨论。同样这个也可以先加个讨论时限，如果超过时限没有结果，那就把每个方案推进一小步，看看效果，在讨论。不断地小步迭代。
  瀑布开发模型和敏捷开发模型最大的差异在于是否存在迭代。所谓迭代就是反复的开发，观察，讨论。省去反馈讨论的时间，然后，骗自己全速开发，往往会南辕北辙，适得其反。
• 构建自动化测试环境
  需要额外的人力和时间去编写测试用例，并且。。。。。维护。。。。。。（写写还是挺容易的，要是哪天网站改版了，，，，interesting）

全维度测试的优势

• 关注重点，减少无用功
  “不识庐山真面目，只缘身在此山中。”人在忙于细节的时候，很容易忽视全局，所以需要一个旁观者来提醒。测试人员要审视团队要实现的功能是否偏离产品的本意，或者设计的过于繁琐的操作，甚至是开发过程中出现的沟通不畅等问题。

• 降低测试、维护成本，提高开发效率
  有了全局意识后，你就可以发现功能与功能间不是等价的。如果有个功能去掉后，并不影响操作的话。那么，这个功能就是“鸡肋功能”。对于“鸡肋功能”，个人看法是果断砍掉。因为，如果一个“鸡肋功能”被砍掉了，也就不用开发相应的自动化测试脚本，也就不用去修 bug，这样开发人员会把更多的精力投入到新功能的开发中，而不再在修无用功能的 bug 中沉沦。留着这些“鸡肋”，只会增加“沉默成本”。

举两个例子：
一是 coding 的动态墙。这个地方我没写自动化测试，如果有人报这个地方的 bug。我会自动忽略掉，因为没有这个模块，用户依然能在 coding 愉快的玩耍。不要问我为何那么叼，先看看这功能有多鸡肋
二是个人中心旁边发冒泡的功能。同样是无人使用的功能，前段时间，用户报了一个 bug，最好的修 bug 的方法就是，将其换成“任务列表”，然后在“冒泡广场”加一个朋友圈。

后记： 全栈，日益模糊的角色定位

在这里我说的全测工程师好像无所不知，无所不能的样子。其实，真实的全测工程师应该说是团队的不同成员组成的，很难有一个人能从头测到尾。人人都是测试员，只要测试能渗透到产品的各个生命周期，不断的产生各种有价值的反馈，全测工程师的目的就达到了。