第一篇：自动化测试平台学习总结
自动化测试平台学习总结
学习工作内容
在如下的案件流程中：
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。就可以执行自动化了。
遇到的问题：在执行民事二审自动化流程时，点击二审后跳转的页面是“刑事二审”的，这是由于重名导致的自动跳转问题。修改的时候，在流程中加入一个判重模块用于判重，修改参数值，排去无效模块，进行再次运行，就将正确跳转到民事二审页面，见下图：
第二篇：自动化测试学习历程感悟--（定稿）
软件设计与自动化测试学习历程感悟
序言：最近一段业余时间都在进行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的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。
第四篇：电商平台测试总结
测试总结
后台
：
进入页面是登陆功能，登陆成功之后是主页菜单：
关键字搜索
用户个人资料修改
系统设置
商品管理 ： 新增功能
修改功能
删除功能 订单生成 ：
修改功能
删除功能 上架 ： 删除功能 评论 ： 删除功能
公益 ： 删除功能
新增功能
修改功能 订单结算 ：删除功能
供应商管理 ：修改功能
删除功能
备注：后台的增删改是为了商家更好的提供商品
前台：
登陆
主页面
分享商城： 个人设置
商品分类
品牌分类
价格区间
限时活动
商品推荐
关键字搜索我的订单
环球购
城市管
家
点击进入商品页面 ： 上架 评论 购买 提交 备注 本店推荐商品 公益平台：
平台推荐公益
公益项目
公益活动
生活管家：
行程安排
定制提醒
系统消息
群发信息
朋友圈：
交友晒图
分享 购买消息
商品质量
物流速度
公益项目 还可以分享身旁趣事
诚信保障： 货源渠道：严格的供货管理方案，规定供应商必须为具备一定诚信级别的分享会员。从申请到正式入驻需经过十打步骤严格检验，提供营业相关的齐全证件才可申请成功。
级别与交易：平台严格把关，推出完整而严谨的诚信积分规则
推荐佣金：不用担心推荐人是为了赚取佣金，所有人成为会员之后都能第一时间知道自己的推荐人是否真的购买或体验过此类商品
第五篇：调度自动化学习总结
关于三则《广东电网调度自动化安全提示》的学习总结
红海湾电厂 继保班
为提高厂内继电保护人员对自动化的风险意识，预防人为、设备等原因导致的自动化异常事件，2015年1月5日上午，电厂继保班组织人员对中调自动化管理规定进行认真学习，同时对近期下发的几则广东电网调度自动化安全提示进行讨论学习，结合本厂实际情况制定了一系列的管理规定和预防措施。
首先，针对《220kV某中调直调电厂AGC调试违反设备检修审批流程》事件，厂内明确了自动化工作申请批复事宜的流程，结合广东中调自动化管理相关规定，厂内要求涉及自动化的设备检修（紧急消缺除外）工作，需遵照执行如下工作流程：
1、计划性工作须提前一周（至少三个工作日）向中调自动化提交申请，得到批复后做好相应准备工作，包括制定事故预想，准备好备品备件等。
2、项目开工前电话联系中调自动化专责及电话联系自动化值班人员确认安措已执行完毕方可开展厂内工作。
3、每日开工前均要向自动化值班人员取得许可后方可开展工作。
4、工作结束后及时向广东省中调汇报完工，便于中调侧对我厂自动化安措的解除工作。
针对《某电厂某220kV线路连续3次开关跳闸无反应》事件，厂内对涉网设备及自动化设备进行了一次全面排查，确认所有设备均符合正常运行工况，同时也制定了相应的预防性措施：
1、检修人员对涉网设备、保护装置等定期巡检（每周一次），及时发现问题。
2、对远动设备、后台、通讯设备、调度数据网等设备定期进行检查，防止装置死机、故障、网络中断等造成数据传输异常情况的发生。
3、加强继保人员自动化知识的培训，包括对自动化设备硬件设备认识、软件管理、链路走向、物理连接，提高人员的风险意识。
4、完善现场设备的相关参数的收集工作，保证今后工作有据可查。
针对《某地调误发“110kV某风电站全站失压”信号》事件，再次重申：
1）开展检修工作前分析可能影响自动化业务的所有可能，坚决杜绝譬如变送器测量导致数据跳变的恶性事件发生;2)现场自动化设备相关工作必须执行凭单、凭票开展，开工前由自动化专责进行安全交底，并形成书面材料，严禁口头知会；
3）现场工作必须由熟悉业务的人员（至少两人）开展，工作中相互提醒，坚决杜绝独自开展自动化业务的工作；
为避免厂内停运机组负荷数据上送中调，重申机组停运、启动后须执行如下工作：
1）停机后第一时间电话联系广东省中调自动化专责或自动化值班人员，做好数据封锁等处理；
2）开机前再联系中调自动化专责或自动化值班人员解除对封锁机组的数据。
点击咨询 