自动化测试案例设计及读后感

第一篇：自动化测试案例设计及读后感

[转] 自动化测试案例设计及读后感

作者：TIB来源：博客园发布时间：2011-04-06 09:51阅读：198 次原文链接[收藏]

散步的SUN

自动化测试已经越来越深入人心，其重要性也是不言而喻的。性能测试中大规模并发的要求，压力测试中的大规模压力的模拟，回归测试中的大规模测试用例的反复执行都要求实现一个高可用、高可扩展性的自动化测试框架体系。因此，如何在一个开放的框架下，构建一个完整的自动化测试体系是我们需要研究的方向。

一个完整的自动化测试框架体系包含以下几个部分：

1、自动化测试框架；

2、测试脚本以及测试数据管理；

3、测试脚本的执行管理系统；

4、测试结果的显示与分析系统。其中最重要的是自动化测试框架部分。

第一部分，自动化测试框架。自动化测试框架要解决的问题，从本质上来说，是实现分布式资源透明化的过程。由于性能测试、压力测试的要求，我们往往需要构建一个分布式的测试环境，在这个分布式的测试环境中，我们需要多种测试平台（例如：多台windows，多台linux等）。自动化测试框架的作用就在于将分布式环境中的各种资源变成相应的服务对象。例如一台windows机器，在自动化测试的框架中，我们看到的将不再是一台windows机器，而是绑定到某一个IP地址上的一个服务对象。通过这个对象，我们可以通过一个通用的调用方法（本地调用一个远程提供的方法，需要采用对象映射的技术），告诉这个对象，让它做我们希望它去做的事情，例如启动一个指定的测试脚本（这个测试脚本可能是我们日常写的某一个测试用例，也可能是其他操作）。在自动化测试框架的实现上，其主要是建立了一个以提供服务为主的底层的通讯网络。而在服务的应用上，我们可以采用插件模式，以及对象映射的技术，可以动态的无限的扩展我们的服务。根据我个人的实践，STAF + python的开发模式可以很好的实现这个框架。STAF主要构建了一个网络体系，使得各种机器资源之间可以自由的通讯。而python则可以在STAF的基础上进行二次开发，可以构建一个动态插入的服务体系。

第二部分，测试脚本及测试数据的管理。首先要选择一种合适的自动化脚本语言。一般来说，需要考虑以下几个方面：（1）高可读性，（2）无需编译，（3）可扩展性，（4）强大的第三方支持，尤其是对各种数据源的支持。我们可以采用CVS或者SVN的方式来实现对测试脚本和测试数据的管理。在这里，主要依靠高度组织化的目录结构来实现，尤其是需要和实际测试过程中的测试套件，测试模块以及测试用例的组织结构进行匹配，分级管理。形成一个完整的测试脚本和测试用例的资源库。对于测试脚本的编写，有一些基本的要求：

1、形成一套测试脚本的编写规范；

2、测试脚本采取分层设计思想，持久层（数据资源库，对象资源库，统一IO），逻辑层（封装基本业务逻辑，实现API级调用），脚本层（实现测试用例过程，主要是描述测试步骤）。通过这些，测试工程师编写测试脚本将会变得十分轻松，测试的效率也会有大幅度的提升，大规模回归，甚至是在第一轮测试就实现自动化测试也不再是梦想。

第三部分，测试脚本的执行管理系统。大量的测试脚本编制好了以后，一个很重要的步骤就是大批量的执行这些测试脚本。通过CVS或者SVN的管理，我们生成了一个测试资源库，一个测试用例将是一个测试脚本。测试脚本执行管理系统的目的，就是要在用户定制的时间去执行用户选定的测试用例。测试脚本执行管理系统也应该能动态的追踪到当前正在运行的任务的状态，例如执行百分比等等；还可以实现多用户管理，例如同时执行多个用户提交的测试需求。同时，测试脚本管理系统还应该实现测试环境自动部署的功能。一般来说，我们在进行大规模的自动化测试之前，需要准确部署测试环境，这里就要求用最新的代码版本来进行测试。因此，测试环境的自动部署也是很重要的。

第四部分，测试结果的显示与分析系统。通过统一的IO调用，我们可以将测试过程中产生的错误信息，日志信息，以及测试结果动态的放到我们想要存放的地方。测试结果的显示与分析系统正是基于这些数据进行处理的系统。每一个测试用例在执行的过程中，需要输出大量的日志信息，这些日志信息是非常重要的。通常，我们判断一个测试用例执行结束以后，是否有Bug，常常需要深入分析这些日志信息。在测试用例执行的过程中，不光要打印相关的测试数据，实际获取到的数据，还要打印相应的测试步骤，这样才便于对测试结果进行分析。至于显示系统，主要是对测试结果的一个分类检索功能，可以生成各类报表，例如，一个300个测试用例的模块

中有多少通过的，有多少是失败的等等。有一个基本原则是很重要的，自动化测试不是为了自动化，而是为了发现Bug。如果自动化测试不能发现Bug，那么花费大量的人力物力实现自动化，也是没有什么实际意义的。因此，深入收集测试用例执行的过程中产生的各种信息是非常重要的。个人的实践经验表明，这些信息对于发现Bug起着至关重要的作用（测试步骤的描述也不容忽视）。

自动化测试体系不是一个工具，一种自动化测试脚本语言就可以实现的。它需要一个完整的解决方案才能实现。个人的实践经验表明，自动化测试框架的引入、强大的资源整合能力和有效的自动化测试体系的设计将是实现自动化测试的十分重要的因素。

特别喜欢这篇文章，从整体上把握了自动化测试，我们好多人做自动化测试，一开始就缺乏全局观念，但全局观念的修炼却又是很难很难的，不仅需要懂得各种技术，最关键的是其快速的学习能力，以及从宏观上把握整个流程的能力，因此，如果真的想帮助公司把自动化测试做大做好的话，不是一个自动化理念，也不是一个自动化工具，而是一整套的自动化测试解决方案；如果真的从这上面出发的话，我相信，做好自动化测试不是一个遥不可及的东西。

第二篇：自动化测试经验分享

一、测试的困惑

以前我时常反思，测试组的工作多吗？我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗？最终的回答却并非成正比。我们的测试工作成果往往并不理想，甚至是差。那么为什么事倍功半？这问题很难找到清晰的答案。

参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有BUG吗？不是，测试的最高境界是不需要进行测试。为什么不需要进行测试？是因为所有的问题都已经在软件各阶段中介入的测试工作中给预防解决了。由此引申，测试的定位并不是找出BUG，而是预防BUG。” 这是我培训报告中的一部分。如果测试的出发点只为是发现BUG，那么测试工作将会如何？辛苦的发现了一个BUG，之后开发针对性的修正了这个BUG，再回重新测试的过程，又会有多少人会重新被卷入，又会有多少BUG因此而产生，又需要花费多少时间，答案可想而知。这就是我们忙又不见成果的主要原因。所以改善这个问题的出发点就是改变对测试工作的认识——测试的目标并不是为了找出BUG，而是预防BUG的出现。

如何理解正确的测试目标是预防BUG的出现。首先可以从软件测试的阶段划分来看。软件测试的阶段划分为需求、设计、编码、测试、验收。但按此划分来定位测试是错误的。假如在编码阶段完成后测试出的BUG属于设计问题（这也是我们测试工作中经常遇到的情况），那么我们已经编码完成的产品就要面临着伤筋动骨的修改，这样的修改会带出多少个新的BUG出现？为这个修改我们又要重复的测试我们的新提交版本多少次？想必都有很深刻及惨痛的答案了。由此可以说明需求设计阶段的测试比编码阶段测试重要的多。在需求上出现的BUG就很有可能足以推翻整个产品。那么如果在需求设计阶段测试人员就能发现产品设计的BUG，那么就可以避免了因此而衍生的产品BUG，达到预防BUG这种测试理念的目标。

那么又如何能做好以预防BUG为目标的测试工作。“测试工作不只是一种技术，也不仅是一种活动。测试工作的成功也不能取决于测试成果，测试的BUG越多并不能证明测试工作做的好，所以由此引申，测试工作要站在团队的高度来开展，在团队中做好测试，而不是在测试小组中做好测试。”这是我培训报告中的另一部分。要做好以预防BUG为目标的测试工作，首先要尽早的参与到项目中，其次就是需要各部门及小组的大力支持，与业务、项目、代码人员共同形成团队，在团队中影响其他小组提高产品质量，更好的完成以预防产品出现BUG为目标的测试活动。

总结来看，我个人觉得拥有这样的测试理念可以解开我们的疑惑，带领我们走出目前的困境。

二、自动化测试迷失

随着工作、发展、提高等等多方面的需要，我接到了开展自动化测试的研究工作。概念上来说自动化测试是一种测试度量体系。现实点来说，自动化测试可以为我们自动、无误的运作完成大量且需要重复执行的测试用例。这是多么让人振奋的概念。甚至可以解开我上文所提到的有关测试工作的困惑。我很兴奋的去展开研究目前最流行的自动化测试工具之一QTP。甚至设计出了管理中心的三个重要功能的自动化测试脚本，并且运行无误在自动化测试讨论会上兴奋的向大家演示。之后还用工具按键精灵设计出了前端的A类测试用于实际的测试。但很让人沮丧的是最终这些脚本全被遗弃在电脑硬盘的角落，再也没派上用场。为什么？因为他们维护起来很困难，因为他们编写它们的时间与实现的价值并没有超过手工测试。这就是自动化测试吗？怎么不可行啊，我有点不太相信这种结局，所以我再一次困惑了。

外部培训的老师这样告诉我们：“我们并没有理性的看待自动化测试，自动化测试并不是我们看上去的那样美。首先自动化测试能直接的节约成本、让测试人员变轻松的想法是一个误区。因为原本用于手工测试的时间用来编写及维护测试脚本了，而完善的自动化测试脚本编写或维护的时间很可能会超过手工测试的时间。再者自动化测试脚本用例是测试人员所编写，自动化测试只能是沿着该测试人员的“足迹”前进。所以用自动代测试来发现更多软件产品问题的想法也是一个误区。其次并不是所有的测试都能自动化，测试的自动化也不一定是解决问题的最佳手段。”

听完这些，原本困惑的我又多了份惊讶，一方面惊叹产述的这些状况与我之前的自动化测试的试行失败是相近的。另一方面又猜疑这自动化测试该不会像共产主义社会那般吧！随着培训内容的展开，我终于解开了困惑，何为理性的看待自动化测试。

“如同不能指望原始社会拥有了汽车就能进入现代社会一样，自动化测试工具永远都不能主导测试实现自动化”（出自国信培训文档）。我们错误的把自动化测试看成了一种测试工具或测试手段。自动化测试是一种理念，它要发挥它真正的作用就需要这种理念转变为一种体系——自动化测试体系。

“引入自动化测试的前提是已经建立了合适的自动化测试体系，如果没有这些，而片面的追求自动化，无异于缘木求鱼。自动化测试体系是指能够适用某种环境的测试工具、过程、人员结构、方法的综合，运用于整个项目团队”。回到我之前的对QTP研究失败的原因，首先我开始就觉得因为研发的设计、编码实现并没有考虑到自动化，而导致自动化脚本的编写非常吃力。比如产品页面项目的命名不规范，导致自动化测试工具很难捕捉这些页面对像。其次就是测试脚本的方向迷失，我在研究QTP的时候就发现了这个问题。随着我一点点的在编写着脚本，我不断的发现自己在的测试脚本的编写方向上出现了迷失。这段脚本我编写的目标本来是功能测试，但随着我的补充却接近于开发级的单元测试。而另一段本属于功能性测试的脚本，因为功能的重点需要，我又补充了部分脚本导致整个测试脚本测试目标变成了完整关联性测试。而做为单元测试的脚本却并没有在开发的角度上来设计，根本做不到函数、类等代码级的测试，根本不能达到要求。做为完整性测试的脚本也无法模拟接口功能中几何倍数级的各种条件输入对应的输出测试。而功能测试脚本算是硕果仅存，但随着开发对产品的代码大规模调整（这些调整当然不会考虑对已经实现的脚本的影响）而直接“报废”。如果需要脚本继续工作，那么就要花时间来修改调整它。这些脚本的结局又再一次可想而知了。

所以首先我们要理性的看待自动化测试，不要片面的去追求它。对不同的项目要开展不同自动化策略。参考如下

（1）评审项目中特定的部分作为应用自动化的候选对像。

（2）从项目中高度冗余的任务或场景重点考虑自动化。

（3）将乏味且人工容易出错的工作重点考虑自动化。

（4）将回归测试经常需要“照顾”到的部分重点考虑自动化。

（5）自动化开始时要首先关注开发成熟、理解透彻、相对稳定的且不易变的部分优先考虑自动化

其次，自动化所实现的最大价值目标是可不间断的、可重复的自动执行对需求、设计、代码全面覆盖的大量测试用例从而预防bug的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。

第三篇：软件(自动化)测试工作总结

2012年工作总结

2012年自动化测试工作严格按照要求，保质保量完成客户指派的任务。截止目前，已完成话费收取、账单查询、产品变更、营销活动等137项关键业务测试用例、105个自动化回归测试场景设计，范围涵盖个人业务、家庭业务、集团业务、账务管理、营销活动及各类常用查询功能。陕西公司在大型版本上线时均进行关键业务自动化回归测试，降低了新版本上线风险，保证了新版本上线后关键业务和常用业务正常受理。累计已进行新需求上线前后回归测试68次，运行业务脚本13100余次，发现系统原有缺陷38个，新需求缺陷69个，进行业务规则梳理146个，为新需求影响范围分析提供了数据依据，较大程度的提高了上线成功率，降低了上线后系统的缺陷率，提高了系统的稳定性。

从2012年5月份入职到现在的多半年时间内，主要对系统，业务的深入理解，学习。对工作中所运用到得工具熟练掌握，每次上线都能按照要求，独立完成分配的任务。对自动化脚本进行重新整理改进，发现问题及时联系局方人员进行协商，处理。

主要工作内容是负责自动化测试这块，自动化测试的目的在于保障在新业务上线后，能正确的把控新上线内容对整个生产环境的影响。确保在新业务上线过程中，及早发现关键业务的情况，判断其是否受到影响，同时确定新上线业务是否满足要求，达到预期的功能目的。每次上线加班，严格按照要求进行测试，仔细记录测试中发现的BUG，当天寻找开发或相关负责人进行解决，每次按时到达工作现场，认真对待工作，至今没有由于个人原因出现严重过错。其他时间，对测试环境，测试数据和脚本进行维护，管理。领导每次分配的任务认真对待，按时保质完成。

工作中存在还需要以后改进的几点：

1、对业务的熟悉度更进一步了解，拓展。

2、对脚本进行改进，创新，能够更全面的覆盖测试面，争取最大限度的找出问题所在。

3、在测试工具，软件，脚本等方面进行创新，提高测试正确度，测试效率，真正达到自动化测试的目的。

以后主要对自动化更深一步的了解，学习，还有对移动业务庞大的系统进行深入了解，经过这样紧张有序的一年，我感觉自己工作技能上了一个新台阶，做每一项工作都有了明确的计划和步骤，行动有了方向，工作有了目标，心中真正有了底！基本做到了忙而不乱，条理清楚，从根本上摆脱了刚参加工作时只顾埋头苦干，不知总结经验的现象。针对个人和工作上存在的不足，我会不断的去改善，好的习惯继续保持，同时也会不断更新自己的知识库。

第四篇：.自动化立体仓库案例

自动化立体仓库案例

案例一：

广西首座全自动智能化立体仓库近日在北生药业科技园建成并投入使用，这表明广西的仓储业已向现代化大步迈进。据介绍，这座立体仓库投资近千万元，占地面积1758平方米，分为作业区和仓储区，仓储区由六排层货架组成，每排货架长92.4，高9.71米，共有3312个货位，每个货位最大承载量为530公斤，总承载量为1755吨。该立体库采用了目前国内最先进的仓储技术，突破了传统仓库的平面化模式，充分利用垂直空间，占地面积小，存储量大；温度、湿度、光线、通风等全部由电脑监控，能够自动调节到最佳状态；货物入库和出库全部由电脑控制的叉车和堆垛机完成，无需人工搬运，存取快速方便；具有自动识别系统，能准确地识别库存货物的入库时间、合格品、不合格品和退货，出货时自动做到先进先出，保证库存货物不会过期存放，也不会发错货物；取货物绝对牢靠，完全避免了人工搬运货物经常出现的失手摔坏货物现象；其中电脑系统能实现出入库账目处理，并能与客户的电脑联网，实现信息和资源共享。

案例二：

大阪物流配送中心建立了自动化立体仓库，采用了自动分拣系统和自动检验系统，从进货检验、入库到分拣、出库、装车全部用各种标准化物流条码经电脑终端扫描，由传送带自动进出，人工操作只占其中一小部分，较好地适应了高频度、小批量分拣出货的需要，降低了出错率。特别值得一提的是大阪物流配送中心为解决部分药品需要在冷冻状态下保存与分拣而采用了全自动循环冷藏货架。由于人不便进入冷冻库作业，冷冻库采用了全自动循环货架，取、放货时操作人员只需在库门外操作电脑即可调出所要的货架到库门口，存、取货作业完毕后再操作电脑，货架即回复原位。

富士物流配送中心具有配送频度较低、操作管理较为简单的业务特点，在物流设备上采用了最先进的大型全自动物流系统，从商品保管立体自动仓库到出货区自动化设备，进、存货区域的自动传送带和自动货架、无线小型分拣台车、电控自动搬运台车，专职分拣装托盘的机器人，全库区自动传送带等最先进的物流设备一应俱全。在富士物流配送中心，由于自动化程度很高，虽然其最大的保管容量达到8640托盘，最大出货处理量可达1800托盘/日，一天可安排10吨的进出货车辆125辆，但整个物流配送中心的全部工作人员才有28名。另一方面，虽然目前在日本有30％以上的物流配送中心使用富士通公司开发的物流信息系统和相应的自动化物流设施来实现物流合理化改革，逐步取代富士通东京物流配送中心，但大部分的物流作业仍然使用人工操作，没有引进自动化仓库、自动化分拣等自动化物流设施。他们认为，日本的信息技术更新换代非常快，电脑车一般一年要升级换代3次，刚安装的自动化装置可能很快就进入被淘汰的行列或者很快就需要投资进行更新以适应信息系统的发展变化。而物流的实际情况也是千变万化的，单纯的自动化设置不能针对实际情况进行灵活的反映，反而是以人为本的标准化作业更有效率。所以，富士通东京物流配送中心的最大特点是设定了简单而又合理的库内作业标准化流程，而没有采用全自动化的立体仓库和和自动化分拣系统。

第五篇：自动化测试方法改进方案

自动化测试方法改进方案

自动化测试是测试领域中一个争议性比较大的区域，虽然它并不是一个新生的事物，但是至今仍没有一套比较完善的理论可以提供行之有效的方法，使之更好的为产品质量服务。各个研究机构和公司的专家提供了许多自动化测试的理论和模型，但是均没有形成通用理论，被大众广泛认可。

作者通过对安全产品进行自动化测试，从需求定义开始进行跟踪，涉及产品的设计与实现，对产品的接口、实现功能等进行自动化集成测试，采用测试代码和测试角本相结合的开发方式。作者总结了在工程中遇到的问题和实施中的成功之处，提出改进意见，对自动化测试人员具有较强的工程参考意义。

二、自动化测试简介

所谓自动化测试，就是充分利用测试理论和相关的工具，对产品进行自动化的测试，减轻甚至摆脱某些人工测试的繁重劳动，能够形成统一的测试报告并发布。

自动化测试涉及面很广，可以涉及单元测试、集成测试、系统测试、压力测试等诸多方面，针对不同的测试有不同的处理方法和工具。

经过实践，业界对自动化测试形成了一定的统一观点：

自动化测试不能代替手工测试;

自动化测试进行的是常规测试和回归测试，测试集覆盖率和BUG发现率均不高(这两组数据没有定论，根据测试系统的不同，数据会有所不同，但均低于50%，甚至低于30%)。

三、测试中的“人”

人永远是软件开发领域中的重要因素，不同的人掌握着不同的角色。充分调用不同角色的主动性，可以有效的提高自动化测试的效率。

1.领导支持

自动化测试是个系统工程，测试人员要制定合理完善的测试用例，需要得到需求、设计、开发等相关人员的配合。没有领导的鼎力支持，各方力量配合将会减弱，测试的实现目标将会大打折扣，测试工期也将无法保证。

因此从需求调研之初，就需要得到领导的大力支持，充分估计自动化测试所能达到的目标，制定良好的开发计划，如有可能，由项目经理直接进行领导，以期达到自动化测试的最优效果。

2.避免测试人员“挪作他用”

在许多公司，自动化测试均不是专职人员，经常是针对产品从研发、测试等部门抽调而来，因此他们原来都负担过别的工作。在自动化测试工作过程中，尽量不要由于其原工作问题，将自动化测试人员调回，更不能因为自动化测试在前期开发过程中收效甚微，在开发工期有限的情况下，暂时裁减开发人员。由于自动化测试工作量很大，从理解需求、设计用例、用例实现、测试驱动的设计与开发，到用例调试、用例的最终应用要经历比较长的工期，经常性的人员调动会导致工作情绪的波动和工作进度的滞后。

四、文档工作

在项目管理中，文档是软件工程各阶段的产品和依据，自动化测试当然也不能例外。

1.测试文档要及时

自动化测试与其说是一种任务，更不如说是一个公司知识库的积累过程，测试代码绝不是自动化测试的最终目的。

因此在测试开发过程中，要随时书写自动化测试的配套文档，并要根据需求和设计的变化，即时更新。文档包含自动化测试的设计、实现文档，测试集测试用例文档，测试驱动文档。测试文档的积累，也是对公司知识库的积累，减少将来进行同样开发的成本。

2.开发文档要完善

自动化测试的根本是文档，它依靠需求和设计文档来开发用例，而绝不是根据开发人员实际代码来进行的。因此在自动化测试开始工作之前，要准备好各种文档，包括需求、接口设计、数据库定义等，测试人员只有依据这些文档，才能制定合理的开发计划，开发出适合本系统的测试用例。

一定要避免由于工期等原因，产品的需求和设计文档跟不上，甚至编码前几天，需求设计才最终确定，在开发过程中也要避免频繁的更改需求和设计，其结果经常导致自动化测试人员开发测试用例“无依据”，常常要跟着开发人员跑，而不是跟着文档跑，期间的沟通要花费了大量的时间与精力。同时已经存在的文档如果经常发生变化，如果通知不及时，也会导致开发成本的加大。

通过自动化测试，可以达到检查开发文档，促使开发流程规范化的作用。

3.自动化测试报告清晰

自动化测试之所以在业界一直得以推崇，就是因为测试的自动化、报告的自动化，倘若缺少一份有效的自动化测试报告，即使有再全面的测试用例，别人也会对工作感觉很茫然，缺乏到工作的全面了解。

测试报告中，除有明确的统计数据(包括测试用例数据、通过率等)，还需求提供测试的跟踪信息、测试用例失败的原因分析。特别是由断言失败导致的失败原因分析，应具有很好的原因说明，良好的可读性，对问题有很好的描述与定位，可供自动测试人员、开发人员、设计人员和领导等多方人员阅读，对测试结果有很好的理解和定位。

自动化测试报告最好要做到妥善保存，利用测试报告可以跟踪项目进度，把握功能点的完成情况，同时也有利于BUG的回归查找。

五、方法的改进

在实施过程中，需要掌握不同的处理方法，应对处理各种实际问题，包括人员情绪。

1.沟通方式要完善

确认了自动化测试，就需要把自动化测试工作纳入到项目的统一安排之中，把自动化测试人员也做为需求、设计、开发的相关共利者，当发生改变时，要即时通知，以便修改测试用例，避免编码或设计已发生改变，而自动化测试还不知道，其结果将导致查找原因花费大量时间。

沟通也发生在人际关系的处理上。为充分理解需求与设计，自动化测试人员不可避免的要找设计人员沟通产品设计，有时还可能是频繁的询问，遇到设计人员工作重或心情不好，就有可能导致沟通上的困难或不充分。因此沟通需要技巧，测试人员需要耐心与细心，与开发人员保持好的关系，同时要尽量把问题一次沟通清楚，避免沟通不清导致测试用例返工，由此导致工作量的浪费。

对于基于组件的自动化测试，需要开发人员对功能充分的理解，明白自己开发的功能必须依靠什么组件，模块运行必要的支持组件。开发人员理解不充分，就会浪费测试代码的调试时间，直接影响最终的部署。

2.测试用例代码健壮性有待提高

测试用例的代码应具有很好的健壮性，理想的测试用例代码本身不会引入错误误报，断言错误时，只能是被测模块发生了失败。而在实际实施过程中，测试代码的健壮性很难保证，一方面由于测试用例代码编写人员本身编程水平不能保证，很可能产生代码上的BUG，另一方面由于需求和设计的变化，测试用例本身也要随时发生改变，测试用例更新不及时，就会导致被测模块的失败，因此及时沟通，及时更新用例代码，也是非常有必要。

3.避免测试驱动滞后

测试驱动是实现测试用例的根本，由于分工和涉足点不同，自动化测试人员只能完成很少一部分测试驱动，其它驱动由开发人员完成，测试人员只是负责定义驱动的输入输出接口。

但是开发人员有自己的任务，编写测试驱动势必增加其工作量，影响其原有工作的进行。为了自动化测试的正常进行，必须要与开发组领导进行充分的沟通，合理安排开发人员工作量，在不影响原有工作的基础之上完成测试驱动。

测试驱动实现的滞后，将影响测试用例的调试和最终部署，影响整体流程。

4.多种自动化测试工具的引入

一种产品可能会包含各种功能组件，比如数据库、界面、通信等各种操作，因此要引入不同的自动化测试工具，完成不同功能点的测试。如界面操作的角本录入WinRunner、压力测试工具LoadRunner等，各种工具的引入，可以使自动化测试的测试用例覆盖率扩大，使自动化测试更加深入和全面。

5.自动化测试工作的必要性

这一点也是最难处理的。自动化测试由于缺少成型的理论指导，常常导致没有达到理想的效果，使领导和开发人员怀疑其工作的必要性，同时也可能成为软件项目管理中的“鸡肋”。

如何考虑这个问题呢?是否有必要设置自动化测试这一环节呢?

要处理这种心理落差，就需要在开始工作之前，领导及相关人员确立切实可行的目标，考虑清楚自动化测试测试用例的覆盖范围、BUG率等，不要过于乐观的考虑自动化测试的工作成果。根据实际情况制定切实可靠的目标，使获得的回报更驱于理性。公司原有自动化测试的知识储备、自动化测试人力资源的部署、整体团队的配合等诸多因素都会影响工作的最终效果。

六、结束语

自动化测试是一片新鲜的土壤，虽然没有特别完善的理论，但是只要在实施的过程中把握好几条重要的原则，一定可以达到很好的效果。