引言
之前分享过一篇关于使用unittest框架做接口自动化测试的文章——基于Python接口自动化测试框架+数据与代码分离(进阶篇)，该篇文章主要讲设计思路与简单实践的过程。但是，小编力求实战，恰巧遇到项目所需。俗话：光说不练假把式，很多人写博客，弄几个小示例后，就感觉自己学会了一套框架，甚至觉得自己是测开了。其实不然，实践使用过程，你会发现很多问题，特别是公司的花式接口和复杂业务逻辑的，你会发现往日搭建的框架很多残缺，无法完全应用所有场景。这个时候，你需要去在实践中不断优化与完善，这也是非常难得的，必须这个过程你在不断探索与学习，进而提升自己的能力。
Unittest跳过测试
在版本初期，绝大多数项目接口开发完成后，测试就可以做接口测试了。而项目后期，维护好的接口测试用例及脚本可以用于回归测试，以便腾出时间用于手工测试及测试用例测试场景的设计。鉴于之前设计模式DDT，都是全量执行测试用例，如果想执行一部分测试用例的话，怎么办？基于unittest框架的跳过测试使用方法：
一般情况下，unittest 会自动测试每一个测试用例（以test_开头的方法），但是如果想临时跳过某一个测试用例，有两种实现方法：
方法一：使用 skipXxx 装饰器来跳过测试用例，unittest 一共提供了 3 个装饰器：
@unittest.skip(reason) ----- 代表无条件跳过；
@unittest.skiplf(condition, reason) ----- 代表当 condition 为 True 时跳过；
@unittest.skipUnless(condition, reason) ------ 代表当 condition 为 False 时跳过。
方法二：使用 TestCase 的 skipTest() 方法来跳过测试用例
案例演示：
import unittest
class TestHello(unittest.TestCase):
# 测试 say_hello() 函数
def test_001(self):
self.assertEqual(1+2,3)
print("test_001:执行了")
# 测试 add() 函数
@unittest.skip('临时跳过 test_002')
def test_002(self):
self.assertEqual((3+4), 7)
self.assertEqual((0+4), 4)
self.assertEqual((-3+0), -3)
print("test_002:执行了")
def test_003(self):
self.skipTest("临时跳过 test_003")
print("test_003:执行了")
if __name__ == '__main__':
unittest.main()
结果如下：
DDT跳过测试
上面是unittest的跳过测试，而ddt本身使用的也是unittest框架，也是可以用这种方式来实现。但是，我这里不介绍了。我使用另一种方法。我们的测试数据都存于excel文件中，前面实现了读取和写入操作，既然这样，可以设置一个开关，用来读取我们想要执行的测试用例。
实例：
我们在数据驱动模板中增加一个字段：run，用于控制用例执行。
然后在我们核心运行程序中，加逻辑判断：
测试结果与日志优化
我们将结果统计出来，便于我们调式的时候，可以追踪到哪些成功和失败，并且失败原因是什么。
运行结果：
打印日志：
在看看所有用例是否执行了？
总共维护了134-1，然后所有用例执行开关是打开的，所以运行日志显示总数是133，执行了133，成功132，失败1个。由于详细日志数据涉及到保密协议，我这里不便贴图，请谅解。
动态图：
测试报告
报告和打印的测试结果数据都是一致的，证明是没问题。
疑难问题处理
上面基本上是显示上优化的，那么对于一些接口，你封装好的是result['message']这种字段，但是你测试的接口，并不是所有接口返回的json字符串里面有message字段，如果公司每个开发都有自己的风格，没有统一的话，那这样就是给测试带来一定的困扰，比如我遇到的接口，返回的是result['msg']，而有些的是result['message']。而你写好的断言方式是 assertEqual，并且是使用其中一个，但是大量接口，有些没有这个字段，你这样写，定会报错。所以你的改代码逻辑。最简单的方式，直接使用条件判断，分流处理：
接口一的返回数据：
接口二的返回数据：
再举个例子，比如我们写好的代码获取的是接口序列化数据——json字符串，但是有些接口返回的并不是json格式，有可能是其他格式，甚至在实际项目中，我遇到的接口，返回的数据就是一个动态值或常量值。这个时候你取数据的方式是:res.json()。必然是报错的。而且对于变量值，你无法断言，因为预期结果你都不知道是什么，它是变化的。但是也不是没有规律的，至于规律，也就是生成的逻辑，这个需要与开发沟通后，你知道了，然后再去写这逻辑，最后去断言。单单这种接口，做起来就没有那么简单了。所以平时做接口测试，多思考。
总结
以上是自动化测试框架用于实际项目中的问题，这些问题可能你从不曾遇到过，也可能遇到过但从不曾思考过，当然，如果你有更好的方式处理这些问题，可以加入测试开发交流QQ群来沟通与学习：696400122。本群以学习交流为主，所有干货以实际项目中实战案例为背景，深入学习与分享。