自动化测试学习历程感悟--（定稿）

第一篇：自动化测试学习历程感悟--（定稿）

软件设计与自动化测试学习历程感悟

序言：最近一段业余时间都在进行web编程设计，采用的是JSP技术，虽然JSP在网站设计上过于复杂，可是其能帮助学习java的思想，而且觉得在理解自动化测试方面颇有些帮助。自动化测试设计也是软件产品设计的一种，不过为了在此区分，一个为被测试软件的设计，一个为测试软件的设计。前者是面向特定用户使用的，后者是面向测试人员使用的，前者是为了帮助特定用户实现某个场景、提高生活效率。后者是为了帮助测试人员完成测试工作，提高测试效率。

回想自动化测试过程和软件设计学习过程，后来看了一个人所谓的软件设计学习历程，颇有感悟，当然，只是在这里说说自己的感受，也许说的有点乱，读者需要保持一颗自我和清醒的心。

软件设计学习过程：

某位人士23岁毕业，对Java的优雅设计情有独钟，其Java技术之旅开始了。

1、最开始三个月，开始接触Java，比如接口、继承、封装等，买了本《Think in Java》天天啃，并且同时做项目实践。猛学了三个月后，对面向对象编程OOP熟悉了，原来脚本式思维和对象思维确实有差别。

2、三个月后，开始啃《Core Java》，《Effective Java》，对Java有了更深入的了解，回调的概念也有了，逐渐接触到更高的层次，面向对象设计OOD，这时又看了一本书《Head First Design Patterns》，感觉设计模式特别有趣。再写代码，已经不是面向实现编程，而是面向设计编程。感觉写Java代码太简单了。逐渐了解了WebWork等Web框架的使用。

3、六个月过去了，Java瘾越来越大，逐渐开始往更高层次攀登，这时，又看到两本书《企业应用架构模式》、《UML和模式应用：面向对象分析与设计导论》，已经开始从设计往面向对象分析OOA、架构攀登了。Hibernate已经比较熟悉了，了解Hibernate背后的持久化技术、Spring背后的IoC容器、组装技术原理。

4、一年后，他逐渐脱离了Java语言，开始看这类书《面向模式的软件体系结构卷1》。这个阶段持续了一年，并且对以前的学过的设计模式，如命令模式、观察家模式有一个更深入的了解。因为两年的企业应用开发，他已经熟悉了Java EE的十来种规范，对Web容器和Servlet规范的关系有很深的理解，对JDBC规范和数据库驱动程序的关系也很了解。他正在经历Java开发的快速上升期。

5、两年后，他突然发现，他学的很多东西都没用，都是纸上谈兵，比如，在自己的企业应用开发中，Command模式、Template从来没有用过。他还发现，本来100行写的一个功能，花了1000行，就是为了所谓的设计优雅性：可扩展。而实际上，还没有等到扩展，该系统就已经废掉了。他发现原来设计模式主要用在系统框架开发，而不是应用开发，一般开发人员不用，只需要理解。他还发现，他认真学过的JMS、JCA、JTA、EJB像是从来没有用过。突然他想通了，JMS、JTA可能是一种无奈的选择：处理遗留系统。当他开始对自己两年学到的知识进行反省、批驳时，他已经有了技术辨别能力，知道技术推广也不是那么纯洁，也有商业炒作。这时候，他已经不限于Java了，开始了解C#，Ruby，发现Java可能并不太适合互联网开发，PHP可能更适合，ROR开发更快但需要在牛人的手里。两年后的这个时候，他才开始真正驾驭Java，他已经不再限于Java，而是企业应用。这个时候，技术提升的速度越来越慢了，因为不知道还可以学习什么新技术。因为他发现，原来这些东西，最深层次的，都是几十年前的技术概念：消息系统、异步通讯、事件机制等等....6、三年过去后，他已经不再限于企业应用，而是解决方案，技术只是一种解决问题的方式，比如企业信息化成功的关键，恐怕不是技术，而是企业本身的业务流程成熟度;企业信息化成功的关键，不是处理好了技术，而是处理好了几位企业高官的利益。这时候，对IT行业新闻，逐渐有判断力和免疫力。他突然发现，技术的力量很有限，商业才是最大的驱动力量。而此时，他已经不再钻研技术细节，比如JVM的垃圾回收机制，如果他在一个技术研发型公司，比如普元，可能还会深入挖掘技术。如果他在东软这类行业应用开发企业，这类企业的口号是Beyond Technology，这时候他再执迷于技术而轻业务，恐怕不太受欢迎。这个时候，技术的提升，就会进入一个平台期。

自动化测试学习过程：

自动化测试的整个学习过程中，不断在探索，虽然时间不算很长，但是确实是在一直在思考、一直在观察、一直在领悟：

1、刚开始的时候，是从手工测试入手，偶然之间开始了自动化测试之旅，发现自动化测试很神奇，在进行自动化测试用例撰写过程中(命令行的填充)，对脚本技术(tcl)猛学了几个月。

2、若干月后，随着自动化测试用例加多，偶然开始有了结果的输出、日志的记录以及脚本库。在不清楚所谓的框架时，形成了一个简单的“框架”。

3、之后，需要对界面进行测试，开始研究自动化测试工具，之后在领悟了其神奇之后，开始疯狂的学习商业自动化测试工具(RFT、QTP等)，因为主要是研究RFT，被其ITCL的框架深深打动、后来在实践过程中，脱离了录制，开始迷恋基于工具的各种框架。RFT的ITCL、QTP的轻量级框架以及各种工具的自动化测试框架，后来也学会了自己去拓展这些框架。

4、之后，因为对RFT的学习，开始喜欢上了java设计，每天都享受应用java设计，开始沉迷于技术，想着如何去用技术完善自动化测试，开始不注重那些已经搭建好的脚本环境。

5、到了现在，突然回过头发现，自动化测试最害怕的事情就是一群疯狂技术者的游戏，其实最基础的还是踏踏实实的把需求做好，以前所设想的搭建的业务分层现在不是主要问题，以前设想的如何去跟踪命令行的变更问题，到现在也不是主要问题，其主要问题是一个简单的技术是否实现了其需求正常的落地了，发现现在真正用起来的东西才是最好的。而更多的技术只是在需求不能得到满足的情况下去拓展的。

6、当然，工具、编程、框架都是必须的一个过程，关键是不要纠结于一些技术细节而不去向前，要看到主要和本质的东西，其工具、编程、框架、流程最终都需要转换成思想，不管何种方式都信手拈来，成为满足需求中的一部分。所以接下来，我觉得，自动化测试的学习道路有两个阶段，第一个阶段，以技术学习为基础，不断进行技术方面的探索。然后，每隔一个阶段，跳出技术的视野，去挖掘一定的自动化测试需求，其痴迷的细节不是技术方面，而是自动化测试需求方面，从另一个角度说，也是测试的方式和需求。

7、而在学习java的过程，也接触过J2SE、J2ME、J2EE，用了swing界面，也进行web设计，进行最基础的设计、也应用了一些框架，在没有多少实践的时候，就开始专研设计模式且一直以数据结构为伴随，后来在进行整个系统设计中，也学了一点系统建模以及数据库建模，但总的来说，还是处于模糊状态，也曾迷恋过，也曾迷茫过，一直处于一种不断怀疑、不断痛苦、不断惊喜的过程。

其实个人想说的是，上两种方式，并不是去评断其好坏，不管什么方式，都有其好坏性，大家看看热闹就行，但是每种方式、每种领悟都是一段过程的结果，最重要的是我们坚定一个学习的信念不断学习下去，学习但不要迷恋于技能、要总处于一种简单的自我怀疑状态，一切以价值实现为导向即可。

突然想起，以前看的一段话：人早期看山是山、看水是水;中期看山不是山、看水不是水、晚期看山还是山、看水还是水，也许就是说的我们这一段学习过程吧，刚开始因为单纯，所以我们能够简单应用那些知识实现我们的需要就行，后来学习的深究，各种技术交杂在一起，人难免会有点晕眩，不能把控好自己的方向，后来，才发现不论什么方式，其实最终目的还是为了需求，不管简单或者复杂，能够把控好自己，把控好整个流程就好。

所以，自己还在技术的迷乱期，需要的还是不断的学习，这就是一个过程，所以相信，最终还是会有一个接一个的领悟，但关键是坚持啊，坚持啊，不管迷茫、不管怀疑。

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

一、测试的困惑

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

参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有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的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。

第三篇：创业历程和感悟

创业历程和感悟

我在这六年的创业历程中，正如刚才VCR中所说，一路走来有激情，也有迷茫，在创业的路上我要感谢政府和社会各界对我的大力支持，感谢我的团队给了我前进的动力，我也曾经抱怨，但我从不抱怨社会，我直报怨我自己的努力不够，能力不足。因为这个社会给了我们每个创业者太多的机会，太多的资源。

对于创业者来说我是幸运的！我为我的选择而骄傲，农民对于我们每个人来讲都有不同的认识和认知，我和我的父辈都是以种地谋生，我的创业初衷就是要把农民从田间地头拉回来，从温饱线上拉回来。因为我能懂的农民的艰辛和不易，通过这几年的努力我感到我的选择是对的。我的梦想也会实现。应为我坚信“只要我的梦想足够大，全世界都会来帮我”

走现代农业道路是解决目前中国农业发展的唯一出路，食用菌工厂化生产是现代高效设施农业的最具有代表的产业，食用菌工厂化生产是按照菇类生长需要设计的封闭式厂房中，在不同地域不同气候条件下利用温控、湿控、风控、光控设备创造人工环境；利用机械设备自动化（半自动化）操作，高效率生产；他集约用地、绿色、环保。六年的摸爬滚打锻造了我坚定的信念，我坚信“打造中国养生菇第一品牌，做中国食用菌行业领跑者的目标”在不久的将来就会实现，因为我得到了来自大家的支持，来自全世界的帮助。

第四篇：软件测试学习感悟

学习软件测试的感受及体会

这学期学习了赵培英老师教授的软件测试这门计算机专业的专业课，我们学院又开设了刘老师的关于这方面的讲座，更彻底的使我们加深了对软件测试的认识。所以我想谈谈关于软件测试的体会及学到的一些知识。

作为计算机专业的一门很重要的课程，在计算机领域占据着不可替代的角色，随着人类社会的进步，各种领域计算机的普及，计算机软件也越来越多的出现在各个场合，为人们的办公，生活，学习，休闲等提供了前所未有的方便。软件测试，其目的是：第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。作为计算机专业的学生，我想以我自己的观点来阐述一下我对软件测试的理解。

以前，就是在我没有认真了解测试行业之前，我也一直认为测试应该是不重要的，甚至认为有必要有专门的测试职业吗？认为软件主要是开发人员的事，软件的成果也是由开发人员决定的，当我学了软件工程这门课，真正的了解到它的必要性，事实上真的不是那么一回事哦。软件无处不在，然而，软件是人编的——所以不完美。

我还查阅了一些资料就是不注意软件测试的案例：

1、迪士尼的狮子王（1994～1995）软件在少数系统中能正常工作，但在大众使用的常见系统中不行。后来证实，迪士尼公司没有对市场上投入实用的各种pc机型进行正确的测试。

2、英特尔奔腾浮点除法软件缺陷（1994）英特尔为自己处理软件缺陷拿出4亿美元支付更换坏芯片的费用。导致付出如此昂贵的代价，其主要原因是发现了软件缺陷没有正确的处理。

3、美国航天局火星极地登陆（1999）该项目使用前有经过测试，两个测试小组双方独立工作都很好，但从未走在一起。

4、爱国者导弹防御系统（1991）一枚导弹在多哈击毙28名美国士兵，症结在于一个软件缺陷：一个很小的系统时钟错误累积起来就可能拖延14小时，造成跟踪系统失去准确度。在多哈袭击战中系统被拖延100小时。

5、千年虫（大约1974）估计世界各地更换或升级该系统程序解决原有2000年错误的费用已经超过数亿美元。

这就是不注重测试的一些严重后果，因此我们发现了软件测试的必要性！在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则，包括： 1、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计划和设计。、Pareto 原则应用于软件测试。简单地讲，Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ”。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5、为了达到最佳效果，应该由独立的第三方来构造测试。“ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。

6、不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现.。

还有就是关于软件测试的分类：从是否需要执行被测软件的角度，可分为：

－静态测试

－动态测试

从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为 ：

－白盒测试

－黑盒测试

关于静态测试和动态测试：（1）静态测试是指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误的过程。

其中包括代码测试、界面测试和文档测试3个方面。对于代码测试，主要测试代码是否符合相应的标准和规范。对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。对于文档测试，主要测试用户手册和需求说明是否符合用户的实际要求。

（2）动态测试是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以，我们判断一个测试属于动态还是静态测试，唯一的标准就是看是否运行程序。

关于黑盒测试和白盒测试 ：（1）黑盒测试

指的是把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子，只关心软件的输入数据和输出结果。

黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误: • 是否有不正确或遗漏了的功能?

• 在接口上，输入能否正确地接受? 能否输出正确的结果? • 是否有数据结构错误或外部信息(例如数据文件)访问错误? •性能上是否能够满足要求? • 是否有初始化或终止性错误?

用黑盒测试发现程序中的错误，必须在所有可能的输入条件和输出条件中确定测试数据，来检查程序是否都能产生正确的输出。但这是不可能的。

黑盒测试的测试用例设计 •等价划分法 •边界值法 •错误推测法 •因果图法（2）白盒测试

指的是把盒子盖打开，去研究里面的源代码和程序结构。白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。使用被测单元内部如何工作的信息，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

白盒测试的主要方法：

•逻辑驱动测试

•基本路径测试

主要用于软件验证。

使用程序设计的控制结构导出测试用例。

逻辑驱动测试：

主要是测试覆盖率，以程序内在逻辑结构为基础的测试。包括以下6种类型：

•语句覆盖

•判断覆盖

•条件覆盖

•判定-条件覆盖

•条件组合覆盖

•路径覆盖

白盒测试的主要目的

• 保证一个模块中的所有独立路径至少被执行一次；

•对所有的逻辑值均需要测试真、假两个分支；

•在上下边界及可操作范围内运行所有循环； •检查内部数据结构以确保其有效性

测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）；第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息；第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。

经过这一门课程的学习和老师的给我们的讲座，意识到测试并非是我想像的从客户角度任意使用软件产品，从而发现有无质量问题，它有它的理论和实践体系。软件测试是一项严谨的工作，软件测试员一个基本的素质是打破砂锅问到底。喜欢找出那些深藏不露的系统冲突，乐于处理最复杂的问题，外表上热衷於来回奔忙，追求尽善尽美，为征服系统而额手称庆。

最后特别感谢老师对我们的课程学习的讲授，让我们了解到计算机更多的知识，也让我们了解到求职关于计算机方面的岗位，应具备哪些专业知识，谢谢老师！

第五篇：自动化测试平台学习总结

自动化测试平台学习总结

学习工作内容

在如下的案件流程中：

1.自动化开发平台_数字法院3.4_民事_中院_一审案件_走审查走审批_全子表流程

2.自动化开发平台_数字法院3.4_民事_中院_二审案件_走审查走审批_全子表流程

3.自动化开发平台_数字法院3.4_民事_中院_公示催告案件_走审查走审批_全子表流程

4.自动化开发平台_数字法院3.4_民事_中院_申请支付令审查案件_走审查走审批__全子表流程

5.自动化开发平台_数字法院3.4_民事_中院_民事再审案件_走审查走审批_全子表流程

添加新案件来源的模块到流程中；

添加新法标_接待新案件模块到流程中； 添加新结案方式到配置中；

添加完之后将各个案件流程跑通；

准备工作：登录自动化平台点击客户端下载“页面元素抓取工具”，运行自动化平台最好使用“猎豹浏览器”，因为IE用于抓取页面信息，区别于自动化测试平台登录，这样截取的页面信息比较准确。

（laxt地址:http://172.16.60.244:8088/laxt(登录用户:lijh 密码:123)审判系统:http://172.16.60.244:8484/spxt 自动化平台地址:http://172.16.31.100/atdp/login.do 登录用户:wanghuanren 密码:wanghuanren）

操作过程

这几个案件的自动化流程是用于新案件类型的，所以需要添加“新案件来源”“新结案方式”“新法标_接待新案件模块”到每个案件流程中，使得新案件流程能够对应新修改的页面走通流程。

1.在每个案件流程中的模块都是添加好函数的模块，在这次操作中，基本不需要修改模块里的函数；

2.需要加进去新案件来源的参数值，是在“新法标_新案件来源_公用”模块中。参数值来源于laxt页面上的下拉框的值；

3.新结案方式的配置是在“配置”中，先数据后控件： 数据配置，先找到“小节”，选择哪个小节，需要去流程模块的最后阶段“子表通用”的结案项之上的“批量赋值”中看，其参数就是小节，或者带有结案字样的模块，看到是“结案”上有一个为批量赋值那一项中的参数值就是了。

然后就是控件，控件的话需要的页面抓取工具，抓取结案方式的那个html id到参数值。

遇到的问题：在实际操作中，批量赋值中没有小节名，现在需要在配置中在增加一个小节。在“配置”中点击批量获取，调用抓取工具，在NP的spxt的结案页面上选择一个框就能够获取到一个小节的页面信息，注意将结案页面上必填项都填上，抓取后的小节信息中关于日期的都修改为{今天}，就完成了一个结案信息的小节。

在执行时如果有连接服务器一直处于连接状态的话，就直接在服务器：172.16.31.105上进行执行。（从101到120都是可用的服务器：Microadministrator/ceshi1）

步骤：将要执行的流程名字放在服务器的：D:自动化开发平台自动化开发平台配置

中的测试控制.ini下的第三行：当前流程=?的后面

点击开始的自动化平台远程助手，【调试模式】，再运行QTP。就可以执行自动化了。

遇到的问题：在执行民事二审自动化流程时，点击二审后跳转的页面是“刑事二审”的，这是由于重名导致的自动跳转问题。修改的时候，在流程中加入一个判重模块用于判重，修改参数值，排去无效模块，进行再次运行，就将正确跳转到民事二审页面，见下图：