功能测试用例深入设计_花样案例汇总

一些定义:

客户端:安卓版app,IOS版app

服务器端:服务器服务范畴内的所有服务(不含数据库,不含nginx,不含防火墙)

接口文档:特指客户端和服务器端的接口文档(两个部门开发协商后的产物)

案例一、客户端行为与接口文档中某接口的极度隐晦关系

客户端结构:一层外壳Demo(有游戏,社交软件等),内部支付SDK(被外壳包围,需要支付时调用该SDK)

Demo
SDK

业务交互场景:

1、DemoA把一个加密后的token传递给服务器端,其中token=md5("DemoA的包名":"com.demoA"+私钥:‘ABCDEF123‘)

2、SDK主动获取DemoA的包名定义为一个变量  sdk_getDemoA_packageName(注意,这里sdk_getDemoA_packageName可能与com.demoA相等或不相等)

3、SDK会把Demo的token和sdk_getDemoA_packageName传递给服务器端

4、服务器端得到2个变量值token和sdk_getDemoA_packageName,服务器端使用"公钥“:"321FEDCBA"对Token进行解密,等到"DemoA的包名":"com.demoA"。用com.demoA与sdk_getDemoA_packageName进行是否相等对比?对比结果=“相等”,则允许客户端继续XXXXX,对比结果≠“相等”则阻止客户端继续XXXXX;

协议:

接口测试:

TC_1、会给App.Package写一个真实存在的值Value_Pa,给App.Sign写一个 MD5(Value_Pa+“ABCDEF123”)值,请求时把2个参数传递服务器,服务器判断App.Package与App.Sign“相等”,验签成功;

TC_2、会给App.Package写一个真实存在的值Value_Pbbb,给App.Sign写一个 MD5(Value_Pa+“ABCDEF123”)值,请求时把2个参数传递服务器,服务器判断App.Package与App.Sign“不相等”,验签失败;

功能测试:

TC_1、符合登录条件,登录成功;

TC_2、账号错误,密码错误,验证码错误,账号被冻结,登录失败;

阐述极度隐晦关系的形成原因:

1、接口测试的时候很自然的会忽略掉App.Package,App.Sign的真实来源,只会按照测试用例直接进行赋值并请求接口,这是忽略App.Package描述的第一个情况;

2、功能测试的时候,更多参考的是有UI的需求文档,且由于没有明显的界面可见App.Package,Value_Pa,只能通过日志查看,且日志内容项极多事,会忽略App.Package,Value_Pa的真实来源,这是忽略App.Package描述的第二个情况;

3、很大可能是,做功能tester和做接口tester不是同一个人,他们之间没有太多交流。甚至功能测试工程师根本就不关心这份接口文档的存在。

So,功能测试用例应该补充用例TC_3、用户登录符合登录条件,但App.Package和App.Sign在服务器端验签失败,登录失败

解决方案:1、所有测试都看接口文档和需求文档;2、客户端开发和服务器端开发出交互文档,详细描述输入与输出之间关系,供tester参考测试;3、tester看客户端和服务器端代码。。。

案例2、期待ing... ...

时间: 2024-11-05 03:10:38

功能测试用例深入设计_花样案例汇总的相关文章

功能测试用例的设计

功能测试的目的需要确保在各种场景下,软件的功能都是正常可用的 解释一下我说的功能测试,就是显示的功能性需求:终端用户可见的功能,软件应该做的功能都做了,不应该做的没有做 非功能性需求就是涉及安全性,性能,兼容性 现在很多软件都是先做功能需求,再做性能,兼容,最后考虑安全 1,设计测试用例的方法? 总结下最常用三种方法:等价类,边界值,错误推断法 2,怎样拆解需求? 把一段需求分解成多个需求点,把需求点分解成多个测试点,每个测试点设计许多条测试用例 3,测试用例应该做到哪些点? 1,覆盖全面,设计

从“系统登陆”测试用例案例来分析测试用例的设计

编写测试用例是软件测试工程师最基本的工作.但是如何要编写出好的测试用例,这还真是需要我么对平时的工作认真的进行总结一下. 下面我以"系统登陆"黑盒测试用例设计来分析一下测试用例到底如何来写? 一.案例描述 测试对象:是一个以B/S结构系统的登陆功能点. 功能描述:1.用户在地址栏输入相应的地址,要求限时登陆界面 2.输入用户名.密码和验证码,登陆,系统自动校验,并给出相应提示信息. 3.如果用户名.密码.验证码任一信息未输入,登陆后系统给出相应提示信息. 4.连续3次未通过验证时,自动

测试用例的设计方法

测试用例的设计方法有: 等价类划分方法,边界值分析方法,错误推理方法,因果图方法,判定表驱动分析方法,正交实验设计方法,功能图分析方法,场景设计方法 等价类划分方法: 基本概念: 一.方法简介 1.定义 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 2.划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等

软件测试用例的设计和编写

一.为什么要写测试用例 写测试用例可以让测试的需求覆盖更加全面,让测试工作进行得条理有序,且方便移交和交流 好的测试用例要做到:结构设置和理,case覆盖全面,且具有可执行性,可重复等特点. 二.软件测试文档 1.测试范围列表:需求编号.模块名称.功能名称.复杂度.复用性.自测充分性.是否公用模块.使用频率.优先级 2.测试用例一般包含的要素:用例编号.测试项目.用例标题.优先级(致命.严重.一般.微小.建议).预置条件.输入参数.执行步骤.预期结果 3. 缺陷报告要素:缺陷编号.缺陷标题.严重

测试用例的设计步骤

测试用例的设计步骤作为测试新人,如何实现测试用例的设计一直是我的一个疑惑,在工作中写过几个项目的测试用例,尝试总结一个测试用例的设计步骤.前提:编写测试用例之前我们需要对项目的需求有清晰的了解,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数,作为测试用例的编写者不仅了解要有常见的测试用例编写方法,同时需要了解被测软件的设计.功能规格说明.用户试用场景以及程序/模块的结构.步骤:1.测试需求分析从项目部拿到软件的需求规格说明书后,开始对项目的需求进行分析,通过自己的分析.理解,整理成为测

【tool】浅谈功能测试用例模板

[摘要]本文介绍测试用例一般要素,以及如何根据项目特点设计测试用例模板,用以提高测试用例设计效率和实现测试用例执行结果报告的自动化计算,分析测试用例覆盖率. 测试用例设计和执行是测试工作的核心,也是工作量最大的任务之一,设计良好的测试用例模板能提高测试用例的设计质量,便于跟踪测试用例的执行结果,自动生成测试用例覆盖率报告.这几年测试技术和理论有了长足的发展,就功能测试用例设计要素而言,样式上均大同小异,一般都包含主题.前置条件.执行步骤.期望结果等. 测试用例可以用数据库.Word .Excel

单元测试中测试用例的设计方法

单元测试中测试用例的设计方法 1. 用于语句覆盖的基路径法 基路径法保证设计出的测试用例,使程序的每一个可执行语句至少执行一次,即实现语句覆盖.基路径法是理论与应用脱节的典型,基本上没有应用价值,读者稍作了解即可,不必理解和掌握. 基路径法步骤如下: 1)画出程序的控制流图 控制流图是描述程序控制流的一种图示方法,主要由结点和边构成,边代表控制流的方向,节点代表控制流的汇聚处,边和结点圈定的空间叫做区域,下面是控制流图的基本元素: 以下代码: void Sort(int iRecordNum,

在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?

导语:”在国外,资深的软件测试人员大多是手动测试,他们厉害之处在于测试用例的设计,但在国内,很多测试人员都把自动化测试当成很厉害的资本,为什么?” 偶然在知乎上看到一篇关注度很高的话题,标题如上. 作为一名从业8年有余的软件测试工程师,并且一直在外企做测试的我, 忍不住想发表一些自己的看法和见解. 我觉得在国内,很多公司或者个人把自动化测试当成一个了不起的资本,根本是源于国内大家对代码的无上崇拜,这也造就了国内现在IT互联网行业内一个鄙视链: 开发---> 测试开发--->自动化测试---&g

RabbitMQ基本功能测试用例(Java实现)

为了测试RabbitMQ是否好用,编写了一个由Java语言编写的RabbitMQ基本功能测试用例,仅供参考. 代码说明: 由于实现语言是Java,因此有Java虚拟机(安装了JDK或JRE)即可测试,不需要像Python一样需要安装第三方模块,便于Docker环境下做简单测试.在此测试用例用用到了amqp-client-3.x.x.jar库,可以自行下载. 为实现一个java源文件中实现收与发(编译后还是3个Class文件),在main函数中起了两个线程,一个负责发,一个负责收,用来测试Rabb