谈系统中对于极端情况的处理-（测试的力度和覆盖度）
系统中总有些可能产生极端情况的地方，这算是一种风险，但是未必总有人重视。没有做过专业的测试，也不知道从有关专业的角度怎么看这个问题。这里只是说说我对于极端情况的一点看法。
那些几分钟或者个把小时的分析就能发现的边界情况，可能都算不上极端情况。比如一个返回integer型返回值的函数getCount（），正常思路就应该考虑大于0,等于0和小于0这三种情况。所以，0只是一个边界
那么我说的极端情况是什么哪？还说刚才说的这个 getCount（），如果正常返回区间是[0,n)（n是正整数），出错时候返回小于0的某个代表出错情况的代码。如果这样，似乎没有很明显的问题。在函数开始的部分，就设置了默认的返回值0,然后在中途运行出错的时候，可能恰恰没有“正确的”返回一个小于0的错误代码，而是“意外”的带出了默认的返回值。或者，函数中用来存储返回值的变量没有正确的初始化就被直接使用。
然后在很多的测试中，因为测试环境创建的够“完善”，或者根本就是在开发环境做的测试，很可能根本没有测试到出错退出的情况。
然后在使用中，也许恰巧有一次，服务器被客户方的管理员关掉了，或者说掉电什么的。然后再恰巧，这次取得的返回值的作用是判断是否进行某个重要的备份，或者删除某些重要的数据。然后，事故发生了……
我这两天就在客户现场，做一个系统的数据迁移的正式实施。主要的迁移代码都是我写的。截至目前还没有出现过类似上面我说的这种极端情况。但是，如果在更严谨苛刻的测试下，我想我的代码也肯定有一些类似的潜在的缺陷。
其实，我真正想说的是：很多时候，不是开发人员，或者研发团队不知道有边界情况，甚至极端情况，只是，在预防措施成本、发生“意外”（也许该叫异常）的概率和“意外”处理成本之间衡量之后，很可能就降低了测试的深度、力度和覆盖度。
例如：在公司里一个软件部内所有人都在用的iPM系统中，就发现一个情况：在按需求行政助理的权限几乎仅次于系统管理员的情况下，有一个行政助理在一个按需求应该所有人都能看到并进行选择的选择框中，却没有任何的可选项。
很多时候，对于代码品质的底限，也许不是因为组织的要求不高，或者保证措施不高，而是在不考虑质量或者很少考虑质量的情况下编排的满负载甚至超负载任务计划，具体开发人员，在加班和降低个人代码品质底限之间， 选择了后者。
