问答 服务端测试用例设计，是从需求书开始设计用例，还是等待接口文档出来后，编写用例？
在做服务端接口测试用例设计的时候，我目前做法，是根据需求书，梳理功能点，然后等待接口文档出来后，根据接口文档的每个字段，写出每个字段对应的等价类、边界值、错误推测的划分，然后设计测试数据去覆盖每种场景，并补充其他的功能场景以及各种返回结果的场景用例。
最近在考虑，是否应该在需求书出来后，就开始设计用例，当接口文档出来后，再去补充测试用例？
大家是怎么做的呢？
有两种情况：
1、非常熟悉业务对应接口，对于接口数据源也非常了解（经常负责的对应业务接口，理论上应该是完全能够掌握，数据来源了，从上层接口还是数据库进行获取数据，心里有数的）
- 在需求出来后，第一时间就可以和研发一样，结合需求同步进行初步接口分析和用例设计
- 研发接口文档出来后，结合自己的分析情况，进行查缺补漏。研发分析的不代表是全的、对的
- 要求前、后端开发对接口文档达成一致后，完善用例
2、能进行接口测试，没办法自行分析接口伪开发需求，比如现有接口是否能满足？新的需求用到的数据，需要从哪里获取之类的
- 梳理业务点
- 研发接口文档出来后，结合业务点，确认接口是否满足
- 编写接口测试用例
谢谢，很棒的见解，我打算试试第一种情况
你的问题我理解不是什么时间点开始写测试用例的问题， 本质上是如何系统化编写测试用例或者测试分析的问题；
其中你说的接口出没出来，只是一个测试分析当中一个比较重要环节而已，从整体来看的时候其重要性可能不是最大的；
给你举一个系统化设计测试用例/测试分析的工具：
- 概述 需求/背景
- 需求分析 + 测试用例分析 2.1 功能点梳理/功能点测试分析 2.2 系统架构梳理/架构维度用例分析 2.3 接口分析/接口测试用例分析 2.4 页面分析 2.5 数据库分析 2.6 异步任务分析 2.7 中间件分析 2.8 关联影响分析
- 白盒测试分析 业务逻辑 静态代码
- 异常测试分析 业务异常/系统异常/三方异常
- 兼容/安全/性能等～～～～
如需要详细的可以私聊我
