主讲：五娃
昨晚五娃分享的直播，中间挑自己需要的点，做了笔记，供以后回看。
一、用例的定义
二、测试用例的好处
1.输出用例量，老大根据用例量来评估后期的工作时间。工作跟开发同步，做测试计划，工作时间要有一段依据；
2.用例写完后，没有时间做测试，可以让其他人跟进测试用例做测试执行；
3.互联网的版本迭代、功能也是迭代的。测试用例有通用的地方，测试用例的输出避免了重复性；
4.用例书写-评审-更新-测试-更新，用例也是一个迭代更新的过程（如发现一个bug,针对这个bug,再添加相关用例）
三、什么时候开始写？
需求文档定版后
1.产品文档很low，各种需要测试去沟通，各种找需求。
做完自己手头的工作，去找领导反馈，并且带着解决方案去。或拿出一定证据给老大以谈判的依据。
2.在用例执行过程中，发生需求变更？
去确定该需求影响的范围多大，如果很大，等于说推翻你自己之前的工作。加功能或变需求，如果合理或不得不加，可以加进去；如果可以推迟，坚决不加。
四、设计测试用例？
1.产品文档/需求文档中的规则转换为每个用例的检查点。
2.先写正向用例、再写反向用例（异常）
a.从头写到尾，b.先写重点模块，然后重点模块的关联模块 ，然后无关性的模块
3.涉及到数据库的内容，做数据库的用例设计；起码做到，去和数据库的数据做对比，保证数据库入库的数据是正确的，否则即使功能走通，数据不对，也是无效的。
五、实际工作中的测试用例？
www.we.com
罗列出5个模块
功能点罗列后要找到对应的角色
1.所有用例必须评审？是的，全部。评审后如果没进行任何更新，说明参加评审会的人都没用心；
2.所有的需求都要写测试用例？不是，并非所有的需求都要写，一眼能看出来能测的就不用写；
3.用例的粗粒度？用例是给别人看的，别人清楚知道怎么操作就好，不是越细越好；
