计划、用例、报告百人计划

测试用例

2017-03-06  本文已影响60人  傻虫子

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

测试用例的好处:

   1)能有效,快速的了解熟悉产品

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

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

   4)将人为的因素减少,比如:其他人执行的时候可以看得懂

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

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

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

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

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

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

如何设计测试用例

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

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

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

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

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

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

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

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

思考:

用例是否评审:

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

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

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

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

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

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

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

  1. 编号,便于查找;

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

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

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

  5. 预期结果

上一篇 下一篇

猜你喜欢

热点阅读