年前启动的项目，之前一直各种需求文档的评审，之后搁置了一段时间进行其他项目的测试，如今开始各个模块的测试点评审，项目较大，模块较多，仅需求点将近250个。由8个人负责分工完成，几乎每天一个会议对各模块测试点进行评审。这么多测试点如何有效评审呢？
由于用例的复杂性评审较困难，采用测试点全部评审，用例抽样评审的方式较为合理。我们规定格式，测试点大家用思维导图的方式展现，尽量做到一目了然。基本要求三级目录，但由于大家的思维方式不一样，编写的思维导图各有差异，评审时的效果也不同，在此谈谈我的想法
第一：必须做到点线面相结合，要明确本模块的重点，检查点。编写思路可以按入口、GUI、逻辑功能、交互功能、控件、异常展开写。所谓点包括入口、GUI、控件点到即可，如文本框的校验等都套用公共模块用例，大同小异不用详细讲解；所谓线本模块的逻辑功能点要连贯，重点讲述检查点在哪里，如添加，添加过程做了哪些动作，添加的结果跟预期的是否一致；所谓面就是思考的面要广，本模块与其他模块交互的地方是否考虑到，如修改删除功能对其他模块的影响。
另外需要避免的几个缺点
1. 需求点的照抄照搬模式，没有自己的思想
2. 主次不分或主次颠倒，逻辑功能交互功能少，界面点多
3. 需求点不会合并，太分散或重复很多（同一个界面需求点写的很细但测试检查点可以合并，多个小模块测试点都类似的比如BS、CS同一模块，应该合并讲解或只评审一份就可以，另一份只需要评审不同的地方，再如服务器添加只需要评审一个实例就可以）
评审时注意不要照本宣科，因为再坐的其他人未必事先看过你的模块或并不熟悉，最好展示演示界面或交互界面进行分析，带动大家的注意力和思维
另外一个成年人的注意力大概能保持50分钟，评审时间建议不要超过2个小时。中间还可以适当休息一下。评审的过程中大家要积极思考，如负责人可以要求每个人必须有提问或补充
做到以上几点，相信我们的评审效率会高很多
为了提高大家的编写能力，会后应该进行总结，分析哪些是写的好的哪些是需要改进的
测试点的最终目的，别人看着你的测试点基本可以编写所有测试用例
版权声明：本文出自 June6521 的51Testing软件测试博客：http://www.51testing.com/?76747
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
