思路|产品新人应如何撰写测试用例(功能性测试)

46 评论 153799 浏览 1078 收藏 7 分钟

如果你在大公司,那么恭喜你,你很幸福。因为你只需要写好产品需求文档就好了。但如果你恰恰在一个创业公司,那么你很可能要担负器撰写测试用例的重担。那么,作为产品新人的你,该如何撰写测试用例呢?

事先声明,本文是给产品新人的一个指导方向,如果你是测试大牛,那更希望你能弄出一篇完整的教程来。

既然你公司没有测试,那么作为产品汪,自然就得担负起产品测试重责。

一、产品测试的意义

一个完整的开发流程。从提需求、开发、交付。这中间都应该有个结果。就如你做一件事,得有个东西来判断你是否已经完成了这件事。那么测试结果就是这个东西了。

一般情况下,在开需求评审会议时同时会把测试需求列明,以确保产品按质量上线。

二、测试文档的结构

一般情况下,测试文档主要分两个部分。即:非功能性测试需求、功能性测试需求。

所谓非功能性测试,主要指APP运行时在各种环境下是否能正常运行,而功能性测试是指每个具体功能是否按要求运行。

作为产品新人,测试文档也不需要太复杂,直接使用excel编撰就可以了,请看下图:

上图是我刚刚编写的,直接写了一个简单的注册登录模块下的账号密码登录部分测试用例。

一般情况下,功能性测试文档直接使用该模板就能满足大部分的需求。

三、具体编写方法

在编写测试用例之前,你得想好有哪些前置条件。这些前置条件满足了才能达到你得预期。比如账号密码登录,前置条件时账号和密码同时正确才能正常登录成功。那么此时你就得编写条件不符的时候,是否也会成功。如果成功了,那就属于BUG,需要技术进行修复。

一般正常情况,请考虑一下几个方面:

  1. 页面布局是否合理,如导航栏上面应该显示三个按钮,实际上却显示了两行。
  2. 页面文字描述是否准确,如气泡提示:密码格式错误,请重新输入。实际上却显示:账号密码错误。
  3. 如果有加载规则,是否符合加载规则。如:进入页面加载20条内容,实际上却加载了10条。
  4. 如果有排列规则,是否符合排列规则。如应按照时间倒序排列,实际上却是正序排列。
  5. 操作是否符合要求,如单击某个点,是否准确跳转或显示内容。如本应该进行跳转,实际上却未进行跳转。
  6. 输入框输入的内容是否有符合格式要求。如:账号不允许”,”,而实际上却允许了。
  7. 输入的内容是否符合合法性要求。如:账号密码是否一致等问题。
  8. ……

这些基本考虑内容都需要考虑进来。

大概理清楚需要考虑的内容之后,就可以开始动手写了。

  1. 序号: 不用说,就是按顺序下去的。
  2. 模块:该功能点具体属于哪个模块的,填写这个主要是方便查找,如:注册/登录模块
  3. 编号:对每个用例进行编号,方便后期跟进。毕竟用文字说,容易口误。不过此处建议编号设计的有点规则,方便快速定位查找。如:A0001。其中A表示注册/登录模块。00表示账号登录,01 表示账号密码登录下的第一个测试用例。
  4. 功能点:具体指某个功能,如:账号登录、首页、发布等。
  5. 子功能点:具体指功能点,如:账号密码登录、手机验证码登录、邮箱登录、第三方授权登录等。
  6. 用例名称:具体测试用例的名称。如:输入账号、输入密码、密码不合规等等。
  7. 前置条件:指要达到预期测试结果,需要满足那些条件才能达到。如:账号密码不一致时,就需要登录失败,那么此时就得保
    证账号正确或密码正确以及账号正确时是存在的。
  8. 操作步骤:指要达到预期测试结果,需要按这些步骤来。最好说明在什么页面,点击或操作什么内容,输入什么内容。
  9. 预期结果:说明按照前面写的应该呈现出怎样的结果。
  10. 测试结果:如果符合预期结果,直接填写正常或OK,如果不符合,则说明不符合或NO,
  11. 结果描述:如果正常,可以不用填写,如果不符合预期结果,则说明哪里不符合。
  12. 测试人员:填写测试人的名字,方便后期跟踪BUG。
  13. 测试日期:填写测试的时间,方便后期查询。
  14. BUGID:跟测试编号一样,自己设定ID规则,方便快速查询。
  15. BUG负责人:此处应该有技术那边填写,具体落实到某个人身上,才能更好的解决到问题。

以上就是测试用例的具体填写方法及作用。测试完了之后,记得进行回归测试以确保测试的意义。

如果你对我写的这个感兴趣,那么就期待我的下篇文章吧,下次认真说下非功能性测试怎么弄。

 

本文由 @光点神奇 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 这是把产品当狗使唤了呗?代码我给研发码好,测试用例写好,原型图出全真的,运营方案也写好,埋点写好,数据分析也做了,其他人领工资不就行了呗

    来自湖北 回复
    1. 今天研发刚给我说让我写测试用例

      来自江苏 回复
    2. 这个确实是不该了

      来自上海 回复
  2. 不会写测试用例、码代码、设计效果图、设计宣传页、卖东西、做PPT的产品经理不是好产品经理

    来自广东 回复
    1. 天呐,太真实了

      来自广东 回复
  3. 流程图

    回复
  4. 图不清楚啊,大佬

    来自辽宁 回复
  5. 如果您具备系统产品知识技能,
    有一套体系化的个人项目作品,
    您觉得,工作和求职,是否会更加地顺畅?

    想体系化学习训练,看公开课点这里: http://996.pm/7GVQ4

    来自广东 回复
  6. A0008-“账号密码不合法验证-账号错误”测试中,预期结果提示有误。系统怎么会判断账号错误呢?系统也不会通过密码来反推账号是否正确。所以,用户端实际操作是“错误账号,正确密码”,而系统判断只有两种情况:1、账号不存在时提示“账号不存在”;2、账号存在时提示“密码错误,登录失败”

    来自北京 回复
    1. 他这里是账号不合法密码正确,所以提示的该是“账号格式错误”,而不是“账号错误”,大约作者忽略了这俩字吧

      来自江苏 回复
  7. 请问一下正常走向产品需要给测试人员什么资料呢?我们公司的测试同事要产品提供测试用例(测试内容,操作,预期效果),感觉工作量堪比需求文档

    来自浙江 回复
    1. 很多人会吧测试用例写在PRD里面,但是我觉得还是一张表格就差不多了,测试功能项目,前置条件,测试步骤,以及其他的一些日期项目名称,等基本信息,表格可以请你们测试在后期帮你完善,这样你的目的能达到,测试也会把自己的方式帮你丰富表格,一举两得 😐

      来自上海 回复
    2. 12345

      来自广东 回复
  8. 最近在走测试流程,公司有专业的测试人员,不用产品做测试用例,实际本来也不是产品的工作,通过测试人员的测试,还是发现了不少问题,专业的测试还是不能少的

    来自北京 回复
  9. 正好需要,受教,感谢

    来自北京 回复
  10. 您好,作者描述的很详细,本人在一家小公司,偶尔会负责到测试的内容,原来正规的测试案例需要描述的如此详细,学习了很多,特别感谢!
    有几点小疑问,还请指教。
    1.用例A0006中为什么账号正确密码也正确气泡却显示该账号不存在呢?
    2.在文中描述的情况下,若账号密码均错误,气泡该如何显示?是显示请输入正确账号,账号不存在还是密码错误呢?
    3.测试登录过程中,账号密码输入格式方面是否需要增加如下异常情况的分类:a.账号输入非数字(此处若设置只允许数字输入的限制,且如若账号为手机号设置为首字符为1,可忽略);b.账号和密码输入多位字符数(此处若设置字符数的限制,可忽略);c.密码输入特殊字符是否能照常登录

    来自湖北 回复
    1. 帐号格式正确,不代表帐号正确吧。

      来自北京 回复
  11. 我们没有测试用例 直接手工测试记录bug,测试时能想到什么测什么,业务流程能下来就是OK了

    回复
    1. 业务流程一般有很多交叉情况,你这样会漏掉很多东西的。

      来自香港 回复
  12. 产品是最后要什么都懂,不是什么都干,测试用例都要产品写,想当然也是让产品测,一个产品的专业测试流程走下来是很费时间的,而一个好的测试不仅仅是排除bug也会对产品有积极的建议,公司如果不重视测试可想而知做出来的产品多么粗糙

    来自广东 回复
    1. 就一个项目来讲,产品经理是第一梯队,对产品的理解和要求是接近最准确的,越是业务越复杂的,越需要一个优秀的产品经理写出完善的测试用例。

      来自北京 回复
    2. 写完用例后,不一定非要产品测,制定者不一定是执行者,可以安排测试人员,按照产品写的用例去执行和完善。

      来自北京 回复
  13. 来过,受教,感谢

    来自浙江 回复
  14. A007期望结果返回首页应该没有吧

    来自广东 回复
  15. 有点像接口的测试哈哈

    来自广东 回复
  16. 非常感谢,感觉难点就是要将前置条件考虑全面,没想到一个登录就有这么多测试用例

    来自湖北 回复
  17. 学习了,非常感谢楼主,点99个赞! 😉
    有点小疑惑:用例A0008,账号错误我理解只可能是账号不存在(或是账号格式错误,其实也是不存在),是不是和前面两个case重复了呢。 ➡

    来自北京 回复
    1. 给你点个赞,说明你认真看了。这个case是有错误,不过不是你说的错误,应该是输入错误的账号,我写成了输入正确的账号了。
      这里的情况是这样的:用户输入错误的账号不代表这个账号就不存在。比如A用户的账号是123,B用户的账号是124。但是用户B把账号输入成:123了。密码正确,这个时候就是这个case了。

      来自广东 回复
    2. 这个时候系统应该会判断是A在登录,然后提示密码错误 🙂

      来自上海 回复
    3. 我也觉得

      来自福建 回复
  18. 😉

    来自北京 回复
  19. 期待楼主的下一篇非功能测试

    来自山东 回复
  20. 给楼主点个赞!

    来自辽宁 回复
  21. 楼主你好!请教一个问题:你的测试用例表格中,是否还需要一项“输入数据”?

    来自北京 回复
  22. 我只想说,产品还要写测试用例的公司~ 还是别干了吧~ 这个都省了~公司很难做起来~ 基本上断定是个 大坑

    来自广东 回复
    1. 说的很有道理,但是像这样的公司还有一大堆。并不是每一个公司都有测试专员的。。

      来自福建 回复
    2. 我公司就没正经测试,所以做出来的东西非常粗糙,这就是不重视的结果,直接降低了最终产品质量。

      来自广东 回复
    3. 来自福建 回复
    4. 想起了我第一家公司,才20几个人的时候就已经招了测试专员……而现在这家……

      来自广东 回复
    5. 同感

      来自上海 回复
  23. 非常基础的文章

    来自四川 回复
  24. 期待下一篇文章

    来自广东 回复
  25. 哈哈,我们的测试用例基本差不多哈,我觉得应该考虑一个情况:一个完整的功能性测试的用例需要尽可能的覆盖所有的情况,所以会很长很长,一次测下来费时费力。但是可能由于版本迭代有点快,或者其他原因,不可能每次都测。这时候需要两个维度去测试:1、去测有变动的模块 2、类似冒烟测试,把每个模块的核心环节中的主要场景测一下,发生概率小的或者次要的可以不测。

    综上(说了一堆废话,哈哈),我的建议是:给测试用例也分个优先级,重要的必须每次都测,不重要的视情况而定

    来自广东 回复
    1. 嗯,是的,这些需要跟实际情况相机处理,除非是大公司,小公司一般都很少天天测全部功能😹😹😹

      回复
    2. 但我们公司会出现这样的情况,:改了一个bug,其他已经测试通过的功能又出现了bug;所以结果就是改一个bug,就全部要重测一遍

      来自上海 回复
    3. 这就是最可怕的状况了。。。

      来自山东 回复