测试用例

测试用例的定义：按照一定的输入和预制条件执行之后能达到预期结果，验证功能程序所需要的需求。

测试用例的好处：

   1）能有效，快速的了解熟悉产品

   2）可以评估需求的覆盖率程度

   3）用例的细化程度可以作为阶段性工作的时间安排依据

   4）将人为的因素减少，比如：其他人执行的时候可以看得懂

总结：对产品有清晰地思路。

1、用例的输出避免一个重复性，版本更新是迭代，功能也是一个迭代的过程，迭代的过程中会回归老的功能，如果不写测试用例那么要重新去写测试用例，无形中把工作增加，费时。

2、测试的用时是根据测试数量可以排出一个时间

3、测试用例是不断更新的，随着时间和对产品的了解是不断更新的，测试结束发现bug时要再次更新。

 什么时候开始写测试用例？

产品写的很low,什么都要测试自己去沟通，确定；那么这种情况就要先把自己的情况做好，再次要向领导反映，反映的时候要把解决方案，或者想法；

如何设计测试用例

在测试中出现需求变更，先评估需求，看影响范围是否大，如果要推翻之前的工作那就拒绝，如果合理或必须加那就加，如果需求变更会导致版本延期那就不加。

产品文档，规则转换为测试用例的检查点

一条用例只做一件事，只验证一个功能

先从单个模块或功能点开始

借助一些测试用例方法：等价类，边界值，因果图

兼容性测试，如浏览器，APP的兼容

设计测试用例的时候要注意数据库的关联，数据库中数据正确性的验证

设计用例的时候要考虑关联模块的问题

思考：

用例是否评审：

  所有的用例都需要评审，如果评审过后没有更新，评为：大家评审时都不走心..........

所有的需求都需要写测试用例吗？

   不一定，如果需求一眼就能测完不需要，如果比较复杂比较大的需求就需要写

测试用例的学详细越好吗？

  记住：用例是写给别人看的，别人能看得懂的用例才是好用例

  写的用例面面俱到详细真的好吗？不是的。

写用例的时候要包含哪些因素：

1. 编号，便于查找；

2. 描述，便于清楚写的是哪一些功能

3. 前置条件，有就写没有就不写，

4. 步骤，需要用到的数据写在前置条件

5. 预期结果