janne09的专栏

事情的起因是这样的上周三下午要出去打个电话，经过小会议室门口的时候测试负责人叫住我问有事吗？小A做的性能测试出现了点问，要我帮忙分析一下。打完电话后到小会议室与小A、测试负责人一起看小A的性能测试出现了什么问题。小A说她对X项目进行了性能测试，但是结果与现在线上的差距特别大，线上入库是10条/秒，而她测试的结果是3-4条/秒，对于她测试得出来的结果项目的负责人很不认同，认为是她做错了，而她又找

先问一个问题，BUG是怎么出来的。估计会有很多人回答，是测试人员测出来的。如果测试人员连BUG都测试不出来，那还叫啥测试人员了。再继续深入问下去，如果BUG本身就不存在，测试人员能测出来吗？这个时候的答案应该是“不能”吧。换个角度讲，测试人员只是使BUG浮出了水面，使一些人（开发人员、项目经理等）知道了他的存在。继续问，BUG是怎么出来的？或者说BUG是怎么产生的？是什么原因使他深藏在地下？

上次参加培训时，在课堂上有人提出来现在公司测试需求变更太快，测试人员一直疲于应付各种变更，开发人员提交测试的质量太差，正常的流程很难一次跑过，边边角角的问题更多。想做进一步深入测试，但是时间总是不够，自动化测试也只是想想。吴穹老师说，这些问题的主要原因是测试滞后导致的，所谓测试滞后就是说，本来不应该由测试人员来做的事，现在都由测试人员来做了，测试人员在还其他人的债，所以自己本身的事反而没时

测试空间活动：参加活动的人员分成四个小组，每个小组由一名thoughtworks员工领队，小组成员，每人手中拿到一份“需求”，小组成员进行讨论对“需求”进行明确，不明确的地方向领队确认，最后形成一份文档交付给客户。活动时间共计5分钟，包括小组成员意见达成统一，文档书写到白板上。本人不擅长领导别人，所以分成小组后，便无公害的跟在小组成员后面，看手中需求文档，记录不明确的问题，听小组成员讨论，向领

掰着手指数，做测试这份工作已经六年了，年纪也一大把了，和出来抢饭碗的90后拼体力已经拼不起了，所谓”人老奸，马老滑“，拼不起体力，那只能拼巧劲儿了。      巧劲儿也不是那么好拼的，那也得有扎实的基本功才能，什么测试的理论、方法、胆大心细、逆向思维啦什么的，会点语言写点代码、会个工具忽悠忽悠外行。。。。。。        铛、铛、铛、铛。。。巧劲儿大比拼开始       行业知识的深

为什么要有一份活文档？在现实中有太多这样的情形：新介入一个项目，老人会丢过来一堆的文档或者链接地址，并告诉你说，这些是与这个项目相关的一些文档资料，这些资料里有些内容是已经过时了的，项目有些最新的需求还没人补充，先借鉴着看吧，不看文档还好一点，看了文档更晕。产品经理闷着头吭哧吭哧写了半个月的需求说明，然后招集大家开会，在会上打出投影对几十页的需求说明一个字一个字的过，产品经理在上面讲的口吐白沫