精华内容
下载资源
问答
  • 本篇的目的是简明的完成一份接口测试用例设计的撰写,维护的文档,需要大家共同努力,不断完善,存在的不足以及日后在实际使用中暴露出来的问题,希望大家及时出,以便更新文档。 一、 用例设计过程: 用例不是一次...

    本篇的目的是简明的完成一份接口测试用例设计的撰写,维护的文档,需要大家共同努力,不断完善,存在的不足以及日后在实际使用中暴露出来的问题,希望大家及时出,以便更新文档。

    一、 用例设计过程:

    用例不是一次完成的,书写测试用例本身和完善代码一样,也是一个循序渐进的过程。
    首先,必须熟读需求说明书和接口设计文档,了解每个接口具体的使用场景,明白软件的性能指标。
    其次,设计接口测试用例:开始在编码阶段,测试人员根据需求说明书和接口设计文档设计接口测试用例。
    然后,code review:开发完成编码后,在时间充裕的条件下,要进行 code review,一方面是检查开发的代码功能逻辑是否正确,另一方面通过review开发的代码来补充接口测试用例。
    最后,完成用例后,随着对系统了解的增多,不断提高用例精度,对测试用例需要进行定期review,一旦测试需求发生变化,测试用例必须重新维护。

    二、接口测试用例构思结构:

    阶段一:开发在编码,测试拿到需求文档和接口设计文档:
    1、基本功能测试(业务测试):根据需求文档和接口设计文档的转译,需要清楚业务流程规则和每个接口的使用场景方式,设计符合业务逻辑和接口使用场景的用例。
    2、边界分析测试:在基本功能的基础上,开始考虑接口输入输出参数的影响。主要采用等价类划分、边界值分析方法等。
    覆盖所有的必选参数
    组合可选参数
    a.参数有无、或为null
    b.参数的顺序、个数、类型
    c.参数类型数值大小、输入的数值的范围
    d.参数字串长短,Null-max-max+1
    e.参数包含特殊字符
    3、参数组合测试:在边界分析的基础上,考虑输入条件的各种组合、输入条件之间的相互制约关系。主要使用因果图法进行用例设计。
    4、异常情况测试:接口实现是否对异常情况都进行了处理,接口输入参数虽然合法,但是在接口实现中,也会出现异常,因为内部的异常不一定是输入的数据造成的,而有可能是其他逻辑造成的,程序需要对任何异常都进行处理,比如:某个接口需要先登录获取token,如果直接调用该接口应该给出相应提示。
    5、幂等级测试:简单说就时针对连续重复提交的情况的进行测试,特别是涉及到交易金额的场景,需要验证软件是如何处理的。
    6、并发测试:两个以上用户同时操作使用同一场景时,可能引导争夺资源,死锁等现象。
    7、事务性测试:一个业务流程包含多个操作步骤,如果某个操作失败,那么整个操作需要回滚。或者调用前一个步骤的逆向接口进行操作取消。
    8、大数据量时测试:数据库里数据量较大时(百万级),测试对DB进行增删改查操作的效率。
    9、环境异常测试:关联系统出现宕机、超时或者无响应的状态时,接口返回提示正确,业务逻辑正确,不可存在事务性不一致的情况
    阶段二:开发完成编码,测试时间充裕的条件下,需要对开发的代码进行code review
    1、 review开发的代码实际业务逻辑是否正确
    2、隐含条件测试:进行code review,检查代码中是否有隐含的默认条件。
    3、SQL测试:针对需要进行数据库操作的接口,查看相关sql,对sql的正确性进行验证。一般sql的过滤条件都会比开发告诉我们的要多,所以查看sql进行验证是最保险的方式,特别需要设计组合条件的场景进行验证。

    三、测试过程验证点:

    1、接口返回数据
    a) 返回json数据的层次关系是否与文档一致
    b) 数值类型数据: 特别是金额,负数、小数转为json输出是否正确
    c) 接口返回数据与接口文档一致
    d) 接口返回数据和数据库一致
    e) 接口返回数据符合业务逻辑(比如转账功能,从一个账户扣款,另一个要增加相应金额)
    f) 对于列表,应该根据请求参数,也应该验证列表的长度是否与期望值一致
    g) 负面测试用例,应验证ERROR INFO是否与实际相匹配
    2、数据库
    a) 接口传入数据与插入DB的数据一致性:
    b) 前端某个操作涉及后台DB多张表时,每张表都要检验数据正确性。
    3、安全层面:
    a) 后端接口返回给前端的数据包含敏感信息(如:姓名、身份证号、卡号、手机号、加密后的密码等)时,不能明文传输,需要加密。
    b) 后台打日志要求对于敏感信息不能打出,或者进行加星号脱敏后打出,具体有:
    (1)身份证号,用户密码(含加密后),用户手机号码,用户姓名,银行卡号
    (2)身份证号码脱敏字段为生日时,生日在日志中不能打出
    4、性能层面:
    a) 接口响应时间: 接口处理数据的时间也是测试需要关注的一个点。牵扯到内部就是算法与代码的优化
    b) 接口数据包大小:接口传递的数据包大小也需要关注,特别是返回给前端的接口,要把不同接口数据包大小需要做限制。
    c) 并发承载能力:多用户并发时接口可以承载合同中的并发量。

    展开全文
  • 零,所有待测接口都要覆盖 一,参数覆盖(所有、...n个必填参数,就需要设计n个用例 预期:业务失败,报错,并有提示信息 必填参数的个数(冗余与缺失,逆向,1+n):。 接口需要机制去判断:如果参数多了或者少了

    零,所有待测接口都要覆盖

    一,参数覆盖所有、必填、可选

    1,覆盖所有参数(正向,2个):

    1,包括必选和可选:1个

    2,不包括可选只包括必选:1个

    总共:2个

    预期:返回正常的响应报文

    1. 必填参数是否为空(逆向,n个):

    每个必填都要考虑

    必选参数A:为空

    必选参数B、C、D...:不为空

    可选参数:不写为空的逆向用例

    n个必填参数,就需要设计n个用例

    预期:业务失败,报错,并有提示信息

    1. 必填参数的个数(冗余与缺失,逆向,1+n):。
      1. 接口需要机制去判断:如果参数多了或者少了,怎么处理。

    接口文档中应有说明:参数多,应自动忽略。参数少应提示缺失。

    如果没有说明,找接口文档编写者确认。

      1. 必填参数

    必填参数:多1个,设计1条用例。预期:正常

    必填参数:少1个,每个必填缺失,n个必填参数可以设计n个逆向用例。预期:报错

      1. 可选参数:不考虑多和少

    4,可选参数的任意组合,正向用例(若干个):

      1. 必填参数必须有
      2. 根据可选参数数目,设计若干条。

    3个可选参数组合方式,7种:ABC,1个可选(3种),2个(AB AC BC,3种),3个(ABC,1种)

    5个可选参数,31个:C(5,1)5+C(5,2)10+C(5,3)10+C(5,4)5+C(5,5)1=31个用例

    (3)预期:不报错

    二,参数类型覆盖n+1:数据类型错误-逆向用例

    1,每个必填参数编写1条错误类型的用例,n个必填,编写n个逆向用例

    2,所有可选参数编写1条错误类型的用例,必选参数类型正确。1个逆向用例。预期:不报错

    为了提高覆盖度,理想的情况:n个可选参数就写n个逆向用例

    注意:字符串类型的错误类型可以包括:布尔值,数字(整数、浮点数)

    3,预期:报错,并有提示信息

    三,参数值覆盖

    1,参数默认值

    设计1条正向用例:无论是否必选,具有默认值的参数名都要填写,但是不填写参数值。其他无默认值的必填参数及无默认值的可选参数都填写常规值。

    预期:返回正常业务的响应报文,不报错

    注意一下两点,灵活调整

    • 必填参数带默认值可能与必填参数值为空的用例重复
    • 可选参数带默认值可能与可选参数缺失或值为空的用例重复

    2,参数值范围(边界值)(1+1+n+n)

    (1)最大值,正向用例1个:

    所有参数:最大值

    预期:返回正常业务的响应报文,不报错

      1. 最小值正向用例1个:

    所有参数:最小值

    预期:返回正常业务的响应报文,不报错

    视具体情况而定,一般最小值是隐含的。显式指明的,则需要考虑覆盖。

    注意:如果分析隐含最小是0,需要判断该参数能否为空,如果能为空,那最小就是0,不能为空,则最小需要大于0个字符。

    (3)逆向用例,n个

    每个参数1条(无论是否必选):超出最大范围,n个

    每个参数1条(无论是否必选):超出最小值,n个

    注意:超出最小值可能会跟参数为空的测试用例重复

    预期:报错,并有提示信息

    3,参数值存在(n+n)

    (1)重复性校验:有些参数值需要保持唯一(不能重复),n个参数就设计n个用例--逆向。预期:报错,并有提示信息

    (2)存在性校验:有些参数值需要存在数值(不能是错误--非空但不存在),才能使用。

    每个参数1个(n个参数就设计n个用例)--逆向。例如:查询不存在的ID。预期:报错,并有提示信息

    有时可以1个。

    经常用于过滤、查找、搜索等接口。

    • 业务规则

    灵活性太高,没有固定的的规则遵循,具体问题具体分析,例如关联场景

    ,其他补充:

    1,前提条件的存在与缺失--权限、用户名密码、token等

    2,请求之间的关联,参数之间的关联

    3,错误推测法:根据经验:经验来自于错误的积累(前后加%、空格、#、@、/、$等)

    接口需要机制去处理:

    1,过滤这些特殊字符

    2,提示用户参数值含有非法字符:%、空格、#、@、/、$等

    4,其他

    六,总的指导原则:

    1,效率、成本和覆盖度之间的平衡

    2,以最少的用例达到最大的覆盖

    3,根据情况灵活决定设计测试用例的数目

    展开全文
  • 接口测试用例设计 - 实战篇

    千次阅读 2021-03-14 15:10:22
    常用的接口测试用例覆盖方法 五.接口测试的接口优先级 5.1 优先级--针对所有接口 5.2 优先级--针对单个接口 六.接口测试的设计思路分析 七.接口测试返回结果的比较 八.实践操作 8.1接口样例 8.2 接口...

    目录

    一.接口测试流程

    二.分析接口文档中哪些元素

    三.如何设计接口测试用例

    3.1 为什么要设计测试用例

    3.2 设计接口测试用例从哪些方面考虑

    四.常用的接口测试用例覆盖方法

    五.接口测试的接口优先级

    5.1  优先级--针对所有接口

    5.2 优先级--针对单个接口

    六.接口测试的设计思路分析

    七.接口测试返回结果的比较

    八.实践操作

    8.1接口样例

    8.2 接口测试用例设计

    8.3 个人对接口的认知


     

    一.接口测试流程

    1.需求讨论

    2.需求评审

    3.场景设计

    4.数据准备

    5.执行

     

    二.分析接口文档中哪些元素

    1.接口名称

    2.接口地址

    3.支持格式

    4.请求方式

    5.请求参数(参数名称、类型、是否必填、参数说明等)

    6.返回参数(返回码、返回值信息、返回json串信息)

     

    三.如何设计接口测试用例

    3.1 为什么要设计测试用例

    1.理清思路,避免漏测

    2.提高测试效率

    3.跟进测试进度

    4.告诉领导做过

    5.跟进重复性工作

     

    3.2 设计接口测试用例从哪些方面考虑

    1.功能

    • 功能是否正常

    • 功能是否按照接口文档实现

    • 正常场景

    • 异常场景

    2.逻辑业务

    是否依赖业务,比如是否登录成功

    3.异常测试

    (1) 参数异常:

    • 关键字参数、参数为空、多、少参数、错误参数

    • 覆盖所有的必选参数,组合可选参数,参数有、无或为null,参数的顺序、个数、类型,

    • 参数类型数值大小、输入的数值的范围,参数字串长短,参数包含特殊字符。

    (2)数据异常:

    • 关键字数据、数据为空、长度不一致、错误数据

    4. 安全

    Cookie、header、唯一识别码

     

    四.常用的接口测试用例覆盖方法

    4.1 必需参数覆盖

    对于接口的参数,接口文档一般都会说明哪些儿是必需的,哪儿是非必需的。对于必需的参数,一定要测试传参数和不传参数接口是否报错?

    4.2 必需的参数各种情况覆盖

    传非法的字符,特殊的字符,空值,超过边界的参数是否报错?错误信息是否正确?

    4.3 非必需参数覆盖

    一般接口对于非必需参数都不会做非正常性传值的判断,所以要测试合法的参数值 ,接口返回的内容是否正确。如果有接口文档说明对非必需参数做了非正常的验证的话,也要对其进行验证。

    4.4 参数的组合覆盖

    有些儿参数需要相互配合着才起作用,如“offset”和“count”组合起来进行翻页,这个时候要组合起来进行测试。

    4.5 业务逻辑相关的覆盖

    有些儿接口与业务逻辑关联密切,单独从接口角度测试,可能会遗漏掉一些儿因业务逻辑而产生的bug。所以如果和业务逻辑相关,也要考虑到业务逻辑相关的测试用例。

    其实接口的测试用例差不多也就这些儿情况,也许有特殊的接口,到时候和产品,开发人员做好沟通,尽量先从接口层面保证质量。这样再从测试接口的应用层的时候,就可以少很多工作量,只注重样式和各个接口调用的配合就可以了。

     

    五.接口测试的接口优先级

    5.1  优先级--针对所有接口

    1.暴露在外面的接口,因为通常该接口会给第三方调用

    2.供系统内部调用的核心功能接口

    3.供系统内部调用非核心功能接口

    5.2 优先级--针对单个接口

    1.正向用例优先测试,逆向用例次之(通常情况,非绝对)

    2.是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围值限制

     

    六.接口测试的设计思路分析

    6.1是否满足前提条件

    有些接口需要满足前置条件,才可成功获取数据。常见的,需要登陆Token。

    逆向用例:

    针对是否满足前置条件(假设为n个条件),设计0~n条用例

    6.2 是否携带默认值参数

    正向用例:

    带默认值的参数都不填写、不传参,必填参数都填写正确且存在的“常规”值,其它不填写,设计1条用例; 

    6.3 业务规则、功能需求

    这里根据实际情况,结合接口参数说明,可能需要设计n条正向用例和逆向用例 

    6.4 参数是否必填

    逆向用例:

    针对每个必填参数,都设计1条参数值为空的逆向用例

    6.5 参数之间是否存在关联

    有些参数彼此之间存在相互制约的关系

    逆向用例:

    根据实际情况,可能需要设计0~n条用例

    6.6 参数数据类型限制

    逆向用例:

    针对每个参数都设计1条参数值类型不符的逆向用例

    6.7 参数数据类型自身的数据范围值限制

    正向用例:

    针对所有参数,设计1条每个参数的参数值在数据范围内为最大值的正向用例

    逆向用例:

    针对每个参数(假设n个),设计n条每个参数的参数值都超出数据范围最大值的逆向用例

    针对每个参数(假设n个),设计n条每个参数的参数值都小于数据范围最小值的逆向用例

    以上几个方面考虑全的话,基本可以做到如下几个方面的覆盖:

    • 主流程测试用例:正常的主流程功能校验;

    • 分支流测试用例:正常的分支流功能校验。

    • 异常流测试用例:异常容错校验 

     

    七.接口测试返回结果的比较

    对于接口返回值的校验问题,其目的一是验证代码正常,二是验证代码正确,个人总结:

    1.首先比较返回码

    2.然后比较返回值的完整性,即返回的key全不全

    3.然后比较key的value数据类型(也就是jsonschema)

    4.然后比较key对应的value值(也包括验证业务相关数据的value值)

    然而,一般接口自动化,通常验证1、2两点即可,第3点根据公司测试周期来评估,而第4点,在功能测试中会验证value值的正确性。

    注:jsonschema 是把返回的键 和 键的数据类型定义包,然后保存到文件中,然后和读取到的接口 做键 和值的类型 做比较

     

    八.实践操作

    8.1接口样例

    获取订单列表接口(多条件)

    获取店铺指定期间的所有订单列表(多种条件组合),默认根据日期倒序排序。

    接口方向

    客户端 -> 服务端

    接口协议

    接口地址:$xxx_Home/xxx/鉴权前缀/xxxxx/getAllOrderList

    接口协议:JSON

    HTTP请求方式:GET

     

    消息请求

    字段列表如下:

    字段名

    数据类型

    默认值

    必填项

    备注

    shopId

    int

     

    商铺编号

    token

    string

     

    条件

    设备令牌。Token鉴权方式必填

    dateType

    int

    1

    订单查询时间字段。

    1:下单时间(order_time)

    2:订单完成时间(order_finish_time)

    3:结算时间(shop_settle_time)

    startDate

    date

     

    查询日期

    endDate

    Date

     

    查询结束日期。

    orderStatus

    String

     

    订单状态。

    不填表示所有状态

    多个状态之间以英文逗号分割

    0:已预定

    1:已开单

    2:派送中

    3:已完成(原已结帐)

    4:退单中

    5:已退单

    8:自助下单

    9:待确认

    orderTransactionType

    Int

     

    订单交易状态。

    不填表示所有。

    1:未完成,

    2:已完成(3:已完成, 5:已退单)

    payType

    int

     

    支付方式。

    不填表示所有。

    1:现金

    2:POS

    3:线上

    cashierId

    int

     

    收银员

    billerId

    int

     

    导购员

    pNo

    int

     

    页码,从第1页开始,默认为1

    pSize

    int

     

    每页记录数,默认为10

     

    消息请求样例:

    ?shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10

    消息响应

    字段元素如下:

    字段名

    数据类型

    默认值

    必填项

    备注

    orderTotalPriceTotal

    double

     

    实收金额合计(已完成的合计)

    platformTotalIncomePriceTotal

    double

     

    平台服务费合计

    cashPayTotal

    double

     

    现金支付(已完成的合计)

    posPayTotal

    double

     

    POS支付(已完成的合计)

    onLinePayTotal

    double

     

    线上支付(已完成的合计)

    lst

    object

     

    明细列表

     

    明细列表对象字段元素定义:

     

    字段名

    数据类型

    默认值

    必填项

    备注

    orderId

    string

     

    订单ID

    orderTitle

    string

     

    订单标题

    mobile

    string

     

    会员账号,如果是会员则显示手机号,为空时表示“非会员”

    settlePrice

    double

     

    交易金额

    orderTime

    datetime

     

    下单时间

    serviceAmount

    double

     

    平台服务费

    Status

    Int

     

    订单状态。

    0:已预定

    1:已开单

    2:派送中

    3:已完成(原已结帐)

    4:退单中

    5:已退单

    8:自助下单

    9:待确认

    cashPay

    double

     

    现金支付

    posPay

    double

     

    POS支付

    onLinePay

    double

     

    线上支付

     

    成功时,返回JSON数据包:

    {

        "code": 0,

        "msg": "查询订单列表成功!",

        "data": {

            "pNo": 1,

            "rCount": 5,

            "orderTotalPriceTotal": 23.3,

            "platformTotalIncomePriceTotal": 0,

            "lst": [

                {

                    "orderTitle": "kouxiangtang",

                    "settlePrice": 15.89,

                    "cashTotal": 15.89,

                    "posTotal": 0,

                    "onLineTotal": 0,

                    "orderTime": "2015-09-29 13:44:26",

                    "orderId": "12345679282015092913440268141",

                    "mobile": "13424183952"

                },

                {

                    "orderTitle": "红塔山",

                    "settlePrice": 7.5,

                    "cashTotal": 7.5,

                    "posTotal": 0,

                    "onLineTotal": 0,

                    "orderTime": "2015-09-29 11:37:58",

                    "orderId": "12345679282015092911370588273"

                }

            ]

        }

    }

    8.2 接口测试用例设计

     

    用例

    设计思路

    传参

    用例1

    覆盖所有参数,正向用例

    data={'shopId':123,'token':'bolixiyang','dataType':1,'startDate':'2016-06-06','endDate':'2016-06-07','orderStatus':'','orderTransactionType':'','payType':'','cashierId':'','billerId':'','pNo':'','pSize':''}

    用例2

    覆盖所有必填参数,正向用例

    data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06'}

    用例3

    某一必填参数为空,逆向用例

    data={'shopId':'','token':'bolixiyang','startDate':'2016-06-06'}

    data={'shopId':123,'token':'','startDate':'2016-06-06'}

    data={'shopId':123,'token':'bolixiyang','startDate':''}

    用例4

    多传一个参数、少传一个参数,逆向用例

    data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06','canshuduo':'123'}

    data={'shopId':123,'token':'bolixiyang'}

    用例5

    必填参数数据类型错误,数据值错误,逆向用例

    data={'shopId':'123','token':'bolixiyang','startDate':'2016-06-06'}

    data={'shopId':666,'token':'bolixiyang','startDate':'2016-06-06'}

    用例6

    任意组合可选参数,正向用例

    data={'shopId':123,'token':'bolixiyang','dataType':1,'startDate':'2016-06-06','endDate':'2016-06-07','cashierId':'','billerId':'','pNo':'','pSize':''}

    用例7

    参数数值的范围、参数默认值的范围、字符串的长度,逆向用例

    data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06','orderStatus':'0,1,2,10'}

    用例8

    与业务逻辑相关的,token为空或者错误,逆向用例

    data={'shopId':123,'token':'','startDate':'2016-06-06'}

    data={'shopId':123,'token':'errorToken','startDate':'2016-06-06'}

    用例9

    字段的唯一性校验,如插入数据userName字段不能重复,发送两次请求,查看第二次返回结果

    data={'userName':'bolixiyang'}

    data={'userName':'bolixiyang'}

     

    8.3 个人对接口的认知

     

      其实接口测试和其他测试一样,都是写用例,每次传递的参数发生不同的改变而已,我们真正的目的不是用接口测试去测试和覆盖所有内容,而是接口测试在实际工作中,可以在没有ui的情况下就可以直接介入测试,以及会使用接口测试。一般情况下,接口里不会做任何拦截,你传错了,可能也不会校验,校验一般都是在前端会加拦截器等内容,主要是接口能正常调起来就可以了。

    展开全文
  • 6、接口测试用例模板 1、通过性验证 首先肯定要保证这个接口功能是好使的,也就是正常的通过性测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。 2、参数组合 现在有一个操作修改商品的接口,...

    目录

    1、通过性验证

    2、参数组合

    3、接口安全

    4、异常验证

    5、设计测试用例

    6、接口测试用例模板


    1、通过性验证

    首先肯定要保证这个接口功能是好使的,也就是正常的通过性测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。

    2、参数组合

    现在有一个操作修改商品的接口,有三个字段,商品id、商品名称、价格,至少有一个是必传的。
    这样就要测参数组合了,比如只传商品名称看能不能修改成功;传商品id、商品名称、价格的时候能不能修改成功等等。

    3、接口安全

    (1)绕过验证,比如说购买了一个商品,它的价格是300元,那我在提交订单时候,我把这个商品的价格改成3元,后端有没有做验证,更狠点,我把钱改成-3,是不是我的余额还要增加?
    (2)绕过身份授权,比如说修改商品信息接口,那必须得是卖家才能修改,那我传一个普通用户,能不能修改成功,我传一个其他的卖家能不能修改成功。
    (3)参数是否加密,比如说我登陆的接口,用户名和密码是不是加密,如果不加密的话,别人拦截到你的请求,就能获取到你的信息了,加密规则是否容易破解。
    (4)密码安全规则,密码的复杂程度校验。

    4、异常验证

    异常的,也就是我不按照你接口文档上的要求输入参数,来验证接口对异常情况的校验。
    比如说必填的参数不填;输入整数类型的,传入字符串类型;长度是10的,传11。
    关注点:必传非必传、参数类型、入参长度等。

    5、设计测试用例

    根据业务逻辑来设计测试用例,就是根据系统的业务来设计用例,每个公司的业务不一样,就得具体看自己公司的业务了,其实这也和功能测试设计用例是一样的。
    比如BBS的需求是这样的:
    (1)登录失败5次,就需要等待15分钟之后再登录
    (2)新注册的用户需要过了实习期才能发帖
    (3)删除帖子扣除积分
    (4)......
    像这样的你就要把这些测试点列出来,然后再去造数据测试对应的测试点。

    6、接口测试用例模板

    测试接口肯定要写测试用例,接口测试用例要素如下:
    (1)项目
    (2)模块 这个接口是属于哪个功能模块的
    (3)用例id
    (4)接口名称
    (5)用例标题 用例是干嘛的
    (6)请求方式 GET/POST/...
    (7)请求url url地址
    (8)请求参数
    (9)前置条件 有依赖的时候,比如说要测登录失败3次等
    (10)结果验证 预期结果
    (11)请求报文
    (12)返回报文
    (13)测试结果 通过/失败
    (14)测试人员

    AllTests软件测试

    展开全文
  • 从接口测试目的出发,详细分享接口测试用例设计思路。最后以最常用的增删改查接口为实例分享接口测试用例设计全过程。
  • 简介: 设计思路 1) 优先级--针对所有接口 1、暴露在外面的接口,因为通常该接口会给第三方调用; 2、供系统内部调用的核心功能接口; 3、供系统内部调用非核心功能接口
  • 无论是功能测试用例设计还是接口用例设计,都必须要了解用户的需求是什么,为了解决什么样的问题而做这个需求。 2、查看接口设计文档 接口设计文档是必须要有的,包括接口的url、是Get还是Post方法、Http Header中...
  • 接口测试用例设计

    2021-11-05 17:21:23
    设计思路 1) 优先级--针对所有接口 1、暴露在外面的接口,因为通常该接口会给第三方调用; 2、供系统内部调用的核心功能接口; 3、供系统内部调用非...3) 设计分析通常,设计接口测试用例需要考虑以下几个方面:...
  • 接口测试非常快速、UI自动化执行一个测试用例10S左右、接口测试用例执行的话,需要的时间是毫秒级的 12、之前在接口测试过程中,使用的工具是什么? postman或jmeter(5.1) 13、之前用过抓包工具没有?如何使用的? ...
  • 有关于接口清单和用工具执行测试用例,我们已经在下面的这篇文章中介绍过了,这篇文章来介绍一下测试用例设计方法。 其实说的很玄乎,叫什么测试用例设计,这名词拽的一溜一溜的,但其实不要觉得它很难,不要...
  • 如何编写接口测试用例?测试工程师必备技能!

    千次阅读 多人点赞 2021-04-16 21:21:37
    自动化始终只是辅助测试工作的一个手段,对于测试人员而言,测试基础和测试用例设计才是核心。如果测试用例的覆盖率或者质量不高,那将这部分用例实现为自动化用例的意义也就不大了。
  • 所以接口测试用例的编写要先于ui功能测试用例 依据文档:接口测试用例参考接口文档,ui功能测试参考功能需求文档 组成:接口测试用例核心是:请求方式、请求地址以及请求参数 Ui功能测试用例核心是:测试步骤、...
  • 接口测试用例基础知识 接口测试要测的是什么? 接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。 接口...
  • 二、用例 1、TestApiGetSearchSuggestion.java,该代码实现对Api接口的请求,对返回的数据进行判断,并写文件。 2、Jmeter_GetSearchSuggestion.java,为本节介绍的重点 [java] view plain copy package ...
  • 一、为什么要做接口测试 在日常开发过程中,有人做前端开发,有人负责后端开发。接口就是连接前后台,由于前端开发和后端开发的速度可能不一样,例如后端开发好了,但是前端没有开发。那么我们是不是就不需要测试呢...
  • 接口测试用例模板

    2021-07-07 15:45:10
    用例名称 接口名称 请求URL 请求类型 请求头 请求参数类型 请求参数 预期结果 测试结果 IHRM-LOGIN-001 登录 ...
  • 今天给大家分享一份文档《接口测试用例设计大全》,致力于帮助广大测试人,觉得有用麻烦点个赞哟。 设计思路 1)优先级--针对所有接口 1、暴露在外面的接口,因为通常该接口会给第三方调用; 2、供系统内部...
  • 一、接口测试用例命名与分类需要注意: 命名测试用例主要为了区分用例验证点和用例作用,好的用例名称可以让人一看到就清楚明白用例的作用。根据不同的测试重点可将接口测试用例大体分为五个类别: 1、正常场景接口...
  • (3)测试用例 二、生成报告 (1)保存json ​​2.生成报告html 一、登录接口解析 (1)登录接口文档 基本信息 Path:/api/sys/login Method:POST 接口描述 请求参数 Headers 参数名称 ...
  • 目录 一、黑盒测试 1.等价类划分 2.边界值分析法 3.正交试验法 4.状态迁移法 ...等价类可以划分为有效等价类和无效等价类,设计测试用例的时候要考虑这两种等价类。 2.边界值分析法 边界值分析法
  • 1. 接口测试用例设计 通过性验证:传入正确的参数,验证返回结果是否正确 异常参数验证:传入的参数类型不正确、长度过长、为null、包含特殊字符、必填项为空等,验证接口是否处理异常情况 参数组合:根据某个参数...
  • 软件测试用例设计方法-边界值法
  • 《【接口测试实战(三)】接口测试用例的编写》 相关文档: 《【自动化测试】接口测试基础》 《【自动化测试】接口测试的具体内容和流程》 文章目录1)测试用例1.1 测试点梳理:1.2 部分用例:2)执行用例2.1 新增2.2...
  • 自动化测试用例一般可以由手工测试用例转化而来,需注意: ·不是所有手工测试用例都要转为自动化测试用例 · 考虑到脚本开发的成本,不要选择流程太复杂的用例,可以把流程拆分成多个用例 · 选择的...
  • 接口测试用例设计主要针对输入、处理、输出进行考虑 01 针对输入进行设计 对于接口来说,输入就是入参,一般的参数类型: 数值型 ① 边界内、边界值、边界外三个方面去考虑 ② 特殊值处理不当程序异常、类型边界...
  • 1、验证接口正向流程通过 —> 传入正确的入参---->接口请求不报错 2、验证接口入参必填项—>接口入参必填项均填入------>接口请求正常,返回正确 接口入参必填项不填**—>返回错误提示信息 验证接口...
  • 接口测试的必要性 可以发现很多页面操作发现不了的问题 检查系统的异常处理能力 检查系统的安全性、稳定性 前端随便变,接口测好了,后端不用变 ...接口测试用例设计 通过性验证:首先保证接口好用,按文.

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 116,751
精华内容 46,700
关键字:

接口测试用例设计方法