随着新版本的上线，这个阶段的测试工作暂时告一段落，闲暇之余，不禁对测试团队的工作方式产生了一些想法，先写下来，当作是一次总结吧。
IT从业者，不论是运营人员、需求分析还是程序员，都应该对测试不陌生吧。测试工作，尤其是黑盒测试，在他们眼中，不外乎点点鼠标，操作操作界面，是一项挺没意思的工作，做测试的都挺无聊的(不无聊，谁没事净干点鼠标的活啊)，跟开发不在一个层级上。怀着对开发的敬畏，对测试的蔑视，对测试本质的理解，也是渐行渐远。
测试就是点鼠标。
第一次听到这句话，我和我的小伙伴们都惊呆了，心脏猛跳了几下，血液循环也加快了不少。可笑的是，当时的我根本不知该如何反驳，对于这样的冷嘲热讽，只能无言已对。那段时间，所谓的“猴子测试”也被大家熟知，想一想平时的工作，嘿，还真像只猴子。当然，像也只是工作方式上与猴子的行为接近，我本人还是一个正常人类的，若不然，猩猩都要称霸世界啦。
如今，回过头再看这句话，是没有丝毫道理的。跟吃饭就是张嘴，走路就是迈腿一样，废话而已。单单说的是必然会经历的动作，忽略了深层次的思想活动。测试技术经过多年的发展，已经形成了一套非常完善的方法体系。测试计划、测试方案和测试用例，成为了测试人员的三大法宝。那敢问，做好了这些，就可以高枕无忧，一劳永逸了吗？答案，是否定的。
我一直认为，测试的精髓在于测试过程中不时闪现的灵感，对测试用例的扩展与改编，就像是拍电影是演员的现场发挥,临时增加的剧情，往往会取得出人意料的效果。有人会问，测试用例难道就不重要了吗？要知道好的用例可以发现所有的BUG。先不论测试用例重不重要，我想，世界上没有谁敢说他的测试用例可以发现所有的BUG，也没有哪一款软件产品敢说完全没有BUG，微软不也是经常通过补丁修复BUG吗。
当然，这不是否认测试用例的重要性，我本人也一直在认真的设计测试用例。只是，我设计测试用例的时候，只写一个业务流程，提供一个大体的方向。要知道，在现今的大环境下，开发周期变短，很多项目都通过压缩测试时间的方式来达到快速开发，往往一个版本留给测试的时间只有一周不到，要在这么短的时间里，执行完成百分之百覆盖的用例，我想，除了“少睡精英”，也不会有其他人了吧。如果用例只是提供测试的方向，例如业务流程这样，那就可以从基础的流程入手，根据自己的感觉(测试人员的感觉有时比专业更重要)，逐渐覆盖可能产生BUG的模块。这样，在实际的测试过程中，会不断的有灵感闪现，往往会找到用例中没有考虑到的点，比依葫芦画瓢执行用例要好的多。
灵感这东西是需要状态的，我们必须在一段不受打扰的时间里达到“入定”的状态，接着就需要更长一段免打扰、完整的时间。其实，测试跟开发一样，都是逻辑性要求很高的工作。一次无关紧要的会议，一封不痛不痒的邮件，哪怕是一句善意的问候，都会打断思维，让我们从入定的状态中醒来。而这种一旦从“入定”的状态中脱离，想要再次进入，自然是难上加难。
可以预见的是，在实际的测试过程中，肯定会产生很多的BUG，怎样处理这些BUG，什么时候解决，什么时候发布补丁都是需要经过深思熟虑，考虑到测试团队的工作习惯而制定的。我的建议是对于Block级别，引起系统崩溃，流程不能执行的BUG，应立即解决并迅速发布补丁。其实，这种级别的BUG不应该在系统测试阶段出现，而应该在白盒测试及开发联调阶段发现并解决，这样的BUG会严重影响到测试工作的流畅性和“入定”状态的持久性。对于其他级别的BUG，应实行统一提交和解决，可以规定每天下午1点、5点是提交BUG的时间，这同时也是打补丁的时间(只是参考，具体时间可以根据项目情况而定)，大家也知道打补丁需要重启服务器，如果频繁的发布补丁，会对测试工作造成严重影响。例如，正在测试某一功能突然提示不能连接服务器，特别是那种需要做很多输入的表单类操作，我想，大部分人都想拍桌子骂娘了吧。这样可以保证测试人员有两部分完整的免打扰工作时间，对效率的提升是显而易见的。
当然，测试工作的开展与观念的传播离不开整个团队乃至整个社会的支持，只有大家真正树立起对测试的正确认知，QA这个称呼才能实至名归。
也许，这一天就要到来了吧。