搜狗质量部测试总结之述职杂谈

airong · 2016年11月26日 · 最后由 airong 回复于 2017年01月18日 · 4182 次阅读

本帖已被设为精华帖！

前言：

最近一段时间一直在忙着平台开发的一些事情，一直都没有时间梳理和总结这过程中的点滴。下个月要准备述职报告，所以就借着这个机会把测试过程中的一些感受记下来，以飨各位看官。本篇是杂谈，所以不谈具体技术，只谈风月。。。

一、论工具之稳定性压倒一切

作为一名测试开发工程师，测试工具应该是非常熟悉了，测试工具是测试过程中的好帮手。好的测试工具对于测试人员效率提升以及减少漏测率都有非常大的帮助。测试工具的来源也有很多，有的工具是较为成熟可以直接拿来用的，有的是基于一些开源的项目然后根据自我需求二次开发的，还有一些是对于某些需求特殊定制的等等，那么对于测试工具什么最重要呢？

从标题可以看出我的结论是，稳定性是一个测试工具最核心的需求。当然这并不是说测试工具的执行效率，测试工具的可扩展性以及可维护性不重要，只是相对于这些特征，稳定性才是一个工具必须要保证的特质。

从半年前的入职到现在，搜狗 ADTQ 测试组给我留下较深印象之一便是持续集成做的非常出色。因为我所在 PC 组，所以就以 PC 组举例。现在 PC 组对于新增的提测单，除了人工的验证新增功能以及样式展示外，其他的全部交给自动化来执行，包括所有 case 的分布式执行测试、新旧版本的压力测试、新旧版本的对比测试等等。其中令我吃惊的是这些部署在 jenkins 上的任务，大多是在 2014 年就已经完成开发，从 2014 年到现在一直都在稳定的运行，除了进行必要的维护以及 case 更新之外，这些工具都表现的非常出色。

这些工具大部分是东哥（暂且这么叫吧^{^{）开发的，主要通过 shell 脚本来实现，我和东哥也没见过我入职时东哥已经离职了，但这也不妨碍其所做的工具对我们目前工作的帮助。以 case 的分布式测试为例，其实现分布式也并非用了非常高深的技术，主要是通过 jenkins 的 api 以及 shell 来完成，就这个看似简单其实并不简单的工具支撑着我们每次上线前的 500 多个 case 的回归，帮助我们减少漏测的情况。只要 case 的分布式执行出现问题，比如突然失败几十个，有可能是功能的漏测，也有可能是合并后的代码有误。}}

这个分布式 case 的执行工具之所以可以用的现在，其本身程序的稳定性占有很大的比例，如果一个工具每次的运行都不稳定，或者运行的时候时不时的报个错误，出现个 exception，你还会信赖它？还会用它吗？

我所希望的工具就是在我需要它的时候，它能够按时完成我交给它的任务，别给我出乱子，这就足够了。我最讨厌的测试工具就是我一边在使用着这个工具，一边忍受其所报的各种错误提示，对于出现的错误我还要调试半天究竟是什么地方出错了。就是这样一件非常简单的要求，又有多少工具能够很好的满足呢，所以我才要特别强调工具稳定性的重要性，我希望即使我以后离开公司，我的工具也可以在仅有必要维护的情况下能够很好的工作。

最近一段时间做了两个内部使用的平台，其中一个就是开发了新的分布式测试系统，改进了原先分布式测试系统的一些缺点。在试运行阶段，修改了各种 bug，现在已经上线并取代原有的分布式测试工具。在开发新的分布式测试系统时，我就感觉到要做好一个工具的稳定性真的非常不容易，需要考虑各种可能的情况，比如一些特殊的输入，执行过程中可能出现的异常，还有 case 执行过程中的一些特殊的依赖等等。

希望新的分布式测试平台能够发扬老一辈分布式测试系统的优点，将稳定性的核心特质保持下去。这里感谢下东哥，在设计新的测试系统时借鉴了很多老平台的优点。

其实当设计平台将稳定性考虑在内时，你就会考虑更多的东西，比如你的系统需要依赖机子 A 上的某个文件，如果这种依赖关系是硬编码在代码中，那么极有可能出现 A 机子文件被删除导致获取失败的情况。这种情况下如果是你自己在维护可能还好，如果你已经离职，新入职的员工如何知道你所依赖的这个文件是什么内容，这种依赖关系是否是必须，这些新员工都不清楚。

如果这种依赖关系是可配置的，不管是通过 xml 还是 json 或者 web 界面，并对这种依赖关系进行详细标注，甚至说明所依赖文件的生成方法，那么这种系统的稳定性以及可维护性就要好很多，甚至不需要去读测试工具的代码就能搞定所出现的问题。关于稳定性还有很多的要求，由于我自己也处在学习阶段，所以就先谈到着吧

二、论旧工具与新工具的前世今生

旧工具可以理解为早些时候开发的工具，这些旧的工具有些可能还在使用，有些可能因为年久失修已经废弃了。当需要这些测试工具所提供的功能时，是继续使用这些即使有些缺点但是还可以使用的旧工具，还是花费大量时间精力去开发新的工具，我相信很多测试同学都有过这种选择，在综合权衡下，做出自己的选择。

我知道肯定也有一些同学与我的想法一致，旧的工具用着不顺，新的工具开发成本又太高，那么就综合两者，以旧工具为蓝本添加新的功能修复原有工具的缺点。当然这三种选择并没有孰优孰劣，能根据具体的测试需求综合权衡，做出正确的选择就好。比如原有的工具实在是太难用，而这个工具开发有比较简单，那么可以考虑重新开发一套，具体情况具体论，切勿盲目追从。

本节所谈论的主要是第三种情况，对现有旧工具进行改造，要不怎么说是前世今生呢，哈哈。还是拿我自己举例吧，现在组内的一些工具，比如性能对比工具，其实现起来比较复杂，首先便是需要搭建一套测试环境，然后再进行对比分析，现有旧的工具也还可以使用，像上一节所谈的，稳定性很好，但就是有些缺点比如生成的报告不直观、调用入口单一（大多数情况通过 jenkins 平台直接调用）、出错排查不方便等。

如果综合权衡考虑这几方面的因素，会发现改进原有旧工具的缺点，并添加所需要的功能是效率最高的。由于现在 ADTQ 组有一个统一的测试平台，整合了测试组常用的工具，所以考虑是否能够将原有的 jenkins 任务整合进现有的平台当中，使得调用更加方便，结果展示更加人性化，错误排查容易呢？通过查询资料以及对旧平台代码的通读，发现改造是可行的，是可以实现的。

由于现阶段还没有进行改进开发，所以就大致说一下我自己改进的思路吧：

关于任务的执行、查询、终止等操作全部通过 python 版本的 jenkins api 来完成；
修改原有的 jenkins 任务脚本，添加结果收集模块，将收集的结果写入到数据库中，mysql 或者 Mongodb 都可以；
重新开发前端页面，主界面主要有任务触发、结果查看等功能。

其实这个思路也并不复杂，实现起来的成本也不是很大，主要的工作在于前端页面设计以及和数据库的交互逻辑，这样的改进方法比起重新开发新的工具要省事省力很多。当然也有其他的方法，比如组内的宋大神（非常 NB）就利用异步框架 Celery 加 paramiko 来实现对脚本的调用，以代替 jenkins 的工作。改造的方法多种多样，可爱的同学发挥你的聪明才智吧~

旧工具与新工具并非是势同水火的关系，如果能让旧的工具进一步贡献自己的价值那么何乐而不为呢。可能有的同学会问，既然比较推崇对旧工具进行改造，那么你为何又重新开发新的分布式测试平台呢？

其实在本章节我有说过，做出某项选择必然是要经过充分的权衡考虑的，我这里解释一下，旧的平台主要有几个明显的缺点比较难以克服所以才考虑开发新的平台，其一是执行的粒度无法控制，其二是分布式节点部署非常繁琐极易出错。这两点我开发新平台的主要因素，现有的平台在节点部署方面做的非常出色，通过 ansible 可实现 1 分钟内将分布式节点由 3 个扩展到 N（具体多少看 ansible 的性能）个，而旧的平台要实现这样的改进就非常困难，其成本不亚于开发新的平台，所以才考虑开发新的平台

前段时间开发的广告预览平台也是放弃了旧的平台，开发新的平台。之所以做出这样的选择，并非是对旧的平台改造困难，恰恰相反，由于预览平台的技术含量较低，并且有现成的 api 接口可供调用来完成图片获取，开发的成本较低，同时为了界面更加的友好所以才重新开发。举了这些例子就是想说明，究竟采取那一种方法是需要根据具体情况具体分析的，不能因为某些炫酷的功能而盲目开发新平台，同时也不能因为开发新平台或者改进旧平台的成本太大就放弃努力，得过且过。其实大家都知道我说的是什么意思，这里不再赘述了

三、脚踏实地、仰望星空

温家宝总理说过这样的话："一个民族有一些关注天空的人，他们才有希望；一个民族只是关心脚下的事情，那是没有未来的"。温家宝总理说这句话时，想表达的是一个国家即需要踏实肯干的人才，也需要有卓越远见，考虑长远的人才。

这句话放在部门内也同样行的通。在当今的社会我们既要做到踏实肯干，同样也需要能跳出当前着眼长远，不要故步自封。如果只是抱着旧的工具方法、旧的流程规章，虽然短期之内并没有大的坏处，但是长久来看，落后是必然的。所以如果有新的想法、新的设计构想、新的技术就要大胆的尝试，虽然不能保证每次尝试都有好的结果，但是如果连努力尝试的想法都没有，一个部门想保持长久的活力也是不可能的。

还是举个例子吧，现在部门内的无线端广告预览只有模拟版本，也就是分辨率可以确定，通过 phantomjs 来截图。其实都知道如果能实现真机的截图就最好了，考虑很多方面以及 testerhome 上分享的文章，我们觉得使用 stf 或许可以完成这样的功能，虽然最后的结果不一定能成，但是尝试又不收费，再说万一要是成了呢。现阶段各种新的技术、新的方法层出不穷，如果能充分利用现有的新技术、新方法，或许可以做到事半功倍。

四、论错误排查

之所以把错误排查单独列出来，是因为我觉得错误排查的能力真的非常非常重要。不管是你自己的程序还是测试工具或者测试环境甚至开发的程序，如果出现了问题，应该知道如何去排查。

现在有些测试同学，都没有自己的测试环境，测试和开发共有一套环境，难道测试的地位真的这么低，都不能有一套独立的测试环境。其实有些时候并非是因为测试地位低，而是测试自己不想去维护这套环境，习惯了只要环境出问题就喊开发来解决，并且认为测试的环境理应当由开发来维护，真不知道为何有这样的想法。如果连维护一套测试环境的能力都没有，还谈什么自动化测试。

我始终相信每个错误的产生必然有其产生的原因。如果一个错误出现了，那么在程序以及资源不发生变化的情况下，其重复出现是必然的。之前出现错误会感到困惑和无奈，而现在则慢慢学会了抽丝剥茧，探索错误产生的根本原因，其实错误排查的过程也充满了乐趣。当然并非每次都是这样，我自己就被一个错误折磨了差不多一个星期，其实差不多都快到崩溃的边缘的，所以耐心也很重要。

举个例子吧，在新的分布式测试系统的实现过程中，就出现了这样一个问题，在 docker 节点中通过 nosetests 来执行 case 时，有一定的概率 server 主程序会被杀死，重点就是在这一定概率上，因为对于同一个 case 有时候 server 运行是正常的，有些时候则直接被 kill 掉。我反复将相关的 shell 以及 python 脚本通读好多遍，都觉得不应该出现这样的问题。就在我差不多快崩溃的时候，才发现原来 node 节点中部署了一个 case 收集程序，这个程序在收集 case 时会杀掉当前的 server 程序，由于这是一个 crontab 任务，所以这才导致了 server 被杀死的概率性。当时找到这个错误的原因时，真的蓝瘦香菇了。。。

再说一个例子吧，通过 docker 来部署 stf 服务的时候，所有都部署完毕，但是 stf 主程序访问就出现错误，但是 stf local 程序就可以好好的运行。后来也是经过详细的排查才发现由于 stf 容器在 vmware 虚拟机中运行，而其中的 ubuntu 虚拟机是采用 NAT 的方式，这导致了 docker0 在此网络模式下无法与 host 进行通信，所以导致无法访问。

举得两个例子是我自己错误排查过程中遇到的两个印象较深的错误，但是好在都找到了原因，其实在错误排查的过程中，你对某程序某方法必要要有很深的了解，要不你怎么排查呢？这样反过来也加深了对某些知识的理解，既解决了问题又涨了知识，这或许是对错误排查过程中所遇到困难的补偿吧。测试同学不要一有问题就找开发了，锻炼一下自己的排错能力吧。。。