由柠檬班线上整理编辑

<业务线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个用例，我们要做一下通用方法抽象吗？

这些测试用例，在你的质量模型里面，维度够了吗？

......

“测试用例这么基础的东西就自己搞了吧，我们要做更高级的测试策略、测试工具”

抓住即将失去的东西

我以前让团队写规划，会让他们有“以终为始”的思维，去追求事情的价值。在做之前先想好做了之后，我们怎么吹牛逼。先把各种数据预设好，并为之而付出努力。但在对所谓的“价值追求”上，我们是去了作为软件质量从业人员的技术情怀。

来源柠檬班软件测试自学网网络整理，作者:张翔

现在柠檬班推出国际权威认证ISTQB认证考证【试听课】