测试思想-测试设计 接口测试用例设计实践总结

简介: 测试思想-测试设计 接口测试用例设计实践总结

接口测试用例设计实践总结


 

设计思路

1)  优先级--针对所有接口

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

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

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

 

2)  优先级--针对单个接口

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

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

 

 

3)  设计分析

通常,设计接口测试用例需要考虑以下几个方面:

1、是否满足前提条件

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

逆向用例:

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

 

2、是否携带默认值参数

正向用例:

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

 

3、业务规则、功能需求

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

 

5、参数是否必填

逆向用例:

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

 

4、参数之间是否存在关联

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

逆向用例:

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

 

5、参数数据类型限制

逆向用例:

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

 

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

正向用例:

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

 

逆向用例:

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

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

 

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

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

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

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

 

4)  编写描述

尽量逻辑化,这样方便后续的维护

 

5)  实践操作

接口样例

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

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

接口方向

客户端 -> 服务端

接口协议

接口地址:$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"

           }

       ]

   }

}

 

 

 

用例设计

 

 

 

 

存在问题:

如上,还没写完就有40几条用例了,要是接口参数再多点,接口数量再增加点,工作量可想而知,所以,问题来了,咋办呢?

 

个人见解:

1、根据接口的使用对象(外部,系统内部),有选择的去、留部分用例

2、根据接口的是否核心接口,有选择的去、留部分用例

3、根据参数说明,及实际情况,有选择的去、留部分用例

 

实例:

上例这个接口,是供app、商铺后台调用的,且为系统内部调用,所以,以下用例可酌情略去:

test-E-按商铺id查询-商铺idint

test-E-按设备token查询-tokenstring类型

test-E-按订单时间类型查询-时间类型非int

test-E-按起始日期查询-时间类型非date

test-E-按结束日期查询-时间类型非date

test-E-按订单状态查询-订单状态非string类型

test-E-按交易状态查询-交易状态非int

test-E-按支付方式查询-支付方式非int

test-E-按收银员查询-收银员idint

test-E-按导购员查询-导购员idint

test-E-按页码查询-页码非int

 

理由:

这个接口是给其它开发于系统内部调用的,开发过程中,开发者肯定需要调用这些接口,如果类型错了,他们也就获取不到预期的数据,这些错误,他们肯定可以发现,所以,他们传递的参数值一般能保证类型正确。

 

test-N-按参数类型最大值查询    所有参数

test-E-按商铺id查询-商铺id超过类型范围值

test-E-按订单状态查询-订单状态值超过类型最大值

test-E-按交易状态查询-交易状态值超过int类型最大值

略去的用例部分(参数值超过类型最大值)

 

理由:

1、内部调用,参数值不是外部手动输入的,输入数据长度、值大小可控,当然如果数据一直增长,那再大的类型可能都无法保证不超出,比如自动增长的商铺id

2、部分参数的参数值是自定义的,比如订单时间类型,就那几种,除非传错了,不然不可能超出范围

 

最后简化后的用例数差不多28条,如果是手工测试,对于正向用例,根据等价类原理,可以制造一条数据,覆盖多条用例,当然,也可以冗余处理,即一条用例一条数据,这样的好处就是每次的验证点比较单一一点,比较有针对性。

 

问题

如果是自动化测试呢,这里是设计一个方法覆盖多条用例呢(如上,一条数据,覆盖多条用例)?还是一个方法覆盖一条用例呢?

 

我个人的答案是一个方法一条用例,你的呢?

目录
相关文章
|
19天前
|
数据采集 监控 机器人
浅谈网页端IM技术及相关测试方法实践(包括WebSocket性能测试)
最开始转转的客服系统体系如IM、工单以及机器人等都是使用第三方的产品。但第三方产品对于转转的业务,以及客服的效率等都产生了诸多限制,所以我们决定自研替换第三方系统。下面主要分享一下网页端IM技术及相关测试方法,我们先从了解IM系统和WebSocket开始。
34 4
|
21天前
|
人工智能 JavaScript 前端开发
自动化测试框架的演进与实践###
本文深入探讨了自动化测试框架从诞生至今的发展历程,重点分析了当前主流框架的优势与局限性,并结合实际案例,阐述了如何根据项目需求选择合适的自动化测试策略。文章还展望了未来自动化测试领域的技术趋势,为读者提供了宝贵的实践经验和前瞻性思考。 ###
|
6天前
|
监控 JavaScript 测试技术
postman接口测试工具详解
Postman是一个功能强大且易于使用的API测试工具。通过详细的介绍和实际示例,本文展示了Postman在API测试中的各种应用。无论是简单的请求发送,还是复杂的自动化测试和持续集成,Postman都提供了丰富的功能来满足用户的需求。希望本文能帮助您更好地理解和使用Postman,提高API测试的效率和质量。
40 11
|
19天前
|
测试技术 Python
探索软件测试的深度与广度:从理论到实践
在数字化时代,软件已成为我们生活中不可或缺的一部分。随着技术的不断进步和用户需求的多样化,确保软件质量变得尤为重要。本文将深入浅出地介绍软件测试的核心概念、类型及其在软件开发生命周期中的重要性。我们将通过实际案例,展示如何实施有效的测试策略,并探讨自动化测试的未来趋势,旨在为读者提供一套完整的软件测试知识体系,帮助提升软件质量和开发效率。
|
20天前
|
测试技术 Python
探索软件测试的奥秘:从理论到实践
在软件开发的宇宙中,软件测试犹如一颗璀璨的星辰,指引着质量的方向。本文将带你穿梭于软件测试的理论与实践之间,揭示其内在的逻辑和魅力。从测试的重要性出发,我们将探讨不同类型的测试方法,并通过实际案例分析,深入理解测试用例的设计和应用。最后,我们将通过一个代码示例,展示如何将理论知识转化为实际操作,确保软件质量的同时,也提升你的测试技能。让我们一起踏上这段探索之旅,发现软件测试的无限可能。
|
23天前
|
jenkins 测试技术 持续交付
自动化测试框架的搭建与实践
在软件开发领域,自动化测试是提升开发效率、确保软件质量的关键手段。本文将引导读者理解自动化测试的重要性,并介绍如何搭建一个基本的自动化测试框架。通过具体示例和步骤,我们将探索如何有效实施自动化测试策略,以实现软件开发流程的优化。
50 7
|
22天前
|
测试技术
探索软件测试的奥秘:从理论到实践
本文深入探讨了软件测试的基本概念、重要性、主要类型以及实施策略。通过分析不同测试阶段和相应的测试方法,文章旨在为读者提供一套完整的软件测试知识体系,帮助他们更好地理解和应用测试技术,确保软件产品的质量和可靠性。
41 4
|
25天前
|
存储 算法 C语言
用C语言开发游戏的实践过程,包括选择游戏类型、设计游戏框架、实现图形界面、游戏逻辑、调整游戏难度、添加音效音乐、性能优化、测试调试等内容
本文探讨了用C语言开发游戏的实践过程,包括选择游戏类型、设计游戏框架、实现图形界面、游戏逻辑、调整游戏难度、添加音效音乐、性能优化、测试调试等内容,旨在为开发者提供全面的指导和灵感。
43 2
|
18天前
|
监控 搜索推荐 测试技术
电商API的测试与用途:深度解析与实践
在电子商务蓬勃发展的今天,电商API成为连接电商平台、商家、消费者和第三方开发者的重要桥梁。本文深入探讨了电商API的核心功能,包括订单管理、商品管理、用户管理、支付管理和物流管理,并介绍了有效的测试技巧,如理解API文档、设计测试用例、搭建测试环境、自动化测试、压力测试、安全性测试等。文章还详细阐述了电商API的多样化用途,如商品信息获取、订单管理自动化、用户数据管理、库存同步、物流跟踪、支付处理、促销活动管理、评价管理、数据报告和分析、扩展平台功能及跨境电商等,旨在为开发者和电商平台提供有益的参考。
25 0
|
25天前
|
人工智能 数据管理 jenkins
探索软件测试中的自动化框架:从基础到高级实践
在当今快速发展的软件行业中,自动化测试已成为提高开发效率和保障产品质量的关键手段。本文将深入探讨软件测试自动化的各个方面,包括其重要性、主流的自动化测试框架、以及如何有效地实施自动化测试策略。我们还将通过案例分析,展示自动化测试在实际项目中的应用效果,以及面临的挑战和解决方案。无论是软件开发者还是测试工程师,了解并掌握自动化测试技术都将极大提升工作效率和产品质量。
44 0