软件测试基本理论和方法

1CSIA软件测试工程师培训软件测试基础理论与方法2引言软件测试是保证软件质量的重要技术手段–测试理论和测试方法–测试过程及测试的管理–测试工具3测试的原则原则一：穷尽测试是不可能的原则二：测试工作具有创造性，但很困难原则三：测试旨在防止错误的发生原则四：测试是有风险的原则五：测试需要有计划性原则六：测试需要有独立性4软件测试技术基础6.1、测试的目的6.2、测试的原则6.3、测试的层次结构6.4、测试阶段6.5、测试方法6.6、测试种类6.7、测试自动化6.8、小结51、测试的目的•测试是通过运行程序来发现错误的过程•测试可以说明软件存在错误，但不能说明它不存在错误•目的：用相对少的测试尽可能多地找到程序中的缺陷62、测试的原则•一个好的测试用例具有较高的发现过去未被发现过的错误的概率，而不应只表明程序运行正常•自己不能测试自己编写的程序•对期望结果的描述是每个测试用例的必要组成部分•杜绝不能重现或匆忙的测试•既要编写使用有效输入条件的测试用例，也要编写使用非法输入条件的测试用例•深入细致地审查测试结果72、测试的原则•如果一段程序中发现的缺陷数量增加，则意味着有更多未被发现的缺陷的可能性也在增加•让最优秀的人员去完成测试•保证软件可测试性是软件设计的一个重要目标•不要为了测试方便而修改程序•测试工作必须在任务建立之初就确定目标83、测试的层次结构类型方法阶段举例：•功能•算法•正向•反向•可用性•边界验收测试确认测试集成测试单元测试白盒黑盒自顶向下自底向上模拟用户操作94、测试阶段•单元测试•组装测试•确认测试•验收测试104.1、单元测试•单元测试的目的是在一个隔离环境中对独立的软件模块进行测试以发现其中的缺陷。114.1、单元测试124.2、集成测试•集成测试的目的是当模块组装后查找模块间接口的错误134.3、确认测试•确认测试的目的是确定软件是否满足软件需求规格说明所提出的所有需求144.4、验收测试•用户参与的确认测试155、测试方法•黑盒测试方法•白盒测试方法•自顶向下方法•自底向上方法•模拟用户操作测试方法165.1、黑盒测试方法•黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用。176.5.2、白盒测试方法•白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。186.5.3、自顶向下或自底向上方法•依据模块在模块层次中的位置，对模块组装并测试，属于增量组装测试方法。196.5.4、模拟用户操作测试方法•着重对那些用户可能发现的错误进行测试及修改工作206.6、测试类型•功能测试•算法测试•正向测试•反向测试•可使用性测试•边界测试•平台测试•负载/强度测试216.7、自动化测试•6.7.1、属性及优点•6.7.2、主要分类•6.7.3、实现类型•6.7.4、注意的问题226.7.1、属性及优点•速度。例如手工测试Windows计算器，假定平均每5秒钟执行一个测试案例，那么数千个案例需要数小时的时间。而自动化能够以成千上万倍的速度来执行。•效率。测试工具减少了执行测试案例的时间，有更多的时间进行测试计划考虑新的测试用例。•准确度和精确度。尝试执行百个测试用例之后，注意力就会分散，开始犯错误。测试工具每次执行同样的测试，并毫无差错地检查结果。•坚持不懈。测试工具和自动化永远不会累倒或半途而废。236.7.2、主要分类•回放类型自动测试工具•代码分析器：复杂度等•覆盖分析器•内存分析器•强度测试工具•web测试工具•其它——测试用例管理、文档管理、bugreporting、配置管理246.7.3、实现类型•宏录制和回放。最基本的测试自动化类型时录制第一次执行测试用例时的键盘和鼠标操作，然后在需要重新执行时回放•可编程的宏编写回放系统遵守的简单指令•完全可编程的自动测试工具提供编程语言256.7.4、注意的问题•软件变更•人眼和直觉是不可替代的•验证难以实现•容易过分依赖自动化•不要花费太多时间使用达不到测试软件目的的测试工具和自动化•编写宏、开发工具都属于开发工作，应该遵守要求程序员遵守的相同标准和规范•某些工具是侵入式的，可能导致测试的软件不正常失败。266.8、小结测试的目的测试的原则测试的层次结构测试阶段测试方法测试种类测试自动化27软件测试理解1软件测试活动2测试过程3测试方法4测试类型5测试策略6小结281软件测试活动•测试是从大量的测试用例中选择有限的测试用例发现软件中的大部分缺陷的一种技术•好的测试用例的4个特性：1.检测软件质量的有效性，是否能发现缺陷，或至少可能发现缺陷；2.可仿效的测试用例可以测试很多内容，因而减少测试用例的数量；3.经济性，测试用例的执行、分析和调试是否经济4.测试用例的可修改性，每次软件修改后对测试用例的维护成本如何实现？？29测试活动计划编制测试计划：标志测试条件（确定测试什么）和测试的优先级设计设计测试用例（确定怎么测试）开发测试开发（设计脚本、数据等）执行执行测试用例将测试结果与期望结果进行比较评估30测试活动1—计划阶段内容：人员、进度、资源。测试条件取决于被测试验证的项目或事件。测试条件是被测环境的描述。可以用多种方式描述：如简单的语言，表格项形式或类似于流图的图表形式；标识测试条件的活动最好与开发活动（即V模型左边的活动）并行开展31测试活动2—设计阶段内容：设计测试用例、预期结果测试用例（testcase）是按一定顺序执行的与测试目标（testobject,测试理由或目的）相关的一系列测试。测试用例设计将产生许多测试所包括的运行测试的有关信息（如环境要求，也称为先决条件）、输入值、期望结果。期望输出包括应输出或建立的内容，应修改或更新或应删除的内容。期望输出集可以是一个很大的集合。32测试活动测试用例：POS1036先决条件：作为数据输入员注册到定单系统显示的主菜单数据库系统必须含有标准数据集合确保系统中没有其他活跃的新定单活动步骤输入期望输出测试条件1建立用任何一个标准的订单项建立一个新订单，设置订单数为100显示订单确认信息VB10VB202确认订单打印具有正确细目购置订单VB103打印新订单报表打印的新订单报表就是新创建的订单VB10VB234取消订单打印正确的取消购置订单信息VB85打印新订单报表无打印订单输出VB833测试活动3—开发阶段开发测试用例包括:准备测试脚本、测试输入、测试数据以及期望输出。测试脚本（testscript）是具有正规语法的数据和指令的集合，在测试执行自动工具使用中，通常以文件形式保存；必须先完成测试用例的先决条件（precondition），然后再执行测试。测试用例可能要求专门的硬件或软件，如网络环境或打印机等；期望输出可以组成文件形式用于自动工具。对于手动测试，期望输出仅仅只是简单地记录在手工测试过程或脚本中。对于自动测试，其期望输出比设置用于手工测试的期望输出复杂得多。在自动工具中要求每项内容都要拼写正确，而在手工测试中要求没这么严格。测试开发的任何工作可以提前进行（相对V模型左边的活动进行），以后可以节省时间。34测试活动4—执行阶段执行测试用例对于手动测试：测试者按事先准备好的手工过程进行测试，测试者输入数据、观察输出、记录发现的问题。对于自动测试：可能只需要启动测试工具，并告诉工具执行哪些测试用例；测试执行只能在软件开发完成后进行，即V模型右边的活动。35测试活动5—评估阶段将测试结果与期望输出进行比较应该对每次测试的实际输出进行分析研究，判断软件功能是否正确。验证可以是测试者的主观判断，也可以是将实际输出与期望输出进行严格准确的比较。信息比较，如可以在执行测试时进行显示屏幕上的信息，另一些输出比较，如修改数据库记录，只能在测试执行结束后进行。自动测试一般结合了信息比较的两种方法。36软件测试与软件工程模型V模型介绍扩展：左边的每一部分还包括评审，也是测试任务。需求验收测试系统测试集成测试单元测试概设详设编码测试测试测试测试37测试设计基于需求分析•缺陷预防：是指各种错误遗留到后续开发阶段之前，运用各种技术和过程来发现和避免这些错误。•最有效的测试工作应该开始于需求；•对于每一条需求，如果可以设计出一个过程来执行所测试的功能，若输出结果是可以预先知道的，并且能够通过编程或者人工方法加以验证，则称该需求是可测试的；•测试人员需要彻底了解产品，只有这样他们才能设计出更出色和更全面的测试计划，测试设计和测试过程和测试用例。38测试人员及早介入•避免在项目生命周期中的后续阶段对产品的功能行为不理解•了解应用程序的哪些方面对最终用户而言是最关键以及哪些元素的风险最大•测试重点放在应用程序中最重要的部分，避免对不经常使用的部分过度测试而对重要的部分又测试不充分。39RequirementsspecificationRequirementsverificationFunctionaldesignspecificationFunctionaldesignverificationCodeandspecmodificationSystemandacceptancevalidationCodeandspecmodificationFunctionvalidationCodeandspecmodificationIntegrationvalidationProductsimulationUsabilitytestCodeCodeverificationCodeandspecmodificationUnitvalidation12InternaldesignspecificationInternaldesignverification4597108113640测试的生命周期在软件开发生命周期中，软件是通过迭代来不断加以完善的。在这种环境中，对于每个作为测试目标的工作版本，测试的生命周期还都必须具有一种迭代方法。41测试的生命周期42测试活动的信息流被测模块设软系统客计件其他户信需元素参息求与被测模块被测模块单元测试单元测试单元测试集成测试确认测试系统测试验收测试已经测试过的模块已集成的软件已确认的软件可交付的软件43测试阶段的信息流测试阶段的输入信息有两类：软件配置：这是测试的对象，包括需求说明书设计说明书被测的源程序等。测试配置：包括测试计划测试步骤测试用例（测试数据）具体实施测试的测试程序测试工具等44RUP中定义测试的目的在于：Findinganddocumentingdefectsinsoftwarequality.Generallyadvisingaboutperceivedsoftwarequality.Provingthevalidityoftheassumptionsmadeindesignandrequirementspecificationsthroughconcretedemonstration.Validatingthesoftwareproductfunctionsasdesigned.Validatingthattherequirementshavebeenimplementedappropriately.45RUPActivities活动46RUP-2001Artifacts工件472测试过程2.1单元测试2.2集成测试2.3系统测试2.4验收测试482.1单元测试目的：分别完成每个单元的测试任务，以确保每个模块能正常工作。单元测试-RUP单元测试在迭代的早期实施，侧重于核实软件的最小可测试元素。单元测试通常应用于实施模型中的构件，核实是否已覆盖控制流和数据流，以及构件是否可以按照预期工作。这些期望值建立在构件参与执行用例的方式的基础上，参与方式可参见该用例的序列图。实施员在单元的开发期间执行单元测试。实施工作流程对单元测试作出了详细描述。49单元测试的考虑算法和逻辑模块接口数据结构（全局和局部）边界条件