写了一周测试用例,感觉自己是个文员怎么办?

文章讲述了在需求不明确的情况下,测试人员应如何采取行动,包括将需求不明确视为机会,搜集资料,借鉴竞品,根据经验和常识判断以及沟通讨论。同时,提出了在时间紧张时如何高效设计测试用例,先梳理关键测试点,然后在需求明确后再编写详细测试用例。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

需求没定,只出一个主流程,还在细化有可能要改主流程,没有UI图,没有需求,开了两次会听需求,今天又要开,开完估计又要改用例了,项目老大要求昨天就要求用例评审,,内心慌乱啊

这个问题,表面上以为是控诉“测试用例没啥技术含量,文员都能干”,看完补充文字,才发觉真正控诉的是 “需求不明确,测试用例改来改去,像个文员”。

面对真正控诉,深有感触,瞬间回想起自己在测试行业混迹10年摸爬滚打的曲折路程。为了彻底解决“需求不明确,测试人员应该怎么做”这个问题,我从下面两个方面分享我个人的解决经验:

1、需求不明确,作为测试人员怎么办?

2、在需求不明确,时间紧的情况下,如何高效的设计测试用例?

需求不明确,作为测试人员怎么办?

我说经历的互联网公司,普遍存在需求不明确的问题,也就是大家吐槽最多的“一句话”需求。

甚至我还遇到过比“一句话需求”让人更崩溃的事情:记得当时刚入职一家新公司不到1个月,接了一位产品经理的小需求,提测之后,我发现需求内容在之前的代码中已经实现了,也就是说这次需求是无效的,开发和测试人员都在做无用功。。。作为测试人员的我,内心是崩溃的。。。
在这里插入图片描述
"需求不明确"的问题很普遍,测试人员该怎么应对呢?两个方面:

一、心态上,要将需求不明确看成是一个机会

因为需求不明确,就留下了我们对需求进行分析设计的空间,留下了我们施展拳脚的舞台,能够发现更多的问题。这个过程中,是提升自己的过程。

二、行动上,采用四步走

1、搜集资料

搜集所有相关资料,包括但不限于与客户沟通的需求记录、需求评审记录、开发设计文档、开发需求功能列表、开发会议记录、数据库说明文档等。

这些虽然比较零散,但是有价值。

2、借鉴竞品

一般情况下,我们测的软件系统总会有着众多的对手产品,所以会有原型参考。

比如要测的是电商系统,就可以参考淘宝、京东、拼多多。电商系统主要功能逻辑基本一样的,只是细节可能有出入,我们在淘宝、京东、拼多多上操作一遍,基本上对电商系统的主要功能就已经了解了。

即使没有竞品可参考,也可以在网上搜索资料,参考下行业的基础知识,对系统有一定的认知,也可以更好的去分析需求内容。

3、根据经验和常识判断

随着测试经验的积累,大家就发现,所有系统的测试,万变不离其中,思路和方法都可以套用的。

比如上个项目测得是音乐播放系统,现在小说阅读软件系统要做会员功能,需求就一句话“做一个会员功能”,怎么测?没有详细得需求文档我就没法测了吗?no no no。

之前测的音乐播放系统也有会员功能,我们就可以用来参照。根据小说阅读软件系统的功能业务特点去细化测试会员功能。

所以之前的项目经验、测试用例设计方法、处理问题的方法、测试技术等等都可以套用。

当然这对测试人员的能力素养有一定的要求,需要测试人员不停的提升自己各方面的能力。

4、沟通讨论

这点非常重要。针对不明确的需求疑问点,可以跟客户沟通,也可以和内部开发人员、产品经理进行沟通讨论。沟通过程中,需求疑问点会越聊越清晰。

针对整个项目组已经沟通确认的需求内容,就可以同步更新到产品需求文档中。

三 、在需求不明确,时间紧的情况下,如何高效的设计测试用例?

需求不明确,时间还紧,也要设计编写测试用例吗?答案是必须的,为了保证测试质量,不漏测,也必须要设计编写测试用例。

但在这种情况下,可以不必非要编写详细的测试用例,可以针对需求内容先梳理设计关键的测试点,先保证能对现有的需求覆盖全面,以防遗漏。

好处就是给测试人员提供一个全面可靠的思路,防止设计用例过程中的遗漏或者错误。

这样即使后面需求变更,只需要根据需求变动部分修改补充测试点即可,不需要大规模的变动。

测试用例评审时,可先直接评审测试点。

等需求明确,测试点也通过评审后,再来进行详细测试用例撰写。

所以在需求不明确,时间紧的情况下,高效的设计测试用例共分为2步:

第一步:针对需求内容,先梳理设计关键的测试点

如何将需求内容转化为测试点呢?

1、梳理拆解测试点

一般把需求内容拆解成小的功能点,再针对每个小功能点,使用一些常用的设计测试用例的方法,分别设计测试点。

常用的设计测试用例的方法有:等价类、边界值、错误推测法、判定表、因果图、场景法等
举例:现在评价页面需求如下:

评分:1-5星
评价晒单:10-200个字符
图片:最多上传5张,小于2M,支持格式:png、jpg、jpeg、gif
匿名评价:勾选、不勾选

若上述需求要拆分成测试点,需求如下:

图片

2、根据质量模型特性,补充测试点

测试点拆解完成之后,根据质量模型特性,站在用户角度想方设法思考,用户在使用过程中可能会存在的问题,补充完善测试点。

质量模型特征包含:功能性、性能效率、安全性、易用性、兼容性、可靠性等
仍然以上面评价页面功能为例,根据软件质量模型,补充测试点:

图片

第二步:需求明确+测试点没问题,编写详细的测试用例

针对详细的测试用例的编写,提供几篇文章给大家学习,这里就不再唠叨了。

最后: 为了回馈铁杆粉丝们,我给大家整理了完整的软件测试视频学习教程,朋友们 如果需要可以自行免费领取 【保证100%免费】
在这里插	入图片描述

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

在这里插入图片描述
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值