如何构建自动化测试框架？（10-05-24）（获奖名单已公布）

liaoxj

不可否认，随着系统架构越来越复杂，带来测试技术的冲击是越来越大，公司测试架构形成对提高测试效率和质量，一定会是行之有效的手段。
     做测试架构前期需投入很大成本和时间，问：在很多公司连程序架构的思路都没有很好理清的情况下，我们如何去做测试架构。
     我是从公司只有两个测试人员的基础上，通过6年的努力发展到12人，我深有感触，测试架构形成要分三分走，首先人员架构，知识库架构，技术架构。
     人员架构建立是整个测试架构形成基础，当公司只有两个人做测试，何谈测试技术架构。记得我们两个人测试的时候，我们没有分工所有产品大家一起来。发展到四个人的时候，我按大产品线分两小组，当我们发展到7个人的时候我们按项目分组，发展到10个人的时候我们又回归产品线，今年我们发展到12个人时候，我们组建了自动化测试小组。
     知识库架构的建立是整个测试架构形成的资源的方向，并需要不断积累的完善。记得刚开始的时候我们所有测试都是功能测试而且全墨盒，但是我们积累了详细的业务知识，并整理了详尽的测试案例，后面根据产品线进行分类，并且获取了公用测试用例，并配合开发组形成了界面规范，数据库规范，代码规范等。后面由测试业务需要我们进行性能测试，尝试使用很多测试工具，jmeter,loadrunner, JProfile等，我们整理了工具的特性，什么时候应该使用工具，并且顺便整理了一些监控工具，有操作系统的OmniPeek、Aports等，网络监控工具TCPMonitor等，网页监控工具HttpWatch，Xenu等，也顺便整理了一个测试辅助工具如DataFactory, jsunit。形成了自己公司独有知识库体系和知识库管理流程。
      技术架构需要根据公司的测试团队规模和测试技术实力，目前还没有到哪家公司的测试技术框架能够照搬，参照也很难，做到借鉴已经不错，现在只通过自己公司知识库积累，搭建符合自己测试技术框架。小公司现阶段不适宜搭建什么测度技术框架平台，那很不务实的，但是小公司我们整理自己的“公用类库”，如QTP的公用类库，jsunit的公用类和方法。并在项目中执行，结束后，然后不断不完善。最后时机成熟了，就可以很好嵌入到所谓的平台

    自己看了一遍，好像没有回答问题似的，大家看看，只是我一些想法和现在做的事！

[ 本帖最后由 liaoxj 于 2010-5-31 15:27 编辑 ]

dennyqiang

谈框架，谈的就是个思想，要谈思想，先要解放思想。

没有弄清楚工具前，谈方法，不可取。
没有弄清楚方法前，谈框架，不可取。
框架很空洞，实现起来很麻烦，不可取。
把框架神化，认为框架无所不能，不可取。
框架设计要花很多时间，所以不要也罢，不可取。

如果企业流程混乱，没有一个完全理解自动化的人来主导自动化，莫谈框架。
如果没有一个完整的规划和风险识别，莫谈框架。
如果连基本的自动化测试都没做起来，莫谈框架。
如果测试开发人员只会录制回放和一些基本的代码操作，莫谈框架。

框架是什么？框架无非就是一组封装好的类和方法，其目的在于统一企业的自动化测试流程和方法，并为具体的自动化测试项目提供可重用的，易于维护和扩展的架构。

框架不是一蹴而就的，而是在使用过程中逐步完善的。

不可将框架设计得很复杂，妄想用户编写测试代码变得简单方便，其结果是降低框架的灵活性，框架本身的维护成本会增加，得不偿失。

框架并不深奥，完全不必谈框架色变，任何一个组织，只要经过一些指导和培训，均能开展自动化测试。

框架的设计通常遵循如下原则进行：
a) 高度重用：重用测试用例，重用对象，重用各种组件，通过重用性设计来提高模块化程度。
b) 随需应变：通过分离对象与用例，用例与业务(一个业务或场景应该是由一个或多个单个的测试用例组成)，业务与数据来使自动化测试代码更加灵活，自适应性更强。
c) 简化开发：并非所有测试人员都是软件开发方面的专家，自动化测试的很多用例书写和后续维护工作还应该交给测试人员来进行，那么如何让一个没有多少软件开发经验的员工来开发或维护自动化测试用例呢？设计一个简单易用框架是最好解决方案。
d) 框架维护成本低：框架不但应该满足上面三个原则，同时还需要考虑到框架本身的复杂性，如果为了提升模块化，为了提升灵活性或是为了简化开发而将框架本身设计得非常复杂，将是一件得不偿失的事情。

蝈蝈5

原帖由 兰兰 于 2010-5-25 10:55 发表
在公司尝试启用自动化测试已经有三年的时间了，但是一直似乎都是口号式的，年初计划的很好，但是在实际的操作过程中，遇到的技术难题较多，可值得交流人和借鉴的经验很少，在加上公司项目较多，测试人员较忙，几乎没 ...
  在具体的实现过程中牵扯到很多的技术细节，在这里不再一一介绍，算是抛砖吧

很空泛的实心板砖

蝈蝈5

原帖由 JamesHao 于 2010-5-25 22:43 发表
我这方面有些心的，但是落地纸面上没有时间。：）

那您打这几个字就有时间了，别累坏了您

蝈蝈5

原帖由 shanxi 于 2010-5-27 13:16 发表
对于大部分人来说，由于并没有机会开发界面自动化的核心组件，所以开发框架成为了自动化脚本开发人员的主要提升方式。

个人经验以为，界面自动化测试框架并不需要太高深的技术，它是一个逐步完善提高改善的过程。 ...

很赞成您的观点，看了半天，就您的话有帮助

archonwang

凶悍。。。。

测试和开发密不可分，即使在实现形式上也有很多类似。

做测试这么多年，发现其实还有很多东西要学。。

JamesHao

原帖由 蝈蝈5 于 2010-5-31 16:04 发表

那您打这几个字就有时间了，别累坏了您

说的很好。
其实并不是不能谈，试问自动化落地，真的是框架问题吗？
之所以不再这里谈，是我觉着在帖子谈不清楚。（可能是我的表达能力问题）
我可以安排在某周六或者周日，进行一次面对面的沟通，共同探讨这个问题。
地点：上海。

konnie

公司内部也在组织进行自动化测试，框架方面和楼上所说的大同小异。需要在过程中不断总结，抽取出可自动化的各种组件，资源消耗是比较大的，但这也是自动化测试必须付出的代价。