可以参考 httprunner 的思路，将测试数据，接口数据抽离出来，相同业务流程的在一个 testcase 中，动态创建多个 test 方法来执行接口

个人感觉在面试场景下如果没有特殊说明, 能实现就好了,从测试角度来说能写出来就好了,大部分公司算法只是加分项不是必需项, 那些要求很高的会要求你实现并写出单元测试,那就可以写的更健壮一点, 当然如果纯站在讨论解题上,还是需要考虑很多情况的

def searchNum(array):
    length = len(array)
    left_first = 0
    right_first = 0
    left_last = length - 1
    right_last = length - 1
    left = None
    right = None
    while(1):
        # left
        left_mid = (left_last + left_first)//2
        if array[left_mid]<0 and array[left_mid+1] == 0:
            left = array[left_mid]
        if array[left_mid] >= 0:
            left_last = left_mid
        if array[left_mid] < 0:
            left_first = left_mid

        # right
        right_mid = (right_last + right_first)//2
        if array[right_mid] > 0 and array[right_mid-1] == 0:
            right = array[right_mid]
        if array[right_mid] <=0:
            right_first = right_mid
        if array[right_mid] > 0:
            right_last = right_mid

        if left and right:
            return left, right

现在动不动的框架就是一门开发语言 + 相关单元测试框架 +excel+ 报告输出 + 关键字驱动数据驱动, 简直了

我觉得接口测试的校验应该是对接口返回值的校验,以查询类商品为例,我查询篮球, 校验返回数据量, 返回数据中商品 type 等来验证这个接口是否正常,而不是去数据库用 sql 拿数据再做全量对比, 如果这样做的话我感觉可以归类为单元测试了,对开发写的 sql,逻辑处理函数进行测试。
而对于一些 post 类操作, 比如下订单, 我们可以通过接口串联来判断接口是否正常, 例如下单接口 ok 把订单 id 拿到,调用订单详情接口,再看订单详情页接口是否正常这样将业务串联起来。
另外, 也主要看你要把接口测试应用到什么阶段, 如果是回归测试阶段, 我觉得应该以提高测试覆盖率,提高回归测试效率为主,而不是细致到数据的全量对比, 如果是开发前期接口测试介入, 那可以做的细致一点
一点想法, 仅供参考