接口测试用例生成工具介绍及应用

Posted 2023-05-24 自先沉稳,而后爱人

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了接口测试用例生成工具介绍及应用相关的知识，希望对你有一定的参考价值。

目前，接口测试是开展项目测试实施过程中非常重要的环节，对于新增接口和修改接口更是需要做到应测必测，但是在实施过程中普遍存在一些问题，经分析总结如下： 1.耗时长：接口测试整体流程较长，对每个字段都需要进行各种校验，且人工进行基础性字段验证的过程极为痛苦重复。 2.无数据留存：每次接口测试所使用的完整的测试用例、测试数据、测试结果不易留存，不方便复测和排查问题。 3.容易遗漏：纯手工测试，受制于测试人员的能力、经验，测试的覆盖度无从追溯，且枯燥乏味的字段校验极容易遗漏。基于以上问题，我们需要研发一种可以通过预配置实现、基于经验积累、满足多种测试要求的接口测试工具。

目前，接口测试是开展项目测试实施过程中非常重要的环节，对于新增接口和修改接口更是需要做到应测必测，但是在实施过程中普遍存在一些问题，经分析总结如下：

1.耗时长： 接口测试整体流程较长，对每个字段都需要进行各种校验，且人工进行基础性字段验证的过程极为痛苦重复。

2.无数据留存： 每次接口测试所使用的完整的测试用例、测试数据、测试结果不易留存，不方便复测和排查问题。

3.容易遗漏： 纯手工测试，受制于测试人员的能力、经验，测试的覆盖度无从追溯，且枯燥乏味的字段校验极容易遗漏。

基于以上问题，我们需要研发一种可以通过预配置实现、基于经验积累、满足多种测试要求的接口测试工具。

工具实现思路
本章将通过对接口测试的步骤和用例组装过程进行拆分来介绍工具实现的总体思路。

图一接口用例自动化生成的总体思路

工具将接口测试划分为三个阶段，分别为准备阶段、执行阶段以及后续工作。准备阶段主要是准备接口测试所需要素和配置，执行阶段主要为工具自动化执行生成测试用例、数据和接口测试的执行，后续工作主要为生成擎云所需要的自动化测试文件，对执行结果进行断言判断，手工录入tfs进行缺陷跟踪等。

其中，工具将接口测试的重点聚焦于接口测试的准备阶段，通过air接口文档或自定义格式接口文档进行，通过配置“用例集”与参数“组装规则”生成执行阶段所需要的完备测试用例与数据，然后通过工具自动进行执行。

图二接口用例自动化生成的具体细节

工具将接口用例组装过程拆分成接口层、参数层、用例集组装层、兜底测试组装层、参数组装规则层这几部分，下面对这几层进行详细的介绍。

1.接口层：接口层中包含的是接口的整体信息，主要有接口的类型（post/get），接口所包含的参数，接口可能所需要的header头等信息。该部分信息可以通过读取air接口文档或自定义接口文档或者手工录入的方式进行维护。

2.参数层：该层聚焦于接口中的某个具体参数，如图二中的单个“phoneNo”参数，该层主要为了聚焦单个参数并将其送至后续的“用例集组装层”、“兜底测试组装层”进行衍生和变形。

3.用例集组装层：该层通过预先配置好的“用例集”对参数进行组装，从而生成单个参数所需要衍生出的测试用例与数据。譬如某条用例集“反例/首位为1，小于11位数字/1341111111”，那么工具会根据该条用例衍生出“phoneNo”:“1341111111”的数据和“被测接口phoneNo参数首位为1，小于11位数字”的反向测试用例。

参数与用例集的匹配有自选和工具根据参数名进行匹配两种方式，关于“用例集”这一概念的具体设计思路我们将在下文进行详细解释。

4.兜底测试组装层：所谓的兜底测试，就是指我们在接口测试中，需要反复的对每一个字段都进行测试的基础性验证。如参数为空、为空格的情况，参数超出和少于长度限制的情况，参数类型与规定类型不同的情况。该种验证极易检测出代码中的异常捕获缺失与代码异常错误泄露的缺陷，但人工进行该种检测极为枯燥重复，所以需要使用工具对参数进行兜底用例的衍生与测试。

兜底测试组装层的用例和数据的衍生规则与用例集组装层是类似的，不同的是兜底测试组装层会对每个参数都进行相应的兜底测试，兜底测试也不需要选择相应的用例集。

5.参数组装层：参数组装层主要是为了将参数层衍生出的众多单个参数的案例根据一定逻辑和规则组装到一起，最终形成完整的测试报文与测试案例，目前使用的参数组装规则主要有以下三种：控制变量法、正交法、parwise法。

关于“参数组装规则”这一概念的具体设计思路我们将在下文进行详细解释。

用例集
用例集是自动化接口测试的“血肉”，是完成数据预配置、经验积累的实现方式，是对接口数据进行衍生和测试的基础。用例集中包含了测试系统、参数属性、内容、用例内容的信息，下面我们对这几个字段进行详细解释。

图三最小用例集

1.测试系统：标志了该用例集所在的测试系统，由于不同系统中所使用的测试数据、测试考量点不同，所以用例集需要根据系统对接口参数进行匹配，同时标识系统也方便了同系统的测试人员对数据进行分享和复用。

2.参数属性：标志了该用例集为参数类型还是参数名，如果为参数名的话，就当作普通的用例集对该参数名进行优先匹配，如果为参数类型的话，工具就会自动对该系统内该种参数类型的参数进行兜底测试。

3.内容：与参数属性相对应的参数名称或参数类型。

4.用例内容：包含了用例描述、正反向类型和测试数据。其中，测试数据为非必选项，如果测试数据为空的话，那么仅可以生成接口测试用例而不可以生成接口测试报文。

图四不同接口测试维度的测试颗粒度与用例集维护难度关系图

工具生成用例的测试多样性和覆盖度离不开我们对用例集的设计。通常，我们设计接口测试用例集从以下三个角度进行。

1.兜底测试：指每个参数都需要进行校验的情况，如参数为空，参数过长等，该种情况往往通过设置参数类型的用例集和工具自动识别来进行测试，兜底测试的数据几乎不会改变，也不需要进行维护。

2.功能测试：指满足功能需求，有一定功能含义的测试用例，如对卡号这个参数来说，已销户的卡号对大多数交易来说就是一个有功能含义的反例，对于功能测试，大多数测试用例与数据是有一定的时效性和可复用性的，但对数据的维护仍需要一定成本，对于经常变动的数据，目前的解决方案是通过sql语句进行动态提取。

3.安全测试：满足横向越权、竖向越权等安全测试要求的测试用例，测试人员需要对越权类场景进行识别与设计，同时对越权测试所使用数据也需要进行精心的构造，一旦完成了对数据的构造，那么安全测试的测试用例和数据也可以看成一种特殊的“功能测试”添加进对应参数的用例集中。

参数组装规则
如果说用例集是自动化接口测试的“血肉”的话，参数组装规则就是自动化接口测试的“骨”，规则将各个参数所衍生出的用例根据一定的逻辑紧密联系到一起，最终形成覆盖度高却不冗余的测试用例。目前支持的规则主要有以下三种。

图五使用控制变量法进行自动化接口测试

1.控制变量法：功能测试的经典方法，控制其他参数不变，修改某一参数进行衍生用例进行测试。

2.正交法：将所有单个参数衍生出的全部用例进行正交组合，可以覆盖测试中的所有情况。

3.Parwise法：基于Pairwise统计学的用例计算方法，原理为双因子之间进行正交，实际为对正交法的一种科学的裁剪，适合没有明确正反向的高效接口自动化测试。

推广使用效果
通过配置用例集我们实现了对测试经验的积累，对测试场景的全覆盖。通过配置用例生成规则，我们保证了生成用例的覆盖度高而又不冗余，最终完成我们对接口测试的高效率、高覆盖度、高质量的要求。

图六部分系统推广使用效果图

该工具目前已在掌银信用卡频道、微银行信用卡模块、星云、PDS等26个系统模块中使用，共对304个接口生成测试用例3638条。

最后：这里有我建立的一个专门交流软件测试方面问题的学习群，里面也有很多大公司的技术大牛。很多时候，技术大牛的几句话就会让我们醍醐灌顶，少浪费时间，如果想要多跟有经验的人学习，就找我加入我的软件测试交流群，以后有工作的内推机会都相互推荐一下，毕竟我们是关系社会。

软件测试技术交流群社：786229024 等待你的加入... 大家可以一起探讨交流，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路。

❤️熬夜7天肝出5万字禅道/缺陷报告/测试报告/接口测试及用例/Fildder超详细总结❤️

一、禅道

一、测试工具背景

当测试环境搭建完成后，测试人员将在自己搭建的环境上执行测试用例，开展测试工作。测试人员在执行测试用例的过程中，如发现实际结果与预期结果不一致，则意味着出现Bug (缺陷、错误、问题)。当测试人员发现了Bug之后，就需要把Bug提交给开发人员进行修复。那测试人员应如何记录一个Bug呢?测试人员通过什么工具把Bug转发给开发人员的呢?测试人员提交完Bug后又如何做回归测试呢?本章将对提交Bug所涉及的各种问题进行详细介绍。提交Bug不仅仅是测试人员价值的体现，也是测试人员迓开发人员沟通的重要桥梁，Bug 的数量和质量将会对软件质量的改善起到重要的推动作用。

二、测试管理工具

测试管理工具是指在软件开发过程中，对测试需求、计划、用例和实施过程进行管理、对软件缺陷进行跟踪处理的工具。通过使用测试管理工具，测试人员或开发人员可以更方便地记录和监控每个测试活动、阶段的结果，找出软件的缺陷和错误，记录测试活动中发现的缺陷和改进建议。通过使用测试管理工具，测试用例可以被多个测试活动或阶段复用，可以输出测试分析报告和统计报表。有些测试管理工具可以更好地支持协同操作，共享中央数据库，支持并行测试和记录，从而大大提高测试效率。

三、测试工具介绍

目前市场上主流的软件测试管理工具有：TestCenter（泽众软件出品）、TestDirector（MI公司TD，8.0后改成QC），TestManager（IBM），QADirector（Compuware），TestLink（开源组织），QATraq（开源组织），oKit (统御至诚)，Jira 管理工具，禅道。

测试管理包含的内容有：测试框架、测试计划与组织、测试过程管理、测试分析与缺陷管理。

四、禅道介绍

1. 禅道简介

禅道由青岛易软天创网络科技有限公司开发，国产开源项目管理软件。它集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款专业的研发项目管理软件，完整覆盖了研发项目管理的核心流程。

禅道官方网站：http://www.zentao.net/

官网使用步骤详解：http://www.zentao.net/book/zentaopmshelp/38.html

2. 禅道项目管理系统的特点

第一款完整涵盖产品管理、任务管理、测试管理的开源管理软件，使用一个软件解决项目管理核心问题。

基于国际流行的敏捷管理方式scrum。

B/S Broswer/Server C/S Client/Server 架构，方便部署、使用。

概念简单，容易上手。

开源的项目管理软件，可自由进行定制，修改。

免费的项目管理软件，降低企业的投入成本。

自主的开发框架，预留扩展机制，通过第三方的插件扩展获得更多的功能。

3. 禅道系统的功能列表

产品管理：包括产品、需求、计划、发布、路线图等功能。

项目管理：包括项目、任务、团队、版本、燃尽图等功能。

质量管理：包括bug、测试用例、测试任务、测试结果等功能。

文档管理：包括产品文档库、项目文档库、自定义文档库等功能。

事务管理：包括todo管理，我的任务、我的Bug、我的需求、我的项目等个人事务管理功能。

组织管理：包括部门、用户、分组、权限等功能。

统计功能：丰富的统计表。

搜索功能：强大的搜索，帮助您找到相应的数据。

扩展机制，几乎可以对禅道的任何地方进行扩展。

api机制，所见皆API，方便与其他系统集成。

4. 用户角色

image.png

禅道管理软件中，核心的三种角色：产品经理、研发团队和测试团队，这三者之间通过需求进行协作，实现了研发管理中的三权分立。其中产品经理整理需求，研发团队实现任务，测试团队则保障质量，其三者的关系如下图：

image.png

5.禅道的安装

5.1.双击文件，安装(解压)

image.png

注意：必须安装在英文目录下。

5.2.查看目录

image.png

点击服务：apche可以选择80或88端口，mysql可以选择3306或3308端口

点击访问禅道，页面会自动跳转到禅道的页面。

也可以直接访问http://localhost/zentao/ 管理用户：admin，密码 123456

备注：如果你启动的是88端口，请使用http://localhost:88/zentao来访问。

image.png

5.3. 登录

image.png

5.4.登录成功

第一次登录成功自动跳转修改密码界面。

image.png

五、禅道操作

人员管理

权限分配

产品控制

项目控制

编写用例

提交缺陷(bug)

1. 人员管理

使用管理员（admin）登录后将出现的页面

image.png

1.1.添加部门

进入“组织” → “部门” 的页面，新建三个部门并保存

image.png

1.2.添加用户

进入“组织” → “用户” → “+添加用户”的链接页面，添加“项目经理”账户并保存，邮箱和源代码账号可以为空，其中“您的系统登录密码”我管理员admin的密码。

image.png

1.3.添加产品经理

image.png

1.4.添加开发人员

image.png

1.5.添加测试人员

image.png

账号：hgx hgx123457

mayan mayan123457

wangqing wangqing123457

1.6 添加成功展示效果

image.png

2. 创建产品

在禅道中，产品是一切的核心，所有的东西基本上都是围绕产品展开。那么如何创建第一个产品呢？

产品经理登录禅道，进入“产品” → “+添加产品”的链接页面，新建产品并保存。

image.png

在这个页面中，产品名称和产品代号是必填的。比如，我们创建一个“测试产品”，代号为test。点击保存。

3.添加需求

添加了产品之后，需要创建一个需求。

所谓需求，就是来描述一件事情，如模板：作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>。这样的需求，有用户角色，有行为，也有目的和价值所在，非常方便与团队成员进行沟通。

创建需求的步骤如下：

1.产品经理登录禅道。

2.进入产品视图。

3.在页面右侧，有“新增需求”菜单，点击菜单，出现新增需求的页面。

4.需求的创建页面，预计工时和需求名称都为必填项。预计工时，也就是你估计完成这个需求大约多少个小时。

image.png

注意：由谁评审，选择不需要评审，这样新创建的需求状态是激活状态。只有激活状态的需求才能关联到项目中，进行开发。

4.创建项目

创建了产品和需求以后，需要创建一个项目，来完成这个需求。在实际的情况中，肯定会有多个需求。那么如何确定一个项目中该做哪些需求呢？应该对需求进行优先级的排列，并根据项目的周期和参与的人手来决定。

4.1 项目经理登录禅道，点击“添加项目”

image.png

4.2 点击创建项目中的“保存”，系统将自动跳转到下图：

image.png

4.3 点击“设置团队”链接进入“团队成员”页面，如下图：

image.png

4.4 点击“团队管理”链接进入“团队管理”页面，添加团队成员并保存，如下图：

image.png

4.5 进入“项目” → “需求” → “+关联需求”的链接页面来关联该项目的需求并保存，如下图：

关联需求.png

单击保存.png

4.6单击图中的“保存”按钮后看到积云商城第一期项目所关联的需求，如图：

保存.png

4.7单击上图中的“批量分解”的链接按钮进入“批量创建”页面，并进行任务指派、保存，如下图：

关联需求成功.png

批量创建任务.png

5. 开发人员领取任务，并提交测试版本

5.1. 查看任务

开发人员登录禅道系统，进入“我的地盘” → “任务” →的链接页面就可以查看项目经理分配的任务

查看任务.png

5.2. 完成任务

当开发人员完成某一项任务时，可以单击右侧完成按钮，在弹出的对话框中设置消耗的事假并保存即代表改任务完成，如下图：

完成任务.png

5.3. 创建版本

当开发人员全部完成任务时，便可提交相应的测试版本，进入“项目” → “版本”的链接页面进行版本的创建，如下图：

创建版本.png

5.4. 点击“+创建版本”链接进行版本创建，并保存，如下图：

创建测试版本.png

6. 通过禅道系统来追踪Bug

在上一节中开发人员已经通过禅道系统提交了可测试的版本，接下就由测试人员来执行测试，并提交Bug。

6.1. 查看任务

测试人员登录禅道系统，进入“项目” → “任务” → 的链接页面，此时就可以查看项目经理分配给测试人员的任务，如下图：

查看任务.png

6.6.2. 提交bug

假设测试人员已经完成测试用例设计并测试用例执行完毕，并且在测试中发现了问题，那么测试人员就要通过禅道提交Bug给开发人员。

测试人员，进入 “测试” → “Bug” 的链接页面，如下图：

提交bug.png

6.3. bug提交

单击“提交bug”链接进入到提交Bug的页面，此时可以提交Bug并进行相应保存，如下图：

Bug提交.png

image.png

6.4. 查看bug

开发人员登录禅道系统，进入 “测试” → “Bug”的链接页面，此时就可以看到测试人员提交的bug，如下图：

image.png

6.5. 完成解决

开发人员修复好该bug之后，就会单击“解决”按钮，在弹出对话框中设置解决信息并保存，那么此时Bug就已经解决完成，如下图：

image.png

6.6. 关闭Bug

测试人员登录禅道系统，并验证所提Bug是否被开发人员修复好，如经验证，此Bug已被解决，将会弹出“关闭”按钮，并备注相关信息，如下图：

image.png

点击“保存”后，“解决”按钮变为灰色，点击“关闭”，弹出如下图：

image.png

6.7. 查看状态

当测试人员再次查看此Bug时，此Bug为关闭状态，如图所示：

image.png

6.8. 如果没有解决

如果测试人员验证此bug发现并没有解决，就会再次编辑此bug，并将bug的状态设置为激活状态并重新指派给开发人员。

至此，bug的基本流程已经完成。

7. 创建发布

当某一期的项目结束后，如果这一期的版本可以对外发布，此时产品经理的一个职责就是创建一个发布。创建发布的意义在于告知相关部门人员，有新产品上线，可以让相关人员继续开展工作。

创建发布的步骤：

1.产品经理进入产品视图，选择“发布列表”。

2.点击【创建发布】，进入创建发布页面。

3.填写必填项：发布名称、Build和发布日期。

注意：发布的前提是要创建一个Build。

image.png

8. 测试团队

8.1.Bug处理

测试 → bug → 提bug → 生成bug列表

8.2.测试用例操作

1.1.4.修改用例

用例操作

1.1.5.执行测试用例

1.1.6.设置第三个测试用例执行失败

1.1.7.可以直接将执行失败的用例转成bug

六、禅道使用流程总结

人员管理（admin）：添加部门 → 添加用户

创建产品（产品经理）：产品 → 添加产品

添加需求（产品经理）：产品 → 需求 → 提需求

创建项目（项目经理）：项目 → 添加项目 → 自动跳转（选择设置团队）→ 团队管理 → 给团队配人

关联需求（项目经理）：项目 → 需求 → 关联需求 → 勾选任务

批量分解（项目经理）：在任务右侧 → 选择批量分解 → 批量分解

查看任务（开发人员）：我的地盘 → 首页查看任务 → 点击任务数量进入任务列表 → 选择完成任务

创建版本（开发人员）：项目 → 版本 → 创建版本

测试Bug（测试人员）：测试 → bug → 提bug

解决bug（开发）：测试 → bug → 确认 → 完成

再次测试（测试人员）：测试 → 再次测试 → 如果解决的，点击关闭，否则重新编辑

创建版本（产品经理）：产品 → 发布 → 创建发布 → 完成

七、案例练习

要求：

公司名称：1802C科技有限公司，

部门：开发，测试，产品，

用户：后台开发2个人，产品2个人，测试1个人，前端1个移动端1个运维1个

产品：社区商圈项目

Web端一级功能，二级功能

App端一级，二级

二、缺陷报告

8.1 定义

概述：标识并描述发现的缺陷，具有清晰、完整和可重现问题所需的信息的文档。

理解：测试人员发现缺陷，将缺陷记录在《缺陷报告》中，通过缺陷报告将缺陷告知给开发人员，并对缺陷进行跟踪和管理。缺陷报告是测试人员与开发人员之间重要的沟通方式。

8.2 什么是缺陷

软件缺陷就是通常说的Bug，它是指在软件中（包括文档和程序）存在的影响软件正常运行的问题。

软件未达到产品说明书标明的功能，如一个即时通讯App不能聊天。

软件出现了产品说明书指明不会出现的错误，如高考不带身份证。

软件功能超出产品说明书指明的范围，如即时通讯App做了一个地图功能。

软件未达到产品说明书虽未指出但应该达到的目标，如一个账号的密码是明文。

软件难以理解、不易使用、运行速度缓慢或者从测试人员的角度看最终用户认为不好，如一个即时通讯App无法找不到聊天界面。

8.3 软件缺陷产生的原因

需求不明确和变更

软件需求不清晰或者开发人员对需求理解偏差，导致软件设计时偏离用户的需求目标，造成软件功能或特征上的缺陷。此外，开发过程中客户频繁更新需求也会影响软件最终的质量。

软件结构复杂

编码问题

项目期限短

使用新技术

8.4 导致软件缺陷的典型错误

错误软件缺陷

客户与软件开发人员之间交流困难缺少预期的软件功能

开发人员未注意到代码中的逻辑错误单击按钮没有进行任何操作

开发人员忘记了对文件复制代码进行错误检查复制了一份被破坏的文件，导致软件崩溃

开发人员没有理解客户的情况软件不能满足客户的要求

8.5 软件缺陷分类

软件缺陷分类.png

8.6 缺陷报告的核心要素

八项：缺陷编号、缺陷状态、缺陷标题、重现步骤、严重程度、优先级、缺陷类型、测试环境。

缺陷编号

缺陷的唯一标识符

缺陷状态

缺陷跟踪过程的进展情况

缺陷处理流程.png

缺陷状态.png

新建：刚发现的缺陷

已指派：已经由测试人员将缺陷指派给开发人员进行处理

已打开：开发人员正在修复缺陷

已修复：开发人员完成缺陷修复，还未进行回归测试

已拒绝：发开人员拒绝修复

已延期：对缺陷进行延缓处理

已关闭：由测试人员回归测试后，缺陷不存在了

重新打开：由测试人员回归测试后，发现缺陷任然存在，

缺陷标题

缺陷的概述，描述问题本质

重现步骤

①一步一步描述再现缺陷的操作步骤

②预期结果

③实际结果

严重程度

缺陷对软件系统的影响程度

优先级

修复缺陷的重要性或紧迫性

缺陷类型

根据缺陷产生的来源和根源划分出的缺陷种类

功能、配置、安装、性能缺陷

测试环境

测试环境配置，包括软件环境和硬件环境

8.7 缺陷报告编写技巧

1、对错误的描述要做到简洁、准确、完整，揭示错误实质2、尽量使用短语和短句，避免复杂句型句式3、每个软件问题报告只书写一个缺陷或错误4、明确指明错误类型和严重程度5、每一个步骤尽量只记录一个完整操作6、复现的操作步骤要完整，准确，简短7、可以附加必要的错误特征图像8、可以附加必要的测试用例

8.8 缺陷报告模板

报告缺陷模板.png

三、测试报告

9.1 引入

回归测试工作完成后，就代表着产品即将上线，此时每个测试人员都需要针对自己所测试的模块出具一份测试报告，以此来总结测试结果。测试报告可以说是软件测试人员在测试阶段的最后一份输出文档。那么初级软件测试工程师应该如何撰写测试报告呢？

9.2 定义

记录测试的过程和结果，对发现的问题和缺陷进行分析的文档

9.3 测试报告分类

阶段测试报告

整体测试报告

9.4 报告内容

9.4.1 概要

编写目的

①对测试报告进行相应的解释

②对项目进行简介

③对于测试任务进行简单描述，要测试哪些内容

测试人员

类似于测试计划中的人员分工，简单描述日期等

测试环境

软件和硬件环境

9.4.2 测试过程

阶段测试报告：

1、测试进度情况

2、用例执行情况

3、缺陷统计

总体测试报告

1、各版本的测试情况

2、各版本的缺陷统计

9.4.3 缺陷分析

1、按照缺陷级别

2、按照功能模块

3、按照轮次

4、缺陷总数

5、缺陷类型

6、缺陷趋势

9.4.4 测试总结

1、测试结论

通过/不通过；

需求覆盖率100%，测试用例执行过率100%；

缺陷：致命=0，严重=0，一般=0，提示≤10%

2、风险分析

测试进度、人员安排导致的风险；

测试内容考虑范围之外导致的风险；

测试环境不全面导致的风险。

3、遗留问题

遗留问题描述、等级、处理方法。

9.5 测试报告模板

一、概要

1、编写目的

背景

本报告为积云商城1.0版本的测试报告，用于记录测试过程，总结测试情况，分析测试数据，归纳测试工作过程中的问题与遗留的风险，给出相应的测试建议供后续参考。

积云商城是Android平台的电商应用，1.0版本是首次发布版本。包含登陆/注册、商品展示/搜索、购物车、订单管理、支付等功能。

测试内容

对积云商城1.0版本进行了功能、性能、易用性、兼容性测试。功能测试覆盖以上所有功能；对登陆和订单管理功能进行了性能测试；兼容性测试覆盖了Android 6，7，8，9版本，华为、小米等主流厂家机型。

2、测试人员

测试工作6月1日开始，6月15日测试完成，测试组4人，总工作量60人天。人员分工如下表：

姓名角色职责

测试经理测试负责人制定测试策略，编写测试计划，设计测试用例，编写测试报告

工程师A测试工程师制定性能测试方案，进行性能测试，编写性能测试报告

工程师B测试工程师设计测试用例，测试执行

3、测试环境

配置应用服务器数据库服务器测试机

硬件配置CPU：双核1.8G主频 Intel(R) Xeon(R) CPU 2GHz

内存：4G

CPU：双核1.8G主频bIntel(R) Xeon(R) CPU 2GHz

内存：4G

CPU：1CPU（双核），Intel(R) Pentium(R) CPU E2180 2.0GHz

内存： 8G

软件配置Windows2008 server

Tomcat 6.0 (功能测试)

Websphere 7.0(功能、性能测试）

CentOS7、Oracle 11g R2Windows7+IE11，性能测试工具：Loadrunner11

二、测试过程

1、测试进度

测试任务责任人启动时间计划完成时间完成时间备注

测试计划/评审测试经理2019.5.272019.5.272019.5.27

需求分析测试工程师2019.5.282019.5.282019.5.28

测试用例设计/评审测试工程师2019.5.292019.6.42019.6.6需求变动，用例设计延迟2天完成。

2、用例执行情况

模块用例总数执行用例数通过用例数未通过用例数阻塞用例数

购物车75737032

支付75707005

合计20019318857

执行率=执行用例数/用例总数

通过率=通过用例数/执行总数

3、缺陷统计

1.0版本共发现缺陷21条，新增bug10个，修复bug17个，遗留bug4个。

模块名称bug总数新增bug数修复bug数遗留bug数

商品4331

合计2110174

修复率=bug修复/bug总数

三、缺陷分析

1、缺陷级别分析

缺陷级别.png

解析：严重缺陷、一般缺陷、轻微缺陷各占总缺陷的5%，轻微缺陷占85%。

2、缺陷模块分析

image.png

解析：bug共21条，其中17条存在于登录/注册模块，开发人员需要着重对于该模块进行自测。

3、缺陷类型分析

按照版本统计

按照趋势统计

四、测试总结

1、测试结论

内容：通过/不通过，执行率、通过率、修复率、遗留问题的级别以及数量。

示例：积云商城1.1测试通过，可以上线。测试用例执行率100%，测试用例通过率95%，未通过的测试用例不影响业务运行。严重缺陷为0，一般缺陷为0，轻微缺陷小于10%。

2、风险分析

编号风险描述规避方法及建议

3、遗留问题

编号缺陷描述缺陷等级处理方法

四、接口测试以及用例编写

11.1 接口

11.1.1 接口概述

定义：接口就是API（Application Programming Interface，应用程序接口），是一个软件或服务对外提供的接口，别人只要调用这接口，而内部如何实现，不需要关心。你只要按照要求进行接口调用即可。

外部系统与系统之间以及内部各子系统之间的交互点。包括外部接口、内部接口。

举例：

假设物流中“货物”是数据，存放货物的“总仓库”是数据库，“店铺”是我们的网站、App。页面上显示的内容、数字，以及用户的操作请求和结果都是需要不停搬运的“货物”——数据，则负责调配分配打包的中转站就是API，快递小哥直接从中转站取货就好。

作用：对于软件提供商来说，留出API，让别的应用程序来调用，软件才能发挥最大的价值，才能更有生命力。（同时别人也看不见代码，不伤害商业机密。）

对于应用开发者来说，有了开放的API，就可以直接调用多家公司做好的功能来做自己的应用，不需要所有的事情都自己操刀，节省精力。

11.1.2 接口的表现形式

客户端要先操作服务端资源，首先要找到服务端提供的接口，然后才能向服务端发送资源请求，那么何为服务端接口呢？其实就是一个地址（URL），比如：

http://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1

1615302590(1).png

采用的协议(http:)：一般来讲网址中第一个“:”前面的就是该网址所采用的协议。这里的HTTP就是个协议。HTTPS是HTTP的安全版本，HTTPS在HTTP的基础对传输的数据进行了加密和签名，以保证数据传输的安全性。我们平常打开两页的时候会看到网址前面都有一个HTTP或HTTPS，这就是告诉你，你在向服务器发送此请求的过程中要遵循的协议是HTTP或HTTPS (也就是规则)。

服务器地址(//www.qubaobei.com)：以双斜杠“//”开头，后面跟的就是这个服务器的地址，专业术语叫域名。

请求资源路径(/ios/cf/dish_list.php) ：表示你要请求的资源在该服务器下/ios/cf/dish_list.php的路径下。

参数（?stage_id=1&limit=20&page=1）：参数可以找到具体内容，和路径之间使用“?”隔开，参数之间使用“&”隔开。参数是以键值对的形式表现出来的。

把此URLhttp://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1称为食品模块个接口，也称为接口地址。

11.2 接口文档

接口文档展示

11.2.1 封皮

封面最好是本公司规定的封面，有logo，内容标题，版本号，公司名称，文档产生

日期。（错误地方在于，文档的标题要和页眉中的标题一致）

11.2.2 修订历史

表格形式较好些。包括：

版本，修订说明，修订日期，修订人，审核时间，审核人。

11.2.3 接口信息

接口调用方式，是post方式还是get方式，接口地址，别人需要线上的哪个地址就写哪个。（自己提前测试好线上的这个接口，是否有其他问题，千万别犯低级的错误，尤其是某个字母写错）

11.2.4 功能描述

一定要清晰的描述接口功能。（不要遗漏一些细节，比如接口获取的信息不包括哪些，哪些要写明白）

11.2.5 接口参数说明

每个参数都要和实际中调用的一样，包括大小写；参数的含义言简意赅的说明；格式是string 还是int 还是long等格式（例如参数为@RequestParam("appKey") StringappKey, @RequestParam("randomId") Integer randomId）；说明部分，说明参数值是需要哪个公司提供，并详细说明参数怎么生成的，例如时间戳，是哪个时间段的；参数是否必填，一些参数是必须要有的，有些是可选参数，一定要注意写清晰。

11.2.6 返回值说明

1、有一个模板返回值，并说明每个返回参数的意义。

2、提供一个真实的调用接口，真实的返回值。

注：现实工作中，对接口有疑问要及时跟同事交流。

11.3 接口测试的概念

11.3.1 概念

测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。

11.3.2 接口测试本质

实质就是数据的传输和接受，传输的是接口地址中的参数，接受的是文本字符串，然后对比文本字符串是否正确。

11.4 接口测试的目的和原理

11.4.1 目的

测试接口的正确性和稳定性。

11.4.2 原理

接口测试的原理是通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一个过程。

11.5 常用接口测试工具

11.5.1 典型商业工具：

LoadRunner（LR）：一款商业性能测试工具，用来做接口测试，很好很强大，但是配置比较麻烦。

SoapUI：开源测试工具，通过soap/http来检查、调用、实现Web Service的功能/负载/符合性测试；该工具既可作为一个单独的接口测试工具使用，也可利用插件集成到Eclipse，maven2.X，Netbeans 和intellij中使用。了解就可以了，基本已经不用了。

11.5.2 典型开源工具

Jmeter ：一款开源的接口测试工具，操作简单，方便，既有jdbc request操作数据库数据，也有http request和soap request应对测试

13.5.3 扩展插件

postman：谷歌浏览器的扩展工具，主要用来做接口测试，谷歌商店中选中安装，界面同poster差别不大，界面简洁。

13.6 接口测试应该测什么

13.6.1 单一接口

单一接口功能的测试主要测试返回的数据结构是否和接口文档给出的一致，接口的正常功能是否完成，接口的参数检查测试，接口的异常测试。

13.6.2 组合接口

定义：组合接口测试主要是通过组合多个单一接口，来测试一个业务场景

案例：测试购物网站的一个下单的功能，那么因为在下单之前还有一些流程，所以要测试一个场景。

测试：搜索商品 --> 选中商品 --> 添加进购物车 --> 提交订单 -->支付

（提交订单时还涉及到地址的选取等）

注：涉及到如果使用从cookie或者session在本例中的区别：如果使用cookie加入购物车，那么换一台电脑购物车里的商品就不存在了，但如果使用的是session，购物车里面的东西就一直存在，即：cookie是本机作用的，session不止于本机作用。

13.6.3 结构检查

（1）检查返回值的结构是否正确，如是json类型还是xml类型的数据

（2）字段名称是否正确等

XML和JSON都使用结构化方法来标记数据

13.7 接口测试内容

13.7.1 功能逻辑

通过查数据库或缓存等验证数据是否处理正确。

通过其他辅助途径进行验证

13.7.2 异常测试

接口测试中主要测试接口正常逻辑，但仅逻辑测试不能保证数据的安全及程序接口在异常情况下的逻辑处理的正确性。

13.7.3 路径测试

当被测接口的实现方法中，判断逻辑复杂分支多，且判断中又调用了其他的接口，此时必须要进行路径覆盖测试。

13.7.4 其他异常场景

研发的项目，有些项目是底层使用的系统，根据项目特点，可能会存在特殊的异常场景。

例如：支付的异步操作，支付消息重试等

11.8 测试案例

11.8.1 get请求

11.8.2 post请求

Postman使用

13.9 接口测试用例模板

接口测试用例模板.png

五、Fiddler

14.1 Fiddler简介

14.1.1 简介

Fiddler是位于客户端和服务器端之间的代理，也是目前最常用的抓包工具之一。它能够记录客户端和服务器之间的所有请求，可以针对特定的请求，分析请求数据、设置断点、调试web应用、修改请求的数据，甚至可以修改服务器返回的数据，功能非常强大，是web调试的利器。

14.1.2 功能

1、能够监听http/httpS的流量，可以截获从浏览器或者客户端软件向服务器发送的http/https请求；

2、对截获之后的请求，我们还能够查看请求中的内容；

3、伪造请求。不仅可以伪造客户端的请求，还能够伪造服务器的响应。——该功能能够方便我们进行前后端的调式。

4、测试网站的性能；

5、解密https的外部会话。因为https本身是一种加密的协议，通过fiddle我们可以进行解密操作；

6、提供第三方扩展插件，满足更多需求。

14.1.3 Fiddler工作原理

fiddler原理.png

14.2 Fiddler下载安装

下载：打开官网

安装：

汉化：

14.3 Fiddler界面介绍

fiddler界面.jpg

Fiddler界面从上到下分为：菜单栏、工具栏、回话列表、功能页签、命令行，状态栏六大板块

file capturing = F12 = 左下角capturing

14.4 菜单栏

14.4.1File菜单

1、Capture Traffic：可以控制是否把Fiddler注册为系统代理。

2、New Viewer：打开一个新的fiddler窗口

3、Load Archive：用于重新加载之前捕获的以SAZ文件格式保存的数据包。

4、Save：支持以多种方式把数据包保存到文件中。

5、Import Sessions...：支持导入从其他工具捕获的数据包，也支持导入以其他格式存储的数据包。

6、Export Sessions...：把Fiddler捕捉到的回话以多种文件格式保存。

7、Exit：取消把Fiddler注册为系统代理，并关闭Fiddler

14.4.2 Edit菜单

1、Copy：复制会话。

2、Remove：删除会话。

3、Select All：选择所有会话。

4、Undelete：撤销删除会话。

5、Paste as Session把剪贴板上的内容粘贴成一个或多个模拟的会话。

6、Mark：选择一种颜色标记选中会话。

7、Unlock for Editing 解锁会话。

8、Find Session...打开Find Session窗口，搜索捕获到的数据包。

14.4.3 Rules菜单

1、Hide Image Request：隐藏图片回话。

2、Hide CONNECTS：隐藏连接通道回话。

3、Automatic Breakpoints：自动在[请求前]或[响应后]设置断点。Ignore Image触发器控制这些断点是否作用于图片请求。

4、Customize Rules...：打开Fiddler脚本编辑窗口。

5、Require Proxy Authentication：，要求客户端安装证书。该规则可以用于测试HTTP客户端，确保所有未提交Proxy-Authorization请求头的请求会返回HTTP/407响应码。

6、Apply GZIP Encoding：只要请求包含具有gzip标识的Accept-Encoding请求头，就会对所有响应使用GZIP HTTP进行压缩（图片请求除外）。

7、Remove All Encoding：删除所有请求和响应的HTTP内容编码和传输编码

8、Hide 304s：隐藏响应为HTTP/304 Not Modified状态的所有回话。

9、Request Japanese Content：选项会把所有请求的Accept-Encoding请求头设置或替换为ja标识，表示客户端希望响应以日语形式发送。

10、User-Agents：把所有请求的User-Agent请求头设置或替换成指定值。

11、performance：模拟弱网测试速度。

14.4.4 Tools菜单

1、Options...：打开Fiddler选项窗口。

2、WinINET Options...打开IE的Internet属性窗口

3、Clear WinINET Cache：清空IE和其他应用中所使用的WinINET缓存中的所有文件。

4、Clear WinINET Cookies：清空IE和其他应用中所发送的WinINET Cookie

5、TextWizard...：选项会启动TextWizard窗口，对文本进行编码和解码。

6、Compare Session：比较回话。

7、Reset Script：重置Fiddler脚本。

8、Sandbox：打开http://webdbg.com/sandbox/

9、View IE Cache:打开IE缓存窗口。

14.4.5 View菜单

1、Show Toolbar：控制Fiddler工具栏是否可见2、DefaultLayout、Stacked Layout、Wide Layout三种界面布局3、Minimize to Tray：最小化Fiddler到系统托盘（快捷键:CTRL+M）4、Squish SessionList：控制回话列表是否水平收缩。5、AutoScroll Sessionlist：添加新的回话时，自动滚动到回话列表底部

14.5 工具栏

fiddler工具栏.png

1.备注功能

2.重新发送请求，快捷键：R键。

3.删除请求

4.当有请求前断点时，点击去发送请求。

5.流模式。(默认是缓冲模式)

6.解码

7.保持回话的数量。

8.选择你想要抓包或者监听的程序

9.查找

10.保存所有会话，文件名以.saz为扩展名

11.截图

12.计时器

13.快捷的打开IE浏览器

fiddler工具栏1.png

14.清除IE缓存

15.文本的编码解码工具

16.分离面板

17.MSDN查询

18.本机的信息

14.6 会话列表

fiddler绘画列表.png

1.请求的ID编号

2.http响应状态码

3.会话使用的协议

4.请求发送到的服务器主机名

5.数据包在服务器中的路径和文件

6.响应body的字节数

7.响应头信息Cache-Control的值

8、响应头信息Content-Type的值

9.发起请求的本地windows进程

10.注释

11.自定义备注

14.7 功能页签

14.7.1 Statistics页签

通过该页签，用户可以通过选择多个会话来得到这几个会话的总的信息统计，比如多个请求传输的字节数。访问页面时选择第一个请求和最后一个请求，可获得整个页面加载所消耗的总体时间。从条形图表中还可以分别出哪些请求耗时最多，从而对页面的访问进行速度性能优化。

14.7.2 inspectors页签(常用页签）

它提供headers、textview、hexview,Raw等多种方式查看一条http请求的请求和响应，它分为上下两部分：上部分为请求展示，下部分为响应展示。

14.7.3 AutoResponse页签（常用页签）

它可以抓取在线页面保存到本地进行调试，大大减少了在线调试的困难，可以让我们修改服务器端返回的数据，例如让返回都是404的数据包读取本地文件作为返回内容。

14.7.4 composer页签常用页签）

支持手动构建和发送HTTP，HTTPS和FTP请求，我们还可以从回话列表中拖曳回话，把它放到composer选项卡中，当我们点击Execute按钮时则把请求发送到服务器端。

14.7.5 FiddlerScripts页签

打开Fiddler脚本编辑。

log页签：

打印日志

14.7.6 Filters页签（常用页签）

过滤器可以对左侧的数据流列表进行过滤，我们可以标记、修改或隐藏某些特征的数据流。

14.7.7 Timeline页签

时间轴，也称为Fiddler的瀑布图，展示网络请求时间的功能。每个网络请求都会经历域名解析、建立连接、发送请求、接受数据等阶段。把多个请求以时间作为X轴，用图表的形式展现出来，就形成了瀑布图。在左侧会话窗口点击一个或多个回话，Timeline 便会显示指定内容从服务端传输到客户端的时间。

14.7.8 命令行

help 打开官方的使用页面介绍，所有的命令都会列出来。

cls 清屏 (Ctrl+x 也可以清屏)

select 选择所有相应类型的回话(如select image或select css)。

?sometext 查找字符串并高亮显示查找到的会话。

size 选择请求响应大小小于size字节的会话。

=status/=method/@host 查找状态、方法、主机相对应的会话

1uit 退出fiddler

bpafter xxx 中断URL包含指定字符的全部回话响应

bps xxx 中断HTTP响应状态为指定字符的全部回话响应。

bpv xxx 中断指定请求方式的全部回话响应

bpm xxx 中断指定请求方式的全部回话响应。等同于bpv xxx

bpu xxx: 与bpafter类似。

14.8 状态栏

fiddler状态栏.png

1、显示的Fiddler是否处于捕捉状态(开启/关闭状态),可以点击该区域切换

2、显示当前捕捉哪些进程。

All Processes 捕获所有进程的请求

Web Browsers 捕获 Web 浏览器的请求，应该特指 IE

Non-Browser 捕获非 Web 浏览器的请求

Hide All 隐藏所有请求

3、显示当前断点设置状态，通过鼠标点击切换。有三种：

不设置断点

所有请求在断点处被暂停

所有响应在断点处被暂停

4，显示当前共捕获了多少回话(如：300，表示共捕获了300个会话，如：10/300，表示当前选择10个会话，共捕获300个会话)。

5，第五区块，描述当前状态。

如果是刚打开Fiddler，会显示什么时间加载了CustomRules.js；如果选择了一个会话，会显示该会话的URL；如果在命令行输入一个命令，就会显示命令相关信息。

14.9 web抓包

我们双击打开软件，进入到如下的一个界面，然后点击某一个请求，你会发现请求的内容是一堆明显不对的文字，然后该请求的左边是一个锁的样式，联想到https加密，你会发现原因可能是没有配置Fiddler。然后解释一下右边的默认返回内容，第一句是“这是一个CONNECT隧道，加密的HTTPS流量通过该隧道流动。”，就证实了我们的猜测，果然是因为https加密的原因。