功能测试培训手册

功能测试培训手册第一章测试概述1.测试发展测试是一个级其宽广的概念，并且涉及到我们生活的各个方面。作为用户，他们希望所使用的产品是可靠的、使用简单方便及符合需要的。那么，怎样才算是可靠的、符合需要的呢？最简单的方法是通过建立一些异常的环境及一些异常的操作，看产品在这些异常的环境及这些异常的操作下是否能正常工作。这就是测试。可以说，测试是随着社会化生产应运而生的，不是近代才出现的产物。但是，我们这里强调的是对软件产品的测试。软件测试是软件工程的一个范畴，或是说是软件工程的一个部分。这主要是因为测试活动是一个工程性的活动而不是简单、孤立的活动。软件测试最早可以追溯到软件开发的初期。着计算机的诞生，开始了软件开发和软件测试。于早期的计算机运行性能比较差，软件的可编程性范围比较狭窄，误主要集中在元器件的不稳定上。这一阶段还没有系统意义上的软件测试，更多的是一种调试性测试用。测试用例的设计和选取是在随机的基础上，凭借测试人员一定的经验进行的。测试更多的是为了证明系统可以运行起来。20世纪50年代后期到20世纪60年代，高级语言相继诞生并得到了广泛的应用，测试的重点逐渐转入到高级语言编写的系统中来。与以往不同的是程序的复杂性增强了。但是，由于受到硬件系统制约，软件相对而言仅占系统的次要位置。软件正确性的把握主要依赖编程人员的水平。因此，测试理论和方法在这一阶段的发展比较缓慢。20世纪70年代以后，随着计算机处理速度的飞速提高，内存和外存（主要是硬盘）容量的快速增加，软件在整个系统中的重要性变得越来越高，软件的规模越来越大，可视化编程环境、日益完善的软件分析设计方法（如面向对象的分析设计概念的产生）以及新的软件开发过程模型的提出（如螺旋模型，增量模型等）使得大型软件的开发成为可能；同时，由于软件规模和复杂度的急剧增加，软件的可靠性面临危机；软件测试在这一阶段承受了挑战。许多测试理论和测试方法相继诞生，逐渐形成一套体系。同时，这一阶段也孕育、培养出了一批出色的测试专家。随着软件产业化的发展，人们对软件的质量、成本和进度提出了较高的要求。质量的控制已经不再是传统意义上的软件测试。传统的软件测试是基于代码运行的，只有在软件开发的后期才能介入。然而，产业界的大量研究表明，设计活动引入的错误占软件过程中出现所有错误数量的50～65％。根据IBM的研究结果，假定在分析阶段发现的错误其改正成本为1个货币单位，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为6.5个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为15个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为60～100个货币单位。该比例同样也适用于发现一个错误需要的时间代价。IBM的研究结果还表明：缺陷存在放大趋势。如果在需求阶段漏过一个错误，该错误可能会引起N个设计错误。N称为放大系数。一般而言，不同阶段其N不同。经验表明，从概要设计到详细设计的错误放大系数大约为1.5，从详细设计到编码阶段的错误放大系数大约为3。图1-1表示了缺陷放大模型大致状况。图1-1缺陷放大模型图因为有上面这些内在因素的制约，就不难想象为什么很多软件产品在其开发过程中投入了大量的时间和金钱在没完没了的系统测试上，而最后得到的产品却依旧是低质量的软件。在经过了大量的失败实践之后，人们逐渐发现，一个软件的成功不可能仅仅依赖于软件开发技术是否选进。相反，软件产业化要求有一个规范的软件开发过程，一个全局的质量控制体系。一个好的软件开发过程为软件的开发指明了一条通向成功的捷径。在此要求下，许多优秀的软件开发过程，开发规范应运而生，如CMM、IPD、RUP、CMMI等。在这些过程中，测试已经不再是一个编码后才进行的活动，而是一个基于软件开发整个生命周期的质量控制活动。测试的概念也扩展到了静态测试（静态测试：不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。）范畴。软件测试的V模型说明了何时应进行测试。但是，该模型仅涉及到单元测试、集成测试、系统测试和验收测试的过程，以及这些测试与前期阶段的对应关系。其实，在开发过程中，测试始终在扮演着验证和确认的角色。如在功能性需求分析阶段，除了要考虑系统测试范围的内容外，还必须包括功能需求本身的测试。从需求考虑系统测试范围，主要是考虑系统测试应当按照功能需求的内容测试系统是否符合需求；而需求本身的测试则是测试需求的完整性、一致性、无冲突性等。软件测试V模型如图1-2所示。需求阶段缺陷概要设计阶段缺陷详细设计阶段缺陷编码阶段缺陷放大n1倍放大n2倍放大n3倍图1-2测试V模型2.什么是软件测试简单地说，如果你写了一段代码，我来帮你查看代码并找出里面的错误，这就是测试。也可以这么说：软件测试目的在于发现错误；一个好的测试用例在于发现从前未发现的错误；一个成功的测试是发现了从前未发现的错误的测试。软件测试在一定程度上是直观的，但总体上是系统的。好的测试涉及的内容远不只是将程序运行几次看它是否正常工作。对程序的彻底分析有利于你更系统、更有效地进行测试。2.1.IEEE的定义1983年，IEEE提出了软件工程标准术语，软件测试定义为：“使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”该定义明确提出了软件测试以检验是否满足需求为目标。验证和确认验证和确认验证和确认验证和确认需求分析概要设计详细设计代码审查编码单元测试计划、设计、实现执行单元测试集成测试计划、设计、实现执行集成测试系统测试计划、设计、实现执行系统测试2.2.测试在软件开发中的角色为了更好地理解测试，必须了解测试在软件开发中所扮演的角色。主要如下：测试是执行或者摸拟一个系统程序的操作。测试是为了建立一个信心，即软件是按照它所要求的方式执行的，而不会执行它不被希望的操作。测试是带着发现问题和错误的意图来分析程序的。测试是度量程序的功能和质量的。测试是评价程序和项目工作产品的属性和能力的，并且评估其是否获得了期望和可接受的结果。测试除了包括执行代码的测试，还包括监视和结构化同行评审。3.为什么要进行软件测试AirLie软件咨询中心提出了5个主要的原因，它们是：一个糟糕的测试程序可能导致任务的失败，更严重的是可能影响操作的性能和可靠性，并且可能会导致在维护维护阶段花费巨大的成本。一个好的测试程序是项目的主要成本。复杂的项目需要花费超过项目一半以上的成本在软件测试和验证上。为了使测试有效，必须提前花费适当的时间在计划和组织测试上面。一个好的程序可以极大地帮助你定义需求和设计。这有助于项目在一开始时就步入正轨，并且它对整个项目的成功有着重要的影响。一个好的测试可以迫使你在工作时必须去面对和处理问题，并且会使重新工作或修改缺陷的成本变得很低。一个好的测试不能弥补一个糟糕的软件项目，但是的确有助于发现许多问题并且至少使得你尽早知道你处在问题当中。只要是人，都会犯错。即使是一个优秀的程序员，也会犯低级性的错误。正因如此，测试是必须的。常见导致错误的根源有：缺乏有效的沟通，或者没有进行沟通。现在的软件开发已经不是一个人的事情了，往往涉及到多个人，甚至几十、几百个人。同时软件的开发还需要与不同的人，不同的部门进行沟通。如果在沟通方面表现不力，最后会导致产品无法集成，或者集成出来的产品无法满足用户需要。软件复杂度软件越复杂就越容易出错。在当今的软件开发中，对于一些没有经验的人来说，软件复杂性可能是难以理解的。图形化界面、客户／服务器和分布式的应用、数据通信、大规模关系数据库、应用程序的规模等指数般地增加了软件复杂度。面向对象技术也有可能增加软件复杂度，除非能够被很好地工程化。编程错误编程错误是程序员经常会犯的错误，包括语法错误、语义错误、拼写错误、编程规范错误。有很多错误可以通过编译器直接找到，但是遗留下来的错误就必须通过严格的测试才能发现。不断变更的需求在实际项目开发过程中，不断变更的需求是项目失败的最大杀手。用户可能不知道变更的影响，或者知道影响却还是需要进行变更。这些会引起项目重新设计，工程的重新安排，对其他项目产生影响。已完成的工作可能不得不重做或推翻。硬件需求可能也会受到影响。如果存在许多小的变更或者任何大的改动，由于项目中不同部分间可知和不可知的依赖关系，这样就会产生问题，跟踪变更的复杂性也可能引入错误。项目开发人员的积极性也会受到打击。在一些快速变化的商业环境下，不断变更的需求可能是一种残酷的现实。在此情况下，管理人员必须了解结果的风险，QA工程师和测试工程师必须适应和计划进行大规模的测试来防止不可避免的BUG出现无法控制的局面。时间的压力进度压力是每个从事软件开发人员都会碰到的问题。为了抢占市场，他们必须比竞争对手早一步把产品提供出来，于是不合理的进度安排就产生了。不断加班加点，最终导致大量错误的产生。另一方面，由于软件项目的时间安排是最难的，通常需要很多猜测性的工作。因此，当最后期限来临时，错误也就伴随发生了。缺乏文档资料代码由于人员的变动和产品的生命周期演进，在一个组织中很难保证一个人一直待在某个产品开发活动中。因此对于后面进入产品的人员来说，去读懂和维护一个没有文档的糟糕代码是一个灾难。最终的结果只会导致更多的问题。软件开发工具当产品开发依赖于某些工具时，那么这些工具本身隐藏的问题可能会导致产品的缺陷。因此，在选择软件开发工具时，尽可能选择比较成熟的产品，不要去追求技术最新的开发工具。这类工具往往本身还存在很多问题。4.测试的目的从历史的观点来看，测试关注于执行软件来获得软件在可用性方面的信心并且证明软件能够满意地工作。这引导测试把重点投入在检测和排除缺陷上。现代的软件测试持续了这个观点。同时，还认识到许多重要的缺陷主要来自于对需求和设计的误解、遗漏和不正确。国此，早期的结构化同行评审被用于帮助预防编码前的缺陷。证明、检验和预防已经成为一个良好的测试的重要目标。这一发展过程如图4-1所示。证明检测预测表明软件能够工作发现错误管理质量20世纪60年代20世纪70年代中期20世纪90年代图4-1发展过程图4.1.证明获取系统在可接受风险范围内可用的信心；尝试在非正常情况和条件下的功能和特性；保证一个工作产品是完整的并且可用或者可被集成。4.2.检测发现缺陷、错误和系统不足；定义系统的能力和局限性；提供组件、工作产品和系统的质量信息。4.3.预防澄清系统的规格和性能；提供预防或减少可能制造错误的信息；在过程中尽早检测错误；确认问题和风险，并且提前确认解决这些问题和风险的途径。5.黑盒测试5.1.什么是黑盒测试黑盒测试（BlackBoxTesting）又叫功能测试（FunctionalTesting）。这是因为在黑盒测试中，主要关注于被测软件的功能实现，而不是内部逻辑。黑盒测试是与白盒测试截然不同的测试概念，也是在软件测试中使用得最早、最广泛的一类测试。在黑盒测试中，被测对象的内部结构、动作情况对测试人员是不可见的。测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。就像对一台自动售货机，为了验证其能否自动售出货物，你可以指定需要购买的物品，塞入钱币，然后观测售货机能否输出正确的货物并找出正确的零钱。在这个过程中，你不需要关注自动售货机是如何判定钱币数额，如何选择货物，如何找出零钱等内部操作。这是白盒测试关注的范围，黑盒测试关注的是结果。图5-1是黑盒测试的一个示意图。黑盒测试试图发现以下类型的错误：功能错误或遗漏；界面错误；数据结构或外部数据库访问错误；性能错误；初始化和终止错误；