设计用例最开始遇到的异常情况，就是前置条件引起的异常流。例如，不具备订购条件的用户，不能订购该服务，这种条件排列组合就会产生很多种异常场景。
接下来遇到的异常场景就是，在操作进行中遇到的。
[plain] view plaincopyprint?
- 1）比如说操作进行时，断电、断网、死机等原因导致的信息丢失的异常；
- 2）订购过程中，用户或产品的状态变化引起的异常。例如商品下架或价格调整的处理；或是用户在下单后付款前，被监管等。
- 3）操作中应该选择的选项没有选择时的场景，例如购买产品服务时，未选择同意服务协议的场景，此时付款按钮应该灰显，无法进行付款操作。
- 4）通过构造URL产生的异常场景。例如用户存在某产品失效的订单，通过URL进入订单支付的页面的异常情况，此时应该提示此订单已经失效，支付不成功。
- 5）打开两个页面做相同操作时的异常流。例如，用户满足订购该产品的条件，用户打开两个购买服务页面A和B，当在A页面订购成功后，点击B页面的订购可能有三种可能：一是若订购的产品是周期型的，则进入续费的流程；二是，若订购的产品是永久型的，则会提示不可重复订购；三是，若订购的产品是计量型的，则可继续正常订购。
- 6）用户账户余额不足，充值失败的异常场景。
最后还有一些不怎么被关注的异常。因为这些异常发生的概率极低，而且通过正常的验证方式非常麻烦。例如，订购服务打标志位的问题。我们通常的测试方法，是去验证用户做了某个操作之后，有没有成功地打上应有的标志位；但是我们会忽略掉，如果用户做了某个操作后，除了打上应有的标志位以外，还打上了非期望的标志位的异常场景。这时，我们是否要验证每一个标准位是否有被误打上。这样工作量就太大了，因为也许有非常多的标准位。面对这种情况，我认为可以通过两个步骤来保证质量。第一，将标志位分类，以期望的标志位为标准，筛选出与它关系及其密切的标志位，例如有依赖关系和对立关系的标志位，这些标志位是重点校验的对象。第二，从源头检查。找出这些标志位的值是从何而来，可以通过检查配置或代码走读来检验。
由于实际上，普通人类的思维不可能缜密的无懈可击，不可能把大量复杂的逻辑整理得完美无瑕。这就像是小说里的“密室杀人案”，看上去是多么的不可思议，然而真相大白时的结果却是完全符合逻辑的。因此，作为测试设计人员，我们必须有良好的预见性，去摸索，并组合一些“必然”的错误。当然每一种产品都有他的特殊性，于是就存在其独特的异常场景。以上是我的一些想法，欢迎拍砖和补充，谢谢！
版权声明：本文出自fnngj的51Testing软件测试博客：http://www.51testing.com/?363937
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。