当选择一个商品的时候，我们常挂在嘴边的一个词就是“质量”，这是影响我们选 择的一个很重要的指标。这一篇我们就来探讨一下什么是软件的质量。当然，都是个人的一些观点，不同意可以拍砖或者来探讨。
　　质量这个词用得太普遍以至于混乱，有时候它表示质量这个指标，有时候它隐含质量好的意思。而且不可避免的，好的质量常常和它的反面联系在一起，就好像以前的“质量万里行”，或者现在的3.15，列出的都是质量方面的问题，好像很少宣扬质量好的产品。所以很多时候，我们看质量是从反面（缺陷，或者质量不好的地方）来看 的。在下面讨论的时候我们也会用或正或反的例子来看。虽然是在探讨软件的质量，但是为了便于理解，可能也会举别的产品的例子。
　　前一篇里面 也提到，在传统的关于软件缺陷的定义中，是看实际做出来的产品是否和规格说明书（spec）一致，如果不一致那就是defect或者俗称bug。如果只是 从这个范围来看，这个定义本身没有问题，因为如果做出来的东西不是我们想要的，那当然不对。所以下面我们得出质量的第一个方面。
　　Quality scope #1： 实现了说明书上的功能
　　比如你下载了一个电影播放器，它宣称可以支持MP4， MOV， RMVB， AVI格式，那么它必须可以正确播放这些格式的文件。这是一个很基本的要求，就像洗衣机要能洗衣服。如果实现这样的基本功能出现的问题，那么用户会非常生 气，觉得质量太差，根本不能用，直接卸载掉，或者要求退货（商业产品）。
　　正因为这样的后果很严重，所以在测试中，对于这样的基本功能我们都会反复验证。
　　OK， 如果说明书上说的功能都实现了，那么就是一款质量很好的产品了吗? 实际上可能并非如此。那么差别在哪里呢？
　　Quality scope #2： 一些不言自明的要求
　　为什么说是不言自明呢。举个例子， 还是洗衣机，客户可能会说“我想买一台洗衣机”。然后他买回去一台，价格也还不错。回去后发现确实能洗衣服（上面提到的基本功能实现了），但是有个问题， 这个洗衣机洗一次衣服需要3个小时，而且洗的时候噪音很大。
　　洗衣机是很普遍的一个商品，用户在一开始买的时候可能也不会问洗一次要多长时间或者噪 音多少分贝。这并不代表他没有这方面的标准，而是“不言自明”。 如果事先没有说明，这可能会带来一些纠纷，但是最终生产这样的洗衣机的厂家一定是这些问题的受害者。因为大家都会知道这个牌子的洗衣服超慢，而且噪音大。 而如果只按照第一个scope的要求，它可能是一个很合格的产品，而且或许衣服还洗得挺干净的，通过了QA的测试。
　　我相信这一类的例子还 可以举出很多
　　笔记本： 发热量比较小，不会太烫
　　杀毒软件：占用系统资源不要太多，机器启动也不会变得很慢
　　网上购物系统：响应时间不能太长
　　这方面的要求有很多，比如包括safety， performance，stability，impact to other software...
　　也正因为这一类的要求是“不言自明”的， 所以开发的时候反倒容易被忽视。当然也可能是故意被忽视，因为技术和成本的原因，很多山寨产品就是如此吧。
　　比较好的做法是我们把这些方面的需求明 确的列出来，并尽可能的进行量化。比如前面例子中涉及的时间和噪音问题，如果在内部的设计文档中就有明确的要求，最终出来的产品就不会有这么大的问题。
　　关于这一类的需求，还有几个特点。
　　1. 这方面的要求不容易确定，也不容易评估或者验证。
　　比如performance，比单纯的某个功能点，要复杂很多，有时候甚至什么是performance够好或者很好都难以界定。所以这也要求产品的设 计和开发人员对产品和用户的需求有更输入的理解，而不只是照着做。
　　2. 这方面的产品特性是难以被抄袭的。
　　国内的山寨能力想必大家都见识过，很多产品出来后很快就有了功能十分相近的仿制品。小到手机，大到汽车。iphone的山寨版长得很像哦，而且也可以全屏 触摸，multi-touch，而且不到1千块。还有双环的SUV，远一点看就是BMW X5，之前一位美国同事来出差看到一辆还特意掏出手机拍照留恋，因为他是X5车主。现实中，iphone在国内依然火爆，X5也还是很多人的dream car。因为有很多看不见的特性（比如performance）在它们和抄袭者之间划清了明确的界限，质量高下立现。当然，差别也不只是这么提到的这些， 还有其他，比如branding。
　　好吧，如果我们的产品连这些不言自明的要求也考虑到了，那么是不是就会被认为质量很好 呢？ 不一定。
　　Quality scope #3： 设计符合用户的需求
　　在scope #1中，我们提到好的质量的最起码的条件就是实现了宣称的功能。那么引伸出另一个问题是，设计本身是合理的吗？
　　如果我们把developer定位 成实现所需要的功能的人，把QA定位成验证这些功能是否正确实现了的人，那么这一部门的质量我们就没有办法覆盖到。因为如果是这样的定位，大家就不会去 想，这样做合理吗？是用户想要的吗？做出来用户会喜欢吗？ 反正我们只要按着spec做出来就好了。
　　这样的例子其实也有很多，比如
　　1. by design，我们只支持IE浏览器。但是我们发现很多用户都在使用Firefox和Chrome。
　　2. 我们的邮件历史查找只支持按收件人，现实中有很多用户也需要按发件人来查找
　　3. 如果用户重装系统的话，需要把曾经在老系统上配置的policy一条条重新配置，包括white list和black list。
　　4. 如果中途网络断掉了，用户前面输进去的东西下次联网后要重新输入。
　　类似的例子我们还可以举出很多。这些问题有什么共同点呢，那就是用户会 抱怨我们的系统质量不够好，会给售后服务部门提一个case过来，提出他们的合理（从他们的角度确实是）要求。
　　如果我们的软件测试只停留在验证功 能的角度，这些问题都不是问题，因为直接被我们排除在工作范围以外。但是最终这些问题都会被用户遇到，而且形成一种印象，那就是我们的产品质量不够好，特 别是当竞争对手能够做到的时候。这就会形成一个gap，我们内部测试的时候觉得质量很好很稳定，但是用户还是不满意。
　　要解决这样的问题， 可能有两个方面的要求
　　1. 测试人员（其实也包括开发人员）应该更多的从用户的角度来考虑问题。也就是常说的customer insight，从这个角度我们不是完全被动的按着spec走，而是可以challenge它，为什么做成这样，至少要知道为什么。
　　2. 测试人员要往开发流程的更前面走，而不只是等到产品做出来了之后去装起来验证。那样太晚了，而且修改的成本比早期要高很多。测试人员一开始就应该参与到产 品的设计中，并且从用户的角度给出自己的意见。当然，这一部分也依赖于domain knowledge和个人的经验。
　　以上两个方面，对 测试人员来讲，是挑战，因为要求更高了，也是机会，因为工作更有value了。
　　到目前为止，看起来我们的质量范围已经比较完整 了？ not yet。
        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 等等。