标题: Zero bug start from here [打印本页] 作者: xianggx 时间: 2010-6-12 20:26 标题: Zero bug start from here 无论是业务型项目还是改进型项目，测一个项目最大的风险可能就是需求的不确定性。或许我们都经历过这样的问题：1.介入的项目是自己以前从未接触过的业务领域2.项目的需求朝令夕改，跟不上变化3.需求不了解，测试不深入，不敢承诺质量。有很多时候，因为时间和资源等等方面的问题，往往会遇到PRD不够详细，UC描述又过于简单（对于技术优化类的项目，UC可能完全就没写），虽然说我们都有权利退回需求不明的测试任务，但是在遇到“不得已而为之”的时候(比如紧急需求)，想办法解决问题，给出切实可行的方案总是好过什么都不做的退回，抱怨解决不了任何问题。那我们怎么才能占据主动，让需求自己能够跳出来找我们呢？
在接手一个需求后，作为测试人员，到底应该思考些什么，或者说到底有哪些内容是我们需要去把握的。如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把”软件”两个字全部替换成了”测试”。这样，我们就明白了整个测试活动的依据来源于测试需求，那么我们应该怎么来挖掘测试需求呢？
下面先来看一段场景：律师草拟遗嘱的过程：假设你有一大笔财富，在即将临死之前，你邀请了一个律师，说明了你的财产分割意向：你希望将其中的一部分钱留给外甥的孩子，律师说：假设你的外甥没有小孩该怎么办？但是你从来都没有考虑过那种可能性，所以考虑了一会儿，然后告诉律师说如果那种情况发生，就将所有的钱捐给福利院，几轮问题之后，律师几乎已经覆盖了你所有的愿望，即使有些可能你连自己都未曾想过的，并且最后草拟了你的遗嘱。其实这就是一个挖掘需求的过程，它涉及到那些甚至可能不会发生的将来的事情。
由于思考方式、对于需求的理解程度、开发人员编写UC的经验、以及文字描述的习惯不同，往往会导致需求文档中会存在含混性，意思不够明确，逻辑上前后矛盾等等方面的问题，从而导致开发，测试一系列的chain reaction，针对这些问题，个人觉得可以从以下几点开始着手：
1. 全程扫描需求：在接手一个测试任务之后，务必腾出时间对需求仔细阅读一遍，最好是在自己思维最清晰的时间段。也许很多同学会抱怨我手头上的事情太多了，根本没时间看，这个到时候吃亏的还是你自己。因为通过阅读，会让你思绪澎湃，自然而然发出这样的问题：这点功能没有表达清楚是做什么的？这点和那点业务之间有关系吗？有没有一些被用户认为在业务处理上是理所当然、极其平常的事情，而没有作为需求提出来？列出自己不是特别理解的内容，包括功能点清晰，但是不知道使用场景类的问题，也务必记录下来，最后集中起来找相关的需求人员逐一进行确认。这样下来，对于需求错误，需求描述不清晰之类的问题就能被彻底清理出来。其实通过这样的一个过程，我们大致的测试框架也都已经能够罗列出来了，而对于具体的实现细节的细化，则可以等到开发提供相关的设计文档后再进行补充。
2. 亲自体验项目需求：哪怕是项目需求文档，设计文档，UC文档已经非常精细了。动手画一画系统结构图，业务活动图，甚至是系统交互图，因为看的明白和画的明白，运用的是人脑的不同功能，视觉是理解的来源，动作是理解的表现。在制作的过程中，会要求你的大脑去串连所有需求片段，信息不断地做着加法，一旦需求有遗漏或是需求理解有错误，都会让你拼不出完整的各式图表，于是这个项目的各种需求问题不断的蹦发出来。当拼接的各式图表成功时，原先杂乱的大脑信息碎片开始迅速做起减法，让你倍感轻松，快乐无比。无疑，这是实打实的技术战，凭的是经验，拼的是能力
3.带着思考去评审UC，千万不要吝啬提问题：在我自己本周参与的旺铺超级市场的日常评审中，感触还是颇深的。因为需求是自己写的，对于需要和业务部门进行确认的细节基本上心里都有个谱，后来在评审的过程中，随着开发大概的一个设计思路的展开，发现原来在编写需求时还真的忽略了一个重大的细节：装修模板的订阅原来还是可以拆分成模块进行打包销售的。这个主要是由于对业务方的需求场景了解的不够深入，习惯性的会认为模板就应该是一个完整的模块，结果就出了问题。其实一些需求的细节性的问题，我们可以抓住预审的机会，通过循序诱导的方式，先谈你的理解，然后让对方进行确认你的理解是否正确，这样不光你的问题及时得到了解答，同时还能帮助需求得到完善，更是帮助自己的能力得到了提高，而且通过这种方式比较容易与这位同学建立起合作的关系，相辅相成，交流越多，越能发散出问题，越能找到像需求遗漏这样的大问题。参与需求评审，不要把自己当作一个“Listener”，而是更多的要当作一个“Asker”。
4.构建一系列的测试用例，并且问“假设类”的问题，得到这种情况将会发生的答案。然后与PD进行讨论，PD对用户的使用场景应该是最了解的，在这个讨论的过程中获取在UC中不会涉及的一些市场信息：目标用户群的状况以及用户将什么行为认为是最重要的,将一系列的假设问题放进去请他们进行确认并且阐述细节,类似”如果x发生了，产品应该做Y事”，不断的重复这个过程，经过几轮的探索之后，对于需要什么以及什么对于期望是合理的就会有了更清楚的印象。
5.把已有的产品信息用作需求的切入点，查看原有的哪些功能在新产品中不见了？ 询问关于不见的功能，以及没有他们之后使用者该怎么办？现有的产品中存在哪些问题？在原有旧的需求中遗漏了什么，并拿它和新的产品做一个比较，提出一份在新需求中可能遗漏的功能列表。我本周所接手的帐务开票日常流程的分析就属于这一类的问题：原有的开票流程不符合财务的运作规范，而且在数据的处理上也存在问题。经过与财务相关人员的讨论之后，整理出一套解决的方案。测试人员可以针对这一列的解决方案提炼出新产品的测试要点，然后思考一下这个方案是否都已经解决了用户心中永远的痛，还是说只是头痛医头，脚痛医脚。
6. 思考一下这个需求的实现方案：如果让你自己来设计，你会怎么样来考虑，然后与开发最终给出的方案比较一下是否有异曲同工之妙。我这次的日常产品定义这一块，就没有考虑到系统层面的问题。因为没有考虑到模板的接入量会很大，如果全部数据都写入我们的汇金系统，系统之间的耦合性就会很大，一旦一个系统出现问题，另一个系统也会被拖垮。这其实也是我们测试人员可以寻求突破的地方，从某种角度上讲这也是缺陷的预防。
提升质量的基础在于我们每个人都在一开始时就把正确的事情做正确，质量可以是免费的，关键就是在于事先的预防，而不是事后的查漏补缺。只有这样，那些浪费在修复bug 上的时间、金钱和精力就都可以避免，“Quality is free!”也就不会遥不可及了。通过预防产生质量，把一个项目团队的成员比作一个球队的话，PD好比就是前锋，PD把控着需求的质量，而测试好比就是后卫和守门员，要做好最后的把关，则必须首先在源头上切断病根，真正意义上的做好测试需求分析