大家好，还是我，朋友给我起了个外号叫他姥爷（别问我典故。。。都是眼泪，我媳妇现在一听这三字就笑的惨绝人寰的。。。），今天他姥爷想跟大家聊聊基础。本来基础的我实在懒得说，而且也没什么逼格是不（哈哈哈，俺很虚荣的）。但现在我说一下吧，因为偶然想以前的东家的一些事。我觉得跟大家讲一下这些事挺有借鉴意义的。之所以收录到测试开发之路中，算是给想走测试开发这条路的新人们一个借鉴吧。
在老东家的时候有段时间推接口测试。把基础的架子搭好以后便急急忙忙的去测性能去了。留下业务线的一个同事继续跟着那个项目。后来转过头来看他写的东西，顿时一脸黑线的感觉。我就说最简单的一个点吧。接口返回中有一个字段对应着错误信息，这些 error message 都是 RD 的同学互相约定好的定义在他们的项目中的一个枚举中。但我的同事自己并没有将这些错误信息也定义在一个枚举中，而是直接以字符串的形式赋值到期望结果中，数个 case 中的错误信息都是这么写死的。
我问：为啥不存到一个枚举里或者你随便弄个接口里也行啊。
他说：有啥啥区别啊，没必要。
结果过了一周多的样子吧，开发那边改了一个错误信息。他这边好几个 case 挂了。然后跑到工程里手动改了好几处。又过了几天，另一个错误信息也改了。他这边 10 几个 case 挂了。他又手动改了 10 几处。类似的事情还出现在各种约定的状态值，字段名等等等等。
公司一直有 UI 自动化测试，case 的量积累的还不少。page object 这东西我是真不想说。。但还是得说，因为我发现很多小伙伴们的 page object 就只是类似下面这个样子。
public class MainPage{
public static By createProjectSpan= By.xpath("//span[contains(@class,'ProjectTree__blueAdd')]");
上面我就随便写写吧，也有用 page factory 的。反正就是把页面元素的查找方式封装起来了。 然后呢？ 然后就木有然后了。。。。。每个页面的逻辑，甭管它有多通用，统统都在 case 里写。 看着一坨一坨的重复代码我就忍不住的蛋疼。。于是乎开发那会随便改改逻辑，改改页面。。小伙伴们就蛋疼的去改 N 的 N 次方个 case 去了。
其实应该是第二件事的后续吧，就是我终于说服小伙伴们把逻辑封装在 page object 了。 但是后来我又蛋疼了。因为我发现小伙伴们封装的方法中，参数清一色的都是基本数据类型，一个对象都没有。我问他你为啥不把参数都封装在一个对象里。小伙伴们还是一句没必要吧。我接着劝服说：这个逻辑所在的页面要是加功能了呢，随便加一个必填的选项。你就得改所有脚本吧。 你要是用对象当参数，需求变动时加选项还是减选项你在类里修改属性给个默认值就行了。很多 case 都不用改。小伙伴看来是懒惰木有心思重构。然后某个时间他又蛋疼的跑去一个个改脚本去了。
在上个东家，一个跟我一样做测试开发的小伙伴负责写测试管理平台。偶然间我去看他的代码的时候，我也顿时一脸黑线。一个方法里无数个 if else，N 层 for 循环 while 循环的。还半行注释都没有。只为了遍历一个 xml。。。。。 跟我他推荐了几种模式去重构代码，或者使用开源的工具包处理 xml。可能我说的太直了伤到他了吧，也可能我比他年轻太多他没把我当回事。也可能他是没时间重构代码。 然后一个需求改变，xml 的结构也变了。。。 而且代码是他好几个月前写的。。。 我都不忍直视他改自己代码的时候有多蛋疼的样子了。。。
之前曾经在朋友圈里看有人发过一个故事。大概意思是 3 个人：菜鸟，老手，高手。他们三个人各自过一片雷区。菜鸟很自信的立刻就说我要一天就能走过这个雷区了，老手在观察了些许时间后说我需要一周的时间。这时候菜鸟很诧异的看着他，觉得老手在搞笑么。 最后高手也观察了一会后说我需要三天。菜鸟和高手都不约而同的看着他不说话。菜鸟觉得你俩都在搞笑。老手觉得高手怎么这么有把握。 于是三人分别出发了，菜鸟在路程上频频触雷，伤痕累累，最后前功尽弃，放弃了穿越这片雷区。 老手亦步亦趋，小心翼翼，铲掉了很多累但是仍有触雷的情况。身上也是带伤，但他确实在一周的时候准时穿越了这篇雷区。但这时候高手早已在终点悠闲的喝茶了。菜鸟和老手问高手：你是怎么解决那些雷的。高手回答道：我当初就没给自己埋雷。
故事说完了，大家到这应该也懂了。我上面说的 4 个事都是再给自己埋雷的典范。有些时候我们觉得维护自动化成本很高，觉得自动化的投入大产出小。这其中固然有互联网创业之期需求变化快，产品不稳定的因素。但是我们不要把所有的黑锅都扔给他背。公司除非死掉，否则也终有业务稳定的一天。届时你还能把黑锅推给谁背？别说变化太快。没有软件是不变化的，这一行里唯一不变的就是需求永远在变。而问题是，你适应的了变化么？别说产品不能自动化，我就没见过不能自动化的产品，每个产品是有几个模块不适合自动化，但我就不信处处都不适合自动化。而问题是，你是合适做自动化的那个人么？别说自动化发现的 bug 少不值得做，自动化测的是之前存在的功能，发现的 bug 要是比你测新功能都多那你们的开发也就可以集体自刎了。做自动化前你得知道自动化的目的。而问题是，你懂自动化么？
我们之前把太多的失败因素都归结于需求，归结于产品，归结于没有文档，归结于开发不配合甚至归结于自动化根本没用等等等等。
该醒醒了
老实承认吧，你就是不懂代码
老实承认吧，你就是懒的学习
老实承认吧，你就是懒的思考
老实承认吧，你就是自以为是
老实承认吧，你就是 low
知道自己 low 是好事，因为它激励着你前进。2 年前我承认我自己 low，所以我才能努力的变成今天这样不那么 low 了。
测试这个行业一开始都不会代码的，大家都认为面试的时候面试代码是在装逼。但是后来有了各种自动化，性能，安全等等。大家有了共识那就是测试也是需要会写代码的。我记得 monkey 还说过行业在这方面好转了。但是我依然可以听到类似这样的声音：怎么问这个，我来面试测试的。又或者：要求这么高，你招开发还是测试啊，再或者：问这些你要招全占工程师么。 但实际上我可能只是问了一句单例模式怎么写，而且我也没说这么一道题就决定候选人的去留吧。我到底怎么戳到这么多人的痛点了？
说到底我们对自己的要求还是太低，虽然我们号称技术工种但我们却没有用真正的技术工种该有的技能要求我们自己。
我们总是纠结某某技能是开发该会的，不是我们该会的。我就问你，你是不是写代码的？是，那你凭什么说自己不该会。
我们总是纠结某某事情不是 QA 该做的，我就问你，这事能提升质量不？能，那你凭什么说自己不该管
我们总是纠结某某公司没有人教你，我就问你，你是来给公司创造价值的不？是，那你凭什么认为你是来当学生的。
做一个测试开发，起码要以一个初级开发工程师的水平要求自己，否则这活你干不好。写自动化测试，就是写代码，就是在开发。我之所以说初级开发工程师，是因为我也知道人的精力是有限的，我们有很多其他杂七杂八的事情要做。但是如果说你达不到初级开发工程师的水平，那这活太难干了。不是说会写两行代码你就是懂开发了，能干活了。就像我上面说的那几个例子。我直接以为我们倒退到了 C 语言刚开发出来那会了。我也没说你一定得玩转设计模式，架构模式这些看着高大上的东西（我也玩不转）。但起码你得让我知道你是在用高级语言干活吧。封装这个我们绝对是第一个学的特性。已经被多少人忘到脑后了？我列举的前三个例子哪个不是可以用很简单的方式把变化封装起来的？这已经不是什么编程技能了，这就是最起码得编程习惯。基础到不能再基础的程度。
自动化的工程跟开发的工程一样，需要设计，需要架构，需要策略。你可以为了快速应对变化先糊出来一个，但是之后也要适当重构，再重构。否则人家开发那边高内聚，低耦了。我们测试这边连各种 hard code 都漫天飞呢。你觉得你怎么变的过开发。需求一个改变人家可能改一行代码，你这得改 100 行。 你说你这还玩什么了。为啥我在很多地方都说我反感关键字驱动和录制回放的框架。最大的原因就是这玩意根本应对不了变化。小项目用用还行，case 一多就痛苦死你。
当然了，开发能力不仅仅体现在应对变化上。好的开发水平能帮助你实现复杂的功能，优化框架，理解产品等等等等。这些都是有助于你的工作的。
在写代码的事上说了这么多。。。我也是够啰嗦的。很多情况下自动化的成败也并非是代码的问题。 是策略的问题，是权衡利弊的问题，是衡量得失的问题。每个产品都不一样，很难总结出个通用惯例。我就说说大家总在纠结的自动化测试发现的 bug 少，做自动化有啥用的问题吧。 因为最近总是听到大家在纠结。
首先，觉得自动化测试发现的 bug 少就质疑自动化测试的人，从根本上就把自动化的目的搞错了，自动化本不是为了发现 bug 的。这么说吧，你决定自动化的东西肯定是在一定程度上趋于稳定的东西或者是你认为即使变化你也可以快速应对的模块。这种功能出现 bug 的几率本就不大，就像我刚才说的，要是这种模块还整天搞出一堆 bug 出来那你们开发真可以自刎谢罪了。所以不要对自动化发现的 bug 数量期望太高。我之前一个公司 6，7 千的脚本。每天跑 ci 的时候也没见有多少 bug 测出来。
OK，那我们搞自动化干嘛的，其实这不废话么，节省成本啊。以前运行这些测试用例要 3 个人，现在我两个人就搞定了。那么这个自动化就是有效的。一切不以节省成本为目的的自动化都是在耍流氓。 有些人也许会问你自动化的那些 case 根本没发现多少 bug 啊。好，那我问你，即便这些 case 没发现什么 bug，可能你就觉得这功能已经很稳定了，出 bug 的几率不大。那你测试不？如果答案是测，那不就得了。我还需要再多说什么么？ 你跟老板说你要搞自动化的时候，你觉得老板是关心你搞自动化能发现多少 bug 么？他关心的是你搞自动化能给他省多少成本。
其实自动化不仅仅是测试，还有自动化部署，上线，备份，管理等等等等。不要以为这些事跟 QA 没啥关系，还是那句话，能提升质量的跟你都有关系。
总结啥呢，貌似我通篇说了一堆没啥营养的话。我们还是好好学习天天向上吧。