第一篇：iPhone App自动化测试工具总结
iPhone App自动化测试工具总结
无线客户端的发展很快，特别针对是android和ios两款无线操作系统的客户端应用，相应的测试工具也应运而生，这里主要给大家介绍一些针对iPhone App的自动化测试工具。
首先，我们把这些测试框架分为三大类：接口测试工具、注入式UI测试工具、录放式UI测试工具。
一、接口测试工具，主要在iphone SDK提供的单元测试框架的基础上，完成代码的接口功能测试。
这类工具用的比较多的是SDK本身提供的test unit，以及google的google-toolbox-for-mac工具。google的GTM工具是在test unit上做了一层封装，可以简单、快速的完成测试脚本编写，提供完善的测试日志和报告，并提供部分简单的UI测试功能。
详细的文档可以参考这里：http://code.google.com/p/google-toolbox-for-mac/wiki/iPhoneUnitTesting
二、注入式UI测试工具，可以完成对被测应用的UI功能测试，需要在源代码中加入一些必须的测试代码。优点是可以模拟用户的操作，测试被测应用 的相关功能，可以覆盖比较全的应用功能。缺点是因为在源代码中插入了必须的测试代码，而这些应用发布时需要去除，引入了被测应用和发布应用不一致的风险。
UISpec,提供了用例运行前的准备和运行的恢复功能，UIQuery功能，以及较为完善的校验功能，但该工具的使用比较复杂，脚本的编写也很繁琐，虽然对UI可以query，但无法方便、清晰、直观的查看应用控件的属性。
详细的文档可以参考这里：http://code.google.com/p/uispec/wiki/Documentation
Bromine,脚本编写简单，对控件的操作，完全模拟touch事件实现，但控件的定位通过对控件重画，并插入定位需要的信息，xpath的描述串也稍显复杂，校验功能相对较弱。
详细的文档可以参考这里：http://code.google.com/p/bromine/
三、录放式UI测试工具，主要通过录制用户的操作行为，通过回放来完成对被测应用的功能测试，这类工具对UI的功能测试相对是比较弱的。
比较常用的有Instrument、FoneMonke。
Instrument，是iOS提供的主要用于分析应用的性能和用户行为的工具，利用它可以完成对被测应用的简单的UI测试。
FoneMonke，是国外提供的一个开源的，免费的录制/回放工具。网站：http://www.xiexiebang.com/fonemonkey
以上是了解的一些针对iPhone App的自动化测试工具，大家感兴趣的可以了解了解，欢迎交流、学习！
第二篇：Android自动化测试工具常用ADB命令总结
自动化测试常用ADB命令操作总结
自动化测试基本操作命令：
模拟点击操作：adb shell input tap 500 500(点击手机（500，500）坐标)模拟滑动屏幕操作：adb shell input swipe 200 500 400 500 模拟输入文本信息：adb shell input text helloworld 模拟按键命令：
adb shell input keyeventKEYCODE_VOLNME_DOWN按音量下键 adb shell input keyeventKEYCODE_VOLNME_UP
按音量上键 adb shell input keyevent 自动化测试中日志分析截图命令：
数据线连接手机截图：adb shell /system/bin/screencap–p /sdcard/screenshot.png 将截图复制到电脑盘中：adb pull /sdcard/screenshot.png E:download 输出所有已经安装应用： adb shell pm list package –f 查看预安APK adb shell pm list package-3 安装应用程序：
adb install –r 应用程序.apk 文件传输：
获取模拟器中的文件：adb pull
常用的发送键盘事件：
命令格式：adb shell input keyevent“value” 其中value以及对应的key code如下：
KeyEventValueKEYCODE 0 KEYCODE_UNKNOWN 1 KEYCODE_MENU 2 KEYCODE_SOFT_RIGHT 3 KEYCODE_HOME 4 KEYCODE_BACK 5 KEYCODE_CALL 6 KEYCODE_ENDCALL 7 KEYCODE_0 8 KEYCODE_1 9 KEYCODE_2 10 KEYCODE_3 11 KEYCODE_4 12 KEYCODE_5 13 KEYCODE_6 14 KEYCODE_7 15 KEYCODE_8 16 KEYCODE_9 17 KEYCODE_STAR 18 KEYCODE_POUND 19 KEYCODE_DPAD_UP 20 KEYCODE_DPAD_DOWN 21 KEYCODE_DPAD_LEFT 22 KEYCODE_DPAD_RIGHT 23 KEYCODE_DPAD_CENTER 24 KEYCODE_VOLUME_UP 25 KEYCODE_VOLUME_DOWN 26 KEYCODE_POWER 27 KEYCODE_CAMERA 28 KEYCODE_CLEAR 29 KEYCODE_A 30 KEYCODE_B 31 KEYCODE_C 32 KEYCODE_D 33 KEYCODE_E 34 KEYCODE_F 35 KEYCODE_G 36 KEYCODE_H 37 KEYCODE_I 38 KEYCODE_J 39 KEYCODE_K 40 KEYCODE_L 41 KEYCODE_M 42 KEYCODE_N 43 KEYCODE_O 44 KEYCODE_P 45 KEYCODE_Q 46 KEYCODE_R 47 KEYCODE_S 48 KEYCODE_T 49 KEYCODE_U 50 KEYCODE_V 51 KEYCODE_W 52 KEYCODE_X 53 KEYCODE_Y 54 KEYCODE_Z 55 KEYCODE_COMMA 56 KEYCODE_PERIOD 57 KEYCODE_ALT_LEFT 58 KEYCODE_ALT_RIGHT 59 KEYCODE_SHIFT_LEFT 60 KEYCODE_SHIFT_RIGHT 61 KEYCODE_TAB 62 KEYCODE_SPACE 63 KEYCODE_SYM 64 KEYCODE_EXPLORER 65 KEYCODE_ENVELOPE 66 KEYCODE_ENTER 67 KEYCODE_DEL 68 KEYCODE_GRAVE 69 KEYCODE_MINUS 70 KEYCODE_EQUALS 71 KEYCODE_LEFT_BRACKET 72 KEYCODE_RIGHT_BRACKET 73 KEYCODE_BACKSLASH 74 KEYCODE_SEMICOLON 75 KEYCODE_APOSTROPHE 76 KEYCODE_SLASH 77 KEYCODE_AT 78 KEYCODE_NUM 79 KEYCODE_HEADSETHOOK 80 KEYCODE_FOCUS 81 KEYCODE_PLUS 82 KEYCODE_MENU 83 KEYCODE_NOTIFICATION 84 KEYCODE_SEARCH 85 TAG_LAST_KEYCODE
第三篇：自动化测试经验分享
一、测试的困惑
以前我时常反思，测试组的工作多吗？我的回答是多。测试小组的工作成果的好坏和工作任务的多少成正比吗？最终的回答却并非成正比。我们的测试工作成果往往并不理想，甚至是差。那么为什么事倍功半？这问题很难找到清晰的答案。
参与了外部培训之后，发现了自己在对测试的工作有了新层次的理解。对之前工作成果差的问题思考也有了新的方向。“测试的最高境界是找出所有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的产生的一套质量保障机制。所以自动化测试的重点在于测试自动化作为一个体系，要运用于整个项目团队。项目组要讨论它（策略、时间、成本等）、研发需要参与它（编码方向、自动化支撑、以及代码单元测试自动化的计划和执行等）、测试要引导及推进它（策略、方法、执行、跟进、维护等），各团队共同形成体系，才能让自动化测试工具真正的成为一种质量保证的有力武器。
第四篇：Web测试工具小结
Web测试工具小结
单元测试方面：（对开发人员比较有用）J-Unit工具。
功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。
如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。
另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序，如SMTP Server等。这两个工具都是使用Post URL的方法测试Web Application的。对大量使用JavaScript的页面不太适合。当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。
另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。
另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。
至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。
测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试
白盒测试工具主要有：
内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等
代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等
代码性能检查：Numega中的truetime,Rational的Quantify等
代码静态度量分析质量检查工具：logiscope和Macabe等
黑盒测试工具主要有：
客户端功能测试：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
服务器端压力性能测试： MI公司的winload,compuware的qaload,Rational的SQA load等等
Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等
测试管理工具：rational的test manager,compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。
数据库测试工具:TestBytes
黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。
回归测试工具：Rational TeamTest，WinRunner（MI公司）
WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）
白盒测试工具：Numega、PuRe、软件纠错工具（Rational Purity）。
嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。
系统负荷测试工具：RationalPerformance
涵盖测试工具范围评估工具
软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify
测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理）
第五篇：软件(自动化)测试工作总结
2012年工作总结
2012年自动化测试工作严格按照要求，保质保量完成客户指派的任务。截止目前，已完成话费收取、账单查询、产品变更、营销活动等137项关键业务测试用例、105个自动化回归测试场景设计，范围涵盖个人业务、家庭业务、集团业务、账务管理、营销活动及各类常用查询功能。陕西公司在大型版本上线时均进行关键业务自动化回归测试，降低了新版本上线风险，保证了新版本上线后关键业务和常用业务正常受理。累计已进行新需求上线前后回归测试68次，运行业务脚本13100余次，发现系统原有缺陷38个，新需求缺陷69个，进行业务规则梳理146个，为新需求影响范围分析提供了数据依据，较大程度的提高了上线成功率，降低了上线后系统的缺陷率，提高了系统的稳定性。
从2012年5月份入职到现在的多半年时间内，主要对系统，业务的深入理解，学习。对工作中所运用到得工具熟练掌握，每次上线都能按照要求，独立完成分配的任务。对自动化脚本进行重新整理改进，发现问题及时联系局方人员进行协商，处理。
主要工作内容是负责自动化测试这块，自动化测试的目的在于保障在新业务上线后，能正确的把控新上线内容对整个生产环境的影响。确保在新业务上线过程中，及早发现关键业务的情况，判断其是否受到影响，同时确定新上线业务是否满足要求，达到预期的功能目的。每次上线加班，严格按照要求进行测试，仔细记录测试中发现的BUG，当天寻找开发或相关负责人进行解决，每次按时到达工作现场，认真对待工作，至今没有由于个人原因出现严重过错。其他时间，对测试环境，测试数据和脚本进行维护，管理。领导每次分配的任务认真对待，按时保质完成。
工作中存在还需要以后改进的几点：
1、对业务的熟悉度更进一步了解，拓展。
2、对脚本进行改进，创新，能够更全面的覆盖测试面，争取最大限度的找出问题所在。
3、在测试工具，软件，脚本等方面进行创新，提高测试正确度，测试效率，真正达到自动化测试的目的。
以后主要对自动化更深一步的了解，学习，还有对移动业务庞大的系统进行深入了解，经过这样紧张有序的一年，我感觉自己工作技能上了一个新台阶，做每一项工作都有了明确的计划和步骤，行动有了方向，工作有了目标，心中真正有了底！基本做到了忙而不乱，条理清楚，从根本上摆脱了刚参加工作时只顾埋头苦干，不知总结经验的现象。针对个人和工作上存在的不足，我会不断的去改善，好的习惯继续保持，同时也会不断更新自己的知识库。
点击咨询 