这些天招了新人,新项目紧张的测试告一段落,我也开始为功能写用例。
一段时间不写了,写起来有点生疏,但是思路还很清楚。写到一半收到新人写完发过来的用例。
我一看就懵了,哥您这用例根本就是直接拷策划案啊,跟策划案都一样还要你这用例干嘛。
我一下就觉得这哥们是不是糊弄事儿,后来我把他叫过来聊了聊,发现不是,是他就觉得用例就该是这样。
在之后不断教他和反复修改用例的过程中,我也同时开始不断审视用例到底该写到什么程度。
首先,先说用例的目的是什么?
用例的主要目的是让可以将每一条需要测试的点都想清楚明白,其次让你测试的覆盖面尽量广,并且通过书面的形式记录可以减少遗漏。
目的清楚了那要写到什么程度去达到这个目的就轻松多了。
再回答这个问题,测试用例要详细到什么程度?
有人主张测试用例详细到每个步骤执行什么都要写出来,目的是即使一个不了解系统的新手都可以按照测试用例来执行工作。主张这类写法的人还可以举出例子:欧美、日本等软件外包文档都是这样做的。
另外一种观点就是主张写的粗些,类似于编写测试大纲。主张这种观点的人是因为软件开发需求管理不规范,变动十分频繁,因而不能按照欧美的高标准来编写测试用例。这样的测试用例容易维护,可以让测试执行人员有更大的发挥空间。
实际上,软件测试用例的详细程度首先要以覆盖到测试点为基本要求。
举个例子:“用户登陆系统”的测试用例可以不写出具体的执行数据,但是至少要写出五种以上情况,如果只用一句话覆盖了这个功能是不合格的测试用例。覆盖功能点不是指列出功能点,而是要写出功能点的各个方面(如果组合情况较多时可以采用等价划分)。
另一个影响测试用例的就是组织的开发能力和测试对象特点。
如果开发力量比较落后,编写较详细的测试用例是不现实的,因为根本没有那么大的资源投入,当然这种情况很随着团队的发展而逐渐有所改善。测试对象特点重点是指测试对象在进度、成本等方面的要求,如果进度较紧张的情况下,是根本没有时间写出高质量的测试用例的,甚至有些时候测试工作只是一种辅助工作,因而不编写测试用例。
因此,测试用例的编写要根据测试对象特点、团队的执行能力等各个方面综合起来决定编写策略。
最后要注意的是测试人员一定不能抱怨,力争在不断提高测试用例编写水平的同时,不断地提高自身能力。
以下可做参考:
1.将每一个功能点分解成可以进行测试(需要写明可操作的步骤)的测试点
2.用例每一条都是一个测试点,不要将多个测试点写到一个用例里
3.无法测试的点需要提出与程度沟通定出解决方案(做GM命令,改数据库等)
只有清晰明确了,用例才能帮助你进行全面的测试。
同时用例也是考察技术基本能力重点之一,因为用例实际就是你怎么测的思路的表现,我不可能站在你身边看你怎么测,我只能通过用例去看,如果用例写的不好,那这个测试员我只能说我可能也不会太看好。
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。