引言
本来就不是文科生，也没有做总结的经验。本次要离开IM了，呆了一年多的IM，姑且总结归纳了一下自己一年来的成长，脑子一闪，就分别写下了以下四点，各位看官，若闲时，姑且听我一絮。
1.测试技能请验收
从开始IM测试到现在，也有将近一年的时间、从测试小白走向了一名准QA，期间经过了无论是自主学习还是组内培训，都积累了一定的测试技能。
这里我把测试技术划分为代码能力，以及业务能力。从代码能力上看，无疑这一年中有了巨大的提升。一年前的这个时候，我还只是一个勉强能写Python脚本的小白。当时主要的工作也都在维护现有的api测试框架上、编写接口自动化用例以及给新入司的实训生/实习生培训指导Python自动化。那时候有点蜜汁自信，以为掌握了皮毛就可以吃透接口自动化测试了。现在回头想来，当时是有一些幼稚的。当然那段时间也没有白费，在培训新人的过程中，对api自动化框架的底层有了一个全新的认识，这才有之后的包括说改造框架支持微信推送、重点API推送、以及支持虚拟组织等。后来团队（主要是蒋指导）对ImWeb服务端的测试有了更高的要求，需要的不仅是是是接口层面的测试，我们需要对标BAT，对开发代码进行CR，包括当时也开发了测试沙龙去认识优秀的腾讯测试人员是怎么进行CR的。当时对我来说，真的觉得这个挑战有一点点大。因为我（有点自知之明的哈哈。）其实对Java的知识仅仅是停留在大学阶段而已，并没有更深层次的了解。对自己是否能够胜任，抱有比较大的疑问。期间部门成员发生了比较大的调整，青椒小哥离职了，转Java软件开发；还有位天天和我聊人生的老大哥被优化离职了。这两件事对我的影响比较大，一是，让我认识到了，其实作为测试人员，不要贬低自己，看低自己的能力，我们也是可以懂代码，用代码的，而不仅仅是写脚本，后期还可以转开发。还有就是老大哥的离职，让我对部门现状有了比较大的认识，这个竞争残酷的社会，是不进则退，优胜劣汰。那段以后，我开始反思。确实，无论是自己的代码能力，或者说当时的整个服务端测试水平，API测试已经进入了瓶颈。因为基于接口的测试，其实并不是服务端测试的最终目的，对于整个服务端的业务来说，我们所触及到的也仅仅是表现层（MVC模式），后面还有巨大的测试空间等待我们去摸索，研究。那以后，我就开始重温美好的Java（囧），花时间借书籍（大学期间把所有的技术类书籍全卖了 0.2元/一斤 囧），上Google，找开发。这段时间，经常晚上搬一张椅子，拿一本笔记本，坐在开发隔壁（提前预约开发，指望开发上晚班，强哥也给力，千年睡不够上晚班），指着代码问问题，像回到了当初自学Python的时候（身为外包为了留下来得有一技之长啊，用午休时间自学Python，阅读接口自动化框架，记了满满一本笔记本，考各种在线认证）。久而久之，对spring框架，对MVC，对MAVEN都有一个比较大的斩获。那时候经常开着开发的代码工程，阅读开发的代码，熟悉每个开发的编码风格。那段时间，是真正提升代码能力的时间。这里真的要十分感谢老宋头给我的大力帮助。可以说没有他就没有我今日。到后来，可以通过阅读代码，提出一些代码上的BUG，到这一阶段，心里的喜悦真的是无法描述的。（心说我可能也有机会年终奖100个月了，纯YY）。自从可以进入初级CR以后，许多的测试技术手段也在源源不尽的向我走来。包括可以对模块进行unittest啊，对数据库的读写验证，一些关键依赖进行依赖测试（部门级专项），本地启动服务进行特性测试啊等等，不一而足。通过mock的手段，大大丰富以及拓展了整个服务端测试所能覆盖的范围。进入CR就像打开了新的一扇门一样，让我对测试有了极大的热情。之后我对整个服务端的业务把控更加得心应手，对业务细节的梳理更加清晰深刻。后来由于02有了一个机型适配后台的想法，咬咬牙把服务端接口以及数据库设计给接过来做了。设计，开发，上线，成功的完成了她所提出的需求。那以后，我切身意识到，真的，其实大家都是人，我也是可以具备开发能力的（低水平开发，高水准装逼）。当然还是那句话，我还是对自己有比较大的认识。但这点小技术已经够我在服务端如鱼得水了。无论如何，IM的服务端测试在我这里走向了更深，更全，更有技术性。期间无论是我自己本身的成长，还是整个团队的成长都是喜人的。
说完技术能力的提升，当然还有业务能力的提升。业务能力相对于代码能力，可能表述和理解起来更加虚一点。说白了业务能力是需要长时间对业务的理解，把控细节，是功能测试的核心（一直认为技术是为业务服务，没毛病）。从进入IM以来，IM的服务端业务沉淀，从无到有，从粗到细。都是一步步积累起来的，当然前期是很痛苦。因为之前的服务端是没有直接进行测试的，相对于IM目前七十多个子服务来说，我们所掌握的真的是凤毛菱角。得益于现有的流程，我是从BUG中成长的（所以收到外部BUG不一定是坏事，当然如果不算绩效的话，蒋总不开骂，包总不扣分，郭总笑嘻嘻，那是好事）。主测需要对外部BUG进行分析，让我有了更快去了解业务的一个途径。写到这里，顺便也提一下BUG分析。BUG分析是一项作为QA人员必备的技能。它的意义在于，不仅仅我们能从BUG中发现我们漏测的缺陷，提供解决方案，评估解决方案，还在于在分析BUG的过程中，一来可以提升我们对底层具体业务实现细节的了解，加深对业务的掌握程度；二来也是对作为QA的我们为后续的BUG预防，编写高覆盖度的用例，提升产品质量的一个宝贵依据。能够对缺陷提前预警制定方案是身为QA人员的职责，也是身为QA（QUALITY ASSURANCE）的意义。在此期间，像IM代理，群组，公众号等这些服务都是通过这个途径去认识的。然后编写成相关的功能机制文档沉淀下来。后来，一次偶然的机会，IM服务端开发有一个离职，从他手上也拿到许多服务端的设计文档以及开发文档。就开始看，吸收他们的文档内容，形成自己的认识。还有一种业务外的提升，如数据迁移测试。这些是和业务剥离的，在意的点更偏向于数据的精细化处理。这些是需要从老员工以及有经验的前辈那里去请请教的。我感受深刻，回想刚开始做数据迁移的时候，我其实是很懵逼的，起码的概念都没有。哪些点该注意，哪些点能避免的说白了就是未知。那就学啊，找02要了她做数据迁移的迁移计划，借鉴里面的一些验证点，数据库不同的情况下，该关注哪些问题，数据迁移的整体策略该怎样，然后自己根据实际的情况，写一份初稿，定方案，写验证脚本，然后找蒋指导进行方案及测试策略评审。这样的数据迁移，IM期间做了有好几次，久而久之，从无知到自信，就是这么过来的。到现在，再大的数据迁移（imcore 2亿多数据+数据清理，完美完成数据迁移，0BUG），我也有信心能够完美完成。现在，在IM交接之际，服务端整理出来的交接文档总计已经有700M了。对后续的团队有很大的帮助，至少不用再像我这样了，从零开始。业务能力的提升，最直接的效果就是。1.对后续服务端改动的判断更为准确，如对风险及性能的评估； 2.能够快速处理BUG，定位BUG，推动快速解决BUG； 3.快速理解开发的设计模式，对后续新的服务设计进行比对参考，提供更优方案。
总的来说，无论是业务还是代码能力的提升是依赖的是测试工作的流程化，文档化，对缺陷的预警提前化，学习利用好周围的资源，清晰的工作/自身的认识，和良好的团队氛围（方向）。特别要说一下，以前说“学如逆水行舟，不进则退”，在工作上，在社会上，这句话同样也有相同的警示作用。感谢蒋指导正确的方向引导，感谢所有IM服务端开发的技术支持。此刻，在即将离开IM服务端之际，回头望过去一年来的光景，我可以由衷的对自己说，谢谢你在这一年中没有放弃，不停的汲取知识，锻炼自己，才有我的今天。
2.测试大观
测试大观，更确切点描述，应该说是对整个业务测试的大局观。身为IM服务端主测，所处在的团队中的角色是十分重要的，当然这是后面才认识到的。在IM服务端测试的初期，我的认知其实是非常局限的。当时考虑的更多的是单个服务上的接口测试，认为把单个测试做完，就可以尽善尽美了。殊不知由于IM组件的特性，许多组件间的关系是互相影响、关联的。这里有个非常典型的案例。当时是IM-Tools(业务组件)下的agent代理服务上了一个新的版本--“代理支持消息重试”，意思就是在整一条投递链路中，只要有一个环节出了异常，代理就会进行重试，消息重新入队。程序在投递线程数上没有进行调整，沿用了旧版本的20个线程，这样做的直接结果导致了对MQ队列的消费能力不足，当代理收到大量的消息投递，并有大量消息重试时，将有大量的消息堵在MQ队列中，导致无法及时消费，消息延迟严重，用户客户端无法及时收到消息。出现这个问题以后，当时的决定是将20个线程开到500个（因为堆积量太大，消息延迟严重 >30min）。而由于我未联系上下游关系，这草率的决定直接冲击了IM-CORE的分发服务的MQ了，导致了新的堆积。所有的消息收发都收到了影响，全部客户端消息发送失败。这个案例令人影响深刻，对我造成了极大的影响。坏的一方面是，我被蒋指导臭骂了一顿（囧）；好的一方面是，从那时候开始，我开始有意提示自己的测试大局观，尝试去理清整个服务端端的架构部署，依赖，关联，去读开发的时序图，去把整个IM的服务端在脑子里搭建起来，形成一张网。了解开发设计以BUG修复的时候，尝试着去从整体的角度考虑方案的可行性以及正确性。测试的过程中考虑内部和外部依赖的影响。现如今，对于整个IM服务端的测试大局观，比之之前，绝对是飞跃一般的提升。对整个IM服务端的认识也上了一层高度。感觉现在做测试，更加得心应手，应付自如了。至少我们可以评估完开发的设计以后，拒绝版本提测(代理UC离线包)，站在质量的角度和开发说no。所以我说，作为IM服务端主测，是需要有整个服务端的大局观的，整个那么多的服务，要合理的评估特性的影响，提供相应的解决规避方案，提出一些可能潜在的风险，是做好服务端测试需要具备的核心能力。我在后面才认识到这一点，不夸张的说，掌握了业务后大局观成熟的服务端主测，是团队中的面对开发决策，面对整个新特性测试的先驱。只有服务端测试的够全面，才能为客户端的成功打下坚实的基础。当然，现在团队的要求会更加紧迫，现在的测试大局观已经不紧紧是服务端之间的串联了。还包括和客户端之间的交互，这个也是后续努力的方向。
3.对测试的把握
其实对测试的把握，来源于对业务的认知。测试是无法穷尽的，和用例一样，无法做到100%的全覆盖度。尤其对于复杂业务的服务来说，对业务的精准测试是提升测试效率的有效方法。这里必须要夸赞一下IM团队的测试流程化规范。在测试前期，我们会根据需求案以及通过获取开发的设计时序或者理念，通过CR的形式来提升对业务的掌控，并将相应的验证点、测试点及初步的风险记录汇总后召开测试前的测试方案讨论会。会议上，所有人群策群力，取长补短。之后会在主测方产出测试方案最终版，大家根据最终版来编写测试用例，采用相应的测试策略（毕竟不是科普文章，如果我有空，也会整理一下），完成测试。对测试的把握，可能更多的体现在新旧版本的升级，以及BUG修复测试。通过查看git，可以快速的给出开发的修改范围，主测在业务上可以快速评估出对实际业务的影响访问，从而避免了重复而单调无聊的测试。可以花大的时间成本在新增/改动的模块上进行详细的测试。当然这些都是不是一朝一夕的成果。精准测试离不开对CR能力的要求，对大局观的把控，对业务的熟识。相较于以往普通的测试来说，精准测试是一个良好的测试工作改进的提高的方向。将繁重的业务测试，控制在理想合理的范围内。不可否认的是，如此高的要求，我目前还不能完全做到。但将会是我为之努力的方向。说来其实也挺遗憾的，我才刚入门这一阶段，就面临的转换项目的未知，失去了再进一步的机会。只能是期待将来的项目也会有机会继续实现精准测试。对于测试的把握，私以为评审是流程，CR 是手段，测试是精准的，这是他的三大要素，缺一不可。
4.对未来测试的想法
为什么我们要沉淀？简单来说就是为了将过去我们所掌握的，所提出的，或者所讨论的大家认可的一些方案，思路，知识，流程等内容，作为可持续发展的资源保留下来。无论是纸质的也好，或者是电子版的，或者是脑路上的。作为自身的储备，在后续的工作中能够原原本本的运用。我认为，测试的工作是互通的，不在乎是IM还是VR，业务永远是核心，做好对业务的掌握是关键的一步，对服务的架构了解也是不可或缺的，同时，优秀的测试流程设计和方向把控也是不可或缺的，在有能力有条件的基础上可以试试对测试的精准测试。这些储备在合适的时候都会运用的上。我所能做的就是做好自己的本职工作，然后去考虑一些优化，一些技术攻关。运用相关能力提升整个团队的测试能力，质量保障能力。
尾声
此去与IM恐再无瓜葛，只愿IM项目越做越红火。BUG越来越少，愿所有的IM开发及测试成员工作顺利，身体安康！
2017.11.10
