用例

作者：京东科技 刘刚 用例评审对于品质同学是再相熟不过的一个重要环节，用例评审也是十分无效的保障测试品质的伎俩，但咱们品质同学做了这么屡次的评审，有没有去思考怎么去进一步晋升用例评审的品质，应用例评审更加无效呢，这里呢抛砖引玉，总结一下我集体对用例评审的思考，心愿能给大家带来一些启发。 用例评审的意义对于用例评审，咱们要首先要想分明通过用例评审能够带来哪些价值和收益，而不只是停留在外表和流程上，要继续的去思考和晋升用例评审成果，这样大家专门花工夫进行用例评审能力更有意义，这里我提出四点价值： 共识需要 • 开发、测试、产品碰撞本人了解需要是否正确的过程，进一步排除一致，达成共识。 • 帮忙开发进一步理清需要，补充开发未思考到的场景。 补全场景 • 帮忙测试发现用例中存在的场景欠缺，防止需要脱漏，并补全测试场景。 • 疏导产品进一步思考，补全考虑不周之处。 危险躲避 • 对测试重点、危险点、测试范畴团队共识 附加价值 • 疏导团队品质意识晋升 • 体现测试价值 前置筹备在正式评审前，咱们须要提前做些筹备工作，这样能力无效保障咱们的用例评审成果。 用例评审前的筹备工作有品质 • 如果本次需要较为简单或自信心不强，强烈建议在正式需要评审前进行一轮测试外部评审，应用例达到比拟齐备的条件。 划重点 • 适宜评审会上独特探讨的需要中疑难点和优化倡议，提前在用例中做好标记（留神大部分疑难点应线下提前沟通明确，防止会上过多探讨） • 用例要有逻辑清晰的构造出现，并且提前划分好用例优先级和评审重点。 降老本 • 用例较多时，将用例按前端用例、后端用例做好分类，以便用例评审时可离开review，节省时间。 • 倡议提前一天，将用例提前发给相干人员查阅，并提前收回会邀，预约好工夫。 • 评审前五分钟，提前去会议室筹备好，并将相干用例、需要页面、开发设计页面、原型图关上。 用例评审机会要求为保障用例评审成果最大化，最迟应该在开发提测前进行评审，最佳评审工夫为开发中后期，这时开发对需要已有较为全面了解，程序架构也根本成型，用例评审时开发可给出较多倡议和补充。 用例评审人员要求不同角色的人员到场要求如下： • 前后端开发（必须） • 产品（必须） • 设计（看状况） • 其余（如：量化、经营同学） 评判规范好的用例评审具备哪些特点怎么的用例评审才算好的评审，这里我提出三点，供大家参考： 共识需要 • 共识需要细节，排除纳闷，防止需要了解一致 补全场景 • 业务/测试场景及技术计划思考周全，可能给产品、研发较多无效输出 • 疏导产品和研发思考，促其提出无效倡议和补充 高效评审 • 可能进步用例评审效率和成果 流程标准用例评审流程这里绘制了一下用例评审的流程环节，清晰展现用例评审相干的各个节点和动作，共大家参考。 用例评审补充倡议会前筹备 • 用例设计，构造思路要清晰，表白要精确(尽量采纳开发/规范的表述)，防止有歧义的语句 • 对有歧义的问题，最好是在评审前找对应的开发/产品确认下 会议阶段 • 评审会议时长最好管制在1H，若货色太多，能够分屡次评审 ...