软件测试人员培训版ppt课件.ppt
软件测试培训教程,产品研发部,软件测试理论基础,定义：软件测试就是为了发现错误而审查软件文档、检查软件数据和执行程序代码的过程。软件测试应该是对软件形成过程的文档,数据以及程序进行的测试,而不仅是对程序进行的测试。60%以上的软件错误并不是程序错误,而是分析和设计的错误,提倡软件全生命周期测试的理念。,软件测试定义,软件测试的目的,想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。 测试能够证明软件的功能和性能与需求说明相符合。实施测试收集到的测试结果数据为可靠性分析提供了依据测试不能表明软件中不存在错误，它只能说明软件中存在错误,所有的软件测试都应追溯到用户需求。应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。完全测试是不可能的，测试需要终止。测试无法显示软件潜在的缺陷。也就是说测试只能证明软件存在错误而不能证明软件没有错误。,软件测试的原则,软件测试的对象,根据软件定义，软件包括程序，数据和文档，所以软件测试并不仅仅是程序测试，软件测试应该贯穿整个软件生命周期中。 需求分析，概要设计，详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明，概要设计规格说明，详细设计规格说明以及源程序。,软件测试的对象,了解软件工程，熟悉软件测试过程和标准，熟悉配置管理技术和工具能够编制测试计划、设计测试用例、编写Bug报告和测试总结报告、使用测试工具、开发测试脚本熟练使用Windows或Unix或Linux操作系统了解业务领域（ERP、OA、）熟练掌握至少一种以上的测试工具，如TestDirector、QTP、LoadRunner、Robot,企业需要怎样的测试人才？,一般的，我们将软件测试活动分为以下几类：黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手动测试、自动测试,软件测试分类,黑盒测试又叫功能测试、数据驱动测试或基于需求规格说明书的功能测试。该测试类别注重于测试软件的功能性需求。测试工程师无需了解程序代码的内部构造，完全模拟软件产品的最终端用户使用该软件，检查软件产品是否达到了用户的需求。如图1-4所示为黑盒测试实例图。黑盒测试能更好的从用户角度来考察被测系统的功能性需求实现情况。,软件测试分类黑盒测试,白盒测试又称结构测试、逻辑驱动测试或基于程序代码内部构成的测试。白盒测试需要测试工程师深入考查程序代码的内部结构、逻辑设计等。就像前面的例子，我们拆开手机，观察手机电路板的设计，液晶屏的构成等。对于白盒测试工程师来说，软件产品的内部结构是敞开的。如图1-5所示是白盒测试示例图。,软件测试分类白盒测试,灰盒测试介于白盒和黑盒测试之间。灰盒测试一方面考虑程序代码的功能性表现，另一方面，又需要考虑程序代码的内部结构。通俗地讲，灰盒测试就是白加黑。像我们的性能测试，自动化功能测试就是采用了灰盒测试的方法。图1-6是灰盒测试的示例图。,软件测试分类灰盒测试,定义：静态的、不执行被测对象程序代码而寻找缺陷的过程。在进行静态测试时可采用一些代码走查工具，如QAC+、C+Test等。,软件测试分类静态测试,实际的执行被测对象的程序代码，输入实现设计好的测试用例，检查程序代码运行得到的结果与测试用力中设计的预期结果之间是否有差异，判定实际结果与预测结果是否一致。动态测试有四部分组成：设计测试用例、执行测试用例、分析比较输出结果、输出测试报告。动态测试有三种主要方法：黑盒测试、白盒测试和灰盒测试,软件测试分类动态测试,它是测试人员设计测试用例并执行测试用例，然后根据实际的结果去和预期的结果相比较并记录测试结果，最终输出测试报告的测试活动。可充分发挥测试工程师的主观能动性，将其智力体现在测试工作中，能发现许多的缺陷，但同时又有一定的局限性和单调枯燥性。,软件测试分类手动测试,定义利用测试工具，模拟用户业务使用流程，让他们自动运行来查找缺陷。优点 快、广泛、可重复性工作缺点只可检查比较主要的问题，如崩溃、死机，无法发现一般的日常错误。编写脚本工作量 也很大，有时会超过手动测试时间。我们要根据实际情况选择或者不选择测试工具，选择使用何种测试工具，不能为了实用工具而可以的去使用工具。,软件测试分类自动化测试,软件测试流程,软件测试虽然是软件生存周期的一个独立阶段，但测试工作却渗透到从分析、设计直到编程的各个阶段中（1-7是软件测试所经阶段的一般流程）。需求测试、单元测试、集成测试、系统测试、性能测试、用户测试、回归测试,软件测试流程图,又称模块测试，就是对程序代码中最小的涉及模块单元进行测试。 在单元测试中我们主要采用静态测试与动态测试相结合的办法。单元测试要求需要几年的代码编写经验，并且要十分熟悉当前的被测系统，以及该系统是否与其他系统的接口关联情况。单元测试在编码阶段占据非常重要的地位。 可以降低编码的错误率，提高编码质量,单元测试,又称组装测试，是将软件产品各个模块组装起来，检查接口是否存在问题，以及组装后的整体功能、性能表现。一般可采用非增式集成方法、增式集成方法（自底向上集成、自顶向下集成、组合方式集成）等策略进行测试，利用一黑盒测试为主，白盒测试为辅的测试方法进行测试。主要解决各个组成但源代码是否符合开发规范、接口是否存在问题，整体功能有无错误、界面是否符合设计规范、性能是否满足用户需求等。,集成测试,回归测试是经过一段时间以后再回过头来对以前修复过的Bug重新进行测试，看该Bug是否会重新出现。有些时候可采用自动化测试工具来进行回归测试，如利用QTP一般情况下，都由测试工程师手动的执行一千的测试用例。来检查用例通过情况。,回归测试,软件测试工作流程,1、人员构成 测试主管、测试组长、环境保障人员、配置管理员、测试设计人员、测试工程师,测试部门组织结构,项目管理技术人员要求掌握一般的项目管理知识，如配置管理、版本控制、评审管理、项目实施与进度控制等。 资源构成,测试部门组织结构,测试用例编写,测试工作流程,测试开展阶段搭建测试环境测试组长，可根据说明说中的软件产品运行环境配置要求搭建。测试环境最好与开发环境分开文档引入工作日报、功能测试报告、性能测试报告等模板执行测试根据项目的Bug管理流程，经过多次的版本迭代，完成测试工作。,测试工作流程,测试输出阶段测试计划测试方案测试用例测试工程师的工作日报功能测试报告性能测试报告,测试工作流程,软件测试用例设计方法,什么是测试用例,测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。,测试用例包含要素,每个具体测试用例都将包括下列详细信息：编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果（含判断标准）、环境要求、备注等。具体可以参考建行测试用例模板,黑盒测试案例设计技术,测试用例设计：将软件测试的行为活动，作为一个科学化的组织归纳。测试用例：设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的执行结果。因为我们不可能进行穷举测试，为了节省时间和资源、提供测试效率，必须从数量极大的可用测试数据精心挑选出具有代表性或者特殊性的测试数据来进行测试。,测试测试用例的好处,在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。测试用例的使用令软件测试的实施重点突出、目的明确。在软件版本更新后只修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。功能测试模块的通用化和复用化使软件易于开发，而测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。,常见黑盒测试用例设计方法,等价类划分法边界值分析法错误推测法因果图法判定表驱动法正交试验设计法功能图法场景法,等价类表,设计测试用例,软件缺陷,什么是软件缺陷,符合下面 5 条规则之一的问题称为软件缺陷：1、软件未达到产品说明书标明的功能。2、软件出现产品说明书指明不会出现的错误。 （如果软件含有产品说明中根本没有存在的功能，这是缺陷）3、软件功能超出产品说明书指明的范围。4、软件未达到产品说明书未指出但应达到的目标。 （产品说明书虽然没有提到，但是按照常理应该达到的功能）5、软件测试人员或用户认为软件难以理解，不易使用，运行速度缓慢等问题。,缺陷的生命周期,简单周期： 测试员找到并登记软件缺陷，软件缺陷移交到程序员=程序员修复软件缺陷，软件缺陷移交到测试员=测试员确定软件缺陷被修复，测试员关闭软件缺陷。,缺陷的生命周期,复杂周期：发现缺陷（测试员发现并登记缺陷，软件缺陷转到程序员）=软件缺陷移交到项目管理员=（以不修复形式解决）项目管理员认为软件缺陷不重要，软件缺陷移交到测试员=重新激活缺陷（测试员不同意，找出通用失败案例，软件缺陷移交到项目管理员）=项目管理员同意缺陷需要修复，缺陷转给程序员=以修复形式解决（测试员确认软件缺陷得以修复，测试员关闭软件缺陷）=缺陷关闭,报告缺陷的要点,复杂周期：发现了软件缺陷，需要记录下来，不但要记录结果，同时需要详细描述发现的步骤，以备程序员重现问题，并解决它。要求报告写的清楚明了和准确。有时利用截屏技术把当时的情况保存成图片，可以达到一图胜千言的效果。,缺陷的严重性分类,A类致命性： 不能完全满足系统要求，基本业务功能未实现系统崩溃、不稳定或挂起等导致系统不能继续运行、导致系统出现不可预料的严重错误的问题。,缺陷的严重性分类,B 类 严重错误：严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装 或重新启动不属于更正办法）。使系统不稳定、破坏数据、产生错误结果，部分功能无法执行 。,缺陷的严重性分类,C 类 一般性错误： 1、界面错误。 2、非重要功能无法正确执行， 实现不正确， 实现不完整，但不影响功能 3、非严重性产生错误结果，但不影响一起功能。 4、正确性不受影响，但系统性能和响应时间受到影响。,缺陷的严重性分类,D 类 轻微错误： 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能， 或对最终结果影响有限的问题。,缺陷的严重性分类,E 类 测试建议： 不影响系统运行，对系统的可用性等提示的建议性的问题。 例如： 1、系统各个位置初始值的建议。 2、流程优化建议等等。,缺陷分析报告,可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据,软件测试的技巧,需求测试回归测试错误处理测试支持手册的测试系统兼容测试控制性测试并行测试,功能测试技巧,目标程序修改后，确保功能的正确性如何使用重新测试应用程序中没有改变的部分例子重新执行以前的测试用例什么时间使用当新的程序有可能影响老的功能的时候,回归测试,目标检验当使用适当的参数和数据时，需要的信息可以在两个系统中正确的交换如何使用文件和数据被用来在多系统之间传递。例子典型的由一个系统到另一个系统的数据交换程序。什么时候使用当两个应用程序之间的参数有可能发生变化的时候,兼容性测试,测试计划,定义测试目标开发测试矩阵软件模型结构特性批量测试的阶段和用例为在线系统作概念上的测试脚本软件测试矩阵定义测试管理测试计划的一般性信息定义测试里程碑定义管理上的检查点书写测试计划,建立测试计划,正式评审中的角色缓和剂（SQA）读者记录者作者检测员正式评审发现的缺陷应包含的信息起因类型分类级别,评审测试计划,计划和组织通篇的讲解（可选）个人准备评审会议修订和反复,评审流程,手册，回归，功能点测试一致性测试（授权）功能点测试（完整性）功能点测试（审计，追踪）覆盖性的测试（测试的连续性）压力测试（服务水平）一致性测试（安全性）依照预先定义的测试方法功能点测试（正确性）支持手册的测试（易用性）检查（可维护性）灾难性的测试（可携带性）功能和回归测试（耦合性）一致性的测试（性能）操作性的测试（易用性）,典型测试类型,测试方法测试用例的概念是简单的建立有效的测试用例是复杂的设计测试文件测试用例应当包含合法的和非法的输入每一个动作只进行一次关键操作输入测试数据分析结果尝试将测试文件违反程序的规则进行输入容量测试的测试工具以大信息量的数据进行输入这是一个昂贵的测试，应根据需要来选择在线系统需要做压力测试,建议测试方法,测试总结,目标表示出目前项目的实际状况明确什么是测试做的工作，什么是不作的工作。给出系统的操作性能的评价明确什么时候系统可以进行产品化的工作关注点测试报告只有真正需要的时候才有用，需要配合市场和管理测试的信息是不充分的（对于评价一个项目来说）测试状况并不能真实的反应个人的状况,测试报告,报告目前的软件状态功能/测试矩阵功能测试的状态报告，侧重点分析关于功能的工作时间轴期望发现 VS 实际发现的缺陷比没有发现的缺陷和改正的缺陷的差距按照类型分类，没有改正的缺陷的平均值缺陷分类报告测试活动报告,测试报告,各个阶段的项目测试总结报告继承性测试报告系统测试报告确认测试报告,最终的报告汇总,
