最近我们准备把一些服务从一个二次开发的 k8s 平台迁移到另一个二次开发的 k8s 平台去，这时候我们遇到了一个比较棘手的问题：因为迁移是有损的，也就是说迁移的过程中伴随着一定量的代码修改和容器编排方式的适配，那么我们如何保证服务迁移以后的功能是正常可用的呢？

想了一些方法，这些办法其实比较常见：

• 增加监控指标和告警指标，迁移后如果服务有问题那么这些指标会让我们尽可能快的发现问题；
• 增加自动化的测试用例，通过用例尽可能的对现有服务功能进行覆盖；

那么问题就来了，如何用最低的成本去实现这些自动化用例呢？

首先我们应该选择合适类型的自动化用例，目前我们可以实现的用例有

• 单元测试用例，实现成本高，但是运行成本低，运行速度快，服务没有启动的情况下也能跑，如果有的选，那么单元测试用例是首选；
• 接口级的测试用例，实现成本相对较低，运行成本高，需要服务跑起来才能进行测试，运行速度相对单元测试是慢一些的；
• ui 自动化测试用例，实现成本高，运行成本也高，运行速度也慢；

最终我们选择增加一些核心的单元测试用例和 ui 自动化用例，然后尽可能多写接口测试用例。

我们的服务实现了一些微服务化，请求从最前面接入层进来之后会到 http 层，该层会调用更下层的 rpc 微服务层实现具体的业务逻辑，因此我们的接口就有两种，分别是

• http 接口，客户端直接调用
• rpc 接口，http 层以及微服务之间进行调用

因为业务逻辑往往需要多次的 rpc 调用才能实现，所以直接写 http 层的接口测试用例相对来说是一种比较经济的方式，因为一次的 http 接口调用会产生多次的 rpc 调用，从业务逻辑上和服务的触达性上来说都是令人满意的。

那么怎么去用尽可能最低的成本去实现这些 http 接口的用例呢？我之前有过使用 postman 把自己变成一个没有感情的用例生成机器的经历，在这里可以给大家分享一下。

举一个具体的例子，看这个接口。

POST /api/users

请求
{
  "user":{
    "username": "Jacob",
    "email": "jake@jake.jake",
    "password": "jakejake"
  }
}

响应
{
  "user": {
    "email": "jake@jake.jake",
    "token": "jwt.token.here",
    "username": "jake",
    "bio": "I work at statefarm",
    "image": null
  }
}

这是一个用户注册的 POST 接口，需要向后端传 json 类型的数据，我们可以看成是传递一个 user 对象，这个对象有 username, email 和 password 属性，用 json 字符串的形式表达出来而已。

我们很多时候都需要 mock 服务，比如

• 在做性能测试的时候，我们希望调用第三方服务的接口可以被 mock 掉，这样就不会因为压测而对第三方依赖造成巨大的负载
• 第三方服务归属于其他团队，不同环境之间的沟通和协调其实比较麻烦
• 消除不同测试环境之间的差异
• 控制请求的时延
• 如果是使用云服务的话，使用 mock 接口还可以节约出口的带宽
• 提升第三方服务的稳定性

所以 mock 的作用就是用最小的代价实现跟第三方接口几乎一样的假的接口，最好返回的内容是动态可配置的，这样我们在测试环境就可以直接去调用这个假接口，从而消除了对第三方的依赖。

实现 mock 的方式很多，最简单的做法就是随机应变，自行实现，比如在 python 技术栈里，我们可以用 flask 去这样实现

from flask import Flask, jsonify

app = Flask(__name__)

@app.route('/api/get-json')
def hello():
    return jsonify(hello='world') # Returns HTTP Response with {"hello": "world"}

用 go 实现起来也不难，下面的例子来自 go 的官方文档，使用了 gin 框架。https://go.dev/doc/tutorial/web-service-gin

package main

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

// album represents data about a record album.
type album struct {
    ID     string  `json:"id"`
    Title  string  `json:"title"`
    Artist string  `json:"artist"`
    Price  float64 `json:"price"`
}

// albums slice to seed record album data.
var albums = []album{
    {ID: "1", Title: "Blue Train", Artist: "John Coltrane", Price: 56.99},
    {ID: "2", Title: "Jeru", Artist: "Gerry Mulligan", Price: 17.99},
    {ID: "3", Title: "Sarah Vaughan and Clifford Brown", Artist: "Sarah Vaughan", Price: 39.99},
}

func main() {
    router := gin.Default()
    router.GET("/albums", getAlbums)
    router.GET("/albums/:id", getAlbumByID)
    router.POST("/albums", postAlbums)

    router.Run("localhost:8080")
}

// getAlbums responds with the list of all albums as JSON.
func getAlbums(c *gin.Context) {
    c.IndentedJSON(http.StatusOK, albums)
}

// postAlbums adds an album from JSON received in the request body.
func postAlbums(c *gin.Context) {
    var newAlbum album

    // Call BindJSON to bind the received JSON to
    // newAlbum.
    if err := c.BindJSON(&newAlbum); err != nil {
        return
    }

    // Add the new album to the slice.
    albums = append(albums, newAlbum)
    c.IndentedJSON(http.StatusCreated, newAlbum)
}

// getAlbumByID locates the album whose ID value matches the id
// parameter sent by the client, then returns that album as a response.
func getAlbumByID(c *gin.Context) {
    id := c.Param("id")

    // Loop through the list of albums, looking for
    // an album whose ID value matches the parameter.
    for _, a := range albums {
        if a.ID == id {
            c.IndentedJSON(http.StatusOK, a)
            return
        }
    }
    c.IndentedJSON(http.StatusNotFound, gin.H{"message": "album not found"})
}

从上面的代码可以看出来，如果不需要实现创建接口的话，代码量还能少三分之一左右，总的来看其实难度也不算大。

最近看到一篇文章是关于软件测试与节能减排的讨论的，可持续发展这个观点在西方国家目前经常被拿出来探讨，因为这与气候变化等的人类世问题关系非常密切。把这篇可持续软件测试：为更绿色和更高效的未来制定 5 项策略 简单翻译了一下，里面还是有很多中肯的建议的，一些看法其实与效能提升关系密切，毕竟效率提高了，消耗和浪费可能会有所减少。

背景

在技术进步与进步同义的时代，软件开发的生态足迹往往被忽视。

• ShiftProject 的一项研究估计，2018 年信息和通信技术(ICT)行业的碳足迹约占全球温室气体排放的 2-3%。
• 彭博社预测，到 2030 年，IT 系统将占全球能源需求的惊人 20%。从这个角度来看，交通运输业目前占全球能源消耗的 25%。
• 根据国际能源署(IEA)的数据，2018 年数据中心在全球消耗了约 200 太瓦时(TWh)的电力。

绿色软件开发的出现宛如灯塔，提供了一种转向生态友好实践的范式转变，与全球对可持续发展的迫切呼吁一致。这种方法不仅仅是一个流行语，它呼吁在软件生命周期中致力于资源效率、减少能源消耗和全面考虑环境。

通过优化软件测试流程中的资源利用和能源需求，组织可以降低整体测试成本。对于大型测试项目来说，这可以节省大量的资金。此外，测试过程变得更加高效和流线化，从而实现更快的交付周期和更短的上市时间。

目标很简单：优化测试策略和自动化实践，以节省资源，从而节省能源。

以下是 5 项策略，可立即在您的组织中启动“绿色 QA”。

1. 使所有测试执行“上下文相关”

• 仅执行与代码更改相关的测试。避免盲目执行；不要在每个环境上运行每个测试。避免大批量的测试执行。这将减少资源消耗并最大限度地减少能源使用。
• 避免像晚上、一天多次等计划执行。这些执行会消耗太多资源，如果自上次执行以来部署的代码没有变化，则可能不会提供任何价值。
• 将测试隔离，确保每个测试套件或测试用例在不影响其他测试套件或测试用例的情况下独立运行。这可以防止资源争用并提高并行执行的整体效率。减少测试间依赖，以便更容易地在不等待其他测试完成的情况下并发执行测试。
• 利用云平台进行测试执行，因为它们可以根据需要动态分配资源。这可以为能源效率做出重大贡献。
• 重新设计 CI 和 CD pipeline，以在各种“测试”阶段结合上述原则。

可以通过转向 Trunk-based 开发和使用注释在代码中标记测试并将其作为参数传递给 CI/CD pipeline 来实现。

2. 实施节能的测试自动化 (编码) 实践

测试执行能耗 = 活动代码能耗 + 等待代码能耗 + 空闲代码能耗

• 将测试自动化框架和脚本容器化。容器提供了一个轻量级且孤立的环境，使其易于水平扩展。它们还减少了每次代码下载和构建过程生成的网络流量。
• 最小化文件 I/O 操作，尤其是在循环或频繁文件访问场景中。使用缓冲 I/O 操作来减少磁盘访问次数。例如：从文件中读取测试数据或从文件中读取配置或将结果推送到测试管理工具。
• 学习编写优化的代码，包括死代码消除、循环优化、公共子表达式消除等。此外，分析不同算法的性能特征并为您的特定用例选择最合适的算法。
• 保持测试工具和库是最新的，以受益于任何性能改进。
• 在代码中及时释放资源，尤其是在资源受限的环境中，如移动设备或物联网设备测试。
• 最小化后台进程、任务和线程，这些进程、任务和线程可能会提高 CPU 和内存利用率，从而增加功耗。
• 调整日志记录和报告的详细程度，以避免不必要的资源消耗。

可以通过在自动化指南文档中记录所有上述内容、与质量工程师沟通并在代码审查过程中将它们作为检查领域来实现。

playwright 是微软推出的一款自动化测试工具，据说开发小组的核心人员来自 google 的 puppeteer 团队，真是一出生就有了个好爹而且好爹的亲爹也是爹中的战斗机，这就让人非常期待了。

下载与安装

playwright 应该是使用 JavaScript 进行开发的，不过考虑到大部分的测试同学可能对 python 更为熟悉，这里的安装就以 python 版本为例。

在命令行中输入pip install pytest-playwright，等 playwright 安装成功之后再输入命令playwright install，这条命令的作用是安装测试所需要的各种浏览器支持，相比较 selenium 需要先安装浏览器再安装相应版本的 driver，playwright 的初始化工作就显得轻松了很多。

第一个用例

接下来按照官方文档里的例子我们来跑第一个 playwright 用例。

新建一个名为 test_my_app.py 的文件，然后把文档中的例子一字不差的进行拷贝粘贴。

import re
from playwright.sync_api import Page, expect

def test_homepage_has_Playwright_in_title_and_get_started_link_linking_to_the_intro_page(page: Page):
    page.goto("https://playwright.dev/")

    # Expect a title "to contain" a substring.
    expect(page).to_have_title(re.compile("Playwright"))

    # create a locator
    get_started = page.locator("text=Get Started")

    # Expect an attribute "to be strictly equal" to the value.
    expect(get_started).to_have_attribute("href", "/docs/intro")

    # Click the get started link.
    get_started.click()

    # Expects the URL to contain intro.
    expect(page).to_have_url(re.compile(".*intro"))

然后在命令行里输入 pytest，视网速而定，等待个 10 秒钟左右，就可以看运行结果了。

一般情况下我是不喜欢追热点蹭热度的，不过这两天公安机关警情通报之后，吴亦凡事件发生了各种逆转，这起全员恶人事件非常凑巧的契合了安全测试中的一个概念：也就是中间人攻击。我们在吃瓜之余可以简单了解一下中间人攻击的一些原理，通过例子去学习，印象自然会深刻一些。

什么是中间人攻击？

下面的定义来自维基百科。

中间人攻击（英语：Man-in-the-middle attack，缩写：MITM）在密码学和计算机安全领域中是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。在许多情况下这是很简单的（例如，在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者，可以将自己作为一个中间人插入这个网络）。

一个中间人攻击能成功的前提条件是攻击者能将自己伪装成每一个参与会话的终端，并且不被其他终端识破。中间人攻击是一个（缺乏）相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信任的数字证书认证机构颁发，并且能执行双向身份认证。

举个例子

下面的内容依然来自维基百科。

假设爱丽丝（Alice）希望与鲍伯（Bob）通信。同时，马洛里（Mallory）希望拦截窃会话以进行窃听并可能在某些时候传送给鲍伯一个虚假的消息。

首先，爱丽丝会向鲍伯索取他的公钥。如果 Bob 将他的公钥发送给 Alice，并且此时马洛里能够拦截到这个公钥，就可以实施中间人攻击。马洛里发送给爱丽丝一个伪造的消息，声称自己是鲍伯，并且附上了马洛里自己的公钥（而不是鲍伯的）。

爱丽丝收到公钥后相信这个公钥是鲍伯的，于是爱丽丝将她的消息用马洛里的公钥（爱丽丝以为是鲍伯的）加密，并将加密后的消息回给鲍伯。马洛里再次截获爱丽丝回给鲍伯的消息，并使用马洛里自己的私钥对消息进行解密，如果马洛里愿意，她也可以对消息进行修改，然后马洛里使用鲍伯原先发给爱丽丝的公钥对消息再次加密。当鲍伯收到新加密后的消息时，他会相信这是从爱丽丝那里发来的消息。

具体展开如下：

1.爱丽丝发送给鲍伯一条消息，却被马洛里截获：

爱丽丝“嗨，鲍伯，我是爱丽丝。给我你的公钥” –>  马洛里   鲍伯

2.马洛里将这条截获的消息转送给鲍伯；此时鲍伯并无法分辨这条消息是否从真的爱丽丝那里发来的：

爱丽丝   马洛里“嗨，鲍伯，我是爱丽丝。给我你的公钥” –>  鲍伯

3.鲍伯回应爱丽丝的消息，并附上了他的公钥：

爱丽丝   马洛里<– [鲍伯的公钥]–  鲍伯

Selenium 4.11.0 正式发布了，先来看一下主要特性。

• Chrome DevTools 支持的版本现在是：v113、v114 和 v115（Firefox 仍然对所有版本使用 v85）
• 通过 Selenium Manager 支持 Chrome For Testing（CfT）
• Selenium Manager 现在可以在 PATH 或配置的路径上定位 driver 的二进制文件，检查潜在的不兼容性，并提供更好的警告和错误信息。
• 每晚都会推送 Ruby 和 Java 的构建版本。对其他语言的支持即将推出。
• 在查找窗口句柄时忽略进程 ID 匹配 - Edge 上的 IE 模式。

这里最重要的更新是支持了 Chrome For Testing.

Chrome For Testing

这是 chrome 推出的专门针对测试场景使用的浏览器，为了解决下面一些痛点

• chrome 的自动化更新。自动更新：对用户来说很方便，对开发者来说很痛苦，特别是测试同学，应为我们希望(a)在重复的测试运行中获得一致且可重复的结果，但如果浏览器可执行文件或二进制文件在两次运行之间决定自行更新，这会毁了一切。(b)我们想要固定一个特定的浏览器版本，并将该版本号添加到你的源代码仓库中，这样你就可以检出旧的提交和分支，并重新运行测试，以便使用那个时间点的浏览器二进制文件进行测试。基于上面两个原因，自动更新让人欲除之而后快。

• 下载不到特定版本的 chrome 浏览器。除了自动更新之外，你可能也发现很难找到特定版本的 Chrome 二进制文件。谷歌故意不提供带有版本号的 Chrome 下载，因为用户不应该关心版本号，他们应该尽快更新到最新版本。这对用户来说很好，但对于需要在旧版本的 Chrome 中重现错误报告的开发人员来说很痛苦。这个问题的一个更具体的例子是当你想要使用 ChromeDriver 进行浏览器自动化时。你不仅需要以某种方式下载 Chrome 二进制文件，还需要一个相应版本的 ChromeDriver 二进制文件，以确保这两个二进制文件是兼容的。

在这样的背景下，chrome for testing 应运而生。官方的说法是

为了解决这些问题，Chrome for Testing 是 Chrome 的一个专用版本，针对测试用例进行了优化，不会自动更新，与 Chrome 发布流程集成，每个 Chrome 版本都可用。这个版本的二进制文件尽可能接近常规的 Chrome，同时不会对测试用例产生负面影响。