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