使用场景

前端自动化测试的稳定性是个很大的问题，在一些不追求速度追求稳定性的场景下，我们可以通过失败重试的功能来达到测试结果的稳定性．

为什么需要记录下来

之前为了兼容JDK7的环境，TestNG的版本一直用的是6.9.6的版本，但是注意了，这个版本是有bug的，对于不带DataProvider的情况，重试功能可以正常使用，但是一旦加上数据驱动，运行结果就各种混乱了．因为这个版本问题，困住近一周．

自己也是一根筋，没有想到去TestNG的官方issue里找答案，结果在开发者的解答中说6.9.7版本已经解决这个bug，抱着试一试的心态更新了一下TestNG的版本，果然，结果正常了，瞬间想骂脏字．

需要记录的几个点

• 1.TestNG的版本问题

需要通过jacoco统计单元测试覆盖率，不需要对项目做配置，直接运行如下命令即可：

1

mvn clean org.jacoco:jacoco-maven-plugin:0.7.4.201502262128:prepare-agent  install sonar:sonar -Dmaven.test.failure.ignore=true -Dsonar.host.url=http://localhost:9000

前言

在上一篇<敏捷研发模式下的质量控制>中介绍了质量控制策略,测试活动是整个研发过程中质量控制活动的一部分.广义的测试活动包括研发全生命周期的测试,例如单元测试,集成测试等,而通常我们所说的测试活动仅指由测试人员完成的部分.

我们可以将产品的质量看成一个完整的积木模型,各个部分的质量合起来就形成产品的整体质量,所以如果我们能保证各个部分的质量,产品的质量自然就得到保证.

将产品质量进行切分常见的有两种方式:

• 第一种是按照产品的架构进行切分,例如前后端分离,微服务架构等,都是从产品架构层面,将一个产品拆分成多个相对独立的部分,保证了这几个部分的质量,并辅以简单的连通性测试,产品的质量基本就得到了保证.

• 第二种是按照产品研发过程进行切分,例如将研发过程质量控制划分为编码阶段的质量控制,测试阶段的质量控制,运维阶段的质量控制等,这几个阶段的质量合力确保了整个产品的质量.

测试策略制订的意义

前言

敏捷研发在领域内已经火了不是一天两天了,其具体内容与优势无须赘述.从研发团队的角度来说,转换一种新的研发模式必然是因为想达成之前的模式无法达成的目标,通常,我们会将这个目标定义为”加速交付”.这个目标比较笼统,从字面上理解,”加速”是核心,即我们追求更快的速度,但是从”交付”的定义上看,在追求效率的同时,我们会优先确保合格的质量.

如何确保质量?与传统研发模式一致,依赖研发过程质量控制.

敏捷模式下的质量控制的特点

敏捷模式与传统模式的区别在于迭代频度更高,反馈效率更快.因此对于研发过程中的质量控制活动来说,也需要更快速的提供质量反馈从而实现快速响应.这有赖于后面会提到的自动化手段.

除此之外,传统的瀑布模式从组织上会更明确开发团队和测试团队的概念,而忽略研发团队的概念.举例来说就是开发人员负责开发,测试人员负责测试,我们并不否定这种职责划分,但是在敏捷研发模式下,这种界限会相对模糊,因为两者的工作会有大量交集,过于清晰反而不利于质量控制活动的开展.

质量控制策略如何制定

使用场景

Jenkins虽然有质量门插件,但是存在的问题是通过命令行触发静态扫描完成后,会将扫描结果发送至Sonarqube进行解析,解析需要一定时间,因此如果在解析未完成的时候获取质量门结果,有可能获取到上一次的扫描结果.

脚本内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#!/bin/bash
#默认后面跟的第一个参数就是sonar服务地址,第二个参数为项目代码
 sonar_url=$1
 CI_PROJECT_NAME=$2
#执行sonar
<!-- more -->
mvn sonar:sonar -Dsonar.host.url=$sonar_url
#获取projectKey
projectKey=com.travelsky.$(echo $CI_PROJECT_NAME | tr '[A-Z]' '[a-z]'):$(echo $CI_PROJECT_NAME | tr '[A-Z]' '[a-z]')
#获取componentId
curl -s $sonar_url/api/components/show?key=$projectKey > component.json
componentId=$(jq .component.id component.json | sed 's/\"//g')
#等待当前项目无in progress任务
while [[ $QUEUE != [] ]]
do
	curl -s $sonar_url/api/ce/component?componentId=$componentId > task.json
	QUEUE=$(jq .queue task.json)
	echo "等待Sonar解析任务完成..."
done
#获取qualitygateStatus
curl -s $sonar_url/api/qualitygates/project_status?projectKey=$projectKey > qualitygate.json
qualitygateStatus=$(jq .projectStatus.status qualitygate.json | sed 's/\"//g')
#判断如果qualitygateStatus不为OK，则终止
if [[ $qualitygateStatus != OK ]]
then
	echo "质量门不通过，请查看Sonar结果详情！$sonar_url/dashboard?id=$projectKey"
	exit 1
else
	echo "质量门通过"
fi

使用方法和注意事项

使用方法

1

chkgate http://localhost:9000 Demo

注意事项

• 1.不同版本sonar可能api有所区别,需要做调整.本脚本基于sonarqube6.4版本.

• 2.需要用到jq工具解析json串.需要安装.

前言

尽管当前业界各路言论都严重不看好WebUI层的自动化测试，但是不管是“质量金字塔”或是“721原则”，尽管优先级较低，UI层的自动化却仍有一席之地。UI层的测试最接近真实用户使用习惯，因此在一些特定场景下，仍发挥着不可替代的作用，最典型的场景就是冒烟测试。冒烟测试的意义在于快速发现质量缺陷，这类缺陷通常是流程性的较严重的功能问题，并且通常会严重影响用户使用。因此在设计冒烟测试用例时，通常会依据实际用户使用习惯，这时候，从前端页面驱动测试就很有必要了。

方案介绍

1.WebDriver和Grid

WebDriver已经是业界比较通用的UI自动化测试解决方案，相比Selenium1，抛弃了通过执行JS驱动浏览器的方式，而是通过直接调用浏览器的原生态接口来操作。由于得到浏览器厂商的支持，因此稳定性上面比Selenium1提升了不少。WebDriver是典型的“C/S”架构，启动时会现在本地起一个server绑定到指定端口，然后client端通过发送各种指令到server,server解析之后帮助我们达到操作浏览器的目的。也正是由于这种”C/S”的架构，client端支持各种语言的开发。

Grid是Selenium的另外一个产品，主要解决的是分布式测试运行的问题。Grid启动之后，会在指定的远程服务器上启动一个hub，然后所有的WebDriver命令都会通过这个hub转发至注册到这个hub的所有node上，从而达到分布执行的效果。

由于UI自动化测试需要驱动浏览器，浏览器自身的机制可能导致在同一台服务器上的多个浏览器操作互相影响，使用传统的WebDriver多线程并发操作会出现问题，因此需要结合Grid将不同用例分发至不同node运行，以此避免不同用例操作互相影响。

前言

去年作为公司的持续集成环境的主要维护人员,将基于Jenkins的持续集成环境搭建起来,并维护了近300个Job,随着持续交付陆续在公司落地,可预见的是构建任务会越来越多,对持续集成环境的要求也越来越高.目前持续集成环境采取的方案是单master节点+多slave节点的传统方式,随着任务量越来越大,暴露出几个明显的问题:

• 1.构建节点数不够：带来的直接影响是如果多任务并发，将会有大量任务由于没有可用构建节点而需要长时间的等待。这对于持续交付要求的快速反馈是非常不利的。
• 2.分发服务器资源利用率不均：这一点与Jenkins自身的分发机制有关，单任务只能指定构建节点，即必须指定服务器。带来的影响是如果构建策略命中的任务只集中在一台服务器构建，那么可能指定的这台服务器基本满载，而另外的分发服务器可能是空闲的。
• 3.环境可用性差：目前环境的维护是纯靠手工的，特别是在服务器出现问题之后，需要人工及时重启，如果维护人员没有及时知晓，可能环境长时间不可用，这对于生产工作也是极为不利的。

基于以上存在的问题，我们引入了Mesos+Marathon+Docker+Jenkins的技术方案来搭建一个弹性高可用的持续集成环境。

方案介绍

首先，我们先来了解一下这个方案中涉及到的新工具。

写在前面

前段时间为了方便使用docker,将电脑系统由windows换成了ubuntu,加上宝宝出生,一堆事情待做,hexo博客迁移一直没做,今天终于下定决心做迁移,也会陆续将前段时间的一些总结更新到博客.

迁移步骤

• 1.环境准备

首先需要准备好新系统上的环境,主要是安装nodejs环境和npm环境.

下载地址:https://nodejs.org/en/download/

tar.xz解压可以直接用tar xvJf ***.tar.xz

Dockerfile

FROM selenium/node-chrome-debug

MAINTAINER angrytester <thx_phila@yahoo.com>

USER root

RUN apt-get update \
    && apt-get -y install ttf-wqy-microhei ttf-wqy-zenhei \
    && apt-get clean

USER seluser

DesiredCapabilities dCaps = DesiredCapabilities.phantomjs();
String[] phantomArgs = new String[] { "--webdriver-loglevel=NONE"," --ignore-ssl-errors=true" };
dCaps.setCapability(PhantomJSDriverService.PHANTOMJS_CLI_ARGS, phantomArgs);
dCaps.setCapability(PhantomJSDriverService.PHANTOMJS_PAGE_SETTINGS_PREFIX + "userAgent",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11");
dCaps.setJavascriptEnabled(true);
dCaps.setCapability("takesScreenshot", true);

重点是--ignore-ssl-errors=true