科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道函数库、组件产品的测试方法

函数库、组件产品的测试方法

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

这是我为公司的接口类产品制定的测试指南,文中列出了对于函数库、组件等对象(下文统称函数接口)的测试过程...

作者:qiuyangzh 来源:BLOG 2007年10月13日

关键字: 函数库 组件产品 测试方法

  • 评论
  • 分享微博
  • 分享邮件
这是我为公司的接口类产品制定的测试指南,文中列出了对于函数库、组件等对象(下文统称函数接口)的测试过程。这里描述的属于确认测试过程,但由于从形式上类似于单元测试,而且也基本适用于单元测试的过程,所以放到单元测试栏目中。

  1.1 概述

  函数接口(或称API)是公司的一个产品类型。目前包括:TRS Database为各类平台提供的接口,以及TRS CKM工具包,以后有可能会继续增加。本部分的测试指南,描述了对这类产品进行测试时的参考过程。

  下面首先给出整体的测试过程,然后针对每个子过程需要进行的工作进行具体描述,最后是几点补充说明。

  1.2 测试过程

  函数接口的整体测试过程如下:

  * 制定测试计划

  * 设计测试用例

  * 执行测试

  * 编写可复用的测试代码

  * 增强测试

  * 结束测试

  1.3 过程说明

  下面是对各个子过程的具体说明:

  1.3.1 制定测试计划

  分析被测试对象的具体情况,制定测试计划,形成文档。测试计划至少要包括以下内容:

   测试范围。测试要覆盖哪些库以及库中的哪些函数,要覆盖哪些文档,包含哪些测试类型等等。

   测试工具。选择什么工具组织测试代码,是否还需要其它的辅助性测试工具。

   测试环境。都需要在什么环境下执行测试,环境指硬件类型、OS、DB等等。

   测试数据组织。对于测试代码所需要的测试数据,以什么方式来组织和保存。

   进度安排。各个阶段的工作内容、时间安排。

   测试尺度。测试的深度和广度是什么。根据现有的资源情况,在计划中设定一个标准,避免测试的盲目性和随意性。

  1.3.2 设计测试用例

  按照函数接口说明文档,依据测试计划中的测试尺度来设计测试用例,形成文档。

  函数接口的测试用例设计,与传统GUI界面产品的用例设计思路是一样的,包括测试输入(正常、异常输入)和预期输出两部分,等价划分、边界值等设计方法也同样适用,只是这时的界面变成了函数接口的输入参数,而不再是GUI元素。

  1.3.3 执行测试

  依据测试用例设计文档,编写调试代码,执行测试。这是函数接口测试中最为耗时的过程,Bug也主要是在这个过程中被发现的。开发人员修正Bug,测试人员进行回归测试,直至Bug被关闭。

  1.3.4 编写可复用的测试代码

  当一个函数的bug修正基本完成后,整理调试代码,将其转化为可复用测试代码。

  函数接口最后的测试代码与其测试用例设计应该是一致的,测试代码是测试用例的具体实现。如果测试代码需要独立的测试数据,则要详细记录下这些数据的相关信息。测试用例设计文档、测试代码、测试代码所需测试数据,这三者构成完整的测试程序。

  在编写测试代码的时候需要注意:不同测试部分的测试数据应该互不干扰,各部分的测试代码,在测试结束时要负责恢复测试环境,以使下一个测试能正常运行,也便于测试代码的维护。

  1.3.5 增强测试

  这是一个可选项目,不是必须的。是否进行这项工作,在制定测试计划的时候就要考虑清楚。

  对于函数接口的增强测试,可以考虑的测试内容包括(但不限于):代码测试覆盖率的统计、函数接口的Run-time错误检测。这类测试工作需要工具的支持,可选的工具如:Compuware的Devpartner,IBM的PurifyPlus等。

  1.3.6 结束测试

  结束测试阶段的工作包括:编写测试报告、测试资料整理。

  完成测试计划中罗列的所有工作,达到预期的测试目标后,进行测试报告的编写。

  对于测试过程中产生的测试资源——测试计划、测试用例设计、测试代码,这些是以后测试复用的基础。如果这些资源本身不能说明自己,则需要整理一份单独的说明文档,供以后参考使用。

  1.4 补充说明

  1.4.1 测试过程的补充说明

  对于上面描述的测试过程中的‘设计测试用例’、‘执行测试’、‘编写可复用的测试代码’这三个步骤,不是完成一项后,才开始进行下一项,而通常是一个交替进行、逐步迭代的过程。先制定好测试用例文档的整体结构,然后设计一个函数接口的测试用例,接着执行对其的测试,最后整理成可复用的测试代码。针对每个函数接口都重复这个过程,直至完成所有函数接口的测试。

  1.4.2 测试过程中产生的测试资源

  测试过程中产生,测试结束后需要存档的测试资源包括:

  测试计划(文档);

  测试用例设计(文档);

  测试代码及相关数据(代码、数据);

  测试报告(文档);

  其它的相关说明文档(如果有的话);

  测试框架的介质(如果选用了第三方测试框架的话)。

  1.4.3 函数接口测试的自动化

  函数接口产品的一个特点就是对外表现比较稳定,因此一旦实现了对其测试过程的自动化,积累起可复用的测试资源,就会大大缩短以后该产品的测试周期。所以对于函数接口的测试,建议都能以测试自动化的过程进行组织。

  为了实现函数接口的测试自动化,就需要选择一个稳定、可靠的测试框架来组织测试代码,在这里建议使用XUnit工具。

  (注:针对不同的开发语言,Xunit提供了不同的版本,如Junit(for Java),CppUnit(for C/C++),Nunit(for MS .Net)等等,每种主流的语言都有其对应的Xunit框架。Xunit是Open Source的工具,可以从http://sourceforge.net下载。)

  1.4.4 测试代码的维护

  测试代码并不是写完后一次后就一劳永逸了。随着被测产品的升级,测试代码也需要作出相应的调整,以适应被测产品的变化。

查看本文来源

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章