通知：《打工人日报》迁移到独立板块 考虑到近期的一些情况，我决定将《打工人日报》迁移到独立板块，将不在首页展示，后续的更新将在独立板块中进行。不影响原文章的阅读和订阅邮件的推送。感谢各位的支持和关注！！！ 访问地址 访问链接 首页点击访问

分享一款 去除视频中移动的物体。的本地部署软件，完全免费！ 效果 物体移除 水印去除 下载地址 国内下载 代码仓库 ProPainter 安装 1git clone https://github.com/sczhou/ProPainter.git 1conda create -n propainter python=3.8 -y 2conda activate propainter 3cd ProPainter 4pip3 install -r requirements.txt 版本要求 CUDA >= 9.2 PyTorch >= 1.7.1 Torchvision >= 0.8.2 开始使用 准备预训练模型 预训练模型从版本 V0.1.0 下载到 weights 文件夹。 https://github.com/sczhou/ProPainter/releases/tag/v0.1.0 1weights 2 |- ProPainter.pth 3 |- recurrent_flow_completion.pth 4 |- raft-things.pth 5 |- i3d_rgb_imagenet.pt (for evaluating VFID metric) 6 |- README.md 快速测试 1# The first example (object removal) 2python inference_propainter.

背景 calibre-web 支持opds协议，ip+端口/opds就是opds路径，所有支持opds的客户端都可以。安卓下推荐静读天下，ios推荐kybook 3，我这边主要介绍一下，kybook 3。 KyBook 3 支持几乎所有主要的电子书格式，包括： EPub、FictionBook（fb2，fb2.zip）、纯文本和富文本（txt，rtf）、PDF、漫画（CBR，CBZ，CBT）、MobiPocket、Kindle（mobi，azw3）以及有声读物（mp3，m4a，m4b）。 基本上你在网络上找到的书籍资源，都可以用 KyBook 3 打开。 下载 KyBook 3 下载 添加OPDS源 打开KyBook 3 -> 底部目录 -> 添加 添加源地址 https://ip:port/opds 例如 https://192.168.1.1:8080/opds 2. 输入密码 添加书籍 总结 亚马逊 Kindle 一直是受欢迎的电子书阅读器，在我看来，它的巨大优势之一在于亚马逊丰富的线上资源，可以很方便地购买，并在 PC、移动端和实体 Kindle 上同步观看。 KyBooks 3 相比之下，最强大的在于对不同文件格式的支持，以及丰富的阅读自定义设置。 不足 当然，Kybooks 3 也存在一些问题，比如不少人都反馈无法注册，从而影响同步，这应该和 KyBook 的服务器设置有关。还有它仅支持iOS端，平台多少有些单一了。 你可以在 Appstore 免费下载 KyBook 3，它提供了「专业版」与「高级订阅」两个内购的选项：「专业版」包含去广告（不过免费版目前并没有广告）、用户辞典、手写标注、自动滚动等功能，花费 4.99$ 可永久升级，你可以免费体验 14 天以绝对是否购买。 「高级订阅」在解锁了全部「专业版」功能外，还允许用户使用 KyBook 服务器在不同设备间同步数据，年费为 14.99$，但因为前面所说的登陆问题，同步功能的体验可能会受到影响。

tmux 是一个终端 multiplexer，它可以让你在一个终端中开启多个会话，并且可以在一个终端中切换多个会话。 安装 tmux 安装很简单，直接在终端中输入以下命令即可： 1# Ubuntu 或 Debian 2sudo apt-get install tmux 3 4# CentOS 或 Fedora 5sudo yum install tmux 6 7# Mac 8brew install tmux 使用 安装完成后，键入tmux命令，就进入了 Tmux 窗口。 1tmux 按下Ctrl+d或者显式输入exit命令，就可以退出 Tmux 窗口。 1exit 前缀键 Tmux 窗口有大量的快捷键。所有快捷键都要通过前缀键唤起。默认的前缀键是Ctrl+b，即先按下Ctrl+b，快捷键才会生效。 举例来说，帮助命令的快捷键是Ctrl+b ?。它的用法是，在 Tmux 窗口中，先按下Ctrl+b，再按下?，就会显示帮助信息。 然后，按下 ESC 键或q键，就可以退出帮助。 快捷键 面板（pane）指令 前缀 指令 描述 Ctrl+b " 当前面板上下一分为二，下侧新建面板 Ctrl+b % 当前面板左右一分为二，右侧新建面板 Ctrl+b x 关闭当前面板（关闭前需输入y or n确认） Ctrl+b z 最大化当前面板，再重复一次按键后恢复正常（v1.8版本新增） Ctrl+b ! 将当前面板移动到新的窗口打开（原窗口中存在两个及以上面板有效） Ctrl+b ; 切换到最后一次使用的面板 Ctrl+b q 显示面板编号，在编号消失前输入对应的数字可切换到相应的面板 Ctrl+b { 向前置换当前面板 Ctrl+b } 向后置换当前面板 Ctrl+b Ctrl+o 顺时针旋转当前窗口中的所有面板 Ctrl+b 方向键 移动光标切换面板 Ctrl+b o 选择下一面板 Ctrl+b 空格键 在自带的面板布局中循环切换 Ctrl+b Alt+方向键 以5个单元格为单位调整当前面板边缘 Ctrl+b Ctrl+方向键 以1个单元格为单位调整当前面板边缘（Mac下被系统快捷键覆盖） Ctrl+b t 显示时钟 系统指令 前缀 指令 描述 Ctrl+b ?

背景 6 月 6 日，上海交大的 Docker Hub 镜像加速器宣布因收到通知要求被下架。声明称：“即时起我们将中止对 dockerhub 仓库的镜像。docker 相关工具默认会自动处理失效镜像的回退，如果对官方源有访问困难问题，建议尝试使用其他仍在服务的镜像源。我们对给您带来的不便表示歉意，感谢您的理解与支持。”Docker Hub 是目前最大的容器镜像社区，去年 5 月起国内用户报告 Docker Hub 官网无法访问，其网址解析返回了错误 IP 地址。 因为不能直接访问国外的镜像仓库，下载国外的docker镜像速度一直很慢, 国内从 Docker Hub 拉取镜像有时会遇到困难，此时可以配置镜像加速器。 使用 我这边已经部署好了加速镜像节点，同学们如果不想自己部署，可以使用我的加速节点，但是，不能保证节点长期有效。 1https://dockerhub.jobcher.com 第一步：代理拉取镜像 假如我们下载node镜像，那么我们可以这样写： 1docker pull dockerhub.jobcher.com/library/node:latest 2# 或者 3docker pull dockerhub.jobcher.com/bitnami/node:latest 第二步：重命名镜像 1docker tag dockerhub.jobcher.com/library/node:latest node:latest 2# 或者 3docker tag dockerhub.jobcher.com/bitnami/node:latest node:latest 第三步：删除代理镜像 1docker rmi dockerhub.jobcher.com/library/node:latest 2# 或者 3docker rmi dockerhub.jobcher.com/bitnami/node:latest 或者直接配置到镜像仓库 1sudo mkdir -p /etc/docker 2sudo tee /etc/docker/daemon.json <<-'EOF' 3{ 4 "registry-mirrors": [ 5 "https://dockerhub.

背景 使用 docker compose up 部署新版本的服务会导致停机，因为应用容器在创建新容器之前已停止。如果你的应用程序需要一段时间才能启动，用户可能会注意到这一点。为了保障服务用户无感，可以使用docker rollout 适合没必要用 K8S 轻量级小项目 安装 项目地址 1# 为 Docker cli 插件创建目录 2mkdir -p ~/.docker/cli-plugins 3 4# 下载 docker-rollout 脚本到 Docker cli 插件目录 5curl https://github.jobcher.com/gh/https://raw.githubusercontent.com/wowu/docker-rollout/master/docker-rollout -o ~/.docker/cli-plugins/docker-rollout 6 7# 使脚本可执行 8chmod +x ~/.docker/cli-plugins/docker-rollout 使用 注意事项！！！ 服务不能在 docker-compose.yml 中定义 container_name 和 ports ，因为不可能运行具有相同名称或端口映射的多个容器。 需要像 Traefik 或 nginx-proxy 这样的代理来路由流量。 每次部署都会增加容器名称中的索引（例如 project-web-1 -> project-web-2 ） 使用示范 1# 下载代码 2git pull 3# 构建新的应用程序映像 4docker compose build web 5# 运行数据库迁移 6docker compose run web rake db:migrate 7# 部署新版本 8docker rollout web 或者使用docker-compose.

背景 Stable Diffusion 在训练数据集之前，需要先对数据进行预处理。 本篇文章就是介绍如何对图像进行批量预处理。 图片上传 上传图像到你指定目录，我的目录时/mnt/smb/ 打开SD-web地址，进入192.168.1.232:7861，选择附加功能，进行图像预处理 批量抠图 选择从目录进行批量处理 填写输入目录和输出目录 举例： 原本我的共享文件夹 地址是\\192.168.1.249\DB Training\ai-pre-photo\out-photo 将所有的 \\192.168.1.249\DB Training\ 改为 /mnt/smb/ 所有的 \ 改为 / 因此 需填写地址如下图： 选择抠图模型 滑倒最底部选择背景去除算法,选择你要使用的算法，我这边选择silueta算法,可以根据你自己的需求使用算法 执行生成 点击生成按钮，开始对图像批量处理 查看生成的图像 在对应的共享文件夹也可以查看

背景 ComfyUI 是用于稳定扩散的基于节点的用户界面。ComfyUI 由 Comfyanonymous 于 2023 年 1 月创建，他创建了该工具来学习稳定扩散的工作原理。 效果 webui和ComfyUI之间的区别,相比较webUI，ComfyUI更工业化，更符合高级使用者的配置 安装 安装本体 下载软件 1mkdir ~/sd-web 2cd ~/sd-web 3git clone https://github.jobcher.com/gh/https://github.com/comfyanonymous/ComfyUI.git 环境依赖 1cd ~/sd-web/ComfyUI 2conda create -n ComfyUI python=3.10 3pip install -r requirements.txt -i https://pypi.douban.com/simple --trusted-host=pypi.douban.com 下载sd_xl_turbo模型 1aria2c --console-log-level=error -c -x 16 -s 16 -k 1M https://huggingface.jobcher.com/https://huggingface.co/stabilityai/sdxl-turbo/resolve/main/sd_xl_turbo_1.0_fp16.safetensors -d ~/sd-web/ComfyUI/models/checkpoints -o sd_xl_turbo_1.0_fp16.safetensors 启动服务 1cd ~/sd-web/ComfyUI 2python main.py --listen --port 6006 --cuda-device 1 webUI共享模型 1cd 2mv extra_model_paths.yaml..example extra_model_paths.yaml 编辑参数 1vim extra_model_paths.yaml 修改 base_path: path/to/stable-diffusion-webui/ 改为你的webui实际地址，例如： base_path: ~/sd-web/stable-diffusion-webui/ 1#config for a1111 ui 2#all you have to do is change the base_path to where yours is installed 3a111: 4 base_path: path/to/stable-diffusion-webui/ ## 这里改为你实际的webui地址 5 6 checkpoints: models/Stable-diffusion 7 configs: models/Stable-diffusion 8 vae: models/VAE 9 loras: | 10 models/Lora 11 models/LyCORIS 12 upscale_models: | 13 models/ESRGAN 14 models/RealESRGAN 15 models/SwinIR 16 embeddings: embeddings 17 hypernetworks: models/hypernetworks 18 controlnet: models/ControlNet 重启服务

背景 Stable Diffusion (稳定扩散) 是一个扩散模型，2022年8月由德国CompVis协同Stability AI和Runway发表论文，并推出相关程序。 AUTOMATIC1111开发了图形化界面：「Stable Diffusion WebUI」，这是能用AI技术生成图片的开源软件，只要给定一组描述文本，AI就会开始绘图(准确的说是「算图」或「生图」)；亦能模仿现有的图片，生成另一张图片。甚至给它一部分涂黑的图片，AI也能按照你的意愿将图片填上适当的内容。除此之外还支持自行训练模型加强生图效果。 本篇文章就是介绍如何安装 stable-diffusion-webui 安装conda 在 Ubuntu 上安装 Anaconda 的步骤如下： 首先，你需要下载 Anaconda 的安装包。你可以从 Anaconda 的官方网站上下载最新版本的 Anaconda for Linux。选择适合你的系统的版本（Python 3.x）。 访问下载链接：https://www.anaconda.com/products/distribution#download-section 下载完成后，你可以在终端中导航到下载的文件所在的目录。你可以使用 cd 命令来改变目录。例如，如果你的下载文件在 Downloads 文件夹中，你可以输入以下命令： 1cd ~/Downloads 然后，你需要运行 bash 命令来安装 Anaconda。假设你下载的 Anaconda 文件名为 “Anaconda3-2020.02-Linux-x86_64.sh”，你可以输入以下命令： 1bash Anaconda3-2020.02-Linux-x86_64.sh 请注意，你需要将上述命令中的 “Anaconda3-2020.02-Linux-x86_64.sh” 替换为你实际下载的文件名。 4. 接下来，你会看到 Anaconda 的许可协议。按 Enter 键滚动到底部，然后输入 ‘yes’ 来接受许可协议。 5. 然后，你需要确认 Anaconda 的安装位置。你可以选择默认位置或输入新的位置。 6. 安装完成后，你会看到一个提示，询问你是否希望 Anaconda3 添加到你的 PATH。你应该输入 ‘yes’。 7. 最后，你需要激活安装。你可以通过关闭并重新打开终端或运行以下命令来完成此操作： 1source ~/.bashrc 验证安装。在终端中输入以下命令： 1conda list 如果安装成功，这个命令会显示一个已安装的包的列表。

单元测试的价值 单元测试是一种白盒测试技术，通常由开发人员在编码阶段完成，目的是验证软件代码中的每个单元（方法或类等）是否符合预期，即尽早在尽量小的范围内暴露问题。 我们都知道，问题发现得越早，修复的代价越小。毫无疑问，在开发阶段进行正确的单元测试可以极大地节省时间和金钱。如果跳过单元测试，会导致在后续更高级别的测试阶段产生更高的缺陷修复成本。 如图，假如有一个只包含两个单元 A 和 B 的程序，且只执行端到端测试，如果在测试过程中发现了缺陷，则可能有如下多种原因： 该缺陷由单元 A 中的缺陷引起； 该缺陷由单元 B 中的缺陷引起； 该缺陷由单元 A 和单元 B 中的缺陷共同引起； 该缺陷由单元 A 和单元 B 之间接口的缺陷引起； 该缺陷是测试方法或测试用例的错误导致的。 由此可见，忽略单元测试会导致后续发现缺陷时，要花费较高的成本来确认缺陷原因。 单元测试除了能够在较早阶段识别软件中的错误，它还有如下价值。 反馈速度快：单元测试通常以自动化形式运行，执行速度非常快，可以快速反馈结果，跟持续集成结合起来，形成有效的反馈环。 重构的有力保障：系统需要大规模重构时，单测可以确保对已有逻辑的兼容，如果单元测试都通过，基本上可以保证重构没有破坏原来代码逻辑的正确性。 使更熟悉代码：写单元测试的过程本身就是一个审视代码的过程，可以发现一些设计上的问题（代码设计的不可测试）、代码编写方面的问题（边界条件的处理不当）等。 既然单元测试由开发人员来设计和执行，那作为测试人员是不是就不需要学习这门技术了？不知道你是怎样看待这个想法的，我的观点是： 单元测试只是通常情况下由开发人员完成，并不是绝对的，在一些公司或项目里也存在测试人员完成的情况； 在你负责的模块或服务里，第一级别的测试不是你来完成的，那么你更有必要去了解它的设计思路和执行情况，这能帮助你发现单元测试可能存在的问题点，也有利于你设计和执行后续高级别的测试类型； 开发人员总是不太擅长做测试类的工作，当你掌握了单元测试的技能，你便更有机会去帮助和影响到开发人员，赢得他对你的尊重，也有利于你们更好地合作； 这种想法是测试人员的常见想法，所以掌握单元测试技能在测试人员群体中也会是稀缺技能，因此，掌握它将会获得额外的锻炼机会和个人影响力，要知道，机会总是留给有准备的人。 微服务下的单元测试类型 就像之前课程所说：微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，服务与服务之间常常互相调用以实现更多更复杂的功能。 举个例子，我们需要测试的是订单类（Order）中的获取总价方法（getTotalPrice()），而在该方法中除了自有的一些代码逻辑外，通常需要去调用其他类的方法。比如这里调用的是用户类（User）的优惠等级方法（reductionLevel ()）和商品类（Goods）中的商品价格方法（getUnitPrice()）。很显然，优惠等级方法或商品价格方法，只要一方有错误，就会导致订单类获取总价方法的测试失败。基于这种情况，可以有两种单元测试类型。 1. 社交型单元测试（Sociable Unit Testing） 如图，测试订单类的获取总价方法（Order.getTotalPrice()）时会真实调用用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）。将被测试单元视为黑盒子，直接对其进行测试，这种单元测试称之为社交型单元测试（Sociable Unit Testing）。 2. 孤立型单元测试（Solitary Unit Testing） 如图，如果测试订单类的获取总价方法（Order.getTotalPrice()）时，使用测试替身 （test doubles） 技术来替代用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）的效果。对象及其依赖项之间的交互和协作被测试替身代替，这种单元测试称之为孤立型单元测试（Solitary Unit Testing）。 另外，上述提到的测试替身是一种在测试中使用对象代替实际对象的技术，常用的技术如下。 桩代码（Stubs）：当在对象上调用特定方法时，会对其进行硬编码（临时代码）的方式来代替真实代码提供固定响应。比如，某函数 X 的实现中调用了一个函数 Y，而 Y 不能调用，为了对函数 X 进行测试，就需要模拟一个函数 Y，那么函数 Y 的实现就是所谓的桩代码。 模拟代码（Mocks）：模拟代码跟桩代码类似，它除了代替真实代码的能力之外，更强调是否使用了特定的参数调用了特定方法，因此，这种对象成为我们测试结果的基础。 根据被测单元是否与其交互者隔离，会产生以上两种单元测试类型，这两种类型的单元测试在微服务测试中都起着重要作用，它们用来解决不同的测试问题。

可以从两个方面来保障微服务的质量： 选取合适的测试策略模型，确保测试活动全面且有效； 建立质量保障体系，使质量保障内化为企业的组织能力。 如何选择合适的测试策略模型？ 要想使面向微服务的测试活动全面且有效，可以借用“测试金字塔”的思想，针对不同类型和颗粒度的测试投入不同的精力，达到一个最佳平衡： 测试需要分层，每一层的测试颗粒度有所不同； 不同层次的测试比重有差异，通常来说，层次越高，测试比重应越少。 需要说明的是，传统意义下的测试金字塔，在微服务架构下不再完全奏效。因为微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，这一点值得特别注意。 因此，针对微服务架构，常见的测试策略模型有如下几种。 （1） 微服务“测试金字塔” 基于微服务架构的特点和测试金字塔的原理，Toby Clemson 有一篇关于“微服务架构下的测试策略”的文章，其中通过分析阐述了微服务架构下的通用测试策略。 如图，该策略模型依然是金字塔形状，从下到上依次为单元测试、集成测试、组件测试、端到端测试、探索式测试。 （2） 微服务“测试蜂巢” 这种策略模型是蜂巢形状，它强调重点关注服务间的集成测试，而单元测试和端到端测试的占比较少。 （3） 微服务“测试钻石” 这种策略模型是钻石形状的，组件测试和契约测试是重点，单元测试比率减少，另外增加了安全和性能等非功能的测试类型。 我想，有多少个基于微服务架构的测试团队大概就有多少个测试策略模型吧。“测试金字塔”是一种测试策略模型和抽象框架，当技术架构、系统特点、质量痛点、团队阶段不同时，每种测试的比例也不尽相同，而且最关键的，并不一定必须是金字塔结构。 理解了测试策略模型的思考框架，我们看下应如何保障测试活动的全面性和有效性。 全面性 微服务架构下，既需要保障各服务内部每个模块的完整性，又需要关注模块间、服务间的交互。只有这样才能提升测试覆盖率和全面性，因此，可以通过如下的分层测试来保证微服务的全面性。 单元测试（Unit Test） ：从服务中最小可测试单元视角验证代码行为符合预期，以便测试出方法、类级别的缺陷。 集成测试（Integration Test）：验证当前服务与外部模块之间的通信方式或者交互符合预期，以便测试出接口缺陷。 组件测试 （Component Test）：将测试范围限制在被测系统的一部分（一般是单个服务），使用测试替身（test doubles）将其与其他组件隔离，以便测试出被测代码的缺陷。 契约测试（Contracts Test）：验证当前服务与外部服务之间的交互，以表明它符合消费者服务所期望的契约。 端到端测试（End-to-end Test）：从用户视角验证整个系统的功能能否符合用户的预期。 可见，上述测试策略模型中的测试方法，是自下而上逐层扩大测试范围和边界，力保微服务架构的模块内、模块间交互、服务内、服务间交互、系统范围等维度的功能符合预期。 有效性 确定了分层测试方法，我们应该如何选取每种测试方法的比例，来确保该测试策略的有效性呢？ 首先必须要明确的是不存在普适性的测试组合比例。我们都知道，测试的目的是解决企业的质量痛点、交付高质量的软件。因此不能为了测试而测试，更不能为了质量而不惜一切代价，需要考虑资源的投入产出比。 测试策略如同测试技术、技术架构一样，并不是一成不变，它会随着业务或项目所处的阶段，以及基于此的其他影响因素的变化而不断演进。但归根结底，还是要从质量保障的目标出发，制定出适合当时的测试策略，并阶段性地对策略进行评估和度量，进而不断改进和优化测试策略。因此，选取测试策略一定要基于现实情况的痛点出发，结果导向，通过调整测试策略来解决痛点。 比如，在项目早期阶段或某 MVP 项目中，业务的诉求是尽快发布到线上，对功能的质量要求不太高，但对发布的时间节点要求非常严格。那这种情况下快速地用端到端这种能模拟用户真实价值的测试方法保障项目质量也未尝不可；随着项目逐渐趋于平稳后，时间要求渐渐有了节奏，对功能的质量要求会逐渐变高，那么这时候可以再根据实际情况引入其他测试方法，如契约测试或组件测试等。 你要永远记住，适合自身项目阶段和团队的测试策略才是“完美”的策略。 如何建立质量保障体系？ 上述分层的测试策略只是尽可能地对微服务进行全面的测试，确保系统的所有层次都被覆盖到，它更多体现在测试活动本身的全面性和有效性方面。要想将质量保障内化为企业的组织能力，就需要通过技术和管理手段形成系统化、标准化和规范化的机制，这就需要建设质量保障体系。 质量保障体系：通过一定的流程规范、测试技术和方法，借助于持续集成/持续交付等技术把质量保障活动有效组合，进而形成系统化、标准化和规范化的保障体系。 同时，还需要相应的度量、运营手段以及组织能力的保障。 如下几个方面是质量保障体系的关键，后续课程也将按如下方式展开讲解。 流程规范：没有规矩不成方圆，好的流程规范是保障质量中非常关键的一环。当出现交付质量差的情况时，过程质量也一定是差的。通常会出现某些关键动作未执行或执行不到位、对事情的不当处理等情况，而这些情况可以通过建立闭环、分工明确的流程规范完全可以避免。另外，研发过程中，过程质量跟执行人的质量意识、个人能力等直接相关，那么就需要建立易执行的流程规范，降低人员的执行门槛。同时需要特别注意，规范的不断完善是几乎所有团队的常态，但当规范执行效果不好时一定要及时跟进，分析其根本原因，必要时要进行简化。 测试技术： 测试策略模型中的分层测试方法可以使面向微服务的测试活动具有一定的全面性和有效性，使得被测内容在功能方面符合预期。除功能性之外，软件质量还有其他很多属性，如可靠性、易用性、可维护性、可移植性等，而这些质量属性就需要通过各种专项测试技术来保障了。同时，还有许多测试技术的首要价值在于提升测试效率。因此合理地组合这些测试技术，形成测试技术矩阵，有利于最大化发挥它们的价值。 持续集成与持续交付：微服务的优势需要通过持续集成和持续交付的支持才能充分发挥出来，这就要求在执行测试活动时提高反馈效率、尽快发现问题。一方面要明确各种“类生产环境”在交付流程中的位置和用途差异点，保证它们的稳定可用。另一方面需要将各种测试技术和自动化技术集成起来，使代码提交后能够自动进行构建、部署和测试等操作，形成工具链，实现真正意义上的持续集成和持续交付。 度量与运营：管理学大师德鲁克曾经说过“你如果无法度量它，就无法管理它（It you can’t measure it, you can’t manage it)”。要想能有效管理和改进，就难以绕开度量这个话题。对于研发过程来说，度量无疑是比较难的，它是一个脑力密集型的过程，指标多维度，且很多维度的内容难以清晰地度量。在质量保障体系中，我将基于质量、效率、价值等多维度视角建立起基础的度量体系，并结合定期运营做定向改进，形成 PDCA 正向循环，促使各项指标稳步提升。同时，需要特别警惕的是，度量是一把双刃剑，这里我也会告诉一些我的经验教训和踩过的坑，避免走错方向。 组织保障：产品的交付离不开组织中每个参与部门成员的努力。正如质量大师戴明所说，质量是设计出来的，不是测试出来的。因此在组织中树立起“质量文化”至关重要。在这部分内容里，我将介绍常见的参与方的角色、职责和协作过程中的常见问题、对策，以及如何营造质量文化等内容。 总结 谈到了基于微服务架构下的各种质量挑战，可以从两个方面有效且高效地保障微服务的质量：确保面向微服务的测试活动具备全面性和有效性，质量保障需要内化为企业的组织能力。

端到端测试详解 定义 端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。 它模拟用户真实的使用场景，通过用户界面测试应用程序，如图所示： 与其他类型的测试相反，端到端测试是面向业务的，其目的是验证应用程序系统整体上是否符合业务目标。为了实现这一目标，该系统通常被视为黑盒子：尽可能完整地部署系统中的微服务，并主要通过 GUI 和 API 等公共接口对其进行操作。 GUI：Graphical User Interface，又称图形用户界面或图形用户接口。它是采用图形方式显示的计算机操作用户界面，是一种人与计算机通信的界面显示格式，允许用户使用鼠标等输入设备操纵屏幕上的图标或菜单选项，以选择命令、调用文件、启动程序或执行其他一些日常任务。 API：Application Programming Interface，又称呼应用程序编程接口或应用程序接口。它是一组定义、程序及协议的集合，通过 API接口实现计算机软件之间的相互通信。API 的一个主要功能是提供通用功能集，同时也是一种中间件，为各种不同平台提供数据共享。 由于微服务架构包含多个具有相同行为的活动部件，因此端到端测试为服务之间传递消息的正确性提供了更多的信心，而且还可以确保正确配置了其他网络基础结构，例如防火墙、代理或负载均衡等。 测试范围 通过微服务的分层测试策略可知，端到端测试的范围比其他类型的测试大得多。 分层测试策略-测试范围 绝大多数情况下，微服务应用系统会依赖一个或多个由外部管理的微服务。通常，这些外部服务包含在端到端测试范围内。 但是，在极少数情况下，也可以主动排除它们。因为如果外部服务由第三方管理，可能会经常出现稳定性和可靠性问题，这会导致端到端测试因不可控的原因而失败。 微服务应用的典型示例 比如，某个应用程序系统依赖公安部门的背景审查服务，通过调用该服务来查询用户是否有过违法前科。首先这样的服务通常会按调用次数付费（每次 5-10 元），具有较高的测试成本，其次背景审查服务不总是稳定可用的。在这种情况下，通过服务虚拟化技术模拟背景审查服务是个不错的选择，这虽然多少会降低端到端测试的信心，但增加了测试用例套件的稳定性。 测试入口 因为端到端测试是面向业务的，那么测试时要从真实用户的使用场景来进行测试，根据应用程序系统是否有 GUI，可以分为两种情况： 应用程序系统有 GUI，这种情况下用户可以直接操作 GUI 来使用系统，那么诸如 Selenium WebDriver 之类的工具可以帮助驱动 GUI 触发系统内的特定行为。 应用程序系统没有 GUI，这种情况下，使用 HTTP 客户端通过其公共的 API 直接操作微服务。没有真实的 GUI，不能直观地看到业务功能行为，但可以通过后台数据来确定系统的正确性，比如 API 的返回结果、持久化数据的变化情况，等等。 测试设计 确定测试范围和测试入口后，可以进一步梳理出要测试的功能列表或用例集，并对其按业务能力、优先级、重要性等维度进行分组。这样可以将它们拆分为较小的任务，以便整个团队可以排序处理，比如可以首先实施优先级较高的用例组，或按紧急程度处理关键的用例，这有助于我们尽早消除潜在的障碍。 另外，由于端到端测试的目标是完全集成后的系统的行为，使得编写和维护测试用例会比其他类型的测试更加困难： 端到端测试涉及的活动部件比其他测试多得多； 端到端测试须考虑系统中的异步处理。 这些因素都可能给端到端测试带来挑战，比如测试过程不稳定、测试时间过长、测试用例集的维护成本高，等等。因此，应尽可能以最粗粒度进行端到端的测试设计。 如何开展端到端测试？ 熟悉了端到端测试的基本内容，我们来看下如何开展端到端测试，主要有如下几类： UI 自动化 对于带有 GUI 的应用程序系统，在进行端到端测试时，可以通过 UI 自动化的方式进行。如果 GUI 是 Web 形式，则 Selenium 是首选工具；如果 GUI 是 Native 形式，则可以使用 Appium。