在jenkins中配置selenium测试

jenkins是流行的集成测试工具,在上面建立编译,发布,运行单体测试的任务都非常方便。 selenium是优秀的Web画面的自动化结合测试工具,它的测试代码有两种形式。 一种是用java,C#等高级语言编写的,特点是功能强大。 另一种是用HTML写的,特点是使用方便。 下面以HTML形式的test suite为例,说明如何在jenkins中配置selenium测试。 先下载插件,在jenkins的plugin管理画面中,选择安装Hudson Seleniumhq plugin。 安装完后重启jenkins。 然后下载selenium-server。其实就是一个jar文件。例如,selenium-server-standalone-2.21.0.jar 用这个jar文件,就可以实现命令行运行selenium测试。 命令行格式如下, java -jar D:/workspace/testproject/selenium/selenium-server-standalone-2.21.0.jar -htmlSuite “*iexplore” “http://localhost:8081” “D:/workspace/testproject/selenium/alltests.html” “D:/workspace/testproject/selenium/results.html” -port 4445 先用命令行测试一下,看看能否生成测试结果(上例中,results.html) 准备工作就绪,接下来把它配置到Jenkins的具体的Job中。...

TestNG 使 Java 单元测试轻而易举

试用这个测试框架,了解它对 JUnit 的超越 在每个现代软件包的构造阶段,测试这一实践都扮演着中心角色。过去那种先编写代码,然后有空的时候再测试(或者根本不测试)的日子已经一去不返,因为大多数开发人员现在认识到需要采用编码和测试彼此交织、同步推进的软件方法论,以便尽早发现 bug,在开发过程开始的时候就识别出主要的风险。 JUnit 超过了其他测试框架,推动开发人员理解了测试尤其是单元测试的用途。利用一个相当简单、实用、严格的架构,JUnit 已经能够“传染”大量开发人员。(有关“被测试传染”的更多信息,请参阅 参考资料。) JUnit 用户已经学会了单元测试的一些基本规则: 每段代码都必须经过测试。 只要有可能,代码的测试必须隔离进行(例如,使用像 模拟对象这样的技术 )。 软件必须容易测试 —— 也就是说, 在编写的时候要想着测试。 但是,随着开发人员对测试的信任增长,JUnit 的简单性和严格性把他们分成两个相反的派别。一方面,有些人坚信 JUnit 的简单性对于不断地提醒程序员软件也必须保持简单来说是必不可少的(这称为 KISS 原则,代表...

基于 Jenkins 快速搭建持续集成环境

持续集成概述 什么是持续集成 随着软件开发复杂度的不断提高,团队开发成员间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。尤其是近些年来,敏捷(Agile) 在软件工程领域越来越红火,如何能再不断变化的需求中快速适应和保证软件的质量也显得尤其的重要。 持续集成正是针对这一类问题的一种软件开发实践。它倡导团队开发成员必须经常集成他们的工作,甚至每天都可能发生多次集成。而每次的集成都是通过自动化的构建来验证,包括自动编译、发布和测试,从而尽快地发现集成错误,让团队能够更快的开发内聚的软件。 持续集成的核心价值在于: 持续集成中的任何一个环节都是自动完成的,无需太多的人工干预,有利于减少重复过程以节省时间、费用和工作量; 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换言之,任何时间点都能第一时间发现软件的集成问题,使任意时间发布可部署的软件成为了可能; 持续集成还能利于软件本身的发展趋势,这点在需求不明确或是频繁性变更的情景中尤其重要,持续集成的质量能帮助团队进行有效决策,同时建立团队对开发产品的信心。 持续集成的原则 业界普遍认同的持续集成的原则包括: 1)需要版本控制软件保障团队成员提交的代码不会导致集成失败。常用的版本控制软件有 IBM Rational ClearCase、CVS、Subversion 等; 2)开发人员必须及时向版本控制库中提交代码,也必须经常性地从版本控制库中更新代码到本地; 3)需要有专门的集成服务器来执行集成构建。根据项目的具体实际,集成构建可以被软件的修改来直接触发,也可以定时启动,如每半个小时构建一次; 4)必须保证构建的成功。如果构建失败,修复构建过程中的错误是优先级最高的工作。一旦修复,需要手动启动一次构建。 持续集成系统的组成 由此可见,一个完整的构建系统必须包括: 一个自动构建过程,包括自动编译、分发、部署和测试等。 一个代码存储库,即需要版本控制软件来保障代码的可维护性,同时作为构建过程的素材库。 一个持续集成服务器。本文中介绍的 Jenkins...

集成 Jenkins 和 TestNG 实现自助式自动化测试平台

https://www.ibm.com/developerworks/cn/opensource/os-autotesting-jenkins-testing/ 本文介绍了如何使用 Jenkins 和 TestNG 实现满足复杂测试需求的”自助式”自动化测试平台。该方案以 Jenkins 作为平台的基础,结合功能强大的插件及系统配置,部署基于 TestNG 的自动化测试包,并提供了友好的 Web 访问界面。项目成员可以在任何时间和地点,通过浏览器访问该平台,而且可以按照不同需求选择测试环境、测试集、测试用例,并提交自动化测试请求,达到真正的“自助式”自动化测试。该平台它可以极大地提高开发和测试团队自动化脚本的使用效率和便捷性。 背景介绍 在软件业十分成熟的今天,敏捷(Agile)开发在业界日益流行,而面临的挑战也日益增多,不断变化的用户需求、缩短的开发周期、频繁的部署上线、复杂的产品架构和团队组织,如何继续保证软件的质量是一个不能回避的课题。 许多企业级规模的项目常常按照功能模块将庞大的团队分为多个独立的 Scrum 团队。在这种情况下,每个 Scrum 团队各自负责其所属功能模块的开发和测试。在 Scrum 团队中各种角色在不同的时间点有针对性不同的测试需求。其次,Build 部署以及测试频率大幅增加。测试类型和阶段也更加细化。 而现有的自动化测试,常常由独立的自动化测试团队来执行和维护。其他的 Scrum 团队成员除非十分了解自动化测试包的细节,否则无法按照自身多类型的测试需求来执行自动化脚本。并且有些项目自动化测试包涵盖了成百上千的测试用例,仅仅因为需要验证某个模块或某几个功能点是否成功而执行整个测试包不仅费时且没有必要。...

用ldap方式访问AD域的的错误解释

用ldap方式访问AD域的的错误解释 用ldap方式访问AD域的的错误一般会如下格式: LDAP: error code 49 – 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece 其中红字部分的意思如下: 525 – 用户没有找到 52e – 证书不正确 530 –...

[转] Linux shell判断文件和文件夹是否存在

#!/bin/sh myPath=”/var/log/httpd/” myFile=”/var /log/httpd/access.log” #这里的-x 参数判断$myPath是否存在并且是否具有可执行权限 if [ ! -x “$myPath”]; then   mkdir “$myPath” fi #这里的-d 参数判断$myPath是否存在 if [ ! -d “$myPath”]; then   mkdir “$myPath”...