直接针对提供出去的 API 接口做接口测试不香吗？

我跟 4 楼是一样的观点。

可以

歪楼了，呵呵！
测试用例设计是个系统工程，不能单一看待。测试用例的目的是验证软件行为是否和设计预期相符，即实际结果 (actual result) 是否和期望结果 (expected result) 相符。
表单及旁边标签文字如果是该用例的运行实际结果或结果中的组成部分，就必须对照期望结果进行验证，反之不需要。
用例评审时，一项重要内容就是纠正解决用例验证点不足、验证点错误及验证点多余等问题。

取决于测试用例的设计是否有这样的要求。

8 楼正解

是的，删掉。

优化测试数据后，测试结果也就是搜索结果可以是单页，验证单页结果是能达到验证目的的，不是只验证第一页。

测试用例设计优化，既包含测试步骤优化，又包含测试数据优化。无论是否优化，测试结果验证都是必须的步骤，没有结果验证那不叫测试用例。
搜索结果是单页是能够达到验证目的的。搜索为空，按默认或某列排序，会有个期望的单页搜索结果 listExpected(已排序)，执行测试步骤后会得到单页搜索结果 listActual(已排序)，在用例中直接 Assert.AreEqual(listExpected, listActual, msg) 即可，不用拆开进入 list 并循环对比验证。这么做了就不会有你后面说的逐行逐列验证问题。

1. 将搜索内容为空作为独立用例处理；将验证点击新页面是否重新排序作为独立用例处理。
2. 还是没看明白，但感觉处理得好繁琐，还是那句，照前条说的做，测试场景设计优化后，既能达到验证的目的，又能达到便于验证的目的。
3. 验证必须放用例中，不能使用 if，必须使用 assert，assert 的多种重载中支持 object 参数，可以直接对比两个列表而避免使用循环。举例，Assert.AreEqual(listExpected, listActual, msg);

接口测试的依据，本就该是接口设计文档，而不是需求文档。

请教：随机生成测试数据，怎么验证测试结果呢？流程跑完就算正确吗？

是不是一开始方向就不对，为什么必须得是白盒测试呢，黑盒很好或更好吧。
“这个 json 是基于动态获取某一个接口类下获取的所有方法生成的”——怎么还动态获取，直接参考接口设计文档不行吗？

分别回答你的 3 个问题。

1. 通过良好的用例设计，将搜索结果控制在一页，既能达到验证的目的，又能达到方便验证的目的。
2. 不太明白这个问题，但感觉按前一条说的做了就不存在这个问题了。
3. 验证部分必须放在用例中，不同的搜索条件对应不同的用例。拆分的好处是有利于用例实现和维护。

正解

需要优化场景设计，原则是要利于（自动化）用例的执行。

修正下。
5.返回值测试： 返回值除了类型需要是正确的，还需要内容也是正确的

“测试方法名 + 数字编号”，ddt 生成报告使用这样的命名，这很标准也很规范，测试功能点已经通过测试方法名体现了。
不清楚你为什么有这样的需求，能否详说下。

使用代码自动创建 bug 单，首先很难判断要创建的 bug 是否已经存在，其次你补充的问题也很难解决，再者完整的 bug 单还有别的项都是自动化难以解决的。解决这些问题远没有手工创建更准确、更简便、也更划算。

需要加大产出才能得到更好的投入产出比。故需覆盖尽可能多的流程，而不仅仅是业务主流程和使用频率高的功能点。

不要用代码自动创建 bug 单，要手工创建。

可以做到动态刷新，脚本中插入打印日志语句即可。

谈自动化测试的时候，我们经常会讲到它的优点，其中一个就是降低错误率，发现人工无法发现的缺陷。那么，在这里统计的结果，我们做接口测试真正发现的缺陷是屈指可数，凤毛麟角的。有的甚至一个都没有。

自动化测试目的不在发现缺陷，而在回归。你们没有怎么发现缺陷会不会是迭代版本没怎么对已有功能造成影响，换句话说这也是开发团队能力强的表现？

测试工程师专门负责设计用例，然后交给外包团队来将这些用例再翻译成测试脚本，这样的做法，效率不低下才怪。
首先外包同志不熟悉业务线，直接转化，还是得从了解业务开始。
其次功能测试用例直接翻译成自动化测试脚本存在重复性劳动，同时也会出现场景遗漏，场景不可用的情况。
正确的姿势是：测试工程师自己就将测试脚本交付出来。

这种体现分工思想的做法其实是可以提高效率的。
首先，这种分工，外包团队就不需要熟悉业务线，因为用例测试工程师团队专门负责设计。
其次，这种分工，怎么会存在重复性劳动，同时也会出现场景遗漏，场景不可用的情况？应该是可以避免才对。
正确的姿势，既可以是测试工程师设计用例并实现自动化脚本，又可以是不负责设计用例只实现（翻译）自动化脚本。

但是，现实却是，在版本变更中，真正去执行以前维护的接口测试用例来回归测试的人太少了。据我观察和了解，在短期迭代中，上个迭代维护的用例，这个迭代没人会去跑，哪怕只用一分钟的时间。

自动化脚本的实现和维护都付出了相当大的成本，却没人真正去执行，这不是暴殄天物嘛！你们可以设定自动化测试任务按条件触发或定时自动运行。

其中原因，有些可能是真正的忙，没有时间。有些可能因为懒，不想去维护。总而言之，测试团队中有一部分人是没有去更新接口测试用例的。

之前 “分散的自动化测试” 的时候，大家是不是也因为这些原因不去维护接口测试用例？如果之前大家都很积极主动去维护，那么是不是应该反思：这个自动化测试平台是不是反而降低了大家的工作积极性？