如何理解完美测试

《完美测试》前言　

当写本书的时候，出于一种心愿，出于一种理想，取书名为《完美测试》。当真正开始写作时，又觉得是一件很困难的事。首先如何理解什么是完美的测试？然后又如何把测试工作做得完美？于是在微博上发出帖子，问大家如何理解什么是完美测试，但得到的答案也是不一样的。 

　　@张定勇_darren：值得思考的问题。我的理解，软件测试是建立对产品信心的过程，将产品引发最终用户损失的风险降低到一个“可接受”的程度。因此，“完美”只能是相对的，或者说测试永达不到完美的程度（这也是测试的魅力所在）。比如我们都知道的一个基本事实是，产品的缺陷是不可能100％消除的。 
　　@小马老矣：简单地讲，满足用户需要就可以了。从实践来看，重在测试需求分析。根据软件需求，先从功能角度，分析所有的功能点及非功能需求，并根据实际应用分级；其次是从技术角度，分析可能对功能产生影响的因素，根据风险高低分级。以此产生测试用例，并妥善安排测试计划。 
　　@Eagle_Yu：我心中“完美测试”的结果是产品推出之后，所有使用该产品的客户都认为它是一款设计合理、性能稳定并且没有什么Bug被发现的产品。（从实现完美测试角度看）我们测试人员希望产品初期PM、RD、QA、UED能通力合作：即产品经理能明确规划出用户的需求，用户体验设计能设计出符合用户操作习惯的用户界面和性能，开发人员能分析出将要做的产品技术上是否可行、减少正式开发过程中因为技术达不到而做的返工，品质保证能明确测试范围。而且，测试计划达到测试范围明确、阶段目标清楚、风险分析准确、可执行性高。测试案例达到覆盖面广、优先级权重准确、可维护性强。测试人员经验丰富、时间充裕。同时，开发部门开发能力强、产品高内聚、松耦合。 
　　@狂奔的小溪流：要做到完美测试，就是在规定的时间内通过各种测试方法把软件各个方面（如功能、性能……）的质量状态全面地体现出来。 
　　@赵枚：一个自证明的系统！当这个系统交付的时侯，已经完成了其各部分的功能验证。 

　

 　那我个人的理解又是如何呢？我认为“完美测试”是通过最有效的手段（包括方法、技术和工具）完成所有必要的测试，达到事先所要求的功能需求和非功能需求的测试覆盖率、代码的测试覆盖率, 最终能准确地给出软件产品一个完整的质量评估。因此，最有效的手段、必要的测试、测试覆盖率、准确又完整的质量评估是构成“完美测试”的关键要素。 

　　1） 最有效的手段：即以最短的时间或最少的资源来有效地完成给定的测试任务。自动化测试方法是一种有效的方法，但不一定是最有效的，需要具体问题具体分析。自动化测试方法的投入产出比（ROI）在某些测试场合低于手工测试的ROI，例如一次性的软件项目（而不是产品的系列开发），这时自动化测试方法就往往没有手工测试效率高。适合用自动化测试方法就一定要用自动化测试，该用手工测试的（如软件产品的易用性测试等）就一定用手工测试。 
　　2） 必要的测试：没有执行多余的测试任务，也没有漏掉该执行的测试任务。不需要的测试功能模块、不需要测试的特性、不需要测试的代码等能被隔离出来，它们会被排除在测试范围之外；而且能确定代码改动的影响范围，能够确定测试任务的优先级，从而根据有限的资源和时间，完成所需要执行的测试任务。如果时间非常有限，就完成优先级最高的那部分测试；如果时间稍微宽松些，就完成更多的测试任务，包括优先级较高的那部分。如果有足够的时间，那就完成所有任务的测试。 
　　3） 测试覆盖率：没有覆盖率的衡量，就不能确定测试的效果、不能确定完成了多少应有的测试任务；没有覆盖率的衡量，就很难知道测试什么时候可以结束；没有覆盖率的衡量，就难以对测试工作进行评估，甚至难以控制测试的进度。测试覆盖率包括两方面：实际用户需求验证的覆盖度和被测试代码的覆盖度。 
　　4） 准确又完整的质量评估：在完成必要的测试之后，并有能力发现测试范围中的软件缺陷，然后根据所发现的缺陷，以及前面所参与的需求评审、设计评审和代码评审的结果，针对待发布软件的各种质量特性做出准确的评估，从而能够全面地、准确地了解软件产品的质量，从而能快速地对软件产品能否发布做出正确的判断，对如何持续改进软件质量也能提出明确的举措。 
　　 
　　那么，又如何将测试工作做到完美的程度呢？不外乎从人、流程、技术等方面去考虑。人是决定的因素，又是不够稳定的因素，把每个测试工程师都打造成优秀的测试工程师，几乎不可能。但是，我们打造一支优秀的测试团队是完全可能的。即团队的每个成员都有特长，在某个方面有很强的能力、形成互补，这样，从团队来看没有弱项。基于一支优秀的测试团队，我们就能建立或引入良好的测试流程，拥有良好的测试方法、技能，最终交出一份满意的答卷。 
　　谈到测试流程，首先还得考虑整个组织的研发流程，测试流程也只能算研发流程的一部分，需要和产品开发、项目管理流程和谐共处。如果开发采用IBM的统一过程模型（RUP），测试流程可以采用迭代的W模型；如果开发采用敏捷开发，测试也得采用敏捷测试的流程。即使选用W模型或敏捷测试模型，如何细化流程、如何引入最佳实践等问题还是需要仔细考量的，针对不同的团队、不同的项目类型需要定制、剪裁软件测试流程。例如，互联网创新产品的开发，对软件缺陷有一定的容忍度，软件测试强调协作、灵活和效率，比如某些对于缺陷零容忍度的关键系统（如金融系统、交通自动控制系统等）对缺陷是零容忍度，在测试流程上要严格、规范得多。 
　　从技术上看，构建覆盖整个测试流程的自动化测试框架是重中之重。总体上看，基于自动化测试的方法能够提高测试的效率，也能更好地衡量测试覆盖率，但是自动化测试工具只是工具，很难进行测试需求的分析和设计，测试人员自身的智慧、技术能力依旧是最重要的。他们需要理解软件系统架构的设计、深刻了解软件实现的技术环节，包括如何让开发人员保证软件的可测试性，从而找到有效的测试方法，并能在技术上保证测试的顺利进行，获得高效的生产力。 

　　

   从“什么是完美测试”到“如何做到完美测试”，当然不是上面几段文字就能说清楚的，甚至难以用一本书把它说清楚。一方面，大家对“什么是完美测试”会有不同的看法；另一方面，每个方面（团队、流程、技术）要说清楚，都需要单独用一两本书完成，加起来，可能需要四五本书才能完全阐述清楚。所以，笔者对写好这本书，一直没有把握，怀着诚惶诚恐的心情，但必须迈出第一步，触发测试人员的不断思考、创新和提高。另外，由于刚到一个新单位工作，有很多事要做，心情也不够平静，对本书的写作也有较大的影响，所以到后来，不得不把如下一些已经写了几页初稿、内容很好的章节删去。 

　　让单元测试无处不在。 
　　模糊测试——距离之美。 
　　安全无底——但测试有方。 

.　　回归测试——从有到无。 
　　测试过程之美——立体之美。 
　　测试的三重境界。 
　　如何构建一流的测试团队。 
　　 
　　希望将来这些内容可以在本书再版时放进来，让大家看完本书后还怀有一丝期盼。 

　　如果说“软件测试是艺术”，多数人都不会同意，他们觉得软件测试是一项技术工作，更乐意去讨论软件测试的自动化测试技术，讨论性能测试、安全性测试的技巧。虽然Glenford J. Myres写了一本《软件测试的艺术》，但许多人仍很难从软件测试中获得艺术的欣赏。后来，又有一本叫《测试之美》的书出版了，让我们能欣赏到一些测试的技巧之美，也能获得一些真知灼见、有价值的建议或者寓有挑战性的想法，距离软件测试艺术又前进了一大步，开始领略软件测试之美。 
　　 写《完美测试》还有另外一个含义，就是想将测试之美表现出来。因为为数不少的测试人员，特别是测试领域之外的IT人，总觉得软件测试缺乏技术含量，是一份枯燥而且重复性很强的工作，测试跟“美”是没有任何关系的。为了改变这种看法，笔者想通过写一本书来展示测试之美，虽然之前已经有一本《测试之美》，觉得还不过瘾。但这本书做得也不够好，多数测试工程师因为是理工科出身、长期从事技术工作，那么仅有的几个艺术细胞早就被磨灭了，所以本书的多数作者还难以写出真正的测试之美，还需要更多的观察和更长时间的修炼。 
　　

    最后，尽管本书没有完成全部使命，但还是带领大家完成了一趟快速的艺术之旅，在软件测试领域充分地欣赏各种测试之美，包括软件测试的距离之美、空间之美、技巧之美和辩证之美，更重要的是贯穿全部测试过程的平衡之美。当然，本书更多的篇幅还是在讨论如何进行更彻底的测试，从各个方面保证软件产品的质量。这里的“完美测试”，更多倾向于前面所叙述的那部分思想，即如何全面地、完整地、充分地完成测试，将测试工作做到相对完美的程度。 

　　 

    这就是本书写作的初衷和思路，但现在仅仅跨出第一步，算是敏捷方法的前一两个迭代，还需要根据读者的反馈，不断进行修改，不断迭代，争取在不远的将来推出本书的第2版、第3版，以回馈读者。 
　 

    http://product.china-pub.com/199160#qy