gitbook/自动化测试高手课/docs/522445.md

94 lines
9.4 KiB
Markdown
Raw Permalink Normal View History

2022-09-03 22:05:03 +08:00
# 结束语|测试有终点,成长无边界
你好,我是柳胜。
首先,恭喜你完成了这门课程的学习,感谢你的一路相伴。不得不说,我们的专栏要结束了。不管是一门课程,还是一个项目,结束的时候都需要一个回顾的仪式,把学过的内容再次梳理和总结。跟开篇词不同的是,到这里我们已经翻过山涉过水,再次驻足回望,会看到不同的风景。
正如开篇词的标题“做性价比最高的自动化测试”怎么通向这个目标需要先有一个整体视角不是割裂地去看待各个测试细分领域。这样你才能知道把有限的精力投入到哪里才能得到更高的ROI。
为了达到整体效果我们不仅在水平方向做了测试左移和右移分别切入到开发知识数据知识和运维知识还在垂直角度依次从单元测试、API测试、UI测试、验收测试各个层面来分析它们各自的实现方法和优劣势。有了整体视角后我们就可以运用ROI思维来分配自己的精力了用Job模型做好设计用自动化测试工具写好代码。
总结一下,在这个专栏里,**我们一共覆盖了业界三大技术方向13个知识点。其中有6个开发知识点3个运维知识点4个数据工程知识点AI单独作为数据工程下的一个知识点**。
方法论和模型也是专栏的特色。我一共讲了9个模型其中**微测试Job模型、3KU法则和3KU金字塔模型**都是在业界首次提出的新模型。而质量度量体系,也是第一次对业界林林总总的度量做出的结构化整理。
除了学习方法论我们当然也不能忘了落地和实践我在讲解中为你穿插介绍了10款测试工具覆盖单元测试、API测试、数据测试、UI测试和布局测试等等。
现在回顾开篇词里“航海指南型”的学习路径,你是不是又有了新的体会?
![图片](https://static001.geekbang.org/resource/image/20/d9/2056005c907cf1e0abe5a4c4590295d9.png?wh=1920x1080)
如果把专栏学习比作我带你一同航海探险那后面的总结图就是为了庆祝我们完成这次冒险我送上的航海图。我把重要知识点和它出现的章节做了梳理方便你回顾紫色的A、B、C对应三大技术方向蓝色的D、E对应模型与工具
![](https://static001.geekbang.org/resource/image/01/23/0192a1fc38dab85bb7b07e6bfefc4423.jpg?wh=6651x4802)
通过总结图你也能感受到,我们讲到的内容知识面很广,还要覆盖道术器三个维度。
还记得今年2月开启专栏项目时一共规划了30讲估计内容有15万字还要提炼各种图和表格。面对这个工作量我的心情是又期待又畏惧。
期待在于能把自己工作这么多年积累的经验心得,写下来分享出去。这对我而言,是一个梳理和再学习的过程。而畏惧来自于不确定自己能不能做好“传道授业解惑”的角色。
真正的高手能把一个复杂的事情掰开了、揉碎了以简单干脆的方式告诉别人“这xx就是这么回事”。可以说这简直是对自己技术专业水平、知识理解水平、讲解表达能力和持续写作耐力的四重考验。
尽管下定了决心,准备了很久。但从项目启动到最终交付整个专栏,我也有种过五关、斩六将的感觉。从刚开始诚惶诚恐、怕自己写不出来,到后期写完了又持续整理删减,怕啰嗦了浪费同学时间。这里特别要说的就是你们在留言区的积极反馈,这给了我非常大的鼓励和启发。
我看到有朋友在留言区的反馈“一看就会,一上手就废”。这种情况,其实我在设计专栏的内容时就在思考,广度和深度该怎么配比,才能为你提供最好的内容。
这个问题确实困扰了我好多天。我先写出了Job模型、自动化测试价值这几讲来找感觉。有一天我在写ROI的时候突然悟到了“**最好的内容**”不就是给读者朋友做“**最优ROI的知识分享**”么?
领悟到这点以后我很激动,然后很快就理清了专栏的设计思路。我力求在专栏里分享的是你在网上找不到的知识,有启发的观点、能落地的思路、删繁就简的模型、更贴近业务的场景案例,以及我所积累的实践经验体会。而网上能很容易搜索到的知识,工具的使用技巧、代码的调试等等,不应该占用专栏宝贵的篇幅,给出链接就可以了。
相信这个搭配,能让你学到价值最大化的内容。而为了弥补“上手”的最后一公里路的问题,我会持续地更新本专栏的 [GitHub仓库](https://github.com/sheng-geek-zhuanlan/awesome-test-automation),分享更多的免费又易上手的资料。
![图片](https://static001.geekbang.org/resource/image/b5/5b/b52e1d2627486e0e46afea04ea73195b.jpg?wh=1920x1549)
在这篇“结束语”的留言区里,希望同学们都能“冒个泡”,分享一下在这个专栏中的收获和心路历程,还有将来的打算。也欢迎你继续跟我交流互动,我会定期回看留言动态。
## 学习还未结束
下面,我继续讲讲我的心里话。
专栏学习虽然告一段落,但测试从业者的成长却要“活到老学到老”。关于学习,我最想聊的一个话题就是**跨界学习**。为什么说跨界学习重要呢?
做了测试和开发这么多年,我越来越感受到测试无法成为一门独立于软件开发和运维的技术。换句话说:没有这样的好事,我只是学好了测试工具和技术,就能到一个企业把自动化测试做好。
一个优秀的自动化测试工程师,应该同时也是一个优秀的全栈技术工程师。
在这个专栏里我也提到做好单元测试需要先做好代码设计做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://static001.geekbang.org/resource/image/58/0c/587d264b94f8c42104f9fb5635dcf30c.jpg?wh=1142x801)](https://jinshuju.net/f/a51zTF)