• @seveniruby 看着你这块经历一如自己过往。然后,怎么说来着,混着混着,就没影了。发现自己可能已经不再属于测试那一块,虽然涉及的内容也越来越多,但是对于测试领域这块的关注倒反而不如之前一般专注了。
    专业化程度随着年龄和阅历一点点被蚕食掉。技术人员之殇啊。有时候也迷惘,曾经这么努力的是为了什么?在这个领域里,我还能为别人做点什么呢?

    最近在公司忙于构思基于任务调度的研发任务一体化,就研发质量评估、持续集成、持续发布及自动化测试等相关领域。且不说这块对于互联网创业公司研发团队的意义,在业内也的确有比较成功的案例。有时间的话可以和大牛们交流下想法和思路。

  • web 接口测试总结 at 2016年05月28日

    #1 赞同!!
    目前正在弄 jmeter + jenkins 的自动化测试, 后续会把 selenium 加入到 jenkins 里头去。

  • 对于敏捷中的测试用例管理,有楼上的同志说是可复用性。实际在我们的项目中,除了流程用例复用外,大多数用例可能都还没有精简到可复用的地步,大多数都是采用多层迭代的方法逐步强化和完善。如果要说复用的话,可以考虑将测试工作前置来完成覆盖率来保障质量,比如接口方法测试等一些自动化技术,但是快速开发需要依赖一套相对成熟稳定的测试框架来实现。So,在此大家可以先自问下,目前你所在的团队有这方面的持续投入没有——这块是很关键的。

  • 快进快出的,推崇敏捷直接不要走用例,用脑图。但是弊端也比较明显,如果有 3、5 年经验的话,且长期使用脑图来实现测试执行的话可以。大多数大型团队,不可能使用脑图作为指导团队测试执行,原因在于大型团队中人员的水平、经验、个人体验等有较大的差异,要拟合这些问题需要大量的时间和培训。此外,个人觉得也不利于团队的管理,在测试活动继承等方面有较大的弊端。

    所以,个人建议如下:

    1. 小型团队,1~3 人可以考虑脑图,不写用例直接参与执行;经验值高的测试人员可以快速发现问题并提交大量的 bug;
    2. 中大型团队,脑图只能作为工具,不是唯一的测试用例设计方法,还是需要老老实实写用例清单;首次测试的结果对一个项目来说太重要,直接决定了质量印象。