如何引导开发人员及项目经理评审测试用例及测试方案

 引言：写这个帖子也是近段时间一些项目的测试经理普片向我提及的一个问题。即：面对几千个测试用例，普通开发人员及项目经理如何评审他们，虽然我们已经构建了这样一个体系活动。但大部分的开发人员仍然不知道如何评审它们，即便是我们自己测试成员也是同样。写这个帖子目的，希望抛砖引玉谈一些我的理解和我们采用的方法。这里要感谢架构师Jack这段时间交流与指导，因为这些方法来自于一些公共的测试技术。

先从测试方案入手：

一般我们常见的问题是哪些呢？

Topic1：测试方案过于复杂，在不了解业务情况下，很难对逐点评审；

Topic2：开发人员评审时无法聚焦焦点，测试用例太多，测试方案也太多；

Topic3：评审方案往往耗费较多的人力与时间，需要太多人参与，且评审效果很不理想；

Topic4：测试方案写作视测试人员经验和能力而定，写作方案时的思路及策略无法找到依据；

Topic5：测试用例的覆盖如何判断？用例命中率只能在执行后期统计及完善；

这些也许是我们通常评审方案是遇到主要问题，看看我们如何来破解他们，应该如何引导开发人员的视角在他们必须关注且能发挥极大作用的地方。

这里，抛出来一个主题：何为开发人员的视角。

何为开发人员视角呢？他们在关注什么？通常意义上来说，是微观的部分。开发人员关注的基于需求的实现方案、模块之间的接口、传输的数据流，判定路径等。

而测试人员的视角呢？他们在关注什么？通常意义上来说，是宏观的部分。测试人员关注的基于需求的业务数据流向、多维交互、质量属性、异常等。<