前言

移动互联网测试大会结束了。在某些方面，我想我的感悟在社区里是最深的了。为什么呢？因为我是社区的一个异类 -- 我不是移动互联网的人，甚至我已经不在互联网这个行业里了。好多的技术和策略，如自动遍历，灰度发布，监控，都不能在我们的产品中玩起来，看着移动圈的技术越来越成熟，而我抛弃了这些现在还在当前的领域里摸着石头过河。我心里是感慨万千的，说没有质疑当初选择的想法是骗人的。有些时候我一直在问自己，当初离开互联网行业来到这里，真的是对的么？当然了那句话怎么说的来着。自己的选择就算跪着也要走下去。所以每次问完自己后我总是又告诉自己，自己的选择不会错的。

说说我的圈子吧

有的小伙伴们会问我，难道你选择的行业才刚起步么？没错，我在这个目前还很小众但我坚信未来会火的行业中 --- 人工智能。咳咳，听着这么高大上，我说大白话其实原理就是机器学习。在大数据下利用机器学习算法建模并预测未来的这么个东西。之前一直对外宣称是大数据分析。因为跟客户说人工智能人家根本听不懂你们公司到底干嘛的。后来阿尔法狗火了，我们终于有个成功的例子跟人解释我们到底是干嘛的了。因为我们的产品跟阿尔法狗的原理是一样的（很多算法算的都是权重）。要说这东西现在有多小众，国内专门做这种机器学习平台产品的貌似就我们公司一家，BAT 和一些公司有自己的机器学习系统，但是做到我们公司这种平台化肯定是没有的。所以国内连个像样的竞争对手都几乎找不到。入这一行的门槛也比较高 (必须要有牛逼的数据科学家)，所以这个行业的 QA 圈子，小，灰常的小。总共就这么三瓜俩枣的，全都是在摸着石头过河。

这一行的测试

那这行的测试工作是什么样的呢？我说一下我感觉的几个难点吧。

1. 我看不懂那些复杂的机器学习算法，这些算法光解释就好几页。我们老大曾说过科学家团队那边也需要 QA，我说我爱莫能助。水平有限，我真看不懂他们开发的那些东西，尤其是那些算法，怎么测试啊。我说我们很难找到能看懂那些算法的 QA，能看懂那些算法的，估计也不会来做 QA
2. 产品中的任务几乎都是异步执行，且执行时间长。自动化比较困难
3. 任务执行成功可以验证，但是执行结果难以验证。举个例子，执行一个特征工程，结果是在 hdfs 上的一个文件。不暴露在 UI 上给用户看。用户只能看到执行成功的标示。想要验证结果是不是正确的。需要执行从 dataload 一连串的任务最后建模。而且建模结果的正确与否也是科学家团队自己写的验证程序验证的。这种验证结果困难，任务之间相互依赖性过强的场景，对自动化和分层测试都是个挑战。
4. 因为产品是给建模工程师用的。所以产品的使用难度本来就高。在 UI 上写 pyspark 脚本和 spark sql 都是常态，以后还要加 R 语言脚本。为啥子要在 UI 上写脚本呢？还是用 python spark？ 木有办法啦~~ 不是所有数据处理算法都是能模板化的，有时候就得写脚本做数据拼接，数据清理，特征工程啥的。而且用户群体 -- 建模工程师几乎都是 python 和 R 语言出身。所以 QA 要懂很多东西，即便是 UI 上做手动测试。起码也要会写 spark sql 和 python spark。想往深了测，就要熟悉 hadoop 生态圈的这些东西了。

我现在怎么做的

1. 这一行招到合适的 QA 比较难，比招开发都难。所以 QA 不足，发动产品和开发测试是必须的，也是没办法的。好在领导和开发的同学们都理解这些，开发人员慢慢的都在写单元测试。我在 Jenkins 上配置了 job，push 和 merge 都会触发自动打包运行单元测试，测试成功就打包部署到开发环境中。
2. CI：以 Jenkins 和 docker 为工具自动化部署环境并触发自动化测试。分别针对 master，develop 和 release 分支分别持续集成。配合 jacoco，和 gitlab，github 插件以及 log 等机制做 bug 定位。
3. 对于难以自动化的部分。暂时手动测试，对业务模型进行分析并用 xmind 画出业务模型图。手动测试人员会在开发提测后开始测试。
4. 测试前置与分层测试。前端以 RAP 做为 mock server 进行测试。API 端以专门的测试框架进行测试。 spark 相关的模块，在整体联调结束前只能以命令行的模式将任务提交到集群上测试。

目前跟测试相关的，我也就做了这些。来公司 3 个多月了。进度挺慢的。

结尾

就想一开始说的，移动互联网发展迅速，各种测试技术层出不穷。而我这里一穷二白，用的仍然是老一套。一直希望在 hadoop 圈子里也能有一套测试体系和测试技术。但是自学了一段时间 spark，yarn。现在除了调用 yarn 的 API 之外，我暂时想不到别的辅助测试的方法了。当然我学的还比较浅，没发现好的测试方式。还是慢慢摸索吧。