什么是测试用例评审?
  测试用例(Test Case):是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。
  评审:指评议和审查;审议。为确定主题事项达到规定目标的适宜性、充分性和有效性所进行的活动。
  测试用例评审如何走向正规
  做事的方式有从上而下和从下往上,我比较擅长的是从下往上。
  第一步:先开始评审
  8月份正式开始做测试用例评审这件事情,刚开始时团队成员都不知道怎么开始做,一来是团队有四个新人,技能和业务上都不够熟,为了让评审能走下去,采取的方式:一写测试用例的人会讲解下需求,二是测试经理会主动说出疑问。其他人成员听和理解较多,这一评审方式好处 让团队成员可以更快地理解需求(在较短的时间内积累不同业务知识),坏处是:团队成员思考的时间少,不能发现问题,去提交自己编写测试用例的技能。
  经过三个月的工作积累,也明显感觉到团队成员对业务有了一定的了解和分析能力,到了测试用例评审改进的时机啦,毕竟测试用例评审终目的是提交大家编写测试用例的水平。
  第二步:优化评审方式
  优化评审前,会先有一个培训会,再次告诉所有成员较为规范的测试用例评审 评审哪些内容,我们当前的评审有哪些缺点,如何来改进(这里有讨论),以下是初步优化内容:
  1)提前二天发出需求和测试用例 ?给参与用例评审的人员
  2)会议前2小时 参与用例评审人员 将问题反馈到 主持人
  3)主持人根据问题排优先级和严重程度(正式评审时 按优先级和严重程度 开始讨论)
  4)评审过程中发现问题能当场修正的当场修正,修正时间超过5分钟的,会后修正。
  5)评估测试用例所需的执行时间和优先级
  6)整理待修正内容和评估修正需要的时间,会后发出
  7)编写测试用例成员需要在预估修正所需时间内 发出 修改的测试用例
  8)主持人检查 测试用例是否修正,没有修正则继续盯着
  9)测试用例的主持人每月换一次,测试部门成员轮流当主持人
  第三步:明规范、定标准
  根据前段时间的测试用例评审经验,将前后台的测试用例进行总结,定义出明确的规范和标准。
  1)简单业务需求 ,团队成员交叉审核即可
  2)核心业务流程+复杂业务,启动团队评审流程