小团队玩不转的测试

早在上一家公司,就为测试问题头疼过,那时候测试全靠人肉,还整出了黑盒白盒测试文档,还要对代码进行打点,还要人工去匹配打点数据是否执行…都是泪,都是泪,都是泪啊!

那个时候团队人数最多时有十二个,项目现在想想也不算大,按道理是可以分出来一部分人来专做测试工作的,只是当时无法说服领导成立测试小组,毕竟自己也没有自动化测试的经验。最后强迫别的部门的同事来帮我们测,除了心不甘请不愿外,测试的结果也不是特别的理想。

换了一家公司,依然是四人小团队,现在我开始琢磨如何自动化测试了。毕竟之前的不愉快精力,再加上我现在的岗位更多是解决团队的开发效率问题,所以必须得正视这个头疼的问题。

痛点

小团队自动化测试的困难到底有哪些?

  • 人手不足
  • 时间不足(和团队大小无关)
  • 经验不足

前两点都归结于资源不足,正常的项目排期满满当当的都是需求文档和功能开发,不过仔细分析了一下团队的工作时间分布,发现其实还是有三分之一左右的时间是留给测试环节的。

按照我们的开发节奏,平均两周一个版本,三分之一相当于3.5天,相当可观的开销。如果这三天半的时间来花在写测试项上,应该也可以拿到一个比较好的结果,至少面对日后的回归测试会有较大的帮助,这里有一个公式:

自动化的收益 = 迭代次数 X 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

至于经验不足,也是一个比较头疼的问题。要知道,写好一个测试本身就不是件容易的事儿,而编写高可测试代码更要求开发人员的能力,这可不是短时间就能获得的技能啊。

测试关注点

  • 哪些代码适合写测试

简而言之,就是那些重要的,复杂的,不易变的逻辑部分适合最适合写测试。

  • 怎么写出好的测试项

    • 覆盖率
      如果没有定好测试覆盖率,就无法评估测试的程度,你也就不能安心的认为跑完测试的代码就一定没有问题,好尴尬啊~

    • 定位问题
      我们的测试项报错后,应该尽可能的辅助开发人员定位问题的位置,而不是笼统的报错。

    • 低耦合
      尽量的保证业务代码的耦合较低,有助于编写和维护测试项。

    • 高性能
      尽可能保证测试的性能,谁都不愿意等待。

  • 怎么维护测试项

这就是个权衡问题了,前期测试项写的越多,一旦代码变更了,需要同步修改的测试项也会很多。上一张经典的测试金字塔图:

图中:

  • UI:端到端测试
  • Service:集成测试
  • Unit:单元测试

该图表达了不同测试类型对应的测试项比重,这是前辈们的经验得出的科学分配法,值得我们遵守。

测试套件

Karma

Karma作为测试套件的执行器(test runner),为我们的测试框架提供测试环境的,它的安装和配置简单的我都想哭了。不过好像它并无法直接进行端到端测试,github上有一个扩展:karma-e2e-dsl是专门做这件事儿的,有兴趣的可以看看。

Atomus

Atomus给自己定位很准确,就是轻量级UI测试套件,重点提到了它可以支持局部界面测试,其实就是利用了jsdom提供的能力来灵活的做到了js+html联调,思路不错,不过github上的关注度和活跃度不算高。

Casperjs

类似Atomus,但是Casperjs更加的强大,它是基于PhantomJS来实现浏览器模拟的,并提供了强大的测试API,该项目的关注度也很高,值得好好看看。

google上可以找到比较多的使用casperjs配合mocha和chai来做端到端测试的资料,这也是目前我比较中意的组合。

chrome上还有一个casperjs的插件:Resurrectio,用来帮助我们通过直接在页面上操作来录制测试脚本,虽然作者好像已经不再维护这个项目,但经测试依然可以满足一些简单的场景。

Mocha + Chai + Sinon

这套黄金搭档在面对单元测试时基本上所向无敌,不过如果是做端到端测试,我们几乎不需要做mock或stub,所以Sinon就可以先放一边。Mocha配合Chai可以提供标准的测试所需功能,是目前最新的测试框架之一。所以之后我在搭建具体测试环境的时候也会优先选择这俩工具。

PhantomFlow

如果你想要一份屌炸天的测试报告,那PhantomFlow应该是一个开箱即用的工具了,它基于我们上面提到的一些工具,并提供了各种漂亮的展示模版,很适合装逼用。

Page-Monitor

上面说的都是功能测试为主,最后我们来说一下界面测试,国人大牛提供了Page-Monitor工具,可以帮我们对比界面的差异,使用方法非常简单,具体可以根据官方步骤来做,目前这不是我的关注点。

总结

这篇文章走马观花的看了一下目前能发现的一些测试套件,科普的成分多一些,没有啥干货。之后我会根据自己选择的相关工具集合把搭建环境和编写测试脚本的步骤和流程写出来,请给予关注哟~

虽然这篇自身没有太多干货,但下面的参考文献提供的文章却非常有料啊,希望大家能看过瘾。

参考文献

Git Hook帮你维护前端代码规范

只要不是一个人在战斗,你都一定会碰到很多工程问题。我们今天来说的,就是代码格式问题。这不是个什么有意思的话题,这个话题讲的就是条条框框,就是枯燥,就是没意思。但是,如果你的团队缺少代码格式规范的话,当你review组员的代码时,你就会感觉在吃屎,没错,不夸张!

我不怀疑团队组员的积极性,因为条条框框本来就不是程序员的调调,而且人类和机器的最大差别就是遵守规范的程度。所以,你不能要求你口头上说代码格式要怎样怎么,所有同事就会立刻写出符合要求的完美代码。

阅读全文

Open-Falcon初探

随着项目的开发一点一点的完成,离初版上线日期已经越来越近了,这样就涉及到各种运维问题,监控的意义就体现出来了。虽然项目最终会部署在云平台,而云平台自身会带监控套件,不过不够灵活,一些想要的指标和报警方式还是需要自己来实现。大概看了几款监控解决方案,对Open-Falcon特别有好感,虽然我不懂GO语言~

阅读全文

传统Web项目代码变更引起的浏览器缓存问题和解决思路

不确定文章的标题描述的是否已经足够明了,至少用类似的描述在gg中并没有定位到相关的文章。讨论这个话题的更多是围绕这前端工程化套件的用法的(例如webpack、grunt、gulp等),而这些工具对单入口页面SPA应用支持度非常的好。但现实往往不尽如意,面对传统的多入口web项目,前端又应该如何解决浏览器缓存旧版本代码的问题呢?

阅读全文

【转】调整虚拟机中Ubuntu Server屏幕分辨率

转自:http://blog.csdn.net/weilanxing/article/details/7664324

VMware中的Ubuntu Server的控制台窗口有点儿小,使用起来不太方便,要调整控制台的窗口大小,需要修改屏幕的分辨率,修改方法如下:

  1. 打开grub文件($vim /etc/default/grub), 修改参数GRUB_CMDLINE_LINUX的值,
    GRUB_CMDLINE_LINUX=”vga=0x317”, 参数值参考下图:

    1
    2
    3
    4
    5
    6
    | 640x480 800x600 1024x768 1280x1024
    ----|--------------------------------------
    256 | 0x301 0x303 0x305 0x307
    32k | 0x310 0x313 0x316 0x319
    64k | 0x311 0x314 0x317 0x31A
    16M | 0x312 0x315 0x318 0x31B
  2. $sudo update-grub

  3. $sudo reboot

Docker for Win

我所在的项目,小伙伴们都在fire in coding,我也不能闲着,我开始为项目的持续交付进行思考和设计。

第一个要解决的问题,就是开发环境,测试环境和线上环境的一致,那不用说,今天最流行的做这个事儿的应该就是docker了吧?!

阅读全文