今天在工作中进行了用例review，那本章就这个话题来聊聊吧。
用例review通常分为内部review和外部review，内部就是测试团队内部人员去review，外部是指开发与产品参与review。一般是以会议的形式，或者直接私下抽时间去看用例。以下讨论的是以测试人员的角度去做review。
首先从心态上来说，被review的人不要认为别人这是在找你的茬，或者觉得被提出问题没面子，不愿意接纳别人的意见，其实用例经常被review有利于拓展自己的思路，提高自己的用例设计水平，从而测的更全面。当然，做review的人见到写得不好的地方也不要太生气，如果是比较低级的错误，那就等人家第二次还是没写好的时候再生气吧~
当我做用例review时，首先会快速的阅读一遍需求文档，大概了解这次包含哪些功能，再分功能模块去细看，自己先思考有哪些测试点，会怎么去设计用例的结构，采用何种方法，然后再去找对应的用例。这样不容易被写用例的人引导思路，如果功能比较复杂，不能直接想出有哪些测试点的话，就要借助于思维导图先列出来。
那么用例review时一般关注哪些问题呢？
1、用例写作规范是不是遵守了？一般公司都会有个用例模板，基本的元素不能少填或者填错。错别字？那更是不能出现的，做为测试都写错别字，那别人怎么会相信你的细心程度呢。
2、用例的结构是否合理？正反面的流程不能写在一个用例里，不同模块的功能不能写在一起，一个用例不要太长，15步左右为宜。
3、是否存在冗余步骤？各用例的侧重点是不同的，如果一个功能已经在一个用例里验证过了，在另一个用例就不需要重复验证了。曾经见到过有测试人员测一个页面的反面流程，因为有3个入口可以进入此页面，然后测这个页面的反面流程写了3遍（捂脸）。
4、是否漏测？需求文档上提到的功能那是一定不能少测的。其次要多考虑的是一些异常场景。
5、需求文档的细节，或者逻辑是否都合理？不能把需求文档当做圣旨，在写用例的时候可能会发现需求细节上没有定义清楚的地方，应该都要找出来讨论清楚。曾经遇到过需求文档上的一句话术漏写了一个字，然后测试用例也是照需求写的，然后开发也是照需求做的，最终这个bug就到了线上（捂脸）。测试要清楚的是，不仅仅只有开发做好的功能是可测的，应该从需求文档就开始进入到测试了。
当别人review自己的用例提出一些好的建议，或者发现了一些问题时，应该要积极的去面对，因为帮助自己提高了而感到开心，也要把问题作为自己的一个checklist，下次写用例时看一遍，以防止再出现同样的问题，这样才是真的进步了。
大家有什么补充的都可以给我留言讨论~