Quality scope #4： 处理异常情况的能力
说到这个问题，还是举个例子吧。 很多人可能对nokia手机的抗摔能力印象深刻，自己遇到的或者听朋友说的。常见的情节是这样的，一不小心从桌子上，或者从楼梯上把手机摔了下来，然后盖 子摔开了，甚至电池也掉出来了，这时候心里拔凉的，但是抱着侥幸心理把它们重新装到一起，按下开机键，everything is OK，然后很happy。这种故事的后续是很多人因此第二次，第三次称为诺记的用户。因为觉得他们的手机质量很好。
这个故事有趣的地方在于说明书 上从来不会写我们的手机从楼梯上摔下来不会有问题，厂家估计一般也不敢写。从楼梯上把手机摔下来绝对是一个异常的情况，也不是产品针对的场景，严格来说摔 了之后坏了也属正常。但是反过来，如果这种异常的情况下，都没有问题，就会让人觉得质量很好。所以是一个质量加分的地方，也是branding build up的地方。比如你可以（以前?）不小心把水倒在Thinkpad的键盘上，也可以踢到macbook的电源线。
从软件的角度，异常 的情况也有很多，比如
1. 突然停电
2. 硬件故障
3. 操作系统故障
4. 网络连接意外中断
5. 系统资源（内存，硬盘，网络端口等）耗尽
6. 用户的误操作
通常情况下，这些情况都不会发生，但是还是会发生（墨菲法则）的。如果只是一 个PC上播放MP3的软件，遇到上面的情况就出问题了，甚至不能恢复需要重装，也许还是可以接受的，毕竟不是很重要的任务，而且也不常发生。但是如果是很 重要的软件系统，而且有着重要的数据，不能恢复就问题大了。
对于这一部分，我们都应该考虑到，不管是开发还是测试。在测试的过程中，我们 也要尽量的去验证。
其实质量还有很多的方面，比如。
Quality scope #5： 易用性
这是一个很重要的也常常被忽视的方面。很多时候我们开发产品的人会觉得自己的产品很好用，但是用户不觉得。我想其中一个很重要的原因是我们自己对这个领域很 熟悉，而且对产品的各个功能，甚至他们内在的联系很清楚，再者因为工作的原因我们已经用了几十上百遍。这样算来易用性当然不是问题。但是我们不能要求我们 的用户如此，因为用户不会（很多产品也不应该）花很多的时间研究学习我们的产品，他们购买我们产品提供的功能，就是要更有效和高效的完成他的工作。如果用 户为了完成一件常见的工作，比如修改一项小的设置，就需要去修改很多的地方，而且没有提示要告诉他修改对应的地方，那么这就是我们产品的问题。
很多时候用户错用或者误用我们产品的功能，除了用户自身知识和经验不足之外，我们也应该反思一下是不是我们的产品做得不好用，流程和界面设计得太让人困惑。
易 用性不只是产品的UI做得比较好看，更多的时候还包括产品的流程和接口的设计。这是一个很大的领域，这里限于自己的自己的了解和篇幅就不详述了。最基本 的，我们可以把自己想象成对产品了解有限的初用者，很多问题就容易暴露出来了，或者还有一个办法，找一个不太了解人的，给他一些任务，让他去操作，然后去 观察，听听他的感受。
Quality scope #6： 可维护性
维护的目的有很多，比如产品升级，功能升级， 打补丁等等。 对于一个正式而长期使用的系统而言，特别是服务器软件，这是很常见的工作。这些方面处理的好坏往往也非常容易影响到用户对产品的判断和印象。常见的问题包 括
1. 产品升级不能将来的版本的数据导过来，或者数据出错
2. 升级后不兼容或者对硬件要求很高
3. 打补丁或者升级后遇到问题是否可以回滚？
4. 用户报过来问题，如果收集信息定位问题
软件质量其实是一个很复杂的东 西，上面提出的其实也只是工作中常遇到的一些方面（即便如此，很多还是常被忽略），比如用户对产品质量的看法还会受到情感因素的影响，比如产品的UI，和 客服人员的沟通过程，以及公司和产品的品牌等等。
从软件测试的角度，针对质量的不同的方面，我们也有不同类型的测试活动来保证，比如design review，还有各种测试类 型，functional，stability，performance，deployment，migration，usability，stress，compatibility 等等。
