软件测试人，你们在逐渐失去一些东西
一些正在发生的事情
我最近参加了团队TL的规划通晒，看到了一些现象：
<业务线TL>
今年我们准备提升自动化运行效率，同时建设全链路自动化，这样我们就可以通过迭代分级策略，在有些迭代中不参与进去了。
今年我们准备在线上质量上玩一把大的，部署用户体验探针，做到各种体验问题五分钟发现、半小时解决。
<资损风险TL>
今年我们准备采用xxx工具做实时核对，用xxx工具做T+1核对，再用xxx工具做交付文件的核对，这样我们的资损发现体系就完整了。
<数据质量TL>
A：今年我们在各战场上都主打高可用，线下迭代质量、线上资产监控、线上应急响应、提前数据治理，通过这套体系，保证账单等重要数据资产万无一失。
B：今年我这边主打效能提升，搞了一个实时数据自动化测试框架，测试用例写起来快得飞起，10行代码内完成，回归效率分分钟。
......
听到最后，我问了几个类似的问题：
“全链路自动化，准备跑什么测试用例？”
“用户体验探针，准备部署哪些检测项？”
“资损风险体系，准备运行哪些资损点？”
“线上资产监控，准备从哪些维度监控？”
......
问完之后，我突然意识到一个比较深刻的问题，然后我问了一下大家：
“面对这些被测对象，你们的质量理念是什么？”
是否清楚，为何而战？
<黄金时代>
记得在09年刚入行的时候，经常会和架构师JACK、朱少民等前辈探讨质量相关的东西，那会儿我们提到最多的东西是：
“UML图解法”
“非功能质量属性，ISO9126”
“探索式测试”
“可测试性”
“测试用例设计”
“故障注入”
......
在那段时间里，大家更关注“黑盒质量理论”、“优秀的测试用例设计”、“复杂用例场景构建”...
......
之前有幸和架构师JACK合作了一款质量产品：
我们制作了一款在windows平台上的故障注入工具，通过NAPI hook技术，把软件处于“磁盘满”、“磁盘坏道”、“断网”、“内存分区错误”等一系列的故障环境下。
同年Chrome浏览器刚问世，开出“一个BUG一万”的悬赏。在我们的故障注入下，发现了几十个引起浏览器Crash、数据泄露的BUG。
我们在微博上投递了相关视频，一周之内有近100家公司申请试用，不乏微软、Google、华为、阿里等企业。那段时间觉得自己走上了人生巅峰。
回想起来，这个故障注入工具我是在某年十一期间，和老婆一边看着美剧、一边顺手做出来的，其复杂度低得令人发指。而工作多年后的我才清晰的认识到，重要的并不是做出来了这么一款有爆点的质量产品，重要的是这款质量产品所传递的“质量理念”为人所动。
“华为那一年的金牌质量技术奖，是一块出现坏道的硬盘；它让我们避免了半天无法取社保的灾难”
......
在这一段时间里，网上的各种质量理论百家争鸣，延续着软件测试自1900年开始的灿烂生命。故障注入、MBT、RBT、ML-testing等理论一直延续至今，以此为基础的质量技术产品也在不断成长。
<大萧条>
近十年的互联网技术经历了快速的发展，很多热点喷薄而出：
“移动化，IOS/Android”
“大数据”
“React”
“微服务”
“人工智能”
“区块链”
......
在这段时间里，出现了一些变化，有两点我觉得是值得记录下来的：
随着被测对象的快速变化，QA为了“落地测试执行”，开始学习和了解各种新技术的细节，关注“术”多于“道”。
随着敏捷、工程师文化的流行，技术团队中“去QA”不知何时成了大趋势；而在很多的产品下，传统的QA工作确实可以被RD替代。
在这段时间里，我和大多数掌握了“术”的同学类似，开始从事软件研发、算法研发、大数据研发、前端研发的工作；2、3年的研发时光里，我掌握了越来越多的技术，也曾获得公司级“全栈工程师”大奖；一度认为自己将在大数据、算法、知识图谱、实时分析、人工智能等前沿技术上走更长的时间。
......
不知道后来人会怎么评价这一段历史，从质量技术人的角度看，理论与应用不但停滞不前、还在不断后退。
<可能还是在大萧条>
我回到了质量团队，期望用新技术为老问题带来新解法。
前段时间和 小强(前腾讯质量通道总监) 吃饭聊起我团队现在的一些事情，我不断的show肌肉说我们又通过大数据、算法解决了什么问题，我们的技术和框架多么先进。
也不知道后面聊到什么话题了，大约听到小强说了这些东西：
“其实公司的质量基建年久失修”
“追求形，忽略神，小心技术革命的坑”
“测试用例对产品进行全面的刺激反馈，让质量可评估”
...
测试用例，一个熟悉而又陌生的名词。
通过新技术确实解决了很多老问题，例如通过图像识别/特征提取等技术解决兼容性问题。
张翔：兼容性测试，你们怎么玩？
同时我又深深的感觉到，在平时项目中，越来越缺少对测试用例的关注；我们在测试分析评审时，只关注测试人员是否熟悉了本次的业务逻辑，且认为他能讲清楚业务逻辑，那他就能够测试好，没问题。
可能因为我们太忙了，很少去看测试用例的设计是否合适：
100个用例，可以设计成10个用例达到同样效果吗？
100个用例，能够并行跑起来吗？
100个用例，我们要做一下通用方法抽象吗？
这些测试用例，在你的质量模型里面，维度够了吗？
......
“测试用例这么基础的东西就自己搞了吧，我们要做更高级的测试策略、测试工具”
抓住即将失去的东西
我以前让团队写规划，会让他们有“以终为始”的思维，去追求事情的价值。在做之前先想好做了之后，我们怎么吹牛逼。先把各种数据预设好，并为之而付出努力。但在对所谓的“价值追求”上，我们是去了作为软件质量从业人员的技术情怀。
>> 质量理念
我们为什么做用户体验探针？
我们为什么做数据治理？
我们为什么做兼容性智能测试？
“The most important thing is not what you do, but what you think.”
>> 微小而美好的测试用例
每一个测试用例都可以是打动人的，它不应该成为“300+测试用例”这样冰冷的数字。
大家会为因为“300+检测项”而昏昏欲睡，也会因为“具体的例子”而感同身受，我们通过每一个微小而美好的检测维度、检测项构建的质量模型，是具有生命力的。有更多的方法论需要和质量理念需要融入并落地成为我们的每一个测试用例。
所以我也常常和团队说这样一句话：
“世界会因我看待世界的不同视角而改变”
【作者介绍】
张翔，车手、歌手、程序员，有态度有方法的质量TL、新技术探索者和布道者，现就职于蚂蚁金服，他和他的爱车定居于成都。