如何防止低级问题导致的质量事故

如何防止低级问题导致的质量事故
2017-02-04 杨晓慧 测试人杨晓慧
这里说的低级问题是指：不需要特殊条件，就是在用户进行正常业务的基本操作时，由于缺陷导致业务操作无法完成。
例如：正常安装或升级过程中出错；新研发特性的基本功能有错；升级后原本正常使用的功能出错；产品在正常使用中数次崩溃；正常使用中有导致用户有直接的经济损失或信息泄露的错误。
 
你可能觉得，这种问题应该非常罕见，但事实上你在生活中就会碰到。下面是我一次在当当买书的真实经历：
朋友向我推荐了一套《给孩子的哲学》，我搜索得到下面的列表：




点开第三条链接，显示如下：




在这个例子中，搜索结果的书名信息和搜索关键字”给孩子的哲学”毫无关系，但是除了书名以外，其他的内容都是正确的，书籍的整个购买流程也可以正确的实现。
但是，如果我不是一个对缺陷敏感、好奇心爆棚、喜欢一探究竟的测试工程师，而是一个就是想好好买本书的普通用户，看到第一个界面时就已经懵圈了。
 
为了搞清楚缺陷是不是与特殊输入有关，我又试了其他一些书名（如下图），发现这就是一个低级问题，和书名一点关系没有，就是某个字段的数据来源指错地方了。


 
如果你的产品这类问题频出，那么恭喜你，你大概有希望做出一些有价值的事情了，因为这类缺陷对用户的影响最大，是研发需要最优先解决的问题，你在解决这个问题时，很有可能也能得到相应的资源。
而且这个问题看上去也不难解决，基本功能的测试用例我们是有的，只要实现自动化就好了……，如果你这样想了，也这样和老板说了，那么，很遗憾，这事十有八九会搞砸了。
 
再看一个例子吧，某天，我需要把信用卡提前还款，恢复信用额度，以应付接下来的支付需要。通过网银查询账单：


 
点击链接进入快速还款，发现应还金额为零，与账单查询到的不一致。




查询未出账单，发现此笔已经自动还款，因此上述应还金额为零可能是对的。但是还款之后的消费，无论是否入账，都无法选择提前还款，这样，还是无法恢复信用额度（以前曾经这样操作成功过）。




查询账单、快速还款，这些功能单独看起来都是对的，但是组合起来，却无法实现我所希望的应用场景。
 
看完这个例子，你还觉得你有全部的基本功能测试用例了吗？如果想要彻底杜绝低级问题，你的“基本功能测试用例”至少需要覆盖：所有特性的基本功能，以及主要的应用场景。这里还没有包括基本的DFX测试……
 
那么，补用例+自动化就够了吗？no，no，no。回想一下本文第一个例子，即使已经有了“根据书名搜索”的测试用例，你确定你的用例会检查每个字段吗？别忘了，这个例子里，只有一个显示字段是错误的，其他都是对的！所以，测试用例的预置条件、操作步骤、中间和最终结果检查需要更严谨。
然而，我们是故意少检查一些东西的吗？不是的！我们少检查，是为了让特性变更的时候，那些只是使用而不是为了验证这个特性的测试用例就不用修改。如果检查内容更严谨，很可能会需要更方便的测试用例管理工具，使得随版本同步修改用例变得简洁。
 
现在，问题有点复杂了，为了杜绝低级问题，需要对测试设计进行重新整理，确保其覆盖所有特性的基本功能和主要应用场景，每个用例的内容严谨。此外，需要一个好用的，方便同步修改多个用例的测试用例管理工具。
然而，故事还没有结束，发生这类问题还可能是与客户的业务流程、使用习惯、网络和服务器环境、产品部署、用户数据特性有关……
瞧，现在与“只要实现自动化就好了”想去甚远了。
 
当然，这并不是说只要是杜绝低级问题，就一定需要做上述工作，怎么才能知道是不是需要做这些呢？只能求助于客户问题分析，只有知道导致问题出现的因素，才能知道测试时需要考虑哪些因素。
测试团队要像重视测试设计一样，重视客户问题的分析，这是测试最重要的两个手段，无论是个人能力提升，还是团队技术积累都要用到。
至于客户问题怎么分析，我们在另外的话题分享。
 
测试设计的问题解决了，接下来才是实现自动化测试，根据测试设计考虑的因素不同，在实现自动化的时候，除了最基础的选择工具和测试接口、自动化用例的设计等，至少还需要考虑：
1、  测试环境的自动化搭建和配置——如果测试需要在若干不同的环境上执行
2、  从用户接口（UI）进行测试——如果包含应用场景的测试用例，则通常意味着需要从UI进行测试
 
最后，我们的目标是“杜绝低级问题”，问题应该在什么环节发现——自动化测试用例的执行时机；问题由谁解决——确保自动化测试用例执行通过的责任人，这两个问题还需要落实到流程。
 
现在，为了实现“杜绝低级问题”，我们需要进行客户问题分析，根据分析结果和测试现状优化测试用例，实现自动化的测试，并将相应的测试活动确定责任主体并落实到研发流程中。相比仅仅实现自动化测试，这样做的工作量、需要的外部支持都有很大的差别。
 
现实中，我们很少有人能意识到，问题的解决需要这样一套“组合拳”。真正遇到这样的机会，我们很可能是这样的：
我们已经知道，问题爆发只是表象，内在的原因很可能是测试积累了大量的技术债务。终于质量问题开始失控，让研发团队痛下决心，加大对测试的人力投入。测试经理也终于有了喘息之机，把很久就想做的测试设计方法应用、自动化、测试方案模板规范化、DFX测试……一一落实。
那么，问题来了：千头万绪，从哪里开始？要不就是基于最近出现的、客户反应激烈的几个问题；要不就是测试经理有印象的一些问题；要不就干脆不是基于问题，而是测试经理或几个专家个人的技术偏好。具体实施某一项工作，比如测试设计，开展的工作就是组织团队学习测试类型、测试设计方法、制定测试的各种模板、把写的好的测试方案和用例做成样板或案例……，测试团队致力于学会使用标准的方法和模板，使测试终于像一个有技术含量的工作，但是却完全忘了当初为什么要做这些。
最后，在局外人来看，测试团队就是利用这些人，做了最基础的、本来早就该做好的事情，真正的业务问题，并没有思路、没有行动去解决。
这并不是说不能在这个时间进行基础能力建设，而是说不能止步于此，需要着眼于问题，从问题分析得到解决方案，有能力短板则补齐短板，最后以新具备的能力为基础，结合其他辅助手段完成解决方案的实施，最终解决问题。这样才算完成了一个问题闭环的循环


 
总结一下：低级问题通常并不像看上去的那样容易解决，除了自动化，至少还需要在SE甚至运营维护部门的帮助下，完善测试设计；还要在研发经理的支持下，调整研发流程。
 
本文例子和观点摘自《软件测试价值提升之路》的第三章，书中有更系统的解决思路，以及更详细的解决方法介绍。


购书链接：http://product.china-pub.com/5035410
        https://item.jd.com/12085936.html
        http://product.dangdang.com/24160890.html

以上内容系本人原创，如需引用，请注明出处。