软件系统的测试论文（精选12篇）

软件系统的测试论文 第1篇

1. 软件测试的概念。

软件测试就是利用测试工具按照测试方案和流程对产品进行功能和性能的测试, 甚至根据需要编写不同的测试工具, 设计和维护测试系统, 对测试方案可能出现的问题进行分析和评估。执行测试用例后, 需要跟踪故障, 以确保开发的产品适合需求。可以说, 软件测试是发现软件错误的过程, 所以对软件要尽早测试和充分测试。

2. 黑盒测试。

大体上分, 软件测试方法可分为白盒测试和黑盒测试2种。黑盒测试也称功能测试或数据驱动测试。它在已知产品应具有的功能条件下, 通过测试来检测每个功能是否都能正常使用。在测试时, 把程序看作1个不能打开的黑盒子, 在完全不考虑程序内部结构和内部特性的情况下, 测试者在程序接口进行测试。常用的黑盒测试的测试方法包括等价类测试法、边界值测试法、决策表、因果图、场景法和正交试验法。

3. 白盒测试。

白盒测试则只根据程序的内部结构进行测试, 而不考虑外部特性, 如果程序结构本身有问题, 比如说程序逻辑有错误或是有遗漏, 则无法被发现。白盒测试可全面了解程序内部的逻辑结构, 无法对所有逻辑路径进行测试。在使用这一方案时, 测试者必须检查程序的内部结构, 从检查程序的逻辑着手, 得出测试数据。常用的白盒测试方法包括逻辑覆盖测试、基本路径测试、分支条件测试、循环测试和数据流测试等。

二、面向对象特征对软件测试的影响

类的封装性和继承性给面向对象软件的开发带来了很多好处, 但却给软件测试带来了不少负面影响。一方面, 面向对象测试用例设计的目标是类, 类的属性和操作是封装的, 而测试需要了解对象的详细状态。另一方面, 继承也给测试用例的设计带来了不少麻烦。继承并没有减少对子类的测试, 相反使测试过程更加复杂。

1. 类和对象对功能模块测试的影响。

在面向对象系统中, 系统的基本构造单元是封装了数据和方法的类和对象, 而不再是一个个能完成特定功能的功能模型。每个对象都有自己的生存期和状态。消息是对象之间相互请示或协作的途径, 是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下, 由对象所属类中定义的方法与相关对象的合作共同完成, 并且对象在不同状态下对消息的响应也可能完全不同。

2. 系统功能实现对测试的影响。

在面向对象系统中, 系统的功能体现在对象间的协作上, 而不再是简单的过程关系调用。面向对象程序的执行实际上是执行一个由消息连接起来的方法序列, 方法的实现与所属对象本身的状态有关, 各方法之间可能有相互作用。为实现某一特定的功能, 可能要激活和调用属于不同对象类的多个成员函数, 形成成员函数的启用链。因此, 基于功能分解的自顶向下或自底向上的集成测试策略不适用于面向对象软件系统的测试。

3. 封装对测试的影响。

封装是指在词法单位之中或之间决定名字可见性的访问控制机制。它支持信息的隐蔽和模块化, 有助于防止全局变量的访问问题。尽管封装不会直接促成错误的发生, 但它却给测试带来了障碍。封装使对象的内部状态隐蔽, 如果类中未提供足够的存取函数来表明对象的实现方式和内部状态, 则类的信息隐蔽机制将给测试带来很多困难。

4. 继承对测试的影响。

继承也是面向对象语言中的一个本质特征。继承可用于一般与特殊关系, 并且方便编码。但继承削弱了封装性, 产生了类似于非面向对象语言中全局数据的错误风险。由于继承的作用, 一个函数可能被封装在具有继承关系的多个类中, 子类中还可以对继承的特征进行覆盖或重定义。

5. 多态对测试的影响。

多态是指一个引用可以与多个对象绑定的能力。多态能减少代码的复杂性和规模, 同时还可以实现动态绑定。但依赖于不规则类层次的动态绑定可能会产生编程人员想象不到的结果。虽然, 某些绑定能正确地运行但并不能保证所有的绑定都能正确地运行。以后绑定的对象可能很容易地将消息发送给错误的类, 执行错误的功能, 还可能导致出现一些与消息序列和状态相关的错误。

三、面向对象软件测试的层次划分

1. 方法测试。

主要考虑封装在类中的1个方法对数据进行的操作。可以采用传统的模块测试方法, 但方法是封装在类中的, 并通过向所在对象发消息来执行, 它的执行与状态有关, 特别是在操作多态性时, 设计测试用例时要考虑设置对象的初态, 并且要设计一些函数来观察隐蔽的状态值, 使它在收到消息时执行指定的路径。

2. 类测试。

在测试过程上等同于传统的单元测试, 面向对象的类测试主要考察封装在1个类中的方法和类的状态行为。进行类测试时要把对象与其状态结合起来, 进行对象状态行为的测试, 因为工作过程中对象的状态可能被改变并产生新的状态。测试范围主要是类定义之内的属性和服务, 以及有限的对外接口部分。在类测试过程中, 不能仅仅检查输入数据产生的结果是否与预期的相吻合, 还要考虑对象的状态, 整个过程应涉及对象的初态、输入参数、输出参数以及对象的终态。

3. 类簇测试 (集成测试) 。

把一组相互有影响的类看做一个整体称为类簇。类簇测试主要根据系统中相关类的层次关系, 检查类之间相互作用的正确性, 即检查各相关类之间消息连接的合法性、子类的继承性、父类的一致性、动态绑定执行的正确性和类簇协同完成系统功能的正确性等特性。其测试有2种不同策略:基于类间协作关系的横向测试和基于类间继承关系的纵向测试。

4. 系统测试。

是对所有程序和外部成员构成的整个系统进行整体测试, 检验软件和其他系统成员配合工作是否正确。另外, 还包括确认测试内容, 以验证软件系统的正确性和性能指标是否满足需求规格说明书的要求。

四、面向对象测试用例设计

1. 测试用例设计。

面向对象的软件测试用例则着眼于适当的操作序列, 以实现对类的说明。黑盒测试不仅适用于传统软件, 也适用面向对象的软件测试。白盒测试也可用于面向对象软件类的操作定义。但面向对象的软件中许多类的操作结构简单明了, 所以有人认为在类层上测试可能要比传统的软件中白盒测试更加方便。

2. 测试用例设计要点。

测试应该唯一地标识每一个测试案例, 并且与被测试的类明显地建立关联, 并陈述测试对象的一组特定状态。对每一个测试建立一组测试步骤, 需要思考或确定的问题包括:对被测试对象的一组特定状态, 一组消息和操作, 可能产生的一组异常, 一组外部条件, 辅助理解和实现测试的补充信息。

五、设计类测试用例

1. 基于故障的测试。

在面向对象软件中, 基于故障的测试具有较高的故障发现能力。基于故障的测试与传统的错误测试推测法类似。首先, 推测软件中可能有的错误。然后, 设计出可能发现这些错误的测试案例。为了推测出软件中可能存在的错误, 应该仔细研究分析模型和设计模型, 这在很大程度上要依靠测试人员的经验。

2. 基于脚本的测试。

基于脚本的测试主要关注用户需要做什么, 而不是产品能做什么, 即从用户任务 (使用用例) 中找出用户要做什么并去执行。这种基于脚本的测试有助于在一个单元测试情况下检查多重系统。所以基于脚本的用例测试比基于故障测试更加接近用户, 而且更复杂。

3. 随机测试。

如果一个类有多个操作功能, 这些操作功能序列有多种排列。而这种不变化的操作序列可随机产生, 用这种可随机排列的序列来检查不同类的实例, 叫做随机测试。随机测试是针对软件在使用过程中随机产生的一系列不同的操作序列设计的测试案例, 可以测试不同的类实例。

4. 划分测试。

划分测试方法与传统软件测试采用的等价划分方法类似, 它减少了测试类所需要测试用例的数量。首先, 用不同的划分方法 (包括基于状态的划分方法、基于属性的划分方法和基于功能的划分方法) 把输入和输出分类。然后, 针对划分出来的每个类别设计测试用例。

六、设计类间测试用例

1. 基于场景的测试。

基于场景的测试关注的是用户需要做什么, 这正是基于故障测试所忽略的。当与不正确的规约发生错误关联时, 软件就可能不执行用户所设定的工作, 这时软件质量就会受到影响。当一个子系统所建立的环境使得另一个子系统失效时, 子系统间的交互错误便会发生。

2. 行为测试。

软件系统的测试论文 第2篇

简单的说，经过良好规划和管理的测试环境，可以尽可能的减少环境的变动对测试工作的不利影响，并可以对测试工作的效率和质量的提高产生积极的作用。

一、规划测试环境——让环境为你服务

对于“金山词霸”这样的软件，大多数测试工作都可以在一台单独的电脑上完成，而对于一套电信系统，为了执行测试用例，你可能会需要搭建一个由多台计算机以及其他网络设备组成，采用集群和负载均衡技术，并且接驳到Internet的计算机网络。

不同的行业应用，不同的质量目标，都可能会影响到测试环境的规划。但从测试工作自身的要求来看，一条应当遵守的原则就是“尽可能的还原软件在用户那里最终实际运行的环境”——虽然在很多时候这是不现实的。^_^

通常来说，我们所需要搭建的环境，主要是用于被测应用的系统测试——单元测试和集成测试由开发人员在开发环境中进行，而验收测试则在用户的最终应用环境中进行，因此都可以暂不考虑。

为了确定测试环境的组成，我们需要明确以下问题：

1.所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；

2.部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

3.用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

4.用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

5.是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

6.测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；

7.执行测试工作所需要使用的文档编写工具、测试管理系统、性能测试工具、缺陷跟踪管理系统等软件的名称、版本、License数量，以及所要用到的相关补丁的版本。对于性能测试工具，则还应当特别关注所选择的工具是否支持被测应用所使用的协议；

8.为了执行测试用例，所需要初始化的各项数据，例如登陆被测应用所需的用户名和访问权限，或其他基础资料、业务资料；对于性能测试，还应当特别考虑执行测试场景前应当满足的历史数据量。当然，还有另外一个非常关键的问题：在测试过程中受到影响的数据如何恢复？

明确了上面的问题后，明确哪些条件是可以满足的，哪些是需要其他部门协助调配、采购或者支援的。建议在搭建测试环境之前，把上面的问题做成一张 CheckList，并为每一项指定一个责任人，完成一项就填写一项，最终形成的文档则作为测试环境的配置说明文档使用。当然，如果时间或其他条件允许，应当做好应急预案，尽量保证在环境失效时不会对正常工作产生太大的影响。

二、管理测试环境——把变化掌握在手中

测试环境搭建好以后不太可能永远不发生变化，至少被测应用的每次版本发布都会对测试环境产生或多或少的影响。而应对变化之道，不是禁止变化，而是“把变化掌握在手中”。下面的这些建议可以帮助你尽可能摆脱环境变化所带来的不利影响。

1.设置专门的测试环境管理员角色

每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；

记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；

完成被测应用的部署，并做好发布文档的编写；

测试环境各项变更的执行及记录；

测试环境的备份及恢复；

操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

当测试组内多名成员需要占用服务器并且相互之间存在冲突时（例如在执行性能测试时，在同一时刻应当只有一个场景在运行），负责对服务器时间进行分配和管理。

2.明确测试环境管理所需的各种文档

一般来说，下面的几个文档是必需的，当然你也可以根据需要增加新的文档。

组成测试环境的各台计算机上各项软件的安装配置手册，记录各项软件的名称、版本、安装过程、相关参数的配置方法等，并记录好历次软件环境的变更情况；

组成测试环境的各台机器的硬件环境文档，记录各台机器的硬件配置（CPU/内存/硬盘/网卡）、IP地址、具体用途以及历次的变更情况；

被测应用的发布手册，记录被测应用的发布/安装方法，包括数据库表的创建、数据的导入、应用层的安装等。另外，还需要记录历次被测应用的发布情况，对版本差异进行描述；测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因（与上次备份相比发生的变化）以及所形成的备份文件的文件名和获取方式；

用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录。

3.测试环境访问权限的管理

应当为每个访问测试环境的测试人员和开发人员设置单独的用户名，并根据不同的工作需要设置不同的访问权限，以避免误操作对测试环境产生不利的影响。下面的要求可以作为建立“测试环境访问权限管理规范”的基础。

访问操作系统、数据库、中间件、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；

测试环境管理员拥有全部的权限；

除对被测应用的访问权限外，一般不授予开发人员对测试环境其他部分的访问权限。如的确有必要（例如查看系统日志），则只授予只读权限；

除测试环境管理员外，其他测试组成员不授予删除权限；

用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中。

4.测试环境的变更管理

对测试环境的变更应当形成一个标准的流程，并保证每次变更都是可追溯的和可控的。下面的几项要点并不是一个完整的流程，但是可以帮助你实现这个目标。

测试环境的变更申请由开发人员或测试人员提出书面申请，由测试环境管理员负责执行。测试环境管理员不应接受非正式的变更申请（例如口头申请）；

对测试环境的任何变更均应记入相应的文档；

同每次变更相关的变更申请文档、软件、脚本等均应保留原始备份，作为配置项进行管理；

对于被测应用的发布，开发人员应将整个系统（包括数据库、应用层、客户端等）打包为可直接发布的格式，由测试环境管理员负责实施。测试环境管理员不接受不完整的版本发布申请；

对测试环境做出的变更，应该可以通过一个明确的方法返回到之前的状态。

5.测试环境的备份和恢复

对于测试人员来说，测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价 值。因此，应当在测试环境（特别是软件环境）发生重大变动（例如安装操作系统、中间件或数据库，为操作系统、中间件或数据库打补丁等对系统产生重大影响并 难以通过卸载恢复）时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。并由测试环境管理员在相应的“备份记录”文档中记录每次备份的时 间、备份人以及备份原因（与上次备份相比发生的变化），以便于在需要时将系统重新恢复到安全可用的状态。

软件测试是提高软件质量的保证 第3篇

【关键词】错误 测试 目的 质量

随着信息技术的发展,计算机的应用领域越来越广,软件对于人们生活所造成的影响是巨大的,软件的好坏直接关系着人们的日常生活。尤其是计算机网络迅速发展的今天,由于小的软件故障就有可能造成一些不必要的大损失。

现在人们已经逐步认识到:正是软件错误导致了软件开发在成本、进度和质量的失控。有错是软件的属性而且是无法改变的,因为软件是由人来完成的。问题在于我们如何去避免错误的产生和消除已经产生的错误,使软件中的错误密度达到尽可能低的程度。“软件测试”为我们提供了这种可能。隐藏在软件中的错误可以依靠“软件测试”来揭示,软件中的错误密度也可以通过“软件测试”来进行估计。“软件测试”是信息技术的重要方面,是保证软件达到高质量和高可靠性的关键元素。

一、软件测试的目的

软件测试是软件工程过程的一个重要阶段,是在软件投入运行前,对软件需求分析、设计和编码各阶段产品的最终检查,是为了保证软件开发产品的正确性、完全性和一致性,从而检测软件错误、修正软件错误的过程。

谈到软件测试,许多人都会引用Glenford J.Myers就软件测试目的提出的以下观点:

①测试是程序的执行过程,目的在于发现错误;② 一个好的测试用例在于能发现至今未发现的错误;③一个成功的测试是发现了至今未发现的错误的测试;

这是一种比较狭窄的观点。软件测试是以查找错误为中心,但发现错误并不是软件测试的惟一目的,查找不出错误的测试也不是没有价值的。

软件的测试,基于不同的立场,存在着完全不同的测试目的。从用户的角度出发,软件测试不是为了演示软件的正确功能,而是希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可以接受该产品。从软件开发者的角度出发,应当从软件过程的角度来看软件测试。测试并不仅仅是为了要找出错误或缺陷,而是以查找错误为中心,分析错误产生的原因和错误在开发的哪一个阶段产生,这具有非常重要的意义。通过分析错误或缺陷的原因,可以立即在软件开发行动中对其进行改正,通过分析也能帮助推理出与所分析的错误或缺陷有关联的潜在错误或缺陷,从而有针对性地设计出检测潜在错误或缺陷的方法,改善测试的有效性。最终表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确保软件的质量。

软件工程的总目标是充分利用有限的人力和物力资源,高效率、高质量地完成软件开发项目。对于软件不足的测试,势必使软件带着一些未揭露的隐藏错误投入运行,这将意味着软件具有一定的缺陷,软件产生的更大危险将要让用户承担。但是对软件进行完全测试是不可能实现的,因为会受到软件开发过程中人力和物力资源的影响。也有可能到了测试后期,即使找到了错误,然而修正错误需要付出了很高的代价。软件测试只能表明错误的存在,而不能表明错误不存在。可见,测试是为了使软件中蕴涵的缺陷低于某一特定值,使产出、投入比达到最大。

因此,测试的目的是以最少的人力、物力和时间投入,尽可能多地找出软件中潜在的各种错误和缺陷,检验软件的功能和性能是否符合用户需求、确保软件产品中的问题在分发之前被准确定位、改进生产过程,提高用户满意度。

二、软件测试的原则

根据软件测试的目的,软件测试的原则应该是:

(1)应当把尽早地和不断地进行软件测试作为软件开发者的座右铭。坚持在软件开发的各个阶段的技术评审,这样才能在开发过程中尽早发现和预防错误,把出现的错误克服在早期,杜绝某些隐患,提高软件质量。

(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。如果对测试输入数据没有给出预期的程序输出结果,那么就缺少了检验实测结果的基准,就有可能把一个似是而非的错误结果当成正确结果。

(3)程序员应避免检查自己的程序。如果由别人来测试程序员编写的程序,可能会更客观,更有效,并更容易取得成功。 

(4)制定严格的测试计划,并把测试时间安排的尽量宽松,不要希望在极短的时间内完成一个高水平的测试。

(5) 妥善保存一切测试过程文档,意义是不言而喻的,测试的重现性往往要靠测试文档。

(6)回归测试的关联性一定要引起充分的注意,修改一個错误而引起更多的错误出现的现象并不少见。

三、软件测试的方法

软件测试方法包括静态测试、动态测试两种。其中,静态测试包括代码审查、静态分析。动态测试包括黑盒测试、白盒测试。黑盒测试适用于单元测试到系统联试阶段,而白盒测试通常适用于单元测试、集成测试及部分软件的配置项测试阶段。

1、静态测试

在静态测试中,代码审查的针对性强,一般情况下能发现70%-75%的特定问题,而且还能发现许多隐藏很深但非常致命的缺陷。但这种方式对资源的耗费很大,过分地依赖代码审查人员的素质和表现,对有些软件不适用;静态分析自动化程度高、效率高,分析全面、准确,包括分析理解、质量度量、规则检查等,但它存在适用性有限,许多分析结果需要人工给予进一步的分析和确认。

所以,应该将代码审查和静态分析两者结合,在静态测试中做到:

能用工具做的尽量用工具进行静态分析;

对部分静态分析结果通过代码审查的方式进行进一步的确认;

先静态分析,再代码审查;

利用静态分析结果作为引导,使代码审查工作更为有效。

2、动态测试

在动态测试中,黑盒测试直接面向需求设计测试用例,把被测程序看成一个黑盒,只考虑数据输入与输出的关系,完全不考虑程序内部的结构和特征。测试者只是按照软件规格书内容导出测试数据,并将注意力集中在寻找程序未按规格运行的情况。白盒测试直接针对软件内部的控制流和数据流进行测试用例的设计,要求测试人员对软件源程序有较深入的了解,允许测试人员从程序的逻辑着手检查程序的内部结构和源代码,得出测试数据,但常常会忽略了软件规格书的要求。

所以,应该将黑盒测试和白盒测试两者结合,在动态测试中做到:

先黑盒,再白盒;

在软件各测试阶段都可以使用这样的测试策略。

在整个测试过程中,应注重动态测试和静态测试的互补,将静态测试和动态测试相结合,先静态测试后动态测试,先静态分析再代码审查,先黑盒测试再白盒测试。

四、软件测试与软件质量保证的关系

软件测试能够提高软件质量,但与软件测试和软件质量保证二者之间既存在包含又存有交叉的关系。

软件测试能够找出软件缺陷,确保软件产品满足需求。但是测试不是质量保证,二者并不等同。测试可以查找错误并进行修改,从而提高软件产品的质量。软件质量保证则是避免错误以求高质量,并且还有其他方面的措施以保证质量问题。

从共同点的角度看,软件测试和软件质量保证的目的都是尽力确保软件产品满足需求,从而开发出高质量的软件产品。两个流程都是贯穿整个软件开发生命周期中。正规的软件测试系统主要包括:制定测试计划、测试设计、实施测试、建立和更新测试文档。而软件质量保证的工作主要为:制定软件质量要求、组织正式审查、软件测试管理、对软件的变更进行控制、对软件质量进行度量、对软件质量情况及时记录和报告。软件质量保证的职能是向管理层提供正确的可行信息,从而促进和辅助设计流程的改进。软件质量保证的职能还包括监督测试流程,这样测试工作就可以被客观地审查和评估,同时也有助于测试流程的改进。

二者的不同之处在于软件质量保证工作侧重对软件开发流程中的各个过程进行管理与控制,杜绝软件缺陷的产生。而测试则是对已产生的软件缺陷进行修复。

五、结束语

在软件越来越普及的今天,对软件产品质量的度量、评估和保证,成了用户和软件开发企业都十分关注的问题。软件测试是保证软件产品质量的重要手段,但完全的软件测试也是不现实的,它不能保证发现软件中的所有问题,它不能取代其它质量保证手段,而且,软件测试过分是一种浪费。在系统条件人力和物力资源的允许下,软件测试只有经过有序地组织、管理,并在各个阶段的每一测试过程中,运用合理的测试原则、方法,才能做到测试最优,也即保证软件产品质量最优。

参考文献:

[1]刘琴等译 《软件测试基础教程》[M].北京:人民邮电出版社,2009:1

[2]何国伟 王纬 等编 软件可靠性[M]. 湖南 国防工业出版社,1998:1

[3] (美)Ron Patton 周予滨 姚静译《软件测试》[M]. 机械工业出版社,2002.1

作者简介:

论软件系统的测试 第4篇

计算机软件是基于计算机系统的一个重要组成部分, 影响软件产品质量的原因主要有: (1) 庞大的系统规模, 使得软件及系统的复杂性呈指数增长; (2) 需求变化引发的项目各部分之间已知或未知的依赖性可能会相互影响导致更多错误的出现; (3) 代码文档的贫乏, 导致出错率增加; (4) 软件开发工具自身的错误带到了软件中; (4) 程序设计人员的经验不足引发错误; (6) 项目工期紧张, 导致出错率增加。

软件开发完毕后应与系统其他合集在一起, 此时须要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围, 这些测试也不可能仅由软件开发人员完成。在软件测试之前, 软件工程师应完成以下工作: (1) 为测试软件系统的输入信息设计出错误处理通路; (2) 设计测试用例, 模拟错误数据和软件界面可能发生的错误, 记录测试结果, 为系统测试提供经验和帮助; (3) 参与软件测试的规划和设计, 保证软件测试的合理性。

二、软件测试的目标

测试的目标是什么?G.Myers给出了关于测试的一些规则, 这些规则可以看做是测试的目标和意义。 (1) 测试是为了发现程序中的错误而执行程序的过程; (2) 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案; (3) 成功的测试是发现了至今为止尚未发现的错误和测试。

从上述规则可以看出, 测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”、“成功的测试是没有发现错误的测试”等等是完全相反的。正确认识测试目标是十分重要的, 测试目标决定了测试方案的设计。如果为了表明程序的正确而进行测试, 就会设计一些不易暴露错误的测试方案。由于测试的目标是暴露程序中的错误, 从心理学角度来看, 由程序的编写者自己测试是不恰当的。因此, 在综合测试阶段通常由其他人员组成测试小组来完成测试工作。

三、软件测试准则

怎样才能达到软件测试的目标呢?为了能设计出有效的测试方案, 软件工程师必须深入理解并正确运用指导软件测试的基本准则。主要的测试准则包括: (1) 所有发现测试都应能追溯到用户需求。正如软件测试的目标是发现错误。从用户角度来看, 最严重的错误是导致程序不能满足用户需求的那些错误。 (2) 应该远在测试之前就制订出测试计划。实际上, 一旦完成了需求模型就可以着手制订测试计划, 在建立了模型之后就可以立即开始设计详细的测试方案。因此, 在编码之前就可以对所测试的工作进行计划和设计。 (3) 应该从“小规模”测试开始, 并逐步进行“大规模”测试。通常, 首先重点测试单个程序模块, 然后把测试重点转向在集成的模块中寻找错误, 最后在整个系统中寻找错误。 (4) 穷举测试是不可能的。所谓穷举测试就是把程序所有可能的执行路径都检查一遍的测试。即使是一个中等规模的程序, 其执行路径的排列数也十分庞大, 由于受时间、人力和资源的限制, 在测试过程中不可能执行每个可能的路径。因此, 测试只能证明程序中有错误, 不能证明程序中没有错误。但是, 精心地测试方案, 有可能充分覆盖程序逻辑并使程序达到所要求的可靠性。 (5) 为了达到最佳的测试效果, 应该由独立的第三方从事测试工作。所谓“最佳效果”是指有最大可能性发现错误的测试。

四、以白盒测试技术为例的测试步骤

除非是测试一个小程序, 否则一开始就把整个系统作为一个单独的实体来测试是不现实的。测试过程也必须分步骤进行, 后一个步骤在逻辑上是前一个步骤的继续。大型软件系统通常由若干个子系统组成, 每个子系统又由许多模块组成。因此, 本系统设计的测试过程有下述几个步骤组成:模块测试;子系统测试;系统测试;验收测试;平行运行。测试任何产品都有两种方法:如果已经知道了产品应该具有的功能, 可以通过测试检验是否每个功能都能正常使用;如果知道产品的内部过程, 可以通过测试来检验产品内部动作是否按照规格说明书正常进行。前一种称为黑盒测试, 后一种方法称为白盒测试。本系统重点研究后种技术。

白盒测试的前提是可以把程序看成装在一个透明的白盒子里, 测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序, 检测程序中的主要执行通路是否能按照预定要求正确工作。白盒测试又称结构测试。下例说明本系统模块所应用两种常用白盒测试技术。

(一) 逻辑覆盖测试技术

有选择地执行程序中某些最有代表性的通路是对穷尽测试的唯一可行的替代办法。所谓逻辑覆盖是对一系列测试过程的总称, 这组测试过程逐渐进行越来越完整的通路测试。例如本系统中某模块在测试中所应用的几种覆盖技术。

1.语句覆盖。为了暴露程序中的错误, 至少每个语句执行一次。语句覆盖的含义是, 选择足够多的测试数据, 使被测程序中每个语句至少执行一次。如1图所示的程序流程图描绘了一个被测模块的处理算法。为了使每个语句都执行一次, 程序的执行路径应该是sabced, 为此只需要输入下面的测试数据 (实际上X可以是任意实数) 。

本系统某模块测试流程图如图1所示。

2.判定覆盖。判定覆盖又叫分支覆盖, 它的含义是, 不仅每个语句必须至少执行一次, 而且每个判定的每种可能的结果都应该至少执行一次, 也就是每个判定的分支都至少执行一次。对于模块来说, 能够分别覆盖路径sacbd和sabd的两组测试数据, 或者可以分别覆盖路径sacbd和sabed的两组测试数据, 都满足判定覆盖标准。例如, 用下面两组测试数据就可以做到判定覆盖:

A=3, B=0, X=3 (覆盖sacbd)

A=2, B=1, X=1 (覆盖sabed)

(二) 控制结构测试技术

循环测试专注于测试循环结构的有效性。在本系统的程序设计中应用了3种循环, 即简单循环、串接循环、和嵌套循环。下面分别针对这3种循环的测试方法。

1.简单循环。应该使用下例测试集来测试简单循环, 其中n是允许通过循环的最大次数。

跳过循环。

只通过循环1次。

通过循环2次。

通过循环m次, 其中m

通过循环n-1次。

2.嵌套循环。如果把简单循环的测试方法直接应用到嵌套循环, 可能的测试数就会随嵌套层数的增加按几何级数增长, 这会导致不切实际的测试数目。B.Beizer提出了一种能减少测试数的方法:

●从最内层循环开始测试, 把所有其他循环都设置最小值。

●对最内层循环使用简单测试方法, 而使外层循环的迭代参数 (例如, 循环计数器) 取最小值, 并为越界值或非法值增加一些额外的测试。

●由内向外, 对下一个循环进行测试, 但保持所有其他外层循环为最小值, 其他嵌套循环为“典型”值。

●继续进行下去, 直到测试完成所有循环。

3.串接循环。如果串接循环的各个循环都彼此独立, 则可以使用前述的测试简单循环的方法来测试串接循环。但是, 如果两个循环串接, 而且第一个循环的循环计数器值是第二个循环的初始值, 则这两个循环并不是独立的。当循环不成立时, 建议使用测试嵌套循环的方法来测试串接循环。

参考文献

[1]伍利.ATE软件测试方法研究及实现[D].成都:电子科技大学, 2004.

[2]张永梅, 陈立潮, 马礼, 郭韶升.软件测试技术研究[J].测试技术学报, 2002, (2) .

[3]薛赛男, 赵伟.软件测试技术——计量测试技术的新领域[J].计量技术, 2003, (5) .

软件测试笔试的题目 第5篇

答案：

测试设计阶段：

1)了解被测系统的性能需求，定义测试目标和范围;

2)了解系统的技术信息，如系统架构等;

3)确定测试方案、进度安排，并制定测试计划，场景设置方案，及需要收集的测试数据;

4)同相关人员协商讨论测试方案;

5)准备数据收集模板;不同项目的性能测试，需要收集的数据不同;针对性的制定一个模板，更符合需要;

测试环境准备：

1)技术准备;选择性能测试工具;测试方案中涉及到的技术问题;测试数据的收集方案实现;如：如何监控系统资源等;

2)搭建测试环境;

3)创建初始数据;如虚拟用户使用的账号等;

测试执行阶段：

1)录制脚本;

2)调试脚本;

3)执行场景;

4)收集测试数据，并简单整理;

测试分析阶段：

1)分析测试数据;

提交测试报告 。

2、解释5个常用的性能指标的名称与具体含义。

答案：

并发：所有用户在同一时刻对系统执行操作，一般指做同一件事情或操作。

在线：所有用户在一段时间内对系统执行操作。

请求响应时间

从client端发出请求到得到响应的整个时间;

包括：client端响应时间+网络响应时间+Server端响应时间。

事务请求响应时间

完成相应事务所用的时间;这个是性能测试中重点关注的指标。

TPS(Transaction Per Second)

每秒钟系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS是LoadRunner中重要的性能参数指标。

点击率(Hit Per Second)

每秒发送的HTTP请求的数量;点击率越大对Server的压力越大。

资源利用率

对不同资源的使用程度，如CPU，I/O，内存，

3、写出5个Loadrunner中常用函数，并对其中2个举例说明用法。

答案：

字符串复制

strcpy(str，”Hello “) ;

字符串连接

strcat(str，”World !”);

lr_message(“str: %s”，str);

sprintf(s， “%s love %s.”， “I”， “ocean”); //产生：”I love ocean. ”

变量转为参数，将变量str的值存到参数Param中

lr_save_string(str，”Param”);

参数复制

lr_save_string(lr_eval_string(“{Param}”)，”Param_1″);

参数转为变量

strcpy(str1，lr_eval_string(“{Param_1}”));

4、简述LoadRunner的工作原理?

答案： loadrunner会自动监控指定的URL或应用程序所发出的请求及服务器返回的响应，它做为一个第三方(Agent)监视客户端与服务器端的所有对话，然后把这些对话记录下来，生成脚本，再次运行时模拟客户端发出的请求，捕获服务器端的响应。

5、LaodRunner脚本中action和init、end()除了迭代的区别还有其他吗?

答案： 集合点只能插入到Action部分，vuser_init和vuser_end 中不能插入集合点。action()和init、end()都可以插入事务点。

6、什么是集合点?设置集合点有什么意义?LoadRunner中设置集合点的函数是哪个?

答案： 集合点：是一个并发访问的点，例如在测试计划中，可能会要求系统能够承受1000 人同时提交数据，在LoadRunner 中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner 就会检查同时有多少用户运行到集合点，如果不到1000 人，LoadRunner 就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000 人时，LoadRunner 命令1000 人同时去提交数据，并发访问的目的。

注意：集合点经常和事务结合起来使用，常放在事务的前面，集合点只能插入到Action 部分，vuser_init和vuser_end 中不能插入集合点。集合点函数如下：lr_rendezvous(“SubmitData”)

7、录制Web脚本时，生成的脚本中存在乱码该如何解决?

答案 ： 录制脚本前，打开录制选项配置对话框Record-Options，进入到Advanced标签，先勾选”Support charset”，然后选择中支持UTF-8再次录制，就不会出现中文乱码问题了。

8、HTML-based script与URL-based script的脚本有什么区别?

答案： 使用”HTML-based script”的模式录制脚本，VuGen为用户的每个HTML操作生成单独的步骤，这种脚本看上去比较直观;使用”URL-based script”模式录制脚本时，VuGen可以捕获所有作为用户操作结果而发送到服务器的HTTP请求，然后为用户的每个请求分别生成对应方法。

通常，基于浏览器的Web应用会使用”HTML-based script”模式来录制脚本;而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、基于浏览器的应用中使用了HTTPS安全协议，这时使用”URL-based script”模式进行录制。

9、使用LoadRunner进行综合场景测试，如何设置能够使被测系统所受压力减轻，请分别加以说明。

答案： 若使被测系统所受压力减轻，可从如下方面进行综合调解：

将测试脚本中think time值加大并在控制台中按比例实现，此处think time指在transaction外部的时间;

Controller中Run-Time Setting的Pacing设置值加大;

虚拟用户登录时使用递增策略，间隔稍长。

软件系统测试中的场景建模技术应用 第6篇

软件系统测试现状

作为现代信息系统的核心，软件的作用日益突出。为了令软件产品功能更完善、架构更健壮、性能更可靠，系统测试工作贯穿于软件生命周期的每个阶段。软件研发过程中，工程人员需要开展各种不同类型的测试，包括单元测试、部件测试、配置项测试、系统联试和系统测试等。

系统联试是由软件研制单位组织的系统连通性验证试验，重点关注系统主要功能的正确性，而受软件研制人员自身思维定势所限，测试粒度、完备性都不够理想。

配置项测试是对组成系统的各个软件配置项进行测试，重点考查软件功能实现的正确性和完备性，能够较好地发现软件中存在的问题，但受制于配置项测试的环境因素，往往不能如实反应外部相关软件的实际影响，难以验证系统主要业务流程的正确性和协调性。

面对上述问题，进行软件系统测试就显得尤为重要。系统测试是软件测试工作的重要环节，目的是在实装环境（包含真实的人、机、数据环境）或接近实装的环境中，考查系统各业务流程执行的正确性和协调性，从而验证系统软件是否达到研制总要求，以及系统和子系统段设计文档中所列出的全部功能和指标需求。

目前，复杂任务电子信息系统多为庞大的系统工程，硬件结构繁复，软件架构庞大，且由众多不同领域的企业协同开发……这为系统的软件测试工作带来了诸多困难：多单位协同开发，测评环境往往分布于多地，且侧重点不同；系统规模庞大，系统内外部接口复杂，测试人员需要理解整个被测系统，作为测试依据的被测系统设计/输入类文档的质量及详细程度影响着整个系统测试质量。面对上述情况，探寻有效的系统级测试实施策略与技术方法显得尤为重要。

软件系统测试技术研究

若干实践经验表明，有效的软件系统测试必须包括选取确定的测试范围、系统场景建模、测试内容策划等关键环节。

大型任务电子系统的内外部接口关系复杂，由不同专业的分系统构成，按照严格的科研管理流程，通常由研制企业内部进行软件单元/部件测试，配置项测试以及出厂（所）测试，由经国家授权的软件测评机构执行第三方配置型测试、分系统测试以及系统测试。其中分系统软件测试工作将重点关注构成分系统的软件配置项的功能、内外部接口、性能等要求的实现情况，并能给出分系统的测试结果。考虑到系统的规模、复杂度以及分系统测试工作的实际情况，在启动系统测试时，需对系统功能进行筛选，选取出需要进行系统级测试的系统功能。因此必须确立相应的筛选原则，以保证系统测试的有效性与逻辑覆盖的完备性，在工作中总结出以下原则：涉及分系统之间交互的功能点需被选取，而在分系统内部闭环的功能点不被选取；在测评环境满足的前提下，选取覆盖最大闭环路径长度的业务流程进行系统功能验证。

随着UML在软件开发过程中的广泛运用，基于UML 的测试技术逐渐受到人们的关注。UML顺序图是一种常用的UML动态建模模型，可以建模系统的使用逻辑（或称为应用场景），具有直观、半形式化等特点，包含丰富的、体现设计架构的系统信息。适用于描述对象之间的动态交互关系，显示一个协作涉及对象的消息传递关系，它着重体现对象间消息传递的时间顺序。

UML的顺序图有两个维度：纵向是时间线，定义对象在交互活动中的生命周期；横向是不同的对象。顺序图中用一个带有垂直虚线的矩形框表示对象，矩形框内标有类名、对象名或角色名。垂直虚线称为生命线，代表在对象之间的交互作用中该对象的生命周期。对象间的通信消息通过对象生命线之间的箭头表示，箭头上方标注消息名和一些控制信息。接收对象收到消息时被激活，在对象生命线上显示一个细长矩形框来表示，激活描述在一定时间段内对象执行操作的持续时间。

在场景建模阶段，通过分析系统研制总要求、系统/子系统段设计文档等测试依据类技术文档，以及与软件研发人员和系统使用人员进行交流沟通，获取被测任务电子系统的主要业务流程。根据提取的业务流程，利用UML顺序图进行场景建模，不仅能够清晰地展现系统业务流程中的动态交互关系，还有助于测试项的确定以及潜在业务流程的发掘。

根据系统典型应用场景对各系统的综合应用工作流程进行测试。各应用场景用例主要用来验证各分系统间的协调性和正确性。系统级应用场景是指至少涉及两个分系统之间的集成工作流程。任务电子系统测试时基于分系统间的交互关系进行系统应用场景分析，首先建立获取顶层的系统应用场景，再逐层细化分析出各分系统之间的集成工作流程，如任务执行场景等。

清晰完整、合理可行的测试项集合是测试项目顺利开展的必要条件，进行场景建模的目的正是为了提取系统测试的测试项。业务流程场景图的建立能够清晰地展示业务流程相关的测试项，方便了测试项的确定。

然而测试项的划定必须考虑测评环境的制约——环境因素可能会影响业务流程执行的畅通性，还必须对环境带来的差异进行有效地分析确认，使其能够充分支持业务流程的验证。

在确定测试范围的基础上，依托场景图和实际环境因素，给出测试项相关的测试类型并明确各种测试类型的测试方法、测试输入/输出数据以及测试通过判断准则等信息，从而完成在特定场景下对相应系统功能的测试内容策划，并填写相关信息。

测试项的建立过程中需要积极和软件研制人员与系统分析使用人员沟通交流，确保测试项内容的正确性、完整性。测试项的完整性体现了对顶层需求（包括隐含需求）覆盖的完整程度，同时能够反映测试的充分性。为了及时掌握测试项完整性情况，可建立需求追溯矩阵来反映当前测试项对顶层需求的覆盖情况。

nlc202309061017

软件系统测试用例开发设计辅助环境

根据UML顺序图应用场景建模执行软件系统测试，可以实现软件系统测试用例开发设计环境，其中内嵌了符合UML 2.0规范的建模组件，能够针对软件系统应用场景进行建模，然后基于模型，结合软件配置项测试、子系统测试阶段设计的测试用例，生成软件系统测试应用场景的测试用例集，满足软件系统、分系统、子系统的测试需求。

软件系统测试用例开发设计环境使用UML描述应用场景模型，并基于该场景模型生成对应的测试用例集合。系统测试人员可根据自动生成的测试用例集合进行修改或优化，得到最终测试用例集。

软件系统测试用例开发设计环境由场景顺序图建模、测试用例生成两个子系统，由图形用户界面、模型生成、模型解析、场景树生成、用例生成等模块共同组成。

进行系统测试场景模型建模时，使用符合UML 2.0规范的顺序图描述系统级的事件交互及事件的顺序，对系统的参与者（用户、子系统或配置项）、参与者之间传递的数据或调用命令等系统组成要素进行建模。在顺序图中，须测试的应用场景被定义为在相互交互过程中的各对象间传递的一个消息序列，每个消息序列代表一个可能的事件流，在一个顺序图中通过分支和循环结构可实现多个场景的定义。

对于每一个测试场景，建立各对象（用户输入、子系统或配置项）的测试用例，其输入和输出参数化，定义各对象测试用例的执行流程顺序；按照执行流程顺序，关联各测试用例的输入.输出参数；测试场景的测试用例实例化按照覆盖正常值和边界值的原则，对测试场景的测试用例进行实例化脚本生成。

基于UML2.0的被测系统应用场景建模主要基于顺序图完成给定的典型应用场景的建模，其建模过程可按照系统、子系统分层建立，建模后形成基于元数据交换格式XMI（XML Metadata Interchange Format）模型文件。

解析由XML表示的UML顺序图，提取相关信息建立场景测试树；对于要进行测试的具体场景，记录该场景的条件约束、各对象状态等模型中的语义信息。基于顺序图的用例生成技术使用这些信息生成测试用例所需数据，并与场景结合生成实际的测试用例，场景实例化主要基于XML解释程序解析由XMI表示的UML顺序图或状态图，主要对IF、While等进行处理，生成无分子转移的顺序流程，形成场景测试树，其叶节点可为子系统或配置项。

系统测试用例生成过程读入UML 2.0实例化场景模型文件解析后的信息、对于每一个被测应用系统测试场景，按照分层原则，完成测试用例的开发、设计，必要时，建立相应的测试控制脚本。包括输入和输出参数化，定义各配置项测试用例的执行流程顺序；按照执行流程顺序，关联各测试用例的输入输出参数；测试场景的测试用例实例化按照覆盖正常值和边界值的原则。

软件系统测试用例开发设计环境的运行过程分为“场景建模”与“测试用例生成与优化”两个主要阶段。

软件系统测试用例开发设计环境场景建模工具提供图形用户界面，包括符合UML2.0规范的建模界面和模型元素，对任务电子信息系统、分布式应用系统的典型应用场景进行UML顺序图建模，根据典型应用场景建模生成的顺序图保存为可解析的模型文件（XML格式）。

测试用例生成包含模型解析、场景树生成与用例生成三个主要过程。“模型解析”提取场景顺序图的模型文件，将其转换为XML格式的中间文件，获取该场景的参与者、消息及相关约束等信息；“场景树生成”，根据模型解析生成的XML文件生成测试场景树数据文件；“用例生成”根据生成的测试场景树文件生成测试用例集，并进行优化，最终产生该场景的最小测试用例集，以XML格式存储到本地文件系统。

算法实现的基本过程包括：查找顺序图中的基本流，基本流即无警戒条件的消息。将找出的基本流序号按次序放入容器m_BaseFlow中，另外对于那些有警戒条件的消息，根据他们的值，将这些消息分组，有相同警戒条件值的消息划分在同一组，有些警戒条件是由若干个其他警戒条件用连接符AND，OR和NOT组合而成，那么还要记录这些警戒条件是由哪些其他警戒条件共同组成。

找出顺序图中所有的场景结束点，将所有的结束点的序号按次序存放在m_EndPoint容器中，所谓顺序图的场景结束点就是被标注了<>的消息。

根据警戒条件进行排列组合运算，得到相应的场景序列。查找生成的场景序列中是否有多个结束点，如果有多个结束点，这个场景就不正确，将在场景容器m_SceneVec中删除。最后，去除重复的场景序列以及含有子场景的场景序列。

综上所述，针对复杂电子信息系统软件系统测试的实施过程，基于场景建模的系统测试技术方法给出了基本实现方法和软件实现实例，目前已在多个大型系统测试项目开展过程中运用，在保证系统测试完备性、提高工作效率方面，可以取得很好的效果。

软件系统的测试论文 第7篇

1.1 测试与测试用例关系的处理

设计测试用例之前非常重要的一步, 就是确定自动测试用例的组成部分。测试用例对于不同的人而言持续时间是不同的, 较长的测试用例通常由一系列单个测试组成, 每个矩形代表一个测试用例, in和out分别表示测试时激活和终止软件, 每个测试由单个测试用例完成, 测试用例完成所有的测试。无论哪种执行方式, 这些测试的输入和期望输出是相同的。

1.2 前处理与后处理

之所以对测试用例的前处理和后处理进行自动化, 主要原因是前处理和后处理的类型比较单一 (它们各自有如上文列出的这4种类型) , 重复率高 (基本上每个测试用例都包含前处理和后处理) , 且易于实现自动化 (它们几乎都是如拷贝/转移文件这样的简单操作) 。同时, 在自动化测试过程中, 可以看出前处理和后处理出现在整个测试的不同层次。不仅仅是单个测试用例包含前处理和后处理, 每个测试件组甚至这个测试集都包含。

1.3 比较输出的方法

输出结果比较方法有两种:动态比较与执行后比较。动态比较, 是指在执行测试用例时进行的比较。执行后比较是指在测试用例运行后执行比较, 执行后比较主要用于比较发送至屏幕上以外的输出, 如已创建的文件和数据库更新过的内容。动态比较有助于使测试用例更智能化, 使之根据输出采取相应的动作, 增加脚本的弹性。而执行后比较在比较顺序和内容上都更加具备可选择性, 可以使测试执行结果更直观。

2 自动测试用例的设计

2.1 手工脚本与自动脚本

测试脚本是交互应用或部分非交互应用的测试自动化中必要的组成部分。它分为模糊的手工脚本, 详细的手工脚本和自动脚本。模糊的手工脚本, 含有测试用例的描述, 但不对输入和比较进行详细描述, 测试条件可能是隐含的而不是显示说明的。模糊的手工脚本用于自动测试, 取决于测试工程师的技能, 要求他能确定测试条件且对软件和应用有所了解。详细的手工脚本, 含有准确的测试输入数据及相应的测试输出结果, 可以严格按脚本进行测试。在此基础上进行自动测试就比较容易。自动脚本, 含有测试工具中使用的数据和指令。如同步、比较信息、从何处读数据和将数据存放何处, 以及控制信息。

2.2 比较输出的实现

本自动测试系统所采用的比较方式动态比较与执行后比较相结合的方式。伴随自动测试用例的执行, 输出各个执行步骤相应的结果, 同时在测试用例执行完后输出一个汇总的结果。为了避免由于一些次要的因素影响到测试结果的正确性, 因此不采用单纯地显示最终测试结果是通过或是失败, 而是以一种汇总的形式, 列出每个测试步骤执行结果及执行成功的测试步骤数占总测试步骤数的比率。这也方便测试工程师查找出错原因, 使测试结果更人性化。

3 脚本技术

3.1 脚本语言的组成

自动测试脚本所使用的编程语言的来源有:

1) 发展得比较成熟的解释性编程语言Tcl;2) 本自动测试系统的核心驱动TET所提供的、与Tcl兼容的API函数;3) 网络管理工具Scotty所提供的API函数;4) 作者进行二次开发得到的功能函数及软件包。

3.2 自动测试脚本技术的类型

1) 线性脚本。在录制手工执行的测试用例时得到的脚本。包含所有击键操作, 有时包含比较指令。每个测试用例可以通过脚本完整地被回放。在自动测试系统发展的第一阶段, 这种脚本应用得相当普遍。2) 结构化脚本。类似于结构化程序, 含有三种基本控制结构 (其顺序结构就是线性脚本) , 但还可以“调用”其他脚本。这种脚本的主要优点是健壮性更好, 结合了模块化编程, 提高了复用性, 也增加了功能和灵活性。与此同时, 脚本变得更加复杂, 测试数据仍包含在脚本内。3) 共享脚本。可以被多个测试用例复用, 即脚本语言允许一个脚本被另一个脚本调用。它的主要思路是产生一个执行某种任务的脚本。其优点是能减少维护开销, 但若要充分发挥共享脚本的优点, 则好的技术人员和配置管理系统十分重要。共享脚本比较适合小型系统或大型应用的一小部分。4) 数据驱动脚本。将测试输入和期望输出储存在独立的 (数据) 文件中, 而不是存放在脚本中。脚本中存放控制信息。执行测试使从文件中读取测试数据, 这样只需修改数据表便容易增加新的测试而无需修改脚本。

4 编程风格与规则

4.1 编程风格

自动测试用例是自动测试系统的一个重要组成部分, 测试脚本的好坏直接关系到整个系统的运作情况。作者总结了几点在本自动测试系统中自动测试用例的编程风格:1) 保持测试脚本与共享脚本、支持脚本等的统一风格, 保证不同的测试程序遵守同一个标准格式, 便于使用, 阅读及维护;2) 统一变量命名规则, 防止变量名重用;同时注意使变量名更具可读性, 如vlan_info表明该变量保存VLAN的相关信息;3) 为测试脚本添加详细注释, 如果是以详细手动脚本为基础进行自动测试脚本的编程, 则注释可以略微简单 (注意:注释不是简单重复代码) 。

4.2 编程规则

为确保自动测试用例能顺利执行, 自动测试用例编写者需要遵循以下规则:1) 确定测试策略, 本系统中自动测试用例可以分为两类:初始条件测试和常规测试, 各自适合不同的测试情况;2) 测试中每一步的执行, 要求使用支持脚本中的信息报告函数来告诉测试工程师测试的进展;3) 处理好局部变量和全局变量:在每个步骤中定义的局部变量, 只在定义所在的步骤中生效, 而从测试数据文件以及系统文件获得的数据作为整个测试用例的全局变量;另外, 作者设计的脚本编辑器 (SFEditor) 也提供测试脚本的自动生成, 以及常用脚本命令和ARIES系统提供的关键字。测试工程师编写自动脚本可以通过填写SFEditor提供的对话框来完成, 无需学习各种测试工具的底层接口命令等, 缩短了工程师编写脚本的时间。

参考文献

[1]Elfriede Dustin, Jeff Rashka.Automated Software Testing:Introduction, Man-agement, and Performance电子工业出版社, 2003.

软件系统的测试论文 第8篇

在现阶段,如果发生软件安全事故,不仅会给人们造成巨大的经济损失,还会影响我国经济的稳定。并且随着我国软件安全测试技术的发展,软件测试例集也在不断地增长。而基于测试覆盖的安全关键软件测试技术是一种效率高、安全的软件安全测试方法,在软件领域具有很广泛的应用。所以测试人员应该重视基于测试覆盖的安全关键软件的测试。

1 基于测试覆盖的安全关键软件测试方法

1.1 测试特点

所谓安全关键软件就是指安全系数高、可靠的软件。这种软件在各个领域都有很广泛的应用。常见的应用领域是在安全系统中。安全关键软件主要是通过在特定的硬件环境中应用软件。在应用软件的过程中,会产生很多的数据流,如控制执行语句、传感器信息、接口交互信息。当用户使用时,安全关键软件就会进行实时计算,并作出相对的反应。而当非法用户入侵时,安全关键软件会快速的进行信息筛选、分析,并作出应对。由此可见,在开发安全关键软件时,应该进行危险分析,并对可能会出现的非法攻击等安全问题进行预防。

因为安全关键软件具有一定的特殊性,所以基于测试覆盖的安全关键软件的测试也具有特殊性。首先,它需要配套专门的测试工具。其次,如果软件的开发环境和软件的运行环境不相同时,那么在测试完主机后,还要再进行目标机器的测试。之后,如果测试输入的语句复杂度较高,那么在进行常规的语句测试之后,还要进行时序关系等其它约束语句的测试。最后,对于软件是否具有可靠性指标,采取不同的测试方法。如果有,则需要进行可靠性增长测试。如果没有,则需要进行软件可信度的测试。

1.2 测试策略

基于测试覆盖的安全关键软件的测试需要以生命周期模型为导向,采用白盒测试或者是黑盒测试,进行测试覆盖率的信息收集,并以此而为动态参考数据。基于测试覆盖的安全关键软件测试包括三个步骤。首先,应该先排序例集,并确定优先级。例集主要是通过安全系数分类之后,采用黑盒测试法获得的。其次是对重要的模块进行有限测试。最后是在有限测试所得数据的基础上,进行回归分析,从而得出测试覆盖的增长函数。

在这个过程中,选用的测试用例应该能够促进测试覆盖有促进作用。同时,如果在测试过程中,软件产生多余的残留数据信息,如软件的缺陷属性,则需要建立缺陷模型来保证软件测试充分性和正确性。此外,测试人员还可以通过增加测试用例,来提高安全关键软件测试的精确性。其测试策略如图1。

2 基于测试覆盖的安全关键软件测试的实例

本文以主控软件的测试作为示例。在基于测试覆盖的测试方法中,增加了传统测试方法,然后将两者进行分析对比。实践证明,基于测试覆盖的安全关键软件测试方法具有高效性、短时性。

(1)软件测试的第一步是分析软件的安全性,并确定软件的危险级别。主控软件是一种嵌入式软件,其安全系数比较高。如果主控软件的数据通讯发生通讯链路故障,那么就属于严重危险,而如果数据通讯发生数据内容错误,则属于轻度危险。当主控软件的调焦控制发生接收命令有误的故障,则属于轻度危险;如果调焦控制出现电机驱动故障,则属于严重危险。

(2)确定量化软件的测试覆盖目标。依据主控软件应用在航天型号软件中的特点。该主控软件的测试覆盖目标主要包括两个方面,一是根据实际需要,分解测试项之后,要求需求细节的覆盖率达到100%。同时测试类型必须符合相关标准。二是要应用测试工具时,要分析源程序的覆盖范围。并保证语句覆盖和分支覆盖都能达到10%。

(3)测试用例的选择。主控软件的测试项包括工基本功能、处理时间的余量等83测试项。因而其测试用例大约需要528个。并且测试用例的设计需要利用功能分解、边界值分析等方法。同时要求测试用例的覆盖目标达到100%。

(4)测试环境的准备。基于主控软件运行在太空环境下,因而测试环境配备的是以TestB ed为测试工具,并标配RTInsight数据信息采集工具,同时还添加了RTInsignhtP ro作为结构覆盖测试工具。此外,为主控软件提供的是DSP SMJ320运行环境和软件测试平台。

(5)测试数据信息的收集。主控软件的数据信息采集工具是RTInsight,其主要收集步骤包括硬件连接、源代码插桩、执行测试、分析数据、保存及导入测试记录。所谓硬件连接就是利用三态门将测试工具和测试系统连接起来。此外,为了能够实时掌握监控总线的写入操作状态,需要CSO和WEO分别于写信号、片选相连接。而为了实时掌握监控总线的读操作,需要DATA-CS1和DATA-RD分别于片选和输出相连接。所谓源代码插桩是利用插桩模板,将源文件引入Testbed中,然后根据运行的数据结果进行分析。如果需要二次插桩,则需要将编译后的.Obj文件转换成可存储的代码。所谓执行测试就是建立工程文件,并输入识别地址,连接后即可开始测试程序。所谓数据分析是指根据在测试过程中收集的结果数据,分析语句覆盖率、分支覆盖率、函数时间性能测量值。而数据保存就是利用RTInsight数据信息采集工具实时的保存测试数据。之所以采用专门的数据收集工具是因为软件测试过程中产生的数据流太多。最后是测试记录,测试记录需要记录缺陷数、用例个数、语句覆盖率和分值覆盖率。实际的测试结果如图2,从表中数据可以看出,测试用例个数是528,缺陷数是18,但是语句覆盖率是86.55%,分支覆盖率为67.74%。x可见,语句覆盖率和分支覆盖率并没有达到标准。

(6)预测软件中的剩余缺陷。在预测剩余缺陷之前,需要对测量数据进行归纳和整理。首先是采用了传统软件测试方法,补充了696个测试用例,实际用例数是1224个,执行时间是21天,总共发现了23个问题。其中包括总线通讯、时序控制、指令处理、橡移计算、偏流控制、调焦控制、温度控制、新能指标、成像控制这个几个大方面。缺陷类型包括接口缺陷、输出缺陷、逻辑缺陷、输入缺陷、输出缺陷、数据缺陷、设计缺陷、文档缺陷。之后又采用了基于测试覆盖的测试方法。相比传统测试方法,该方法又补充了45个用例,总共执行了573个用例,执行时间是8天,发现了31问题。然后通过代码的人工走查方法,使语句覆盖和分支覆盖率达到100%。人工走查发现软件缺陷的模块主要包括成像控制、时序控制、温度控制、总线通讯、像移计算。

(7)测试数据分析。在该主控软件的测试中,采用了传统的测试方法和基于测试覆盖的测试方法。其中传统测试方法的实际用例个数是1224个,执行时间是21天,发现的缺陷个数是24个。基于测试覆盖的测试方法的实际用例个数是573个,执行时间是8天,发现缺陷个数是31。两者相比不难发现,基于测试覆盖的测试方法具有很明显的优势,它不仅能够缩短软件测试的执行时间,还能提高软件测试的精确度。基于测试覆盖方法相比于传统测试方法在发现缺陷个数上,其工作效率提高了33%。由此可见,采用基于测试覆盖的软件测试方法能够快速、高效的完成测试任务。

3 总结

综上所述,安全关键软件测试的最佳方法是利用测试覆盖方法。尤其是在安全软件被广泛应用的背景下,提高安全关键软件的测试效率是提高软件的安全性能的关键。所以为了促进我国软件行业的快速发展,促进我国信息化社会的进步,应该积极利用测试覆盖方法来测试安全软件,从而保证软件的可靠性和安全性。

参考文献

[1]黄丹丹,刘超,储开华.基于测试覆盖的安全关键软件测试策略探讨[J].数字技术与应用,2015.

[2]崔天意,肖洋.安全关键软件测试设计方法[J].甘肃科技,2015.

个性化推荐系统的系统测试研究 第9篇

关键词：测试模块,个性化,子系统

系统测试是一个十分重要的一步,是保证系统能正常的运行测试。系统测试的目的是验证系统是不是能够符合用户的需要,同时通过测试找出与系统中各个BBUUGG或与之矛盾的地方,从而进行更加完善的方案修改,来满足实际情况的需要,进一步提高系统统的的可可靠靠性性和和稳稳定定性性。。

1系统测试环境

基于社会计算的个性化推荐系统采用如表1的测试环境。

2系统模块测试

系统模块测试是保证软件质量不可或缺的一步。通过软件测试,检测出系统模块存在的Bug和不足之处,是否符合用户的需求,能否快速高效地运行都能从中体现出来。它也是对之前需求分析工作和系统开发工作的检查和反馈。

一般来说,模块测试的方案也比较容易设计。在一个完整系统中,模块下都包含有明确的子功能。而且,同级其他模块的子功能跟这个子功能是没有关联的。所以,可以把每个模块视为单独的测试实体。模块测试就是检测每一个模块单元能否顺利的执行程序。

一个高效的测试需要有一个详细的测试计划以及覆盖率达标的测试用例。因此,系统模块测试主要以介绍设计用例来展开。。又又因因系系统统模模块块比比较较多多,,主主要要以以采采集集模模块块的的测测试试为为代代表表来来展展开开的。

1) 采集模块功能测试

采集模块测试环境配置如表2采集模块测试环境表所示。

2) 采集模块测试用例

采集模块主要涉及爬虫参数设置测试用例、网页文档信息采集测试用例、搜索推荐测试和创建索引测试用例。下面就以创建索引测试用例为代表,阐述该模块的测试用例,如表3推荐搜索测试用例表所示。

3) 采集模块接口测试

接口测试主要是测试程序能否支持在不同的系统,以及能否正确识别所使用的系统,对不同的系统,功能以及界面上是否存在不同,其测试方案如表4接口测试用例表所示。

4) 采集模块测试结果

通过测试发现,系统能够正常与服务器建立连接,其运行稳定,能够实现数据采集和信息推荐等基本功能。系统界面简洁,功能实用,性能可靠,具有良好的易用性,能够进行充分的使用,基本上达到达到需求规格的要求。

3系统整体测试

1) MyEclipse环境配置

打开MyEclipse 8.5后,选择file—Import,如图1界面选择图所示,选择Existing Projects into Workspace。

然后点击Browse…选择项目的目录,打开之后按Finish如图2系统导入图所示。E

读取成功后要载入Tomcat,点击快捷键栏的Deploy and undeploy J2EE projects.如图3添加Tomact图所示。

选择Add,在Server栏目下啦,选择MyEclipse Tomcat项目,按OK。

2) 连接数据库

打开项目中的jdbc-mysql.properties,在“jdbc.password=”输入电脑的数据库密码,保存。如图4数据库密码设置界面图所示:

运行程序,在最下面的栏目的Servers中找到MyEclipse Tomcat如图5 MyEclipse Tomcat启动图所示:

右键MyEclipse Tomcat,选择Run Server运行项目。

3) 系统页面环境参数配置

在主页右上角点击“后台管理”,然后进入如图6爬虫采集参数配置界面图,可进行爬虫采集相关参数的配置。

配置完数据后,在“采集开始”页面点击“开始采集”,就会进行采集数据,并将数据储存在数据库里。如图7采集数据界面图所示。

采集完毕后,在“创建索引”栏目点击索引,如图8数据索引创建图所示。

接下来,可以在“采集信息查看”栏目看见程序采集的数据内容,如图9数据维护界面图所示。

4) 系统界面测试

打开网页浏览器,输入http:// localhost:8080,这样就好显示出搜索页面。前台用户通过输入关键词查询对此关键词提及最多的用户。系统界面如图10系统测试界面图所示。

输入关键词,点击查询显示结果,得到如图11系统查询结果界面图所示。

5) 系统测试结果

软件测试对于提高软件质量的作用 第10篇

1.1 测试过程

软件开发是一个常规的过程, 在当今时代环境下, 一般分为4个阶段, 每个阶段中都需要对软件进行内部测试, 一般分为:静态分析、代码审查、单元测试、部件测试、配置项测试。

1.1.1 静态分析

使用专业静态分析工具, 对软件应用的程序, 数据等参数进行剖析, 并进行深入的数据分析, 将软件应用内部的静态信息和代码信息提取出来, 为未来的动态测试提供参考数据, 并根据现在的软件模型, 对软件的质量做出正确评价。

1.1.2 代码审查

主要是对代码进行一系列专业的检查过程, 对代码的容错绿, 代码运转结果的一致性, 代码的可读性等进行检查分析。重点对代码的逻辑性, 完整性进行检查, 保证正确率。

1.1.3 单元测试

按照软件设计的说明图, 模拟软件运行环境和运行部件, 针对软件的环境进行接口模拟, 并创造出软件的真实运行环境, 进行测试, 监测软件的运行结果。

1.1.4 部件测试

按照被测软件的说明图, 在单元测试的基础上, 将各个测试成功的单元模块按需求和设计组装成一个符合设计需求的整体功能模块, 并进行测试, 其目的是监测软件各个单元和接口之间的兼容性和容错率, 保证软件的设计成功。

1.1.5 配置项测试

所谓配置项是软件中为满足不同用户的不通需求而设计的, 能体现用户个性化功能的配置功能项, 测试的目的是监测配置项在软件中的一致性。

1.2 问题现象

某产品软件到了后期阶段仍在进行频繁更改, 通过对其分析, 得出软件复杂度高是其存在的主要问题:

(1) 模块在结构上应使用单出入口的结构, 降低复杂性。

(2) 在模块的逻辑设计上进行改进, 采用分层次的结构, 并在不同层次上设计不同的扇入扇出数, 保证模块的扇出数较低, 一般不超过7, 并且尽可能的增加模块的扇入数, 以保证代码的简洁性。另外, 高层模块的设计应该采取不同策略, 比如高层模块扇出较高, 低层模块扇入较高等。

(3) 软件单元的圈复杂度 (即Mc Cabe指数) 应小于10。

(4) 简化软件单元的源代码数量, 高级语言实现的单元, 不应超过60行。

1.3 问题分析

测试的目的是为了更正软件的错误, 降低风险率, 一般来说经过几个阶段的测试后, 软件中的缺陷基本都能被修复, 但是没有重视静态分析中的软件圈复杂度, 基本复杂度超标的现象, 软件在后期的高复杂性往往会带来潜在的风险。

2 测试指导设计

2.1 软件质量的pareto原理

pareto原理[2]指出, 20%的软件模块包含了软件中80%的缺陷, 20%的软件改进, 需花费80%的适应性维护费用。从这里可以得出结论, 高复杂的模块会导致软件中可能出现的绝大部分错误, 而且不容易修复。因此, 在软件设计早起杜绝复杂度过高的风险十分必要。

2.2 降低软件圈复杂度

2.2.1 圈复杂度定义

圈复杂度作为一个衡量软件结构复杂性的标准, 数量上表现为独立线性路径条数, 即合理的预防错误所需测试的最少路径条数。1976年Thomas Mc Cabe提出了圈复杂度 (Cyclomatic Complexity) 的概念, 依据圈复杂度定义了软件的复杂性。1977年Halstead提出了软件科学复杂度度量。文献[3], 在这个理念中重点分析了嵌入式软件的位置的重要性, 并通过模型的方式展示了软件复杂度的度量对识别代码错位的重要性。可以看出, 软件的错误和缺陷并非随机分布的, 而是有迹可循, 和软件的个性化, 复杂度息息相关。

2.2.2 复杂度计算方法

C语言常用的软件模块逻辑结构 (结构流图) 有如下几种, 如图3所示。

2.2.3 降低圈复杂度

如果圈复杂度高于标准值的时候, 可以提前做出判断, 降低代码的复杂度和重复性。在判断语句中采取单一的判断条件, 或者将重复代码用一个函数来替代。都是降低代码复杂度和重复性的有力措施。

2.3 降低软件基本复杂度

运转正常的语句或代码应带保证单入口和单出口结构, 保证程序的简洁性, 不应过多使用异常跳转语句增加程序的运转复杂度, 如果非结构化语句过多, 出入口增大, 只会导致结构的复杂度增高, 增加软件后期运行的风险。

因此, 只要控制程序语句的结构单一化, 简单化, 避免各种非正常跳转语句的使用, 复杂度就会在可控制的范围内, 有利于程序的运行稳定。

2.4 降低软件扇出数

扇出的意思是函数调用其他函数的个数, 如果扇出过小, 则会导致程序代码过长, 如果扇出过大, 则会增加程序内函数的调用次数, 影响速度, 一般来说扇出最好为3或4个, 最高不超过7个。

扇入的意思是一个函数被其他程序调用的次数, 扇入较多会增加模块的使用频率, 但是过高的扇入会影响程序的聚合性, 如果扇出扇入次数过高, 可以考虑重新调整该函数或过程。

3 结语

本文通过以测试结果来倒向改进软件设计的思路, 提高了软件的设计质量和可靠性, 可以看出, 在软件代码内部进行早期分析, 在软件设计早期对软件代码, 复杂度等指标进行优化限制, 对软件后期的稳定运行, 错误率降低有非常大的影响和帮助, 成为软件改进的新思路。

参考文献

[1]尹平, 许聚常, 张慧颖.软件测试与软件质量评价[M].北京:国防工业出版社.2008.

[2]SCHULMEYER G G.软件质量保证[M].北京:机械工业出版社, 2003.

软件系统的测试论文 第11篇

关键词：交互式电子技术手册；通用测试；故障诊断；维修保障

中图分类号：TN431 文献标识码：A文章编号：1007-9599 (2011) 08-0000-01

Universal Testing System Design for Weapon System Based on IETM

Hong Chenghua1,Cao Juan1,Zhao Xuyang1,Mi Wengpeng2

（1.Teaching&Research Section 103,the PLA Second Artillery Academy,Qingzhou262500,China;2.Teaching&Research Section 202,the PLA Second Artillery Academy,Qingzhou262500,China）

Abstract:This documents introduces the outline,the key technicians of the Interactive Electronic Technical Manual(IETM)of the weapon general testing system And the design,usage,maintenance,repeir message of the weapon and their security equipment are described to the commander and the testing operator in an alternating mode,therefore the independently testing maintenance ability of the grass-roots army are increased greatly.the grass-roots army are capable of using and maintaining testing security equipment.

Keywords:Interactive electronic technical manuals;Universal test;Fault diagnosis;Maintenance Support

一、IETM技术概述

IETM不仅实现了技术手册的数字化，而且它具有交互功能，实现了技术手册的智能化。IETM能够将武器装备全寿命周期内产生、传递、使用的大量技术信息和数据结合为一体，并可嵌入武器装备、维修设备、训练模拟系统以及交互式多媒体教学课件中，为操作人员提供适时、适需、适用的技术指导和信息支持，其主要特点包括：多样化的应用形式、详尽的电子手册、灵活的存储介质、关联的信息元素和标准的数据输出。

二、关键技术

（一）标准化技术

信息共享、产品数据的互操作是IETM的核心问题，而实现信息共享的前提和基本保障是标准。目前，IETM的许多标准以军用标准为主。

某武器系统通用测试系统IETM根据相应的标准通过对所有信息的描述采用标准化技术，实现在构建IETM的过程中，IETM的数据组织结构以及数据之间的关联的关系都已结构化、标准化形式存在。这样无需太多的改动就能完成对已开发的IETM修改或更新，提高了其可配置性和灵活性。

（二）交互式的故障诊断模式

通过与用户进行交互，指导最终用户的学习过程和故障排除过程是IETM的一个重要特点。

在本系统中结合IETM的编制标准，以某武器系统和设备的设计文件为基础，以用户熟悉的故障树方式组织一个具体故障的排除过程，采用冲突消解算法把某武器系统和设备的各故障模式加人IETM，生成适用于IETM的某武器系统和设备的各个故障模式，在体验上以交互式对话框方式来呈现，从而实现指导用户进行故障诊断和维修维护。

用户得到相应的测试模型、诊断策略、依赖矩阵是利用设计文件生成TEAMS诊断策略文件，再将TEAMS文件直接导人IETM通用开发平台中。这样并生成相应的故障树，可以用交互式的方法指导用户进行故障诊断工作。

三、某武器系统通用测试系统IETM设计

某武器系统通用测试系统IETM的开发平台用于IETM的创作，运行平台完成IETM的浏览及使用。在电子装备设计阶段，设计人员可以将各类工程数据通过IETM开发平台电子化、标准化，并可以载人相关的诊断策略，通过IETM开发平台的发布功能形成可供维修人员使用的电子手册。

（一）系统的总体架构

IETM系统设计的总体架构如图1所示，主要分为IETM编辑、数据内容管理和IETM发布3个主要阶段。

图1.IETM制作总体架构

某武器系统通用测试系统IETM发布后，主要用于两个方面：一是用于院校和科研院所对相关技术人员进行教学培训工作；二是用于部队测试保障现场，指导基层战士进行某武器系统测试和设备的维护、维修工作。

（二）系统功能设计

考虑到新型设备刚装备部队时，一个全面、立体的概念往往很难在基层战士的知识体系中建立。利用本系统可以给出测试各型号某武器系统的简单的故障诊断信息和操作指南，具有导航、查找和链接等交互功能，而且可显示工程图、三维模型、文本和视频等基本元素对象。系统所有功能设计都紧贴部队实际需求，借助本系统，基层战士可快速了解和掌握所需信息。整个系统分为履历管理、维护保障、维修指南、故障诊断、使用指南和设备介绍等6个功能模块，如图2所示。

图2.某武器系统通用测试系统IETM组成

参考文献：

[1]祁超,解洪成.船舰级维修队IETM的功能增值要求[J].江苏科技大学学报,2006,20(3):21-25

[2]赵建军,杨阳,张广超等.IETM在某型装备示教系统中的应用研究[J].微计算机信息,2009,25(6):256-258

[3]贺韶,马好东.船舰电子装备综合诊断中的IETM设计与应用技术研究[J].计算机测量与控制,2009,17(4):628-630

自动化测试在国际软件测试中的应用 第12篇

1.1传统软件和国际软件介绍

传统的软件一般只用于本地市场, 如国产软件一般只用于国内, 因此当前软件的测试主要关注于软件的功能是否正确、性能是否合适。随着社会的发展, 国际化趋势已经渗入到社会的各个方面, 软件行业也不例外。许多软件行业为了获取更多的利润, 本地市场已经满足不了发展的需求, 于是纷纷开拓国际市场, 如软件巨头微软, 目前超过一半的利润来之于美国之外的市场, 微软大部分产品都致力于开发海外市场。

国际化软件要想适用于海外市场, 必须要能够实现海外市场的本地化, 也必须支持不同目标市场的语言文字和数据信息的输入、输出、显示和存储等。国际化软件的国际版本最初是落后于源语言版本的发行, 国际软件项目的实现分成了软件开发、测试、国际化和本地化4个阶段。该过程是首先进行核心源语言的软件开发以及测试, 再对软件进行国际和本地化开发、测试, 该模式有严重的缺陷, 其一、国际化版本必将落后于源语言版本的发行, 这显然不利于国际化发展的需要, 其二、国际化的开发和测试在源语言版本开发、测试完成之后进行, 如果发现缺陷, 很可能需要修改源语言版本的代码, 众所周知, 在软件开发过程中, 缺陷发现越早, 为弥补缺陷花费的成本越低, 其三、该模式延长了整个软件的开发时间, 增加了开发成本。

为了改进传统模式的不足, 国际化软件的同步开发测试模式应运而生。这种开发模式源语言版本和本地化版本具有一致的核心代码, 本地化版本的生成只需要将本地化串 (翻译后的串) 导入到源语言版本中即可, 因此源语言版本和各本地化版本可以做到同时发布, 其开发和测试也可以同步进行, 这就将本地化中可能出现的缺陷提前发现, 降低了成本, 缩短了软件的开发时间。

1.2国际软件测试内容及特点

由于国际市场的重要性, 国际化测试也成为了国际软件测试中非常重要的一块。国际化测试主要包括国际化版本的基本功能测试、国际化能力测试、市场化能力测试、本地化能力测试以及本地化测试。

基本功能测试以测试软件国际版本的功能和性能为主, 通常在国际化测试的最初阶段进行, 在基本功能都正确的情况下才能进行以后的测试。该阶段的测试可细分为单元测试、集成测试、系统测试和验收测试。

国际化能力测试在于发现软件支持全球不同市场的能力, 如数字格式显示、时间格式、地址格式、日历、货币、日期格式、字体选择、数据输入以及排序等等。国际化能力测试通常较早开始, 一般在基本功能测试之后进行, 国际化测试发现的缺陷通常需要通过修改代码来解决, 因此问题较严重, 在测试的前期发现会比在测试后期发现降低很多成本。

本地化能力是指软件具有在不修改源代码的情况下能够本地化为任何语言的能力, 因此本地化能力测试对于国际化软件至关重要。现在通常采用的本地化能力测试称为Pseudo localization, 它在软件中使用虚拟的语言来模拟真实的语言, 以达到测试软件本地化能力的目的, 因此测试本地化能力通常需要生成一个虚拟版本 (通常称为Pseudo版本) , 该版本中使用的语言并非任何一个国家的语言, 图1所示即为一个典型的Pseudo版本, 其中显示为[]的串即具有本地化能力, 可翻译为任何一个国家的语言。

本地化测试较简单, 通常在国际化测试的后期, 主要是为了发现本地化翻译中的问题, 虽然该测试阶段较简单, 但是对于要本地化为很多语言的软件而言, 测试较为繁琐, 重复性的工作较多。

综合国际化测试内容可知, 国际化测试与普通软件测试的不同在于, 其一、国际化版本除了功能测试之外, 还非常注重国际化能力、本地化能力、本地化等测试, 该类测试关注的主要是界面显示、输入等问题, 其二、国际化测试需要在不同的语言和市场上做重复的测试工作, 重复的次数一般为语言个数*市场个数, 这也就意味着测试用例的个数成倍数的增长, 而且大多数都是重复性的工作, 测试成本较高, 所用时间较长, 而且在工作量大、工期较紧的情况下, 手工测试很容易引入人为的错误。

1.3自动化测试的引入

针对手工测试在国际化测试中的缺点, 自动化测试应运而生。自动化测试的引入很好的解决了上述问题, 自动化测试的优势在于可以规范测试流程, 减少人为的错误, 并且自动化测试由电脑自动执行, 效率高, 另外自动化代码开发出来之后, 可以在不同语言、不同市场上重复利用, 重复利用率很高, 这一点是自动化测试应用在国际化测试中最大的优势。

2 自动化测试在国际软件测试中的实施

2.1可行性分析

并非所有的国际化测试都适合引入自动化测试, 自动化测试也需要开发和搭建测试框架、创建测试用例, 这也就意味着成本的投入, 如果自动化的投入超过了手工测试, 则自动化的引入是不必要的, 因此自动化测试较适合软件长期使用, 版本经常更新的软件, 每次版本的更新都要进行测试, 这进一步提高了自动化测试程序的利用率。

因此软件的国际化测试是否适合引入自动化测试是需要满足一定条件的, 以下几个方面缺一不可: (1) 软件的开发过程已经基本完成, 并且该软件会长期使用, 定期会推出新的版本; (2) 软件需要应用于多个语言和市场上, 测试的重复率较高; (3) 自动化测试较易实现, 投入成本不高。

2.2自动化测试的实施

2.2.1自动化测试程序的框架结构

目前市场上所使用的自动化测试的工具以及方法都很多, 从工具上看主要有LoadRunner、QuickTestProfessional、TestDirectorforQualityCenter、Tational Tobot、WinRunner、QA Run等等, 从测试模式上看, 主要有录制回放模式、录制编辑和回放模式、编程和回放模式、基于数据驱动的编程回放模式等等。

由于很多测试工具并非免费软件, 而且各种软件的实用性具有局限性, 所以在时间、人力等条件允许的情况下, 最好能够使用编程回放模式, 自己开发测试框架模型。目前的测试框架模型总结起来, 可归纳为三层结构:

底层驱动层:该层基于控件, 用来提供底层的驱动, 主要是实现各控件的定义、识别, 提供对键盘、鼠标等的支持, 实现对异常的处理, 以及实现国际化、本地化相关的功能。该层和具体的被测软件无关。

软件代理层:该层基于软件, 实现对软件各个页面中控件的定义, 各个页面中常用函数的编写等, 主要是编制基于软件的函数以及属性以供最上层的测试用例层调用, 可以实现代码的重用, 使整个测试框架结构清晰。该层实现的规模需要分析控制, 规模太大、实现的太细, 会花费较多的时间, 而实现的太粗略, 会导致最上层的测试用例层实现起来较为复杂, 而且不利于软件代码的重用。

测试用例层:该层主要是调用“软件代理层”和“底层驱动层”的方法和属性来实现测试的功能, 所以如果下面两层的基础打的较好, 该层实现起来会非常容易, 只是简单的调用、组合。

因此自动化框架结构的搭建, 主要花费时间的是底下两层, 这两层在实现之后即可重复使用, 之后在每个新版本的测试中只需要修改补充即可, 不需要花费较多的时间, 也不需频繁的更新, 而最上层测试用例层则需经常更新、添加以及修改。

2.2.2“自动化”+“手工”结合模式的引入

自动化框架结构实现之后, 具体地如何来实现国际化测试功能呢?由于国际化测试关注的重点主要是界面, 所以最初有测试小组使用如下方法来实现, 即获取界面上被测焦点, 和标准库中的数据进行比较, 看是否一致。比如:检查界面的串是否本地化为汉语, 可以获取该串, 然后和数据库中该串正确的显示方式比较, 如果一致, 就表示该串本地化正确。这种实现方式在使用一段时间之后, 由于其明显的缺陷被测试人员舍弃, 这个缺陷是手工测试人员写测试用例时一般是分块写, 一个手工测试用例里面可能包含很多串, 所以自动化以串为测试点的方法引入之后, 自动化测试用例数量比手工测试用例数量庞大的多, 该方法可以减少手工人员的数量, 随之而来的则是自动化人员数量的增加, 自动化框架结构过于庞大, 维护成本过高。

鉴于此, “自动化”+“手工”结合模式应运而生, 该模式主要是由自动化程序拍摄出测试的焦点, 手工测试人员只需要查看截图即可, 这样既降低了自动化程序的复杂度, 又加入了手工测试人员的干预, 使测试更灵活, 测试结果也更可靠。

此模式需要在每个测试用例中加入拍图程序, 因此可以预先定义好拍图程序, 在测试用例中调用即可。拍图的实现方法有很多, 通常使用的方式是截屏, 即将整个屏拍摄下来, 这就带来了一个问题, 即测试用例的测试焦点可能只是整屏的一部分, 如果不将测试焦点标示出来, 可能会带来测试工作的重复进行, 因此需要在拍图程序中添加相应的功能, 标示出测试焦点, 如图2所示, 虽然拍摄到的是整个屏, 但是只有标记色框标示的是该测试用例的测试焦点。

2.2.3日志的引入

自动化测试能否成功的另一个关键点在于对自动化运行结果的记录、统计、分析, 以及由此结果进行的维护和扩充。故自动化测试框架结构需要引入日志模式, 该模式的作用是在测试用例的运行过程中记录该测试用例运行的状态信息, 并将其记录在一个文件中, 待手工测试人员查看分析。测试用例的状态信息一般有:测试用例名称、运行时间、优先级、运行结果 (成功?失败?) 、运行步骤、运行失败时的错误提示等等。日志文件示例如图3所示。

该日志主要记录每个测试用例运行的细节情况, 但是对于自动化管理人员而言, 掌握每次自动化运行的概况对管理整个自动化测试也有着重要的意思。

因此, 在日志引入的基础上还需要有总结报表的生成, 用来统计每次运行的概况, 如每次运行成功的百分比、运行成功以及失败测试用例分别分布在哪些部分等等信息。

2.3自动化测试的维护和扩充

自动化测试框架搭建好之后, 由于需要多次使用, 每次新版本的测试均需使用到, 因此维护和扩充也是自动化测试中一个非常重要的部分。对于新版本而言, 自动化测试既需要维护旧的测试用例 (新的版本可能会对旧的测试用例有影响) , 也需要新添加测试用例, 因此, 自动化框架会随着版本的增多越来越庞大。

维护和扩充是一个长期的过程, 其中要注意的是, 并不是所有的测试用例都适合自动化, 每次自动化执行完成之后, 有结果日志可以分析, 对于失败率很高的测试用例, 可以舍弃自动化, 用手工进行测试。

3 结束语

国际化测试中引入自动化测试目前在很多大型IT企业中应用广泛, 也是一个比较新的研究课题, 在细节上不同的公司使用的方法不同, 但是其效率高、重用性强等优点得到了大家一致的认同。测试工作的严谨性要求我们不光能看到其优点, 也必须正视其可能潜在的缺点, 这就要求在实施自动化测试的时候要本着严谨求实细心的态度, 认真地对待每一个问题。本文中所介绍的自动化测试框架结构在很多大型的软件系统中得到应用, 取得了良好的效果。

参考文献

[1]郭伟斌.自动化测试的研究与探讨[J].电脑开发与应用, 2008 (12) .