当今接口测试越来越重要，一般情况下我们总是会对接口的返回的 json 字符串进行验证，看返回是否跟我们的预期相符。不过很多情况下我们会遇到下面的问题

• 响应结果在测试中不停的发生变动，比如昨天还是 3 个字段，今天可能返回值里只有 2 个字段了，测试这边没有比较好的方式感受到后端的变化
• 我们需要对 json 的返回值进行一些校验，需要写很多的断言，大部分时候这些断言都是相似的，或者是重复的，比如说校验某个字段的长度必须小于 10 之类的

那如何解决呢？

• 与前后端沟通好返回值的字段，类型以及校验规则，最好有前后端+测试端统一一份合约，大家都按照合约来进行数据的处理
• 测试的时候通过合约里定义好的校验规则进行数据校验

这时候 json schema 就派上用场了。

json schema

JSON Schema 是一种 JSON 媒体类型，用于定义 JSON 数据的结构。 JSON 模式旨在定义 JSON 数据的验证，可用于验证响应和请求 JSON。 在 JSON Schema 中，我们可以验证数据类型、字段是否为必填、最小长度或最大长度等。

举例

下面的数据代表了一个员工的信息

• id: employeeId
• 员工名称: employeeName
• 年龄: employeeAge
• 职称: jobTitle
• 爱好: hobby

{
  "employeeId": 1,
  "employeeName": "Fulan",
  "employeeAge": 23,
  "jobTitle": "SDET",
  "hobby": [
    "watch movies",
    "play football"
  ]
}

上面的定义其实是有一些疑问的，比如

• id 是什么意思
• employeeName 的最大长度是多少
• employeeAge 的最小值是什么
• jobTitle 是必填吗
• hobby 可以填几个

我们可以通过生成 JSON schema 来回答上面的问题

测试计划在国内其实不是很流行。之前在外企工作的时候，每一次的测试工作基本上都是以编写测试计划开始的。好的测试计划可以让团队成员对测试整体进行和测试策略以及方法有一个大体的认识，在一定程度上可以节约沟通成本。最近正好在 github 上看到一份测试计划文档，我们就一起来学习一下其中的精华吧。项目地址：https://github.com/fityanos/awesome-quality-assurance-roadmap#test-plan-sample

1 介绍

1.1 项目介绍

介绍项目上下文

1.2 读者

描述一下读者人群，比如来自 A 团队的 alice 以及来自 B 团队的 bob

2 测试策略

2.1 测试目标

比如完整的回归测试，还是增量的功能验证等；

2.2 测试假定

假设某些东西不需要考虑或者满足某些条件，比如测试环境上可能没有配置负载均衡，这时就可以假定大家都理解这个点，并可以进行适当的忽略

2.3 测试原则

比如所有 bug 必须 fix 之类的原则性的东西

2.4 测试范围和级别

这里可以定义测试的范围，该做的就做，不该做的就先约定清楚。比如可以定义

• 功能测试范围和时间以及交付物
• 性能测试范围和时间以及交付物
• 回归测试范围和时间以及交付物
• UAT 测试的范围和时间以及交付物

2.5 LOE(level of effort)

这里就是工作量的分解了，越清晰越好。

3 执行策略

3.1 开始和退出条件

比如功能测试的开始条件是产品体验通过和开发自测通过，结束的条件是所有的 bug 都被 fix

3.2 测试轮次

• 第一轮
• 第二轮
• ……

对于敏捷测试团队来说，其实可以忽略测试轮次的概念。对于瀑布流开发团队来说则需要定义清楚，因为每一轮的时间都很宝贵。

今天在 github 上看到一份测试同学的成长之路图谱，不敢独享，在这里给大家汇报一下。

基本概念

首先明确几个基本概念

• STLT: Software Testing Life Cycle 软件测试生命周期
• SDLC:Software Develop Life Cycle 软件开发生命周期
• TDD: Test Driven Development 测试驱动开发
• RPA: Robotic Process Automation 过程自动化

必须掌握的基础能力

测试策略

• 白盒测试
• 灰盒测试
• 黑盒测试

测试类型

• 功能测试
  • 单元测试
  • 冒烟测试
  • 集成测试
  • 回归测试
  • 健全性测试(sanity testing)
  • 用户接受性测试(uat)
• 非功能性测试
  • 负载测试
  • 压力测试
  • 安全测试
  • 性能测试

上面的负载，压力以及性能测试在国内其实不怎么分，可以统一看作是性能测试，只不过测试策略不同而已。

STLC 管理工具

• qTest
• TestLink（常用）
• Zephyr
• Testrail

项目管理工具

• Jira(常用)
• Youtrack
• Trello
• Assembla

软件研发模型

• V 模型
• 敏捷模型：迭代式，较为常用
• 瀑布模型

深度手工测试技能

手工测试目前看来还是软件测试工程师的核心能力，优秀的手工测试能力可以让你的职业生涯发展更加平滑。

原文地址: https://www.stickyminds.com/article/exploratory-testing-why-it-not-ideal-agile-projects

下面是 gpt4 的总结。

探索性测试是一种灵活的测试方法，它不需要预先定义测试用例，而是让测试人员根据自己的判断和发现来设计和执行测试。探索性测试有以下优点：

• 它可以适应需求不明确或变化频繁的场景，提供及时的反馈和建议。
• 它可以发挥测试人员的创造力和直觉，发现一些预期之外的缺陷或风险。
• 它可以节省测试文档的编写和维护的时间和成本，提高测试效率。

然而，在敏捷软件开发中，探索性测试并不是最佳选择。原因有以下几点：

• 探索性测试缺乏可追溯性和可重复性，难以评估测试覆盖率和质量。它也不利于与其他团队成员或利益相关者分享测试结果和经验。
• 探索性测试依赖于测试人员的经验和技能，可能导致测试结果不一致或遗漏重要的缺陷。它也不利于培养新手测试人员或提高团队的测试能力。
• 探索性测试不利于自动化和持续集成，无法实现敏捷开发的快速反馈和交付。它也不利于与开发人员协作，实现测试驱动开发或行为驱动开发等敏捷实践。

因此，作者建议在敏捷项目中使用结构化的测试方法，结合需求分析、测试设计、测试执行和测试评估等步骤，提高测试效率和质量。

同时，也可以在适当的时机进行探索性测试，以补充结构化测试的不足。例如，在需求分析阶段，可以使用探索性测试来理解用户需求和业务流程；在回归测试阶段，可以使用探索性测试来检查系统的稳定性和完整性；在发布前阶段，可以使用探索性测试来模拟用户场景和操作。

有没有人从 QA 转到开发？

前几天在国外论坛上看到个帖子: 有没有人从 QA 转到开发？提问者表示:

我和我的经理谈了谈职业发展，这是我得到的其中一个选择。尝试转为开发人员工作。

在寻找新的 QA 工作时，外面没有那么多 QA 工作，相比之下，开发工作就很多了。

因此，这让我想，由于有更多的机会，是否应该从 QA 转为开发？

个人认为如果有能力转的话还是转一下比较好，毕竟开发的机会更多一点，而且天花板相对也比较高，不过高赞回答提供了另一种视角，我觉得也很有道理。

下面是高赞回答的内容。

我是一名软件测试开发工程师（SDET），拥有计算机科学学位，对高级编程原理有扎实的理解。在我的整个职业生涯（5 年以上）中，我一直在考虑转行。以下是我要说的话：

是的，对开发人员的需求更高，但该行业的开发人员数量也比 SDET 数量多得多。成为最优秀的 SDET 候选人比成为最优秀的开发人员候选人更容易（竞争更弱）。

开发(SWE) 通常薪酬更高，因为他们是构建产品的必需品。他们是新项目的第一个被雇佣的人，也是最后一个被解雇的人。如果没有开发人员，就没有必要有 QA。然而，在许多情况下，SDET 的薪水几乎和他们一样高。我自己在低收入地区: 蒙特利尔，加拿大，我可以赚到超过 150,000 美元的年薪。

这也意味着开发人员通常被视为更重要。很多人看不起 QA，尽管 SDET 经常对编程原理有同样好的理解，我们只是不经常使用它，因为我们遇到的编码问题没有那么难。

做开发人员的坏处是您可能需要工作更多，并承受更大的压力。作为开发人员，您必须遵守严格的交付时间表，同时还必须始终处于新技术和工具栈的最前沿。在工作与生活平衡（WLB）与薪酬方面，我 100%认为 SDET 更胜一筹。我比开发人员工作少 50%，但收入却是他们的 90-100%。这实际上可以让我接一些兼职合同并将我的收入翻倍。

归根结底，这取决于您更优先考虑什么。您是否想留在编码世界并晋升为首席开发人员？还是想拥有更好的工作生活平衡、获得更多产品知识并过渡到 PO/PM 角色？这完全取决于你。

简单来说高赞回答觉得测试开发比开发更好，因为竞争小，收入高，也不需要经常更新技术栈，不过这也意味着市场需求不旺盛，坑比较少，总之是有利有弊吧。

不知道大家对这个问题有什么样的看法，欢迎留言讨论。

最近在搜广推项目里做了一些小小的基于数据驱动的测试尝试。

因为项目的特殊性，大部分的测试场景其实相对类似，大体可以分为下面几步

• 收集数据，整合成 1 个类似宽表的东西。比如在美团上给外卖投放一个关键字广告，那么投放之前需要收集这个商家的门店信息，比如门店名，经纬度；菜品信息，这个商家有哪些菜品，名字分别是什么；品牌信息，这个商家属于哪个品牌，品牌有哪些特殊属性；这些信息其实都分别在不同的业务表里，开发那边有离线数据流去打宽表，但是对于测试来说，如果不使用自动化的方式的话则需要用 sql 去查询，遇到有分表的情况则比较麻烦；
• 构造数据。还是外卖投关键字广告的例子，因为召回的规则和其他一些业务规则，我们投的关键字最好有相关性，比如商家的店名叫做“永久炸鸡”，那么投“炸鸡”这个关键字可能会比较好。所以通过上一步构造好的数据，从里面自动筛选出一些相关数据并进行构造也是必要的；
• 执行业务并进行断言。以搜索为例，收集数据阶段我们收集了很多的门店信息和菜品信息，那么使用门店名和菜品名进行搜索的话是需要有结果出来的，由于排序规则是算法团队去实现和测试的，所以我这边只需要数据可以搜出来就好，至于排序是什么样子，测试用例里面是不需要去关注的。

综合考虑了一下，我有一个大胆的想法。

上面这些步骤是不是都可以完全由自动化来实现？

使用爬虫进行数据收集

测试环境和体验环境我是有数据库权限的，所以可以通过 sql 来进行数据查询，逻辑其实很简单，从现有的数据里查一些拥有有效菜品的有效商家就好了，所以问题就简化成了使用脚本去连接数据库，然后进行一系列的连表查询就好了。不过因为菜品进行了分表，所以需要一些额外的逻辑去处理一下，不过总的来说还是不难的。

一切都很顺利，直到业务上线了以后，我发现我需要在线上去收集这些数据。因为安全策略的缘故，开发和测试都是没有线上数据库的访问权限的，因此我在非生产环境里通用的自动化脚本就成了一堆废纸。

后来有一天，我发现项目的本地测试人员都是在业务后台的各个功能模块里做数据的查询和准备，我突然有了使用爬虫去爬取数据的想法。

原理其实很简单，模拟业务后台的请求，通过后端暴露的 api 进行查询，最后想办法把数据组织好存储下来就行了。

后来用代码简单的实现了一下，效果其实还是不错的，而且完全不需要去顾虑分库分表问题，因为管理后台的 api 把这些都实现好了。这也让我开阔了一些思路，其实爬虫除了爬外部数据之外，还可以爬内部其他团队的数据，只要业务有管理后台，一切都好说。

使用 redis 进行数据存储

爬虫拉到数据之后，就需要对数据进行一些处理和存储。得益于业务 api 的杰出工作，之前查 sql 时候需要进行的数据处理现在就变得特别简单，因为业务逻辑都帮我都处理好了，下一步只需要把数据保存起来就好了。

因为数据需要反复使用和在多个场景下使用，所以存储对于我来说是必须的，但对于另一些场景，存储中间数据可能不是必选项。

因为对 redis 相对比较熟悉，所以我这里用 redis 实现了一些类似索引的东西。

• 用 set 去存储一些实体的主键，比如门店 id 和菜品 id 之类；
• 用 string 去存储详细信息，比如门店名，菜品的详细信息等；其中门店菜品之类的就直接用的 python dict 序列化成 json string，查询时候通过门店的 id 就可以直接拿到 json string，然后重新反序列化成 python 字典就好了

使用后端 api 进行数据创建

对于搜索来说组装好数据基本就可以测了，不过对于广告来说还需要进行广告的创建。这里我是直接调用 api 做创建，效率高而且不用去页面点。

使用 pytest 进行自动化测试

最后就是用例编写了，这里我直接用 pytest 实现了一些用例，贴一个具体例子。