演讲式的用例评审，你见过吗？

在测试过程中，测试用例的设计和编写是一个至关重要的过程，用例的覆盖率高低也直接的代表了项目的质量水平，用例的描述，用例覆盖率的结果好坏很大一部分取决于用例评审；用例的评审方式很多，比如交叉评审，上级评审，项目组评审，同行评审；但现在大部分基本很多都是前三种，并且正规的都是走向项目组评审；

项目组的用例评审不仅仅是要确认用例覆盖率，也是要表现测试的对业务理解度，测试的专业性，以及提示产品，需求考虑不周的地方，提醒开发的注意点，整体提高项目的效率以及大家对测试的认可；那现实往往是打脸的，很多用例评审会议，都是人带来了，心不带来了，比如参加者需求没有好好理解，也没有好好看；没有提前发评审资料或者已更新的需求点等；评审会议氛围枯燥，各自看手机；说的都不是参与者想要的；评审方式都是一起看用例方式，激不起大家参与；评审完会议记录也没有记录，修改完善等，久了以后，大家就认为评审效果不大，慢慢可能就没有了这个流程或者变成了个形式；

那基于这个现象，那要解决这些痛点，采用演讲式的用例评审；前期的准备工作基本跟用例评审的准备差别不了多少（常规的用例评审准备，看需求，标准测试点和疑惑点，然后看交互，标注测试点和对存在疑惑点新增/删除，然后统一跟产品，交互确认，确认以后，抛开功能测试，还要哪些内容，准备哪些测试数据），差别的就是你要对所有的需求点和交互，理解得一清二楚，并且脑袋里就有一个模型，类似这些功能开发好了，你已点击操作过一遍，这些也跟用例需求理解差别不大，那演讲评审，就需要主持评审功能的人沟通表达能力要好，并且能提醒相关人，并说重点；演讲用例评审，需要有两个人，一个负责讲，一个根据演讲者说的关键词标记记录存在问题（关键词标记，如这个需求是没有写到的，有确认结果是这样，需求还未跟新，要确认跟踪下，这个代表要记录）；讲，如何讲呢？讲就是方式，不是拿用例，而是直接根据交互图，(ps:不是让大家看交互说明)，直接跟大家讲这个功能组成，页面，布局，数据，如何操作，就是把所有功能带大家操作了一遍了，并且都说说出了注意点，考虑点，疑惑点等，然后讲完某个重要点，停下，问下大家是否考虑不足的地方，或者对疑惑点进行探讨，然后再继续，最后对所有的疑惑点，需要更新的，都有责任人，时间，然后发出会议记录；案例：搜索框的用例评审，交互上就一个搜索框，大家看下这个搜索框，这个搜索框主要用来对用户名称和用户ID进行搜索，并具有模糊匹配功能，作为测试我们考虑对于用户名称搜索，除了简单的考虑到有用户ID，用户名和无用户名，无用户ID的搜索之外，重点在于两个方面，一个特殊用户名如@字符，/等用户是否能搜索到，并查了用户数据库，把一些用户特殊的字符，如XX拿出来进行测试，这些在需求中没有描述@产品你们这方面文档要更新，@开发同学记得这些字符开发的时候要考虑进去；模糊匹配也就是联想，我看了需求的图片是显示五个，但如果输入一个3,联想数据是40多条，这时如何显示，另外模拟匹配有考虑数字中文，英文，特殊字符，全角，半角输入，是否能显示和搜索到，这方面开发要注意下，需求是没有这方面的内容点的；

术语就是我们今天主要讲什么功能，然后按照顺序把功能一一拆分，该功能用于做什么，有哪些功能，对于需求描述很清楚的简单带过，然后细说我们主要测试哪些内容，哪些需要是隐性需求，需要开发关注和产品补充重点重复，哪些存在疑惑，然后把相关联的功能说完，留下时间让大家补充，解惑，再接下去下面的功能用例讲解；

类似这样的讲法，一个是看交互图，比看用例说明，更不会枯燥，一个讲的方式，等于把功能讲了一遍，把产品理了功能，也意识一些是否没有考虑到，也帮开发更深刻的知道了哪些功能没有考虑到，并提示，避免没有设计到，而有了Bug，并且这个方式，有没有了所谓事前发文档让大家提前了解；大家的参与度高，听得也更入神，避免了会议范围的尴尬，有提醒，有讨论，有记录，有归属人，无意中这样团队的范围更融洽，无意中项目效率提高了；

用例评审演讲的方式，难度就在需求理解度和如何通过讲的方式带大家类似实际操作了这个功能一样，并提醒，难度最大的就在这个讲方式，讲的内容，有趣，需要一定的沟通能力，临场能力，并合适的时机提醒和提问题；这个需要大家多练习哦。这种类似是只可意会，不可言传，毕竟是用讲话的艺术来沟通，带大家了解测试；属于隐性知识，无法写得很详细，有疑惑的，大家可以相互探讨；

时代在变迁，IT技术变更迭代快，对于身在这个行业中的一员，也要保持思想，方法，技术的迭代；希望本次的用例演讲的评审方式，会对身在测试行业中同学，有所帮助；我会持续在工作中分享下我工作的方法和心得。