没有质量保障的敏捷，跑得越快，死得也就越快。同样的，没有断言的接口自动化测试，写得越多，危险程度也就越高。在追求测试覆盖率的同时，我们也需要关注用例的质量，特别是断言的合理性。
01
一个好的断言设计，可以给我们带来以下好处：
验证接口响应是否符合预期：接口测试的主要目的是验证接口的功能是否符合预期，而断言是验证测试结果是否符合预期的关键步骤。通过断言验证接口返回的数据是否包含预期的字段和值，可以有效地验证接口的功能是否正确。
提高测试效率和准确性：断言可以自动化地验证测试结果，避免了手动验证测试结果的繁琐过程，同时也减少了人为因素对测试结果的影响，提高了测试效率和准确性。
便于问题定位和排查：当测试结果不符合预期时，断言可以帮助测试人员快速定位问题，找到导致测试结果不符合预期的原因，便于排查和修复问题。
02
为什么HTTP状态码替代不了断言
因为HTTP请求本身就是无状态的，HTTP状态码只是表达了当前请求的处理情况，与业务的正确与否无关。例如，400错误，并不是服务有问题，而是你的请求参数有错（比如应该传一个Number类型的参数，你却传了一个字符串）。
同理，HTTP返回200，只能表示这个请求是成功的，但是业务可能是失败的。就好比快速投送，其实也是个无状态事件（不影响下一次的投送），它只是把快递送到你手中了（返回200），但是里面的东西是否是你想要的（业务需要的内容），与快递员无关，需要你自己确认。
03
从接口层面看，我们至少需要验证两点：
数据结构验证：验证接口返回的数据结构是否与事先定义的一样。调用方在处理数据时，肯定是根据事先定义好的数据结构来解析数据的，如果数据结构发生变化，那对调用方来说，是灾难性的（契约测试考虑下）。
核心数值的验证：根据业务场景的不同，可以有目的性地验证某些key的值是否与预期的一样，可以结合数据库查询的方式来验证（不同的自动化测试框架有不同的实现方式）。这个就比较依赖测试人员对业务的了解。根据实际情况灵活地设计验证点。
除了以上两点外，还有一些额外的验证点在需要的时候可以进行，如涉及其他地方的数据流转、返回的URL是否可被访问，返回的数据是否真的是必要的（这点很重要，过多的返回会导致很多意外的问题）等等。根据实际情况进行补充。
这样，通过一系列的方法设计出来的接口用例，才会有一定的业务价值，能够真正地帮助到团队，提升测试效率，对于这样的测试脚本，全部PASS的结果才会让人安心。
04
案例1：如下图所示，针对查询类的接口，返回结果不应该只验证总数（因为总数会经常变，数据总会有增删），而是应该根据查询条件，在返回的列表信息中，针对关键字段做匹配验证。
案例2：查询类接口，给定了查询条件，返回的查询结果为空，理论上应该是要置为失败的（要么替换新的有结果返回的查询数据）。但是因为断言设置得不合理，会导致无法确认是查询结果有问题，还是查询无数据。
案例3：针对提交类的接口，除了验证返回状态外，还需要验证返回数据中的关键信息是否与填写的一致，这样就相当于做了一次数据查询，可以确认业务是否真正正确成功。有些接口如果没有返回新建信息，那就需要手动去数据库中查一次，确保业务的正确性。
案例4：等价的断言设置，如下图，success如果为true，那么通常情况下，code也会为0，不太可能出现不匹配的情况，所以，这里其实只要断言一个就可以了。
05
自动化测试想要真正产生价值，需要我们认真去对待它。让他运行的结果真正地被信任，进而释放测试劳动力。除了断言，接口用例，也需要被精心设计，而不是简单的接口堆砌，这个下次再做分享。
