做到这几点，你也能成为 BAT 的抢手人才（下）

文末有福利！

测试工程师的高段位要求

 

计算机领域知识的通盘理解

这条范围非常大，人不可能什么都懂。但最最基础的知识是不能有盲点的：

1. 操作系统工作基础原理与基础操作：如 Linux，要通读过 Linux 操作系统的书，熟悉最基本的概念，基本命令要熟悉，Shell 要能写和读；

2. 网络知识特别是TCP/IP, HTTP知识：推荐两本书 《图解 TCP/IP》 《图解 HTTP》这两本书里的东西要懂。

3. 数据库知识：市面常见数据库（Redis，MySQL，Oracle）的常见 DBA 操作，问题排查；SQL 的熟练使用；

4. Web及移动端知识：能够懂 HTML，CSS，能够读懂 Javascript 代码，能够读懂 Android 或者 iOS 的代码，做简单开发最好。

5. 安全知识：常见的安全防护方法、工具使用；基本的安全攻防原理；

6. 软件工程/开发过程管理：实战中各种磨练，建议系统的学习 PMP，敏捷开发的一些认证课程。

在一个域的深耕

人不可能什么都懂，但在一个领域是需要深耕的。比如，在做了四、五年移动端测试以后：

• Android 和 iOS 都要具备一定的开发能力了，能读懂开发的业务代码是最基础的，能够代替开发实现部分业务功能，完成部分组件开发是个非常好的自检点；

• 能够对移动端自动化工具栈、监控工具栈（如友盟、Bugly、Newrelic 等）、内存泄露检测、卡顿检测、耗电量、弱网、流量、埋点、灰度、版本控制、兼容性、用户体验、安全等等的质量保障方案有通盘搞定能力。

什么叫搞定呢？举个例子：比如，使用多种手段把崩溃率降低到千分之一以下。

对于一个小团队，这是个很不容易实现的坎。做到这点，你需要了解

• 如何收集崩溃率，

• 如何使用一系列工具来定位核心问题，

• 如何推动开发改动，并且预防（静态代码扫描工具引入，阻止乱用第不成熟的第三方插件，代码 Reivew 防止常见 Pattern 如空指针引发的崩溃，推动开发养成良好的log习惯，推动移动端防御性编程编程开发习惯，推动后端开发按照规范吐接口，帮助开发引入内存泄露、卡顿工具，趋势报表，警钟长鸣，各种灰度方式设置，线上监控。。。一个数据的改观，背后要有大量的质量相关工作）。

 

使用综合手段来保障软件质量提升效能的能力

听起来很抽象，举几个例子吧。

例子 1：你所在的 Team 总在被开发抱怨测试用的时间太长。如何能缩短一下测试时间呢？

通过调研，发现测试小伙伴诟病的最多的就是环境不可用。环境到底多不可用呢？

你基于 Grafana 和 Prometheus 做了一个环境可用的监控报表，使用后，发现环境在工作日整体可用率只有35%左右，主要原因是：几个核心热点应用经常挂了没人管。

你拉了整个 Team，明确了部署责任人，约定了部署规则：只能中午饭和晚饭时间部署，并且部署后要自己看一下是不是 OK。

一周后，环境可用度上升到了 65%。再深入分析，发现 2 个同学不守规矩，总是他们在破坏规则，你去找他们单独谈话。

一周后，环境可用度上升到了 80%。还是有少量人不守规矩。
你找SRE的同学提需求，做了部署卡点，非部署时间部署必须TL审批。

一周后，环境可用度上升到了 85%。有些TL也不守规矩。
你建了个报警，环境乱部署，坏掉了，在大团队的群里@全体，告知谁搞坏了环境。

一周后，环境可用度达到了 92%。

你加了一个 Feature：应用挂了一段时间无人响应，自动重启服务功能，仍然有问题，就自动回滚上一版本。
你推动了开发解决了某个应用启动时间过长的问题。
你推动了环境分组。
你推动了测试环境版本上线的规范流程实施。
你推动了冒烟自动化用例卡点。
你推动了环境部署人备份机制。
你推动了全员基础环境部署培训。
你总结了部署手册。
你做了。。。。。

最后，环境可用度稳定到了 97% 以上。你为测试节省了 60% 以上 block 时间（原来可用度未到 35%）。

 

例子 2：上面的问题，除了环境，还有一个槽点：开发提测质量不高。

测试的头几天，很多主流程都走不通，导致测试总是在等待，或者是跟着开发一起联调。而这段时间，已经被习惯性的认为是测试时间了，因为：提测了。

你推动了：测试提供冒烟用例，开发必须完成一定程度的自测才能提测。

你推动了：测试和开发做自动化同期共建，在开发过程中，核心功能就被自动化用例保护起来了。

你推动了：开发切分 feature 提测，而不是攒一个大招一下子提一坨。

你推动了：代码 Codereview 变成团队常规活动，QA 在早期跟进核心代码，把问题坑杀在萌芽阶段。

你推动了：外部资源联调非常早的进行，不会让它在测试后期成为测试 blocker。

你推动了....

例子3：你发现测试时间长，QA 自己也有问题。

你推动了：有明确的测试计划，并让所有干系人都有明确的预期。

你推动了：测试依据风险测试，最大的风险得到最快的cover，科学分配时间，明显缩短 bug 反馈时间弧。

你推动了：bug 严格管理，所有重要 bug 都及时修复。

你推动了：良好的沟通和汇报机制，每天让团队主要干系人清晰的知道，距离发布还差多远。

你推动了....

你能讲出自己做过 5 个以上这样的成功例子，我敢保障，你会被1线大厂疯抢。职级基本都是专家起。

持续学习能力和复杂问题解决能力

例子1：
你近期的工作是帮助团队提升后台服务稳定性。你看到了 NetFlix 内部使用一个叫做 ChaosMonkey 的东西来随机对生产服务期进行攻击，而逼迫工程师提高稳定性，所以，你也实现了类似（更温和）的内部机制，推动团队稳定性的提高。

你怎么知道这个叫做 ChaosMonkey 的东西呢？因为你会习惯性浏览一线厂商的技术博客，参与行业大会，关注各类新技术。持续性的养成习惯。

例子2：
做大规模接口自动化好难，外部数据依赖太难搞，参数构造太费劲，assert 太难写。如果能够简单的录制回放就好了。
但是，外部依赖是个天坑，写操作 mock 也是个天坑，assert 也是个天坑。

实际的案例是，经过几年多个团队持续不屑的填坑，阿里内部已经有应用级的录制回放工具了，数百个应用成功的是用了它，把不可能回归的任务变成了可能（上万数量级的 case当天生成，当天投入使用，并可以分析覆盖率），自动化测试实施需要付出的工作时间革命性降低（不足原来付出时间的 10%）。

你能讲出自己做过 5 个以上这样的成功例子，我敢保障，你也会被一线大厂疯抢。职级基本都是专家起。

其它能力

 测试是个万金油，高阶一些的职位需要什么都要会一些 ，因为越高阶的职位需要解决的问题越综合，需要打交道的人的种类越多。不然很容易变成你职业短板，做个 List 吧（一定不全）：

• 很好的项目管理能力，至少与开发经理能力同级，甚至要强于他。

• 一定的软件架构能力。

• 一定的产品 Sense：可以跟一个资深的产品经理能够顺畅的交流，明白知道他为什么会这么想，所要实现产品的意义，路径；从产品质量方面的考虑要超过产品经理，给他输出。

• 极好的沟通能力。

• 团队管理能力（这个太重要）

• 目标管理能力

• 有一个好的内核（上面提到过）

怎么转型/怎么进阶？

其实不难，没有什么高端的方法。下面这 4 条就够了，核心秘密就是坚持不懈。

 

熟悉你的被测系统，熟悉你的被测系统，熟悉你的被测系统

能够从技术、业务角度做到对被测系统熟悉是做一个好 QA 的最基本职业素养，也是能力提升的最主要源泉。

• 自检点：我能够画出系统的架构图么？我能够读懂开发的代码么？我熟悉常见的业务监控系统么？熟悉日志系统么？知道开发是如何调试和定位问题的么？给我一个线上问题，我能定位么？我能给别人完整的介绍这个域的核心业务么？我能自己直接动手发布上线一个系统么？知道如何回滚么？灰度是如何做的？我知道所有关键的技术点么，如一个交易的幂等性是如何实现的？我在团队中有：“这家伙对系统最熟”的口碑么？
  如果自检点全部是否定答案。。。花一年时间把它全变成肯定答案。这一过程，你一定被迫学到了很多很多，并且获得了极为长足的成长，这是进阶的必由之路，也是卡了很多人的地方。 如果说做不到，后面不用看了，前面的也全部忘掉吧。

• 方法：通读所有文档，强迫自己读代码，积极参与开发所有讨论，不懂的狂问，观察开发如何上线，如何排查问题，模仿，学习，善用搜索引擎，总结。。。

 

找到问题解决问题，找到问题解决问题，找到问题解决问题

你一定有一堆问题，如果你觉得自己做得挺好，没有问题要解决，那必然是你自己有巨大的问题！

• 自检点：找一支笔，写出你觉得质量方面，你的 Team 的 10 个问题，做排序。排出最重要的 3 个。

• 方法：找到 Top3 的问题，选一个，列个接话，去解决。如果找不出来，使劲去观察，然后去看看做的好的同行，比比你比人家差在哪里。尝试去解决这些问题，从小问题，能够见到效果的问题入手，设置一个时间点。你真正解决了 5 个以上问题以后，感觉一定会有。

 

系统学习，系统学习，系统学习

• 自检点：我系统的学过一门知识么？我能讲清楚我这么操作，我写的这行代码的原理么？

• 方法：从工作出发，确认你需要补足哪些知识。从网上找一个具体知识的学习路线图，订个计划，照着来。参加学习小组，找到帮你解决难题的人，多请他吃饭，多请教他。获取知识后，马上回到工作中做检验。还是学以致用才能有所增长。结合工作来系统学习的效果是最好的。
  
  

再举个例子：

上家公司有个小伙伴（他应该也会泡这个社区），开始应聘的时候，他说熟悉 Jenkins，用的很多。

所以第一份工作是：把所有 CI 的日常工作交给了他，并告知 2 个月内要全部搞定。 他一下懵逼了，原来那些不深入的理解支撑不了工作要求。

后来他每天死磕，看了 Jenkins 所有的文档（对，几乎所有文档通读了一遍），翻了无数问题的解决帖子，记录了上百个问题解决的过程，写了上百篇 Jenkins 的小 Blog（现在还没公布出来）。

几个月以后，他比我熟了，他的一项基础能力成长为：可以独自给一个小公司完整的搞定前端、后端、移动端的一整套CI解决方案。其实单凭这一套，就能找到不错的工作了。这是依托工作，系统性学习的结果。

看到有同学说要裸辞，去接受培训。我的建议是，别这样。裸辞你就失去了学以致用的阵地，失去了真正解决问题的机会，还失去了资金来源。依托工作，自主学习是王道。自己饶过不去坎，其实有很多网上教程和非脱产培训班啊。

选择有挑战的团队，选择有挑战的团队

• 自检点：在团队里有很多人比我强么？周围的同事都是我佩服的么？我做的事儿有挑战么？

• 方法：如果这三点都是否定的，并且你处于职业生涯的早期。也许（只是也许），你该考虑一下换个团队了。

总结

本篇内容偏重技能角度，讲了讲市场的需求和 QA 如何做如何满足市场需求。行文仓促，认识有限，其实也并没有什么新东西。欢迎讨论拍砖啊：）

（文章来源于霍格沃兹测试学院）

更多优秀内容及资料可点击获取

http://qrcode.testing-studio.com/f?from=bokeyuan&url=https://ceshiren.com/t/topic/3595