[如需转载，请在转载时注明出处，并保证本文的完整性]
在圈里混迹了几年，难免要接触到自动化，不然不能叫一个合格的测试工程师。其实目前存在的自动化都是靠着市面上提供的工具来完成了，当然财大气粗的公司选择自己开发，本是无可厚非。关于自动化工具的比较前篇已经详细叙述过了，其实自动化接触多了，说起来也就那么回事，没什么神秘色彩。此篇作为自动化的结束之作，将自己几个月写作自动化脚本的心得给记录一下，后续自己已经转战测试其他方面，自动化也要告一段落了。自动化脚本依赖用例设计，这个不需要我去啰嗦，还是那句话，进入这个行业把测试设计做好一点错都没有，无论测试工程师走多远，设计永远都是核心，设计方法永远都不能落下。废话不多说，自动化一般是将手工执行的用例中抽取一部分实现，毕竟开展自动化首先要计算的就是投入产出比。将所有用例都自动化不是不可以，只是成本太高，收益往往达不到预期效果，而且自动化都是在项目的中期才开始搞（开始时可以规划，毕竟这个要等到测试用例设计完成后才开始正式步入实施阶段），如果全部自动化，成本、人力按照标准配置全部用来搞自动化肯定捉襟见肘，因此，自动化抽取的范围较手工测试小，更能集中在主业务上，关注主流程，在项目迭代版本实施过程中更快更节省的发现版本问题。
言归正传，自动化脚本写作人员其实和编码人员没什么两样，初期都是没确定最终的结构和完全实现，都是领导一声令下就开始投入 ，写作的过程中领导变变需求，更改更改环境，后续稳定性测试、更高层面的测试都需要你的脚本来集成，其实写到这里，脚本的几个要素已经全部出来了。那就是脚本要做到可复用、可修改、可扩展。咦，这怎么这么眼熟？靠，这TM居然就是代码，不错，这就是代码，写到后来，脚本都是要往代码上靠，事实证明，自动化脚本也是一种代码。
首先谈谈可复用，其实道理很简单，脚本的核心是逻辑，逻辑作为脚本对象的抽象，首先考虑的就是要复用，辛辛苦苦写好调试完毕的逻辑如果不能做到复用，那有什么用？例如添加一个对象，对于这种逻辑，写作时对象的名称，属性肯定是抽象成输入参数，这个输入参数的范围和字符控制当然和程序中保持一致，对于内部的正确输入给出正确结果，错误给出错误，给出if-else或者switch方法内置，这样，一个逻辑就可以适用添加对象的所有用例，正确的给出正确结果，错误给出错误提示，每个用例在调用时只需要改下输入参数即可复用，这样，既维护了脚本的稳定性，后续修改，只需要改下这个逻辑内部，不会每个脚本都去变更，更便于维护。更不至于逻辑过多让自己头疼，不知道哪个跟哪个了。太多也失去了逻辑的本意，说明还可以继续抽象。
其次，我想先写可扩展，可扩展性最近在程序语言中屡屡被提及，次数也越来越频繁，究其原因，因为软件进入了工程生产模式，不再是交付完了就了事，这个版本做完了，下个版本还有大把需求在此基础上开发，你的程序不可扩展怎么成？难不成每次基础代码都要重新写？既浪费工作量，还增添了不稳定性。对于前一个版本经过大量测试和修改过后的稳定代码直接拿过来二次开发扩展岂不是规避这两种缺点？脚本类似，每次写好一个逻辑，调试通过后经过那么多轮昼夜的循环连跑，正确性是可以保证的，下个版本直接在这个逻辑的基础上封装和二次开发，脚本既快又好。那么如何做到可扩展呢？其实脚本这个东西多少还是要依赖业务。个人认为，逻辑的抽象程度不是越细越好，当然更不是越粗越好。逻辑的粒度依赖业务的复杂程度。一般情况下，一个功能点或者一个子流程（不可分割的单元）为一个逻辑单元，这个划分和函数类似。在此基础上，更复杂的流程和业务在多个逻辑之间组合。在缝隙之间连接好即可。
最后就是可修改，这一点毋庸置疑，脚本如果每一次修改都伤筋动骨，相当于重写，那这个脚本就是相当的失败，我们经常听到开发人员这样抱怨：他的代码我看不球懂，与其改他的代码我还不如重写！啧啧，问题就在这个，与其改，我还不如重写，我们的脚本也一样，你将每个逻辑都写的很复杂，一旦修改，就会大动干戈，要改的点相当多；你把常量写死在每个脚本里，一旦这个常量（譬如动态ID）发生变更，你的脚本每个都需要改，就算改完还不能保证自己没有遗漏，你这是干什么？你这不是玩自己么，自己被自己玩死，效率还低下，到头来付出很多，却没有产出，你怪谁？你还别不信，笔者就碰到大把这样的人，有些还是写了不短时间脚本的老老员工，真奇怪，还真有人没学会吃一堑长一智，反复犯这样的问题，我真是无语凝噎。
看完上面的朋友一定有个问题，就是我好像把脚本和逻辑混淆了。其实不然，有一句话我一直没说相信大伙也已经明白，那就是，自动化脚本的写作核心就是写逻辑，就像代码中的类和函数一样，这个是基础，基础，没有良好的逻辑思维，你的脚本是不可能写好的，抽象是面向对象编程的核心，同样也是自动化脚本的核心。
自动化啊自动化...
没实行过自动化的一枚测试
