在 使用 Postman 进行系统可接受性测试 中，我们介绍了使用 Postman 进行持续测试的方法。实际使用中，我们遇到了这样一个问题：

某个请求的请求体（Request Body）异常的大，JSON 格式，80KB+，占整个 Postman 脚本的近 40% ，格式如下：

{
  "roleId": "{{role_id}}",
  "resources": [
    {
      "id": "0",
       "...

在微服务架构盛行的今天，一套系统涉及到的组件数量是非常庞大的，这不仅增大了系统部署的难度，也提出了一个在系统部署完成后如何进行基本的可用性检查这样一个问题。

有人可能会说我们有完善的测试用例，有专门的测试团队，这完全不是问题，那么问题来了：

1. 人工执行的测试用例，通常需要执行人具备一定的专业测试技能及责任心；自动化测试用例则不仅有更高的技能要求，对测试工具及环境也有依赖；
2. 测试团队的资源是有限的，通常申请测试资源时都需要进行排队等待。

可以用检车来类比一下：检车的流程是固定的，检测的项目就好比...

提到测试，所有人都知道它的重要性，但大部分开发人员都会觉得测试应该交给测试人员来做，或者直接到环境上执行一下、点一点看看没有问题就可以了。

究其原因，个人觉得是因为写单元测试的成本太高了，尤其是对外部环境依赖较多的项目，开发环境想运行起来都要依赖特定的组件，就更别提测试用例的运行了。

一个好的测试用例，应该是自动化的、可重复执行的，容易理解、容易运行的，且有明确的断言，以便在代码出现不符合预期的结果时，能够快速发现且定位到问题的。

本文以一些面向 Java 和 Spring 的常见测试场景为例，...

利用 How to integrate SEATA AT mode with Spring Cloud 中定义好的微服务，进行集成测试。

包含以下服务：

1. 库存服务（storage）
2. 用户账户服务（account）
3. 订单服务（order）
4. 业务服务（business）

业务服务作为直接被调用的接口，组织关联其他三个服务。下订单时，服务的调用顺序如下：

1. 减库存（storage）
2. 创建订单
2.1. 扣减用户账户（account）
2.2. 生成订单（order）

服务之间存在依赖关系，...