单元测试的重要性不再赘述。
但是，让所有管理者头疼的是，很多开发人员意识不到单元测试的好处，经常应付了事。
如果将单元测试的粒度放到方法级别，就会产生非常多的测试方法，而管理者也绝对没有时间与精力去核对。
那么，怎么才能去促进这个单元测试的进展呢？
如果经常说教，很容易让团队成员产生逆反心理。
所以要启发式引导，用结果导向的方式，来驱动大家关注这个事情。
但是要明确一点，单元测试的目的是什么？
是为了提升开发人员的开发质量，而不是为了机械式的让所有的方法都进行测试。
所以，对于管理人员来说，关注的单元测试级别应该更高一点，起码到API级，或者说一些重点功能领域的API接口。
那么，单元测试的审查、抽调，到底检查什么内容？
仅仅是测试方法全部覆盖吗？
查询类接口该怎么写接口测试？
交易类接口该怎么写接口测试？
1
交易类接口测试要点
技术类
包含必输校验、长度校验、数据字典校验、边界值校验、规则校验（手机号字段必须都是数字）等内容。
如果系统框架，已经集成了 hibernate-validator 等外部化校验框架，一般不用过多关注。
但是，对有业务关键影响的字段，要进行测试。
另外，在系统框架对参数进行校验的时候，一般的参数校验，都是遇到第一个参数校验失败就返回，需要找出策略防止”快速失败“引起的测试用例繁多的问题。
功能类
接口功能正常执行通过，并且针对业务级别的功能测试也通过。
例如，金额字段的精度、账务、明细、回单等多系统联动处理。
不仅仅是技术联通，更要查看业务正确。
补偿类
在正向处理业务流程无法自恢复的情况下，进行补偿的功能，需要进行测试。
尤其要关注对于业务补偿的业务正确性，对于其它数据的影响。
健壮性测试
例如一些事务性，多接口组合调用等等，自恢复能力；以及对于一些异常场景处理的系统承受能力。
例如，一些消费方传输大量异常数据的承载等。
当然这一块主要是架构框架的内容。
其它
上面是一些通用的测试要点，也是技术管理者进行抽查时候关注的要点。
但是对于个性化领域的功能，需要针对领域特点来进行设计测试类型。
2
查询类接口测试要点
而查询类接口的测试要点前面技术类、功能类测试与交易类接口一致。
但是需要针对查询接口进行考量的是
正确性
查询回来的结果是否正确，不仅仅是数据量，还有每个字段的正确性。
例如，金额字段的精度、金额的单位、币种等内容。
翻页边界
虽然已经有很多的翻页插件，但是复杂一点的有内部逻辑关联处理的，一定要进行测试。
起码有一些数据量0、5、10这种正好翻页边界值的测试。
避免一些技术处理问题，例如如果是两个表关联查询，如果是左关联的查询，有可能右表某个值是空。
但是这个值是时间字段，而应用程序进行了格式转换处理，没有兼容空的话，就会报错。
并且，这些错误都是隐藏错误。
总之，对于技术管理者来说，你并不想也不可能将所有的单元测试用例，尤其是具体到方法级别的单元测试用例进行完全的审核。
但是，作为技术管理者要一直宣传强调自测的文化，上传下效，从而提升开发质量，减少联调时间。
对于单元测试的审查，可以参照上面的技巧，从而达到事倍功半的效果。
记住，不是监督开发人员做没做，而是帮助他思考的更缜密完备。
原文始发于微信公众号（架构突围）：四两拨千斤，技术管理者审查单元测试的技巧
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/170130.html
