本文做为新人文档主要是说明，如何通过接口快速的了解哪些看不到的边边角角是我们要去熟悉且重点关注的。通过另外一条途径认识业务。

一切从创建订单开始

{
  "money": 129,
  "note": "备注测试",
  "productInfo": [
    {
      "isPrimary": 1,
      "productPrice": 30,
      "peopleNum": 2,
      "skuInfo": {
        "services": [
          {
            "id": 1,
            "price": "99.00"
          }
        ]
      }
    }
  ],
  "realMoney": 129,
  "storeId": 1,
  "type": "person_order",
  "userInfo":{
    "id":1
  }
}

以上是一个常规型的订单创建入参。不管是通过抓包还是直接通过接口文档，此时你应该都能拿到类似以上的数据。那么怎么去分析这串数据让我们明白要去熟悉业务的信息呢？

1. 明白数据的意义

我们大致的将数据分类一下会得到以下类似信息

当我们简单分类一下，我们就应该明白哪些数据是我们需要重点去了解的。这里大家可能想知道你是怎么给这个数据分类的。其实很简单注解型的数据一般只校验长度，他是拿来显示的不会进行数据的计算。其他数据类型不是需要计算得出就是需要作为关联数据参与计算。那么该数据的属性一定会影响这个计算的过程，所以分类就是这么得出的。
通过经验可以给出一个简单的例子。money 字段明显是需要计算价格是否正确的，所以肯定要知道产品的定价，产品的优惠等等。但是这篇文章想让大家了解的不仅仅是这些。让我们接着看。

2. 转化一下观察角度

当我们拿到有意义的数据信息之后我们做一下下列操作以 money 和 userId 为例子

让我们再转化一下形态

从上图你可以看到这个 order 衍生出来的模型。那么上图标记的 1、2、3、4、5 各个链路的任何参数代入到业务中或者说是一种功能，这些功能一定会影响到这个 order 的链路。细心的同学会发现上述还有几个?号的标记，因不管是 userinfo 还是 money，在这里千万千万不要认为他只是一个参数，当我们拿这些数据去分析时应该认为他是一个模型，是一种功能。所以此时你应该用你的经验和抛弃固有的认知，去了解这个项目这个业务他使用的模型是怎么样的。所以我猜测了一下各种模型可能存在的属性，当然根据这个思路去寻找对应的文档这才是正解。比如 user 模型有哪些属性 (用户注销，用户未登录，用户黑名单) 等等支持你拿到这些数据的文档。

通过延伸有意义数据的干扰项，通常这在接口文档和接口评审时都会出具。大家可以使用接口的入参，分析各个参数的数据意义，展开各个数据属性。这样在创建订单这个业务层你就能明白你需要知道哪些内容来帮助我们快速了解业务了。

关于订单之后和其他接口也可以展开重复上面的步骤即可。

同样的当我们知道哪些是关联项的时候我们还能利用错误猜测法，去构建缺参的场景，去构建数据损伤的场景等等场景去破坏数据的合理性，来达到错误猜测异常测试的目的。至于其他测试分析方法可以用类似的思路切入。对于不同层次的测试，接口，E2E，安全，性能都可以用这种方法去切入分析各个参数代表的链路。

最后这个过程结束之后你就应该知道我们需要沉淀哪些文档，这个过程需要出具什么文档来帮助我们快速的了解业务和分析业务。

总结

这篇文章的初衷是发现当业务体量很大的时候，产品文档和流程文档要么断层要么冗余。测试伙伴刚刚入职或者迁移到一个新的项目组，很难快速的分辨这个项目的重点和可能存在的细枝末节，以及以"保障测试主流程为己任的心态"去做测试，这是千万要避免的。我们应该跳出原先点点点的限制。通过这种方式我们能更加全面且站在更高维度去判断业务范围和边界。