软件质量的浅谈
议题：什么是质量？
目的：希望通过探索质量，探求质量提升之道。
目标读者：项目经理、测试员、程序员
图片不显示，想要的联系我[email protected]
今天就“质量”一词，再来谈谈这个老生常谈的话题。当然，都是个人的一些观点和总结，不同意可以拍砖或者来探讨。
“质量”这个词用得太普遍以至于混乱，有时候它表示质量这个指标，有时候它隐含质量好的意思。而且不可避免的，好的质量常常和它的反面联系在一起，就好像《中国质量万里行》，或者《央视3.15晚会》，列出的都是质量方面的问题，好像很少宣扬质量好的产品。所以很多时候，我们看质量是从反面(缺陷，或者质量不好的地方)来看的。这就跟我们总喜欢听成功人士怎么成功，却不喜欢听失败的人士怎么失败一个道理，容易产生判断偏差。因此，在下面讨论的时候我也会用或正或反的例子来论述。
Quality scope 1： 实现与需求一致
这一点蛮好理解，即实现客户要求的功能。这是一个很基本的要求。但是这是一个可以轻松实现的目标吗？显然不是，面临的困难有很多，诸如：
- 需求真的清晰吗？客户真正想要的跟表达出来的一致吗？项目经理理解的跟客户表达的（或真正想要的）一致吗？
- 需求实现有技术难度吗？
- 项目时间足够实现所有需求吗？
以上三点我们一一道来，首先是第一条需求沟通、传递的问题：
我们的做法：
- 编码前用AXURE原型图跟客户沟通、确认
- 需求沟通后，整理需求说明书给客户签字确认，以此确定我方理解与实际需要无出入
这种做法的优缺点：
通过提前项目可视化（所见即所得）和用户签字确认的方式，可有效避免返工，大幅降低项目风险，并可在项目验收结算时提供必要证明。
不足之处是，UI设计时更多的从页面美观性出发，可能会设计出客户没有提的需求，或逻辑上不合理的功能字段，或者技术实现难度较大的呈现方式， 导致其他成员对需求产生歧义， 甚至导致项目范围定义不清、项目严重拖期、预算偏差过大等严重后果。
应对策略：
n 需求沟通时项目经理、UI、测试人员共同参与；
n UI设计完成后，项目经理、技术骨干、测试人员对UI进行仔细的沟通评审；
n 评审完成后制定专人编写需求说明书。
第二条--技术实现的难度：
这一点也好理解，就是客户想要某种效果或功能，但我们没做过也可能不知道怎么做，短期内也难以通过学习来找到解决方案。举个例子来说，客户想要做一个产品类APP，客户想要产品可以按多种样式来排列，比如下图：
这是一个普遍需求的功能，但如果我们没有相应的技术积累，项目周期又短，那么我们可能就无法去实现，无形中就降低了项目的“价值”。如果必须去实现，可能项目就要拖期。。。
我们的做法：
开发自己的框架，建立框架培训体系，完善公司的组织财富库。
这种做法的优缺点：
as u know，一般而言产品是比项目的利润高的。因为项目每次都需要重新开发，而产品某种程度上可以说是“一劳永逸”。项目常常担心项目会不会拖期，而卖产品不用。其实框架也是一个产品，一个好的框架可以为项目的成功提供多大的助力，相信不用我再赘言。
我们需要做的：
开发并持续完善java、.net、Android、IOS、PHP框架，微信管理平台。
Android：
给大家提供一个链接：http://download.csdn.net/album/detail/2225，这是一个开源的Android空间库，上面有可变布局、左右滑动删除item效果、listview动画效果、聊天表情实现及刷新聊天记录、加载网络图片、testview自动提示输入的源码。
微信管理平台：
我这里也有一整套方案和源码，需要的可以问我要。
ps 在缩短项目周期方面，我部门的要求和建议还有：
- 系统测试阶段开始，对数据库结构的改动须用sql脚本进行。并在版本发布时将脚本一并交于测试员--该阶段以后数据库结构变动较小，因此不会给开发人员造成负累。
- 对测试的要求：bug的描述需附加截图，并给出清晰的修改期望--减少因bug描述不清而耗费的时间；
- 对开发的建议：bug解决后，建议给出问题根源和解决方案，这是一项利人利己的工作--测试人员可以通过BUG的来龙去脉决定是否做一些bug预防措施，即使没法做预防，测试员在遇到类似的bug时也可以“凭经验”快速定位问题根源，进而降低bug修复时间。
Quality scope 2： 一些不言自明的要求
为什么说是不言自明呢？比如，一个人买洗衣机的时候，可能只会问一下品牌、价格等，可能不会问耗电多少、噪音多少分贝。这并不代表他没有这方面的标准，而是“不言自明”。 如果事先没有说明，这可能会带来一些纠纷，但是最终生产这样的洗衣机的厂家一定是这些问题的受害者。因为大家都会知道这个牌子的洗衣服超耗电，而且噪音大。而如果只按照第一个scope的要求，它可能是一个很合格的产品，而且或许衣服还洗得挺干净的，通过了QA的测试。
对一个软件系统来说，这方面的要求有安全性、性能、外观、稳定性、兼容性等等。
我们的做法：
GUI：已制定相对完善的《设计、开发测试规范》。以后需加强容错性的处理。
安全性：已制定《安全测试指南》，发现了问题以后即对系统或框架进行完善。
性能：需要在需求中做出更明确的要求，并积累性能调优策略。在典型的系统中建议添加用户行为记录，为该类系统的性能测试提供精确的数据积累。
兼容性：目前已经积累了不少《兼容性常见问题和解决策略》，以后继续补充。
稳定性：系统上线前，采用压力临界点进行7*24压力测试。这样可以发现大多数内存泄露和数据量积累后暴漏的问题。
Quality scope 3： 设计符合用户的需求
在scope #1中，我们提到好的质量的最起码的条件就是实现了宣称的功能。那么引伸出另一个问题是，设计本身是合理的吗? 也可以说，用户想要的就是合理的吗？
我们或多或少的都遇到过这样的情况：客户今天提出一个需求，我们也跟客户确认了，但是过了几天客户又提了一个新想法，可能新想法还跟之前的想法是冲突的！而最终我们觉得客户一直在变想法，需求改了一遍又一遍。最后费了九牛二虎之力终于交付了，客户还总会抱怨我们的系统质量不够好，会给售后服务部门提一个case过来，提出他们的合理(从他们的角度确实是)要求。
我们的做法：
目前来讲，地产全流程方面的业务，或许还算不得专家，但相信我们的产品拿出去，也可以当得一个解决方案。现在跟商派达成合作，不久的将来在电商领域也能迅速积累起自己的口碑和客户。但是在其他方面呢？我们做过不少堪称行业典型的项目，但却算不得“解决方案”--个人觉得如果想叫解决方案，起码得用同一个系统服务过至少两个客户。
对于我们测试人员来讲，要解决这样的问题，可能有两个方面的要求
1. 应该更多的从用户的角度来考虑问题。也就是常说的customer insight，从这个角度我们不是完全被动的按着设计走，而是可以挑战它，质疑它为什么做成这样，至少要知道为什么。
2. 需求阶段就介入（具体工作请查看我写的《如何做好系统测试》）。一开始就应该参与到产品的设计中，并且从用户的角度给出自己的意见。当然，这一部分也依赖于行业知识和个人的经验。
以上两个方面，对测试人员来讲，是挑战，因为要求更高了，也是机会，因为工作更有value了。
举个最近我做的项目--日日顺大盈家APP来说吧。
项目简介：这是一个B类APP，主要是做产品分销。客户希望将日日顺商城中的商品，结合时下流行的分销模式进行售卖。具体模式是微店主（分销人）在APP中选货添加到自己的微店，然后通过分享到微信、QQ等平台，买家看到分享链接后即可点开进行购买。客户下单后由日日顺（或体验店）直接发货。每售出一单商品，微店主可获得不同的佣金。
针对这个APP，我们在调研阶段，获晓了客户的需求之后，就得考虑如何才能让微店主如何喜欢并“依恋”上我们的APP（在上一期《质量简报》中我们提到一个APP最成功的标志就是让用户“依恋”）。以此对微店主展开痛点分析：
对微店主而言，需求阶段可以分为朴素的需求和进阶的需求，这是一个递进的过程。朴素需求就是选货、拿现货（有库存、未下架）。一方面寻求高利润的货，一方面是寻求高品质的货，有些线下体验店和线上C端店铺可能只做高端货，只做高端用户，这个时候对品质需求相对会更高。同时，微店主（买家）也会自寻求一些高品质、口碑比较好的实体店（微店主）对接并把关系沉淀下去。
进阶诉求方面，除了商品本身，也会对微店主的特殊货源诉求、交易流程、信息链做一些特殊需求的满足。比如货源上，有些人喜欢尖货，有一些喜欢最新上市商品，有一些喜欢最热门商品，有一些想要签约体验店，从体验店上货，既有价格优势，质量体系也比较完整。
作为一个B类APP，跟万金油似的淘宝本质上是相同的，都是物质交换。但是它面对的客户群更单一，这就决定了在选货方面更有指向性，比如推送、banner。同时其在分销的过程中对于交互必然是要保证精确、流畅的，这也是它的核心业务。
再看用户情绪诉求上，如果店铺主在逛App的时候认为App做的太low，从感性角度就很难融入。另一方面，人性有没有受到尊崇，这点也是可以让用户持续领略产品魅力，并且忠于产品的要素。用户需要被主动关怀（做一个有情怀的产品），可以是个性化的。比如推送——猜用户喜欢什么；定制——要什么就能得到什么等等，这是原始欲望的一种发泄。
有了以上这些层面的思考，在设计和测试的时候就有了应对策略，浓缩一下就是：市场丰度的打造、服务链路的桥接、体验腔调的攀爬。
如何去塑造和建立一个高丰度的市场群？这点可以从360软件市场做一些类比参考。现在打开软件管家，感受最多的一是软件足够丰富（全部软件21716个， 貌似我平时常用的软件也不过十几种而已）， 二是品类足够全面（各种各样的分类）！
作为一款分销类APP， 我们再从用户的层次进行分析。对于刚接触这个产品的用户，他们上货未必有什么针对性，可能一股脑的全部把货都上架， 分销的时候也是天女散花，随心所欲。对他们而言，可能更看重高佣金、热销的便宜货，对他而言设备的竞争力、新锐程度、品质程度并不是第一优先级。但随着用户经验的丰富，就会产生更有要求、更专业的上货倾向， 比如更看重质量， 或者有底气成为签约用户，或者专做月返商品的分销，或者专做体验店设备的分销，或者更趋向于从线下体验店上货。从这个角度来看，我们需要用一种比较科学的方式为处于不同层次的用户设计不同的上货筛选条件。
最后我们来从买家的角度略作思考，买家也需要按不同的层次来考虑。有喜欢便宜实惠的居家型买家，有喜欢新鲜事物的追新族买家，也有专认某个品牌型号的粉丝型买家，还有只认最高价的土豪流买家。针对不同的买家，我们也需要设计不同的呈现内容。对居家型买家来说，我们设计了通用的秒杀、团购；对追新族买家，我们设计了最新和最热；对于粉丝型买家和土豪流买家来说，店铺主的商品是否提供了便利的筛选方式？ 若没有是否意味着我们需要针对这样的用户添加筛选条件， 或者是为专做高端用户群的微店主定制专门的模板？
Quality scope 4： 处理异常情况的能力
对于这一点我们的处理是把已知的内容整理到《测试工作指南》《输入验证指南》等文档，通过事后的验证进行处理。并把部分优化到框架中，做好事先的bug预防。
Quality scope 5： 易用性
这是一个很重要的也常常被忽视的方面，也是一个没有明确界定的方面。很多时候我们开发产品的人会觉得自己的产品很好用，但是用户不觉得。我想其中一个很重要的原因是我们自己对这个领域很熟悉，而且对产品的各个功能，甚至他们内在的联系很清楚，再者因为工作的原因我们已经用了几十上百遍。这样算来易用性当然不是问题。但是我们不能要求我们的用户如此，因为用户不会(很多产品也不应该)花很多的时间研究学习我们的产品，他们购买我们产品提供的功能，就是要更有效和高效的完成他的工作。如果用户为了完成一件常见的工作，比如修改一项小的设置，就需要去修改很多的地方，而且没有提示要告诉他修改对应的地方，那么这就是我们产品的问题。
很多时候用户错用或者误用我们产品的功能，除了用户自身知识和经验不足之外，我们也应该反思一下是不是我们的产品做得不好用，流程和界面设计得太让人困惑。
易用性不只是产品的UI做得比较好看，更多的时候还包括产品的流程和接口的设计。这是一个很大的领域，这里限于自己的了解和篇幅就不详述了。软件就是服务。让我们把服务一起做的更好一些吧。
我们的做法：
- 通过分享易用性做的好的功能或系统，让易用性“有法可依”。
- 把自己想象成对产品了解有限的初用者。
- 找一个不太了解的，给他一些任务，让他去操作，然后去观察，听听他的感受。
Quality scope 6： 维护
需要加强的方面：系统上线后运营数据的收集， 日积月累， 渐成大数据。
性能测试： 在做性能测试的时候，最理想的情况是清楚的知道各个页面的用户量是多少，系统各个功能的压力分布情况，用户在每个页面停留的时间，日访问量，月访问量，访问峰值，访问峰谷时间等数据，我希望我们的项目能帮忙收集到该类数据。
推送： 前段时间跟一家推广APP的的公司聊过，得知他们可以通过记录用户手机机型、用户习惯等方式，实现定向推送的功能。我们做的海客会、日日顺是否也可以借鉴一下呢? 用大数据的原理，给每个用户推送其喜欢的消息？