测试用例阶段总结

发表于:2019-1-04 13:16

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:幸运的灵小小    来源:博客园

分享:
  测试用例,简单来说,就是一个文档,描述输入、动作和期望的结果,作为一个半路转行的小白来说,刚开始,觉得测试用例有点多余,脑图画画思路,有个梗概即可,但是越来越多的坑告诉我,测试用例,必不可少,那么,大家可能会遇到以下几个问题:
  1.测试用例繁杂,如何维护?
  2.怎样高效利用测试用例来开展测试工作?
  3.测试过程中涉及的范围如何定义?
  接下来,就分享一下自己的方案
  1.高效维护
  刚开始,虽然是模块化,但是在一个sheet里,每次下拉几百行,定位太浪费时间,不知道你们的用例评审模式和我们的是否一样,我们的用例写完之后产品都要先过一遍,所以,每次都会被各种吐槽,所以,商量了一下
  解决方案:分模块,一个模块一个sheet,新增功能或优化按大模块细分增加进去,最近的优化发给产品之前用颜色标注一下本次的修改,再发消息说明总的变动,用例用版本工具维护,第三方工具也可,我们是用SVN维护,可以找回历史版本
  2.测试范围
  之前,同事问我评审测试用例的意义何在,答:距离项目评审已经一段时间,可能会有遗忘,再碰一下,看测试和产品之间对于需求理解有没有偏差,查漏补缺。
  再问,那为什么要叫开发一起呢,答:开发也可能会忘。。。
  说完我自己都感觉搞笑
  完了同事提出了正解:对于初级测试来说,我们对于一个功能可能影响的范围是按照主观来看的,但是实际上可能还影响了其他的模块,这个就要开发帮我们分析一下,他们在改代码的时候可能会动到哪一块,总而言之,两点
  1>思维导图自己梳理功能,和产品达成一致
  2>用例评审过细节,记录开发的问题点,联想可能涉及到的模块
  3.必测项
  刚开始接触这个概念,是基础用例,不过我感觉叫必测项更好理解,字面意思,就是不管上什么功能,你都要保证这部分功能不会受影响
  八个字:由繁至简,由少到多
  一开始,不太确定范围,可以把一些核心流程都测一遍,完了预估时间,多次之后,把一些不会变动且没问题的流程去掉,慢慢形成自己测试的一套必测项,然后,在这个过程中,可能会出现一些新的问题,慢慢增加,这个,是个不断优化的过程
  4.总结
  一件事情刚开始做的时候,可能会觉得很繁琐,但是框架搭起来之后,你会发现,以后的工作会方便很多,所以,磨刀不误砍柴工
  最后,再说个小事吧
  一开始,想把必测项以导图的形式来做的,然后再去找对应用例,但是,又被否了
  你的思路,你知道,后来的小伙伴怎么办,这就是所谓的前人栽树,后人乘凉
  所以,前人小伙伴们,加油吧!

      上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
精选软件测试好文,快来阅读吧~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号