测试用例的定义：按照一定的输入和预制条件执行之后能达到预期结果，验证功能程序所需要的需求。
测试用例的好处：
1）能有效，快速的了解熟悉产品
2）可以评估需求的覆盖率程度
3）用例的细化程度可以作为阶段性工作的时间安排依据
4）将人为的因素减少，比如：其他人执行的时候可以看得懂
总结：对产品有清晰地思路。
1、用例的输出避免一个重复性，版本更新是迭代，功能也是一个迭代的过程，迭代的过程中会回归老的功能，如果不写测试用例那么要重新去写测试用例，无形中把工作增加，费时。
2、测试的用时是根据测试数量可以排出一个时间
3、测试用例是不断更新的，随着时间和对产品的了解是不断更新的，测试结束发现bug时要再次更新。
什么时候开始写测试用例？
产品写的很low,什么都要测试自己去沟通，确定；那么这种情况就要先把自己的情况做好，再次要向领导反映，反映的时候要把解决方案，或者想法；
如何设计测试用例
在测试中出现需求变更，先评估需求，看影响范围是否大，如果要推翻之前的工作那就拒绝，如果合理或必须加那就加，如果需求变更会导致版本延期那就不加。
产品文档，规则转换为测试用例的检查点
一条用例只做一件事，只验证一个功能
先从单个模块或功能点开始
借助一些测试用例方法：等价类，边界值，因果图
兼容性测试，如浏览器，APP的兼容
设计测试用例的时候要注意数据库的关联，数据库中数据正确性的验证
设计用例的时候要考虑关联模块的问题
思考：
用例是否评审：
所有的用例都需要评审，如果评审过后没有更新，评为：大家评审时都不走心..........
所有的需求都需要写测试用例吗？
不一定，如果需求一眼就能测完不需要，如果比较复杂比较大的需求就需要写
测试用例的学详细越好吗？
记住：用例是写给别人看的，别人能看得懂的用例才是好用例
写的用例面面俱到详细真的好吗？不是的。
写用例的时候要包含哪些因素：
编号，便于查找；
描述，便于清楚写的是哪一些功能
前置条件，有就写没有就不写，
步骤，需要用到的数据写在前置条件
预期结果
