年前启动的项目,之前一直各种需求文档的评审,之后搁置了一段时间进行其他项目的测试,如今开始各个模块的测试点评审,项目较大,模块较多,仅需求点将近250个。由8个人负责分工完成,几乎每天一个会议对各模块测试点进行评审。这么多测试点如何有效评审呢?

  由于用例的复杂性评审较困难,采用测试点全部评审,用例抽样评审的方式较为合理。我们规定格式,测试点大家用思维导图的方式展现,尽量做到一目了然。基本要求三级目录,但由于大家的思维方式不一样,编写的思维导图各有差异,评审时的效果也不同,在此谈谈我的想法

  第一:必须做到点线面相结合,要明确本模块的重点,检查点。编写思路可以按入口、GUI、逻辑功能、交互功能、控件、异常展开写。所谓点包括入口、GUI、控件点到即可,如文本框的校验等都套用公共模块用例,大同小异不用详细讲解;所谓线本模块的逻辑功能点要连贯,重点讲述检查点在哪里,如添加,添加过程做了哪些动作,添加的结果跟预期的是否一致;所谓面就是思考的面要广,本模块与其他模块交互的地方是否考虑到,如修改删除功能对其他模块的影响。

  另外需要避免的几个缺点

  1. 需求点的照抄照搬模式,没有自己的思想

  2. 主次不分或主次颠倒,逻辑功能交互功能少,界面点多

  3. 需求点不会合并,太分散或重复很多(同一个界面需求点写的很细但测试检查点可以合并,多个小模块测试点都类似的比如BS、CS同一模块,应该合并讲解或只评审一份就可以,另一份只需要评审不同的地方,再如服务器添加只需要评审一个实例就可以)

  评审时注意不要照本宣科,因为再坐的其他人未必事先看过你的模块或并不熟悉,最好展示演示界面或交互界面进行分析,带动大家的注意力和思维

  另外一个成年人的注意力大概能保持50分钟,评审时间建议不要超过2个小时。中间还可以适当休息一下。评审的过程中大家要积极思考,如负责人可以要求每个人必须有提问或补充

  做到以上几点,相信我们的评审效率会高很多

  为了提高大家的编写能力,会后应该进行总结,分析哪些是写的好的哪些是需要改进的

  测试点的最终目的,别人看着你的测试点基本可以编写所有测试用例

  转自:http://softtest.chinaitlab.com/bug/955565.html