测试用例，你知多少？

一般项目测试，测试都分为测试计划，测试用例，测试执行，测试报告/总结四个阶段，今天我们就来说下测试用例这个阶段我们要做哪些内容？（请耐心看完，跟写用例一样，要耐得住寂寞） 首先在需求评审会结束以后，除了测试计划编写之外，接下来就要根据录入的需求，确认哪些需求需要编写用例，项目测试负责人初步确认，然后提交主管进行确认，确认以后的需求就是要编写用例的需求量，这个确认方式可以口头沟通确认也可以直接把需求不写用例标注下原因，然后发给主管确认，这样确认效率很快； 有了需求量，接下来就是要用例的设计编写，这个过程可以分为识别测试资源，环境搭建，测试数据的准备，用例的设计编写。对于测试资源，环境搭建，测试数据，要根据测试环境阶段确定相关造数据人员以及约定时间，这个很重要，不然会在测试执行阶段影响测试进度，而且是阻碍性的测试；对于用例编写阶段，可以分为用例格式，用例描述标准和用例设计； 用例格式基本大家都懂，基本为元素为ID，类型，模块，前置条件，步骤，期望，结果，备注，这个就不在描述， 这个要重点说的就是用例描述标准，这个描述标准决定着用例易读性，易操作性，易理解性，主要从描述模糊性，实例性，独立性来说，模糊性，指的就是在用例中，不能使用多，少，一个步骤对应一个期望，比如步骤：在输入框输入多个字符，这个用例步骤描述就是有问题，必须输入框，输入整数333，然后点击xxx，这样描述才是对； 实例性指的不要把用例写的跟需求一样，如步骤点击下载游戏，期望：下载过程中的安装状态跟正常游戏下载状态一致，应该步骤是进入到某个页面，点击某个游戏，然后点击下载按钮，期望：按钮状态显示为下载中；还有类似签到功能，一台设备只能签到1次，这时应该是前提：有签到过的A手机，没有签到过的B手机，然后编写用例的时候要指定是A还是B手机来描述； 独立性，也就是用例是独立的，不会依靠其他的用例，不然会出现有的人写的用例关联性是惨不忍睹，会造成执行效率以及他人协助的困扰； 用例的设计其实就是测试内容，除了业务方面设计，设计方法等价类什么，这方面就不说了，我就提醒要建立一份测试功能清单和经常维护各种类型用例，然后编写用例要参考着清单，看是否这些内容是否需要测试，这样可以保证用例覆盖率，并且遇到类似的就可以直接用维护的用例进行简单修改就可以成为用例，编写用例就是为了覆盖功能，目前很多措施都是只能提高覆盖率，如评审，无法有数据的量化，这个是可以代码覆盖率，但因为是未开发中，这个只能在测试执行中，通过功能执行的代码覆盖率来看是否覆盖，然后完善用例，保证用例功能覆盖率； 用例评审，就是测试项目负责人提交需要评审的用例对应的需求，交互等资料，然后标注这些用例是什么日期要评审完，至于评审方式，可以组内交互评审，主管评审，还有会议评审，特别要说的就是会议评审，这个可能大家都做得比较少，这个会议评审，就是当事人在把功能拆解，讲得跟你操作过一样，然后并且提醒这边得测试要注意什么，让听着的人，可以快速了解这个功能，这样的方式，不仅可以让测试的人思路更清晰，也反思自己是否漏掉测试点，也可以让他人掌握这个功能点，便于功能的协助，用例的评审通过标准就是至少不会出现所谓的UI，交互或者需求点漏测并尽量覆盖到隐形需求；评审完以后，要总结相关资料，反馈给测试负责人进行修改，然后修改完，再发给评审者确认，然后写个总结，这个评审流程才算结束； 用例评审的总结主要来评估统计覆盖率，编写水平，做个评估，这样不仅管理者可以知道测试人员的编写水平以及数据统计，告诉他们，让他们知道自己的水平，这样对于用例编写水平九有有内容性和量化的评估； 用例编写水平高低主要表现在易执行和功能覆盖率，而覆盖率比较难衡量，所以不需要了解需求就可以执行这就是用例编写的最高水平；用例编写的好处，让测试逻辑清晰，提高功能覆盖率，方便他人协助，工作安排，能力量化评估，用例维护及服用，提高测试效率，测试质量标准化；

编写测试用例时间来不及，那要怎么办，写还是不写呢？ 写，必须写，除非需求是一看了然大家都知道怎么测，记得是大家都知道。不然都要写，写的方式，最好是用例，除非真的很赶，才用思维导图列出测试点，并且思维导图是主要对点的拆分，对于主要功能正向，一看可以一概而过，重点在于逻辑拆解，有的人说，我在思维导图编写就行了，何必在用例平台或者Bug管理工具 上面写，错了，是一定要按照用例规范写，至于上平台，excel都可以，如果你用XMIND的写的很清晰，跟正规编写用例，其实花的时间一样，再不济这个时间会在用例执行时间补回来，差别的只是你心里账户问题而已。这个心里账户可以比喻为，比如你用你的工资去买衣服，太贵了下不了手，如果是用你彩票中的钱，你就随便买。所以这个只是心里差别，都是发钱；这些是从用例角度，如果是从一个所谓假敏捷模式或者不看重测试，天天追着发版，又不给时间，又要质量，我只能说，同学你能活着就好~最终用例写不写，用什么方式，还是要根据项目或者企业而定，灵活转变，合适最重要；但要记得，用例是衡量项目质量的一个核心因素；