测试应该知道的知识-测试用例设计及用例评审
本文主要总结下，自己在测试中遇到的一些知识，针对用例设计及评审来做一些总结；
- 用例设计：用例如何划分，如何编写用例
- 用例评审：评审的作用，评审的内容
用例划分
小白是否在平时写用例时，有以下困惑：
面对新版本一堆的需求无从下手？
怎么编写用例才能尽可能的将需求及问题覆盖？
测试用例的划分
- 按系统模块划分
- 按性质分类划分
- 按关联紧密程度划分
接下来逐个举例子来解释下
用例划分-系统模块划分
用例划分：针对每个模块、子模块或子模块的模块设计用例
比如：
当前业务模块有消息中心，下载中心，意见反馈，设备管理.....等...
设备管理 又有 设备详情，设备在线数，设备健康状态 等..
优点：容易展开，简单明了
缺点：
1.业务逻辑容易被忽视。模块与模块之间往往是关联的。
2.可能会忽略非UI的功能
用例划分-系统模块划分
设备有历史信息的模块，设备管理删除设备后，设备的历史信息还会存在吗？
历史信息不可见删除的设备历史信息；
用例划分-性质分类划分
兼容性测试 ，安全测试，压力测试，可靠性，用户界面（UI） 等..
优点：对按模块划分的有效补充。
地址栏输入不同的数据之后，再点击提交博客评论，会怎么样？
结果：刷新之后评论不见了？？？？？？？
用例划分-按关联紧密程度划分
也是按模块划分，区别是把关联比较紧密的模块归到某个模块；
以系统模块划分为主，性质及关联紧密程度为辅；
好处：有利于任务分配，减少人力资源的重复投入
用例编写
用例设计-五个维度
用例设计-原则
- 层次性
- 完整性
- 可测性
- 复用性
用例的组成
用例应遵循统一或规范的格式、结构，规范的命名规则，使用术语，用简明、易懂、无歧义的语言来描述，并且具有详细的文档
- 模块
- 用例名 ： 【下载】下载文件内容检查
- 优先级
- 测试环境/测试前提
- 操作步骤
- 预期结果
- 测试结果
- 其他项 ：版本、测试用例类型、备注...
用例评审
关于用例评审，大家应该有很多不同的声音，先来吐槽一下
开发A：测试用例设计是测试的事情，为什么评审要我们参加
测试B：用例评审太枯燥了，200个用例case用一条一条评吗
开发C：这个是别人的负责的模块，跟我没关系
测试D：测试用例已经很多了，不知道需要评审什么
既然大家都这么多吐槽，那么用例评审的作用是什么呢？
以下六点属于转载：http://www.51testing.com/html/54/n-810854.html
原因一：设计完成的测试用例要分配给每个人来设计具体数据，并实现自动测试。设计用例和实现用例、执行用例并非一人完成。设计用例的人并不知道用例在具体执行的时候是否有问题，或者哪些步骤不能实现自动测试。再者“测试是无穷尽的”，谁又能保证自己设计的用例能覆盖完全？
原因二：测试人员总是抱怨测试出来Bug后与开发扯皮太多，主要的原因之一是测试人员和开发人员对于被测试功能的理解未达成一致。因此用例需要提交给开发人员check，并在测试开始之前对于测试目标的功能需求理解达成一致。用例一般比需求文档更加具体，能更好的体现具体测试思路。如果在测试开始之前就提前和开发达成一致，那么在你发现争议的bug的时候，就不用费劲解释了，可以直接告诉他“用例评审的时候已经确认是这样了。”
原因三：让需求人员参与评审，她们能帮助你找出更多的问题。经常在测试的时候，有些细节是无法送需求文档上得知的，需要频繁来和需求人员沟通，问东问西，如果他们在忙，也许会产生这样的心理“怎么连这个也不知道？”我们测试人员多委屈，吃苦不讨好。所以在评审的时候让需求人员明亮的眼睛多帮我们找出问题，解决疑问。
原因四：设计完成用例至少要让Leader评审下，让她理解你的思路，如果有问题也及早提出。不然当你测试的模块出现问题的时候，Leader绝不会说都怪她当时没review你的用例，责任还是在你身上。
原因五：现在有很多人是项目外包或人员外包，那么完成每一项工作的第一件事就是提交客户评审，当然在提交给客户前自己team先评审下最好，确保提交给客户高质量的成功。
原因六：如果严格按照用例数量来计算工作量，真正测试A模块需要200个用例，一周的时间，可是你却由于某些误差设计出100个case，那么评估出来3天的工作量，那么你就等着加班吐血吧。
评审参与者：开发，测试，产品经理
评审的内容
1、描述是否清晰，是否存在二义性
2、内容是否完整,是否清楚包含输入条件和预期输出结果并无争议点
3、是否覆盖了所有场景、逻辑分支、限制条件等
4、是否哪些需求不可测：无法准备环境、可测试性达不到等等原因
5、是否考虑到测试用例的执行效率（冗余的用例）
