M6 米乐自动化测试十篇

　　软件测试是软件生存期中的一个重要阶段，是软件质量保证的关键步骤。软件测试自动化，是一项让计算机代替测试人员进行软件测试的技术。测试自动化通常借助测试工具来执行，测试工具可以进行部分的测试设计、实现、执行和比较的工作[1]。通过运用测试工具，可以达到提高测试效率的目的。本文首先介绍了自动化测试的概念及怎样实现自动化测试，接着介绍主流自动化测试软件及其自动化测试框架的构造，最后介绍用自动化测试脚本语言Tcl(Tool Command Language)实现一硬件系统中主备板间自动切换的测试用例。

　　软件测试跨越整个软件开发流程，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。测试应当有意制造错误从而确定是否漏过预期应当发生的事件，或者发生了预期不该发生的事件，测试的目的是检查错误。经验表明，测试人员多数的时间花在对系统逻辑流程和控制流程的理解（白盒测试），测试覆盖路径的确认，同一测试用例对不同程序修改版本的测试结果验证和手工填写测试报告上等场合，这些领域适当采用测试工具可以提高测试效率和测试正确性[2]。为此我们引用自动化测试。

　　测试自动化可理解为测试过程自动化和测试结果分析自动化。测试过程的自动化指的是不用手工逐个的对用例进行测试。测试结果分析自动化指的是不用人工一点点去分析测试过程中的中间结果或数据流。适合于软件测试自动化的场合：

　　(1)回归测试，重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费；

　　(2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具；

　　(4)自动化工具能够确定测试用例的覆盖路径，确定测试用例集对程序逻辑流程和控制流程的覆盖。

　　常规情况下，软件的自动化测试能够发现10%-15%的软件错误。手工测试能够发现80%左右软件错误，由于自动化测试和手工测试存在重合的错误发现，因此尚需有5%-10%的错误需要通过两者结合和采取其它途径进行发现。

　　单元测试自动化是最轻量级的测试，它的测试目标是特定模块的函数或者代码块。通常单元测试是由开发工程师自己来做的，因为进行这种测试涉及到程序内部设计和代码实现的细节。对于单元测试，我们希望能像使用编译程序器编译一样，每次修改代码后，即可运行编译器进行编译，如果没有错误，完全可不用去看编译报告，当有问题时编译器才会发出警报，并给出一定的线索。我们用编译器来检查语法错误，用单元测试来检查语义错误[3]。单元测试适合于充分的测试代码片断，它的前提是对代码的具体实现非常了解。

　　在这测试环境中，被测系统看作一个整体，它接受到外界的输入后，会产生一些相应的输出。而外部环境是由用户界面和测试工具组成。用户界面就是用户使用被测系统的接口。测试工具这里指的是外部支持系统，可能是一个关联子系统，也可能是一些驱动库，这些系统可能是真实的系统，也可能是专为测试做的模拟系统。一般情况，相对测试系统来说，用户界面是主动的，由它发起对某个功能点的测试，而测试工具是被动的，它接收到由被测系统发出的消息后，发回相应的响应。

　　我们需要编程序来完成用户界面以及测试工具的动作，我们把上图的外部环境分为三种类型来讨论：用户界面，模拟外部子系统和真实外部子系统。这里只考虑模拟外部系统的测试工具，对于真实的外部子系统，它的动作是不用测试者设定，然而某些情况下我们还是需要观察它与被测系统间交互的消息，确认其中的某些检查点。可采用脚本语言来实现测试自动化。脚本语言的特点首先它自动逐条执行语句，并可以方面的修改源代码来设定一系列的动作，另外，脚本语言一般都有非常强大的字符串处理能力，这对于我们实现测试自动化以及结果分析都非常有利。

　　一般来说，用户界面和模拟外部子系统的测试工具功能比较简单，主要是收发短消息或涉及鼠标键盘操作，其中没有复杂的逻辑和算法，可被认为是一个一个的消息触发器组成的，而且每个触发器的动作都是预先设定好，接收到消息A则发送消息B，因此用脚本语言很容易模拟它们的动作。在用脚本语言实现过程自动化的时候，可以通过在脚本中设置控制点，控制脚本的执行。当脚本运行到控制点时，将等待用户输入，然后根据输入进行进一步的动作。这样可逐段执行脚本，便于调试。通过构建自动化测试平台进行过程自动化测试，大大减少了测试过程中所需做的重复性工作，降低了人性的弱点对程序质量的威胁。

　　构建好自动化测试平台后，我们可对测试结果进行自动化分析了。对某一个功能点的测试往往包含用户界面，被测系统和测试工具的多次消息交互，通过查看这些消息的内容和顺序是否与预期一致来判断一个测试用例是否通过，形成自动分析案例。对于某个测试用例，可预先编制一个目标文件，其中包含所有完成这个用例所需交互消息，包括用户界面与被测系统间的消息，以及被测系统与测试工具之间的消息。

　　在自动测试平台中，加入一些控制，在收发消息的同时将消息依次存入到一个文件中，当测试用例完成后，可将两文件做对比，如果匹配的话说明测试成功，如果不匹配，则给出最先不匹配的位置信息。编写目标文件不一定要包含所以消息，有时候可能只需要比较某个测试工具接受的消息就可以判断是否正常，那么在脚本中只需将该测试工具所接受的消息存入文件即可。这样手工编写目标文件容易，比较速度也快。比较文件时所用的匹配算法也可根据自己的需要加以调整，可以是精确匹配，也可以只是检查目标文件中的消息是否在当前生成的文件中依次出现。一些脚本语言，例如TCL具有很强的字符处理能力，可方便的实现某些匹配算法。

　　通过用脚本来实现测试过程与测试结果分析，可形成维护一个测试用例库。每次代码集成的时候都可以通过运行这些脚本对程序进行回归过程测试，整个测试过程不需要人工干预[4]。当出现问题时，会生成相应的测试报告，给出错误信息。这个测试用例库在整个软件的生命周期中都可重复利用。

　　Mercury Interactive 的 LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的周期。LoadRunner 支持广范的协议和技术，为特殊环境提供特殊的解决方案。

　　TestDirector是业界第一个基于Web的测试管理系统，它可以对全球范围内的测试进行管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。一套基于Web的测试管理系统提供了一个协同合作的环境和一个中央数据仓库TestDirector能消除组织机构间、地域间的障碍。

　　Win Runner是Mercury Interactive公司推出的一种企业级自动化测试工具。通过自动录制、检测和回放用户的应用操作，来帮助测试人员自动完成应用程序的功能性测试。可提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障及长期稳定运行。用WinRunner进行自动化测试主要分为5步：

　　(1)创建GUI Map文件。WinRunner可以通过它来识别被测试应用程序中的GUI对象。

　　(2)创建调试测试脚本。通过录制，编程，或两者的组合创建并调试测试脚本。

　　(3)运行程序。运行测试时，WinRunner会自动操作应用程序，就象一个真实的用户根据业务流程执行着每一步的操作。

　　(4)结果分析。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。

　　(5)维护测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试，从而大大地节省时间和资源，充分利用测试环境。

　　根据类和封装的思想,将WinRunner中的类提取来进行封装。所有的类全部封装于函数（ExecuteCase）中，针对每一类，均有具体的行为与之对应，根据配置文件中传入参数的所属类,ExecuteCase会将相应的接口进行处理。如果有新类或特殊类，也可以将ExecuteCase函数进行扩充，从而满足不同的测试需求。

　　Tcl(Tool Command Language)是一种可运行在 Unix，Windows 和 Macintosh 等各种平台上的自动化测试脚本语言。具有良好的扩展性，以便用户为其增添新的功能模块。Tcl语言将程序设计概念高度抽象，真正地把程序设计与操作系统底层结构隔开，因此不依赖于任何平台，具有良好的可移植性[5]。下面简单介绍用Tcl实现一硬件系统中主备板间自动切换的测试事例。

　　软件测试跨越整个软件开发流程, 软件生存期中的一个重要阶段，是软件质量保证的关键步骤. 运用主流自动化测试工具，构建自动化测试平台及自动化测试框架，可提高测试效率和准确性。自动化测试脚本语言的应用更为软件自动化测试提供了有利的支撑。

　　[1] 张克东. 软件工程与软件测试自动化教程[M]. 电子工业出版社, 2002.4.

　　[3] 朱菊, 王志坚. 基于数据驱动的软件自动化测试框架[J]. 计算机技术与发展, 2006,16(5).

　　[4] 张毅坤. 面向对象软件测试的特点及方法[J]．西安理工大学学报，2002,18(4).

　　信息爆炸时代带来了信息数量的级数级增长，各行业也越来越认识到对大数据的掌控和分析能力会是未来竞争力的核心。行业决策也超越了以前依靠抽样调查的阶段，转而依靠大数据进行全面分析支持。

　　除功能外大数据平台性能处理能力是评测大数据平台的重要指标之一。目前，大数据平台性能测试存在的问题主要有：开源版本更换较快，需要频繁更换版本； 测试条目较多，场景比较复杂、繁琐，手工操作容易出错或不准确； 整个测试过程持续时间长。本文基于BigDataBench工具和Apache Hadoop2.5进行大数据平台性能测试自动化研究，尝试解决上述问题。

　　经典的大数据平台组件性能测试项主要包括HDFS的读写、Mapreduce的执行情况、NoSQL的数据库能力等[2]，如表1所示。

　　以上测试项覆盖了I/O测试、I/O密集型、计算密集型及混合类型测试条目，涉及文本、图和表等输入数据。

　　在性能测试中，测试工具支持必不可少，目前除Apache Hadoop自带工具外，还有企业或组织了第三方测试工具。一般测试工具包括测试数据生成、负载运行和报告生成三大功能。

　　HiBench是Intel的一个大数据性能测试套件，包括HDFS、Mapreduce、SQL、网页搜索以及机器学习等性能测试。支持的测试条目比较全面。

　　YCSB在命令行中直接可以设置线程数、读写比例等，可以提供较为详细的测试结果。

　　BigDataBench[3]是由中科院计算所研发的一款开源性能测试套件，是国内大数据组织大数据联盟（推荐的大数据性能测试工具。大数据联盟（DCA，Data Center Alliance）同时配套的还有大数据性能测试基准要求及方法[3]。

　　BigDataBench整合多种测试工具的优点，几乎覆盖所有组件，可以准备文本、图像、数据库等多种数据，实现端到端的性能测试[4]。

　　由于大数据联盟的权威性，几乎国内全部大数据厂商都遵循大数据联盟的测试工具及测试要求，并参加了大数据联盟组织的测试。本性能测试自动化系统也主要是基于BigDataBench工具。

　　大数据平台性能测试自动化系统主要实现部署自动化，测试数据准备自动化，性能负载运行自动化以及数据展示自动化。

　　整个自动化测试过程主要包括版本部署、运行状态检查、数据准备、测试脚本运行、结果收集展示及环境清理几个步骤。

　　在自动化测试中，版本部署部分通过调用Node.js来模拟浏览器的相关操作。准备数据及运行脚本部分，通过调用预先编写的相关Shell脚本来按测试方案配置并运行BigDataBench的相关测试命令，同时采用Nmon工具来监控主机CPU和内存利用率以及I/O性能指标，通过Grafana展示结果数据[5，6]。具体流程如图1所示。

　　最终通过Grafana系统展示测试结果，包括主机性能监控指标，各测试负载结果数据，各版本横向测试结果对比，效果如图2所示。

　　本文在大数据平台研发过程中运用本系统来保障性能测试，取得了较好效果。首先确保了各版本性能测试环境、数据、方法和测试标准的一致性，并大幅提高了工作效率，同时做到7×24小时不间断运行。在实际应用中发现，原来需要4～5天的人工性能测试工作可以缩短到2天之内由测试自动化系统来完成。

　　由本性能自动化测试系统保障的大数据平台在大数据联盟组织的性能测试中，取得了排名前列的成绩。其中NoSQL测试项中的“Write”（读）操作和“Scan”（扫描）两项操作测试指标排名第一。

　　如何加强基本组件的性能测试，比如生成恰当的测试输入数据，实现应用端到端的测试，同时扩充Spark、Kafka、Storm等新增组件的性能测试套件并整合其它优秀性能测试工具，将是后续研究的方向。

　　[1] 朱叶青，牛德姣，蔡涛，等.不同网络环境下大数据系统的测试与分析[J].江苏大学学报：自然科学版，2016（4）：429-437.

　　[3] 陈凯，魏凯，周晓敏.大数据平台基准测试标准化思考 [J].电信网技术，2013（2）：14-17.

　　【关键词】自动化测试 增值业务 短信猫测试自动化 WAP/Web页面操作自动化

　　随着3G网络的广泛应用，电信行业进入体验式经济时代，越来越多的用户通过运营商、移动互联网或应用商店直接购买、体验、使用各类增值业务。高质量的业务应用、良好的服务质量是客户对业务提出的需求，也是电信行业各方竞争的重要领域。中国移动在增值业务领域发展迅速，向用户提供包含娱乐、信息、数据、交易等多种类型的业务应用，如何确保新业务的上线质量，特别是面对数量巨大的新上线业务，同时还要兼顾业务上线前测试时间短等因素，自动化测试成为最为可行的解决之道。本文将结合移动增值业务的特点，特别是个人业务的特点，阐述自动化测试的设计和实现方法。

　　针对个人业务的测试是模拟真实用户从业务办理、业务使用、业务计费以及与用户感知相关的其他方面对业务质量进行的端到端测试。用户使用个人业务的整个过程，包含业务订购、业务使用、业务计费和业务退订。例如移动推出的“手机就是邮箱”的139邮箱个人业务，用户可以通过发送短信到10086办理，也可以通过WAP和Web上网办理；办理成功后，用户使用139邮箱提供的功能，移动会每月从客户的账户中扣除相应的使用费用；当用户退订139邮箱后，该业务订购关系将自动取消。

　　业务订购：当前大部分增值业务均提供了短信订购、WAP掌上营业厅订购和Web网上营业厅订购三种方式。三种订购方式的流程概括如图1所示：

　　从图1中可以看出，短信渠道订购过程中，用户与业务系统之间主要通过短信交互完成，WAP和Web渠道基本的过程差别不大，主要区别在于用户操作和访问的页面不同。

　　业务计费：从计费的及时和准确性出发，对业务计费的验证主要以网厅账详单展示为主。

　　个人业务的测试关注业务上线后的实际体验质量，测试在业务正式面向用户商用推广之前，测试的目的是识别业务潜在的风险，发现业务的质量，及时改善，提高新业务的上线 自动化测试技术的引入

　　个人业务的测试过程，通过测试执行人员手工操作，完全可以实现所有测试点的覆盖。但面对数量巨大的上线业务量，所有的工作都通过人工实现，无疑意味着巨大的时间和人力投入。综合对上述流程的分析，大部分业务的订购、退订以及计费都有着基本类似的操作过程。通过对这些过程的总结，引入了个人业务的自动化测试工作。

　　例如：短信的收发过程自动化可以通过一定的技术手段控制手机或设备实现；WAP页面操作自动化可以通过两种方式实现——控制手机或通过PC浏览器实现；Web操作自动化可以利用已有的成熟工具如RPT等，并配合一定的脚本开发设计，实现流程操作的自动化。

　　本文从业务支撑网所考虑到的角度，以业务订购、退订和计费为内容，展开测试自动化实现方案的介绍。

　　通过对个人业务测试的特点进行分析，自动化测试实现可以分为2大类：短信收发过程的自动化和WAP/Web页面操作的自动化。

　　短信收发过程的自动化实现需要考虑两方面内容：一是短信收发设备；二是自动化的执行系统。

　　短信收发设备有独立手机终端和设备（如短信猫）两类可以利用。两种设备分别具有各自功能上的特点：手机终端功能丰富，完全与真实客户的实际业务操作设备一致，能够满足更多特殊的业务操作要求；而短信猫等设备，功能相对简单，但对于大批量的短信收发支持较好。如图2所示的设计方案，将涵盖对两种设备的支持，整个系统将更好的满足不同测试场景的需求：

　　由于手机终端和短信猫两种设备的差异性，自动化测试系统将通过两种不同的方式实现对设备的自动化控制，从而完成对个人业务测试过程的自动化操作。

　　1）控制手机终端的实现。目前的智能手机系统中，基本上被Android和iOS占领，而Android系统的免费、开放等特性，也为实现对手机的控制提供了可能。本方案选择Android系统的手机实现（如下所提的手机终端皆指安装Android操作系统）。基于VNC（Virtual Network Computing，虚拟网络计算机）技术（VNC是由著名的AT&T的欧洲研究实验室开发的开源远程控制软件，远程控制能力强大、高效实用，能将完整的窗口界面通过网络，传输到另一台计算机的屏幕上），通过在手机终端部署远程控制的服务端程序（VNC Server），在PC机上部署远程控制的客户端程序（VNC Client），手机终端和PC机通过网络连接，即可实现在PC机上远程控制手机终端的操作。基于该技术，实现了手机显示屏幕的操作可同步展示在PC机上，操作员可以通过鼠标和键盘操作，实现手机上选择和文本输入等功能，甚至可完全在PC机上实现所有手机上的操作，实现了对手机终端的全面控制。

　　2）自动化执行的实现。结合上述分析，主要在PC侧实现鼠标和键盘操作的自动化，即可实现对手机操作的自动化。基于目前主流的技术，鼠标和键盘操作的自动化控制已成为十分简单的问题，通过简单的脚本编辑以及系统API的简单调用即可实现对鼠标、键盘操作的控制。

　　3）业务流程的自动化实现。根据业务订购、退订等逻辑过程，组合鼠标、键盘各种操作，通过PC机执行脚本，完成整个业务流程。例如：控制键盘输入短信指令“KTYW”，控制鼠标点击“发送”按钮，以上两项脚本操作，即完成了业务的自动化订购。此外，通过复杂的脚本设计，可以实现对手机的各种控制（如发送彩信、访问网页、运行手机上程序等），满足业务测试的各种需要；而完成了相应脚本的编辑后，即可在没有手工干预的情况下，通过电脑自动执行完成业务处理过程。

　　结合上面设计的组网方案，自动化脚本的设计、执行将在自动化测试系统上完成，远程控制终端，方便测试人员进行系统登录、启动测试及查看测试结果等操作。

　　1）短信猫控制的实现。短信猫功能重点体现在多卡并行上，能较好地满足大批量同类型的用户测试；但这种设备的功能支持相对简单，一般仅提供基本的短信、语音通话功能。对于短信猫的控制，同样是通过脚本控制实现。目前主流厂商的短信猫设备，基本都有配套的管理系统，在管理系统中配置任务表即可实现设备自动收发短信、语音呼叫等功能。结合上面的组网方案，短信猫设备的管理系统也将集成到自动化测试系统中。

　　2）自动化执行的实现。通过自动化测试系统控制短信猫后，即可在系统中通过脚本的形式对短信猫进行远程操作。短信猫、自动化测试系统的交互过程如图3所示：

　　3）业务流程的自动化实现。根据业务订购、退订等逻辑过程，测试系统支持测试用例的导入操作，将短信自动化操作的脚本写好后，导入到测试系统中，通过对用例进行封装和调度的安排后，即可在测试人员定制的时间段内进行业务的订购、退订等操作。测试任务执行完后，系统会将执行结果记录下来，并支持结果的导出操作。

　　WAP页面浏览的自动化，除了可以通过上述控制手机终端的方式实现外，也可以利用业界较为成熟的工具（如RPT等），通过录制和编辑脚本，调用Web浏览器执行，实现对Web页面以及WAP页面操作的自动化操作（其中部分浏览器可通过安装插件，实现WAP页面的访问）。系统的架构如图4所示：

　　基于上面解决方案，用户所有的网厅操作均可以通过自动化的方式实现，通过RPT脚本的录制或编辑，可以完成用户在网厅上业务订购、业务查询、账单查询等操作。另外，配合方案一（短信收发过程的自动化），可以完成其他一些需要用户通过手机配合的业务操作过程，例如：需要手机接收随机验证码、手机接收网址并访问等等，使较为复杂的业务操作通过自动化实现成为可能。

　　综合以上两种设计方案和自动化实现，将各项功能融合后形成个人业务测试的自动化测试系统，用来满足不同业务场景的需要。该自动化测试系统支持的功能具体如表1所示：

　　自动化测试系统 手机终端测试自动化 所有通过手机操作完成的业务处理流程，适用的场景更多，能较好满足特殊的业务需求。可与WAP浏览自动化配合，实现系统下发网址短信，自动执行浏览等操作

　　Web页面操作自动化 网上营业厅、Web业务平台操作。可与手机终端控制自动化配合，实现手机接收验证码，完成网厅操作等业务场景

　　针对个人业务测试的特点，采用自动化测试系统对新业务进行测试后，将其与手工测试进行比较，自动化测试系统在测试时间、测试人力、回归测试方面具有很大的优势。比较结果如表2所示：

　　随着移动通信网络的发展，手机终端智能化的普及，运营商面向终端用户的业务将以更加迅猛的速度增长。在这种市场环境中，最终决定市场表现的还是用户对于业务的认可程度，即用户业务体验质量。通过提升用户业务体验质量，从而提高用户的品牌忠诚度，留住用户并扩大用户规模，这才是企业生存和盈利的关键，而个人业务测试通过在业务上线前对业务的订购、查询、计费、退订等开展测试，正是保证服务质量的重要手段。通过各种自动化手段，基本覆盖了上述所提的各种场景，有效解决大业务量的问题，同时极大降低了人力等成本投入。

　　[1] 高弋坤. 我国增值业务呈规模增长 运营商齐布局搭建统一平台[J]. 通信世界周刊， 2011，26（4）： 35-39.

　　[2] 邓正宏，高逦，郑玉山. 面向对象自动化测试框架的研究与设计[J]. 微电子与计算机， 2005（2）： 168-171.

　　一款软件从开发到，除了软件设计编程之外，软件测试也是不可或缺的一项中心环节。软件测试在以往都是软件开发人员自己检测，但程序员却无法将充足的时间用来测试，所以后来发展为软件开发与测试两者独立，测试部分由测试部门负责。但这个过程人力物力消耗大，时间长，所以软件自动化检测技术也就应运而生。

　　软件的自动化测试是一种新的软件测试技术，根据需要，可以将测试系统的运行环境进行调整，然后按照测试要求与目的设置相关程序功能，然后由系统按照设置好的程序对需要进行测试的软件测试。其运用主要地方为：软件开发完成后的测试以及维护测试。

　　通过软件自动化测试技术进行新软件测试，可以达到：用最少的经费，取得更完整彻底的测试结果，从而根据测试结果进行软件的再修改，以此来提高软件的质量。

　　其实这一点是这项检测技术最基本也是最核心的任务。当一个软件需要进行版本升级时，为了测试新版本软件的性能，那么人工软件测试与自动化软件测试就无可比拟。版本更新周期短，不具有开发阶段周期长这一特质。所以，利用软件自动化测试技术，在省却大量测试时间的同时，还可以加快新版本测试进度，降低版本升级的费用。

　　软件自动化测试技术的另一大特点就是其可持续测试性，自动化测试只要机器运行，就可以一直测试下去，而手工测试却无法具备测试持续性。这是人力测试无法解决的劣势。

　　人力有穷时，对于简单软件系统，人工测试还能胜任，但遇到诸如多元网络传输系统，依靠人力对系统测试，是行不通的。但自动化软件测试技术却可以胜任，其可以同时对这些网元进行仿真模拟测试。所以，自动化测试具有多任务性。

　　通过自动化软件检测技术，可以将更多地人力资源解放出来，让有限的人力资源不再陷入繁琐的测试当中。利用自动化检测软件可以让工作人员只需要思考测试的目的，设计更好地测试方案，控制好测试软件即可。

　　利用软件自动化测试技术，可以将测试的环境保持稳定一致，可以规避人力测试因外界因素影响测试过程，导致测试结果不准确这一问题。

　　软件经过自动化测试之后，测试软件就会将测试信息记录下来，作为范例，当遇到相似测试项目时，这些信息也可以作参考或直接使用。这也是人力测试所不具备的。

　　一款自动化测试软件，其需要具备这几样必须条件：被测软件信息输入部、测试结果输出部分以及多次测试结果对比部分。具备这三大部分，测试软件才能实现自动化测试。

　　软件自动化测试，其优点甚多，但并非万能。自动化测试任然存在一些不足之处，这些都是自动化测试技术所无法具备的：

　　有许多测试任务是自动化测试软件无法完成的。这时候就需要用到人力测试以及测试工程师了。对于简单的软件测试，依靠人力测试即可解决，而不需要检测软件参与，检测软件每次测试，都需进行系统调试，对于简单的测试，其调试时间与人力测试时间相当，这类情况检测软件的使用就不合时宜。还有一些类型也是软件测试所无法替代的，例如：被测软件运行不稳定，这时就需要人力进行测试，这样方便调节。还有有一些需要人机交互的测试，测试软件是一种设定好的程序，对于需要实时进行人机交互的测试来说，其自动化测试无法做到随机应变。所以，自动化软件测试是不能完全替代人工测试的。

　　自动化测试软件的一大好处就是可重复测试，但当使用以往测试数据来测试同软件的新版本之时，自动化软件检测所发现的bug往往会低于人工测试所发现的bug。

　　由于自动化软件测试程序相对固定，当一些被测软件有重大更新时，往往由于测试程序无法与新版本做到兼容，从而导致测试软件崩溃。而自动化测试软件的再设计与维护成本会比人工测试高，且自动化测试比人工测试影响要高，所以会对开发人员造成影响，综合以上因素，会对一些被测软件的重大更新部分造成修改限制。

　　所以，合理安排软件自动化测试与人工软件测试，将会更利于开发人员降低开发成本，减少测试时间，获取高效益。

　　目前的软件自动化测试适用于：单元/组件测试、BVT（版本测试）、集成测试、系统测试、回归测试以及性能测试。

　　软件自动化测试：该被测软件项目无严格时间限制，有良好测试计划与测试目的，测试内容涉及多平台，涉及被测软件运行所需硬件，被测软件可以使用自动化软件进行测试等这些情况下都可以使用软件自动化测试。

　　人工软件测试：没有严格测试时间限制，没有明确的测试目的与计划，开发人员或软件测试人员当中不会操作软件自动化测试的，刚加入开发的新成员，没有相关硬件等等这些情况就不是自动化软件测试所能达到的。

　　在软件自动化测试进程中，还需要一些工具辅助软件测试，目前按照使用环境可以分为：

　　管理型测试工具主要是对软件测试的计划、用到的测试用例、测试所需以及测试进程进行综合管理，同时还能通过这些管理型工具发现自动化测试所存在的漏洞，并就这些测试漏洞进行管理跟踪。而软件的开发者和软件测试人员能够通过管理工具对被测软件信息进行交流。

　　所谓沙盒测试工具，就是在独立环境下，对被测软件内部代码进行逻辑流程测试；而在测试中可以发现被测软件的漏洞，并且能够将这些缺陷定位，最高可定位至代码级。

　　静态软件分析工具可以对被测软件代码直接扫描，在不需编译的情况下进行测试分析。静态软件测试分析工具主要使用在：（1）代码；对被测软件进行语法扫描分析，找出代码编写错误的地方。（2）对被测软件静态情况下分析其结构，静态测试工具会根据被测软件代码结构复杂程度，对软件代码的设计与模块调用生成记录图表。

　　相对静态软件分析测试工具而言，动态分析工具的工作方式是利用钉钉子的方法，在被测软件代码中插入一段检测代码，这段代码会在被测软件运行时，对软件数据与资源调用率进行统计分析。

　　功能测试分析工具也可以称之为黑盒工具，其工作流程是通过自动记录被测软件数据、检测以及回溯客户操作。通过对被测软件测试前所预测结果进行对比，从而帮助开发人员与测试人员对不同版本的软件进行功能测试分析，提高工作人员工作效率。黑盒工具其主要目的是：通过测试分析被测软件程序能否达到预期设计目标以及稳定运行。

　　性能测试分析工具的目标是：分析测试被测应用软件的可扩展性能。在测试过程中，通过性能测试分析工具可以帮助测试人员检测软件运行性能以及查找运行时所出问题。并且就检测出的问题进行自动性能优化，保证应用软件能够正常进行测试运行。

　　这一类的测试工具其本身并不具备测试所需条件，辅助工具存在的目的就是将软件测试过程中所搜集的数据信息生成记录，为测试人员提供参考依据。

　　根据软件测试过程所需工具，正确使用这些测试分析工具可以帮助测试人员更快，更高效完成软件测试任务，缩短软件周期。

　　合理的自动化测试设计，可以提高工作效率，所以，在设计自动化测试时，应注意规避以下几种情况：时间限制，没有明确的测试目标，测试经验不够多，测试人员流动性高，对测试失去耐心和太偏重技术等。

　　过高的设备维护成本将会大大降低自动化测试软件的实际应用性，所以，在设计自动化测试软件的时候，软件的可维护性是其中一大重点考虑对象。目前的自动测试软件领域竞争激烈，而要想获得高的市场占有率，那么具有低维护成本的测试软件将占有极大优势。维护包括测试软件的日常维护以及测试软件的版本更新，其中版本更新维护是维护重点。随着软件开发的深入，软件自动化测试需要紧跟开发者的步伐，当测试软件无法满足测试需要时，那么自动化软件将会逐渐丢弃淘汰。所以，保持更新步伐是需要重点考虑的。

　　可测性就是自动化测试对被测软件的测试是否有效。所以，为了保证软件的可测性，设计时应当使用拥有：CLI、API与GUI接口的测试软件。

　　自动化测试与人工软件测试，其区别只是测试方式不同而已。从以上文章分析可以知晓自动化软件测试其优点突出，但不足之处也是显而易见。

　　自动化测试其根本性目的是将以往人工测试的过程精简化、程序化和标准化。在一定程度上可以代替人工进行软件测试。自动化测试的优点在于：自动化软件测试可以按照软件测试需要进行相应程序修改，然后利用符合测试需求的测试程序进行测试，在这过程中，相对简单的测试部分可以依靠人工测试，对于那些有重复性，测试过程严谨的测试部分则可以利用自动化测试，达到测试目的。综上，可以对软件自动化测试与人工测试进行一个对比，首先是人工测试：

　　人工测试是一开始就使用的测试方式，人工测试需要测试人员有丰富的测试经验。对于相对简单的测试目标具有速度快，效率高的特点。尤其是在相关的人机交互测试这类灵活度较高，测试过程不可控的测试目标，人工测试具有快速反应，测试灵活等特点。相应的，人工测试也存在很大的弊端，人工测试人员受精力与时间限制，对于那些时间短、测试过程程序化与复杂化的测试目标，人工测试就需要耗费大量时间与人力资源来完成。这也导致了测试成本提高，效率低下。

　　软件自动化测试与人工测试相比，自动化测试是按照测试程序对被测目标进行测试。所以对于那些重复性测试具有高效，测试过程严谨的特点。其所具备的强大数据处理能力对于那些测试过程中需要进行大量数据处理运算的测试任务具有高效的完成性。但其缺点也是明显的，对于那些需要进行实时交互的测试目标来说，自动化测试的固定测试程序是无法胜任的。

　　综上分析可以看出，人工测试与自动化测试之间有着明显优缺点，但两者也具有良好的互补性，所以合理搭配这两种测试方式，将会极大提高测试任务的完成效率，有效降低测试成本与人工测试资源。

　　本文从软件自动化测试的意义到应用进行了简单讨论分析，从各方面对比来看，软件自动化测试在软件测试行业中占有重要地位，在未来的发展中，应当加大对自动化测试的研究力度。让自动化测试继续发挥更大的作用。

　　[2]刘艳霞.软件自动化测试技术应用研究[J]软件导刊.2007，5：36-38

　　[5]季淑引.软件自动化测试工具的应用研究[J]科技向导.2012.20：59

　　张维利（1978-），男，山东省人。硕士学历。主要研究方向为信息系统软件测试、软件可靠性等。

　　进入二十一世纪之后，硬件元器件得到了飞速发展，从而也是的嵌入式软件的功能更加强大和复杂。随之而来的也是嵌入式软件测试工作的加重，传统的软件测试技术已经难以满足嵌入式软件越来越复杂的需求。而目前，市场上已经有较多的传统软件自动化测试技术，如何在这些技术的基础上进行改进，从而能够适应嵌入式软件环境，从而实现嵌入式软件的自动化测试，是嵌入式软件发展的重要方向。

　　嵌入式软件的自动化测试即利用脚本来自动化驱动嵌入式软件的运行，并且自动收集相关数据进行分析，最终生成相应的测试报告。虽然，嵌入式软件的自动化测试流程与一般PC机应用软件的自动化测试流程相同。但是，由于嵌入式软件软件对电子设备的高度依赖性，以及电子设备收周围环境影响较重，从而导致嵌入式软件的自动化测试平台存在如下的问题。

　　（1）由于电子元器件受到周围环境的影响，无论在宿主机上所进行的动态测试多充分，也无法保证嵌入式软件在实际的硬件环境中通过。

　　（4）上位机的测试环境中，由于上位机与下位机的通信量较大，测试结果数据较多，容易导致通信的堵塞。

　　米乐M6 M6米乐

　　通过对嵌入式自动化测试框架的分析，本文提出一种由脚本驱动器、接口映射表、数据驱动器和支持函数库所组成的，针对嵌入式自动化软件测试的组合型测试框架。

　　如图1所示，高层脚本调用执行下层脚本；底层运行脚本通过查询接口映射表调用待测试系统接口进行驱动和通信；测试脚本从数据文件调用数据执行测试。

　　脚本驱动器调用高层脚本，高层脚本调用下层脚本。底层脚本包括待测试系统具体的测试步骤。

　　接口映射表借鉴了关键字驱动测试框架中的组件映射表思想。测试人员根据待测试系统的实际需求，设计接口名称和参数，从而实现待测试系统的抽象化。在运行测试脚本是，首先通过映射表匹配接口名称和参数，当系统接口改变时，只需要改变映射表即可，从而实现测试系统与待测试系统的松耦合。

　　数据启动器是测试脚本与数据文件的连接器，通常采用文本文件、XML文件等来实现。在测试过程中，需要数据时，有数据驱动器读取数据。数据驱动器是脚本与测试数据分离，当测试数据变更时，只需要修改数据驱动器，而不需要对脚本进行改动。

　　嵌入式软件自动化测试平台的卡框架，采用嵌入式软件通用的Host/Target测试策略。

　　如图2所示，本文所设计的嵌入式软件自动化测试平台采用测试管理工具和测试双层结构。

　　米乐 M6

　　在进行嵌入式软件自动化测试时，测试人员的工作包括：编写配置文件、编写脚本、生成数据文件、测试报告分析等工作。嵌入式软件的自动化测试流程如图3所示。

　　当建立了管理工具和测试自检的通信之后，向测试发送测试请求，并且将脚本和数据传送到测试上。测试将测试脚本存放到特定的区域执行，并且将测试结果返回给宿主端。当宿主端接收到测试所发送脚本执行完毕信号后，发送新的测试脚本和数据给测试，直到所有的脚本测试完成之后，对测试所返回的测试结果进行分析，得出最终的测试报告。

　　为了不占用宿主段过多资源，将一些协助测试模块都放在宿主端中。管理工具的功能结构如图4所示。

　　在进行嵌入式软件自动化测试之前，需要设计一份配置文件。在配置文件中定义好了脚本位置、宿主机与测试之间的通信、脚本执行时间间隔、通信桩点个数等内容。测试管理工具先对脚本配置文件进行解析，并且将解析的信息传送给目标机。

　　通过插桩对待测试软件的功能进行细分，并且根据执行的情况，来分析待测试软件的测试覆盖情况。

　　测试日志文件中主要包含了待测试软件的测试结果，以及测试覆盖信息。其中测试报告中包括了测试跟踪信息、测试用例、测试用例的期望和实际结果、测试用例的执行情况及汇总等。测试覆盖信息包括：测试和未测试的代码段、功能的覆盖标记及汇总等信息。

　　测试运行在目标机上，是整个嵌入式软件自动化测试平台的核心，测试的整体结构如图5所示。

　　根据配置管理，对管理工具发送的测试脚本进行解析，并且调用工具库中的通用函数来完成测试。同时，将测试结果和桩点覆盖信息存入到特定区域。

　　在数据文件主要包含了测试脚本文件、测试数据文件和测试结果文件。当测试需要数据是，可以通过数据驱动模块完成数据表查找和数据批量处理等操作。对于测试数据量大，测试步骤类似的测试过程，可以极大的减少测试的复杂度。

　　主要负责与管理工具的数据通信模块进行数据交互。主要负责接收管理工具所发送的配置信息、脚本信息和数据文件信息；同时将测试结果和测试覆盖信息返回给管理工具。

　　软件测试是对软件质量进行评估的重要方法，自动化测试技术可以降低软件测试成本，缩短软件测试时间。特别是对于测试环境更加复杂的嵌入式软件而言，自动化测试具有更加重要的意义。

　　[1]邓勇，曾建光.嵌入式软件系统及其自动测试技术的发展与现状[J].科技咨询导报，2007，21：5-6.

　　[2]凌永发，张云生，郭秀萍.软件测试自动化中的脚本技术[J].云南民族学院学报（自然科学版），2002，11（1）：544-548.

　　[3]郑世伟.嵌入式软件的测试方法和工具[J].单片机与嵌入式系统应用，2001，4：26-28..

　　随着Web应用的日渐庞大和复杂，Web应用的测试越来越得到人们的重视，同时对Web应用的测试的要求也更高。研究表明，一种良好的自动化测试技术可以实现许多手工测试不能完成的工作。同时，自动化测试技术大大减少了产品的周期和软件的测试成本，软件测试的效率和速度也有了显著的提高。所以，软件开发组织测试工作可以采用自动化测试方法，同时结合相应的测试框架进行，这样，既提高了效率，又降低了维护成本。

　　自动化测试框架是一个由假设、概念以及自动化提供支持的实践的集合。现在，许多企业和个人都认识到Web自动化测试框架的重要作用，并积极投身于其研发中，并不断有新的框架出来。本文中描述了几种常用的自动化测试框架，并在此基础上，研究了一种实用性强的开源Web自动化测试框架。

　　自动化测试之所以得到人们重视，是应为其具有其他测试所无法替代的优点，概括一下有以下几点：1）效率高，测试时间大大减少。2）降低了测试成本，减少了开销。3）比手工测试完成的测试范围更广。4）测试可靠性、一致性和可重复性好。5）工作质量提高，资源利用好。6）软件推向市场时间更短。7）测试的复用性高。

　　尽管自动化测试有诸多优点，但在测试中仍然存在一定的局限性，具体表现如下：1）自动化测试并不适用于每种情况。2）测试的有效性并没有提高。3）自动化测试工具不具灵活性。4）对测试质量的依赖非常大。5）有时对软件开发有一定的制约。6）没有手工测试发现的缺陷多。

　　通过以上分析可知，让自动化测试完全取代手工测试是行不通的，只有将手工测试与自动化测试很好的结合在一起，才会发挥各自的优势，测试效果才会更好。

　　以下为几种常用的自动化测试框架，它是研究人员为解决脚本维护性问题而设计的。以这些自动化测试框架为基础，结合自己的经验与需求即可以设计出适合自己的自动化测试框架。

　　该框架用创建的独立的小脚本代替被测试应用程序的函数和模块，采用分层的方式完成测试。脚本的实现层作为底层，测试用例的组合层作为上层。脚本模块化框架应用了封装和抽象的原则，提高了测试套件的可维护性。为掩盖应用程序的其他部分采取在一个部件前构建一个抽象层的方式完成。该框架易于掌握和精通。但因其底层脚本的实现依赖应用程序的功能，故缺乏灵活性。

　　测试库构架框架与脚本模块化框架很相似，只是其将应用程序分解后创建的不是脚本，而是过程和函数。被测对象的功能或模块通过创建库文件来描述，测试用例脚本直接调用这些库文件。这样，抽象度更高，测试用例组装更加灵活。

　　该框架又叫表驱动测试框架，是一种比较理想的自动化测试框架。其测试逻辑的描述采用关键字和数据表实现。这些关键字和数据表可以用来“驱动”测试脚本代码，并独立执行测试工具，是应用程序和自动化测试框架彼此独立。这种测试方式与手工测试很像。

　　数据驱动测试框架是从特定的文件（如Excel文件、OOBC源文件、CSV文件、ADO对象文件等）中，把测试的输入和输出数据独立出来，通过变量传入测试脚本中。这些变量就是测试数据用来传递和验证应用程序的。在整个过程中，测试动作的控制（如数据文件的读取，测试信息和记录测试状态等）写进测试脚本中；测试数据不写进脚本，而只包含在数据文件中。这里，测试脚本只是一个传送数据的机制，或仅是一个“驱动”。

　　数据驱动测试框架是测试不同的输入、输出采用相同的测试过程，并将测试输入和预期输出以表的形式组织起来，一个测试作为表中一行。测试过程就是从表中逐行读入，即可实现执行每个测试输入和检验预期输出。将数据驱动测试过程以表组织在一起，执行新的测试就可以反复使用这个过程。这种测试需要执行的脚本大大的减少，大量的测试用例仅需少量的脚本就可实现，对由许多不同数据选项的应用非常有效。

　　米乐M6 M6米乐

　　本框架以开源框架Selenium为基础，进一步设计了此框架的“私有语言”，也就是数据驱动文件的编写规则。数据驱动文件的解析程序的实现就以这些“私有语言”为依据，Web应用的测试执行框架也是由这些“私有语言”和Selenium合并组成。依据这些编写规则，测试人员把数据和对Web应用的操作行为写入数据驱动文件中，测试框架负责对这些数据驱动文件进行解析，将这些解析后的数据传入并调用Selenium API的相应方法，从而使其自动执行。

　　该框架是基于数据驱动的测试框架，并在其基础上进行了一些改进，开源Web自动化测试框架结构如图1所示。

　　此框架中，在Server端安装被测试Web应用，可以供远程访问，方便测试。Extended Selenium RC System作为测试执行引擎安装在Client端，它是本框架的核心，数据驱动文件解析系统是采用开源自动化测试工具Selenium开发的。它的主要功能是通过解析数据驱动文件，得到解析后数据及Web操作，而后调用Selenium API的方法，并将数据作为参数传入，这样对远程Server的操作即可实现。当Server的响应到达Client，Client进行各种元素验证，记录日志文件及保存测试结果等操作。测试工程存放在Project文件夹中，主要由若干XML数据驱动测试文件组成，在Project_Config.xml测试工程注册文件中对各种数据驱动文件完成统一的注册，然后又Extended Selenium RC System按注册的向后顺序对各XML文件依次进行解析。

　　相关操作和数据的文本文件构成了数据驱动文件。由自动化测试工具私有语言手动编写这些文件，接着对其变量赋值，并作为测试数据输入。这些变量使解析程序能通过外部的数据来驱动应用程序。软件自动化测试的一个重要环节是数据驱动文件的开发和维护。对测试文本做合理地修改和调整，可以扩大测试覆盖面，增加测试脚本灵活性，并且对被测试对象变量的应对能力大大提高。

　　本框架中，设计数据驱动文件的“私有语言”是重点，其设计包括以下几个方面。

　　这一部分包括页面中数据的输入和对页面的各种操作。例如：将数据“efg”输入到页面标签中，具体设计如下：

　　其中，方法结点用表示，表示向页面标签中输入数据。具体想哪个页面标签输入数据用表示，其中value属性可以是name或id等，表示定位关键字。具体输入哪个数据，用第二个 表示，value属性中放内容值。

　　这部分是完成对页面标签及数据验证操作。同操作部分一样，方法结点与API的方法名称一致。例如：验证上例中页面中是否存在“efg”文本，具体设计如下：

　　其中与Selenium API中的isTextPresent（“”）方法相对应，表示要验证的内容结点，Value中放具体内容，本例中放的是文本“efg”。本例可以实现对页面中是否存在文本“efg”的验证。

　　若Web应用要运行在不同操作系统上，就需要设计不同版本，虽内容差别不大，但若设计不同的测试工程，则工作量会大大增加。这个问题的解决，可以采取在同一数据驱动文件中写入不同版本的数据驱动文件来解决，并只需用测试环境结点加以标准区分，就可以在解析文件过程中通过操作系统类型与测试环境结点属性值得对比，来判断是否进行解析。

　　除了以上三个方面，还应对结点名称到API方法名的映射及结构等进行合理的设计，从而使数据驱动文件可控性更强，更具灵活性及更便于解释。

　　首先将编写完的数据驱动文件添加到测试平台。接着解析数据驱动文件，实现测试脚本到执行引擎的映射。然后向Web服务器发送HTTP请求来模拟真实用户访问Web的场景，获得测试结果信息。最后，对得到的数据进行分析，得出测试报告及生成日志。

　　本文以数据驱动方法为基础，提出一种开源Web自动化测试框架，重点研究了数据驱动文件的编写规则。本测试框架可以应用不同的工程项目中，具有开发门槛低、独立性强、效率高等特点。特别适用于需要反复测试的回归测试阶段，大大提高了企业的经济效益。

　　[1]赖利峰，刘强.Web应用程序的一种功能自动化测试模型与实现[J].计算机工程，2006，32（17）：42-44.

　　[2]朱少民.软件测试方法和技术[M].北京：清华大学出版社，2005.

　　[3]朱菊，王志坚，杨雪. 基于数据驱动的软件自动化测试框架[J].计算机技术与发展，2006，16（5）：68-70.

　　[4]李晓会.Web系统自动化功能测试框架研究与实践[D].北京：北京邮电大学，2011.

　　[5]樊付星，黄大庆，周未.基于Web的自动化测试框架的研究与实现[J].电子设计工程，2012，20（20）：36-38.

　　[6]黄侨，葛世伦.开源Web自动化测试框架的改进研究[J].科学技术与工程，2012，12（15）：3630-3635.

　　[7]马春燕，朱怡安，陆伟.Web服务自动化测试技术[J].计算机科学，2012，39（2）：162-169.

　　地添加测试用例,为测试用例提供公用函数,执行测试用例,发送测试结果等功能。

　　检查点(CheckPoint):将特定属性的当前数据与期望数据进行比较的地方,用于判定被测试程序的功能是否正确。

　　成本收益比:并不是所有的测试都适合自动化测试,衡量一个用例是否适合自动化测试一个很重要的参考是国际上流行的自动化测试成本收益比,即是p=k*n/c1+c2。各个参数的意义下:

　　二八定律:1897年意大利经济学家帕列托发现的二八定律在软件行业同样适用,而可以给我们很多启发,指导我们的软件开发和测试。80%的用户经常使用的是20%的软件功能。在软件测试中,80%的bug是集中在20%的软件模块中,对于自动化测试来说,找出这20%的测试用例是至关重要的。

　　每次脚本都是从一个统一的文件开始执行的,就是如上的Start.py。这样做的好处是可以把每个脚本都需要处理的工作放到一个文件中去执行,例如收集一些配置信息,读取命令行参数。以这样统一的处理风格为脚本的可读性提供了保证,也为简化了测试脚本的编写,不用每次都要处理一些基本的事务。

　　通过python的内置函数sys.argv就可以读取命令行参数,非常方便。读取到命令行参数后,在Start.py内部可以判断命令行的格式是否符合我们的格式,如测试人员不小心把-s 写成了-z 这样就要退出测试执行。

　　如果输入的格式是正确的,Start.py 负责在特定的目录下寻找特定的Suite文件和Testcase。Suite文件和Testcase的格式会在下边的具体实例中作介绍。

　　找到特定的Testcase后就可以执行测试用例,根据检查点的通过或失败发送测试报告,该报告会以网页的形式显示,方便测试人员和开发人员的查找调试。

　　图形用户界面(GUI) 就是使用图象,输入的文字,带图标的计算机界面,取而代之了许多键盘的功能。GUI可以让用户通过图标和鼠标与计算机进行交互,而不是单调地在命令行中输入文本进行操作。设计良好的图形用户界面可以使用户从命令中解放出来。

　　GUI测试主要包括两个方面:一是纯GUI测试,主要关注应用程序上GUI组件是否符合规范或是用户的使用习惯,二是功能测试,主要是检验和验证系统是否实现了系统的业务需求,旨在验证系统的业务实现能力。但事实上两者不是完全独立的,一方面GUI的测试必定要触发功能,另一方面,功能测试也一定要通过GUI将事件传递给后台服务。

　　测试ID 466540 , 有了测试ID就可以在测试人员提交bug后,QA或开发人员通过ID找到这个测试用例。还有一个更大的用处就是,在自动个脚本生成测试报告后,可以根据测试ID把该测试用例显示在测试报告中,以供测试人员和开发人员调试。

　　测试名称,根据测试名称应该可以很快了解测试用例的内容,所以好的测试名称也是非常重要的。

　　测试优先级(Priority),测试优先级也是一个很重要的参数,因为大型项目都要有很多测试用例要执行。只有明确测试优先级才能确保重要的测试用例得以及时进行,保证软件质量。

　　测试用例概述(summary),帮助测试执行人员了解该测试用例的用测的功能。

　　测试步骤,描述测试人员或是自动化脚本每一步是怎样操作的,例如本例告诉测试人员选择菜单Fie,然后选择菜单项New。

　　预期结果(Expected Results),说明经过以上测试步骤,期望程序运行出现的结果。

　　本文在明确软件测试理论的基础上,对自动化测试做了重点阐述,通过实际项目的自动化测试分析,有些测试用例特别适合用自动化测试。例如GUI测试中,用些是要验证界面元素是否显示正常。如果是脚本就可以准确无误地很快验证完毕,而用人工验证不仅容易出错而且费时间。由于时间和硬件条件有限,本论文规避了许多问题,所以仍有许多工作需要完成。例如:做好脚本的复用,使测试脚本不断积累。及研究怎样在测试工具和自己搭建框架中寻找平衡等。

　　[1] 张克东.《软件工程与软件测试自动化教程》.北京:电子工业出版社,2002.

　　[2] 朱菊,王志坚,杨雪.《基于数据驱动的软件自动化测试框架》[J]计算机技术测试与发展,2006.

　　[3] 马瑞芳,王会燃.《计算机软件测试方法的研究》.小型微型计算机系统,2003.

　　不同的行业具有不同的工作环境，有些工作环境甚至是非常恶劣的。电气自动化控制设备需要面对多种多样的工作环境，以应对环境因素对电气自动化控制设备的不利影响。这些不利的环境因素主要包括气候因素、机械作用力因素与电磁干扰因素。

　　1.气候因素，主要包括湿度、气压、温度、大气污染、烟雾等，这些不利的环境因素会严重电气自动化控制设备的性能、损坏设备结构、运行运动灵活性以及温升过高等，甚至导致设备完全毁坏，不能正常工作；

　　2.电磁干扰因素，该因素是非可见因素，但是对电气自动化控制设备的不利影响不能小视，一般而言，电气自动化控制设备的工作充斥着各种电磁波，这些电磁波会增大设备的输出噪声，导致其工作失稳，甚至影响设备安全。除此之外，人员因素的影响也非常重要。由于电气自动化控制设备比较复杂，掌握和熟练操作的难度较大，因此，操作人员不熟练和不正确的操作均会影响甚至损坏设备；同时，对设备进行科学及时的维护与保养也非常重要，否则会降低电气自动化控制设备的可靠性。

　　电气自动化控制设备元器件的生产厂家繁多，并且良莠不齐。通常而言，生产设备元器件的厂家规模较小，质量管理体系不健全，其元器件质量便很难合格；另外，在市场经济体制下，元器件厂家之间的恶性竞争会让部门厂家只重视“价格优势”，罔顾产品质量，导致电气自动化控制设备的可靠性指标偏低，影响设备的正常安全工作。

　　在进行电气自动化控制设备可靠性测试的过程中，要对测试方式进行有效的选择，基本上需要从试验的环境、实验的场地、试验的程序及组织工作等几个方面来进行。

　　要保证测试的结果，试验场地的选择也必须慎重。一般情况下，对于试验场地的选择是有据可依、有规可循的。依照相关的经验来看，电气自动化控制设备可靠性测试试验场地的选择可遵循以下几点原则：

　　第一，如果测试试验的主要目的是对设备可靠性进行指标性的测试，那么在进行场地选择的时候，以严酷为主，尽可能选择较为恶劣的试验场地，以便于对设备可靠性运行的极限指标进行确认；

　　第二，如果测试实验只是要对设备正常运行的可靠性进行侧测试，那么相关人员在进行试验场地选择的时候，应尽量选取那些较为典型的测试场地即可；

　　要保证整个可靠性测试工作可以按照既定计划有效进行，使每一个测试环节都可以按照相应的要求标准开展，相关管理层应当针对电气自动化控制设备的测试试验选择，制定出一个系统性的、统一的程序，使现场测试人员在进行可靠性试验的时候，每一步操作都严格依照这一系统且统一的程序来进行。需要强调的是，在这个系统的试验程序当中，应当对试验的起始时间、时间间隔、数据采集、保障情况记录、性能指标记录以及故障排除等具体操作进行详细且全面的规范。如此才能够使得整个测试工作更可信、更准确。

　　组织工作可以说是保证测试准确性的重要环节，也是试验过程中最关键的部分。所以在进行电气自动化控制设备可靠性测试的过程中，必须要有一个较为高效且严密的组织机构，通过这一组织机构的组织及管理功能，对整个测试试验进行整体的把握、人员的协调以及有效的监督。

　　首先，组织工作要对相对分散的试验场地进行相应的管理与组织工作，做好对实验数据的收集、整理与分析；

　　其次，组织机构应当依照试验目的的差异，对测试所需的技术人员进行有效的选定，并做好试验工作中的协调与管理；

　　另外，从某一角度上来看，组织机构还应当发挥其应有的监督与控制作用，对最终的测试结果进行客观、科学的判定，从而使整个测试的结果更加可靠。

　　该测试方法主要是在电气自动化控制设备运行的过程中进行控制，以检验其可靠性。进行测试时，需要认真、详细地记录各种数据、并对数据进行数理统计和计算、编制设备可靠性的具体指标，比较真实地评估设备运行的可靠性。该测试方法需要是测试设备相对较少，但是能够比较真实地反应设备的真实性能（真实工作环境之下的工作性能），而且测试成本比较低，不会设备工作连贯性产生不利的干扰。然而此种测试方法的缺点也需要我们注意，即易受外界条件干扰、易受受控条件限制、再现条件较差等。

　　保证试验方法俗称烤机，是在产品出厂前，在规定条件下对产品进行无故障的工作试验。保证实验方法的不同于实验室测试方法，因为电控设备通常是由大量的元器件构成的，因此它的故障以随机性和多样性的形式表现，而不是以几种故障为主表现出来的，随着时间变化是保证试验方法失效率所具有的特性，服从指数分布。烤机就是对产品的早期失效进行测试考核，通过改进使产品的失效率在出厂前达到指标。保证试验所需的时间较长，对于小数量、大系统生产的产品而言，它适用于所有产品，但是对于大量生产的产品而言，只能用于设备的样本。

　　电气自动化控制设备的可靠性测试是非常重要的，从目前来看较为常用的方法有试验室测试、烤机测试以及现场测试几种。从实践来看，烤机测试应用范围过小，实验室测试是未来发展的主流，而从目前来看，现场可靠性测试是最为实用的一种测试方法。

　　无线射频技术（Radio Frequency Identification， RFID）由于具有非接触、远距离、批量识别的优点，逐渐成为自动识别技术中最具有应用前景的技术。随着物联网技术的发展，RFID技术已经在供应链、零售、仓库管理、生产线管理以及军队中得到了应用，目前我国物联网技术正处于由试点应用转入大规模应用的阶段[1]。由于使用电磁波方式传输数据，RFID数据传输易受到气候环境，金属屏蔽，周围材质等因素的影响。因此，RFID应用系统测试技术研究成为了热点[2]，国内外研究机构和大公司纷纷建立RFID测试实验室，研究测试技术和标准。

　　Zeng等[3]用设备部署仿真的方法研究如何提高RFID系统中读写器设备的部署问题，Porter等开发了适应八种不同RFID系统的测试协议[4]。前面所述的RFID测试系统和测试方法都是手动的，在对RFID应用测试时，只能逐一的来执行。RFID系统很复杂，需要开发一些自动化测试技术，制动测试任务后，能够自动执行测试操作。在本研究中，基于整体测试和单元测试的概念[5]，提出了一种自动化的RFID应用系统测试的方法。对于关键的影响因素（见图1）进行分析，设计了自动测试平台的框架，对于其中主要的组件进行了讨论。

　　在RFID应用测试中，数据收集分为三种类型：一是收集RFID电子标签的数据，二是收集环境数据，三是应用场景中电子标签与相关设备的运行状态。当电子标签进入到RFID读写器的识读范围内，电子标签被激活，数据通过电磁信号被传输到RFID读写器中。在测试系统中需要将待测系统中的电子标签的数据进行收集，用于数据分析。

　　电子标签内的数据在传输过程中受到气候，应用现场的电磁干扰，材质/介质等因素的影响，这些影响因素需要被相应的传感器采集，结合RFID读写器读到的电子标签数据一起，形成完整的数据分析的基础数据。

　　在RFID应用系统中，RFID设备和电子标签的运动状态、天线的位姿对RFID系统的应用效果具有明显的影响。在数据收集阶段，要将RFID设备不同场景下，不同时间的姿态数据进行记录，同时将运动的速度，方向数据进行收集。

　　如上所示，气候环境、电磁环境以及RFID设备的参数都是影响RFID系统应用效果的重要因素。如果能够使用自动控制技术对RFID读写器参数、天线的位姿、环境参数等影响RFID应用效果的因素进行控制，将提高测试的精度，实现自动控制。在实际应用场景中，RFID读写器的功率、工作状态（休眠，工作）等参数可以由业务流程来控制，读写器天线的部署参数（角度、高度）可以由自控转台进行控制，RFID电子标签的运动速度和方向可以由速度控制器来进行模拟控制。这样多种控制设备的组合就形成了RFID应用测试平台中的自动控制单元，

　　测试任务是对一个应用场景中多种测试操作的总称。复杂的RFID应用可能对应多种典型应用场景，在指定测试任务时可以按照业务流程或者功能进行划分。根据模块化概念，在测试平台中需要对测试任务进行集中管理，维护任务中的测试模块。

　　测试结果需要保存在数据库中，便于对测试结果进行分析和总结。根据测试中产生的数据类型，测试平台中包括了三个数据库：一是仿真器产生的模拟数据，作为测试的原始数据。二是中间数据库，保存了测试过程中采集的数据。三是测试结果和报表数据库，保存了测试分析的结果、报表数据等。

　　在测试过程中，需要根据测试中间结果来改变控制参数。为了解决测试时间和测试次数，可以使用进化算法来优化控制参数，使被测的RFID应用系统发挥最好的能力。图2示意了采用遗传算法来优化控制参数的流程。在测试平台中，使用者也可以采用其他的优化算法来实现对控制参数的优化。

　　根据测试系统功能分析，设计了测试系统的框架，如图3所示。包括的功能模块有：数据接口模块、RFID中间件模块、数据统计分析模块、参数自动控制模块、优化模块、数据分析算法模块、报表模块等。

　　（1）RFID读写器数据接口，是测试系统与RFID读写器之间的数据接口，传输的数据是读写器与电子标签之间读写的数据。

　　RFID中间件模块的主要功能是模拟被测的RFID应用系统的业务逻辑[7]，包括了RFID读写器控制器，数据收集器和业务逻辑建模工具。RFID读写器控制器主要控制RFID读写设备的工作、关闭、睡眠。数据收集器是记录所有RFID读写器读到的电子标签数据，识别数据的来源，按照时间线创建事件。测试过程中采集到的数据进入到数据统计分析模块。根据测试任务选择相应的数据分析算法来处理这些数据。RFID中间件中一般集成了RFID应用流程工具，用户可以配置不同的应用流程来进行测试，寻找适合的业务流程。

　　数据分析后的结果可以作为优化模块中适应度函数值来指导参数优化的进程。在进化算法的优化过程中（看图2的优化流程），经过交叉和变异新的参数种群。新的控制参数作为输入数据控制测试平台中的自动化设备，改变被测RFID应用系统的参数。待满足优化条件后，退出优化过程，测试系统根据最终确定的参数，可以给予被测RFID应用系统一些改进的建议。

　　为了验证本文提出的RFID应用系统测试平台的功能和性能，本研究中对生产线RFID数据写入和校验的应用场景进行了测试。测试场景的业务流程如图4所示。两个读写器天线米。RFID电子标签放置在产品上面。生产线上产品经过排列后逐个通过第一个RFID天线，此时写入数据。第二个RFID天线负责读取产品中RFID电子标签内的数据，校验前面写入数据的准确性，如果不合格则回流再次重新写入，合格则进入包装环节。

　　在这测试场景中RFID读写器型号为CSL-461，频率范围845～925MHz，最大读取速度1 000个/s。读写器的功率为30db。两个天线，类型为线 测试任务和测试结果

　　选择两种电子标签来进行测试，分别是Inlay Api和Inlay Apr。测试条件为室温20℃，生产线m/s，天线m。两种电子标签的指标参数见表1所示：

　　在生产线运动状态下，测试了两种不同种类电子标签的读写性能。使用80个Inlay Api和80个Inlay Apr的电子标签进行测试，20个电子标签为一组，共进行10次测试。对于数据写入操作，共有77个Inlay Api电子标签成功写入，73个Inlay Apr成功写入，成功率分别是96.25%和91.275%。

　　生产线的速度对于电子标签数据写入具有一定的影响，测试了不同运行速度条件下RFID电子标签数据的写入成功率。其他条件不变的情况下，调整生产线的速度，速度变化范围从0.5m/s到2.0m/s，速度间隔为0.3m/s，测试结果见图5。当运行速度超过1.5m/s时，数据写入的成功率下降。

　　根据RFID应用场景，设计了自动测试系统，并对生产线RFID电子标签数据写入校验应用场景进行了测试。本研究中提出的RFID应用系统测试平台的框架具有如下优点：

　　（1）框架具有较强的灵活性，能够根据被测RFID应用系统的业务需求进行灵活的重构。同时自动控制的参数数据接口，RFID读写设备的控制数据接口也是灵活的。

　　（2）测试任务可以自动执行。RFID电子标签的数据读取，环境数据的收集可以自动执行和分析。RFID读写设备的参数调节也可以自动的执行，从而实现自动对RFID应用系统的优化。

　　（3）具有自动控制、自适应优化功能的RFID测试系统代表了RFID应用测试的发展方向，我们在以后的研究中将具有自治和自适应能力的生物系统激励机制引入到RFID应用测试研究中，用于改进系统的灵活性，功能模块的自适应性以及增强数据分析的能力。

　　软件测试确保软件可靠性安全性的重要途径。随着客户对软件可靠性和安全性要求提高，软件测试也变得越来越复杂。

　　所谓白盒测试就是在测试过程中被测试对象是可见的，测试人员通过测试软件可对软件的功能是否达要求进行测试。白盒测试分静态测试和动态测试两种。

　　静态测试不需要执行程序，进行静态测试主要目的就是为了监测软件的描述和表述之间是否存在冲突。

　　静态测试中一个重要步骤就是对代码进行检查，对代码检查主要方式有，代码走查、桌面审查等方式进行。

　　对软件进行动态测试时，需要执行软件，常用的动态测试方法有三种：基本路径、程序插装、逻辑覆盖测试法。下面就逻辑覆盖法进行重点介绍。逻辑覆盖测试是基于程序逻辑为基础测试方法，采用逻辑测试法需要测试人员对程序逻辑要清楚了解。逻辑覆盖包括以下几种覆盖，语句覆盖、条件覆盖、判定覆盖、判定/条件覆盖、条件组合覆盖以及路径覆盖。

　　语句覆盖：采用语句覆盖测试首先要设计足够多的测试用例，确保软件中每条语句都可以执行一次。

　　条件覆盖：采用条件覆盖首先要设计足够多的测试用例确保程序中的每条语句都可以执行一遍，在此基础上确保程序中每条条件语句都可以获得到可能结果。

　　判定语句：采用判定覆盖首先要设计足够多的测试用例，语句覆盖基础上确保程序中不同判定条件语句最终都可以执行一次。

　　判定/条件覆盖：判定/条件覆盖本质就是判定覆盖和条件覆盖相加得到的结构，它也要在语句覆盖基础上进行。

　　条件组合覆盖：设计足够多的测试用例，确保测试过程中，各种条件组合和在测试过程中都可以执行一次。

　　在测试过程中将程序当做一个不可打开的黑匣子，测试人员也不用关心程序内部语句，利用接口进行测试。进行黑盒测试时，测试人员只需将数据输入到程序中，然后通过改变操作来改变程序输出结果，对输出结构进行记录，将测试结果与预期结果进行对比，判定软式是否可以正常使用。

　　等价划分法就是将所有需要输入数据按照一定类别进行划分，在每一类中找出具有代表性测试用例。代表性数据具有等价特性，它可以代表一类数据，当有此类数据类似测试用例时可以将其划分在同一等价类中，采用等价类划分法可以缩小工作人员在测试过程中测试用例的需求，最大程度减少测试人员工作量。

　　第一步：将测试用例范围有效等价类和无效等价类，将划分列成表，以便测试人员使用。

　　第二部：为等价类中的每一个等价类制定一个唯一编号，然后设计一个测试用例，这个测试用例要尽可能多覆盖所有等价类，重复这个步骤直到所有等价类都被测试用例覆盖为止；当所有有效等价类都被测试用例覆盖后。需要测试人员在针对无效等价类进行测试用例设计，针对无效等价类设计的测试用例，要只覆盖一个没有被覆盖的无效等价类，重复这一步骤，直到所有无效等价类都被覆盖为止。

　　实际测试经验告诉我们，许多软件出现问题时都出现在临界值处，在软件所有能承受的边缘地带而并非内部。因此，在软件测试过程中测试人员可以针对边界值设计测试用例，这样做不但可以减少工作量，而且也可以得到更好的测效果。

　　在确定边界值时首先要确定软件的边界情况；然后依照边界情况，分别选刚刚小于、等于、刚刚大于边界值数据作为测试用例。对于一些边界值复杂的软件，要想找出合适的测试用例则需要根据实际情况进行更详细分析。

　　错误推测法就是一些资深测试员依靠自己经验和直觉对程序中可能出现的一些问题进行设计测试用例。在实软件测试过程中往往都是几种测试方法综合使用。

　　1） 性能测试主要是对软件使用过程中性能否满足使用指标而进行的测试。对于软件性能测试主要包括以下几点：用户反映时间、系统反映时间、软件界面反映时间、处理器利用率以及有没有内存泄露情况发生等。

　　2） 兼容性测试目的在于对软件在使用过程中和其他应用或者系统之间的兼容性。在进行兼容性测试前首先要分析软件都可能在哪些系统中使用，会和哪些软件进行联合使用，会和什么类型数据库进行数据交换，然后依据这些可能发生的情况进行兼容性测试。

　　3） 配置测试主要注意以下几个方面：一是系统自动修改系统配置让软件可以正常使用；二是人为对系统中一些参数进行修改；三是在不同硬件组合下软件是否可以兼容。

　　自动化测试与手工测试相比有着巨大优势，但其中也有着许多不足，首先对于测试人员来说，测试员必行对自动化测试流程有足够了解，能够熟练使用自动化测试工具，善于总结测试经验，不断对自动化测试中进行完善，只要这样自动化测试才会发展得更好，走得更远。

　　[1] 佟伟光.软件测试[J].北京：人民邮电出版社，2011：1-2.

　　[2] 朱少民.全程软件测试[J].北京：电子工业出版社，2014：17-18.