- 专注于分享软件测试干货内容,欢迎点赞 收藏 ⭐留言 如有错误敬请指正!
- 交流讨论:欢迎加入我们一起学习!
- 资源分享:耗时200+小时精选的「软件测试」资料包
- 最困难的时候,也就是我们离成功不远的时候!
这些天招了新人,新项目紧张的测试告一段落,我也开始为功能写用例。
一段时间不写了,写起来有点生疏,但是思路还很清楚。写到一半收到新人写完发过来的用例。
我一看就懵了,哥您这用例根本就是直接拷策划案啊,跟策划案都一样还要你这用例干嘛。
我一下就觉得这哥们是不是糊弄事儿,后来我把他叫过来聊了聊,发现不是,是他就觉得用例就该是这样。
在之后不断教他和反复修改用例的过程中,我也同时开始不断审视用例到底该写到什么程度。
用例的主要目的是让可以将每一条需要测试的点都想清楚明白,其次让你测试的覆盖面尽量广,并且通过书面的形式记录可以减少遗漏。
目的清楚了那要写到什么程度去达到这个目的就轻松多了。
有人主张测试用例详细到每个步骤执行什么都要写出来,目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子:欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些,类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范,变动十分频繁,因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护,可以让测试执行人员有更大的发挥空间。
实际上,软件测试用例的详细程度首先要以覆盖到测试点为基本要求。
举个例子:“用户登陆系统”的测试用例可以不写出具体的执行数据,但是至少要写出五种以上情况,如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点,而是要写出功能点的各个方面(如果组合情况较多时可以采用等价划分)。
另一个影响测试用例的就是组织的开发能力和测试对象特点。
如果开发力量比较落后,编写较详细的测试用例是不现实的,因为根本没有那么大的资源投入,当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求,如果进度较紧张的情况下,是根本没有时间写出高质量的测试用例的,甚至有些时候测试工作只是一种辅助工作,因而不编写测试用例。
因此,测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。
最后要注意的是测试人员一定不能抱怨,力争在不断提高测试用例编写水平的同时,不断地提高自身能力。
以下可做参考:
1.将每一个功能点分解成可以进行测试(需要写明可操作的步骤)的测试点
2.用例每一条都是一个测试点,不要将多个测试点写到一个用例里
3.无法测试的点需要提出与程度沟通定出解决方案(做GM命令,改数据库等)
只有清晰明确了,用例才能帮助你进行全面的测试。
同时用例也是考察技术基本能力重点之一,因为用例实际就是你怎么测的思路的表现,我不可能站在你身边看你怎么测,我只能通过用例去看,如果用例写的不好,那这个测试员我只能说我可能也不会太看好。
如果你想学习自动化测试,那么下面这套视频应该会帮到你很多
如何逼自己1个月学完自动化测试,学完即就业,小白也能信手拈来,拿走不谢,允许白嫖....
最后我这里给你们分享一下我所积累和整理的一些文档和学习资料,有需要直接领取就可以了!
以上内容,对于软件测试的朋友来说应该是最全面最完整的备战仓库了,为了更好地整理每个模块,我也参考了很多网上的优质博文和项目,力求不漏掉每一个知识点,很多朋友靠着这些内容进行复习,拿到了BATJ等大厂的offer,这个仓库也已经帮助了很多的软件测试的学习者,希望也能帮助到你。