人工智能自动化测试框架，自动化测试框架都有哪些

1，自动化测试框架都有哪些

自动化测试框架主要分为以下几种，可以根据项目需要进行选择1.模块化框架（test script modularity）。2.函数库结构框架（test library architecture）。3.关键字驱动测试框架（keyword-driven/table-driven testing）。4.数据驱动测试框架（data-driven testing）。

我之前开始自动化测试的时候也上网查阅过很多资料，但也没有一个比较有权威的说法。有人说是一种解决自动化测试的解决方案，有人说是一套管理系统，有人说是一个软件，有人说是一段代码...举个例子，我现在在公司带头研究自动化测试（刚刚起步），主要是从事web测试。然后使用的工具是ruby + watir-selenium + cucumber，这三种工具都是在国外使用的比较多的。ruby作为脚本语言，watir-selenium用来驱动浏览器，cucumber用来编写测试用例。那么，我对自动化测试框架的理解是，根据公司现在的状况，我使用了这三种工具来搭建了一个自动化测试环境并能实现自动化测试，也就是说，我是用了rubu、watir-selenium和cucumber来构建一个自动化测试的框架，即框架就是ruby、watir-selenium和cucumber，并能用他们来实现自动化测试。

自动化测试框架都有哪些

2，Python BDD自动化测试框架有哪些

好象python的浏览器测试框架，原来只有一个，还是仿ruby的框架做的。似乎在IE上可以比较好的应用。很老的框架。对JS支持不好。不过python写个测试框架真是非常容易的事情，随手就来。基于浏览器测试也容易做。因为你可以使用pyqt，这个库里有一个基于webkit的浏览器。基本上，想做什么都可以了。最近听说有几个新的BDD的框架正在做。也不知道怎么样。其实对于python这种语言来说，框架的成本太低。所以最好不要做框架。它有一个基本的编程原则则DRY。do not repeat yourself。不要再造轮子的意思。直接使用现有的python的testsuite结合进程，线程模型，还有QT轻松就组装出一个测试模块。

1. Python自动化测试框架比较有名的就是python+selenium，还有单元测试框架PyUnit，还有一个叫做Robot Framework的自动化测试框架，大大小小的有很多2. BDD顾名思义Behavior Driven Development，译作"行为驱动开发"，是基于TDD (Test Driven Development 测试驱动开发)的软件开发过程和方法。BDD可以让项目成员（甚至是不懂编程的）使用自然语言来描述系统功能和场景，从而根据这些描述步骤进行系统自动化的测试。3. BDD的自动化测试框架的话，目前应用最好的是Ruby下的Cucumber，Python下有类似的Behave、Lettuce及Freshen等，这三个都差不多，个人推荐Behave4. 可以百度这篇文章（我写的）：Python BDD自动化测试框架初探

Python BDD自动化测试框架有哪些

3，Robot Framework作者建议如何选择自动化测试框架

Pekka Kl??rck，作为Robot Framework的创建者和核心开发者，按照系统级别，介绍了几种不同的自动化测试方法的区别。一、记录回放的方式流行于商业工具之中，无需编程技能即可快速上手。然而这种方法相对脆弱，一旦UI变化测试就会受到影响，分散的脚本不可重用且难以维护，而且系统在测试前必须可用（也就意味着无法使用A-TDD方法）。因此这种方法并不适合大型自动化测试。二、线性脚本允许使用各种语言来编写非结构化脚本，脚本直接与被测系统交互。能够快速上手，灵活性强。但是编写脚本需要编程技能，系统中一个改动会影响所有脚本，没有经过模块化或重用的大量脚本难以维护。因此这种方法适合简单任务，不适合大型自动化。三、模块化脚本由两部分组成：驱动脚本执行测试，测试库函数完成与被测系统交互。驱动脚本编写起来非常简单，这样可以更快地建立新测试，容易维护。然而需要花时间和编程技能建立测试库，并将测试数据嵌入脚本，建立新测试就需要新的测试脚本。因此，只要拥有编程技能，这种方法还是适合大型项目，但不适合非编程人员。四、数据驱动方法，将数据与测试脚本分离，基于模块化的测试库，一个驱动脚本可以执行多个相似测试，这样非常容易建立新测试。维护工作可以分离，测试人员负责数据，程序员负责写测试库。然而，不同类型测试仍需要新的驱动脚本，初始建立数据解析器和重用组件需要花人力。这种方法适合大型项目，只需要较少的编程技能。五、关键字驱动，将数据与关键字结合来描述如何使用数据执行测试。这种方法具备数据驱动的优势，同时非编程人员也能建立新类型测试。所有测试由同一个框架来执行，无需不同的驱动脚本。然而初始成本很大，但是可以使用开源方案！因此非常适合大型项目。Pekka对以上五种方法的介绍其实也是对自动化测试发展史的介绍，同时也体现了RobotFramework背后的设计思想。除了测试框架的选择，要想做好自动化测试，还要关注其他方面。自动化测试需要关注可测性。自动化最难的部分是与被测系统交互，特别是GUI层。确保系统容易被测试，比如给GUI元素增加标识、输出易于解析的文本、提供自动化接口等。系统一般可以分为GUI层以及GUI之下的业务层。GUI层测试需要调用与普通用户同样的接口，但是某些GUI技术缺乏好的工具支持，会使测试变得脆弱，而且执行相对较慢。从业务层开始测试相对容易，执行快。但GUI层仍然需要被测试，以保证GUI正确连接到了业务层，甚至有时GUI层也具有业务功能。Pekka建议考虑对业务层进行完全测试，而部分地对GUI层实行端到端测试。不是所有系统都具有GUI层，却可能具有API、数据库、服务器、命令行等。自动化测试框架可以调用不同驱动来进行测试。这些非GUI层相对容易测试，只要把测试用例看作另一个客户端而已。那么自动化测试应该在什么阶段进行？如果开发完成后单独做自动化，这是典型的瀑布式过程，不同团队之间存在沟通障碍，反馈周期慢，产品在后期难以获得可测性，从而导致复杂和脆弱的测试方案。相反，典型敏捷式过程中，程序员和测试人员协同完成自动化。把自动化看作团队开发的一部分，可测性不再是问题，团队做技术决定时就可以考虑可测性和工具选择，程序员可以提前加入提供可测性的钩子特性。自动化测试需要版本控制和持续集成来支持。将测试和代码放在一起，像管理代码一样管理测试脚本，那么多可用工具，SVN、GIT、Mercurial，没道理不用。持续集成是全方位自动化的关键，当测试或代码有所改动立即执行测试。如果测试运行时间比较长，也可以定期运行。使用Jenkins、Hudson、Cruise Control、BuildBot吧，自己写定时脚本或Cron Job可以休矣。选择商业自动化工具还是开源工具？好东西肯定贵，但是贵的不见得好，再便宜的许可证也会阻止整个团队的协作。而且商业化工具难以和其他自动化工具（特别是其他厂商的）或版本控制、持续集成进行整合和定制化。另外，产品终止或公司关门是潜在的风险。开源工具可供选择余地很大，当然也是良莠不齐。开源工具通常容易与其他工具整合，关键是免费，谁都可以随意使用和定制化，还永远不会消失。至于免费软件，越来越少了，很多自由软件都已经开源。免费软件同样不能定制化，且存在中止的风险。做自动化需要哪些技能？一般来说，包括Python、Ruby、Perl、JavaScript、正则表达式、XPath和CSS定位、SQL语句、版本控制等。有了自动化，手工测试还需要吗？当然需要！！不过，要避免手工执行脚本来测试，还是将其完全自动化吧，测试人员可以更多关注于探索性测试。记住，机器擅长回归测试，人类善于寻找Bug。

Robot Framework作者建议如何选择自动化测试框架