关于一些正确的废话
不知不觉做测试已经一年半了。
在互联网这个更新迭代特别快的地方，不仅是技术，人才也迭代得很快。看着新进的应届小鲜肉质量越来越高，瞅着还没毕业的小朋友一个比一个有料，不禁感慨自己作为职场新人的时候已经过去了。
没有了新人buff，但是也没有变成很厉害的前辈的我，时不时会被焦虑所围绕。
当初入行的时候，心很大，想要得到的很多——变成很厉害的测试开发，做出很厉害的大家都用得很趁手的提升效率的工具。想要做的也很多——idea很多，能力很少。想做一个一键部署测试环境的东西，想做一个能够一键还原干净数据库的东西，想做一个能够把业务接口模块化的框架——可以实现测试人员根据业务模块拼装构建场景的东西——基于BDD的思路……想做的东西好多好多，可是自己却没有能力去实现，总期望能跟着哪位大神学习，以为拾人牙慧便是走了捷径。（在这里感谢前辈们为我开拓了眼界，我才有了这么多这么棒的想法）
这是我刚毕业时候的想法，想着抱紧大腿就能蹭到所有。而事实是，即使得到源码，我也没有认真地解读，更加没有想要基于那个源码做出什么，或者说真正做出有用的什么。都是听之信之，东摸摸西看看，没有一个固定的目标，也没有朝着某一个方向去真正地钻研。喜欢用点小聪明，复制粘贴改一改也的确做出过什么，得到过大家的嘉许。当时甚为沾沾自喜，现在看来发觉十分幼稚。
拥有一技之长，的确比什么都懂一点点好；做了一个可以用的Hello World版本并等同于掌握了一个工具/一项技能；想要提升自己的技术能力与工作结合利用是最有效的，没有业务价值的技术不能对你的工作产生价值，别人不会仅仅因为你好学而嘉奖你只会因为你的好学为工作带来了额外收益才会嘉奖你；学习后没有运用起来的东西隔一段时间就会忘记，是因为你根本就没有学会/没有实践的学习不可能真正地学会。
上述的大道理，我很早就听过，并且认为自己明白该怎么做。但是现在再复述一次，我对各种含义又多了一些不好描述我懒得解释的理解。这些曾经对我来说是一些谁都会说的华而不实的大道理，当我在工作中有过相关的错误后，这些大道理对于我来说才有了更加真实的，贴切的教训，是一堆残忍的，泼人冷水的实话。
其实还有更多这样真实的大道理，只是我一下子想不起来了。如果你是一名刚参与工作的人，大概看到这类道理也像我年轻的时候那样觉得就是一堆正确的废话罢。
关于我在工作中的实践分享（吐槽？）
当然，当时幼稚的不仅仅是那样的想法。还有关于测试方向的选择。当我要选择职业方向的时候，我所在的部门，有前辈做安卓性能相关的 *1，做安卓自动化UI测试的 *1，有做后端性能的 *1，我脑子一抽 ，觉得这里一片红海，所以我选择了iOS自动化+性能。现在想过来，简直是非常弱智的选择，因为完全没有考虑到市场需求+高估自身自主学习钻研能力！
关于自身的学习能力，我一直很清楚我的学习模式是依赖型的，在有前辈手把手教学的情况下，能够快速地掌握技能并且转化成为生产力。创新能力不是没有，但自学入门的能力超级弱或者说效率非常低。自己钻研的时候遇到问题非常容易钻牛角尖然后放弃。10个月过去了，在iOS自动化和性能方面，并无太大建树。曾在前辈的文档指导下出过一份手工的iOS性能测试报告，然后续就再无需求。自动化方面与主流框架Appium天生八字不合，转战Macaca后写过一个简单可执行登录的脚本，至今还没派上用场（写出来的时候还觉得自己很厉害，毕竟没人带自己摸索踩过各种神坑之后居然顺利做出了脚本，呵呵）——原本是打算用来跑马甲包的，因为环境限制+运行效率不高+需求不大，没有花时间继续做脚本的断言，所以现在还是手工过马甲包。期间也努力了代码扫描方向，在两位大大没空做的情况下，认真花了一段时间成功搞定了可运行的基于sonar+oclint的OC代码扫描，但是也是由于没有需求，被闲置了。
从上一段也不难看出，iOS的性能、自动化、代码扫描——我目前接触到的能想到的有一点点技术含量，与测试开发相关的需求，量都不大。但是技术要求却比较高——OC的学习成本高+iOS开发的框架学习成本高——当然这些高都是基于我自身的情况的评价。并且Xcode本身自带的比较强悍的检测工具——内存泄漏、应用启动时间统计、应用使用过程中的内存占用、网络流量消耗等等。开发在调试或者自测过程中打开这些工具就能轻易发现较为严重的性能问题，并不需要留到测试专门做iOS性能测试。
当然，iOS性能当然不只是这么点东西，Xcode自带的检测工具也有很多限制和不足，但是我司的对于iOS的性能要求不高，只要没有严重的操作卡顿、闪退、崩溃等问题就足够了，而满足这些需求甚至不需要用到Xcode的检测工具。
而iOS自动化也是一个比较尴尬的地方了，成本高但是收益非常一般。一个是因为需求量不大，iOS自动化最多的应用场景就是上线前+马甲包测试。由于iOS10开始干掉了UIAutomator后，后面的自动化框架实现思路都是通过FB出的WebDriverAgent调用原生的XCUITest方法进行的（根据我的理解，如有偏差请务必指正，谢谢）。这存在的比较大的问题是对手机性能要求比较高并且配置挺麻烦的，单单一个重签名就够不大懂苹果证书规则+不熟悉Xcode的人喝一壶。而基于WDA运行的自动化测试在性能不好的测试机上面效率非常低，低到一个滑动操作需要十几秒来完成。并且Macaca作为一个比较新的框架，虽然有人维护更新频率也ok，但还是经常有各种各样的坑，并且如果不熟悉node开发，调试也是很难找对思路调试的（这里又体现了我一个智障的选择思路：为什么不选java/python语言来接入，我只能说我选node只是因为他的example看起来最简单并且逼格高）。而iOS原生的XCUITest的方法中不能满足手势密码连线的需求，脚本只能做成半自动的，加上我还没做断言，需求量又小，干脆脚本就被闲置了。
而代码扫描这个东西有比较成熟的教程可以参考，过程中也踩了一点坑，但做出来之后我并不会用/我不知道怎么使用有价值，然后大神也没空用最后干脆就没用了。
关于工作和个人发展的一些鸡汤思考
花了那么长时间，做出来的东西没有一个派上用场。我不明白为什么，所以带着疑问向公司的前辈请教——为什么我觉得我目前的工作没有什么可以提升效率的地方？别的组的方向非常明确，我们组承接的任务又多又杂，没个主线的怎么玩？（到了这一刻我还认为自己没问题，是工作不对hhh）
前辈给我的指导大意是，其实我们组应该是能接触到最多东西的地方了，承接的系统不同能让我有很多学习和实践的机会，这么多系统选任意一个选都可以做效率提升相关的东西。而且不要总想着要一下子做很厉害的东西，先从手头上最容易实现的最易见成效的小脚本开始做起。而且任何技术都只是工具，只有掌握扎实的测试理论和测试方法，会质量管理，才是测试的立命之本。
我一听，这不感觉又是正确的废话，我舌灿莲花似的巴拉巴拉说了一堆我觉得可以尝试的地方，最后一个都没有落实。——说到底，我当时还是没有认识到自己眼高手低的毛病，总觉得自己是还没开始发光的金子、茶壶嘴里掉不出来的饺子。
好大一坨鸡汤不看也罢所幸身边总有勤勤恳恳工作的同僚，他们用实际的产出啪啪地打醒了我。身边有同僚在测试等待的间隙抽时间完善了渠道包检查的脚本；有同僚在完成工作之余总会看书学习，专心学好一个又一个东西，并在工作中利用一切机会用上所学的知识；有同僚工作认真效率高，并且非常擅长把某一些工具用到极致玩出花来；有同僚默默地做出了我意想不到的东西；有同僚经常发一些鸡汤，但最后我发现有些鸡汤的确营养丰富。身边很多优秀的同僚都用身体力行告诉我前面说到的大道理，让我意识到自身的问题。可能我并不容易改，但是正确认知自我也是非常重要的一个事情。
而关于如何在工作中找到效率提升的点，并且正确使力的问题，除了我自己想一步登天的问题之外，还有一个很重要但我缺少的东西——测试理论与质量管理思维。前两天我循例刷了刷各大求职网上对测试的要求，都有一条“精通测试理论和方法”的要求。上学的时候粗浅地在软件工程课上学习过软件测试一课，我便认为我熟悉测试理论，在工作中投入在执行一年多，我便认为我精通常用测试方法。然而现在让我说出测试理论和常用测试方法，我却没办法一下子巴拉巴拉一堆。这说明我既不熟悉也不精通，我只是自以为是。包括之前自己搭建好代码扫描却不知道怎么用于提高质量上也是。我才真正明白只有掌握扎实的测试理论和测试方法，会质量管理，才是测试的立命之本。这句话的含义。虽说光有理论没有实践是不可取的，但是扎实的理论基础的确是实践的最佳指导。扎实的理论知识能够让我在遇到问题和困难的时候不至于没有任何头绪，能够让我更好地把技术运用到测试工作上，而不是乱使力一通。又是一坨鸡汤，但是这真的是大实话。
感想说完了，补充一下之前关于测试方向选择的市场需求，目前以我司的情况来看，后端测试的需求量是最大的，作为一个后端测试，最好是能够自己搭环境+进行性能测试并输出分析调优报告+可持续的接口自动化测试+输出造数据的工具或脚本；安卓端测试的需求次之，最好是能够做性能测试并输出分析报告+UI自动化脚本+独立完成兼容性测试；而H5方面的测试我司要求最低，甚至不求兼容性做得很好，而根据我的了解H5的自动化测试工具都比较适合开发使用，如果作为H5测试的话，建议发展方向是mock+H5性能；iOS——卒。
唠嗑唠嗑
如果看到这里，非常感谢你花费这么多时间看完我整篇文章。上面提出的所有观点都来自我自己的经历和思考，如果有不同的想法或者有待指正的地方，非常欢迎大家留下你们的评论，希望能够一起进步XD。
