Jenkins

源宝导读： 最近几年，微服务架构越来越火爆，逐渐被企业所采用。随着软件架构的变化，对应的软件测试策略需要作何调整呢？本文将介绍云客在微服务架构下的测试策略。 一、云客测试策略模型 策略分析 行业内的测试策略 是一个先底层再上层、从局部到整体的一个过程： 从行业内的演进过程可以看到，项目测试策略在不同阶段结合参考了不同的策略模型：金字塔->近似钻石->蜂巢。 基于行业经验，结合我们实际的架构特点，云客同样划分为不同的层级进行测试：客户端、BFF层、服务层，跟钻石型的过程是类似的。 各层测试侧重点 服务层不正常可能会影响BFF，BFF不正常可能会影响客户端，但每一层级各自验证的侧重点是不同的： 1 客户端 检查客户端（APP、小程序、WEB站点）操作以及操作后的界面呈现。 2 BFF层 不考虑服务层的实现规则和数据库存储，只关注用户在客户端的不同操作场景下，业务逻辑是否达到预期，确保衔接客户端和服务层是否正确。 3 服务层 对单个服务接口逐个测试，需要考虑入参和出参、数据库存储是否符合预期。 二、BFF层测试策略 BFF层测试面临的问题 由于BFF层的接口通常会调用到多个底层服务接口，由此暴露出一系列问题： 涉及业务场景多 涉及多种缓存 自动化用例设计难度大 工具的缺失 BFF层测试策略分析 针对以上问题，考虑云客的BFF层测试策略需要达到以下效果： 解决用例设计困难：

这份文档由阿里巴巴架构师牵头，联合了部门上上下下 P6 - P8 级岗位众人的意见，1.0版本由此诞生。（ 这阵容，质量就不用我多说了吧 ）内容非常全面，主要是结合了互联网大厂的面试需求点，包含了： 分布式架构（大型网站系统的特点+架构演化发展历程+微服务） 中间件技术（缓存+消息队列+搜索引擎） 大数据与高并发技术（秒杀架构设计+数据库架构+阿里巴巴商品信息存放技术+限流算法） 数据库（索引+开发规范+范式+事务+MVCC） 设计模式与实践（常用设计模式+AOP/IOC+Zookeeper） 数据结构与算法（常见算法+红黑树等+HashMap） 虚拟化技术（JVM内存管理+Docker+Jenkins） 面试题实例（真实面试场景提问） 每个知识点都有左侧导航书签页，看的时候十分方便，由于内容较多，这里就截取一部分图吧。需要的记得帮忙点个赞支持一下， 点这里就可以免费拿到这份阿里巴巴架构师牵头总结的“大厂面试参考指南” ！ 设计模式与实践 OOP五大原则SOLID 单一责任原则 开放封闭原则 里氏替换原则 依赖倒置原则 接口分离原则 面向切面编程（AOP）+控制反转IOC 基本思想 登录验证 基于RBAC的权限管理 日志记录 事务处理 统一异常处理 设计模式 代理模式 工厂模式 观察者模式 Zookeeper ZK简述 存储结构 应用场景 写数据流程 Leader选举 中间件 缓存

血泪史 最近在使用Jenkins 拉取Git工程编译代码 时候遇到一个很奇怪的的问题：Jenkins的 GitPlugin 下载代码的版本不对（commitId不对）。由于线上部署和线下部署的编译产物是同一版本，导致最后发布到生产环境的代码版本也不对。这个问题在线上验证阶段才最终被发现，回顾整个job构建过程，控制台没有报错，也成功编译出来了上线包，那到底是哪里出了问题？ 初步定位 我最开始怀疑是 本地Git工程残留 的问题，于是尝试删除jenkins对应job所运行的机器节点上的 WORKSPACE 目录，保证下次触发Jenkins构建能拉取到最新代码。 删除方式： 1. 登陆到运行这个job的节点的机器（在控制台中查看这个job运行的节点，在 第一行 有打印）。 2. 查看$WORKSPACE（在job的控制台中查看；如果找不到，直接在shell executor中加一行echo $WORKSPACE，重新执行job） 3. 删除对应的WORKSPACE信息。 请谨慎操作 ，先看清楚WORKSPACE的值对不对(echo $WORKSPACE)，别搞错导致 删除了根目录！！！ 。 [ -d "$WORKSPACE" ] && rm -rf ${WORKSPACE} 4.删除后重新触发job 这么操作后，最终打包出来的编译产物还是版本不对。 既然不是本地代码缓存问题

顾翔老师的《软件测试技术实战设计、工具及管理》网上购买地址： https://item.jd.com/34295655089.html 《基于Django的电子商务网站》网上购买地址： https://item.jd.com/12082665.html 店铺二维码： 来源：https://blog.csdn.net/ 现如今应该有很多测试人员应该有这样的疑虑，自动化测试要怎么去做，今天把一些学习经验分享给大家，希望对你们有帮助，有说的不好的地方，还请多多指教！ 对于测试人员来说，不管进行功能测试还是自动化测试还是性能测试都是需要编写测试用例，所以我们必须先要了解清楚手工测试用例与自动化测试用例的一些特点，才能更好的开展自动化测试工作。 1、手工测试和自动化测试用例 手工测试用例是针对功能测试人员的，而自动化测试用例是针对自动化测试用例框架或工具的。 1）手工测试用例特点 较好的异常处理能力，能通过人为的逻辑判断校验当前步骤是否正确实现； 人工执行用例具有一定步骤跳跃性； 人工测试步步跟踪，能够细致定位问题； 主要用来发现功能缺陷； 2）自动化测试用例特点 执行对象是脚本，任何一个盘算都需要编码定义； 用例步骤之间关联性强； 主要用来保证产品主体功能正确和完整，让测试人员从繁琐重复的工作中解脱出来； 目前自动化测试阶段定位在冒烟测试和回归测试。 （注意：通过对比发现

分享一个大牛的人工智能教程。零基础！通俗易懂！风趣幽默！希望你也加入到人工智能的队伍中来！请点击 http://www.captainbed.net 什么是自动化测试框架 什么是框架 特指为解决一个开放性问题而设计的具有一定约束性的支撑结构。在此结构上可以根据具体问题扩展、安插更多的组成部分，从而更迅速和方便地构建完整的解决问题的方案。框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。也就是说框架本身不解决特定的问题，它是通过扩展的各种组件或者工具来解决问题，并且它可以方便的添加或者修改部分组件的功能。 什么是自动化测试框架 什么是自动化测试框架，我们拆分来看的话，其实就是三个方面，自动化、测试、框架，什么是框架上面说了，还有就是他能执行测试，而且还是自动化的，所以框架的各个组件的主要功能就是围绕着如何自动化如何执行测试展开的。 这里可以把框架的各个功能称作模块，那我们来看看都需要那些模块：需要一个基础模块，主要是怎么实现脚本编写；管理模块，主要的行为是持续集成，定时执行、case管理；统计模块，主要是发送测试报告，统计分析。那总结一下自动化测试框架的定义就是： 把在自动化测试过程中用到的一些功能或者工具，封装成各个模块，包括如何进行自动化脚本编写以及分层功能的基础模块，进行持续集成、定时任务的管理模块，发送测试报告、进行测试结果统计分析的统计模块等

SonarQube安装 https://docs.sonarqube.org/6.7/RunningSonarQubeasaServiceonLinux.html 主机配置：CPU 2C 内存>4G 数据库安装 安装依赖包 yum install vim gcc gcc-c++ wget autoconf net-tools lrzsz iotop lsof iotop bash-completion curl policycoreutils openssh-clients postfix -y 安装数据库5.6版本 tar -xvf mysql-5.6.48-linux-glibc2.12-x86_64.tar.gz mv mysql-5.6.48-linux-glibc2.12-x86_64 /usr/local/mysql groupadd mysql useradd -r -g mysql mysql cd /usr/local/mysql/ mkdir ./data/mysql chown -R mysql:mysql ./ ./scripts/mysql_install_db --user=mysql --datadir=/usr/local/mysql/data/mysql cp support-files/mysql.server /etc/init.d