精华内容
下载资源
问答
  • 测试用例设计思路

    2021-08-27 22:34:50
    测试用例编写思路: 首先是明确测试范围: 功能测试 界面测试(界面友好性、易用性、一致性) 兼容性测试(不同类型、型号手机、系统(手机系统、桌面系统)、分辨率、浏览器及其版本) 性能测试(页面加载时间...

    测试用例编写思路:

    首先是明确测试范围:

    接口测试

    功能测试

    界面测试(界面友好性、易用性、一致性)

    兼容性测试(不同类型、型号手机、系统(手机系统、桌面系统)、分辨率、浏览器及其版本)

    性能测试(页面加载时间(1万条记录)、响应时间、内存占用)

    安全测试(漏洞扫描、链接安全等)

    稳定性测试(长时间给予压力:80%内存占用)

    可靠性测试(断电、断网、高内存、低网速)

    功能模块中明确测试范围::

    1、划分功能模块

    2、正向功能验证:正常功能是否实现

    3、单个功能项验证:正向+异常

    4、功能之间交互验证:模块之间的数据传递

    5、隐形需求:熟悉业务

    如:

    2.1 web登录页面的测试

             分析:首先我们可以分析一下,该界面都有哪些哪些元素,每个元素又具备哪些规则要求,是否有其他特殊化要求,比如缓存,加密等;分析完毕后,我们就可以根据了解到的去选择合适的测试用例设计方法,对这个页面进行用例的编写。

    2.1.0 UI界面测试

           首先对于用户来说,对一个系统的评价,首先从界面视觉方面去判断,就好比男女之间的第一次见面,嗯,你想的没错,就是相亲,第一印象基本上是从个人长相,精神面貌来的,我们都知道第一印象很重要,尤其是在如今这个快节奏的社会;

           对于一个用户来说,界面的风格,人机交互性,易理解性,易操作性等将直接印象用户的第一使用体验,假如第一使用体验都不好了的话,假如该产品不是不可替代性的产品的话,用户很有可能就此流失掉,假如该系统是用户已经付费了的,虽然不好看的页面,难于操作的页面,难于理解的页面不会马上导致客户退货,但起码会使该用户产生一种一点都不专业的感觉,接下来用户很可能带着一种不愉快的心情去操作了,这就很有可能导致各种各样的刁难挑刺,最终导致彻底对该产品失去兴趣,要不就是打回要求重新调整,要不就是退回退款。

          大部分产品开发过程中,在前期需求确定及评审过程中就会这方面进行一定讨论研究,所以建议测试同学在需求阶段就要介入进去,从界面风格,人机交互性,易理解性,易操作性等几方面去进行审视,给出比较不错的建议。

           根据一般的测试套路,我们先是进行基本的功能测试,只有基本的功能实现了,我们才有意义去进行其他方面的测试。

    备注:扫一扫登录页面由于过于简单就不在此进行阐释了

    2.1.1功能测试

            结合我们所掌握到该页面的相关需求知识以及我们后期拓展到的隐性需求(最好在需求阶段就提出来),提炼出我们所需要的测试点,然后再结合我们所掌握的测试用例设计方法进行测试用例的编写。

    以下就是提炼出的测试点:

                       1.输入框的空值登录

                       2.输入框的空格测试

                               a.账号密码输入框前后中间有空格是否有过滤处理处理

                       3.有效账号密码等信息登录

                       4.无效账号密码信息登录

                                     a.正确账号,错误密码

                                     b.不存在的账号,A账号的密码

                                     c. A账号,B账号的密码

                      5.密码特殊要求测试 

                                    a.在输入框内是否密文展示

                                    b.是否可从外部复制到输入框

                                    c.是否可从密码输入框复制密码出去

                                    d.密码防破解机制验证

                                    e.密码在传输过程中及日志信息中是否做了加密处理

                                    f.密码在数据库表中是否以加密形式保存

                                    g.密码信息是否会被浏览器所记住并保存  

                        6.验证码测试

                                    a.输入正确的验证码登录

                                    b.验证码输入框置空登录

                                    c.输入错误的验证码登录

                                    e.输入过时的验证码登录

                                    f.图片刷新机制是否合理

                         7.账号密码记忆保存测试

                                    a.正确账号密码登录成功后记忆保存

                                    b.正确账号错误密码登录失败后是否只保存账号信息

                                    c. 错误账号登录错误密码登录失败是否会保存

                                    d. 正确账号,密码置空登录,是否会保存账号信息

                                    f. 记忆保存有效时间验证

                                    g. 手动清除缓存是是否仍然保留登录信息

                        8.同时登录测试

                                    a.一个账号能否在同一浏览器上同时登录

                                    b.一个账号能否在同一台机器上不同浏览器同时登录

                                    c.一个账号能否在不同机器上同时登录

                                    d.一个账号能否在web端和移动app端同时登录

                                   e.二个账号能否在同一浏览器上同时登录

                                   f.二个账号能否在同一台机器上不同浏览器同时登录

                       9.默认语言的记忆测试

                                  a.修改界面语言选项,成功登陆后,下次登录是否会记忆上次保存的语言

                                  b.修改界面语言选项,登录失败后,当前页面是否会保存修改的语言

                                  c.修改界面语言选项,登录失败后,关闭浏览器,下次打开登录是否保存上次的语言选项

                       10.输入框长度限制测试

                       11.输入框可输入类型测试

                       12.输入框的大小写是否敏感

    2.1.2 友好及易操作性测试

         1.在输入框内能否使用windows常用快捷键,比如复制粘贴,tab切换,回车等

         2.在输入框内能否切换大小写,输入法,且切换后是否有相应提示

         3.网络异常时,是否有友好加载页面提示

         4.各种登录失败情况下的提示是否友好,清晰,易懂。

    2.1.3 健壮性测试

          1.对浏览器程序进程杀死,重新打开浏览器,已输入的登录信息是否还在

          2.登录页面与其他页面页签之间的切换以及缩小到后台,已输入的登录信息是否还在

          3.假如快速多次点击登录按钮界面是否仍然正常显示及提示

          4.假如快速进行多次刷新操作,界面是否仍然显

    2.1.4 安全测试

          1.账号密码框是否屏蔽SQL注入攻击

          2.账号密码输入框是否禁止脚本输入(避免XSS攻击)

          3.登录是否有防破解机制

          4.密码的缓存信息是保存在cookies中还是session中

          5.密码在任何场所是否都是加密形式展示的

          6.密码是否具有有效期,有效期到快到或者到期后,是否需要提示修改密码

          7.不登录的情况下,直接输入登陆后的url访问,重定向到用户登录页面

          8.密码输入框是否支持复制粘贴

          9.密码输入框输入的密码是否可以在页面源码模式下被查看

         10.同一用户在同一终端的多种浏览器上登录,验证登录功能的互斥性是否符合设计预期

         11.同一用户先后在多台终端的浏览器上登录,验证登录是否具有互斥性

    2.1.5 性能测试

          1.单用户打开登录页面及登录所花的时间是否满足要求

          2.点击登录按钮进入到登录成功后的页面所花时间是否满足要求

          3.支持多少人同时正常打开,同时正常登录操作

          4.单用户登录时,后台请求数量是否过多

          5.高并发场景下用户登录的响应时间是否小于规定值

          6.高并发场景下服务端的监控指标是否符合预期

          7.高集合点并发场景下,是否存在资源死锁和不合理的资源等待

          8.长时间大量用户连续登录和登出,服务器端是否存在内存泄漏。

    2.1.6 兼容性测试

          1.主流的浏览器及各版本,是否很好的兼容该页面

          2.不同的操作平台及各版本是否正常使用

          3.不同屏幕分配率是否合理的显示该页面

         4.放大缩小状态下界面显示是否正常

    2.2 一个水杯的测试(以喝水的杯子为准)

            以此例子来说明,一般我们的测试思路可以怎么展开,其实和上个例子一样的思路,再举例说下这个例子,是用来说明作为测试同学来说,具备很强的逻辑归纳能力,很强的发散思维能力,及很强的产品用户思维能力是很重要的。

    2.2.1 UI界面测试

          1.整体形状外观是否符合用户审美观

          2.杯身图案是否符合用户需求,是否涉及到民族,伦理道德,商业侵权等会引起纠纷的标识

    2.2.2功能测试

          1.能否正常装水

          2.能否正常喝水

    2.2.3 易用性测试

          1.杯子是否容易装水

          2.杯子是否容易出水

          3.杯子是否很方便的拿放(体积质量是否合理)

    2.2.4 健壮性测试

          1.当水装过满的时候,是否有预防水漫出的机制

         2.当水喝的几乎没有的时候,剩下的一点点水是否能够顺利的喝到

         3.当水杯不小心打翻时候,是否很好的避免水流出

         4.当用户手湿滑时候,是否也能够顺利拿起放下杯子

    2.2.5 安全测试

          1. 制作杯子的材料是否会对用户造成损害

          2. 当杯子不小心打碎的时候,碎片是否会伤害到用户

          3. 当装的水过热或者过冷的时候,是否会对用户造成伤害

          4. 当杯子由于外部原因被加热过或者被冰冻过,是否会对用户造成伤害

          5. 当杯子长时间装水状态下,是否会滋生细菌或产生危害到用户的事务

          6. 当杯口以及杯身出现裂痕的时候,是否会对用户造成割伤

          7. 当杯子放进微波炉时,杯子是否会发生爆炸或融化

    2.2.6 性能测试

          1. 杯子在长时间震动下是否会破碎

          2. 杯子在长时间装水状态下是否发生漏水

          3. 当用户使用杯子时用力过猛情况下,杯子是否会破碎

          4. 当杯子不小心摔下的时候,是否会发生破碎变形现象

          5. 当杯子装入过热或过冷的水时,杯子是否会发生破裂等事故

          7. 当杯子用久了,杯身是否会掉色,杯体是否会发生变形,褪色等

    2.2.7 兼容性测试

          1. 杯子除了装水外,是否还能装其他液体。

          2. 杯子除了装液体外,是否还能装固体

          3. 杯子是否能液体和固定的混合物

          4. 杯子是否可以在一些特殊场合使用

    参考自:https://www.cnblogs.com/Aaron-007/p/10697277.html

    展开全文
  • 大转盘活动测试用例设计 题目:2019年双11公司内部员可参与抽奖,每人每天可参与一次抽奖,好友助力,最多额外获得3次机会。 思路: 一、功能验证,所有的功能点是否符合需求设计,比如 1)身份验证:未登录时点击...

    大转盘活动测试用例设计
    题目:2019年双11公司内部员可参与抽奖,每人每天可参与一次抽奖,好友助力,最多额外获得3次机会。

    思路:
    **一、功能验证,**所有的功能点是否符合需求设计,比如
    1)身份验证:未登录时点击抽奖,是否跳转至登录页面,公司员工登录后是否可以正常抽奖,非海尔员工登录是否可以参与抽奖,如果限制住了不可以,是否有合理提示等
    2)抽奖功能:点击转盘是否正常转动,抽完奖后抽奖次数是否-1
    3)结果公示:抽奖结果是否会进入到中奖公示中轮播展示
    4)分享:是否会调起分享控件,以及分享支持哪些平台,分享到各个平台是否成功,是否支持复制链接,到浏览器是否能正常打开抽奖页面等等
    5)分享得机会:邀请好友助力后,抽奖机会是否会+1,邀请4人助力,抽奖机会是否最多+3
    6)查看活动规则:点击是否跳转至目标页面及文案是否正确
    7) 中奖概率验证:若概率是万分之一,如果在前10名抽奖的人员中已经产生了一等奖,如果保证后面抽奖的人员不在中一等奖的问题等。

    **二、UI验证,**验证UI是否与UI设计一致,比如
    1) 页面整体,是否有被切掉的地方,如顶部导航栏左右侧的返回或者分享按钮展示是否被切掉,页面中间的元素,比如button啊这些是否按照原设计图实现等等

    三、兼容性验证
    1)如果是app端,考虑手机机型、同一机型不同系统的适配问题;考虑不同系统,如安卓系统、鸿蒙系统和ios系统的适配等;

    题外小tip:可展开举个小例子,如安卓系统的应用市场一般会默认开启【安装和更新】的自动更新功能,这个功能对测试人员的影响在于,若测试机安装了测试包,应用市场会自动的把测试包更新为线上的最新安装包,影响测试,我们可以在应用市场把改自动更新功能关掉,这个小烦恼就解决了,以华为手机举例,路径为:应用市场->我的->设置->安装和更新->自动更新应用->关闭。
    2)如果是web端,考虑不同浏览器的适配,如chorm,火狐,360,UC等等;
    3)web端还要考虑下分辨率对页面适配的影响;

    四、性能方面验证,如压力测试
    1)可以压一下该url能够承受的最大压力是多少,是否符合需求。具体可以借用jmeter展开将一下压测配置和结果分析

    五、安全性验证
    1)对身份的验证,内部员工和非内部员工
    2)对可抽奖次数的验证,1次和最多3次
    3)对登录用户token的有效期验证

    六、弱网测试
    1)网络环境差的情况下,打开大转盘页面,是否能正常打开,或者在弱网下页面加载的策略是什么?(比如有些页面只加载骨架屏)或者是否给出了合理的提示?(您目前的网络状况不佳,请稍后再试,或者其他一些合理提示等)
    2)如何模拟弱网?可以用fiddler来设置。路径:rules-performance-simulate modem speeds,打开后抓取要测试的url,选中rul查看右侧的statistics的数据

    七、易用性测试
    一些提示是否合理易懂,比如抽奖次数用完后,用户再次抽奖给出的提示对用户来说是否通俗易懂且不失优雅,哈哈~

    展开全文
  • 文章目录1)什么是测试用例?1.1 测试用例的定义测试用例的内容:*为什么需要测试用例?...*如果没有需求文档,怎么设计测试用例?2.2 提取测试点【举例】对PC端QQ账号的登录模块,提取测试点:【举例】对



    1)什么是测试用例?

    1.1 测试用例的定义

    测试用例是对一项特定的软件产品进行测试任务的描述指定输入,预期结果和一组测试项的执行条件的文档。

    • 它是测试工作的核心、是一组在测试时输入输出的标准、是软件需求的具体对照。
    • 体现了测试方案、方法、技术和策略。
    • 测试用例的内容:

      内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。具体有:
      • 用例编号、用例名称
      • 测试背景
      • 前置条件
      • 优先级、重要级
      • 测试数据
      • 测试步骤
      • 预期结果、实际结果
      • 备注等

    *为什么需要测试用例?

    测试用例的作用:

    • 检验软件是否满足客户需求
    • 体现一个测试人员的工作量
    • 展现测试用例的设计思路
    • 测试用例是测试人员在测试过程中的重要参考依据

    • 测试用例可以帮助实施有效的测试,所有被执行的测试都是有意义的,不执行毫无意义的测试操作。

    • 测试用例是一个知识传递的过程,能保持一致、稳定的测试质量

    • 从项目管理的角度来说,测试用例的通过率是检验代码质量最主要的指标之一

    • 测试用例也可以作为评估测试人员进度、工作量以及跟踪/管理测试的工作效率的主要因素,从而更加合理地做出测试安排或调整。

    • 良好的测试用例不断地被重复使用,使得测试过程事半功倍。
      • 在软件产品的开发过程中,开发人员不断的推出新的版本,测试人员需要对原有功能进行多次的回归测试,即使在一个版本中,也要进行 2~3次的回归测试。这些回归测试,就要求能重复使用测试用例
    • 如果没有测试用例,很可能到执行的时候测试点就遗漏了,另外也不便于用例评审,用例总结,对后期测试工作没大的改进作用。
      • 所以测试用例一定要写,颗粒度视情况而定。针对测试人员少,上线时间紧的项目,可只做思维导图列出测试点。

    1.2 测试用例的元素

    测试用例必须给出测试测试目标、测试对象、测试环境要求、输入数据和操作步骤,即 5W1H。

    • 测试目标(Why):

      为什么而测?功能、性能、可用性、容错性、兼容性、安全性等。
    • 测试对象(What):

      测什么?被测试的项目,如对象、函数、类、菜单、按钮、表格、接口、整个系统等。
    • 测试环境(Where):

      在哪里测?测试用例运行时所处的环境,包括系统的配置和设定等要求,也包括操作系统、浏览器、通讯协议等单机或网络环境。
    • 测试前提(When):

      什么时候可测?测试用例运行时所处的前提或条件限制。
    • 输入数据(Which):

      哪些数据?在操作时,系统所接受的各种可变化的数据,如数字、字符、文件等。
    • 操作步骤(How):

      如何测?执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。

    2)测试用例的编写流程

    主要分为以下四步:

    需求分析 -> 提取测试点 -> 测试用例编写 -> 测试用例评审

    2.1 需求分析

    如果直接去测试,会发现有很多需求理解的偏差,测试过程中会发现自己理解的需求跟开发实际做出来的功能不一致。

    所以拿到需求后:

    1、过需求文档:

    • 先自己过一遍需求文档,标出不理解或者可能会有争议的地方。
    • 可以借鉴一下同类产品类似的功能是怎样处理的,这样更有助于理解需求。
    • 针对有疑义的地方与产品经理和开发人员一起讨论,尽量减少大家对需求理解上的误差。

    2、根据需求文档,拆分测试点。

    • 需求的种类:

      • 业务需求:关注系统是否满足业务要求。
      • 用户需求:关注系统是否满足用户习惯。
      • 功能需求:关注系统是否满足功能要求。

    *什么是产品需求文档?

    产品需求文档就是产品功能说明书,包含大量的功能细节,目的是提高沟通效率,避免研发过程出现误会。

    产品需求文档是将商业需求文档(BRD)和市场需求文档(MRD)用更加专业的语言进行描述。

    在这里插入图片描述

    • 需求背景与目标说明:让别人知道为什么要做,要做到什么程度,用户检验功能完成情况。
    • 特性列表:所谓特性其实就是功能模块,把需要做的功能模块都罗列出来,主要用于明确需要做的功能有哪些,用图表体现更佳。
    • 主要逻辑:每个特性之下的操作逻辑,简单特性可以文字说明,复杂特性建议用流程图表现。
    • 特性功能点:补充每个功能点的相关细节描述,是开发,与测试工作的重要依据。包括:
      • 流程细节描述
      • 正常逻辑表现,异常逻辑表现
      • 文案内容,性能需求
      • 交互图(可无)
    • 特性需求,性能需求,数据上报:这一部分类似备注,说明了做这个功能要达到怎样的程度,需要再哪些地方进行数据埋点。

    *什么是交互需求文档?

    交互需求文档是给交互设计师看的文档,应该在需求文档之外单独呈现,主要目的是让交互设计师理解产品的交互需求。

    • 交互需求文档主要是对功能的交互设计,包含功能列表,每个功能的交互要点说明,包含元素等等。

    *如果没有需求文档,怎么设计测试用例?

    • 查找其他相关文档,来帮助理解所要测试的产品需要完成的目标。
    • 尽量多参加项目组内的会议,比如需求讨论、设计讨论、计划讨论等,能够加深对产品的理解。
    • 咨询相关人员:项目负责人、市场人员。
    • 如果是一款已经上线的产品,可以多使用产品,有不懂的问产品经理。
    • 可以去看历史bug,了解到一些需要关注的东西。

    2.2 提取测试点

    对各个功能模块进行测试点分析,提取测试点,再对测试点进行用例编写。

    • 测试点:通过需求分析后,对得出的需求进行测试的具体内容。

    【举例】对PC端QQ账号的登录模块,提取测试点:

    在这里插入图片描述

    • 登录:
      • 正常登陆
      • 账号为空时点击登录
      • 密码为空时点击登录
      • 账号密码都为空时点击登录
      • 密码错误时点击登录
    • 记住密码功能是否有效
    • 自动登录功能是否有效
    • 找回密码功能是否有效
    • 注册账号能否正确跳转

    【举例】对CSDN的web端登录界面,提取测试点:

    在这里插入图片描述

    • 登录:
      • 正常登录
      • 账号为空时点击登录
      • 密码为空时点击登录
      • 账号密码都为空时点击登录
      • 密码错误时点击登录
    • 判断输入的手机号或者邮箱是否符合规范
    • 判断输入的账号是否存在
    • 下次自动登录按钮是否生效
    • 忘记密码按钮是否生效
    • 第三方登录是否有效
    • 注册账号按钮是否生效

    2.3 测试用例的编写

    2.3.1 编写测试用例该注意什么?

    • 根据项目的实际情况设计测试用例表格
    • 用例格式不要生搬硬套
    • 根据具体情况进行编写
    • 小技巧:
      • 把测试管理工具中的缺陷全部分类导出,总结一下哪些模块容易产生哪些缺陷,重点看一下自己没发现或没有考虑到的缺陷。
      • 把测试管理工具中的用例详细看几遍,学习别人的用例编写方法和思想。
    • 测试用例的模板:

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

    2.3.2 测试用例的写作

    • 用例编号/ 序号

      • 应该简单且唯一

    • 用例说明(检查点)

      • 也称测试点、检查点、测试概述、用例概述、测试说明。
      • 用一句话对测试用例进行概述,最好看到这句话就能知道如何测试。
      • 可以总结测试目的,可以用“检查、验证、测试”等字眼(如验证 QQ 默认安装)。
      • 用例执行多轮时,越往后执行可能越快,如果用例写得好,直接看概述就行。

    • 初始条件

      • 也称预置条件、前提条件。
      • 初始条件是第一步操作步骤之前的状态,不能太远,不用从头写到尾。
      • 初始条件要是一个状态,而且是静态的,如管理员已登录后台。
      • 很多项目中不写预置条件。

    • 操作步骤

      • 步骤要都有序号。
      • 每一步用分号分开,最后用一个句号。每一步必须换行。
      • 参数前加冒号(如用户名:admin)。涉及按钮界面用【】、“”等成对符号间隔。
      • 功能的详细用例步骤 4-6 步左右。
      • 若对数据要求高,需要把数据分离出来。

    • 预期结果

      • 是一个状态。
      • 如果参考文档中有描述,原封不动的抄过来。
      • 如果文档中没有具体要求,则点要一致,可以有几个点,如 QQ 默认安装,应能启动、默认选项匹配等。

    • 用例状态

      • 通过、失败、阻塞、未执行、搁置、无效用例等。
      • 初始条件达不到时,一般用例状态设置为阻塞。
      • 看如何执行用例,执行完关心什么来定。

    • 优先级

      • 用例的执行顺序。

    *举例:

    在这里插入图片描述

    2.4 测试用例的评审

    评审就是对测试用例进行检查。用例编写完成后,要组织人员进行用例的评审。

    • 评审包括:同行评审、小组评审、部门评审和第三方评审等。
    • 参与人员:包括需求人员(如产品经理)、测试人员、开发人员等。
    • 评审流程:评审后改进测试用例,再进行评审再改进测试用例,这样一直循环直到评审都通过,这时候才结束评审,也标志着测试用例编写的完成。

    *为什么要进行用例的评审?

    测试用例包含了功能的边边角角,我们不能保证能把所有的测试点都列出来,也不能保证我们所列出来的测试点方向都是正确的,那么就需要其他人来查缺补漏、纠正错误,看一下有没有我们漏掉的点,看一下我们用例的方向是否正确,防止对需求的理解错误。

    • 通过评审发现用例的不足
    • 方便测试人员改进用例
    • 提高测试质量

    2.4.1 测试用例评审要点

    • 根据检查单或检查表(Check List)进行评审。
    • 用例“文字校对”:错别字、病句、语句不通顺、含义不清晰、语句有歧义、格式不一致、标点不一致、中英文混合等。
    • 用例质量:遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例等。
    • 确定用例的优先级。
    • 规划服务器和客户机。
    • 用例的分工执行与人员安排。
    • 记录评审过程,记录测试环境规划。

    2.4.2 测试用例的维护

    • 为什么需要更新测试用例?

      • 先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究,对某些功能、特性、逻辑等的理解越来越清楚、深刻。
      • 所发现的严重的软件缺陷没有被目前的测试用例所覆盖
      • 新的版本中有新功能的需求或者原有功能的增强而需要发生改动。
      • 编写的测试用例不规范或者语句错误。
      • 旧的测试用例已经不再适用,需要删除。
    • 常见的测试用例管理工具

      • 原始的Excel管理
      • TestLink: 免费开源可扩展性高,可以和bugzilla等缺陷管理工具的整合,适合中小型项目的管理。
      • ZenTao(禅道):免费开源,不过定制能力不足,不好用层级结构管理用例。
      • Bugzilla、ALM等,更详细的可以参考:有哪些比较好的测试用例管理工具?(https://www.zhihu.com/question/26898212)

    3)编写测试用例的方法

    常见的方法有等价类划分法、边界值分析法、功能图法、错误推测法、因果图法、场景法等。

    具体可参考本栏目的《【测试】编写测试用例的常用方法》。(https://blog.csdn.net/m0_37621024/article/details/116860859)



    【部分内容参考自】

    • 测试开发之编写测试用例:https://bqleng.blog.csdn.net/article/details/105284818
    • 一份优秀的需求文档:https://www.pianshen.com/article/8729120291/
    • 编写测试用例及一个例子:http://www.51testing.com/html/24/n-3727424.html
    • 测试开发之编写测试用例:https://bqleng.blog.csdn.net/article/details/105284818
    展开全文
  • 在开始设计测试用例前,需要了解项目产品需求,只有对需求深入了解后,才能进一步进行测试用例设计。 (1)水杯有很多,有瓷水杯,纸杯,保温杯,不绣钢杯等,水杯具体需求是哪种杯子?下面以测试【纸杯】为例。 ...

    生完二胎一段时间了,离重新步入职场,要开始拾起知识丰富自己。

    经常面试题1---测试水杯,设计测试用例

    在开始设计测试用例前,需要了解项目产品需求,只有对需求深入了解后,才能进一步进行测试用例设计。

    (1)水杯有很多,有瓷水杯,纸杯,保温杯,不绣钢杯等,水杯具体需求是哪种杯子?下面以测试【纸杯】为例。

    (2)水杯具有的特性要求:  

    • 杯子的容量:要求最大能装多少升水(满杯),空杯,半杯
    • 杯子的型状:圆型,上面口大,下面小。  
    • 杯子的材料:纸杯                                                                                                                       
    • 杯子的耐温性:装冷水,冰水,热水  
    • 杯子的抗摔能力:风吹是否会倒,摔一次是否会摔坏,摔多次是否会摔坏;装一次水,装二次水,装三次水,装多少次水是否会纸化掉无法使用

    思路:从测试类型的入手,根据不同的测试类型来针对性进行设计用例

    ---------功能测试--------

    水杯功能:主要盛水

    (1)是否会漏水

    (2)能否加热,冷藏

    --------易用性测试------------

    (1)是否可方便手握

    (2)是否方便倒水

    ---------性能测试---------:

    (1)装满水后,放置2小时、4小时、24小时......

    (2)装半杯水1次、装半杯水2次、装半杯水3次、装半杯水4次.......

    ----------安全性测试---------- :

    (1)使用材料是否符合食品安全要求

    (2)作为垃圾后是否会污染环境

    (3)装不同的液体是否安全,是否会与纸杯材料有化学反应(可乐、牛奶、咖啡、啤酒等)

    (4)装热水后杯子会不会变型和有异味

    ----------兼容性测试------------:

    兼容不同的饮料:

    (1)装热水

    (2)装冷水

    (3)装饮料

    兼容不同的人群:

    不同人群:老人、小孩、年轻人是否适合杯子的形状:手握是否方便、喝水是否方便

    不同人群是否能接受杯子上图案和文字 

    -----------UI测试---------------:

    (1)纸杯颜色

    (2)纸杯形状

    (3)纸杯上图像设计是否合理、是否可损坏

    (4)纸杯上文字设计是否合理、是否可损坏

    (5)纸杯高度&宽度

    其他类似好的文章

    纸杯测试用例_yichen_panda的博客-CSDN博客_纸杯的测试用例冒烟测试:杯子是否能盛水功能测试:1.能否盛水,能否喝水2.能否加热,冷藏性能测试:1.杯子的容量是多少2.能否盛开水,冰水3.能承受多高温度的水,多低温度的水4.长时间放置是否容易渗水5.是否容易变形,掉色,保温6.杯底是否容易脱落界面测试:1.界面是否美观2.杯口杯壁是否圆整兼容性测试:1.是否可以盛放酒精,碳酸饮料,牛奶等其他液体,固体压力测试:1.使用多大...https://blog.csdn.net/yichen_panda/article/details/102956680一个纸杯的测试用例 - Lewisky - 博客园一个带广告图案的花纸杯,我们能想出多少个测试用例呢?想必很多人都在网上看过微软公司口试软件测试职位的这个考试题,由于当时对软件测试理论和测试用例的设计知之甚少,看到这个题目的时候不知所措,我试着以开发https://www.cnblogs.com/lewisky/p/5086969.html

    展开全文
  • 我这次讨论的不是针对一个软件的测试用例设计,而是针对一个模块或多个模块用例的设计。今天我要写的主要是我自己在工作中所用的一些方法,当然不是最好用的。但我一直在研究最高效,最实用的方法。首先我们要了解...
  • 一、前言作为移动互联网产品『最后一公里的守护者』,我们必须要清楚的知道自己该做什么、怎么做。但从版本迭代速度、需求量级、测试人员不断变动等方面综合来看,我们...二、提高测试用例质量测试用例的存在,能对...
  • #接口测试案例设计思路 #app测试案例设计思路 转自:https://blog.csdn.net/nikita1995/article/details/82494416
  • 测试用例思路分析

    2021-03-23 20:37:26
    作为新手入门,很多同学最顾虑的问题相信都是不知道如何开始书写测试用例,担心测试用例书写的不全面,不完整,生怕漏下的某一点非常重要,造成了自己在接下来的测试工作中存在隐患; 但迟迟不敢下手写测试用例的话...
  • 接口测试用例设计 - 实战篇

    千次阅读 2021-03-14 15:10:22
    目录 一.接口测试流程 二.分析接口文档中哪些元素 三....四....五....六.接口测试的设计思路分析 ...七....八....8.2 接口测试用例设计 8.3 个人对接口的认知 一.接口测试流程 1.需求讨论 2.需求评审 3.场...
  • 零,所有待测接口都要覆盖 一,参数覆盖(所有、...n个必填参数,就需要设计n个用例 预期:业务失败,报错,并有提示信息 必填参数的个数(冗余与缺失,逆向,1+n):。 接口需要机制去判断:如果参数多了或者少了
  • 接口测试简介 1.什么是接口 接口就是内部模块对模块,外部系统对其他服务提供的一种可调用或者连接的能力的标准,就好比usb接口,他是系统向外接提供的一种用于物理数据传输的一个接口,当然仅仅是一个接口是不能...
  • 设计一系列测试用例用以测试这个Web页面。 有经验的测试人员可能会问面试官,字母a区分大小写吗?只统计英文字母的a吗?最长输入字符是多少,最少输入字符是多少?对输入的字符类型是否有限制,是否会自动清除...
  • 为什么要做好测试用例设计?2.好的测试用例设计的共性?3. 移动端测试设计—面向问题发现的测试全面性组织方式3.1 基本功能测试3.2 边界分析测试3.3 存储测试3.4 性能测试3.5 压力测试3.6 兼容性测试3.7 中断功能...
  • 在编写测试用例的时候,我们往往拿到需求就开始各种编写,无效的用例编写导致我们每天都很疲惫的在工作。所以思路清晰、准确、清晰、简洁、完整、一致是编写用例的着重点。系统中的模块基本上都是增删改查,针对这些...
  • (当然什么时候测)测什么的问题由接口清单来解决,而怎么测的问题由测试用例设计和用工具执行测试用例来解决。有关于接口清单和用工具执行测试用例,我们已经在下面的这篇文章中介绍过了,这篇文章来介绍一下测试...
  • 功能测试_测试用例设计方法

    千次阅读 2021-01-21 16:09:17
    该方法是一种重要的,常用的黑盒测试用例设计方法。 2.划分等价类: 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就
  • 缺点:费时费力(往往设计测试用例的时间比执行测试用例的时间还长) 测试用例必备的因素: 编号、模块名称、用例名称、预置条件、操作步骤、输入数据、预期结果 软件的测试用例是什么? 它就是包含 测试...
  • 从接口测试目的出发,详细分享接口测试用例设计思路。最后以最常用的增删改查接口为实例分享接口测试用例设计全过程。
  • 下面我来分享下银行测试用例设计的一些经验,希望可以给大家一些新的启发:经验1:要参与需求评审,评审需求的过程实际也是熟悉业务需求的过程。只有对产品的业务理解到位,才能更好、更充分地设计出高质量的测试...
  • 网上书店测试用例.doc

    2021-07-23 06:07:25
    文档介绍:网上书店测试用例班级:2013级软件一班姓名:... 功能测试用例 31.1 被测试对象的介绍 41.2 测试范围与目的 41.3 测试环境与测试辅助工具的描述 41.4 测试驱动程序的设计 41.5 功能测试用例 42. 性能测试用...
  • 该方法是一种重要的,常用的黑盒测试用例设计方法。 2.划分等价类: 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类...
  • 设计测试案例的时候,需要有清晰的测试思路,对要测试什么,按照什么顺序测试,覆盖哪些需求做到...测试用例设计一般包括以下几个步骤: 1、测试需求分析 从软件需求文档中,找出待测试软件/模块的需求,通过自己的分析
  • 接口测试用例设计

    2021-11-05 17:21:23
    设计思路 1) 优先级--针对所有接口 1、暴露在外面的接口,因为通常该接口会给第三方调用; 2、供系统内部调用的核心功能接口; 3、供系统内部调用非核心功能接口; 2) 优先级--针对单个接口 1、正向用例优先测试,...
  • 设计测试案例的时候,需要有清晰的...本文介绍了用例设计的一般步骤测试用例设计步骤设计测试案例的时候,需要有清晰的测试思路,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数。测试用例编写者不仅要...
  • 总结来说,任何事物的测试思路都可以总结如下: 第一步: 梳理产品的核心业务流程:明白这是个什么项目,实现了什么业务,以及是怎么实现的? 这个步骤一般是参考公司的需求文档来的,如果产品提供需求文档的同时...
  • 【测试】对手机拍照测试用例设计
  • 作为一个测试小白,刚开始接触... 看似简单的页面功能能够设计多少条测试用例完成较全面的测试呢?10条以内?20条?.......  那么在给出上述答案之前,先带大家熟悉一下,什么是测试用例测试用例有什么作用? 然
  • 测试用例设计方法 等价类 因材施教的例子: 原则上讲,老师都应该根据每个学生的学习情况制定相应符合的学习方案,但是实际上学生太多,老师管不过来,只能讲学生分为三六九等,优等生强调知识面的扩展和综合能力的...
  • 判断一个三角形是等边三角形、等腰三角形还是不等边三角形的测试用例设计设计思路:考虑用等价类方法进行分析,等价类分为有效等价类和无效等价类; 是否是三个整数、三个整数之间的关系:能否够构成三角形,能...
  • 该方法是一种重要的,常用的黑盒测试用例设计方法。 划分等价类: 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,750
精华内容 13,100
关键字:

测试用例设计思路