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

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

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

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

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

所以，个人建议如下：

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