Runner

package com.example.demo; import org.junit.Test; //重要包 import org.junit.runner.RunWith;//重要包 import org.springframework.boot.test.context.SpringBootTest; import org.springframework.test.context.junit4.SpringRunner; /** * @Description：TestJson * [@author](https://my.oschina.net/arthor): Ashley * [@Date](https://my.oschina.net/u/2504391) ：2020/6/25 */ @RunWith(SpringRunner.class)//测试类加@RunWith注解 @SpringBootTest(classes = TestHttpClientApplication.class) //主程序java程序必须是SpringBootApplication程序 public class TestJson { @Test public void testForTest(){ System.out.println("单元测试方法 testForTest！！！"); } }

前言 吐槽一波 2020年6月2号刚入职公司时，第一感觉是集群环境是个大坑！内网一套，公网一套。内网采用单节点Kubernetes，公网采用aliyun托管的X节点Kubernetes(还有节点是2C的...)。内网Kubernetes环境几乎无人使用(可能后端开发工程师在偶尔使用吧)。公网的X节点Kubernetes集群，也可以是称之为生产Kubernetes集群，也可以称之为测试Kubernetes集群，天才的设想--通过名称空间区分集群环境！ 引出话题 研发人员向部署在公网的Kubernetes集群的gitlab代码管理仓库推送代码，然后由部署在香港服务器的gitlab-runner做ci，容器镜像是存在gitlab上的，也就是公网kubernetes集群上，emmm，好吧，反正是集群重构势在必行了。 集群重构说的也直接点也就是针对ci的重构，用起内网环境，增加预发环境，将公网Kubernetes的测试环境给剔除掉。 架构图 企业级集群架构图 由上图可知，分三种环境：研发环境（内网环境）；预发环境（和生产环境处于同一VPC）；生产环境（原公网环境【升配】）。 研发环境 研发人员：开发的日常开发工作都在这个环境进行。大部分的基础开发工作都会在该环境进行。 测试人员：主要用于测试验证当前的需求开发是否符合预期。 预发环境 其实就是真实的线上环境，几乎全部的环境配置都是一模一样的

前面写过python 之 unittest初探 和 python 之 unittest+ddt 两篇文章。在之前的文章中，写过可以再次优化。今天写第三篇的目的，就是在原有基础上，基于 openpyxl模块再次优化。在第二篇中，注意到测试数据与代码写在一起，实在是难以维护操作，而我们平时书写测试用例，记录测试数据，通常会使用excel文件或者csv文件。因此，本篇主要使用openpyxl模块对xlsx文件的操作，读取或者写入数据，做到测试数据与代码分离。这样子测试用例也非常便于维护。 基于书中的源码，我做出了一些改动，可以做到在一定格式下，完全读取excel文件的测试数据。本次优化，需要先定义一个DoExcel类，在里面封装2个方法，一个是读取测试数据，另一个是写入数据。 废话少说，直接上代码： 1 # !/usr/bin/python3 2 # -*- coding: utf-8 -*- 3 # @Time :2018/12/11 13:13 4 # @Author :Yosef 5 # @Email :wurz529@foxmail.com 6 # @File: :tryopenpyxl.py 7 # @Software :PyCharm Community Edition 8 import openpyxl 9 class DoExcel(): 10 def __init__

http://tommwq.tech/blog/%e5%85%b3%e4%ba%8e%e4%bd%bf%e7%94%a8junit-4%e6%b5%8b%e8%af%95android%e7%a8%8b%e5%ba%8f%e7%9a%84%e4%b8%80%e7%82%b9%e5%88%86%e6%9e%90/ 1. JUnit 4中的3个核心概念 2. Runner 3. Statement 4. RunNotifier 5. ParentRunner和BlockJUnit4ClassRunner 6. AndroidJUnit4ClassRunner和UIThreadStatement 7. AndroidTestRule和AndroidStatement 8. androidx包中的其他规则 JUnit 4是一种流行的Java单元测试工具。使用JUnit 4和androidx.test包可以为Android程序编写单元测试和Instrument测试。下面我对JUnit 4在Android程序上的使用做一些简单的分析。 1 JUnit 4中的3个核心概念 首先简单介绍一下JUnit 4。JUnit 4是一个单元测试框架，简单来说，JUnit 4的工作就是运行单元测试，然后将结果展示给用户。在这个过程中涉及3个核心概念：表示单元测试的Statement、运行单元测试的Runner

软件测试，爱码小哥邀你同行！ 1. 背景 先来说说花椒测试平台的由来： # 目的1，降低接口测试对测试人员代码能力的要求。测试人员只需要知道接口的url，请求参数，以什么样的格式传个服务端，接口的响应数据里需要验证哪个字段的值即可进行测试，而不需要知道怎么建一个工程，怎么建一个测试类，测试方法，testng是怎么使用的，结果怎么解析，怎么取到想要的字段去做判断。 # 目的2，可视化的case管理，执行，结果管理。打开一个浏览器，根据接口文档新建一个测试case，执行检查接口返回，保存case，建不同入参的该接口的case，组成case集，批量运行，查看运行结果，相比于工程执行批量case，testng的html结果，平台的集中展示更清晰。 # 既然接口的测试已经有case的信息了，对接口进行压测的请求其实也类似一个case，只不过是有很多人在同时执行这个case，所以有了压力测试和接口测试平台的整合。在平台建压测任务的时候选定一个测试用例为载体，多并发的执行case，统计压测数据，实时展示。以往接口测试和压力测试都是分别写一个方法，里面有很多重复的部分。 # 接下来我们会想，像接口测试是由数据驱动的，那么UI自动化是否可以理解为一种另类的驱动呢？UI操作的公共方法如点击，输入，检查元素的值，其实和接口入参和结果检查很像，基于cucumber我们将UI自动化集成进了测试平台

1.unitttest简介 为什么要使用unittest？ 前面我们已经写代码实现了注册接口的处理调用，但是一个接口往往需要多条测试用例才能完整的覆盖到每一种情况，针对于单接口多条测试用例需要执行的情况，我们该如何处理呢？ 在unittest的测试类中定义多个测试方法来完成测试，这可能是大家最先想到的一个解决方法，当然也是能够达到目的的，以下面的注册接口为例，我们基于此思路来编码实现接口的完整测试。 unittest特点 python自带的单元测试框架，无需安装 用例执行互不干扰 提供不同范围的setUp(测试准备)和tearDown(测试清理)方法 提供丰富的断言方法 可以通过discover批量执行所有模块的用例 可以通过TestSuite(测试集)灵活的组织用例 unittest几大组成部分 TestCase: 用例对象，编写测试用例时要继承该类，以具有TestCase的属性和方法 TestSuite: 测试集或测试套件，测试用例的集合，用来组织用例，支持嵌套 TestLoader: 用例加载器，用于向TestSuite中添加用例 TextTestRunner: 用例执行器（输出文本结果），一般以TestSuite为单位执行用例 TestResult: 测试结果 2.接口分析 通过接口的需求分析，我整理了注册接口的三条测试用例： 1）正确的邮箱账号注册 2

1. drone是一款使用 Go 开发的开源的 CI 自动构建平台。原生 Docker 支持，kubernetes也是支持的。drone比argo, tekton更快，更简单，比jenkins更轻量化。drone云原生概念+1，做了很多事不用考虑+1，gitlab/github能看到构建结果+1 环境：kubernetes 1.8+, helm3 参考官方 https://github.com/drone/charts https://docs.drone.io/server/provider/gitlab/ 创建namespace, 添加仓库 kubectl create ns drone helm repo add drone https://charts.drone.io helm repo update 在gitlab中创建一个OAuth应用。Redirect URI是drone的地址并加一个/login，授权两个api, read_user 增加一个文件 drone-server-overrides.yaml 。这里使用的 traefik image: tag: 1.9.0 ingress: enabled: true annotations: traefik.ingress.kubernetes.io/router.tls: "true" traefik.ingress

一、背景 　　最近我们项目越来越多了，然后我就在想如何才能把基础服务的打包方式统一起来，并且可以实现按照我们的要求来生成，通过研究，我们通过使用maven的assembly插件完美的实现了该需求，爽爆了有木有。本文分享该插件的配置以及微服务的统一打包方式。 二、配置步骤及其他事项 1.首先我们需要在pom.xml中配置maven的assembly插件 1 < build > 2 < plugins > 3 < plugin > 4 < groupId > org.apache.maven.plugins </ groupId > 5 < artifactId > maven-jar-plugin </ artifactId > 6 < version > 2.3.1 </ version > 7 < configuration > 8 < archive > 9 < manifest > 10 <!-- 运行jar包时运行的主类，要求类全名 --> 11 < mainClass > com.hafiz.Runner </ mainClass > 12 <!-- 是否指定项目classpath下的依赖 --> 13 < addClasspath > true </ addClasspath > 14 <!-- 指定依赖的时候声明前缀 --> 15 < classpathPrefix

现在大多数公司都很多项目需要自动部署 到多台服务器 代码检查等工作 ，为了提供工作效率往往需要我们的ci就闪亮登场了 今天说一下我所采用的 gitlab-runner 提供的方案 ，感觉这个比较实用而且基本上很多公司也在用gitlab环境 ，应该也很方便部署 减少了再引进其他软件平台所带来的不便，废话不多说 直接进入主题 如何操作使用： 1.找到一个适合自己gitlib 版本的 gitlib-runner 下载 rpm包 2.安装对应的包 rpm -ivh 3.gitlab-runner register 输入你的gitlab地址 4.去gitlab上找到 对应授权的 串码 5.起一下名字 和 标签 和执行方式 6.然后 在你的gitlab上就会出现对应的 一个新的记录 表明你的gitlab已经和对应的服务器进行通讯了（创建的分享类型可以是共享的还有 私有的 或者标注标签的 根据自己的工作需求自己设定） 7.在项目中创建 .gitlab-ci.yml 这个文件中写入你项目要自动执行的内容 比如说PHP可以进行拉代码 同步代码 开启服务等任务。当然现在的大前端趋势下也有很多 任务可以做 代码服务器端 的npm构建 代码的自动检查 等都可以在此文件中进行执行。 具体详情可以参考 https://github.com/Fennay/gitlab-ci-cn 官网中的介绍

不想看前面这么多废话的可以直接跳到 具体实现 Github Actions 是什么？ 说到 Github Actions 不得不提一下。 持续集成 （continuous integration）：高质量的让产品快速迭代 持续交付 （continuous delivery）：交付给团队测试 持续部署 （continuous deployment）：持续交付的下一步核心概念团队测试完成后自动部署到生产环境 CI/CD 是由很多操作组成的(如：执行单元测试、语法检查、打包、部署等等)。Github 把这些操作称为 action ，不同的项目很多的操作都是类似，Github 把这些操作整合成了一个 市场 允许大家发布或使用别人写好的 action 。 Github Actions 的核心概念 操作（Action） action 是工作流中最小的可移植模块 可以创建属于自己的 action ，使用 Github 社区提供的 action 以及自定义公开的 action 在工作流中使用需要将其作为 steps 包含 使用是 用户名/仓储名/版本(或分支) 如： actions/checkout@master 事件（Event） 触发工作流运行的特定事件 Github 本身事件 提交 、 创建问题 、 PR 等 使用 webhook 配置发生在外部的事件 具体事件请参阅 GitHub