引子
业务测试团队的一项核心工作是保证软件产品可以支撑复杂的现实业务。然而很多时候留给测试的时间很少，能保证业务流程是通的就不错了，没有太多的时间去考虑各种各样的异常情况。但是实际上，很多线上事故都是由一些异常情况引起的。而线上问题的跟踪解决，后续方案的制定及实施等等依然会浪费大量的成本，同时用户的体验也得不到保障。所以如何覆盖异常逐渐变成了一个很值得关注的问题。
异常的分类
我个人给异常非常粗犷得划分为两类：业务引起的异常、技术引起的异常。其定义如下：
-
业务引起的异常：主要指的是一些异常的业务操作引起的异常或者为满足业务需求，新增的功能对原功能产生了意想不到的冲击。 -
技术引起的异常：主要指的是未能有效处理某种技术的天生缺陷所引起的异常。
下面分别讨论一下。
软件服务于业务，是一种现实世界的投影。但是实际运行时，有可能不会像现实世界一样存在物理上的制约。比如业务上要先调用方法1，再调用方法2，影射了现实世界的“人”需要先拿起东西1放下东西1（方法1），再拿起东西2（方法2），这个场景下其实是从物理上做了制约。但是从技术实现上，方法1的入口可能是同步接口，而方法2的入口是一个消息队列。那么当用户执行方法1之后立马执行了方法2，便可能会出现方法2在方法1之前执行的情况，如果实际软件在运行中真的发生了这种情况，系统是否可以正确处理。这就是异常业务操作引起的异常。再比如，我们要在现有软件的基础上做一个黑名单功能，对外提供了一个接口。那么将一名用户（或者什么别的）拉入黑名单之后，是不是要把ta的一些关联数据下掉。或者ta有什么未完成的业务的话，是否不可以将其拉入黑名单。同时该接口是一个批量操作的接口还是单个操作的接口，若是批量操作的，有没有可能一次调用量很大，导致接口超时？这些都是需要考虑的问题。而这就是新增功能对原功能产生了意想不到的冲击。
没有一种技术是完美的，可以解决所有问题的。技术在解决问题中发展，但是一定会暴露出一些别的问题。比如分布式服务框架解决了负载的问题，可以满足618期间的大量调用。但是由于是跨服务间的调用，就涉及到了网络请求，从而引入“超时”这一状态，调用方和被调用方如果没有正确处理这个所谓的“第三态”便会发生技术引起的异常。
不过现实情况总是更加复杂，在复杂的软件系统下，业务引起的异常和技术引起的异常总是如影随形，相伴出现。我这种划分方式也主要是给用例设计提供基本思考方向。
职责的划分
仁者见仁智者见智，职责划分也应该具体情况具体分析。我就基于下面的常见条件，给出一种“解法”吧。
一般来讲，业务团队有三种角色：产、研、测。测试在其中属于既懂技术，又懂业务的一拨人。但是往往技术上赶不上研发同学，业务上不及产品同学😔（我们不考虑特殊情况哈，别较真）。针对上述情况，我考虑将业务引起的异常主要交给测试同学来处理。而技术引起的异常主要由研发同学来解决，由测试同学来辅助检查。对此，研发同学应该进行“研发方案设计”。即先想好再做，同时在设计方案的时候需要对技术引起的异常有充分的考虑。同时，测试同学需要将异常放到“测试用例”的设计中。着重考虑业务引起的异常。至于技术引起的异常可以做抽查，或者以Code Review（可以是自己进行Review，不一定是和架构一起的那场Review）的形式来解决。
如何考虑业务引起的异常
每个业务系统服务的业务不同，这里可以聊的东西不多，目前想到两点。
- 从流程顺序不正常（颠倒调用顺序、缩短调用间隔等）的情况下系统如何处理着手。
- 业务上的“并发”（相同权限的人对于相同数据进行操作）。
- 面对新功能时，需要全面考虑新功能会造成哪些影响，系统需要如何处理。
极致提升鲁棒性没问题，但是成本曲线会在鲁棒性达到一定程度时直线上升。所以也不用特别纠结，掌握度。有时候让外部系统来辅助保证业务调用顺序也不是不能接受嘛~~
如何考虑技术引起的异常
这里可以聊的就太多了，完全可以做成一个checklist。目前想到的也不是很多，这个后面再持续完善吧😅。
同步接口
- 调用超时情况下的处理。
- 被重复调用时的处理。
- 被调用时必填字段校验及对应的错误提示。
- 被调用时报文的异常拼装（明细级别的重复、非法字段的传输等）
消息队列
- 消费时遇到了相同的消息体。
数据库
- 数据是否会被同时操作。（有时后面动作的执行依赖前面数据的处理，但是考虑性能问题，一般咱的mysql都是锁写不锁读，这时候可能会发生前面的数据没处理完，后面的动作已经开始执行了，那读到的数据一定是错误的。这时候就需要考虑如何在流程上做限制，是否要引入Workflow Engine之类的了）。
压测
按道理，压测应该归结于业务引起的异常，因为压测是为了看系统能承受多少的调用量。但是实际调用量的多少是和业务有关的。传统的压测往往是单一接口的压测。但是业务一旦跑起来之后，某些特殊的接口压力会突增，并且当某些机器被打崩之后，会产生连锁反应。故，业务上需要依照历史数据等方式进行正确的评估，而压测本身也应该从业务着眼。不知道别处如何，我们这边压测往往是专门团队来做，但是这样做的一个弊端是压测的人并不懂业务。所以后面应该要重新考虑“压测”该如何进行，是不是应该由业务团队来承接压测任务，这样的话或许传统的测试组织架构模式需要进行一轮更新也说不定。只不过我目前不是压测专家，后面进行实践后再来更吧。
更新日志
- 2020年10月9日：初稿。
- 2020年10月27日：增加业务“并发”。
