百人计划

百人4:测试用例经验谈-五娃

2017-03-06  本文已影响0人  兼葭dx

主讲:五娃

昨晚五娃分享的直播,中间挑自己需要的点,做了笔记,供以后回看。

一、用例的定义

二、测试用例的好处

1.输出用例量,老大根据用例量来评估后期的工作时间。工作跟开发同步,做测试计划,工作时间要有一段依据;

2.用例写完后,没有时间做测试,可以让其他人跟进测试用例做测试执行;

3.互联网的版本迭代、功能也是迭代的。测试用例有通用的地方,测试用例的输出避免了重复性;

4.用例书写-评审-更新-测试-更新,用例也是一个迭代更新的过程(如发现一个bug,针对这个bug,再添加相关用例)

三、什么时候开始写?

需求文档定版后

1.产品文档很low,各种需要测试去沟通,各种找需求。

做完自己手头的工作,去找领导反馈,并且带着解决方案去。或拿出一定证据给老大以谈判的依据。

2.在用例执行过程中,发生需求变更?

去确定该需求影响的范围多大,如果很大,等于说推翻你自己之前的工作。加功能或变需求,如果合理或不得不加,可以加进去;如果可以推迟,坚决不加。

四、设计测试用例?

1.产品文档/需求文档中的规则转换为每个用例的检查点。

2.先写正向用例、再写反向用例(异常)

a.从头写到尾,b.先写重点模块,然后重点模块的关联模块 ,然后无关性的模块

3.涉及到数据库的内容,做数据库的用例设计;起码做到,去和数据库的数据做对比,保证数据库入库的数据是正确的,否则即使功能走通,数据不对,也是无效的。

五、实际工作中的测试用例?

www.we.com

罗列出5个模块

功能点罗列后要找到对应的角色

1.所有用例必须评审?是的,全部。评审后如果没进行任何更新,说明参加评审会的人都没用心;

2.所有的需求都要写测试用例?不是,并非所有的需求都要写,一眼能看出来能测的就不用写;

3.用例的粗粒度?用例是给别人看的,别人清楚知道怎么操作就好,不是越细越好;

上一篇下一篇

猜你喜欢

热点阅读