软件测试异常场景（异常测试用例是什么）

其实“异常”测试用例这个说法也只是相对而言，如果需求有明确说明一种“异常”情况下应该如何如何，那测试用例就相对“正常”，如果需求文档中没有明确指出的“异常”场景，可能会习惯的定义为“异常”。

对于测试用例的设计和编撰，首先都得分析并细化需求，再根据细化的功能点编撰测试用例。异常场景的测试用例也应该包括其中。

打个比方，假设有一款导航app,现在需要根据"路线规划功能"设计测试用例。

我们首先要根据文档已有信息加上自己补充整理而得到细化内容（包括异常情况），比如有路线(步行，自行车，汽车，公共交通等)，规划策略(红绿灯少，时间短，换乘少等)还有其他因素（堵车，修路，限行等）。

然后就可以开始列测试点了，就我上面列的因素举例：

汽车+红绿灯少+不堵车+没修路+没限行

汽车+时间短+不堵车+没修路+没限行

汽车+换乘少（正常汽车没有这个选项，如果需求允许的话就属于异常情况）

.....

全部因素都穷举，测试点就很多了，可以用正交实验法减少一些，还可以根据“了解实现原理”来简化测试用例。保证覆盖率不变前提下，精简测试步骤。又比如“堵车、修路”都是独立于其他因素单独实现的功能块，只会影响这条“路线”是否可以“可用”。那就可以单独归类出来另外设计测试用例

“可用路线”+不堵车/不修路

“可以路线”+堵车/修路

然后发散下思维想想异常情况，比如这条"可用路线"因为堵车/修路变为“不可用”后，都没有“可用”路线时，预期结果应如何，或者是在山上，都没有“汽车“的“可用路线”，预期结果应又该如何。还有比如目的地不存在，搜索结果如何显示。

最后，测试用例原则上是要尽量多异常用例，来增加覆盖度。实际测试阶段，要根据项目情况，区分执行的优先级，先主要流程，后异常情况。