标签：
设计用例最开始遇到的异常情况，就是前置条件引起的异常流。例如，不具备订购条件的用户，不能订购该服务，这种条件排列组合就会产生很多种异常场景。
接下来遇到的异常场景就是，在操作进行中遇到的。
最后还有一些不怎么被关注的异常。因为这些异常发生的概率极低，而且通过正常的验证方式非常麻烦。例如，订购服务打标志位的问题。我们通常的测试方法，是去验证用户做了某个操作之后，有没有成功地打上应有的标志位；但是我们会忽略掉，如果用户做了某个操作后，除了打上应有的标志位以外，还打上了非期望的标志位的异常场景。这时，我们是否要验证每一个标准位是否有被误打上。这样工作量就太大了，因为也许有非常多的标准位。面对这种情况，我认为可以通过两个步骤来保证质量。第一，将标志位分类，以期望的标志位为标准，筛选出与它关系及其密切的标志位，例如有依赖关系和对立关系的标志位，这些标志位是重点校验的对象。第二，从源头检查。找出这些标志位的值是从何而来，可以通过检查配置或代码走读来检验。
由于实际上，普通人类的思维不可能缜密的无懈可击，不可能把大量复杂的逻辑整理得完美无瑕。这就像是小说里的“密室杀人案”，看上去是多么的不可思议，然而真相大白时的结果却是完全符合逻辑的。因此，作为测试设计人员，我们必须有良好的预见性，去摸索，并组合一些“必然”的错误。当然每一种产品都有他的特殊性，于是就存在其独特的异常场景。以上是我的一些想法，欢迎拍砖和补充，谢谢！
版权声明：本文出自fnngj的51Testing软件测试博客：http://www.51testing.com/?363937
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
标签：
原文地址：http://www.cnblogs.com/yanghj010/p/5112648.html
