|
|
# 结束语｜测试有终点，成长无边界
|
|
|
|
|
|
你好，我是柳胜。
|
|
|
|
|
|
首先，恭喜你完成了这门课程的学习，感谢你的一路相伴。不得不说，我们的专栏要结束了。不管是一门课程，还是一个项目，结束的时候都需要一个回顾的仪式，把学过的内容再次梳理和总结。跟开篇词不同的是，到这里我们已经翻过山涉过水，再次驻足回望，会看到不同的风景。
|
|
|
|
|
|
正如开篇词的标题“做性价比最高的自动化测试”，怎么通向这个目标？需要先有一个整体视角，不是割裂地去看待各个测试细分领域。这样，你才能知道把有限的精力投入到哪里，才能得到更高的ROI。
|
|
|
|
|
|
为了达到整体效果，我们不仅在水平方向做了测试左移和右移，分别切入到开发知识，数据知识和运维知识；还在垂直角度，依次从单元测试、API测试、UI测试、验收测试各个层面来分析它们各自的实现方法和优劣势。有了整体视角后，我们就可以运用ROI思维来分配自己的精力了，用Job模型做好设计，用自动化测试工具写好代码。
|
|
|
|
|
|
总结一下，在这个专栏里，**我们一共覆盖了业界三大技术方向13个知识点。其中有6个开发知识点，3个运维知识点，4个数据工程知识点（AI单独作为数据工程下的一个知识点）**。
|
|
|
|
|
|
方法论和模型也是专栏的特色。我一共讲了9个模型，其中**微测试Job模型、3KU法则和3KU金字塔模型**都是在业界首次提出的新模型。而质量度量体系，也是第一次对业界林林总总的度量做出的结构化整理。
|
|
|
|
|
|
除了学习方法论，我们当然也不能忘了落地和实践，我在讲解中为你穿插介绍了10款测试工具，覆盖单元测试、API测试、数据测试、UI测试和布局测试等等。
|
|
|
|
|
|
现在回顾开篇词里“航海指南型”的学习路径，你是不是又有了新的体会？
|
|
|
|
|
|
|
|
|
|
|
|
如果把专栏学习比作我带你一同航海探险，那后面的总结图，就是为了庆祝我们完成这次冒险，我送上的航海图。我把重要知识点和它出现的章节做了梳理，方便你回顾（紫色的A、B、C对应三大技术方向，蓝色的D、E对应模型与工具）。
|
|
|
|
|
|
|
|
|
|
|
|
通过总结图你也能感受到，我们讲到的内容知识面很广，还要覆盖道术器三个维度。
|
|
|
|
|
|
还记得今年2月开启专栏项目时，一共规划了30讲，估计内容有15万字，还要提炼各种图和表格。面对这个工作量，我的心情是又期待又畏惧。
|
|
|
|
|
|
期待在于能把自己工作这么多年积累的经验心得，写下来分享出去。这对我而言，是一个梳理和再学习的过程。而畏惧来自于不确定自己能不能做好“传道授业解惑”的角色。
|
|
|
|
|
|
真正的高手，能把一个复杂的事情掰开了、揉碎了，以简单干脆的方式告诉别人“这xx就是这么回事”。可以说，这简直是对自己技术专业水平、知识理解水平、讲解表达能力和持续写作耐力的四重考验。
|
|
|
|
|
|
尽管下定了决心，准备了很久。但从项目启动到最终交付整个专栏，我也有种过五关、斩六将的感觉。从刚开始诚惶诚恐、怕自己写不出来，到后期写完了又持续整理删减，怕啰嗦了浪费同学时间。这里特别要说的就是你们在留言区的积极反馈，这给了我非常大的鼓励和启发。
|
|
|
|
|
|
我看到有朋友在留言区的反馈“一看就会，一上手就废”。这种情况，其实我在设计专栏的内容时就在思考，广度和深度该怎么配比，才能为你提供最好的内容。
|
|
|
|
|
|
这个问题确实困扰了我好多天。我先写出了Job模型、自动化测试价值这几讲来找感觉。有一天我在写ROI的时候，突然悟到了，“**最好的内容**”不就是给读者朋友做“**最优ROI的知识分享**”么？
|
|
|
|
|
|
领悟到这点以后我很激动，然后很快就理清了专栏的设计思路。我力求在专栏里分享的是你在网上找不到的知识，有启发的观点、能落地的思路、删繁就简的模型、更贴近业务的场景案例，以及我所积累的实践经验体会。而网上能很容易搜索到的知识，工具的使用技巧、代码的调试等等，不应该占用专栏宝贵的篇幅，给出链接就可以了。
|
|
|
|
|
|
相信这个搭配，能让你学到价值最大化的内容。而为了弥补“上手”的最后一公里路的问题，我会持续地更新本专栏的 [GitHub仓库](https://github.com/sheng-geek-zhuanlan/awesome-test-automation)，分享更多的免费又易上手的资料。
|
|
|
|
|
|
|
|
|
|
|
|
在这篇“结束语”的留言区里，希望同学们都能“冒个泡”，分享一下在这个专栏中的收获和心路历程，还有将来的打算。也欢迎你继续跟我交流互动，我会定期回看留言动态。
|
|
|
|
|
|
## 学习还未结束
|
|
|
|
|
|
下面，我继续讲讲我的心里话。
|
|
|
|
|
|
专栏学习虽然告一段落，但测试从业者的成长却要“活到老学到老”。关于学习，我最想聊的一个话题就是**跨界学习**。为什么说跨界学习重要呢？
|
|
|
|
|
|
做了测试和开发这么多年，我越来越感受到测试无法成为一门独立于软件开发和运维的技术。换句话说：没有这样的好事，我只是学好了测试工具和技术，就能到一个企业把自动化测试做好。
|
|
|
|
|
|
一个优秀的自动化测试工程师，应该同时也是一个优秀的全栈技术工程师。
|
|
|
|
|
|
在这个专栏里，我也提到做好单元测试，需要先做好代码设计；做API测试，先了解API设计规范；做UI测试也需要了解界面开发技术。测试作为整个软件生命周期中靠后的那一环，如果我们不懂开发，不懂运维，只懂测试，“皮之不存，毛将焉附？”。你很可能会做出一个笨重又费力的自动化测试方案。
|
|
|
|
|
|
所以，我鼓励你多跨界学习，时不时看看开发的代码，了解他们是怎么修改你的Bug的；跟运维聊聊，观察下他们是怎么部署并监控服务，发现线上Bug的。
|
|
|
|
|
|
我有一个实践中的技巧，可以促进你的全栈学习。你不妨为自己的Bug设置一个必填属性，我把这个属性叫做Early possible detect In。
|
|
|
|
|
|
什么意思呢？每一个Bug，你都要考虑在理想情况下，它最早应该在哪个阶段可以发现。
|
|
|
|
|
|
这个阶段可能是在整个软件生命周期的任何一个阶段，需求、设计、代码、单测、集测和系统测试阶段，你都需要了解它们是怎么工作的。通过建立这样一个思维习惯，你不仅可以推动自己思考和跨界沟通，还能驱动优化提升整个测试团队的流程和技术。
|
|
|
|
|
|
## 新的开始
|
|
|
|
|
|
虽然我前面提到测试不能独立于其他工作，但并不是说测试和其他工作都一模一样。实际上，测试工作和开发工作有着本质上的不同：**开发是基于确定性来实现确定性，测试是基于不确定性来寻找确定性**。
|
|
|
|
|
|
怎么理解这句话呢？开发有需求分析、设计模式和开发框架，通过这些开发出软件，实现用户的需求。这都是基于确定的假设，确定的需求。
|
|
|
|
|
|
而测试呢？我们的目标是要验证最终的软件系统，是否满足用户的显式和隐式的需求。这个场景，乐观点说像寻找木桶之中的短板，悲观点可以说是“大海捞针”。
|
|
|
|
|
|
而对我们测试工程师的挑战就是，如何调度有限的资源，在茫茫大海中找出那根针。换个说法就是用最小的资源，赢得最大的质量信心。
|
|
|
|
|
|
这个问题的解就是测试的最优ROI，也可以说是测试里最有价值的那部分工作，不管它的外在呈现是一种测试策略，还是一个测试技术，还是测试工具什么的。
|
|
|
|
|
|
**希望你从今天开始，进入到一个新的思考角度，以ROI方式来看待我们测试的工作。一定会去喧嚣得平静，尽繁华见最真，看到我们工作最本质的东西。**
|
|
|
|
|
|
是要说声再见了。关于怎么做专栏，中间遇到了什么问题，我自己又收获了什么，这些更个人化的感受，我把这些写在了公众号里，你有兴趣可以点[这里](https://mp.weixin.qq.com/s/HvUQ9hppSioWoOdbwfM0HQ)了解。除了在专栏里与我留言交流，你也可以把这个公众号当作我们联系的另一架桥梁。
|
|
|
|
|
|
2022年，会是一个难忘的年度，有人经历着疫情的困扰，有人经历着工作的动荡，这两个多月的难忘时光，感谢你和我一起度过。
|
|
|
|
|
|
引用杨绛先生的一段话：
|
|
|
|
|
|
> “每个人都会有一段异常艰难的时光，生活的压力，工作的失意，学业的压力，爱的惶惶不可终日，挺过来的，人生就会豁然开朗，挺不过来的，时间也会教你，怎么与它们握手言和，所以不必害怕，光明总在前方。”
|
|
|
|
|
|
与你共勉，我们相见在天涯！
|
|
|
|
|
|
最后，我还给你准备了一份[毕业问卷](https://jinshuju.net/f/a51zTF)，题目不多，两分钟左右就能填好，期待你能畅所欲言。
|
|
|
|
|
|
[](https://jinshuju.net/f/a51zTF)
|
|
|
|