自动化测试范文
时间：2023-04-04 15:45:23
导语：如何才能写好一篇自动化测试，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。
篇1
在自动化测试领域中，传统的自动化测试脚本的开发一般有两种方法。第一种方法是通过手工运行一次测试，同时使用自动化测试工具的录制功能，把所进行的操作记录下来，生成测试脚本。这种技术生成的脚本回放成功率比较低，后期维护也比较困难。第二种方法是编写测试框架，对测试需要的基础操作提供接口供调用，测试人员根据用例操作需求，手工编写调用接口的自动化测试脚本，这种方法对测试人员的代码水平要求很高。
目前自动化测试中，测试小组成员编写完用例以后，还需要脚本开发人员单独编写一条针对此用例的自动化测试脚本，然后使用自动化测试工具运行脚本进行测试。当测试用例变更后，还需要重新编写这条测试脚本，资源耗费比较大。测试用例和测试脚本之间的维护比较复杂。
1 实施过程
1.1 项目介绍
针对现有技术中的缺陷，本想法要解决的技术问题是：如何将测试用例自动地转化为自动化测试脚本，以减少自动化测试脚本的代码量、资源消耗及测试用例和测试脚本之间的维护。
为解决上述技术问题，我和小组人员不断的摸索以及通过实际工作中多次测试和联调，探索出一种只要被测产品中没有产生新的控件类型，就不需要修改自动化测试脚本的解决办法。通过在实际项目中多次试验，本控件类型在测试用例中可以任意制定被测产品的流程，不会局限某个系统、某个产品。
根据多次实验结果得出一种自动化测试方法，包括如下步骤：
步骤1：定义控件属性与预置测试脚本代码之间的对应关系。本环节是通过设置的相应的对应关系，在前期就降低控件的可变化性。
步骤2：读入测试用例的测试数据，其中，所述测试数据包括控件属性。
该数据从项目实际运营过程中获取，保证能够在测试过程中发现更多的问题，确保一旦正式后在实际运行过程中避免出现类似错误。
步骤3：针对读入的控制属性，查找到对应的预置测试脚本代码；大多数自动化测试并没有这一步骤，通过读入控件属性，可以降低代码的重复性，是本设计特有的环节。
步骤4：根据预置测试脚本代码形成自动化测试脚本代码；
步骤5：将预置测试脚本代码添加到编写的自动化测试代码框架中，形成自动化测试脚本代码，执行自动化测试脚本代码，其中，自动化测试脚本代码用于模拟手动执行测试用例中各个控件类型的动作。
以上二分部主要由软件自动完成，无需手动进行，这也就是自动化测试的魅力所在，可以在很大程度上降低人力手动操作的时间，腾出更多时间去完成其他事情，增加工作效率。
2 附图说明
2.1 测试流程
为了将思想的其它特征、目的和优点更明显展示出来：通过阅读参照图1附图将会更直观。
2.2 解决办法
下面结合具体实施例对本方案进行详细说明。以下实施案例将有助于本领域的技术人员进一步理解本人的思想，但不以任何形式限制本思想。应当指出的是，对本领域的普通技术人员来说，在不脱离本方案构思的前提下，还可以做出若干变形和改进。
每个项目都需要人员的配合。需要需求人员、产品开发人员和自动化测试脚本代码开发人员共同配合，产生控件ID与被测系统映射表、控件类型与代码映射表，例如表1和表2所示，其中，控件ID与被测系统映射表记录了控件名称、测试用例中控件ID、被测系统中的控件ID之间的映射关系，控件类型与代码映射表记录了控件类型、测试用例中控件类型、被测产品中控件类型、测试脚本中控件类型的映射关系。
本方案的方法和系统可以连接测试用例管理工具，读取测试用例，通过解析模块解析测试用例信息，生成脚本可读的信息，然后根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块，最后确定被测模块；我的主要想法还是根据测试用例中的控件类型在控件类型与代码映射表中查找对应的测试脚本代码，执行自动化测试脚本来最终产生测试结果。具体步骤如图1所示，包括：
步骤1：我们要先读取用户编写的测试用例，例如可以连接测试用例管理工具，从存储有用户编写测试用例的测试用例管理工具中读取，测试用例中的控件类型和操作命令、自动化测试脚本中的控件类型和操作命令、被测试系统中控件类型和操作命令三者一致，测试用例中的控件ID与被测系统的控件ID一致。
步骤2：解析测试用例信息，生成脚本可读的信息。
步骤3：根据测试用例中的控件ID在控件ID与被测系统映射表中查找对应被测模块。具体地，根据测试用例中的控件ID，在控件ID与被测系统映射表中，首先查找到对应的被测系统中的控件ID，然后根据该被测系统中的控件ID再查找到对应的被测模块，其中，所述被测模块是被测系统的某个测试单元，例如，一个文本框、一个多选框、一个单选框等。
本组成员在项目中反复实践发现了一致性的关键点。目前很多自动化测试都是由于忽略了一致性才导致脚本可用性降低从而人为的增加了测试的工作量，说是实现了自动化测试，反而却是增加成本。
步骤4：根据测试用例中的控件类型在控件类型与代码映射表中查找对应的自动化测试脚本代码。具体为，根据测试用例中的控件类型，在控件类型与代码映射表中，首先查找到对应的测试脚本中控件类型，然后根据该测试脚本中控件类型再查找到对应的自动化测试脚本代码。
步骤5：执行步骤4的控件类型对应的自动化测试脚本代码，该自动化测试脚本代码用于模拟手动执行通过步骤3查找到的被测模块的控件类型的动作。
步骤6：输出自动化测试脚本代码产生的实际结果。
步骤7：比较自动化测试脚本代码产生的实际结果与测试用例中的预期结果是否一致，如果一致说明测试通过；如果不一致说明测试不通，并且指出不通过的原因
使用本方案的方法，即使当测试用例变更后，测试人员只需按照关键字规范，手工修改一次测试用例即可。
下面对本方案的一个优选具体实施方式进行描述，在本具体实施方式中，包括以下步骤：
Step1：需求人员、产品开发人员和自动化测试脚本代码开发人员共同定义好被测产品中控件类型与控件的ID，产生相应的映射表，标准控件的使用标准定义。
共同定义是非常重要的，针对不同项目，前期应把控件类型和id定义成标准，并在开发过程中使用统一标准。
Step2：产品开发人员和自动化测试脚本代码开发人员根据映射表为被测产品的每个控件设置控件类型、控件ID。
Step3：定义测试用例内容以及格式；测试用例内容包含：控件类型、控件ID等；测试用例的格式如：（系统模块名称，控件类型，控件ID，输入内容，操作命令，预期输出，时间输出，测试结果）。
Step4：执行自动化测试脚本代码，包括如下子步骤：
Step4.1：读取用户编写的测试用例，所述测试用例中的控件类型和操作命令、自动化测试脚本中控件类型和操作命令、被测试系统中控件类型和操作命令三者一致，测试用例中的控件ID与被测系统的控件ID一致。例如，可以首先连接存储有用户编写的测试用例的测试用例管理工具，然后从测试用例管理工具中读取测试用例。
其中，Step4是自动化测试一个控件过程，在自动化测试脚本代码中，分别实现模拟手动执行每个控件类型的动作，并且使每一个控件类型的动作成为一个独立的模块，根据控件类型可以查找到对应的测试脚本代码。脚本代码可以重复利用，只要被测产品中没有产生新的控件类型，就不需要修改自动化测试脚本。测试用例中可以任意制定被测产品的流程，不会局限某个系统、某个产品。
其实优选具体实施方式和之前介绍的没什么区别，这里要说的是不管哪种方案要强调的是测试用例中的控件类型和操作命令、自动化测试脚本中的控件类型和操作命令、被测试系统中控件类型和操作命令三者一致，这个是本文的重点，也是提出本方法的关键。
3 结论
篇2
关键词 软件测试 软件自动化测试 测试用例
1软件测试的相关概念
软件测试是指在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常，在设计了测试用例并通过评审之后，由测试人员根据测试用例中描述的规程一步步执行测试，得到实际结果与期望结果的比较。在此过程中，为了节省人力、时间或硬件资源，提高测试效率，便引入了自动化测试的概念。
2软件测试的步骤及前提条件
2.1软件测试的步骤
软件测试分为五步，依次为单元测试、集成测试、确认测试、系统测试和验收测试。
2.2自动化测试的前提条件
实施自动化测试之前需要对软件开发过程进行分析，以观察其是否适合使用自动化测试。通常需要同时满足以下条件：
（1）需求变动不频繁。测试脚本的稳定性决定了自动化测试的维护成本。
（2）项目周期足够长。自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成，这样的过程本身就是一个测试软件的开发过程，需要较长的时间来完成。
（3）自动化测试脚本可重复使用。如果费尽心思开发了一套近乎完美的自动化测试脚本，但是脚本的重复使用率很低，致使其间所耗费的成本大于所创造的经济价值，自动化测试便成为了测试人员的练手之作，而并非是真正可产生效益的测试手段了。
另外，在手工测试无法完成，需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。
3自动化测试的工具
3.1 QTP
QTP是quicktest Professional的简称，是一种自动测试工具。使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。因此在测试前要考虑好如何对应用程序进行测试，例如要测试那些功能、操作步骤、输入数据和期望的输出数据等。
QuickTest针对的是GUI应用程序，包括传统的Windows应用程序，以越来越流行的Web应用。它可以覆盖绝大多数的软件开发技术，简单高效，并具备测试用例可重用的特点。其中包括：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果和维护测试等方面。
3.2 WinRunner
Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障及长期稳定运行。
企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。这些系统在之前，升级之后都要经过测试，确保所有功能都能正常运行，没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统，是每个公司都会面临的问题。
3.3 Rational Robot
是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational Test Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。
3.4 AdventNet QEngine
AdventNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。支持对于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发，因此便于移植和提供多平台支持。
3.5 SilkTest
是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使用户能够高效率地进行软件自动化测试。这些功能包括：测试的计划和管理；直接的数据库访问及校验；灵活、强大的4Test脚本语言，内置的恢复系统（Recovery System）；以及具有使用同一套脚本进行跨平台、跨浏览器和技术进行测试的能力。
3.6 QA Run
QARun的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行编辑和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同
3.7 Test Partner
是一自动化的功能测试工具，它专为测试基于微软、Java和Web技术的复杂应用而设计。它使测试人员和开发人员都可以使用可视的脚本编制和自动向导来生成可重复的测试，用户可以调用VBA的所有功能，并进行任何水平层次和细节的测试。TestPartner的脚本开发采用通用的、分层的方式来进行。没有编程知识的测试人员也可以通过TestPartner的可视化导航器来快速创建测试并执行。通过可视的导航器录制并回放测试，每一个测试都将被展示为树状结构，以清楚地显现测试通过应用的路径。
3.8 Telelogic TAU
TAU第二代包含三个最新的、最强大的技术用来加速大规模软件开发和测试：统一建模语言（UML）及它的许多最新修订版本中的特性，UML2.0；功能强大的测试语言TTCN-3和新的构造系统的方法：Model Driven Architecture（模型驱动构架）。
4自动化测试的过程
4.1自动化测试需求分析
当测试项目满足了自动化的前提条件，并确定在该项目中需要使用自动化测试时，我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据，并形成详细的文档，以便于自动化测试框架的建立。
4.2自动化测试框架的搭建
所谓自动化测试框架便是像软件架构一般，定义了在使用该套脚本时需要调用哪些文件、结构，调用的过程，以及文件结构如何划分。
而根据自动化测试用例，我们很容易能够定位出自动化测试框架的典型要素：
4.2.1公用的对象
不同的测试用例会有一些相同的对象被重复使用，比如窗口、按钮、页面等。这些公用的对象可被抽取出来，在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时，只需要修改该对象属性即可，而无需修改所有相关的测试脚本。
4.2.2公用的环境
各测试用例也会用到相同的测试环境，将该测试环境独立封装，在各个测试用例中灵活调用，也能增强脚本的可维护性。
4.2.3公用的方法
当测试工具没有需要的方法时，而该方法又会被经常使用，我们便需要自己编写该方法，以方便脚本的调用。
4.2.4测试数据
一个测试用例需要执行很多个测试数据，我们便可将测试数据放在一个独立的文件中，由测试脚本执行到该用例时读取数据文件，从而达到数据覆盖的目的。
5软件自动化测试的优缺点
5.1软件自动化测试的优点
测试活动自动化在许多情况下可提供其最大价值，如对软件进行的功能性测试，是测试系统在做什么，这些测试可以明确知道应该在什么情况下输入什么，会有什么样的输出。通过自动化测试，可以使某些测试任务提高执行效率，除此之外，还有以下优点：
（1）对程序的回归测试更方便。软件测试实行自动化进程是因为测试工作的需要，更准确地说是回归测试和系统测试的需要。由于回归测试的动作和用例是完全设计好的，测试期望的结果也是完全可以预料的，将回归测试自动运行，可以极大提高测试效率，缩短回归测试时间。
（2）可以执行一些手工测试困难或不可能进行的测试。比如，对于大量用户的测试，不可能同时让足够多的测试人员同时进行测试，但是却可以通过自动化测试模拟同时有许多用户，从而达到测试的目的。
（3）更好地利用资源。将繁琐的任务自动化，可以提高准确性和测试人员的积极性，将测试技术人员解脱出来投入更多精力设计更好的测试用例。有些测试不适合于自动测试，仅适合于手工测试，将可自动测试的测试自动化后，可以让测试人员专注于手工测试部分，提高手工测试的效率。
（4）测试具有一致性和可重复性。由于测试是自动执行的，每次测试的结果和执行的内容的一致性是可以得到保障的，从而达到测试的可重复的效果。
（5）测试的复用性。由于自动测试通常采用脚本技术，这样就有可能只需要做少量的甚至不做修改，实现在不同的测试过程中使用相同的用例。
（6）此外，手工不能做的事情，自动化测试能做，如负载、性能测试等。
5.2软件自动化测试的缺点
在软件测试自动化的实施过程中会遇到许多误区，比较普遍的有如下几种：
（1）不正确的观念或不现实的期望。一般来说，人们对新技术的解决方案常常深信不疑，认为可以解决面临的所有问题，对测试工具也不例外。事实上，如果期望不现实，无论工具如何，都满足不了期望。
（2）希望测试发现大量新缺陷。测试运行第一次时最有可能发现新缺陷。如果测试已经运行，再次运行相同的测试发现新缺陷的概率就小得多。
（3）安全性错觉。如果自动化测试没有发现任何缺陷，并不意味着软件没有缺陷，可能测试设计本身就有缺陷。并且，测试覆盖率也不会达到百分之百。
（4）自动化测试的维护性。当软件修改后，通常也需要修改部分测试，这样必然导致对自动化测试的修改，所以在自动化测试的设计和实现时，要防止自动化测试带来的好处被高维护成本所淹没。
（5）测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。
6自动化测试的意义
自动化测试引入的原因是就把软件测试人员从枯燥乏味的机械性手工测试劳动中解放出来，以自动化测试工具取而代之，使测试人员的精力真正花在提高软件产品质量本身。
总之，软件自动化测试还不能解决所有的测试问题，因此，在进行自动化测试前，首先要建立一个对软件测试自动化的认识观。软件测试工具能提高测试效率、覆盖率和可靠性等，但软件测试的自动化过程是一个渐进的过程，并不需要一开始就对所有的测试实施自动化，也通常也是不现实的。自动化测试虽然具有很多点，但它只是测试工作的一部分，是对手工测试的一种补充。因此，如何合理地规范自动化测试，选择适当的测试自动化工具，是测试管理人员必须解决的问题。
参考文献
[1] 贺平.软件测试教程[M].北京：电子工业出版社，2005.
篇3
关键词:存储过程;自动化测试;测试用例;Junit框架;XML
中图分类号: TP311文献标识码:A文章编号:1009-3044(2009)36-10252-02
Research on Automated Testing of Stored Procedure
MA Zhu-gen
(Department of Computer Science and Technology, Huaihua University, Huaihua 418008, China)
Abstract: Stored procedure test is an extremely tedious work.Some database products provide some tools to be able to make the statistics of the execution time of a stored procedure, the number of records and other information, but these tools can not carry on batch and repeated testing. Moreover,the test result is not intuitive. This paper describes the implementation scheme of stored procedure automation test under the junit framework.The code-reuse technique based automatic testing framework of Junitrealizes the regression testing of procedure. The test cases are described and organized using XML to realize the separation between code and data in order to improve efficiency of test, and the test result using XML provides developers with an intuitive notation.
Key words:stored procedure; software automation testing; test case; junit framework; XML
软件测试是保证软件质量的重要手段,软件测试在整个项目开发中所占的比重也越来越大。随着软件规模的扩大和软件复杂性的提高,软件测试技术不断发展,自动化测试技术得到广泛应用,并逐渐成为软件测试发展的方向。单元测试是软件开发过程中要进行的最基本的测试活动,是确保其他测试能够顺利进行的基础。随着增量开发模式和重构技术的发展,软件自动化测试工具JUnit也随之产生。目前Junit已经成为Java程序单元测试框架的标准,已有多种对其进行扩展的自动化测试工具[1]。
存储过程被广泛应用在各种与数据库相关的应用系统中。在开发阶段,对存储过程进行测试是必不可少的工作。通常的测试过程是由测试人员通过命令窗口执行命令,再将命令窗口中的结果信息拷贝下来,保存到一个文件里,在以后再进行分析或者比较。测试工作也可以使用类似Rapid SQL等图形化的工具来辅助做一些工作,但能完成的测试工作量较少。这种大部分依靠手工进行的存储过程的单元测试存在很多缺点,如测试效率低,无法重用,无法进行自动化的回归测试,没有直观的测试结果,需要程序员手工整理测试结果并生成测试报告。针对这些问题,本文在Eclipse中利用Junit测试框架来实现存储过程测试的自动化。
1 Juit的框架结构
Junit是Erich Gamma和Kent Beck编写的一个回归测试框架,它是一个Java程序自动测试的框架[2],用在软件测试的单元测试阶段,即Java对象类的功能测试。JUnit共有七个包,核心的包就是junit.framework和junit.runner。Framework包中包含了Junit测试类所需的所有基类,它是整个Junit的基础框架[3],负责整个测试对象的构架,Runner则负责测试驱动。JUnit框架中主要有以下几个对象类[4-5]:
1) Assert类,它提供在编写测试时要用到的所有assert方法。当条件成立时assert方法保持沉默,但若条件不成立就抛出异常。Assert类是TestCase的父类。
2) TestCase类
客户测试类所要继承的类,负责测试时对客户类进行初始化,以及测试方法调用。类中的主要方法有:setUp()用于如变量赋值等测试的结果处理,tearDown()用于如文件关闭等测试的结束处理,run()测试实例的执行,并把测试结果放入测试结果对象TestResult中。
3) TestResult类
负责收集TestCase所执行的结果。一般来说,用户不需要对TestResult进行操作,测试结果由系统提供的测试工具自动输出。
4) TestSuite类
TestSuite对象是测试实例的集合,负责包装和运行所有的TestCase。
2 存储过程测试代码的自动生成
Junit测试的实现流程就是继承TestCase类,然后重载它的一些重要方法,如setUp()、tearDown(),最后将这些对象组装到一个Testsuite对象中,交由TestRunner来运行。为了利用 JUnit 带来的高效率,首先需要改变被测存储过程的调用方式,即从手工调用改为使用 JDBC 来调用,把一个个存储过程的调用写成Java 代码,以后需要进行回归测试时,只需要运行这些 Java测试代码就可以了。但是直接使用 JUnit,也会是一个烦琐的过程,因为必须在每段测试代码中编写连接数据库的代码和调用存储过程时的一大堆参数设置的代码。对于存储过程测试来说,这些代码就显得非常累赘了,于是设想把这些操作封装为一个公用的类,只需要在测试代码中提供数据库连接信息、存储过程名字和参数值就可以了,其他的工作由这个公用的类来处理。因此在实现存储过程测试代码的自动生成过程中,首先必须要解决如何获得存储过程名和存储过程参数以及在生成的测试代码中如何运行存储过程,下面分别进行讨论。
2.1 存储过程名和参数的获取
在存储过程测试代码生成过程中,第一个问题是要针对哪些存储过程生成测试代码。获取存储过程名可以有两种方式,其一是由用户手动指定,其二是将储过程名称保存在文件中,由系统自动从文件中分析出存储过程名称。这样的文件可以是一个定义了 Java 常量的 .java 文件,也可以是一个 .properties 文件。文件中可用"="来定义存储过程,系统将自动把"="右边的部分识别为存储过程的名称。
要为存储过程自动生成测试代码,有一个前提条件是被测试的存储过程已经在数据库中创建。作为数据库的对象,存储过程的名称、参数等信息也都有相应的数据字典表存放。只要知道存储过程的名字,可以查询数据字典来获取存储过程的参数信息,如参数名称、数据类型、长度、出入参类型等。因此,在测试代码生成过程中可以根据存储过程的名称查询数据库的系统表来获取参数信息,例如DB2 的 SYSCAT.ROUTINEPARMS表,Oracle 的 USER_ARGUMENTS 表或者SQLServer的SYSCOLUMNS 表等。
2.2 测试代码中存储过程的运行
在已经生成的测试代码中,如果将大批的数据库操作写在测试代码中显然是不合适的,这样会造成代码的混乱和维护困难。因此考虑封装一个类,用它专门来运行存储过程,它提供了以下主要方法:
1) SPProcesss (DBInfoObject dbConfig), 构造函数,根据传入的数据库配置信息,建立数据库连接,初始化运行环境;2) getSPParmList(String routineSchema , String routineName) 根据存储过程模式和存储过程名获取参数列表;3) runStoredProcedure(StoredProcedureInfo spInfo) 运行存储过程,存储过程信息包含在名为 StoredProcedureInfo 的类中。4) String (getDurationTime) 获取存储过程运行时间;5) object getReturnedObject (int parmIndex)获取存储过程输出参数的值。
其中的 StoredProcedureInfo是记录存储过程信息的类,包括存储过程名、存储过程参数列表等。因此,只需要首先创建存储过程信息,然后调用 runStoredProcedure 方法即可运行存储过程。而这部分代码也是自动生成的,程序员真正需要做的就是修改调用参数的值。
3 改进的Junit框架
采用Junit作为单元测试工具有许多优点,但也存在着不足。在实际的单元测试中,发现JUnit产生的测试代码量是庞大的。为了提高测试代码的复用,文献[6]提出了一种改进的自动化单元测试框架。该框架设计的核心是实现测试用例与测试代码的分离,运用XML文件作为测试数据存储的容器,把每个测试用例中的数据装入到对应的JavaBean中,最后构建一个JavaBean对象为元素的ArraList来存储所有的测试用例。测试执行时,测试代码只需要从ArrayList里面取得测试用例的数据,测试代码仅仅完成验证任务。这样,如果测试用例增加了,只需修改相应的XML文件,而不必再修改测试代码,就可完成相应的测试。
借鉴文献[6]的方法,本文将测试用例和测试结果都存储为 XML 文档,使用方法writeToFile(String fileName, String time,ArrayList testResultList)将测试结果保存在XML文件中,测试结果可以包括存储过程运行的时间、返回的记录数、调用的参数列表或者出错信息等。选择把测试结果保存为 XML的一个重要原因是通过简单的 XML编程即可实现对历次的测试结果的比较分析。其实现方法就是将测试结果的XML文件命名为 TestCaseName_年_月_日_时_分_秒.xml,每次运行测试例后,都生成一个具有时间戳的测试结果文件,例如:
testSP_2009_10_18_17_27_00.xml
testSP_2009_10_18_17_30_00.xml
testSP_2009_10_18_17_32_00.xml
通过比较这三个文件中同一个存储过程的运行耗时、返回记录数等指标就能知道这次的测试结果比上次是否有所改进,或者系统在不同时间点的性能变化情况。
有了JUnit 测试代码之后,在 Eclipse 中,左键双击将要运行的 Java 文件,选择 Run As->JUnit Test 就可以在工作环境中运行测试文件了。运行完毕后,会生成一个XML文件,再配合以XSL样式文件,就可以在浏览器中看到美观的测试报告了。
4 结束语
Junit和Eclipse两种软件的源代码都能从网上免费获得,利用Junit基于XML存储测试数据和测试结果的新测试框架真正提高了测试效率,简化了测试步骤,从根本上提高了测试代码的重用性。利用JUnit实现了以往存储过程测试中很难进行的回归测试,利用XML技术实现了测试数据和测试代码分离,提高了测试效率,为开发人员提供了直观的测试结果。
现有的测试框架可以扩展到Cactus(Apache Software开发的用来对服务器上的Java代码进行测试的框架)框架上,实现从浏览器进行存储过程测试用例的调用执行,可以克服因为开发和生产环境之间可能存在的网络、安全等因素而影响测试准确性的问题。
参考文献:
[1] 余波,王树林,张大方.基于Junit自动生成类测试案例框架的实现[J].计算机工程与应用,2006,42(1):89-91.
[2] 王东刚.软件测试与JUnit实践[M].北京:人民邮电出版社,2004.
[3] 孔亮亮,殷兆麟.Java类测试工具Junit的分析与扩展[J].计算机工程与设计,2005,26(12):3413-3415.
[4] 何成万,余秋惠.用JUnit实现Java程序自动测试[J].计算机应用,2002,22(3):93-94.
篇4
关键词:自动化测试;测试仪器;整体化测试平台框架
中图分类号:TP311文献标识码:A
文章编号:1009-2374 (2010)22-0024-02
1自动化测试简介
自动化测试的出现可以大大减少测试开销,同时大幅提高有限时间内的测试覆盖率。成熟的自动化测试机制,是可重复的、极少的人工资源投入的,可以做到“即使最小的改动也可以以最小的代价进行全面的测试”。
但是,在自动化测试实施与推广过程中,常常会因为自动化测试手段与工具的多样化与不统一化对自动化测试件设计/开发效率的影响等,导致自动化测试无法有效地推广开来。
本文通过对数据通信领域的自动化测试平台的探讨,寻找到一种更好的搭建自动化测试平台的方法,提高自动化测试效率。本文提到的实现方法,是以数据通信领域产品的自动化测试为例进行阐述与实际实现的,其他领域的软件自动化测试可以依据自身的特点与情况对此进行一些修正与改造。
2自动化测试实现的常见问题
在通常的自动化测试实现中存在着一些常见的差异性:
自动化测试所使用的测试仪器或工具不同,如:使用PC作为测试工具,或者使用数通领域通用的测试仪器(如:思博伦公司的SmartBits或IXIA公司的IXIA测试仪)作为测试工具。
测试环境(或拓扑)不同,如:有的自动化测试环境为单台被测设备,有的需要多台辅助测试设备,所实现的自动化测试方法也相应有所不同。
2.1基于PC的自动化测试
由于业界有许多基于PC的开源工具或者工具包的支撑,因此在PC上编写各种测试工具与测试软件是一件相对方便且资源丰富的方法。基于PC的自动化测试,主要完成一致性/功能测试与部分性能测试。但由于PC功能较为单一,无法很好地模拟网络的组网方式,因此常见的解决方法是通过PC对实际的组网进行测试,可以进行实际测试效果。
该测试方式的优点是较为直观,自动化测试实现简单易行。但由于不同测试用例的组网环境不同,切换用例需要手动改变组网,自动化无法连续进行,因而完成一系列测试需要相当长的时间,而且回归和重现较为困难。另外,错误故障定位困难,由于测试时使用了不同的辅助设备,出现故障时,具体哪一台设备出现故障难以确定。
2.2基于测试仪器的自动化测试
在数通测试领域,所使用的测试仪器一般都提供了强有力的自动化测试接口支撑,因此可以基于这些接口开发适用于被测设备(系统)的自动化测试软件。
该测试的优点是能够更好地进行路由仿真和性能测试,如OSPF(开放式最短路径优先)协议的收敛时间测试可以模拟任何组网,组网结构可以可视化地改变,并以协议报文的形式反馈到被测设备。
其缺点在于无法深入到具体协议的内部实现交互过程的测试,大多数的软件bug都集中于协议交互过程,导致测试覆盖率不高,需要一致性测试作为补充。
2.3自动化测试的管理
随着自动化测试规模的不断扩大,带来的自动化测试脚本管理、维护困难也会越来越突出。如何管理自动化测试,也成为一个大家愈发重视的问题
3整体化自动化测试平台的设计
3.1测试环境的整体化
自动化测试的组网环境的简化,可通过PC的网络接口模拟实际的路由和交换设备,使用一个单独链路作为被测设备配置链路,专门配置被测系统。测试链路用于测试报文收发,被测设备配置和报文收发和编解码通过脚本控制
配置链路:测试PC通过配置链路对被测设备进行控制,这样的配置链路可以是带内(如:PC的控制口),也可是带外(如:Telnet/HTTP等方式)。
测试链路:通过PC的网卡与被测设备通讯,在PC上运行各种模拟数据通信设备或协议的软件,来达成减少测试环境中的测试设备的目的,所需模拟的测试设备多的时候可以增加PC的网络接口。
这里提到的模拟数据通信设备的软件,可以是一些来自于已有的商用或开源软件,也可以是自行开发的一些测试软件。这些工具与特定应用相关,可以在实践过程不断地扩充。
测试环境的整体化,对于一些不可避免的需要组网环境的测试,目前业界已经有一些比较常用的拓扑切换方法,如使用带拓扑切换功能的网络互连设备,通过对这样的拓扑切换设备的自动化控制、操作来实现不同逻辑拓扑的切换功能,本文不做进一步的细节阐述。
3.2测试工具的整体化
PC测试可以细化编解码和能够进行一致性测试,具有较强的测试覆盖率,测试仪器测试具有能够进行性能测试、物理网络仿真的优势。二者结合后,可以达到通过PC实现协议交互过程,通过测试仪器在这些交互过程中进行所需的测试行为注入。
运用测试仪器提供的扩展命令接口,PC通过脚本控制测试仪器端口协议报文的流量发送,批量统计。同时可通过PC控制网卡适配器报文的收发,进行功能测试等。物理拓扑搭建图如图1所示:
如图1所示,测试PC充当了两个角色:
被测设备控制者:PC通过控制链路对被测设备进行配置、操作等控制。
测试仪器操作者:测试PC同时通过测试仪器提供的自动化测试接口,实现对测试仪器的自动化控制。
测试链路中存在2种测试方式:
测试PC对测试设备的测试链路:通过在PC上运行各种自动化软件,来实现对被测设备的测试,如报文收发、协议模拟等。
测试仪器对测试设备的测试链路:自动化测试程序通过调用测试仪器提供的测试接口,实现对被测设备的各种测试操作,也包括报文收发、协议模拟等。
通过对两者的有机结合,可以将测试PC对测试设备的测试链路与测试仪器对测试设备的测试链路进行统一控制,从而实现二者的交互。
3.3自动化测试管理的整体化
构造整体化的测试平台,除了自动化测试本身外,还兼具测试用例管理、测试用例编辑、测试用例执行、测试结果分析与测试结果统计反馈等功能。将整个自动化测试实现、使用、管理的过程统一在一个平台上实现。
3.4整体化测试平台框架
本章节讨论整个整体化测试平台如何进行构建,形成整体统一的测试平台框架。
3.4.1框架构成整体化测试平台框架包含如下功能支持:自动化测试脚本编辑环境。脚本编辑界面,包括各种基本的编辑功能,语法美化、关键字识别、关键字自动提示等辅助功能。
(1)测试脚本调试环境。自动化测试脚本的调试器,可以通过集成当前通用的调试环境与工具来达成。
(2)测试管理界面。测试工程建立和管理:建立测试工程项目,生成相关的工程组织文件,并可添加/移除已编辑好的测试脚本和测试配置文件。测试参数设置和参数脚本生成:配置测试过程所需的参数,并生成相应的配置脚本文件。当测试环境改变时,测试人员只需更新相关参数。测试例执行规则设置:设置测试例执行的规则,如在何种条件下终止测试执行过程,测试过程希望察看的信息,测试用例按何种顺序执行等。测试用例脚本,用例描述,拓扑的映射关系维护:测试人员可以根据用例列表,查看用例描述,物理和逻辑组网图。测试结果的记录和日志生成:对于测试失败的用例,记录错误的日志。测试结果处理:测试结果的查询,并提供同问题记录系统的接口,使得测试结果能够及时上报;同时,也可视需求决定是否提供E-mail、短信等实时通知功能。
(3)测试执行操作界面。提供测试控制的界面,测试开始,暂停,继续,停止等。
测试过程监视:在窗口界面显示测试例执行的结果和统计,指定类型的协议报文的收发过程和编解码等信息。对各种信息划分等级,测试人员可以在测试执行过程屏蔽/显示某一级别的信息。支持测试人员定义多个窗口显示不同类型的信息。
(4)公用支持库的支撑。提供自行定义的一套自动化测试公用库,其基础构成包括:被测设备的控制库:用于控制不同的被测设备,将相同的操作归类,提供统一接口。报文收发的通用库,这里的报文收发可以通过PC网卡实现,也可通过测试仪器实现,目的是为不同的测试手段提供统一的接口。函数报文缓冲操作接口:提供一组申请、释放和访问内存缓冲区的命令,用于支持协议报文的编解码,以及协议报文编解码命令。利用报文缓冲区管理命令实现特定协议编解码的过程。扩展接口规范的定义和扩展开发库的提供:为后续新的协议支持或新的操作支持,提供兼容性以及统一的命名规则要求。
3.4.2框架实现简述本文给出了具体框架的搭建模型和为实现相应的功能需要完成的内容,具体的实现平台、方式可依据所需自动化测试环境的不同而变化,譬如:平台运行的操作系统、实现平台所使用的编程语言等等。笔者在实践过程中,是在Windows操作系统下的使用C#进行工具实现,完成了对测试PC、思博伦公司的SmartBits测试仪器,以及被测设备的自动化测试。
在实际实现过程中,可以依据当前系统的自动化测试程度与水平,通过逐步叠加的方式来逐步实现框架中的不同功能。譬如:其中提到的自动化脚本编辑环境、测试执行失败记录的分析、测试结果的统计等功能,可以随着自动化测试资源投入的增大,对自动化需求的增多,而逐步增加开发,并不一定需要一步到位地实现所有功能。
本文从数据通信领域自动化测试实现常见的一些问题入手,通过构建一个整体化的,不依赖于自动化测试实现方法、实现手段的自动化测试平台与工具,以期达到解决这些常见的问题,提高自动化测试实现效率,改善自动化测试管理方式的目的。
参考文献
篇5
关键词：软件 测试 自动化 技术
中图分类号：TP311.5 文献标识码：A 文章编号：1007-9416（2016）06-0234-01
软件测试技术从传统的手工测试逐步发展为现在的自动化测试技术。手工测试往往需要技术人员付出大量的精力和体力，是一项工作量极大的过程。如今随着社会的高速发展，信息技术的突飞猛进，软件领域的竞争趋于白热化，软件正在向着复杂、尖端、多元化方向发展。大量的软件程序开发出来，仅依靠效率低下的手工测试已经远远不能达到人们的需求。为了适应市场，自动化测试被开发出来，自动化测试的诞生极大的提高了工作效率，是测试用例的生成软件测试是软件质量保证的重要手段，也是目前软件测试的发展方向。
1 软件测试自动化基本概述
从上世纪六十年代开始人们就对软件测试就行了研究，至今己有50余年的历史。测试顾名思义就是对所开发的软件产品进行检查、评审和确认等过程，是对软件产品质量所进行的自检和自评。
（1）软件测试的概念。软件测试是软件开发的过程中重要的一环，其工作一般是事先安排好工作计划，然后较为全面系统的进行测试工作。是对软件产品进行的自检。该活动伴随着软件开发的每一步进行。通过软件测试，可以检测出软件在运行过程中存在或者潜伏的各种错误或者缺陷，从而为开发者提供数据依据。
（2）软件测试的种类。软件测试的分类方法有很多，比如按软件开发过程可分为单元测试、集成测试、系统测试及验收测试；按软件动作可分为升级变更的测试、重现故障测试、己有功能的测试、回归测试、兼容性测试及恢复测试、安装/卸载的测试等等；按测试方法，又可以分为黑箱测试及白箱测试；按用不用借助软件，可以分为手动测试和自动化测试。
（3）典型的软件测试问题。由于软件系统的复杂性和不可预测性，在软件测试过程中可能会出现一些问题，主要问题可归结为以下几个方面：项目存在风险性，在项目晚期才能真正降低；项目进度不易预测，加之项目负责人对所开发软件实际状况的了解程度不够，造成管理上的问题。开发经费较高，如果在测试过程中错误没被监测出来，后期的软件错误修复费用会极高，同时也会造成整个项目的延迟，可能会导致开发项目成本的大幅度增加，据统计，近些年由软件开发失误所造成的经济损失每年高达几百亿美元。
（4）自动化测试。测试自动化作为一种测试技术，通过设定的机制，可以自动对被测系统进行测试。测试自动化以较低的费用、彻底的测试、较高的产品质量作为目标。实现软件测试自动化的趋势己经不可逆转了。自动化测试主要采用自动化工具提供的测试脚本对目标应用程序进行测试。自动化测试具有速度快、测试效率高、可靠性强、测试覆盖率高通用性强、风险低信任度高、完成手工测试不能或难以完成的测试等特点。虽然自动化测试具有很多优点，但是其不是万能的，也有其自身的局限性。
2 软件测试自动化关键技术
（1）测试用例自动生成技术。测试用例的自动生成是实现自动化的关键所在，靠人为以及手工的方式产生测试用例是较传统的方式，花费时间较长且质量不高，会有人为因素造成一定的错误，而自动生成的测试用例就可以避免此问题的生成。目前有面向路径的测试用例及面向功能的测试用例两种技术。面向路径的技术是针对程序的内部结构的，需要对程序的逻辑路径达到一定程度的覆盖，是基于覆盖的测试用例生成技术，通过覆盖程序中所有路径，找到程序的中隐秘的错误。面向路径的方法主要有动态法、静态法、随机法及动态法。面向功能技术是以规格说明书作为支持，并根据说明书的需求生成相应的测试用例。面向功能技术可分为基于模型的、基于代数的以及基于有限状态机的等。测试用例自动生成相关算法主要有遗传算法、蚁群算法及粒子群算法。目前混合蛙跳算法在测试用例自动算法中也开始使用，此方法是一种全新群体智能算法，结合了模因算法和粒子算法两者的优点。
（2）捕获/回放。自动化测试使用的主要手段之一是捕获/回放。技术人员通过对脚本进行捕捉回放，完成脚本的录制工作。其主要记录内容为所开发软件的系统结构组件，以及所开发软件对测试的具体操作步骤。测试结果一般是以文本格式存放。捕获/回放一般有三种特定级别，即操作系统级别、硬件级别和进程级别。
（3）自动化测试模型选取。自动化测试模型一般可以分为三种，即合并式、独立式及顾问式。其模型主要是为了在组织中实行自动化测试服务。合并式模型：主要工作有设计、开发、执行以及提交等。测试自动化工程师会参与到手工测试人员的每一项工作中，辅助其完成测试工作。独立式模型：一个核心的测试自动化组负责进行自动化测试项目生命周期中的所有活动。这个小组要完成从自动化测试套件开始设计到间的所有任务。在顾问式模型中，负责给手工测试工程师培训关于测试工具，测试方法的知识并为执行和巩固活动提供基础设施。
无论选取哪个模型，其最终的目的都是为了增加工作效率，提高软件检测过程的自动化水平。专门的测试自动化工程师被分配到每个测试项目中和手工测试人员一起工作，共同分担着测试自动化项目的相关活动。在整个测试流程中，自动化测试工程师与手工测试工程师对需要进行自动化的测试用例进行研究讨论，对原有的手工测试用例进行拆分使其符合自动化测试的需求。
3 结语
软件测试是为了发现软件错误以及潜在缺陷的过程，是保障软件质量的关键技术之一。软件自动化测试是软件测试的一个重要组成部分，它可以完成许多手工测试无法实现或者难以实现的测试。对软件测试自动化关键技术的分析具有很重要的意义。
参考文献
[1]傅兵.软件测试技术现状与发展趋势研究[J].电脑编程技巧与维护，2016（02）.
[2]林平荣.高校软件测试自动化教学平台的搭建[J].电脑知识与技术，2010（28）.
篇6
【关键词】软件 自动化 应用研究 测试
一款软件从开发到，除了软件设计编程之外，软件测试也是不可或缺的一项中心环节。软件测试在以往都是软件开发人员自己检测，但程序员却无法将充足的时间用来测试，所以后来发展为软件开发与测试两者独立，测试部分由测试部门负责。但这个过程人力物力消耗大，时间长，所以软件自动化检测技术也就应运而生。
1 软件自动化测试
1.1 软件自动化测试的概念
软件的自动化测试是一种新的软件测试技术，根据需要，可以将测试系统的运行环境进行调整，然后按照测试要求与目的设置相关程序功能，然后由系统按照设置好的程序对需要进行测试的软件测试。其运用主要地方为：软件开发完成后的测试以及维护测试。
1.2 软件自动化测试的目标
通过软件自动化测试技术进行新软件测试，可以达到：用最少的经费，取得更完整彻底的测试结果，从而根据测试结果进行软件的再修改，以此来提高软件的质量。
1.3 软件自动化测试的特点
较传统的人工测试而言，软件自动化测试具有如下特点：
1.3.1 在软件版本升级后，进行再测试
其实这一点是这项检测技术最基本也是最核心的任务。当一个软件需要进行版本升级时，为了测试新版本软件的性能，那么人工软件测试与自动化软件测试就无可比拟。版本更新周期短，不具有开发阶段周期长这一特质。所以，利用软件自动化测试技术，在省却大量测试时间的同时，还可以加快新版本测试进度，降低版本升级的费用。
1.3.2 可持续测试
软件自动化测试技术的另一大特点就是其可持续测试性，自动化测试只要机器运行，就可以一直测试下去，而手工测试却无法具备测试持续性。这是人力测试无法解决的劣势。
1.3.3 多任务性
人力有穷时，对于简单软件系统，人工测试还能胜任，但遇到诸如多元网络传输系统，依靠人力对系统测试，是行不通的。但自动化软件测试技术却可以胜任，其可以同时对这些网元进行仿真模拟测试。所以，自动化测试具有多任务性。
1.3.4 人力资源利用率高
通过自动化软件检测技术，可以将更多地人力资源解放出来，让有限的人力资源不再陷入繁琐的测试当中。利用自动化检测软件可以让工作人员只需要思考测试的目的，设计更好地测试方案，控制好测试软件即可。
1.3.5 测试进程具有稳定性
利用软件自动化测试技术，可以将测试的环境保持稳定一致，可以规避人力测试因外界因素影响测试过程，导致测试结果不准确这一问题。
1.3.6 测试过程与结果可做范例
软件经过自动化测试之后，测试软件就会将测试信息记录下来，作为范例，当遇到相似测试项目时，这些信息也可以作参考或直接使用。这也是人力测试所不具备的。
1.4 软件自动化测试所需技术
一款自动化测试软件，其需要具备这几样必须条件：被测软件信息输入部、测试结果输出部分以及多次测试结果对比部分。具备这三大部分，测试软件才能实现自动化测试。
1.5 软件自动化测试的不足
软件自动化测试，其优点甚多，但并非万能。自动化测试任然存在一些不足之处，这些都是自动化测试技术所无法具备的：
1.5.1 无法完全替代人工测试与测试工程师
有许多测试任务是自动化测试软件无法完成的。这时候就需要用到人力测试以及测试工程师了。对于简单的软件测试，依靠人力测试即可解决，而不需要检测软件参与，检测软件每次测试，都需进行系统调试，对于简单的测试，其调试时间与人力测试时间相当，这类情况检测软件的使用就不合时宜。还有一些类型也是软件测试所无法替代的，例如：被测软件运行不稳定，这时就需要人力进行测试，这样方便调节。还有有一些需要人机交互的测试，测试软件是一种设定好的程序，对于需要实时进行人机交互的测试来说，其自动化测试无法做到随机应变。所以，自动化软件测试是不能完全替代人工测试的。
1.5.2 软件新版本的再测试没人工发现bug多
自动化测试软件的一大好处就是可重复测试，但当使用以往测试数据来测试同软件的新版本之时，自动化软件检测所发现的bug往往会低于人工测试所发现的bug。
1.5.3 自动化软件检测对软件开发存在一定制约
由于自动化软件测试程序相对固定，当一些被测软件有重大更新时，往往由于测试程序无法与新版本做到兼容，从而导致测试软件崩溃。而自动化测试软件的再设计与维护成本会比人工测试高，且自动化测试比人工测试影响要高，所以会对开发人员造成影响，综合以上因素，会对一些被测软件的重大更新部分造成修改限制。
所以，合理安排软件自动化测试与人工软件测试，将会更利于开发人员降低开发成本，减少测试时间，获取高效益。
2 适合软件自动化测试技术的领域与辅助测试工具
2.1 适用范围
目前的软件自动化测试适用于：单元/组件测试、BVT（版本测试）、集成测试、系统测试、回归测试以及性能测试。
2.2 软件自动化测试与人工测试使用环境总结
软件自动化测试：该被测软件项目无严格时间限制，有良好测试计划与测试目的，测试内容涉及多平台，涉及被测软件运行所需硬件，被测软件可以使用自动化软件进行测试等这些情况下都可以使用软件自动化测试。
人工软件测试：没有严格测试时间限制，没有明确的测试目的与计划，开发人员或软件测试人员当中不会操作软件自动化测试的，刚加入开发的新成员，没有相关硬件等等这些情况就不是自动化软件测试所能达到的。
2.3 软件自动化测试所需工具
在软件自动化测试进程中，还需要一些工具辅助软件测试，目前按照使用环境可以分为：
2.3.1 管理型工具
管理型测试工具主要是对软件测试的计划、用到的测试用例、测试所需以及测试进程进行综合管理，同时还能通过这些管理型工具发现自动化测试所存在的漏洞，并就这些测试漏洞进行管理跟踪。而软件的开发者和软件测试人员能够通过管理工具对被测软件信息进行交流。
2.3.2 沙盒工具
所谓沙盒测试工具，就是在独立环境下，对被测软件内部代码进行逻辑流程测试；而在测试中可以发现被测软件的漏洞，并且能够将这些缺陷定位，最高可定位至代码级。
2.3.3 用来分析被测软件在静态环境下的工具
静态软件分析工具可以对被测软件代码直接扫描，在不需编译的情况下进行测试分析。静态软件测试分析工具主要使用在：（1）代码；对被测软件进行语法扫描分析，找出代码编写错误的地方。（2）对被测软件静态情况下分析其结构，静态测试工具会根据被测软件代码结构复杂程度，对软件代码的设计与模块调用生成记录图表。
2.3.4 被测软件动态环境运行分析工具
相对静态软件分析测试工具而言，动态分析工具的工作方式是利用钉钉子的方法，在被测软件代码中插入一段检测代码，这段代码会在被测软件运行时，对软件数据与资源调用率进行统计分析。
2.3.5 功能测试分析工具
功能测试分析工具也可以称之为黑盒工具，其工作流程是通过自动记录被测软件数据、检测以及回溯客户操作。通过对被测软件测试前所预测结果进行对比，从而帮助开发人员与测试人员对不同版本的软件进行功能测试分析，提高工作人员工作效率。黑盒工具其主要目的是：通过测试分析被测软件程序能否达到预期设计目标以及稳定运行。
2.3.6 软件性能测试分析工具
性能测试分析工具的目标是：分析测试被测应用软件的可扩展性能。在测试过程中，通过性能测试分析工具可以帮助测试人员检测软件运行性能以及查找运行时所出问题。并且就检测出的问题进行自动性能优化，保证应用软件能够正常进行测试运行。
2.3.7 辅助工具
这一类的测试工具其本身并不具备测试所需条件，辅助工具存在的目的就是将软件测试过程中所搜集的数据信息生成记录，为测试人员提供参考依据。
根据软件测试过程所需工具，正确使用这些测试分析工具可以帮助测试人员更快，更高效完成软件测试任务，缩短软件周期。
3 合理设计软件自动化的测试
3.1 设计中应当规避的情况
合理的自动化测试设计，可以提高工作效率，所以，在设计自动化测试时，应注意规避以下几种情况：时间限制，没有明确的测试目标，测试经验不够多，测试人员流动性高，对测试失去耐心和太偏重技术等。
3.2 测试软件设计注意事项
在设计自动化测试软件时，有几点需要重点设计：
3.2.1 测试软件的可维护性
过高的设备维护成本将会大大降低自动化测试软件的实际应用性，所以，在设计自动化测试软件的时候，软件的可维护性是其中一大重点考虑对象。目前的自动测试软件领域竞争激烈，而要想获得高的市场占有率，那么具有低维护成本的测试软件将占有极大优势。维护包括测试软件的日常维护以及测试软件的版本更新，其中版本更新维护是维护重点。随着软件开发的深入，软件自动化测试需要紧跟开发者的步伐，当测试软件无法满足测试需要时，那么自动化软件将会逐渐丢弃淘汰。所以，保持更新步伐是需要重点考虑的。
3.2.2 可测性
可测性就是自动化测试对被测软件的测试是否有效。所以，为了保证软件的可测性，设计时应当使用拥有：CLI、API与GUI接口的测试软件。
4 自动化测试与人工测试对比
自动化测试与人工软件测试，其区别只是测试方式不同而已。从以上文章分析可以知晓自动化软件测试其优点突出，但不足之处也是显而易见。
自动化测试其根本性目的是将以往人工测试的过程精简化、程序化和标准化。在一定程度上可以代替人工进行软件测试。自动化测试的优点在于：自动化软件测试可以按照软件测试需要进行相应程序修改，然后利用符合测试需求的测试程序进行测试，在这过程中，相对简单的测试部分可以依靠人工测试，对于那些有重复性，测试过程严谨的测试部分则可以利用自动化测试，达到测试目的。综上，可以对软件自动化测试与人工测试进行一个对比，首先是人工测试：
人工测试是一开始就使用的测试方式，人工测试需要测试人员有丰富的测试经验。对于相对简单的测试目标具有速度快，效率高的特点。尤其是在相关的人机交互测试这类灵活度较高，测试过程不可控的测试目标，人工测试具有快速反应，测试灵活等特点。相应的，人工测试也存在很大的弊端，人工测试人员受精力与时间限制，对于那些时间短、测试过程程序化与复杂化的测试目标，人工测试就需要耗费大量时间与人力资源来完成。这也导致了测试成本提高，效率低下。
软件自动化测试与人工测试相比，自动化测试是按照测试程序对被测目标进行测试。所以对于那些重复性测试具有高效，测试过程严谨的特点。其所具备的强大数据处理能力对于那些测试过程中需要进行大量数据处理运算的测试任务具有高效的完成性。但其缺点也是明显的，对于那些需要进行实时交互的测试目标来说，自动化测试的固定测试程序是无法胜任的。
综上分析可以看出，人工测试与自动化测试之间有着明显优缺点，但两者也具有良好的互补性，所以合理搭配这两种测试方式，将会极大提高测试任务的完成效率，有效降低测试成本与人工测试资源。
5 结束语
本文从软件自动化测试的意义到应用进行了简单讨论分析，从各方面对比来看，软件自动化测试在软件测试行业中占有重要地位，在未来的发展中，应当加大对自动化测试的研究力度。让自动化测试继续发挥更大的作用。
参考文献
[1]应杭.软件自动化测试技术及应用研究[D]
[2]刘艳霞.软件自动化测试技术应用研究[J]软件导刊.2007，5：36-38
[3]蔡志贤.软件自动化测试的研究与实践[D]
[4]陈晓.软件自动化测试的分析与实践[J]计算机科学.2008.35（4）：282-322
[5]季淑引.软件自动化测试工具的应用研究[J]科技向导.2012.20：59
[6]陈哲.软件自动化测试系统的研究与实现[D]
作者简介
张维利（1978-），男，山东省人。硕士学历。主要研究方向为信息系统软件测试、软件可靠性等。
篇7
本文分析了虚拟仪器的特点，将模块化设计思想引入到虚拟仪器的设计中，把分散、独立的传统仪器整合起来，设计出了满足现有产品需求的液晶显示器主板自动化测试系统。
【关键词】液晶显示器 自动化测试 虚拟仪器 仪器控制
随着现代科学技术和现代工业生产的发展，对电子类产品测量和仪器技术的要求越来越高，测试对象和测试内容日益复杂，测试工作量与日俱增，对测试速度和测试精度的要求也不断提高，这使得传统的人工测试已经不适应甚至不能满足实际测试的需求。因此，自动化测试技术成为了测控领域的重要发展方向之一。
1 国内外市场状况
自动化测试系统的研制工作最早可追溯到20世纪50年代，美国为解决军方在军用电子设备维护中遇到的问题而开展了SETE计划。现代测试内容日益复杂， 测试工作量激增，而且要求完成测试的时间越来越短，人工测试很难满足这些要求，自动化测试技术因而得到迅速发展。较完善的自动化测试设备是 60 年代采用电子计算机以后才问世的。
自动化测试设备的发展经历了三个阶段：
（1）采用专用测试系统：这种测试主要用于小型化的工业测试，但不管是在接口上还是总线上，都没有任何标准可言，因此也谈不上通用性。
（2）台式仪器积木型测试系统：采用标准化通用接口母线（GPIB）连接有关设备，系统中各组成部分均配标准化接口功能，用统一的无源母线电缆连接起来。不需要自行设计接口，可灵活地更改、增删测试内容。计算机主要承担系统的控制、计算和数据处理任务，基本上是模拟人工测试的过程，尚不能充分发挥计算机的功能。
（3）智能化测试系统：将计算机与测试设备融为一体，用计算机软件代替传统设备中某些硬件的功能，能用计算机产生激励，完成测试功能，生成测试程序。
2 研究内容
基于以上探索，本文将深入研究以下几个问题：
2.1 测试系统总体模型设计
将虚拟仪器与传统仪器的特点做对比，找出虚拟仪器在液晶显示器主板测试方面的优势，把模块化设计思想引入到虚拟仪器的开发中，综合分析现有的硬件测试表单，设计、抽象出一种能满足现有测试要求的设计模型。
2.2 多功能测试系统平台搭建
在研究传统仪器功能和操作基础上，将分散的、独立的、具有单一功能的传统仪器，用独立总线技术与计算机通讯接口建立连接，使单个仪器成为整个总线上的一个结点，从而搭建成一个符合目前液晶显示器主板测试要求的多功能自动化测试系统。
2.3 系统总体调试和改进
在完成液晶显示器主板测试系统平台搭建后，在LabVIEW平台上对整合后的虚拟仪器软件系统进行测试，发现并修改其中的错误，直到其能正常无误地运行。最后，再将自动化测试的结果与传统仪器测试结果进行比对，进而对测试系统进行修正和改进。
2.4 测试数据智能处理
仪器直接采集到的测试数据，常常由于外界干扰造成数据不准确，或是单次抓到的数据不具有代表性，而造成得到的数据无效，不能满足实际产品需要。为了过滤这些无效的测试数据，需要用其它手段对测试的数据进行智能处理，生成有效数据，再将测试的数据处理并写入电子表格文件，生成测试报告。
3 技术路线
本课题的基本思路为：根据目前液晶显示器主板测试要求和现有的测试表单，拟定系统需求方案书，抽象出系统总体模型。再选择合适的总线和PC机，搭建硬件通讯平台，实现对仪器的控制，然后设计自动化测试软体前台界面和后台代码。最后，将硬件平台与软件系统整合并调试，从而完成整个自动化测试系统的设计。
本课题可分为三大模块，分别是TDS-3054示波器及Chroma 2325信号发生器控制模块、液晶显示器主板自动化测试模块和测试数据智能处理模块。系统总体框图如图1所示。
4 结论
通过把虚拟仪器与传统仪器进行优缺点对比，将模块化设计思想引入到虚拟仪器的设计中，把分散的、独立的传统仪器整合起来，设计并抽象出了满足现有产品需求的液晶显示器主板测试系统模型。利用LabVIEW图形化编程软件，在分析并总结现有产品测试表单的基础上，开发出了符合要求的液晶显示器主板测试平台，包括自动化测试模块和电子表格报告生成模块。
参考文献
[1]赵洁，张璐，李桃.论虚拟仪器LabVIEW的发展及应用[J].山西电子技术，2011（04）：87.
[2]舒梯翔.自动化测试技术的发展探讨[J]. 宇航计测技术，2001，21（3）：46-59.
[3]Chen，S.，et al.，Application of virtual instrument technology in temperature control.Journal of Electronic Measurement and Instrument，2004（02）： p.1205-1207.25.
[4]傅大梅.液晶显示驱动方法的探讨[J].南京工业职业技术学报，2003，3（3）：27-30.
[5]赵高毅.通用串行总线在虚拟仪器技术中的应用研究[J].遵义师范学院学报，2008（0l）.
篇8
1提高电气自动化控制设备可靠性的重要性
目前，随着社会的不断的发展，工业生产和人民生活对电气产品的可靠性都提出了很高的要求。当然，在当前日益激烈的市场竞争中，可靠性较高的电气产品在市场中所占的份额会有所增加。同时，电气自动化设备的可靠性较高也会使得生产出的产品的质量较高。事实上，只有质量较好的产品才能在激烈的市场竞争中立于不败之地。
2电气自动化控制设备可靠性问题的分析
一般来讲，电气自动化控制设备中存在的一些可靠性的问题都是源于组成电气控制设备的相关的元器件自身的质量有关。近年来，随着电气自动化的不断的发展，元器件生产厂家的数量也在急剧增长，但是出现在市场上的元器件的质量是参差不齐的。因此，在制造电气自动化设备的过程中，一定要严把元器件的质量关。因为，当前很多的企业中都存在着很多的管理问题。同时，市场上的恶性竞争也非常激烈，这就使得元器件不能得到企业的高度重视。因此一些元器件的参数指标的下降和寿命的缩短都对电气控制设备带来了极大的影响[1]。另外，当前电气设备可靠性的问题与当前电气设备使用的环境和维护的情况都有很大的关系。电气设备的工作环境通常都是非常复杂的，同时多变的工作环境对电气设备的影响也是有所不同的。目前，很重要的几个因素就是气候变化和电磁干扰。这样会使得元器件的参数得到改变、损坏，进而使得设备的可靠性受到影响。
3电气自动化控制设备可靠性的测试方法
上面我们对电气自动化设备可靠性中存在的问题进行了分析，因此对电气自动化控制设备的可靠性进行测试就显得非常重要。下面笔者就当前比较科学的电气设备测试方法进行阐述：
3.1保证试验法
保证试验法是一种非常常见的电气设备可靠性检测方法。它指的是在生产产品出厂之前，对其的一些参数指标进行测试，从而使得电气设备能够正常的使用。电气自动化控制设备是由很多的器件组成的，因此电气设备所出现的故障的种类也是非常多样的。因此，可以根据电气设备所生产出的产品中存在的不同的问题对其自身所出现的故障进行分析，从而来进行检修和维护[2]。因此，企业可以通过保证试验法来对电气设备的可靠性进行检测，从而能够及时的发现其中所存在的问题。
3.2现场测试法
相对于前两种测试方法，现场测试的方法的实用性是非常强的。这种方式是将电气控制设备放置于一个真实的现场环境，来进行可靠性的测试。这种方式所得到的数据是非常科学有效的。通常是可以作为电气控制设备可靠性测试的重要的参考依据。但是，这种测试方法对试验条件或者周围环境的要求比较高，对设备的质量的要求也比较高。因而，现场测试法的实现条件也是相对困难的。
3.3试验室测试法
试验室测试法主要指的是在可控制的环境中进行全方位的模拟测试。这种方式是将需要测试的设备放置于模拟环境中，这样可以在模拟的环境中施加各种环境的压力，并进行数据的测试。这样就可以获得一定的科学的数据记录，并将数据在一定的系统中录入，从而对数据进行科学、准确的分析，进而得到一套比较合理、可靠的参数体系。这种测试方法的可控性较强，可参考价值也比较高。但是试验与实际环境还是存在着一定的差距的，因此试验成本较高[3]。
4可靠性测试的建议
在对电气设备可靠性进行测试的过程中会出现很多的问题，因而在这里我们就这些问题提出一些建议。即相关的工作者需要选择质量较高的电气元器件，同时还需要掌握一定的技术，从而使得电气设备的工作环境比较适宜。另外，为保证器件的可靠性，需要在其应用于设备之前，逐个进行可靠性的测试。同时，器件的选择也需要从优。除此之外，当前在电气设备中存在的可靠性偏低的问题大都是由环境温度所导致的[4]。通常在电气设备运行的过程中，会散出大量的热量，从而使得环境的问题提升，进而使得设备工作的适宜环境温度超标，并导致器件的损坏。因此，在电气设备工作的过程中，一定要控制好周围环境，或者在设备上安装散热器，从而保证电气设备的正常的运行。
5结语
篇9
关键词：OA系统；软件测试；测试方法；压力测试
中图分类号：TP393 文献标识码：A 文章编号：1009-3044（2014）25-6025-06
Research on Test Methods of Office Automation System
LI Zhu， JIANG Pan， LI Zhen-wei， DENG Hai-kang
（Office Automation Systems Management Office，Chongqing Jiaotong University， Chongqing 400074， China）
Abstract： With the popularization of computer， office automation system （OA system） development， obtained the widespread application in the organs， enterprises and institutions and other industries. However， due to high demand， the development of the office automation system function， the design and programming of OA system becomes more and more complex. The complexity of OA system design and make OA system testing more cumbersome and inefficient， so， how to achieve rapid， effective test of OA system has become an urgent problem to solve. Based on the OA system of Chongqing Jiao tong University as an example， the use of functional testing， conducted a comprehensive test of the system for 5 kinds of test methods for testing， security testing， reliability testing and stress testing， and achieved good results.
Key words： Office automation system； software test； test method； Stress test
1 概述
随着计算机及网络的迅速发展，人们为提高办公效率，减少经费开支，开始寻求一种网上办公方式，办公自动化系统在此背景下应运而生。重庆交通大学办公自动化系统的开发成功为学校实现双校区协同运行、节约办公成本、提高办公效率做出了巨大贡献。
然而，由于软件系统规模和复杂程度的增加，使得OA系统规模巨大，编程复杂，为实现对办公自动化系统改进，快速有效的OA系统软件测试就成为重中之重。该文以重庆交通大学OA系统为例，通过功能测试、安全性测试、易用性测试、可靠性测试和压力测试5种方法实现对该系统的测试，测试结果表明，以上测试快速、有效，能够为OA系统的进一步改进提供依据。
2 OA系统概述
2.1 OA系统的概念及作用
办公自动化系统是利用技术的手段提高办公的效率，进而实现办公自动化处理的系统。它采用Internet/Intranet技术，基于工作流的概念，使用户方便快捷地共享信息，高效地协同工作；改变过去复杂、低效的手工办公方式，实现迅速、全方位的信息采集、信息处理，为单位的管理和决策提供科学的依据。
2.2 重庆交通大学办公自动化系统简介
重庆交通大学办公自动化系统（以下简称OA系统）是覆盖校属各单位的办公信息管理系统。该系统是学校信息化建设与管理工作的重要组成部分，是实现网上办公和信息资源共享，提高工作效率和管理水平的必要手段。
2.2.1 系统结构及组成
学校OA系统采用B/S结构。所有办公数据，如公文、通知公告等信息均存放在服务器上。用户通过浏览器登录系统，进行相关事务的办理，公文的运转，文件、通知的查阅等操作。学校OA系统包括：待办事务、日常办公、网上审批、通知管理、信息、个人助理和系统维护七个部分。
2.2.2 党政发文和校内来文运转流程
党政发文是学校党委发文、行政发文和党政办公室发文的合称，三种发文方式运转流程大体一致，一个正常的党政发文运转流程见图1。
校内来文是指校内运转的各种请示、报告等。校内请示用于学校各职能部门、学院、直属单位等二级单位向学校请示解决有关问题；校内报告用于以上单位向学校告知有关事项、事件。校内来文中请示一般要给出批复意见，报告要给出回复意见，具体流程见图2。
3 软件测试方法
3.1 软件测试概述
3.1.1 软件测试的定义及目的
软件测试是在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程，是使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
3.1.2 软件测试的原则
软件测试的原则主要包含七个方面：1） 尽可能早的测试；2） 软件测试应由第三方进行测试；3） 测试时要考虑全面，要尽量做到测试的全覆盖，并要考虑一些严格状况；4） 要特别注意测试中的群集现象；5） 当测试发现错误时，需要进一步进行确认；6） 为以后系统维护方便，要妥善保管测试资料；7） 测试要具有指导性，制定严格的测试计划，同时要保证测试的时间。
3.1.3 软件测试的目标
软件测试的目标包括：（1） 发现一些可以通过测试避免的开发风险。2） 实施测试来降低所发现的风险。3） 确定测试何时可以结束。4） 在开发项目的过程中将测试看作是一个标准项目。
3.2 OA系统的测试方案及要求
3.2.1 OA系统测试方案设计
下面我们就针对 OA系统的特点从五个方面开展测试方案设计：功能测试、易用性测试[1]、安全性测试、可靠性测试和压力测试。
3.2.2 OA系统测试要求
1） 只有企事业单位自身应用人员最熟悉办公需求，因此专业设计人员在做测试设计之前需要充分和最终使用人员做好交流，以便真正能代表客户验收；其次，最好由本单位使用人员来进行测试执行，专业的测试人员在旁观察。
2） 办公 OA 系统自动化测试需要尽早考虑，需要在软件需求分析阶段就考虑好自动化测试需求。考虑到办公 OA系统各工作流相对独立，建议采用敏捷开发和测试流程，每迭代交付一个工作流。
4 重庆交通大学OA系统测试研究
4.1 功能测试
功能测试也叫黑盒测试，它不需要考虑整个软件的内部结构及代码，而是只需考虑软件的各个功能。
4.1.1 单功能验证
以重庆交通大学OA系统系统登录为例，编写测试用例。如要进入该系统，需输入用户名和密码，只有当用户名和密码都正确时，才可登录；当用户名或密码之一出现错误时，禁止用户登录[2]。
4.1.3 功能间交互验证
功能间交互验证是指当单功能点出现交互操作时，实现对系统功能的验证。
4.2 易用性测试
重庆交通大学OA系统使用人员为校领导、各部门中层领导干部和各单位办公室主任，因此，易用性测试主要在以上人员间开展。
4.2.1 校领导账户易用性测试
由于校领导平时工作繁忙，且要求较高，因此，校领导测试需要安排开发公司人员及办公室人员陪同测试，由开发公司人员讲解示范，校领导亲手操作，党政办人员配合。当场提出修改意见，由党政办人员和开发公司人员记录，然后修改。直到校领导满意为止[4]。
4.2.2 处级领导干部账户易用性测试
处级领导干部账户易用性测试主要由校党政办人员进行当面指导，由处级领导干部亲自操作，然后将使用感受及修改建议记录，再送开发公司进行修改。
4.2.3 各部门OA秘书账户易用性测试
该部分主要测试由校党政办组织联系开发公司人员对各部门OA秘书进行集中培训，培训过程中接受部门OA秘书提出的建议；由于培训人员较多，且不能亲手操作，因此，在培训后，再由党政办人员对有疑问人员进行再次讲解。查找易用性问题及建议，收集后送开发公司修改完善。
4.3 安全性测试
鉴于OA系统中运转的公文都具有较高的安全性要求，因此如何保证OA系统安全就成为一个关键。安全性保证主要有两个方面：网络安全和账户安全，我校OA系统安全主要通过以下方法来保证：
4.3.1 网络安全测试
网络安全测试方法主要采用：（1）TCP和UDP连接测试：netstat （2）网络邻居信息探测工具：nbtstat （3）网络主机扫描：HostScan （4）漏洞检测：X-Scan （5）端口监控工具：Port Reporter五种方法进行测试。
经测试，我校OA系统网络存在部分端口未屏蔽，存在安全隐患；其他方面的问题基本可以避免，系统采用了以下三种方法网络安全防范手段：
1） 设置IP地址限定。鉴于OA系统用户基本都是在上班时间进行OA系统访问，因此，可以设置IP地址限定，非限定IP地址无法进行访问，保证系统用户均为设定用户。
2） 加装软件防火墙。鉴于ESET NOD32防病毒软件和360安全卫士在OA系统防护方面和木马查杀方面的优秀表现，因此使用该软件自带防火墙和360防火墙相配合方式，对出入站通信规则进行设定，避免了非法数据的进入。
3） 邀请网络安全专家对学校OA系统服务器网络进行检测，查找安全漏洞，修改组策略，保证系统网络安全。
4.3.2 账户安全测试
账户安全测试主要采用病毒植入、盗号木马、远程控制等方式进行破坏性测试，测试结果表明：除非系统内部人员刻意破坏，否则基本可以保证账户安全。我校OA系统采用了如下方法：
1） 由于系统使用初期所有人员的密码均为统一初始密码，因此督促系统所有使用人员对密码进行修改。且下发文件要求所有使用人员妥善保管用户名及密码并不定时修改，以避免用户名和密码遗失。
2） 在系统管理员账户中，对用户登录使用情况进行监控，若出现下班时间登录或者频繁操作者，则联系相关人员进行确认，保证安全。
3） 邀请计算机安全专家对系统账户安全进行检测，出具安全报告，保证用户账户的安全稳定。
4.4 可靠性测试
4.4.1 工作流中断
在系统使用过程中，经常出现工作流中断场景，为保证各种流程的正常流转，避免流程错误或中断，在充分调研的基础上，重庆交通大学OA系统采用E2Q Studio设计器，对流程进行跟踪，随时可根据需要对流程进行更改，保证了工作流的顺利运转。
4.4.2 硬件异常
硬件异常主要表现为网络中断、服务器断电等，如何服务器在硬件异常时，保证系统及时恢复。
1） 当出现网络中断时，采用编程方式，在服务器使用ping命令检测网络，当网络出现中断时，服务器自动重启，保证系统运转正常
2） 当出现服务器断电时，及时检测断电点，请后勤能源科及时修复。
4.4.3 数据可靠性测试
经测试，该系统为保证数据可靠性，采用了以下两种机制：1） 定时数据备份机制，在系统中编程实现Oracle数据自动备份机制，每一个小时数据自动备份一次，保证系统数据随时在最新状态。2） 异地备份机制，数据备份后，将数据传送到系统管理员计算机，进行异地备份，中午和晚上各一次，当OA系统服务器出现崩溃或数据丢失时，也可保证系统恢复后，数据在最新状态。
4.5 压力测试
本次采用MI公司的专业压力测试工具LoadRunner 11，采用录制＼回放的方法，即首先录制系统用户并发登录，然后采用多线程的方式模拟大量客户端向服务器方发送登录请求，达到压力测试的目的。
4.5.1 测试场景
表3
4.5.2 测试环境
服务器是一台曙光服务器，安装的软件包括Tomcat 6.0 ，JAVA，Oracle 10g，使用2个笔记本模拟客户端发出请求。
5 结束语
本文首先介绍OA系统的基本概念，然后对重庆交通大学OA系统进行了简要论述，分析了OA系统测试方案及要求，然后根据上述方案，然后通过功能测试、易用性测试、安全性测试、可靠性测试和压力测试5种测试方法对重庆交通大学OA系统进行了测试，实践表明，以上测试结果快速有效，是OA系统测试提出的一种探索。然后限于OA系统规模巨大、编程复杂，因此，测试难免有一定的局限性，不可能形成一种通用测试方法。
参考文献：
[1] 余丽萍，熊伟.浅析办公自动化系统（OA）的测试[J].信息化建设，2012（5）.
[2] 范志琰.某公司OA系统的设计与测试[D]. 北京：北京邮电大学.2011
篇10
>> 基于Web的自动化测试框架研究 基于Selenium 的Web自动化测试框架 Web自动化测试框架的研究 PhantomJS在Web自动化测试中的应用 通过Selenium实现Web自动化测试的研究 基于Flex的自动化测试框架 软件测试技术与自动化测试框架模型的研究与应用 基于RFT的企业自动化测试框架的构建和应用 结合Robot框架的Web Driver自动化测试解决方案 基于Java反射的APP自动化混合测试框架的研究与实现 自动化测试框架：自己的框架 基于WEB结构自动化的嵌入式测试平台设计 基于JAVA的测试自动化设计应用 基于Smart的页面自动化测试的研究 基于Python的软件测试自动化平台研究 基于AutoVue的自动化测试框架设计与实现 基于关键字的自动化软件测试框架设计 基于U盘升级在自动化测试系统中的研究及应用 基于业务流程的SG―ERP自动化测试技术研究与应用 基于Appium的手机应用程序自动化测试研究 常见问题解答 当前所在位置：
[4]STAX Services User’s Guide,IBN Inc.
http：///current/staxug.pdf
[5]http：///
[6]Vincent Massol著,鲍志云译.JUnit in Action[M].电子工业出版社,2004,11
[7]Giovanni Denaro,Andrea Polini,and Wolfgang Emmerich Performance Testing of Distributed Component Architectures.
/articles/2004
[8]Mark Fewster,Dorothy Graham.软件测试自动化技术[M].北京:机械工业出版社
[9]Daniel Hofman."Boundary Values ang Automated Component Testing"Softw.Test Verif Relia b.9.3-26(1999)
