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

　　先从测试方案入手：

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

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

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

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

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

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

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

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

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

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

　　不同的视角，造了他们对同一个事物不同的评判标准。

　　一个好的评审，应该着重去引导两方的思维，它们存在交集，也存在互斥的部分。而这些灰色地带和未澄清的部分，正是容易出错的部分。

　　分析完这些，我们可以给这个问题抛出一些解决方案。

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

　　解决方案1：测试方案分类编写，首先是基于面向对象分析，选择不同的模板分开描述他们。如：功能测试、性能测试、协议测试、质量属性、安全测试等等。

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

　　解决方案2：测试方案不仅仅是一个文字方案，更重要的是图形化的表达，统一建模。 序列图、状态机、User Story等技术，这样的方案将更佳一读，尽量减少文字描述。

　　解决方案3：测试方案需要按照结构化方式编写，思路方面建议采用脑图，这样在评审时。开发及外部专家更容易聚焦到中心上。结构化的思路还包括抽象为OPP的结构，如对FTP对象分析，应该从哪几个方面入手。基于RBT技术，我们可以构建一种Checklist公共测试框架，来解决这个问题。

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

　　解决方案4：也许敏捷开发模型能很好的解决这个问题？XP方式，似乎能引入到这里，但这样评审必须依靠强大模板或者能力较强的TAE介入。

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

　　解决方案5：利用白盒测试技术来解决这类问题，通过SE将需要评审测试用例。按照断点方式来执行，以此收集对测试用例的覆盖。加入新的路径覆盖，这是一个互相牵引的过程。这个过程将使得研发能考虑到更多异常，而测试将通过此类方式弥补更多测试用例；

　　解决方案6：基于RBT思想，历史问题及故障注入技术将帮助我们完善测试覆盖。项目团队总是犯着同样的错误，同时他们有习惯性的思考模式。

　　解决方案7：基于风险测试技术，让开发评审时聚焦关键的方案部分。并将每个测试对象的测试方案、测试策略罗列出来，使得我们的开发人员和项目不在抓瞎，不在茫然。

　　总结：希望这仅仅是抛砖引玉的一步，欢迎大家来信讨论并扩充我们的方法。