项目很赶,应不应该编写软件测试用例
作者:网络转载 发布时间:[ 2012/7/18 11:05:51 ] 推荐标签:
在逛论坛的过程中,发现很多人有这样一种疑问:有时项目很赶,应不应该写测试用例,如果写,哪里有时间?我也来说说我对这个问题的看法。
首先,我们先来了解一下编写测试用例的目的,我不知道别人对编写测试用例的目的怎么看,但在我看来,编写测试用例的目的只有一个,那是指导测试。测试是一种重复的工作,是一种螺旋式的工作,测试->发现问题->程序员解决问题->回归测试->发现问题……是这样一种不断回归测试,正是因为测试的这种特性,测试用例起到极为重要的作用。
很多有经验的测试人员或许会觉得算没有测试用例,也是一样测试,反正测试过程都已经熟悉得不能再熟悉了,但是我觉得没人能保证自己不会存在头脑发昏或者脑袋不清晰的时候,如果头脑清晰,测试分析起来可能确实是头头是道,包括用什么边界值用什么样一个流程都清清楚楚,但是假如有睡得不好,又或者某天心情不好,这时可能有点阻滞了。在这种情况下可能会出现少测了一个点,导致覆盖率不全面,这时有的bug可能测不到了。假如有测试用例的话,这些问题不成为问题了,只要我把所有的测试点都用用例记录下来,哪怕是在极度精神不济的情况下,我也可以按照测试用例一条条地测下来。从小老师教过好记性不如烂笔头,我觉得这句话用在测试用例中倒是很合适,算你记性再好,都有可能有疏忽的时候,还不如用用例记下来,不会出现少测的情况。
回到我们先的问题,项目太赶的时候应不应该写测试用例,我的回答是“不管多忙都好,都应该写测试用例”,但是我们这时不必要按常理出牌,即:先编写测试用例,再测试。写过测试用例的人都知道,其实编写测试用例的时间远远大于测试的时间,在整个测试流程中,测试用例占了绝大部分的时间,而测试过程仅占了其中一小部分,因此,如果项目很赶时间,可以先按照自己的思路去测试,在测试完成之后及时把这个思路记录下来,如果没什么时间,在写测试用例的时候可以不用写得那么详细,只需要把测试标题写上,标题中反应了你的各个测试点,这样整个测试过程可以保存下来了,等到以后有时间了,再来补充测试步骤等。不管你有多忙,只要你想,只写个标题的时间总是能挤出来的。
测试用例的好处有很多,一是可以达到‘一劳永逸’,这里的‘一劳永逸’指的是相同的测试过程,写过测试用例后不需要再去作测试分析,然后再来进行测试,而可以按照测试用例一步步测试下来,节省了不少时间,回归测试的时候我能明显感觉测试得很快;二是有了测试用例作指导,不会发生少测了某些测试点的情况,算是第一次测试少测了,只能说是测试用例覆盖率不够,这时再对测试用例进行补充,在下次不会少测了;三是可以给其他人(特别是新人)进行指导,或者是可以互相交流,有的测试员的测试思路很好,这时我们可以参考一下他的测试用例,看看他的整体测试思路是怎么样的,来提升自己的不足之处。
总之,个人认为,不管怎么样,测试用例都是需要写的,不管是对自己,还是对别人,编写测试用例都是有好处的,但是不必要对编写测试用例这个过程控制得极严,可以根据实际情况来进行操作,任何东西都需要一定的灵活性,编写测试用例也不例外。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11