思路|产品新人应如何撰写测试用例(功能性测试)
如果你在大公司,那么恭喜你,你很幸福。因为你只需要写好产品需求文档就好了。但如果你恰恰在一个创业公司,那么你很可能要担负器撰写测试用例的重担。那么,作为产品新人的你,该如何撰写测试用例呢?
事先声明,本文是给产品新人的一个指导方向,如果你是测试大牛,那更希望你能弄出一篇完整的教程来。
既然你公司没有测试,那么作为产品汪,自然就得担负起产品测试重责。
一、产品测试的意义
一个完整的开发流程。从提需求、开发、交付。这中间都应该有个结果。就如你做一件事,得有个东西来判断你是否已经完成了这件事。那么测试结果就是这个东西了。
一般情况下,在开需求评审会议时同时会把测试需求列明,以确保产品按质量上线。
二、测试文档的结构
一般情况下,测试文档主要分两个部分。即:非功能性测试需求、功能性测试需求。
所谓非功能性测试,主要指APP运行时在各种环境下是否能正常运行,而功能性测试是指每个具体功能是否按要求运行。
作为产品新人,测试文档也不需要太复杂,直接使用excel编撰就可以了,请看下图:
上图是我刚刚编写的,直接写了一个简单的注册登录模块下的账号密码登录部分测试用例。
一般情况下,功能性测试文档直接使用该模板就能满足大部分的需求。
三、具体编写方法
在编写测试用例之前,你得想好有哪些前置条件。这些前置条件满足了才能达到你得预期。比如账号密码登录,前置条件时账号和密码同时正确才能正常登录成功。那么此时你就得编写条件不符的时候,是否也会成功。如果成功了,那就属于BUG,需要技术进行修复。
一般正常情况,请考虑一下几个方面:
- 页面布局是否合理,如导航栏上面应该显示三个按钮,实际上却显示了两行。
- 页面文字描述是否准确,如气泡提示:密码格式错误,请重新输入。实际上却显示:账号密码错误。
- 如果有加载规则,是否符合加载规则。如:进入页面加载20条内容,实际上却加载了10条。
- 如果有排列规则,是否符合排列规则。如应按照时间倒序排列,实际上却是正序排列。
- 操作是否符合要求,如单击某个点,是否准确跳转或显示内容。如本应该进行跳转,实际上却未进行跳转。
- 输入框输入的内容是否有符合格式要求。如:账号不允许”,”,而实际上却允许了。
- 输入的内容是否符合合法性要求。如:账号密码是否一致等问题。
- ……
这些基本考虑内容都需要考虑进来。
大概理清楚需要考虑的内容之后,就可以开始动手写了。
- 序号: 不用说,就是按顺序下去的。
- 模块:该功能点具体属于哪个模块的,填写这个主要是方便查找,如:注册/登录模块
- 编号:对每个用例进行编号,方便后期跟进。毕竟用文字说,容易口误。不过此处建议编号设计的有点规则,方便快速定位查找。如:A0001。其中A表示注册/登录模块。00表示账号登录,01 表示账号密码登录下的第一个测试用例。
- 功能点:具体指某个功能,如:账号登录、首页、发布等。
- 子功能点:具体指功能点,如:账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
- 用例名称:具体测试用例的名称。如:输入账号、输入密码、密码不合规等等。
- 前置条件:指要达到预期测试结果,需要满足那些条件才能达到。如:账号密码不一致时,就需要登录失败,那么此时就得保
证账号正确或密码正确以及账号正确时是存在的。 - 操作步骤:指要达到预期测试结果,需要按这些步骤来。最好说明在什么页面,点击或操作什么内容,输入什么内容。
- 预期结果:说明按照前面写的应该呈现出怎样的结果。
- 测试结果:如果符合预期结果,直接填写正常或OK,如果不符合,则说明不符合或NO,
- 结果描述:如果正常,可以不用填写,如果不符合预期结果,则说明哪里不符合。
- 测试人员:填写测试人的名字,方便后期跟踪BUG。
- 测试日期:填写测试的时间,方便后期查询。
- BUGID:跟测试编号一样,自己设定ID规则,方便快速查询。
- BUG负责人:此处应该有技术那边填写,具体落实到某个人身上,才能更好的解决到问题。
以上就是测试用例的具体填写方法及作用。测试完了之后,记得进行回归测试以确保测试的意义。
如果你对我写的这个感兴趣,那么就期待我的下篇文章吧,下次认真说下非功能性测试怎么弄。
本文由 @光点神奇 原创发布于人人都是产品经理。未经许可,禁止转载。
这是把产品当狗使唤了呗?代码我给研发码好,测试用例写好,原型图出全真的,运营方案也写好,埋点写好,数据分析也做了,其他人领工资不就行了呗
今天研发刚给我说让我写测试用例
这个确实是不该了
不会写测试用例、码代码、设计效果图、设计宣传页、卖东西、做PPT的产品经理不是好产品经理
天呐,太真实了
流程图
图不清楚啊,大佬
如果您具备系统产品知识技能,
有一套体系化的个人项目作品,
您觉得,工作和求职,是否会更加地顺畅?
想体系化学习训练,看公开课点这里: http://996.pm/7GVQ4
A0008-“账号密码不合法验证-账号错误”测试中,预期结果提示有误。系统怎么会判断账号错误呢?系统也不会通过密码来反推账号是否正确。所以,用户端实际操作是“错误账号,正确密码”,而系统判断只有两种情况:1、账号不存在时提示“账号不存在”;2、账号存在时提示“密码错误,登录失败”
他这里是账号不合法密码正确,所以提示的该是“账号格式错误”,而不是“账号错误”,大约作者忽略了这俩字吧
请问一下正常走向产品需要给测试人员什么资料呢?我们公司的测试同事要产品提供测试用例(测试内容,操作,预期效果),感觉工作量堪比需求文档
很多人会吧测试用例写在PRD里面,但是我觉得还是一张表格就差不多了,测试功能项目,前置条件,测试步骤,以及其他的一些日期项目名称,等基本信息,表格可以请你们测试在后期帮你完善,这样你的目的能达到,测试也会把自己的方式帮你丰富表格,一举两得 😐
12345
最近在走测试流程,公司有专业的测试人员,不用产品做测试用例,实际本来也不是产品的工作,通过测试人员的测试,还是发现了不少问题,专业的测试还是不能少的
正好需要,受教,感谢
您好,作者描述的很详细,本人在一家小公司,偶尔会负责到测试的内容,原来正规的测试案例需要描述的如此详细,学习了很多,特别感谢!
有几点小疑问,还请指教。
1.用例A0006中为什么账号正确密码也正确气泡却显示该账号不存在呢?
2.在文中描述的情况下,若账号密码均错误,气泡该如何显示?是显示请输入正确账号,账号不存在还是密码错误呢?
3.测试登录过程中,账号密码输入格式方面是否需要增加如下异常情况的分类:a.账号输入非数字(此处若设置只允许数字输入的限制,且如若账号为手机号设置为首字符为1,可忽略);b.账号和密码输入多位字符数(此处若设置字符数的限制,可忽略);c.密码输入特殊字符是否能照常登录
帐号格式正确,不代表帐号正确吧。
我们没有测试用例 直接手工测试记录bug,测试时能想到什么测什么,业务流程能下来就是OK了
业务流程一般有很多交叉情况,你这样会漏掉很多东西的。
产品是最后要什么都懂,不是什么都干,测试用例都要产品写,想当然也是让产品测,一个产品的专业测试流程走下来是很费时间的,而一个好的测试不仅仅是排除bug也会对产品有积极的建议,公司如果不重视测试可想而知做出来的产品多么粗糙
就一个项目来讲,产品经理是第一梯队,对产品的理解和要求是接近最准确的,越是业务越复杂的,越需要一个优秀的产品经理写出完善的测试用例。
写完用例后,不一定非要产品测,制定者不一定是执行者,可以安排测试人员,按照产品写的用例去执行和完善。
来过,受教,感谢
A007期望结果返回首页应该没有吧
有点像接口的测试哈哈
非常感谢,感觉难点就是要将前置条件考虑全面,没想到一个登录就有这么多测试用例
学习了,非常感谢楼主,点99个赞! 😉
有点小疑惑:用例A0008,账号错误我理解只可能是账号不存在(或是账号格式错误,其实也是不存在),是不是和前面两个case重复了呢。 ➡
给你点个赞,说明你认真看了。这个case是有错误,不过不是你说的错误,应该是输入错误的账号,我写成了输入正确的账号了。
这里的情况是这样的:用户输入错误的账号不代表这个账号就不存在。比如A用户的账号是123,B用户的账号是124。但是用户B把账号输入成:123了。密码正确,这个时候就是这个case了。
这个时候系统应该会判断是A在登录,然后提示密码错误 🙂
我也觉得
😉
期待楼主的下一篇非功能测试
给楼主点个赞!
楼主你好!请教一个问题:你的测试用例表格中,是否还需要一项“输入数据”?
我只想说,产品还要写测试用例的公司~ 还是别干了吧~ 这个都省了~公司很难做起来~ 基本上断定是个 大坑
说的很有道理,但是像这样的公司还有一大堆。并不是每一个公司都有测试专员的。。
我公司就没正经测试,所以做出来的东西非常粗糙,这就是不重视的结果,直接降低了最终产品质量。
➡
想起了我第一家公司,才20几个人的时候就已经招了测试专员……而现在这家……
同感
非常基础的文章
期待下一篇文章
哈哈,我们的测试用例基本差不多哈,我觉得应该考虑一个情况:一个完整的功能性测试的用例需要尽可能的覆盖所有的情况,所以会很长很长,一次测下来费时费力。但是可能由于版本迭代有点快,或者其他原因,不可能每次都测。这时候需要两个维度去测试:1、去测有变动的模块 2、类似冒烟测试,把每个模块的核心环节中的主要场景测一下,发生概率小的或者次要的可以不测。
综上(说了一堆废话,哈哈),我的建议是:给测试用例也分个优先级,重要的必须每次都测,不重要的视情况而定
嗯,是的,这些需要跟实际情况相机处理,除非是大公司,小公司一般都很少天天测全部功能😹😹😹
但我们公司会出现这样的情况,:改了一个bug,其他已经测试通过的功能又出现了bug;所以结果就是改一个bug,就全部要重测一遍
这就是最可怕的状况了。。。