时间：2022-02-01 02:32:47
开篇：写作不仅是一种记录，更是一种创造，它让我们能够捕捉那些稍纵即逝的灵感，将它们永久地定格在纸上。下面是小编精心整理的12篇软件测试，希望这些内容能成为您创作过程中的良师益友，陪伴您不断探索和进步。
关键词：软件测试；软件开发；质量
1.组件测试
组件测试又称单元测试，其目的就是验证应用程序能够很好的工作，以及尽早的发现错误。所谓组件测试其实就是测试单个组件的过程，是一种细粒度的测试。组件测试其实就是一个缺陷测试的过程，基本上使用结构化测试即白盒测试来对组件进行测试。在软件中，组件算是最小的单元，因此，组件测试可以对多个组件来进行。
1.1组件测试的类型
在组件测试阶段，需要测试不同类型的组件（对象内的单个函数或方法、有多个属性和方法的对象类、有不同对象或是函数组成的复合组件）。组件测试的内容主要有模块接口、局部数据结构测试、路径测试、错误处理测试以及边界测试。从测试的类型可以看出，比较简单的就是对单个函数或方法的测试，但是当测试多个组件组成的复合组件时，测试组件间的接口是否能正确执行是首要关心的问题，而这个测试中的关键就是对组合组件的接口测试。
1.2接口测试
接口测试是组件测试中最常用的一种测试。测试符合组件间的接口就是接口测试。由于在符合组件之间存在很多交互行为，因此，在对复合组件中的单个组件进行访问时，是要通过接口来对它们进行调用。所以，接口测试就成为组件测试中的重点。
复杂系统中最常见的错误形式包括接口错误，接口错误主要指接口误用、计时错误、接口误解等等。一般情况在不寻常的条件下、交互双方都存在接口缺陷，而这是很难发现的，因此，接口测试是非常重要的。
组件的开发和测试都是交叉进行的，组件的设计者对组件是十分熟悉的，因此，由组件的设计者来进行组件测试是在合适不过了。
2.集成测试
所谓集成测试就是指测试时将组件集成为系统来进行。集成测试的目的就是检查在一起的组件是否工作，能否正确及时进行组件与组件间的交互。集成测试就是将与接口相关的错误找出，从而使得添加的功能模块确保没有传播不期望的副作用，并且使得由于新模块的添加引起的变更不引入需求外的行为或是增加额外的错误。集成测试过程如图1所示。
图1 集成测试过程
2.1集成系统的策略
集成顺序不同，集成测试也将不同，二者密切相关。集成系统的策略从理论上来讲，其可分为自上而下的集成和自底而上的集成。但是在实际中，大多数的集成策略都是混合型的。自上而下的集成就是指先把系统框架开发出来，然后再向其中添加组件。这种方法存在一个非常普遍的问题，即在测试下一层时，还要兼测上一层。自底而上的集成就是指集成和测试都是从组件开始。不管使用哪种策略，开发额外的代码是必须的，通过额外代码的开发来仿真其他组件，从而使得系统运行起来。
对错误的定位就是集成测试中存在的主要问题。由于组件之间有复杂的交互行为存在，因此，当发现一个错误时，很难将其出错的位置找到。
2.2集成测试的方法
集成测试通常采用增量法来进行测试，从而使得集成测试中的主要问题得以解决。使用增量法，从一个集成度最小的系统配置开始，然后测试这个系统，测试完成后，一个增量一个增量地往系统中增加组件，每次增加组件后再进行测试。这种方法其优点在于易于分离和纠正错误以及彻底测试接口。这种方法的缺点在于在测试过程中经常会出现重复测试。
2.3回归测试
回归测试就是指把测试过的再进行测试。回归测试虽然出现重复测试，但是其能够保证新增模块后不会给原系统组件间的行为产生不期望的变更。回归测试是保证软件的正确运行的必要条件，但是，对测试过的再进行重新测试明显会产生不必要的浪费。
要想在使用回归测试时减少系统资源的浪费，可以从以下几个方面进行：（1）引进自动化测试。这种方法的引入，使得测试自动地重复，从而回归测试对系统资源的浪费得以减少；（2）严格规定增加快增加顺序。先增加最常用的功能块，从而对最常用的组件进行多次测试，确保在各种情况下常用功能能够实现。
集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。
3.性能测试
性能测试就是测试系统对在非正常条件下的运行情况。它的任务是验证软件的功能和性能及其他特性是否达到了需求规格书上的要求。一般情况下包括恢复测试、安全测试、压力测试、性能测试。恢复测试是通过各种方式强制地让系统发现故障并验证其能够重新恢复的一种系统测试。安全测试是验证在系统内的保护机制是否能够实际保护系统不受非法入侵。压力测试是以一种要求反常数量、频率或容量的方式执行系统的测试方法。
4.接收测试
接收测试是对将要分给客户的系统版本的测试过程。通常是一个黑盒测试过程，将软件与计算机的其他系统元素结合在一起，在实际运行环境下，由用户通过真实的数据测试对软件在内的计算机系统，以求能发现系统需求定义中的错误和遗漏。同时也期望能发现因系统的设施不能满足用户的需求或系统的性能无法接受的错误。
4.1接收测试的方法
接收测试的最好测试方法是基于脚本的测试，先设计出多个脚本然后再从脚本中开发错测试用例。
4.2接收测试的分类
接收测试根据用户的不同可以分为α测试和β测试。无论是α测试还是β测试都是在实际的使用环境下进行的。α测试是测试为特定的用户开发的系统，且由最终用户在开发者在场的情况下进行的，开发者在旁边记录用户所遇到的错误和使用问题，α测试要持续进行直到开发者和用户双方都对最后交付的系统满意。β测试的对象是一个将要在市场上销售的软件产品，β测试是所有愿意使用该软件的用户在使用该软件是所遇到的所有问题，然后在反馈给开发者，开发者再根据反馈回来的信息决定对软件做如何处理。通常情况下β测试能暴露开发者无法预见得错误。
随着软件应用越来越广，所要求的设计也越来越复杂，所需的开发周期越来越短，而质量要求越来越高，那么软件企业目前面临着巨大的挑战。由此，软件测试变得越来越重要，软件测试可以有效地提高软件质量。重视软件测试过程和技术是软件企业快速发展的有效途径。
参考文献：
关键词：Web；软件游览；体系结构；方法
0 引言
随着Intemet的普及和电子商务应用的深入。Web应用程序得到越来越广泛的应用，B／$架构也逐渐代替C／S架构成为主流的应用模式。与传统软件相比，Web应用程序具有分布式、并发、多用户异构等特点，这些特点对软件测试提出了新的要求。Web测试是保证Web应用程序质量的有效手段，目前在Web测试的方法和技术以及相关工具等方面的研究已进行了一些尝试。软件测试的自动化技术有助于开发出更高质量的产品，并且可以节省开发时间和开支。
1 Web软件体系结构
Web应用程序采用B／S结构，它是伴随着Intemet技术的不断进步，由C／S结构改进和发展起来的新型体系结构。B／S结构利用不断成熟和普及的浏览器技术实现原来需要复杂专用软件才能实现的强大功能。是一种全新的软件系统构造技术。这种结构已成为当今应用软件开发的首选体系结构。
Web系统的基本工作过程是：在客户端，用户通过浏览器向Web服务器中的控制模块和应用程序输入查询要求，Web服务器将用户的数据请求提交给数据库服务器中的数据库管理系统DBMS；在服务器端，数据库服务器将查询的结果返回给Web服务器，再以网页的形式发回给客户端。在此过程中，对数据库的访问要通过Web服务器来执行。Web系统的基本体系结构及工作过程如图1所示。
从上面的体系结构可以看出，Web测试应该分为三个层次，客户端测试、服务器端测试和数据库测试。客户端主要测试用户浏览器的基本功能和页面现实情况；服务器端主要测试用户请求响应情况；数据库端主要测试数据一致性和输出错误。
2 Web软件测试的主要特点与难点
Web软件由于其分布式应用、具有各种运行时行为、涉及多种标准协议，可能在硬件、软件、通信、对象管理等环节出现各种缺陷。其体系结构和应用的复杂性，以及技术和规范不断地发生变化，对测试提出了新的挑战。Web软件测试的特点与难点主要体现在以下几个方面：
(1)Web软件的开发环境与其应用环境有很大的不同，在之前，很难对其实际的运行场景进行预测，如用户类型、并发用户数量、Web服务调用的装载模式和访问方式等，这些差异和应用的不确定性都增加了Web服务测试的困难。
(2)Web软件测试主要基于软件接口进行设计和实现，因此必须采用自动化测试方法，与传统的需要大量人工干预的测试方法截然不同。
(3)Web软件由于其分布特征，会出现大量用户通过不同的环境访问同一个服务的情形，因此，性能和可扩展性是Web软件测试的重要方面。
(4)Web软件及软件集成的、发现和绑定都是动态完成的，其过程的不确定性和不可见性增加了测试难度。
(5)Web软件访问接口和访问方法后增加了Web软件的安全隐患，提高了被系统攻击的机会。此外，对于所调用的分散、异构的外部Web服务的安全性的管理也非常困难。如何提高Web软件的安全性也是测试者要考虑的重要问题。
(6)Web软件的应用通常涉及到软件提供者、者和使用者三种角色，都需要参与到测试的不同阶段，其分布式合作的特征使得测试的组织、缺陷管理、结果评估等活动都更加困难。
目前。针对Web软件的测试方法和技术的研究还处于初始阶段，代表性的研究主要有基于形式化方法对协议及规格说明的验证(如WSFL验证技术、SOAP验证)和Web服务的集成测试。
3 传统软件测试与Web软件测试
传统软件测试经常是静态、离线的测试，尽管这些传统的测试技术也可以应用到Web服务的测试当中，然而相当有意义的一部分Web软件测试都必须是动态的和在运行时间内的即时测试。Web软件这种动态和即时测试对传统的测试理论提出了新的挑战和要求。表1比较了传统软件和Web软件测试的差别。
4 Web软件测试的内容和方法
Web测试主要目标是确保提交高质量的Web软件。对于错综复杂的Web软件，从什么地方开始测试。哪些方面是测试的核心，有限的测试资源如何分配，这些都是Web软件测试需要重点考虑的问题。下面介绍Web软件测试的主要内容和方法。
4.1 功能测试
链接测试 链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面：①测试所有链接是否按指示的那样确实链接到了该链接的页面。②测试所链接的页面是否存在。③测试Web应用系统上有无孤立的页面。所谓孤立页面是指没有链接指向的页面，只有知道正确的URL地址才能访问。
表单测试 单元当用户给Web应用系统管理员提交信息时，就需要使用表单操作。例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。
Cookies潮试Cookies通常用来存储用户信息和用户在某应用系统的操作。当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登录等信息。如果Web应用系统使用了Cookies。就必须检查Cookies是否能正常工作而且对存储的信息已经加密。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。
设计语言测试 Web设计语言版本的差异，例如使用不同版本的HTML等，可以引起客户端或服务器端严重的问题。在分布式开发环境中，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaSeript、ActiveX、VBScript或Perl等也要进行验证。
数据库测试 数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的。针对这两种情况，可分别进行测试。
4.2 性能测试
网站的性能测试对于网站的运行而言异常重要，但是目前对于网站的性能测试做得不够，我们在进行系统设计时也没有一个很好的基准可以参考，因而建立一整套网站的性能测试方案将是至关重要的。
连接速度测试 用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。连接速度太慢。还可能引起数据丢失，使用户得不到真实的页面。
负载测试 负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线；如果超过了这个数量，会出现什么现象。
压力测试 压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。
4.3接口测试
服务器接口 第一个需要测试的接口是浏览器与服务器的接口。测试方式一般是，测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
外部接口有些Web系统有外部接口，例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生，测试的时候，要使用Web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。
错误处理 最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。为此，可以尝试在处理过程中中断事务，看看会发生什么情况，订单是否完成，尝试中断用户到服务器的网络连接，系统能否正确处理这些错误。
4.4 兼容性测试
平台测试市场上有很多不同类型的操作系统，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下运行可能会失败。因此，在Web系统之前，需要在各种操作系统下对其进行兼容性测试。
浏览器测试 浏览器是Web客户端最核心的构件。来自不同厂商的浏览器对JavadavaScript、ActiveX或不同的HTlML规格有不同的支持，例如，ActiveX是Microsoft的产品，是为Intemet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。测试浏览器兼容性的一个方法是创建一个兼容性矩阵，在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
4.5 安全测试
景登 现在的Web应用系统基本采用先注册，后登录的方式，因此，必须测试有效和无效的用户名和密码。要注意到系统是否对大小写敏感，可以试行登录多少次，是否可以不登录而直接浏览某个页面等。
日志文件为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。
安全漏洞 服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。
关键词：软件测试；系统测试；线索；压力测试；性能测试
中图分类号：TP39文献标识码：A文章编号：1007-9599 (2012) 05-0000-02
一、引言
软件测试作为软件质量保证的关键技术之一，其目的就是能够有效地发现软件中的错误或缺陷。系统测试是对完整集成后的系统进行测试的阶段，用来评价系统对具体需求规格说明的符合性，系统测试是在单元、组件和集成测试阶段之后进行的。主要针对软件系统和其他系统元素（及硬件、数据库和人机交互信息）组合构成完整的计算机应用系统中所有的元素配合是否合适以及整个系统的功能、性能、执行强度、安全性等是否达到规定标准而进行的测试。
二、系统测试概述
（一）系统测试概念
所谓系统测试是将通过集成测试的软件系统，作为计算机系统的一个重要组成部分，与计算机硬件、外设、某些支撑软件的系统等其他系统元素组合在一起所进行的测试，目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或矛盾的地方。
（二）系统测试前的准备工作
系统测试前的准备工作主要包括：对系统各种功能的描述；系统要求的数据处理及传输的速率；对系统性能的要求；对备份及修复的要求；对兼容性的描述；对配置的描述；对安全方面的要求等。
（三）系统测试的测试数据
系统测试所用的数据必须尽可能地像真实数据一样精确和有代表性。可以使用真实数据或者使用真实数据的一个复制，复制数据的质量、精度和数据量必须尽可能地代表真实的数据。
（四）系统测试与确认测试区别
确认测试始于集成测试的结束，那时已测试完单个构件，软件已组装成完整的软件包，且接口错误已被发现和改正。在确认测试时，传统软件与面向对象软件的差别已经消失，测试便集中于用户可见的动作和用户可识别的系统输出。
1.确认测试准则
软件确认是通过一系列表明已符合软件需求的测试而获得的。测试计划和规程都是用于确保满足所有的功能需求，具有所有的行为特征，达到所有的性能需求，文档是正确的、可用的。执行每个确认测试用例之后，存在下面两种可能条件之一：（1）功能或性能特征符合需求规约，因而被接受；（2）发现了与规约的偏差，创建缺陷列表。
2.配置评审
评审的目的是保证所有的软件配置元素已正确开发、编目，且具有支持软件生命周期的支持阶段的必要细节。
3.α测试与β测试
α测试是由最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在典型用户的后面观看，并记录错误和使用问题。α测试在受控的环境下进行。
β测试是最终用户场所执行。开发者通常不在场，因此，β测试是在不为开发者控制的环境下软件的现场应用。最终用户记录测试过程中遇见的所有问题(现实存在或想象的)，并将其定期地报告给开发者。接到β测试的问题报告之后，软件工程师进行修改，然后准备向最终用户软件产品。
二、系统级功能测试技术
（一）线索的概念
线索（thread）的概念很难定义。事实上，一些已经公开的定义都是矛盾、容易产生误导或错误的。可以把线索看作是一种不需要形式化定义的原始概念。以下是对线索的多种看法：一般使用的场景；系统级测试用例；激励/响应对；由系统级输入序列产生的行为；端口输入和输出事件的交替序列；系统状态机描述中的转换序列；对象消息和方法执行的交替序列；机器指令序列；源指令序列；MM-路径序列；原子系统功能序列。
（二）需求规约的基本构造元素
根据一组基本需求规约构造元素，即数据、行动、设备、事件和线索，来讨论系统测试。每个系统都可以使用这五种元素表示。
1.数据
主要包括：变量、数据结构、字段、记录、数据存储和文件、实体关系模型高层数据描述。
2.行动
以行动为中心建模仍然是需求规约的一种常见形式，这是因为有命令式程序设计语言以行动为中心性质的历史原因。行动有输入和输出，这些输入和输出既可以是数据，也可以是端口事件。行动还可以分解为低层活动，例如数据流图。
3.设备
每个系统都有端口设备，这些端口设备是系统级输入和输出（端口事件）的源和目的地。在技术上，端口是I/O设备接入系统的点。
4.事件
事件既有数据方面的一些特征，又有行动方面的一些特征。事件是发生在端口设备上的系统级输入（或输出）。可以是离散的，也可以是连续的（例如温度、高度或压力）。端口输入事件是物理到逻辑的转换，同样，端口输出事件是逻辑到物理的转换。
5.线索
因为要测试线索，因此测试人员通常不能在数据、事件和行动之间的交互中找出线索。线索本身出现在需求规约中的惟一地方，是使用快速原型法并结合场景记录器。
（三）线索测试的结构策略及功能策略
结构策略实际上是基于有限状态机的行为建模中的结构来寻找测试线索的。首先自底向上组织各层次的状态机，然后寻找线索覆盖每个状态机的节点和边，同时还要找出节点与边覆盖指标。
线索测试的功能策略
1.基于事件的线索测试
（1）端口输入事件覆盖指标
五个覆盖指标为覆盖端口输入事件提供了一组线索：
(1)PI1：每个端口输入事件发生。
(2)PI2：端口输入事件的常见序列发生。
(3)PI3：每个端口输入事件在所有“相关”数据语境中发生。
(4)PI4：对于给定语境，所有“不合适”的输入事件发生。
(5)Pl5：对于给定语境，所有可能的输入事件发生。
（2）端口输出事件覆盖指标
根据端口输出事件定义两种覆盖指标：
(1)PO1：每个端口输出事件发生。
(2)PO2：每个端口输出事件在每种原因下发生
2.基于端口的线索测试
基于端口的测试是基于事件测试的有用补充。
对于每个端口都要询问端口上会出现什么事件。然后根据每个端口的事件列表寻找使用输入端口和输出端口的线索。有些需求规约技术要求提供这种端口的事件列表。
设备和事件之间的多对多测试应该在两个方向上进行：基于事件的测试覆盖从事件到端口的一对多关系，反之，基于端口的测试覆盖从端口到事件的一对多关系。SATM系统不能使用这种测试，因为SATM不发生在多个端口上。
三、系统测试的主要内容
系统测试一般要完成以下几种测试：功能测试、性能测试、可靠性、稳定性测试、兼容性测试、恢复性测试、安全性测试、强度测试、面向用户支持方面的测试、其他限制条件的测试。下面就对常用的系统测试做一个介绍：
（一）压力测试
压力测试是指模拟巨大的工作负荷以查看或评估应用程序在峰值或超越最大负载使用情况下如何执行操作。压力测试有如下特点：可以测试系统的稳定性；一般需要对用户的使用情况进行模拟。压力测试的方法包括：并发测试法、增加量级法、重复测试法。
（二）性能测试
性能测试一般需进行：对软件计算的精度有要求时，设计测试用例；对软件有时间要求时，设计测试用例；测试为完成功能所处理的数据量；测试程序运行所占用的空间；测试对系统的负载潜力；测试配置项各部分的协调性；测试软件性能和硬件性能的集成；测试系统对并发事务和并发用户访问的处理能力。
（三）恢复性测试
多数基于计算机的系统必须从错误中恢复并在一定的时间内重新运行。恢复性测试是通过各种方式强制地让系统发生故障并验证其能适当恢复的一种系统测试。若恢复是自动的(由系统自身完成)，则对重新初始化、检查点机制、数据恢复和重新启动都要进行正确性评估。若恢复需要人工干预，则估算平均恢复时间(mean-time-to-repair，MTTR)以确定其是否在可接受的范围之内。
（四）安全性测试
安全性测试验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。系统的安全必须经受住正面的攻击，但是也必须能够经受住侧面和背后的攻击。在安全性测试过程中，测试者扮演试图攻击系统的角色。测试者可以试图通过外部手段获取密码；可以通过瓦解任何防守的定制软件来攻击系统；可以“制服”系统使其无法对别人提供服务；可以有目的地引发系统错误以期在其恢复过程中入侵系统；可以通过浏览非保密数据，从中找到进入系统的钥匙等等。
四、结语
系统测试有助于在其部署中客户发现缺陷之前，尽可能多滴发现缺陷，在系统测试期间要验证完整产品的行为，包括设计多个模块、程序和功能的测试，测试完整产品的行为是很关键的，因为很多人错误地认为经过单独测试的组件放到一起后仍能正常运行。
参考文献：
[1]薛冲冲,陈坚.软件测试研究[J].计算机系统应用,2011,2
[2]陶幸辉,宋志刚.软件系统测试类型及测试用例设计[J].科技经济市场,2011,6
[3]朱家云.浅析软件测试[J].信息系统工程,2011,4
[4王丽达.论软件系统的测试[J].经济研究导刊,2011,14
随着信息化军事技术的不断发展，装备仿真训练软件也获得了迅速的发展，其规模越来越庞大、实现的功能越来越多、结构越来越复杂，装备仿真训练软件的性能和可靠性也成为至关重要问题的。因此，软件测试成为装备仿真训练软件开发过程中一个必要的环节。依据一个科学的测试模型，使用先进的软件测试技术对装备仿真训练软件进行充分的测试，可以及时发现软件程序中的错误，有效降低软件错误出现的概率，验证软件功能的可行性，提高软件的可靠性和安全性。
1 软件测试模型
软件测试是装备仿真训练软件开发过程中一个不可缺少的重要步骤，而且随着装备仿真训练软件规模的增大、复杂度的增加，软件测试也变得越来越重要。装备仿真训练软件软件测试过程与开发过程一样，都能决定软件的质量，而且测试过程的质量将直接影响测试结果的准确性和有效性。
在软件开发几十年的实践过程中，人们总结了很多的开发模型，这些模型对于软件开发过程具有很好的指导作用，由于测试与开发是紧密结合在一起的，所以软件测试也需要有测试模型去指导实践。软件测试模型是将测试过程活动进行抽象的概念模型，用于定义测试活动的流程和方法，是确保软件工程质量的重要手段。测试专家通过实践总结出了很多很好的测试模型。这些模型将测试活动进行了抽象，明确了测试与开发之间的关系，更好的分析软件测试在整个软件研发中的参与度和工作过程，进而不断完善软件质量保证流程，提高软件产品的质量，并成为了测试管理的重要参考依据。目前，主要的测试模型主要有以下4种：
1.1 V模型
V模型是将传统测试模型瀑布模型改进后的一种测试模型，如图1所示，从左到右，分别描述了软件的基本开发过程和对应的测试行为，清楚地体现出每个测试阶段和开发过程各阶段的对应关系。但是在V模型当中，测试过程放在了编码的下一个阶段，这就容易使人误解为测试是软件开发的最后一个阶段，而需求分析的检验工作也是在验收测试才能进行。
1.2 W模型
W模型由两个V模型组成，分别代表测试与开发过程，非常明确的标注了生产周期中开发与测试之间的对应关系，如图2所示。但是在W模型中测试和开发也保持着一种线性的前后关系，上一阶段工作完全结束，才能正式开始下一阶段的工作，这样就无法支持迭代、自发性以及变更性调整等情况。
1.3 H模型
H模型形成了一个完整独立的测试过程，并且将测试准备活动和测试执行活动清晰的区别出来，如图3所示。图中仅仅演示了在整个生命周期中某个层次上的一次测试“微循环”，图中的“其他流程”可以是任意开发流程。H模型的特点是软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。当某个测试点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
2 装备仿真软件测试的特点及关键问题
2.1 装备仿真软件测试的特点
装备仿真训练软件是一个由系统、分系统/子系统、模块组成的复杂系统，并随着系统和操作功能的增多，复杂程度也在增加，系统的好坏归根结底是由各个分系统和各个模块的好坏决定的，对各个分系统和各个模块的测试是一个非常重要的环节。装备仿真训练软件测试具有以下6个特点：
2.1.1 装备仿真训练软件测试主要分为三个阶段
从软件生命周期全过程来看，软件测试可分为单元测试、功能测试、集成测试、性能测试、系统测试、配置测试、回归测试等阶段。根据装备仿真训练软件的结构、规模、类型和安全性关键等级等方面的特点，确定装备仿真训练软件测试主要分为单元测试、集成测试和系统测试三个阶段。
2.1.2 单元测试是装备仿真训练软件的测试重点
装备仿真训练软件测试是一项针对性很强的工作，即使对同一类型的功能，可能由于不同型号任务的要求，功能实现也会有所差异，因此要求重点进行单元测试。单元测试是根据详细设计和源程序，了解每个最小模块的输入、输出条件和逻辑结构是否正确合理。单元测试通常应对模块内所有控制路径设计测试用例，以便发现错误。
2.1.3 装备仿真训练软件程序内部结构复杂，路径组合数目庞大
程序的三种基本结构分别是：顺序结构、分支结构和循环结构，装备仿真训练软件最小组成模块的内部程序都可看作是这三种结构按不同方式组合的产物，这其中包含大量多重选择和循环嵌套的程序，而且模块与模块之间存在着大量的交互，所以程序内部包含的不同路径数目可能是天文数字，尤其对大规模复杂的装备仿真训练软件，穷举所有的路径是不可能的，需要根据实际情况去选择适合的覆盖测试方法。
2.1.4 装备仿真训练软件黑盒测试用例数量庞大
装备仿真训练软件中包含了不同专业的多个分系统，每个分系统又由多个子系统和模块组成，其中包含的参数数量庞大，参数与参数之间的进行组合之后的数量将更加庞大，而软件运行出现的故障时，更多的情况是由于多个参数的相互作用的原因，所以，要想充分考虑到参数与参数之间的关系，需要的测试用例数量是无穷尽的。
2.1.5 装备仿真训练软件测试一般需要特定的测试环境支持
装备仿真训练软件测试可以采用静态测试方法和动态测试方法。其中，静态测试以人工检查为主，不需要特定的测试环境;而动态测试则需要建立驱动软件模块执行的测试环境，支持软件模块的参数输入和输出结果的可视化。
2.1.6 装备仿真训练软件测试一般采用白盒测试与黑盒测试相结合的方法
一般采用白盒测试方法来测试装备仿真训练软件程序内部的逻辑结构;装备仿真软件的功能测试部分则需要采用黑盒测试方法。
2.2 装备仿真软件测试的关键问题
软件测试的目标是发现软件中可能存在的设计缺陷和错误。测试时验证得越全面，软件中可能存在的缺陷就会越少，而每一个项目、每一个软件的测试都会有不同的特点和测试关键问题，测试工作要根据软件的特点和关键问题，设计适合该软件的测试。装备仿真训练软件测试的关键问题主要有以下4点：
2.2.1 测试工作必须由非开发人员来完成
由于许多开发单位对软件测试的认识水平不够，自己设计、自己编程、自己测试、自己维护的现象还比较普遍，这样的结果就是导致测试结果不理想，没有达到测试的要求。所以，为了保证测试质量，装备仿真训练软件的测试工作必须由非开发人员来进行，保证的效果。
2.2.2 在白盒测试中，采用基本路径测试方法解决路径覆盖率问题
在装备仿真训练软件结构中，路径组合是一个庞大的数字，所以要在测试中覆盖所有路径是不可能的，需要把覆盖的路径压缩到一定范围内。如：程序的循环部分可以只循环一次。因此，在路径覆盖测试上，我们选择基本路径测试法。
2.2.3 在黑盒测试中，采用组合覆盖测试方法解决测试用例无穷尽问题
由于装备仿真训练软件中参数与参数的组合数量庞大，无法设计无穷尽的测试用例满足覆盖率问题，为此，采用组合覆盖测试方法，不仅可以充分考虑到软件中参数与参数之间的相互作用，更重要的是能以最少的测试用例实现最大程度的覆盖，具有较好的测试效果。
2.2.4 要有必要的测试文档
没有文档的项目是一个不成功的项目，同样，没有文档的测试也不会是一个成功的测试。测试工作的计划、设计、实现和问题报告都要以文档的形式记录下来留存，方便同项目组人员进行阅读和修改，更重要的是对于后续同类项目是资源的积累过程和设计的改进依据。
3 装备仿真软件测试模型
测试过程模型定义了测试的流程和方法，为测试工作提供了指导。但是传统的测试模型各有长短，不可能适合所有的测试软件，软件测试模型因测试软件的不同而不同，所以，本文通过对传统的测试过程模型进行的分析和探讨，同时研究分析了装备仿真训练软件的实际情况，进而得到了适合装备仿真软件的测试模型，然后从该模型出发，完善软件测试工作流程。装备仿真训练软件测试模型是一个包含了软件文档审查、代码静态分析和审查、单元测试、子系统集成测试、系统测试和验收测试的综合测试模型，如图4所示。
3.1 测试准备
测试准备阶段是在测试实施之前，构造执行测试所需的要素，这些要素通常包括软件开发文档、软件开发程序、实际执行测试所需的软件、准备测试环境和测试工具;同时还要为测试过程准备适当的测试用例。
3.2 单元测试
装备仿真训练软件单元测试部分包含静态测试和动态测试两个部分。其中静态测试的对象是装备仿真训练软件单元模块的文档和程序代码，主要通过文档审查、代码审查、代码静态分析等方法来确保软件需求和设计文档的正确性、代码的规范性、设计或实现的正确性。而软件结构和功能方面的缺陷则需要采用动态测试的方法来完成。
装备仿真训练软件单元模块动态测试采用黑盒测试和白盒测试相结合的方法，从模块级检查软件的功能、性能、接口和其他约束条件是否满足需求。白盒测试技术主要测试每个单元内部逻辑结构的覆盖率，黑盒测试技术测试模块单元功能满足需求情况。
3.3 集成测试
集成测试主要检验装备仿真训练软件中经过单元测试的模块和子系统各部分工作是否实现了相应技术指标、达到了相应的要求。在装备仿真训练软件集成测试部分，既可以弥补单元测试中没有测试到的Bug，又可以测试单元测试中没有办法测试的功能，如装备仿真训练软件中前后台集成之后的关联功能。所以集成测试就是测试各个部件之间的配合情况，为系统测试提供基本保证。
装备仿真训练软件的集成测试必须在所有模块、子系统能够正常运转的情况下才能进行，一般采用的方法是数据驱动方法中的自底向上集成测试。具体的步骤是先测试组成子系统的模块群，由于最底层的单元模块都已经经过了单元测试，所以各个模块可以向上集成为各个子系统;然后在此基础上就可以测试各个子系统能否正常工作，以及进行各个子系统之间的测试工作。
3.4 系统测试
装备仿真训练软件的系统测试是在集成测试的基础上进行的，不仅是单纯的测试软件部分，而是将硬件、网络和外设等其他要素结合进来进行综合性测试。系统测试主要依据系统总体技术方案和需求说明书进行测试，目的是发现系统与用户需求不符或矛盾的地方。
系统测试的测试类型一般包括功能测试、性能测试、负载测试、强度测试、容量测试、安全性测试、用户界面测试、有效性测试、配置测试、故障恢复测试、安装测试和回归测试。而在装备仿真训练软件的系统测试中，功能测试、性能测试、负载测试、安全性测试、有效性测试、配置测试、故障恢复测试是必须进行的，其他项目可以依据具体项目情况选择性的进行。
3.5 验收测试
在完成装备仿真训练软件的系统测试之后，进行验收测试。只有通过了验收测试，才标志着项目的结束，软件产品的完成。一般来说，验收测试以用户为主，主要验证软件的功能、性能以及其他特性是否与用户要求相一致。
4 结束语
软件测试的目的是通过测试来发现缺陷，找出缺陷的分布特征和出现的规律，以便在新的开发项目中改进设计结构，避免缺陷的出现，同时也能够通过设计有针对性的检测方法，改善软件测试的有效性。随着装备仿真训练软件质量要求的提高，软件测试在软件开发中的地位越来越重要。装备仿真训练软件测试模型是从传统的软件测试模型中提取出来的，适合装备仿真训练软件的测试模型，不仅可以提高测试在软件生命周期中的作用，还可以完善软件部分的工作流程。
作者：钟尚斌 来源：电子技术与软件工程 2016年7期
【关键词】软件测试 技术 管理
随着经济社会的不断进步和信息技术产业的持续发展，我国的软件业逐步成为了信息技术产业的灵魂与核心。然而与同属于亚洲的印度相比，我国在全球软件业的整体地位还远远落后，印度目前位列全世界的前五个软件方面供应大国之一，在计算机的软件出口方面地位仅在美国之后、位列世界第二。在促使印度的软件业得以快速成长和发展的原因当中，注重软件的质量是印度软件业能够攻取成功的一个关键性因素，印度的软件企业在世界上所获得的质量认证也是全球最多的。所以，提升软件的质量能够大大地推动我国的软件业的快速发展。而软件的测试是把好软件的质量关口的一个重要的环节，属于软件的开发周期当中占据较大比重的一项内容。然而在开发时间延续中，对软件的缺陷修复的代价会十倍速地增长。所以，加强软件的测试工作研究，对于提升软件产品项目的质量，推动我国软件行业和企业持续健康发展具有十分重要的意义和作用。本文简要介绍了软件测试的目的和分类，深入阐述了促进软件测试技术自动化的措施，研究提出了加强软件测试管理的对策和建议，希望对于推进软件测试的研究和实践工作能够起到一定的帮助和借鉴作用。
1 软件测试概述
软件测试指的是软件产品在投放市场前，对于软件产品所进行的需求的分析，设计的规格和编码等内容的复审，是确保软件产品质量的关键性步骤。
1.1 软件测试的具体目的
软件测试的具体目的决定着如何来组织进行测试工作。通常情况下软件测试工作的目的主要有：一是为发现程序的错误从而进行测试，二是测试用以证明软件的程序存在错误，并非证明该程序不存在错误；三是好测试其功能在于可以发现以前没有发现的一些错误等等。因此，必须关注测试的具体目的，进行测试用例的选择时要遵循经济性原则。
1.2 软件测试分类
软件测试通常可以分为黑盒式测试与白盒式测试两种类型。黑盒式测试就是将软件系统当作黑盒子而不去考虑相关程序内在的逻辑，按照需求规格的说明书要求对程序功能进行检查，看能否达到功能说明的要求。白盒式测试就是允许实施测试的人员根据程序内部的逻辑结构和相关信息进行测试用例的设计与选择，测试程序逻辑的路径。按照前后的过程分类，测试步骤可分成：单元测试，组装（集成）测试，确认测试及系统测试等。
2 促进软件测试技术自动化的措施
2.1 软件传统测试方法的主要问题
一是重复性较强。在功能增加及缺陷修复时均可能修改程序的代码，对改变过的代码进行测试就要反复地执行测试用例，用手工进行重复操作会增加出错率；二是测试的周期过长，手工重复测试将会使软件的测试周期延长；三是测试内容不够全面，修改代码之后，手工进行测试会忽略对关联内容的相应测试；四是不能测试不可视的组件，服务器端重要的程序代码均处于逻辑层，而采取手工进行测试的方法无法判断逻辑层相应内容。
2.2 软件测试自动化技术措施
一是生成测试个案，采用相应的编程语言编制短小程序用以形成测试的输入，以使自动化的测试和结果的核对程序更易于控制与操作。二是对测试进行写控制，对单元的测试及集成的测试会采取单机运行的方式，然而对系统的测试及回归式测试，则可会用到多台设备在网络环境下运行，以节省时间。 三是对测试的结果和标准化输出进行对比，输出的数据量情况和数据的格式对于对比速度有着直接的影响，应当编制特殊软件将测试的结果和标准化输出进行对比。四是利用对比软件，分类、分析记录及通报不符合的测试工作结果。五是产生测试总体统计报表，以增强过程管理工作的质量，节省数据统计时间。
3 加强软件测试管理的对策和建议
3.1 强化软件测试的过程管理
测试需求阶段中，就明确软件测试的对象与范围，测试负责与项目组成员应充分沟通，对各种资料进行收集整理，对各阶段测试工作需求进行分析，把测试内容细分成测试的需求，并保证其测试的可行性。测试计划阶段中，主要的任务就是按照测试需求来制定测试的计划，计划内容应包括：测试的环境、进度、用例及风险的分析等等。测试执行的阶段中，应完成测试的实施与过程的监控。在缺陷跟踪的阶段中，主要是及时报告软件的缺陷，跟踪修改的进展情况。
3.2 强化对软件测试突出问题的管理
一是防范思维定势的问题。克服测试人员由于太过熟悉测试的软件，从而建立起惯性的思维，造成测试的次数越是多，其发现缺陷机会反而越少的情况；防范方法是：测试人员不断编制测试新程序及测试的用例，从而发现更多缺陷；还可用新人进行软件的测试。二是防范定位效应的问题。测试人员的定位效应就是对于已测试功能不能进行认真的测试，由于疏于防范，可能会使缺陷一起存在；解决此问题方法为完整地实施测试用例，或者组织测试的人员进行交叉式的测试。
3.3 强化测试团队的管理
严格员工考核，测试负责人定期组织项目组成员谈话，定期评定做过什么和怎样去做，做好测试人员的绩效考核。加大培训力度，系统学习相关领域的基础和业务知识，强化日常培训，深入学习特定的项目及技术，全面提升测试团队的整体素质和能力。针对测试人员流动带来的影响，建立相应的健全培训工作机制，促进新任员工可以尽快地适应测试工作。
4 结语
综上所述，软件测试工作是软件在投放市场使用前，对于软件产品编码的实现，设计的规格及需求的分析等内容所进行的最后一次审查，是软件项目开发的一个重要的环节，对于软件质量发挥着基础保障的作用。因此，必须高度重视和加强软件测试工作，不断总结技术经验，持续完善管理措施和办法，以提升软件产品的质量、推动软件研发企业持续健康发展。
参考文献
[1]杨亚南，孙忠林，李艳.软件自动化测试浅谈[J].科技信息，2007（24）.
[2]肖新凤.Web应用程序性能测试技术的研究及应用[J].科技信息，2010（27）.
[3]张军威.浅谈如何以软件测试推动军工软件工程化[J].硅谷，2011（14）.
摘要：《软件测试技术》是一门实践性很强的课程，需要在实践中理解和掌握测试思想与方法。采用任务驱动的理论和实践教学，提出加强实验教学方法和途径，强化学生的测试能力。
关键词：软件测试；任务驱动；实践教学
0 引言
随着中国软件行业的不断发展。软件产品的质量关系到企业生存的重大问题。软件测试是软件质量的保障，企业对软件测试投入逐年加大。但是国内软件业对软件测试的重要作用认识较晚，软件测试的人才培养模式还不完善，企业找不到合适的软件测试人员。由于传统教学重理论轻实践。为了适应市场需求，需要调整软件测试传统教学方式。
《软件测试技术》要求有一定实践动手的能力，能把所学的理论和实际应用联系起来，才能真正理解测试思想和方法。在实践教学方法上，采用任务驱动的方式，突出学生实际动手能力的培养。
1 任务驱动教学
任务驱动教学法是特别适合知识性与技能性相结合的学科的课堂教学，在教学过程中，以完成一个个具体的任务为线索，把教学内容蕴涵在每个任务之中，学生运用已有知识完成任务，在完成任务的过程中，发现问题，解决问题，主动、轻松愉快地掌握新知识和新技能。
由于软件测试伴随软件的整个生命周期，《软件测试技术》课程的理论教学和实验教学，必须贯穿于软件开发的全过程。由于软件测试过程与软件设计周期有相互对应的关系，软件测试过程中的单元测试、集成测试、系统测试、验收测试分别对应软件设计中的详细设计、概要设计、系统设计和需求分析。因此，软件测试实践教学需要在不同阶段安排不同的实验内容。要求学生扮演不同角色参与一个系统的完整测试过程。
2 实践教学的前提
《软件测试技术》课程需要在《软件工程》和《Java程序设计》之后开设，学生利用前期所学知识完成《基于Web的图书管理系统》和《简易计算器》设计与实现。要求学生按照W模型来设计与开发。
3 不同测试阶段的实践教学
3.1测试需求分析的实践教学
需求规格说明中说明的需求充分描述该系统所应具有的外部行为。测试需求是为了验证需求的正确性、完整性、一致性等应具有的特性。教师把项目分给三个小组，每组召集相关人员（包含图书管理人员）评审需求。全面了解需求情况。学生通过制作需求评审检查表和测试用例设计可以发现需求的错误、二义性、不可测试性、遗漏等方面的问题。
学生应从不同于开发的角度进行分析，借助Ratio—nal完成数据流图、实体关系图和类图、状态转换图等完成捕述完整性检查，需求项之间的不一致检查等方面的功能，也可获得软件质量特性。对于任务是《基于Web的图书管理系统》需求说明书的验证和确认活动中。
3.2单元测试的实践教学
要求学生掌握多种测试技术和测试用例的设计。是软件开发过程中进行的最基本的测试。单元测试主要按照程序内部的结构测试程序。检验程序中的每条通路是否都能按预定要求正确工作。单元测试主要考虑各个模块接口的输入和输出，模块内部的数据结构，模块的边界条件，模块的基本路径和模块的出错处理。单元测试工具为Junit，在《基于Web的图书管理系统》登录功能模块来实现程序异常情况处理、判定一条件覆盖和条件组合覆盖：在查询模块采用边界值分析方法和等价类分析设计测试用例。
3.3类测试和回归测试
要求学生理解面向对象的封装、继承和多态对测试的影响。在测试过程中，当发现一些缺陷需要修正时，会构造一个新的软件包或补丁，然后进行测试。这时测试不仅要验证被修复的软件缺陷是否真正被解决。而且要保证以前所有运行正常的功能依旧保持正常。对应的任务是《简易计算器》。
3.4集成测试
集成测试是单元测试的逻辑扩展。主要考虑的问题是单元模块的组合能否正常工作：以及与其他组的模块能否集成起来工作：全局数据结构是否有问题等。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。要求学生采用自底向上的集成方法。根据《图书管理系统的概要说明书》编写测试计划和设计测试用例，执行测试过程。并要求学生能描述缺陷和跟踪缺陷。在报告软件缺陷时不做任何评价。
3.5性能测试
性能测试主要是从系统的响应时间、吞吐量、系统资源利用率、并发用户数、HTFP事务处理数/秒、会话数/秒和连接建立时间等方面衡量系统的性能。实验对应于《基于Web的图书管理系统》。要求采用逐步加压策略。循环次数：暂定1次，视运行时间长短而定。虚拟用户数：初始为50个，视测试结果和方案中的公式计算值确定是否需要继续加压。压力机数量：初始为5台，视测试结果而定。中间件服务器数量：初始1台，视测试结果而定。要求学生能分析实验结果，对系统调优。
【关键词】测试模型 川模型 软件测试 测试体系 川模型架构 测试组织简图 川模型价值
随着科技的不断进步，计算机应用已经完全深入到我们整个社会的体系中，人们现在已经无法适应没有软件的世界，您在读这篇文章的时候，您的电脑正在工作、手机正在运行。甚至路上的汽车、信号灯都被软件全副武装。人们对软件的依赖越来越大，虽然质量可靠的软件给我们的工作和生活带来了前所未有的便利，但是质量不好的软件也让我们付出过惨痛的代价，这让我们充分认识到软件质量正在牵动着社会的命脉。
为了提高软件质量，软件开发人员进行过大量的研究和实践。从最初的技术革新，如编译、调试工具等地研究到各种计算机辅助软件环境，再到软件开发模型的研究。但是这种以技术和方法为重心的研究没有真正达到保证软件质量的目的（但是确实对软件质量的提高做出了贡献）。所以，人们开始认识到只有对软件开发过程的质量加以控制，才有可能大幅度的提高软件质量。因此，软件质量保证也从最初的以技术和方法为重心的模式，转移到以过程管理为重心的实践。
软件质量保证的本质是为了确保软件开发过程和结果符合预期要求而建立的一系列活动及其结果评价，其最终目的是缺陷预防，达到用户的实际需求，避免安全风险。软件测试活动是保证软件质量的有力武器，从最初的调试、验证，到现在形成的独立测试体系，无一不体现质量保证的重要性和测试工作的必要性。
本文讨论的目的：在现今科技发展的大潮下，为了提高软件质量及工作效率，提出软件测试的川模型。希望川模型找出一款适合中国国情的软件测试思路和测试模型。
1 软件开发、测试的现状分析
目前主流的软件开发模型有：螺旋模型、增量模型、渐进模型、快速软件开发（RAD）以及Rational统一过程（RUP）等，这些模型对于软件开发过程具有很好的指导作用，但是这些模型并没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型不能更好地指导测试实践。因此，软件测试模型应运而生，它能够系统的有计划的指导测试与研发的一系列活动，对软件质量的提高有着重要的作用。目前常见的软件测试模型有V模型、W模型、H模型、X模型、前置测试模型等。
这些测试模型都在一定程度上完善和发展了软件的测试体系，但是它们仍然存在着或多或少的问题，还没有充分把测试对质量保证的能力发挥出来。下面分析一下几款主流测试模型的优劣情况。
1.1 V模型的优劣分析
V模型强调软件开发的协作和速度，反映测试活动和分析设计关系，将软件实现和验证有机结合起来；强调了在整个软件项目开发中需要经历的若干测试级别，并与开发级别对应。但是，没有体现“尽早地、不断地进行软件测试”的原则；把测试作为编码之后的最后一个活动，项目前期产生的错误直到后期才能测试发现；没有明确指出对需求、设计的测试。
1.2 W模型的优劣分析
W模型强调了测试计划等工作的先行和对系统需求和系统设计的测试；在整个软件开发周期中，测试与开发并行进行，有利于尽早发现问题；提出了测试的对象包括程序、需求、设计等内容；及时了解项目的测试风险，及早制定应对方案，加快项目进度。但是，它没有对测试规程进行说明，同时软件开发和测试保持着线性的前后关系，无法支持迭代、自发性以及需求变更调整等经常面临的问题。
1.3 H模型的优劣分析
在H模型中，软件测试活动完全独立，贯穿于整个软件周期，与其他流程并发进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；提出了软件测试不仅仅指测试的执行，还包括很多其他的活动；测试是根据被测物的不同而分层次进行，不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
1.4 X模型的优劣分析
X模型要求对每一个程序片段都进行单元测试，但没能提供是否要跳过单元测试的判断准则；多根并行的曲线代表着变更可以在各个部分发生，提高了迭代效率；它还定义了探索性测试，这一方式能帮助有经验的测试人员在测试计划之外发现更多的软件错误，但对测试人员的能力要求比较高。
1.5 前置测试模型的优劣分析
该模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为；明确提出了每一个交付的开发结果都必须通过一定的方式进行测试；它还定义了“开发基于需求的测试用例”以及“定义验收标准”，让验收测试和技术测试保持相互独立。
以上模型都有其优劣，但总体来说，都没有真正的把测试对质量的保障意义或时机把控好，大部分模型中，测试只是软件开发过程的一部分，没有明确独立成一个体系，虽然H等模型把测试对产品质量保证的地位提升了不少，但是仍然缺少对测试规程、资料等重要性的体现。
2 川模型架构
针对软件开发、测试的现状存在的问题（并且结合各已知模型的优点），依据“以测试者引导开发，以文档化把控质量”的测试实施理念，完善、发展了一个新的测试模型──川模型。
2.1 川模型
川模型由三条相对独立的测试实施流程组成，因为类似中文的“川”字而得名。其中的三条测试实施流程分别是验收测试实施流程、需求级测试实施流程、业务级测试实施流程。如图1所示。
2.1.1 验收测试实施流程
该流程提出的目的与重点在于保护用户的真实需求，因为最终产品或项目能否成功交付，验收结果是重要的依据，而验收的主导者一定是用户（代表）。该流程的起始阶段就是在投入真正的研发和测试之前，根据项目需求及测试需求设计出验收方案，以纸质方案的形式与用户（代表）进行评审，以减少后期由于三方（用户、研发、测试）需求不一致的原因导致开发迭代增加。同时，以此验收方案为标尺，约束另两个流程的实施。
2.1.2 需求级测试实施流程
该阶段强调测试伴随着整个软件开发周期，测试与开发并行进行，达到尽早发现问题的目的。把测试的对象扩展成程序、设计（文档资料）、数据等内容，测试工作实时准备，以达到在某个测试点准备就绪时，可迅速切入到测试执行阶段。在该流程中，把迭代测试的内容进行了细致的分析与说明，明确提出迭代过程中需要进行单元/集成测试、功能测试、自动化测试、安全性测试以及专项测试。把自动化测试与安全性测试提高到测试指导阶段，也是当今科技发展的必然趋势。
2.1.3 业务级测试实施流程
如果把测试人员按测试能力分为测试负责人、测试执行人员，那么需求级测试实施阶段的测试执行可以让测试执行人员进行，但是业务级测试实施流程的主要执行人员就应该定位成测试负责人，至少应该是测试负责人主导测试。其根本原因在于该阶段的意义是业务、风险等的把控，并且引入了探索性测试，是作为需求级测试阶段的有利补充。
需求级测试实施流程与研发流程无缝有机结合。业务级测试实施流程存在的价值在于把控与掌握住了产品实际投入使用时的场景、风险等因素，对着重需求进行针对性的设计，满足“八二法则”的经典理论，该流程即把重点放在了“二”上（用户使用的80%的场景可能就存在于20%的功能中）。验收测试实施流程依托于用户的实际需求与前期的测试分析，它作为软件生命周期的标尺，运行到产品或项目结项，最大程度上满足用户需求。
2.2 川模型的工作组织规程
从图1可以看出：
川模型突出体现了测试活动对质量把控的重要性。从项目的可行性分析开始，测试人员就担负着重要的角色。同时，把测试需求说明书、验收方案、测试方案的重要性与提出时机进行了说明。体现：
（1）需求分析需要产品/项目经理、用户、测试人员等全程参与；
（2）测试需求说明书需要测试人员起草，由产品/项目经理、用户、研发等共同审核通过；
（3）验收方案提前由测试人员编写，由产品/项目经理、用户共同审核通过；
（4）研发设计阶段主要依据测试需求说明书编写（其次可参考软件需求说明书），在还没有进行完代码开发之前，测试人员提前输出依据测试需求说明书编写的测试案例，由研发人员提前参考，提高研发依据测试案例开发代码的测试通过率；
（5）迭代阶段大部分在需求级测试实施流程，测试工作实时准备，以便迅速切入测试执行；
（6）业务级测试实施阶段的执行工作是需求级的补充，在软件研发的中后期无缝切入；
（7）验收执行的触发点是业务级测试通过，验收工作完成后，进行项目资料归档工作；
（8）研发过程中，如果有任何变更，需走变更控制程序，返回测试需求分析阶段，并根据实际情况与要害人员输出变更后的系列资料（验收方案、测试案例等）。
3 川模型的甘特图
在图1中的左半部分，做了时间轴与等时线的定义。并且说明了不同职能人员的参与时机，已给大家在时序上的理解。
4 川模型的价值
4.1 体现测试的使命与重要地位
在川模型上，可以很容易的看出测试工作对软件质量的保证意义与实施方法。区别于其他模型，该模型更加清晰、系统的说明了测试的使命，并且该模型真正站到了测试的角色，以测试保证最终用户质量的认可下指导研发的工作，作为研发工作的标尺。
4.2 体现测试先行的重要意义
从产品/项目的可行性分析开始，测试活动就一直伴随整个生命周期，真正体现了“尽早地、不断地进行软件测试”的原则。
4.3 文档化的重要性与可追溯性的提出
在现今越来越快的产品/项目的交互进程中，人们对文档化的需求越来越迫切，文档化不仅可以使研发、测试过程更加有理、有据、科学，也为以后的可追溯性提供了基础。同时，产品/项目前期就对测试案例化的要求，对研发的指导意义更大，研发完全可以“依据测试案例设计软件，案例通过即研发完成”的标准进行开发活动，避免了由于需求不一致的情况下导致研发冗余或功能缺失，提高了工作效率。
4.4 提出三种测试技术相结合的规程
川模型第一次提出了三条执行线的工作模式。验收实施流程作为整个产品/项目的指导流程执行，它与用户最紧密相关，最能体现用户的实际需求，同时避免、减少了在工作过程中的随意变更；需求级实施流程则最有效的保证了测试覆盖率，并且与研发的交互也更加顺畅，提高了测试与研发迭代的敏捷度；业务级实施流程则通过有经验的测试人员，把最重要需求做了风险、场景、探索等地设计验证，可以这样说，经过最后一条执行线的梳理后，用户的实际并且经常使用的功能都被覆盖到。
除了需求级实施流程与研发的交互紧密而充分外，另两个流程相对独立，降低了研发过程干扰，为保证软件质量提供了有利基础。
4.5 等时线为质量保证提供了基础
该模型首次提出等时线的概念，在时序上，避免了工作重复甚至没有必要的交叉。正如该模型的约束，我们必须先进行测试需求分析，输出测试需求说明书后，才可进行验收测试设计；在验收测试设计快完成时，才可以进行需求级测试设计，保证了测试设计与验收标准的高度统一；业务级实施流程通过后，才可进行验收执行工作。从另一层面，也对测试提出了更高的要求，例如在研发提交代码之前，测试的准备工作必须完成，可随时切入工作；有需求变更时，测试人员需要先后更新测试需求说明书、验收方案、测试方案等内容，审核通过后，实时共享给要害人员，确保项目的顺利进行。
5 结束语
川模型的提出时间尚短，只在一两个公司进行过相关实践，看到了明显效果；提高了测试人员的使命感与荣誉感；也减少了软件开发过程中的冗余、遗漏问题。但是，该模型没有经过大量的软件企业实践，还会存在或多或少的问题，仅作一个初步研究，通过这初步的研究，想抛砖引玉，真正找出一款适合中国国情的软件测试思路和测试模型，也欢迎大家一起探讨。
参考文献
[1]柳纯录.软件评测师教程[M].北京：清华大学出版社，2005.
作者简介
李龙，现为北京赛博兴安科技有限公司测试部门经理、北京软达启航科技发展有限公司CTO（兼）、济南得润万家农业科技有限公司副总经理（兼）、中国软件测试联盟专家。他提出的“以测试者引导开发，以文档化把控质量”的测试实施理念，在业界得到好评。先后出版《软件测试实用技术与常用模板》、《云计算基础与实用技术》、《无线网络与应用技术》等7部书。
作者单位
1北京软达启航科技发展有限公司・CTO 北京市 100000
各位领导、老师，亲爱的同学们：
大家下午好！
我叫xx，来自xx班级，很高兴能够代表2018软件测试国赛队上台发言。在这次全国比赛中，xx和xx和xx组成的代表队很荣幸获得一等奖，成为此项赛事湖北省唯一获奖的代表队。这一成绩不仅凝结着我们的汗水，更离不开学校和软件工程学院领导的关心支持，辅导老师的辛勤培育。
这次参赛，使我们得到了很大提高和锻炼，使我深深认识到了只要我们自己付出汗水和努力，就一定能够得到回报。接下来，我代表我的队员发表一下我们从培训到参赛期间的心得体会：
1、始终保持一颗学习的心
刚开始训练的时候，我们每个人对软件测试都了解的比较浅薄，需要重新去学习这方面的知识，而理论知识的学习上是枯燥的，在这个过程中，我们每个人都戒骄戒躁，认真学习，讨论、根据老师给出的测试用例设计方法来举一反三。同时，我们要端正对训练期间学习的态度，不能把训练期间学习的内容当作要去比赛而完成的任务，要真正的探讨，把老师教会的知识完全理解、学会，然后运用到实际操作当中。
2、
责任心和毅力是获奖重要因素
从3月初选拔到5月底竞赛，中间经历了将近3个月的训练，我们每天早8晚8，训练12个小时，每天进行2次模拟练习，练习、总结、再练习、再总结。这个过程是枯燥的，别的同学周末、清明节、劳动节在放假、休息时，我们在培训室敲打着键盘，每天都想着自己去提升自己，比如说：比昨天多写50条测试用例，两篇文档的时间再缩短5分钟，Bug找的更多，性能测试能够解决环境问题。4个小时的比赛时间，我们训练时间从最初的4个小时，压缩到3个半小时，再压缩到3个小时。时间安排上从刚开始的早上2小时，下午2小时，改到和比赛时间相符的早上9点到下午1点。每次训练完后我们都会向老师汇报任务完成度，不足之处，进行自我总结，不浪费一丝时间，甚至在去往许昌的高铁上，我们每个人都拿着一撮打印好的知识要点默读，直到参赛前一天的晚上，才结束这种状态。
3、
细节和临场应对是取胜关键
比赛中有很多实力强的团队，但是有的获得了一等奖，有的没有获得一等奖，其原因就在于细心和临场应对能力。4个小时，6篇文档，很多队都能做到，但是得分的关键就在于细节。我们从训练开始就注重细节问题，尽量不因细节问题丢分。其次是临场应对，赛场上的环境是多变的，我们训练的环境并不可能百分百与赛场环境相符，为了保证在比赛期间不因环境问题打乱计划，在训练的过程中，出现的环境问题都是我们尽量自己去解决，实在解决不了才会询问老师。同时，我们还假想了很多赛场上会出现的问题，并且制定了相应的策略，以充足的准备去面对赛场。
4、
团队协作很重要
1 新时代背景下的ORACLE问题
在软件工程中，软件测试地目的是为了能够发现和找出软件错误运行的情况，专门判断测试过程是否通过的可验证即被称为ORACLE，在如今新时代的背景下，不管是趋势分析还是相应的图论计算等，都开始变得越来越困难。新时代的处理模式，主要包括了物理作用下的数据处理和化学作用下的数据处理两种类型模式。其中，物理作用下的数据处理，主要是在保证其价值的情况下，不断的缩小其数据的规模，然后由此清洗不变的数据基本属性。这其中就包含了针对数据处理的多种方式，能够有效的实现将新时代花销，的物理式变化。因此，物理作用下的数据处理测试ORACLE本身并没有问题。
而基于化学作用下的数据处理，则具备最主要的预测和快速算法的问题，这两个问题都非常经典，直接促使ORACLE的确定变得异常的困难。比如在计算个性化推荐统计学信息当中，经过个性化推荐的商品，更容易获得用户们的喜爱，当然也存在一半不喜欢的概率。而经过计算的结果也只是表明此类商品被喜欢的概率相对较高。概率性问题直接导致结果的正确性和确定性产生本质的区别，直接致使ORACLE确定的难度。
2 传统测试平台难以符合新时代处理的要求
以往所采用的软件性能测试，主要是借助控制器协调本地直接向服务器端发出服务的请求，由此实现对服务器压力的测试，其测试负载产生器都属于局部的物理主机。相对少量的服务器构成应用系统来说，用户数在数百上千量级的应用服务，才能有效满足应用的需求。
如今，随着云计算的发展，用户的需求也在不断的增长，其多个系统所需支持的并发用户也在不断的增加，相应的访问量也在由此攀升。这就需要针对服务端系统是否能够真正承受如此巨大的用户访问量进行有效的测试，可直接在系统上线之前就展开较为充分的测试内容。以往局域网主机测试方法所产生压力，很难真正满足服务器对其所产生的压力测试需求。由此软件测试工作中开始出现一系列的问题。一是负载产生器的物理机数量很难获得动态的扩展；二是新时代所驱动的云计算系统，直接采用了广泛的分布客户端。三是在网络海量数据的推动下，控制器所监控的负载产生器状态直接成为性能测试的瓶颈，很容易由此引发测试失败。四是控制器对负载产生器的同步问题变得越来越复杂，直接影响到负载测试的效果。
3 软件服务化所引发的测试挑战
具体从开发的模式而言，软件开发的过程，主要包含了完全编码、构件化、服务以及云计算等多个阶段。
3.1 完全编码阶段
主要是相应开发人员直接从零基础开始对每行代码的编写过程，除了系统本身所提供的类库之外，通常所有的代码都是直接由相应开发人员所掌握。在此阶段当中，用户们普遍具有良好的可测性，几乎所有的测试和调试方式都可以实现。
3.2 构件化阶段
该阶段直接是为了提升软件开发的效率，要求相应开发组织必须在系统类库的基础上，结合业务自身的特点来构建出可复用的业务组件。而通常该组件都是在本地运行，因此其业务系统的耦合度明显偏高，用户们对于组件的掌控也明显较大。
3.3 服务阶段
在此阶段当中，多数本地组件所提供的调用可转变成为远程服务形式。用户们可对外部的服务控制处于逐渐减少的状态，只能透过服务的输入和输出来实现对服务情况的良好把握。
3.4 云计算阶段
这一阶段主要是特别架构和PASS之上的应用程序，在处理输入和输出的同时，多数用户并不具备了解PASS服务运行情况的能力，因而导致用户测试的难度再次增加。
4 杀虫剂效应
在软件工程测试领域当中，杀虫剂效应是指相应的测试软件越来越多，其免疫能力变得越来越强的现象。这种现象就如同采用农药杀虫是一样的效果，如果持续采用一种单纯的农药，则害虫将最终在体内产生一定的抗体，在此情形下，农药将无法发挥出应有的杀虫效力。而在多种构件化开发当中也是如此，通常在中前期发现多种缺陷的模式，其都可直接通过校验和验证的方式集成在构件当中，乃至直接成为构件的必然属性。此类构件并不需要开发人员进行单独的代码编写，其直接对测试的方式产生了天然性的免疫能力。
在软件工程中，杀虫剂效应将有效的促使软件的测试技术获得飞跃式的更新升级，可迅速的找出存在软件当中的缺陷问题。一般在进行测试的初期阶段，只需通过较少的测试即可直接发现其中所存在的更多缺陷，而在后期的测试当中，则很容易发现其所存在的缺陷数量，将渐渐趋于平缓，甚至最终在某个周期停止增长。
关键词： 软件测试 测试用例 复用技术
1.引言
随着软件工程领域的拓展，在软件产业飞速发展的今天，软件测试成为保证软件质量的重要手段。测试用例的选择对于软件测试的成败起着决定性作用，因此如何设计最少的测试用例实现最大的测试覆盖成为自动化测试领域中的主要研究对象。测试用例是确定一组最有可能发现错误的测试数据和流程，实现系统对某个功能的测试［1］。而测试用例的设计与测试人员的个人经验息息相关，不同测试人员的个人经验和书写格式的差异导致了测试的盲目性，以至于产生较高的后期维护费用。测试用例的复用技术一方面是为了解决由测试人员经验不足带来的问题，同时还避免了在设计测试用例中的重复劳动，有效地提高了测试效率。
2.软件测试
2.1软件测试的定义
软件测试（Software Testing）是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（包含输入数据及其预期的输出结果），并用这些测试用例去运行程序，以发现程序错误的过程［2］。
2.2软件测试的目的
Glenford J.Myers就软件测试的目的提出了以下观点：
2.2.1测试是程序的执行过程，目的在于发现错误；
2.2.2一个好的测试用例在于能发现至今为止尚未发现的错误的用例；
2.2.3一个成功的测试是指揭示了至今为止尚未发现的错误的测试。
测试的目的花费最小的代价找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷来提高软件质量，回避因软件潜在错误和隐患带来的商业风险［3］。
3.软件测试用例的复用
3.1软件测试用例的复用
软件测试复用可以理解为在两次或多次不同的软件测试过程中重复使用相同或相近的测试资源来组织测试的过程［4］。软件测试的复用主要包括测试流程的复用、测试方法的复用和测试用例的复用。其中测试用例的复用是测试复用中的关键技术。所谓测试用例复用是指对一个软件已执行的测试用例，将其不同程度地应用于该软件新阶段的测试中或其他软件的测试中。可复用的测试用例具有通用性、独立性、有效性、标准化和完整性的特点［5］。
3.2可复用测试用例的设计
测试用例能否成功被复用很大程度上取决于测试用例的独立性，即能否独立地应用于不同的应用场合和应用环境。在实际应用当中，很多测试用例之间存在着相互的关联。有的测试用例的运行环境要取决于另外测试用例的执行状态，当它所依赖的环境变化或失效时，而与之相关联的其他测试用例的复用属性也可能随之消失。那么如何设计不依靠软件运行环境具有较高独立性、与其他测试用例减少关联且具有统一输入输出接口的可复用的测试用例就成为问题的关键所在。
测试用例是面向不同应用对象的，与被测试软件具有很高的耦合性。为了使得设计的测试用例能够实现成功复用，在测试用例的设计上采取如下步骤。
3.2.1共性分析
首先应该对被测软件进行共性分析，同一应用领域的软件有相似的需求，分析其诸如工作流程或功能相同等共同特点，并根据他们的共性挖掘可复用因素。
3.2.2测试用例统一建模
根据可复用因素，设计合适的测试策略，对测试用例的设计做出统一的建模组织，设计统一的结构和输入输出接口。
3.2.3设计可复用的测试用例
为了尽可能地降低测试用例与被侧软件的相关性，在设计测试用例时应该尽量对其进行通用化处理，同时应保持测试用例的功能单一性。测试用例和被测软件的高耦合性决定了测试用例的复用大多只在同一软件的回归测试或版本升级测试中成功实现，而很难在不同应用领域的软件测试中使用。
3.2.4测试用例的测评
设计好测试用例之后，组织测试人员和评审专家根据功能需求将测试用例应用于被测软件的测试中，确保测试用例的正确性。改变软件运行环境或测试数据后是否能得出合理的测试结果，分析异常和边界情况的测试结果。
3.2.5完善测试用例
根据测试结果分析测试用例是否覆盖并测试了全部的共性需求，进一步完善或纠正测试用例。
3.2.6测试用例入库
将通过测评和完善后的可复用测试用例根据其属性和功能分门别类并按照一定的组织结构放入测试用例数据库中。
3.3可复用测试用例的管理
测试人员要对用例数据库进行统一有效管理，提供测试用例的功能属性、运行环境、测试方法和项目来源以供测试人员以后的查询和使用［6］。管理人员要及时删除冗余，避免重复用例出现。随着软件技术的发展和测试用例数目的不断增加，对那些不再具备复用价值的测试用例移入其他数据库，以便提高搜索和使用效率。
4.结语
软件测试的复用是目前测试领域研究的热点问题，而设计可复用的测试用例又是实现测试复用技术的关键。本文介绍软件测试用例复用的同时，在理论上给出了可复用测试用例设计的思想和具体方法。在实践中，实际存在的问题往往比我们可以预想到的更多、更复杂，在不同领域和不同功能的软件中实现测试复用的难度更大，需要我们在不停总结经验的基础上还要灵活运用，合理有效管理，才能使测试复用技术进一步发展，提高测试效率，更好地服务于软件产业。
参考文献：
［1］张玉彬，谢康林.测试用例的设计和复用［J］.计算机应用与软件，2008，25，（1）：23-24.
［2］缪静.基于Web应用的测试研究与应用［D］.成都.电子科技大学，2005.
［3］赵中芳.基于CBR的测试用例复用模型的研究与应用［D］.青岛：中国海洋大学，2008.
［4］卜国峰，孙志刚，丁小良.软件测试用例的复用研究［J］.四川兵工学报.第30卷第5期，2009.5：34-35.
关键词：自动化软件测试；模糊测试；错误定位
中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）06-1231-04
计算机的应用越来越多地深入到人们的日常生活中，然而计算机软件还远没有达到零错误的要求。提高软件质量已经成为软件工程领域亟待解决的重要问题。软件测试，作为一种提高软件质量的重要手段而备受重视。在软件的开发生命周期中，软件测试是一个耗时耗力的过程，已成为软件开发的瓶颈之一[1]。据统计，软件测试约占软件开发和维护成本的50%～75%[2]，因此，改进和改善软件测试技术变得十分迫切与重要。模糊测试[3]是一种通过提供非预期的输入并监视异常结果来发现软件漏洞的技术。模糊测试一般是一个自动或半自动的过程，这个过程包括反复操纵目标软件并为其提供处理数据。近年来，有很多学者在不同类型软件的软件测试中都证实了模糊测试技术的有效性和自动化的特点。模糊测试技术针对不同类型的测试环境有不同的测试策略。例如，张等人[4]提出了一种针对网络协议及模糊测试框架。沈等人[5]提出了一种基于文件规范描述的文件模糊测试算法，有效避免“无效”测试用例的生成，提高效率同时也增加了测试的全面性。
上面提到的模糊测试的研究重点主要集中在模糊器的设计与实现上，几乎没有涉及到错误定位的技术。基于频谱的错误定位方法是基于实际执行的动态错误定位技术的具体应用。Harrold等人证实了程序频谱与程序行为之间的关系，论证了通过研究运行失败测试用例得到的频谱信息与运行成功测试用例得到的频谱信息之间的差异性可为定位出错语句提供帮助[6]。该文调研了模糊测试技术和自动化错误定位技术的研究进展；第2节论述了自动化错误挖掘与定位技术可行性，并解释本文技术的动机；第3节介绍自动化错误挖掘与定位技术的实现方法；模型的实现将在第4节给出；第5节总结并展望未来的研究方向。
1 研究动机
在软件的生命周期中，软件的维护成本所占比例特别大，所以一个好的软件测试方法是非常必要的。一种优秀的测试方法可以发现软件中存在的大部分漏洞，从而可以降低软件的维护成本，提高软件的质量。模糊测试是1989年由Bartoon Miller教授首先提出的，并通过模糊测试在UNIX存在的大量漏洞。在1999年Oulu大学开发PROTOS测试集，这标志着模糊测试发展历程的一个重要里程碑。2002年PROTOS开始成熟，在2004年文件模糊测试开始兴起，AxtiveX模糊测试在2006年开始流行。到目前为止模糊测试取得了一定的发展，已经是软件漏洞挖掘中不可或缺的技术，但是这项技术仍然不是特别成熟[3]。图1给出了模糊测试的过程。
软件错误定位技术是通过运行测试用例得到程序的各条语句被测试用例覆盖的信息，然后利用覆盖信息计算出程序中语句的出错可疑度[7]。在实际的测试过程中，有很多情况是测试用例导致程序的崩溃，程序崩溃时寄存器中的信息也是非常重要的。所以利用程序的覆盖信息与程序崩溃是寄存器存储的信息共同来定位程序的出错信息可以提高定位的精度和速度。利用GCC中的GCOV命令可以收集C程序的运行的详细信息，包括覆盖率、代码的执行路径、程序的执行结果等信息。利用GDB调试器可以查看程序运行时CPU寄存器的状态。
随着计算机的不断发展，程序的代码越来越庞大，基于源代码审核的白盒测试需要大量的人力和时间，这会大大增加软件开发的成本。软件测试的自动化是未来软件测试发展的主要方向，通过把模糊测试技术和软件错误定位技术结合起来，可以实现软件测试的自动化，提高软件维护的效率。
2 自动化错误挖掘与定位技术
在这一节将介绍自动化错误挖掘与定位技术的总体结构，以及对结构中各主要模块的功能与实现。
2.1 自动化错误挖掘与定位技术的总体结构
为了实现软件测试的自动化，所提出的解决方案由一下几个模块组成：模糊器模块，测试结果记录模块，错误位置分析模块。图2为自动化错误挖掘与定位技术的流程图。
图2 自动化错误挖掘与定位技术的流程图
2.2 模糊器模块
模糊器模块的主要作用是生成测试用例，并把测试用例提交给被测软件，是模糊测试的核心结构。模糊测试可分为两类[8]：基于变异的模糊测试和基于生成的模糊测试。对于不同的测试目标有不同的模糊器，其中主要的分类有：
1） 环境变量和参数。测试对象主要是命令行参数和环境变量，主要的模糊器是iFuzz。
2） Web应用程序和服务器。针对Web服务器的存在漏洞的模糊器有Dave Aitel开发的SPIKE和WebScarab。
3） 文件格式。针对特定的文件格式，用于挖掘客户端文件解析漏洞，主要的模糊器有notSPIKEfile、SPIKEfile和FileFuzz。
4） 网络协议。通过特定的Socket形式将变异或者含有错误的数据包发送给目标程序，相应的模糊器有SPIKE和ProtoFuzz。
此外对于特定的测试目标，我们也可以手动构造模糊器，在构造模糊器时要充分考虑程序中可能存在的问题，例如：拒绝服务、整数处理问题、简单的栈和堆溢出、格式化字符串和目录遍历等。对于不同的问题确定模糊器不同的用例生成规约。例如，对于整数处理问题，我们可以设计这样的用例规约：生成边界值附近的测试用例0，-1，1，2，3，0XFFFFFFFF-1，0XFFFFFFFF-2等测试用例。此外，我们还可以直接在网上下载有用的工具和库，具体请查看文献[12]。
2.3 测试结果记录模块
我们的目标是实现软件测试的自动化，所以就不能依赖人工识别错误。为了实现这个目标，我们需要一种可靠的，可编程的方法。有一种方法是检查程序的返回代码[9]，在现在的UNIX和Linux系统中，如果一个应用程序因为一个为处理的信号而中止，那么Shell的返回代码将等于128加上该信号数字。可以利用这个值来判断不同的错误。还有就是把应用程序连接到调试器，错误处理机制将阻止由模糊测试所导致的许多错误的明显标记，但是这些错误一般可以通过使用一个调试器来发现。在Linux操作系统中，GDB就是一个特别好的调试器，一般来说，GDB主要帮助你完成下面四个方面的功能：1）启动你的程序，可以按照你的自定义的要求随心所欲的运行程序；2）可让被调试的程序在你所指定的调置的断点处停住；3）当程序被停住时，可以检查此时你的程序中所发生的事；4）动态的改变你程序的执行环境。对于有些应用程序，我们也可以通过见识其运行日志带识别程序的运行结果。
测试用例执行路径是用于错误定位分析的主要数据，检测程序的主要方法是在程序的源代码中进行插桩，根据程序的执行结果来得到一个测试用例的执行路径。但是这种方法是基于语句的，在前期对源代码的处理中费时费力，效率低下。在这里提出了一种新的插桩策略，在程序运行的时候，有很多语句块只要语句块的第一条指令被执行，其后面的所有语句都会被执行，把这样的代码块称为基本块。在插桩时以基本块为单位，这样可以减少前期的准备工作，又可以提高程序的运行效率。
对于每个测试用例的结果都进行保存，用于最后的定位分析。我们把用例执行的相关信息保存到数据库中，其中数据库有三个标，分别用为：
1） 代码表（codes），用来存储程序的源代码；
2） 用例执行信息表（info），用来存储用例执行的各种信息，主要用，测试用例、执行路径、执行结果等；
3） 异常表（abnormal），存储导致程序出现异常时CUP各寄存器以及堆栈中的信息。
下面是记录模块的结构图。
图3 记录模块结构图
2.4 错误位置分析模块
错误位置分析模块的功能是根据数据库中的测试数据计算可能出错或存在漏洞的语句。因为数据库中记录了每条测试用例的执行路径和执行结果。可以利用数据库强大的数据处理能力，计算出错路径中每条语句的可疑度，其计算公式如公式（1）：
[RESULTi（s）=TFi（s）TFi（s）+TP（s）] （1）
其中，TFi（S）经过语句S出错（错误类型为i）的测试用例个数，TP（S）是正常经过语句S的测试用例数。最后得到的结果为一系列语句可疑度的列表，其中可疑度最大的，出错的可能性也最大。
3 模型实现与实验
实验模型是建立在ubuntu 13.04 操作系统上，应用的开发语言是Python 2.7.4，数据库是Mysql Server 5.5.31。在实验模型中主要用到的软件有GCov 4.7.3和GNU gdb （GDB） 7.5.91.20130417-cvs-ubuntu。GCov用于收集用例执行路径，Gdb用于查看测试软件的执行细节。实验用的目标程序是从SIR[10]（http：//sir.unl.edu）网站上下载的grep。实验中数据库表结构如下表。
表1 目标程序代码表
表2 用例执行路径表
表3 用例执行路径表
通过简单的模拟实验，验证了该方法在软件测试中代码覆盖率、漏洞定位准确性有明显的提高，并且为发现的漏洞提供了相应的信息。并且在整个软件测试过程中，需要人干预的地方很少，基本实现了从用例生成、错误检测和错误定位的自动化。
4 总结与展望
本文中提到的软件测试方法实现了软件测试中用例生成、测试与错误定位分析的自动化，提高了软件测试的效率，加快了软件开发的周期，降低了软件维护的成本。同时该方法也存在一定的局限性，不能测试出软件中存在的逻辑错误，也不能能验证软件功能的完整，只对软件中存在其他错误（非法引用、堆栈溢出、格式化字符串等）有效。
在以后的研究中，应探索新的软件错误定位的方法和技术。可以从一下几个方面展开研究：
1） 利用动态的二进制插桩。在软件测试中，有很多错误不能直接被发现，例如：函数的堆栈溢出，如果溢出只是覆盖了函数中的一些变量，没有覆盖函数的返回地址，即EIP的值。这种情况程序是不会报错的，根据程序的运行结果很难定位错误。所以利用动态二进制插桩来实时监控程序的运行状态是一个不错的研究方向。
2） 利用人工只能，实现软件错误定位与自动修复。随着计算机技术的发展，软件规模越来越大，Binkley 估计到 2025 年人们开发的代码将达到万亿行[11]。面对数量庞大的代码，数据挖掘、机器学习等人工智能技术将会在故障定位方面得到很好的应用。
参考文献：
[1] Zhang Yu-Qian，Zheng Zheng，Ji Xiao-Hui. Markov Mpdel-Based Effectiveness Predicting for Software Fault Location[J].Chinese Journal of Computer， 2013，36（2）：445-448.
[2] Yu Kai，Lin Meng-Xiang.Advances in automatic fault localization techniques.Chinese Journal of Computer，2011，34（8）：1411-1422.
[3] Sutton M，Amini A G P.Fuzzing： Brute Force Vulnerability Discovery[M]. 黄陇，于莉莉，李虎，译.北京：机械工业出版社，2009：13-20.
[4] 张宝峰，张斌，许源.基于模糊测试的网络协议漏洞挖掘[J].清华大学学报：自然科学版，2009，49（S2）：2113-2118.
[5] 沈亚楠，赵荣彩，王小芹，等.基于规范生成的文件模糊测试[J].计算机工程与设计，2010，31（16）：3591-3594.
[6] Harrol M J，Rothermel G，Wu R，Yi L.An empirical investigation of program spectra[C].Proceedings of the ACM SIGPLAN/SIGSOFT Workshop Program Analysis for Software Tools and Eng （PASTE' 98）. Montreal， Quebec，Canada，1998：83-90.
[7] 谭德贵，陈林，王子元，等.通过增大边际权重提高基于频谱的错误定位效率[J]. 计算机学报，2010，33（12）：2335-2338.
[8] 陈衍铃，王正.模糊测试研究进展[J].计算机应用与软件，2011，28（7）：291-293.
[9] Sutton M，Amini A G P.Fuzzing：Brute Force Vulnerability Discovery[M].黄陇，于莉莉，李虎，译.北京：机械工业出版社，2009：65-66.
[10] Do H，Elbaum S G，Rothermel G.Supporting controlled experimentation with testing techniques： an infrastructure and its potential impact[J]. Empirical Software Engineering，2005，10（4）：405-435.
【关键词】软件测试；安全测试；测试要点；策略
软件开发的完善给测试人员带来巨大的压力，从开发至软件投入使用，都不缺测试工程师的身影。其中过程需要六大质量特性的测试、性能测试、甚至安全测试。针对安全保密性方面，测试工程师需要利用资源进行测试要点的收集及测试用例的设计，从而更多的发现软件运行时可能出现的安全漏洞。
一、数据库安全的测试策略
数据库安全是整个系统的核心，系统中所有用户的信息全依靠数据库的校验。在数据库测试策略中，针对B/S架构软件最常用的有身份鉴别、安全审计、漏洞安全等三方面。
（一）身份鉴别：为的是测试数据库系统账户口令和传输的安全性，执行过程中主用SELECT * FROM DBA_PROFILES命令，其中包涵的内容有：1.数据库系统密码复杂度函数必须实现配置，以避免密码被破解而导致用户敏感信息泄露。2.用户登录系统失败有处理机制，以避免有意人员利用会话失败，进行用户并发攻击数据库，致使数据库崩溃。3.在用户连接数据库后闲置超时，必须有配置自动退出，以避免用户敏感信息被恶意抓包。
（二）安全审计：对数据库系统日志审计的安全性进行测试，保证数据库审计策略配置必须达到基线要求。
（三）漏洞安全：同样是对数据库系统日志审计的安全进行测试，保证数据库能达到安全配置要求：1.数据库必须存在拒绝服务攻击配置。2.不能有远程溢出等安全漏洞。3.数据库组件必须安全配置完备，无漏洞。4.数据库内核漏洞均已修复。
二、WEB应用安全：B/S架构已成为市场信息系统开发的主流，而WEB应用的安全防护更需要谨而慎之，下面罗列出针对WEB应用安全的常见的测试策略
（一）密钥管理：要求根据某个指定的标准规定的算法和密钥长度来生成密钥。操作步骤：1.进入Web应用系统，打开密码修改功能；2.查看Web应用的密码修改功能是否需要输入原密码。3.设置简单密码123456，记录返回结果。期望结果：修改密码是需要输入原密码，并且不能设置简单密码。
（二）输出到TSF控制之外：经由本功能输出的用户数据输出时没有输出相关的安全属性。操作步骤：1.使用webscarab对登录操作进行抓包；2.查看数据包内容是否为明文传输。期望结果：数据包中的密码已进行加密处理。
（三）信息流控制功能：对每一个操作，主体和信息的安全属性之间必须支持基于安全属性的关系，TSF应允许信息在受控主体和受控信息之间经由受控操作流动。操作步骤：1.打开appscanweb安全扫描软件；2.新建任务；3.输入域名；4.开始扫描；5.记录扫描结果。期望结果：不存在注入漏洞及跨站漏洞。
（四）TOE内部传送：数据在传输过程中，期间的所有设备都必须对传输数据的完整性座监视。操作步骤：1.使用webscarab进行抓包；2.修改数据包中内容；3.查看返回信息。期望结果：无法修改数据包中内容
（五）残余信息保护（TSF数据管理）：确保系统内文件、目录等资源所在的存储空间，被释放或重新分配给其它用户前得到完全清除。
（六）访问控制功能：提供访问控制功能，依据安全策略控制用户组对系统功能、文件、数据库表等客体的访问。
（七）鉴别失败：检测系统对用户多次尝试登录失败，系统做出相应的处理。操作步骤：1.连续输入十次账号密码；2.查看系统对该账号是否锁定。期望结果：账号被锁定。
（八）用户标识：在登录网站前要求用户必须输入用户名。操作步骤：1.打开web登录页面；2.查看是否需要输入用户名和密码才可登录。期望结果：必须输入用户名和密码。
（九）不可观察性：要求功能或资源的使用不能被规定的用户或主体观察到，规定用户隐私有关的信息在评估对象内是分布式的。期望结果：1.进入应用系统-使用最高权限管理员登录系统，在用户管理中查看有哪些级别用户和用户的权限；2.退出系统使用普通用户登录系统，去访问非授权资源，和查看非授权的信息。期望结果：无敏感信息泄露。
（十）时间戳：评估对象的安全功能需为它自己的使用提供可靠的时间源。
（十一）评估对象访问旗标：在建立一个用户会话之前，评估对象安全功能应显示有关未授权使用评估对象的一个劝告性警示信息。
（十二）会话锁定：在一定时间内，用户没有做任何操作，系统则自动锁屏或显示一个非重要功能的页面，当用户再次使用时，需要重新登录。操作步骤：1.进入web系统；2.闲置5-10分钟；3.刷新页面；4.记录返回结果。期望结果：账户已自动退出。
三、主机安全：主机是系统客户端与数据库进行数据交换的中心，在其上的安全跟数据库安全相同，需要针对身份鉴别、安全审计、漏洞安全进行探察
（一）身份鉴别：1.系统配置避免重复UID策略。2.系统配置密码安全策略。
（二）安全审计：操作系统中必须开启安全审计策略。
（三）漏洞安全：系统不存在高风险安全漏洞。
总之上述只是简单常见的安全测试要点，安全测试涉及的知识面很广，不同的软件领域需要的测试点不同，此时则需要我们在实际工作过程中自我总结出属于自己并适合公司的测试要点。
参考文献：
[1]GB-T 16260.1-2006 软件工程 产品质量.
