测试设计不只是测试设计工程师的事，需要团队中每一个成员的共同努力，哪怕是主动地反映遇到的问题，下面介绍一个真实的典型案例。
【案例】软件运行得犹如蜗牛在爬行
一个平常的工作日，将近下班时间了，刚参加完关于内存泄漏测试方案评审会的测试设计工程师赵函，习惯性地每天这个时候进入公司的缺陷跟踪系统，跟踪执行人员提交的Bug。其中一个Bug立刻吸引住了赵函的眼球，Bug描述是这样的：“仪器测量完成后，测量结果显示在界面的过程如蜗牛在爬行，响应缓慢（刷新完毕约1分钟）”。赵函马上找到提交Bug的工程师了解详细情况，并察看这个蜗牛爬行的显示过程到底是怎样一种现象（蜗牛爬行的平均速度是每秒钟0.5厘米，如图3-12所示）。不看不知道，此问题不仅仅发生在测量结果显示的处理上，切换到其他任何一个界面同样异常缓慢，这不是明显影响测试的效率吗？于是马上找相关开发工程师一起分析、定位问题，并要求重发版本给测试。后来开发查明是因为某个开发工程师提交版本时忘了关后台的调试信息打印开关。
此Bug是下午2点钟提交的，也就是说测试执行人员在这样的版本上忍受了近4个小时的测试，竟然没人提出要终止这样的版本测试。问及执行的测试工程师时，回答各执一词：“我不用老是切换界面，没有多大影响！”“我已提了Bug，软件慢我也没办法呀！”“开发已知道了，下版会改的。”
“我们的测试同胞都是逆来顺受的？还是哪个流程环节上的出了问题？”赵函这样想着，找来了开发与测试经理，商讨避免这种问题的对策。据调查，负责版本发布的开发人员在版本发布前是有按流程进行冒烟测试的，但遗憾的是，这是在测试环境上确认的功能，不是在真实环境下的用户场景中确认的。而测试工程师也没有流程来支持，遇到这种情况如何处理？
最后商讨的决策是改进开发与测试版本传递的流程定义，明确具体的细节。
要求负责版本发布的开发人员，在版本正式提交给测试前，必须在真实的用户场景环境下运行软件，确认实现的新功能或更改的正确性，并做确认记录，此记录随同测试传递表，以及软件版本一起提交。
增加测试接收版本的约束：增加版本接收确认环节，时间不超过2小时，如出现严重或致命Bug，影响测试工作的开展，通知测试经理，停止当前测试。
图3-12 蜗牛在爬行
相关链接：
