客户端接口测试方法
上一篇 / 下一篇 2010-12-09 09:03:30 / 个人分类：测试基础
1、目的
编写接口测试指导目的是通过文档的编写，让软终端测试人员都能够对接口测试有一定的认识，通过对接口测试可用规避一些客户端测试过程中因为没有借口没有遍历造成客户端对服务器反馈情况缺少考虑的场景，避免代码在异常处理上，缺少异常分支。
2、范围
N/A
3、术语解
接口测试：试程序的不同的接口，检验测试接口函数是否达到接口规范所述的功能，包括内部接口和外部接口的测试。
外部接口：用户接口（UI），数据库接口，通信信道。
内部接口：数据流转移接口（transaction-flowtesting）
4、接口测试的介绍
试范围 | 所有子系统之间的接口和子系统内部的接口（逻辑接口和物理接口） |
测试目标 | 确保接口调用的正确性 |
技术 | 通过接口进行不同子系统之间的数据交换，检查输出输入数据是否完整正确。数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。 |
开始标准 | 各子系统或各模块工作正常 |
完成标准 | 得到所有接口的输入输出数据，并且保证数据的正确性。 |
测试重点和优先级 | 逻辑接口的测试 |
这是接口类产品制定的测试指南，文中列出了对于函数库、组件等对象（下文统称函数接口）的测试过程。这里描述的属于确认测试过程，但由于从形式上类似于单元测试，而且也基本适用于单元测试的过程，所以放到单元测试栏目中。
1.1概述
函数接口（或称API）是公司的一个产品类型。目前包括：TRSDatabase为各类平台提供的接口，以及TRSCKM工具包，以后有可能会继续增加。本部分的测试指南，描述了对这类产品进行测试时的参考过程。
下面首先给出整体的测试过程，然后针对每个子过程需要进行的工作进行具体描述，最后是几点补充说明。
1.2测试过程
函数接口的整体测试过程如下：
制定测试计划
设计测试用例
执行测试
编写可复用的测试代码
增强测试
结束测试
1.3过程说明
下面是对各个子过程的具体说明：
分析被测试对象的具体情况，制定测试计划，形成文档。测试计划至少要包括以下内容：
测试范围：测试要覆盖哪些库以及库中的哪些函数，要覆盖哪些文档，包含哪些测试类型等等。
测试工具：选择什么工具组织测试代码，是否还需要其它的辅助性测试工具。
测试环境：都需要在什么环境下执行测试，环境指硬件类型、OS、DB等等。
测试数据组织：对于测试代码所需要的测试数据，以什么方式来组织和保存。
进度安排：各个阶段的工作内容、时间安排。
测试尺度：测试的深度和广度是什么。根据现有的资源情况，在计划中设定一个标准，避免测试的盲目性和随意性。
按照函数接口说明文档，依据测试计划中的测试尺度来设计测试用例，形成文档。
函数接口的测试用例设计，与传统GUI界面产品的用例设计思路是一样的，包括测试输入（正常、异常输入）和预期输出两部分，等价划分、边界值等设计方法也同样适用，只是这时的界面变成了函数接口的输入参数，而不再是GUI元素。
依据测试用例设计文档，编写调试代码，执行测试。这是函数接口测试中最为耗时的过程，Bug也主要是在这个过程中被发现的。开发人员修正Bug，测试人员进行回归测试，直至Bug被关闭。
当一个函数的bug修正基本完成后，整理调试代码，将其转化为可复用测试代码。
函数接口最后的测试代码与其测试用例设计应该是一致的，测试代码是测试用例的具体实现。如果测试代码需要独立的测试数据，则要详细记录下这些数据的相关信息。测试用例设计文档、测试代码、测试代码所需测试数据，这三者构成完整的测试程序。
在编写测试代码的时候需要注意：不同测试部分的测试数据应该互不干扰，各部分的测试代码，在测试结束时要负责恢复测试环境，以使下一个测试能正常运行，也便于测试代码的维护。
这是一个可选项目，不是必须的。是否进行这项工作，在制定测试计划的时候就要考虑清楚。
对于函数接口的增强测试，可以考虑的测试内容包括（但不限于）：代码测试覆盖率的统计、函数接口的Run-time错误检测。这类测试工作需要工具的支持，可选的工具如：Compuware的Devpartner，IBM的PurifyPlus等。
结束测试阶段的工作包括：编写测试报告、测试资料整理。
完成测试计划中罗列的所有工作，达到预期的测试目标后，进行测试报告的编写。
对于测试过程中产生的测试资源——测试计划、测试用例设计、测试代码，这些是以后测试复用的基础。如果这些资源本身不能说明自己，则需要整理一份单独的说明文档，供以后参考使用。
1.4补充说明
对于上面描述的测试过程中的‘设计测试用例’、‘执行测试’、‘编写可复用的测试代码’这三个步骤，不是完成一项后，才开始进行下一项，而通常是一个交替进行、逐步迭代的过程。先制定好测试用例文档的整体结构，然后设计一个函数接口的测试用例，接着执行对其的测试，最后整理成可复用的测试代码。针对每个函数接口都重复这个过程，直至完成所有函数接口的测试。
测试过程中产生，测试结束后需要存档的测试资源包括：
测试计划（文档）；
测试用例设计（文档）；
测试代码及相关数据（代码、数据）；
测试报告（文档）；
其它的相关说明文档（如果有的话）；
测试框架的介质（如果选用了第三方测试框架的话）。
函数接口产品的一个特点就是对外表现比较稳定，因此一旦实现了对其测试过程的自动化，积累起可复用的测试资源，就会大大缩短以后该产品的测试周期。所以对于函数接口的测试，建议都能以测试自动化的过程进行组织。
为了实现函数接口的测试自动化，就需要选择一个稳定、可靠的测试框架来组织测试代码，在这里建议使用XUnit工具。
（注：针对不同的开发语言，Xunit提供了不同的版本，如Junit（forJava），CppUnit（forC/C++），Nunit（forMS.Net）等等，每种主流的语言都有其对应的Xunit框架。Xunit是OpenSource的工具，可以从http://sourceforge.net上下载。）
测试代码并不是写完后一次后就一劳永逸了。随着被测产品的升级，测试代码也需要作出相应的调整，以适应被测产品的变化。
一种策略就是通过调用程序的API方式来准备数据。这种情况是程序提供了准备数据的API接口，通过一系列的调用得到我们想要的过程数据，比如我们要测试一个更新报告的接口，那么我们可以先调用创建报告的接口，如果这个报告需要审批才可以更新的话，那么我们也需要调用一下审批报告的接口。
对于这种方式好处是：1、保证准备数据正确性。2、保证接口组合调用的正确性，起到集成测试的作用，保证业务的正确性。3、灵活，重用性强。
不利的地方是：1、测试与开发如果是并行的话，基础的接口的开发，如果前面的接口出问题，会引起后续阶段的接口测试的失败。2、准备异常数据时，要写大量的SQL手工就更改字段。3、当接口出现错误时，不能清楚地定位是要测试接口的问题还是准备的数据接口的问题，依赖性太强。
另外一种策略就是直接准备所需要的数据，运行时利用工具插入到数据库。
这种方式的好处：1、测试数据与脚本分开，结构清晰。2、解决了前一种方式引发的三个问题。3、数据直观，可读性强。
问题是：1、需要对各个阶段数据的合法值，非常清楚，测试过程中经常会引测试数据的问题，导致执行不通过。2、当出现大的变动时，数据更改的工作量比较大，灵活性较差，重用性差。
我的看法是：第一种策略适合在集成测试中使用，而第二种更适合接口测试。重要的是针对自身不同的情况，采取适当的策略，或者组合使用，扬长避短，以不断改进我们的工作。
接口测试需要关注的几点：
1、 调用所测试模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；
2、
TAG:
