关于自动化测试，关于Agile，关于团队

lsekfe

关于自动化测试，关于Agile，关于团队

作者: Ant_Yan ，发布于2012-6-8

在第一时间越狱了New Pad，开始把之前眼馋又买不起的App逐个开始下载安装，估计又得花相当一段时间来适应这些办公App了。 团队的成员已经逐渐适应了我分享给大家文章，大家阅读之后融入自己的一番思考并写下blog的方式。在Agile的转型中，驱动每个成员自主的来思考，产生改进的意愿，这可能是最重要的一个环节了。特别是在一个测试团队中，大家深入理解Agile之后对自动化的渴望尤其迫切，我自主研发了项目的第一代自动化工具，大概Cover了100来个Case，但是由于coding比较快，稳定性和运行速度都不是很理想。现在团队更加理解自动化的威力和在Agile流程中对待它的态度之后，我决定开始重构第一代的自动化工具，逐渐往一个framework的方向上来扩展。 在新的framework设计和底层的架构中，我不得不时刻都提醒自己的以下几点： 1. 一次只专注一件事： 公司也有许多项目团队在做自己的自动化，也有专门的自动化组，虽然大家都很努力，但最理解我们项目应该如何测试，大家最需要的自动化是什么样子，还是只有我们最清楚，我把团队的分析都逐一记录下来，一次只专注做其中的一件事，直到大伙都能满意的使用它为止。这一点个人觉得特别重要，泛泛而谈一个自动化框架，基于Web项目，可能包括方方面面的东西，页面的识别、安装磁盘文件操作、Case的设计、数据结果分析、测试报告的详尽……等等，如果我们什么都想要，什么都快速的完成并发布使用，到头来会发现，每一块都存在不小的缺陷，并且随着技术的革新、产品的更新换代，陷入不断的维护每一块的漏洞和更新自动化框架的漩涡中无法自拔。所以，挑选最重要的一项开始，使用Agile同样的思路，不断的快速迭代，保证能使用的一定是稳定且有价值的功能。 2. 让全员参与起来： 由于团队都基本具备了Agile的意识，我不再像第一代工具一样个人开发仅仅让大家来使用，而是让整个团队全员都参与进来。为了让本不具备编程能力的全员团队成员可以参与进来，我非常小心翼翼的设计底层的代码结构和继承关系，控制暴露出来的API清晰表意，简单易懂。大家可能在不懂Java的代码的情况下，就完成了许许多多的Java方法的编码，这里我举一段代码作为例子：（这段代码执行了一串页面操作流程，Cover了系统的某一个功能点，基本上规避了Java的许多繁琐语法和原貌） page.home("Administration").go("Manage Device Groups");grid.locate("Device Groups").toolbar("New Subgroup");dialog.radio("Staging");dialog.to("Next").form("Group Name=testGrp1", "Description=testGrp description");dialog.click("Not specified");dialog.popup().check("operator");dialog.popup().click("OK");dialog.to("Finish").process(); 3. 三层架构： 几天前刚看了一篇文章分析自动化框架的设计思路，传统的自动化思路叫原型式：主要是界面录制回放，它暴露的种种弊端例如：难以重用、环境依赖产生的不稳定性，步骤死板难以扩展并插入界面之外的判断……当下的自动化，主要思路已经不一样了，主要强调的是：界面在运行的过程中不要傻傻的等待而是持续的在后台去做一些事情，为了重用和扩展测试数据和脚本要优雅的分离，整个自动化已经趋向开发所经常使用的MVC模型：表示层、数据层、逻辑层。页面的识别和跟踪操作隶属于表示层，而页面的调度和数据的选取、分析，甚至后台功能的配对检查隶属于逻辑层，真正分离出来管理的测试数据隶属于数据层。三层之间由框架负责协调和管理，最终即使遇见重大更新，也可以化繁为简，只动到某一层中间的一些组件。 4. 完整的核心： 测试的核心是测试用例，在未来的道路上，我们希望每一步都走得能让心里踏实，所以即使在最初大家有许多很不错的想法，我逐一记录下来却告诫并不能什么都想要。对一个TestCase这个核心组件的定义上，我们已经有了一个很完整的想法，这里我只是留下了一张草图和想法，在我们看来，一个TestCase应该包括的部分包括： Pre-Condition: 前置条件，脱离界面的不确定性，直接在后台检查 UI-Process: 完成系统行为或设计场景的操作流程 After-Condition: 后置条件，消除或减轻对后续Case的影响，必须同时在界面和后台做一些恢复等操作 Checkpoint: 同时包括界面的verification和后台数据的对比以及日志甚至进程数据的分析 Case Config: 测试场景的配置，需要何种浏览器，预估时间 Meta Data: 测试用例的元数据，包括针对的系统功能点，描述，测试对象系统的版本等等 Dependency: 为了覆盖到更复杂的场景，在需要的情况下，Case之间可以自由组合并建立起依赖关系【Optional】 最后，我依然不断的告诫自己和团队：谨慎前行，从长期来看变化因素不大的部分开始实践，永远不放弃更新或者摒弃一些随着业界变化而陈旧过时想法。最最重要的，自动化测试始终不可能代替手工探索性测试，但如果自动化测试无法真正的给出有价值的结果，那么手工劳动永远无法真正解放出来。简单来说，如果不能做到自动化Case失败了80%~90%以上一定是Bug存在这一点的话，自动化的价值就无从谈起。所以在前期，我们可以转换思路，先让自动化配合人力的繁琐操作，解放手工操作的劳动力和时间，来进一步摸索如果判断和保证自动化Case有价值的产出，持续的迭代和改进。

seagull1985

精品文章，不错

annaier_go

好文，如果配上设计图，更棒了

jeky2015

思想很有启发，目前在做手机自动化测试