测试工程师，要想明白这件事！
iTesting，爱测试，爱分享
在我们测试圈子里有一个有趣的现象，那就是：有一部分测试工程师是「代码困难户」，不太擅长写自动化测试脚本，甚至畏惧写代码。以我身边的情况为例，能够拥有代码技能的测试工程师比例大约为50%，就好比10位测试工程师里，有一半人都属于「代码困难户」。
前些年，我有个朋友跟我聊到他的公司，一家在上海张江的某个中等规模软件公司，他们公司的测试团队12位员工，只有他一个人能编写自动化测试脚本，其他同事都是编程语言入门小白级别的，工作中更多以手工测试为主。
别不信，这就是我们所处的行业现状。
这种情况让IT同行们对「测试工程师」有着不小的偏见：门槛低、点UI界面、女生多、工作要细心、挑战性不大。
这种偏见很常见，就好比「程序员都是修电脑的」、「销售都是大忽悠」、「做生意的老板都喜欢带大金链子」一样。
好在，近些年测试领域的技术发展很快，测试也有了自己的大会，如：QeCon、MTSC等大会都做的热火朝天。整个行业对测试人才的要求也在不断提高，大部分的测试岗位要求都需要必须掌握自动化测试技能，自动化测试已经是一项必备技能。如果一位测试工程师没有自动化测试技能，那他的应聘面试基本上会是四处碰壁。这说明整个行业在慢慢的洗牌、淘汰，对测试行业应该是好事。
疑问
关于学习自动化测试的历程中，有这么一件有趣的事。
我初入职场时，当时的测试领导就告诉我：「做自动化测试的成本很高，所以我们在做之前一定要弄清楚ROI」。
在很多传统行业或者商业行为中，通常会把投入产出比（ROI，Return on Investment）作为衡量一项生产活动的性能、效益、效率，来判断是否达到预期或者满足投资目标。例如，粮食的产量、物件的良品率以至于直接的货币回报等等，通常是有一个公认的正向回报参考指标。
ROI（return on investment） = 投入产出比 = （A-B）/B。
A：开展自动化测试工作所能获得的回报，节约的人力、回归的范围等等。
B：开展自动化测试工作所需的成本投入，框架设计、用例设计、脚本编写和维护、脚本的执行、看报告提缺陷的时间等等。
当时的我非常信服这个概念，100%地去执行，以至于后面每每有同事跟我谈论自动化测试方案时，我都会说一句：「有没有考虑ROI，投入和收益是不是正比？」
再来看看这个故事：
美国某个教会有一群聪明的孩子们，他们花了200美元买了40件衬衣，每件衬衣5美元。「B = 200美元」
当孩子们拿到衬衣后，对衬衣进行了包装、印教会logo、打包等作业。
然后孩子们以500美元的价格，将这40件衬衣卖给了教会。「A = 500美元」
ROI（return on investment） = 投入产出比 = （A-B）/B。
A为获得的回报。
B为原始的投入。
计算公式：（A - B）/ B = （500-200）/ 200 = 300/200 = 150%。
我们期望的都是：分子能越大就大，分母能越小就小。
ROI，这个概念跟随了我3年，我毫无条件的接受了它，以至于把ROI的概念深入到了生活的每个细胞中。
例如：
想学Python的时候，买一本《7天速成Python》，期望1周就成为Python大神；
想减肥的时候，下个《Keep》App，跑完步就立刻去称称体重，看看自己瘦了多少；
想学经济的时候，买一本《薛兆丰经济学》，实际上是，这本书买回来还没翻10页，书就吃灰了。
但这些事挨个都做过了，并没有让我成为Python大神、6块腹肌和经济达人。
我总觉得有哪里不对，但又说不上来什么道理。渐渐地，我似乎开始怀疑当时的唯ROI论到底是否正确。
尽管在很多地方ROI的表达非常有效，但是在测试领域尤其是自动化测试领域却不如此。我们可以说某某公司或团队自动化测试的覆盖率高、产出BUG多，或者场景化测试有深度，但这些都是从不同的维度去看待的，不同的公司、项目和团队对自动化测试的诉求都是不同的。如果单从一个公式中就能推导测算出一个值，并尝试拿着这个值去度量，显然是不靠谱的。
渐渐地我发现，原来我已经习惯了，干什么事都想找捷径，都想以「最小的投入成本，获得最大的回报」，工作中的方法竟然对我的生活产生了影响，这属于「惯性思维」。
这个事给了我很多启发，之前做过很多事情，折腾来折腾去，也没见事业有什么起色，回过头来看，我发现自己真正能够踏踏实实干的事情，貌似也没有几件。
记得高中时有位同学，他每次考试都名列前茅，我就去请教他怎么做到的，他说：「老师布置的作业我都做完，然后把课本和练习题里面所有的题都做一遍」。大家回顾一下自己高中的情况，练习册、课外教材上都有很多练习题，有多少人一道题不落下全部做完的？几乎没有人会全做，对吧？因为这完全是投入体力和时间的事，这种笨笨的事，很多聪明人不屑于去做，但是人家就笨笨的去做了，就这么简单。
后来这位同学高中考上北大，然后保研继续读，现在在业内号称科技四小龙之一的一家科技公司做技术负责人，从事的是人工智能AI研究的领域方向。他跟我说，人工智能的第一法则就是：「简单的动作确保不能出错，然后逐步迭代，越来越复杂」。
后来我理了理思路，做了深刻的反思，原来自己之前的做事方式是存在问题的，「最小的投入成本，获得最大的回报」只是我自己一厢情愿、天真的想法，世间哪有那么多好事？
这都不遵守「能量守恒定律」啊，我们高中物理课上就学过，请您想想，是不是这样？
其实不光是做事，做人也是一样的。尤其是跟朋友之间，不能什么事都斤斤计较。当好朋友有困难需要帮忙时，难道还要考虑帮他不帮他，我现在帮助他以后会对我有多大的回报。如果凡事都考虑ROI，你会发现自己把自己变得很「油腻」。
当时想明白这件事时，我真有点懊悔，过去的时间都浪费到哪儿去了，到底做了多少「聪明事」？追求了多少「ROI，投入产出比」的事？
所以，今天我把这一把钥匙分享给大家：「简单的动作确保不能出错，然后逐步迭代，越来越复杂」。
自动化测试，3万行代码足够了，三个月足够了，坚持写，不断优化、不断迭代、不断提高。
减肥跑步，每天5公里，坚持三个月，撸铁一万次。
学Python，每天一道题，三个月，坚持写3万行代码。
问题
关于如何提高个人的编码能力，大家可以自行努力：确保最基本的代码是正确的，逐渐迭代，越写越复杂，切忌不要走捷径。
回到我们今天的话题，看到这里，大家心里面肯定会说：「你说的都对，但是现实怎么办呢？团队中依然还是有很多测试工程师短期内写不了代码啊！」
当然，我也是有解决方案的。这里有一款「API自动化测试脚本一键生成工具」供大家下载使用。不但可以免费下载，工具的代码还是开源的，给想学编码的朋友参考学习。
一举两得。
向大家隆重介绍一本书《敏捷测试高效实际 测试架构师成长记》，下载地址的二维码就在这本书的扉页。
为什么介绍这本书呢？因为有三个原因。
01.自动化测试
第一个原因：自动化测试脚本？一键生成！
你没有听错，自动化测试脚本，可以点一个按钮自动生成了。
这本书中开源出来了一项API自动化测试大杀器：「PostSuperman」，这个工具最大的特点就是：「一键生成API自动化测试脚本」，让编程能力较弱的测试工程师也能够轻松搞定自动化测试，动图如下：
基于Postwoman工具，做了二次的开发，加强了很多测试功能，点击生成的按钮，可以迅速将API接口的报文生成为Python自动化测试脚本。
有的朋友说了，Postman工具也支持生成脚本的。
嗯，没错，但是Postman生成出来的脚本，没有PostSuperman出色，原因有以下几点：
一键生成，立即执行
脚本生成后，不需要做修改，直接放在pytest工程里就可以运行，非常方便；
支持自定义断言
PostSuperman工具生成的脚本，支持针对response的断言（而且可以灵活配置），Postman生成的脚本没有断言；
支持场景接口
当你有一组接口时，在Postwoman中设置为一个Collections，直接可以生成场景化的脚本。
在PostSuperman这款工具中都体现了，生成脚本如丝般顺滑，点击一个按钮，脚本自动生成，立即就可以执行了。
PostSuperman不但可以生成一个接口的脚本，还支持生成「场景化批量接口」的脚本生成，请看下面的动图：
PostSuperman不但可以傻瓜式的生成脚本，还支持「用户自定义配置」，你可以在一个配置页面设置自己的脚本特征（加上注释、额外的代码、自己想要或不想要的断言规则），然后取个模板名称，下次生成脚本时使用这个模板名称，就可以生成你想要的脚本啦！情况下面的动图：
这些看起来酷酷的功能，是我和两位朋友一行一行代码写出来的，我们所使用的代码一共只有2000行代码，可以说每一行代码都花在了刀刃上，工程的下载地址已经印在书的扉页，大家有兴趣可以下载学习。
02.敏捷测试工程师
第二个原因：敏捷测试工程师需要掌握哪些技能？
当一位测试工程师小A，在一个敏捷开发迭代中开展测试工作，小A就能称之为「敏捷测试工程师」了吗？
答案肯定是否定的。
有两点是必须要做到的：1、认知上得做到「敏捷」 2、技能上得做到「敏捷」
这里提到的「敏捷测试工程师」，是指在工作中有意识，主动使用敏捷的方式方法开展测试工作，利用技术解决各种各种工作的难题，最终实现端到端的价值交付。
不但要求测试人员具备全栈测试工程师所需要的测试技术，还需要拥有一定的软技能，最终，才能在工作中对业务功能、业务价值负责。
那么，具体需要掌握怎样的技能，才能成为「敏捷测试工程师」呢？大家可以尝试在书中寻找答案。
03.测试效能提升工具
第三个原因：介绍了PostSuperman工具、自动化测试平台和移动端代码染色覆盖率工具的开发过程
这三款工具属于测试创新工具，占了全书一半以上的篇幅，从架构到技术细节，详细诠释说明了。
01 代码染色覆盖率工具
市面上完整介绍「代码染色覆盖率工具」的技术书籍并不多，本书从为什么做这款工具、产品功能设计、技术选型、设计架构图、核心代码编写、经验总结等等，原原本本地还原了整个工具从0到1的过程。
目前，代码染色覆盖率工具已经在作者公司进行了投产使用，效果还不错，有学习诉求的朋友可以来看看，包括这款工具对测试技术的思考，应该能对你的工作有所帮助。
02 PostSuperman自动化测试脚本一键生成工具
上文有介绍过，本书除了开源了PostSuperman这款工具，还把如何做PostSuperman工具的每个步骤都讲透了，整个工具开发的过程，都事无巨细的记录了下来。你可以下载后直接使用，也可以自己再加工开发改造，我们的目的帮大家把整个工具的技术设计、编程语言和功能细节都讲透、讲明白。
03 自动化测试平台
作者公司所使用的自动化测试平台，详细介绍了：
为什么做这个平台
这个平台能带来哪些价值，解决什么样的问题
怎样做架构设计的
用了什么编程语言、如何开发的
等等……
觉得这本书的特色不足？还不够吗？再来重点介绍一项特色吧。
04.漫画式的叙述方式
虽然本书是一本非常严肃的技术书籍，但是，处处却不乏创新。
全书有22副漫画贯穿全书，讲述了一位从校园毕业的「测试小工」如何逐渐成长为「测试架构师」的，这期间经历的磨难、焦虑和有趣的事，凭着主人公自身的付出和努力，终于成长为一名优秀的「测试架构师」。
整个过程是非常有意思的，与其说这是一本技术书，不如说是一本「测试工程师的凡人修仙传」，生动搞笑的叙述风格贯穿整本书，让你在努力学习技术的同时，劳逸结合。
05.为什么写这本书
有人问我们，你们为什么写这样一本书？
我想说的是：「软件测试是我们从事并热爱的职业，我们的奋斗方向是：不断适应行业的变化，并将软件测试这份工作做到极致」。
软件测试是一个需要动脑、工作内容抽象度极高，并且需要足够创造力的岗位，希望本书可以帮助你拓宽思路，提高对软件测试岗位的认知，学习书中的技术，在工作中学以致用。
就像我们写这本书的初心一样，希望可以帮助整个测试行业的同仁一起进步、共同提高：「当你的测试工作遇到瓶颈时，翻开本书，为你打开一扇窗」。
最后，还有软件业内各位专家、互联网大厂的大佬们推荐（朱少民、茹炳晟、云层、恒温、思寒……等16位专家），有这么多专家的爆赞推荐，你，来一本吗？
现在JD、当当网有折扣哦。
- - 时人莫小池中水, 浅处不妨有卧龙 - -
作者：
Kevin Cai, 江湖人称蔡老师。
两性情感专家，非著名测试开发。
技术路线的坚定支持者，始终相信Nobody can be somebody。
· 猜你喜欢的文章 ·