微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

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

来源: 2265
爱盈利(aiyingli.com)移动互联网最具影响力的盈利指导网站。定位于服务移动互联网创业者,移动盈利指导。我们的目标是让盈利目标清晰可见!降低门槛,让缺乏经验、资金有限的个人和团队获得经验和机会,提高热情,激发产品。

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

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

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

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

一、产品测试的意义

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

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

二、测试文档的结构

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

所谓非功能性测试,主要指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运营推广经验、策略、全案、渠道等纯干货知识内容;是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台;

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3083 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号