【精美ppt课件】《软件的质量保证与测试》课件9－16章

在本单元中，您将学习：定义验收测试确定验收测试的阶段,目标,验收测试介绍,验收测试是一种正式测试，执行验收测试是为了确定软件是否符合客户在 SDLC 需求阶段定义的验收标准。 验收测试的概念并不仅限于软件开发。 在涉及客户和供应商的每个事务中都有验收测试和规划的实例。,验收测试的类型,最终用户或客户可以执行验收测试以验证是否接受产品。 验收测试在测试之后和实现阶段之前执行。 验收测试的类型有两类：Alpha 测试：Alpha 测试是在开发团队附近的内部站点进行的模拟或实际运行测试。 此类型的测试有助于评估软件以确定软件是否符合需求分析阶段中指定的所有需求。Beta 测试：Beta 测试涉及在远离开发人员的站点或在客户站点进行软件的运行测试。,验收测试中的阶段,验收测试的各个阶段包括：定义验收测试标准开发验收测试计划执行验收测试计划开发验收决定,执行验收测试,定义验收标准：客户定义验收标准时，还应定义该软件的验收需求。这些验收需求可分为以下类型：功能性需求性能需求界面需求非功能性需求开发验收计划：在此阶段，应定义验收活动的目标以及达到这些目标的过程。应在项目的运营环境和生命周期中，根据软件的目标用途来定义验收目标。,执行验收测试（续）,执行验收计划：在这两种测试技术中进行选择时应考虑以下因素：软件临界状态软件的大小开发软件时涉及的资源开发软件的时间段验收计划的执行包括以下活动：确定需要测试的软件元素指定软件验收测试期间的接受或拒绝标准在最终交付之前审核软件确定将在产品开发中执行的测试类型,执行验收测试（续）,开发验收决定：应作出的一些常见验收决定如下所示：客户在进行下一个活动之前需要接受软件中的所需更改。客户可在首次审核中对软件进行一些更改和接受更改，并在下次审核中执行其他更改。软件验收活动可以继续，可以同时对软件进行更改并接受更改。软件无需任何更改，因此可以执行软件验收。,执行验收测试（续）,问题陈述：考虑一个场景： Web Systems Inc. 是一家基于佛罗里达的质量流程公司。该公司为国际客户提供高质量软件解决方案。该公司在客户端/服务器应用程序、基于 Internet 的应用程序、软件测试和质量保证方面有丰富的经验。Web Systems 需要验收由第三方供应商 CompuSolutions Ltd. 开发的软件应用程序 Emart，以应对电子市场的持续发展。该软件已开发完毕，并且软件的某些部分将本地安装，其他部分将在外地安装。Web Systems 已决定了一些策略或活动，将根据这些策略或活动来接受软件。说明对该软件执行验收测试所需的步骤。,执行验收测试（续）,解决方案：,活动：执行验收测试,问题陈述：创建验收标准,活动：执行验收测试（续）,解决方案：,在本单元中，您学习了：验收测试是一种正式测试，执行验收测试是为了确定软件是否符合客户在 SDLC 需求阶段定义的验收标准。验收测试的类型有两类：Alpha 测试Beta 测试验收测试的各个阶段包括：定义验收测试标准开发验收测试计划执行验收测试计划开发验收决定,小结,符合验收标准包括以下步骤：在开发期间提早检测软件缺陷准备适当的测试设施在软件开发期间提早考虑客户需求要使软件验收符合所需标准，客户需要担当以下职责：开发软件需求和验收标准确定验收的过渡产品和最终产品及其验收标准规划执行每个验收活动的方式和人员根据作出的验收决定来规划提供信息的资源安排足够的时间以在最终验收审核之前检查产品,小结（续）,审核验收测试计划在过渡期针对过渡软件产品的验收标准对其进行核准在软件最终交付期间执行正式验收测试对每个软件产品作出验收决定定义验收标准时，客户必须：充分了解软件。对软件功能感到满意。了解添加新功能以增强软件的后果。验收计划中包括以下组件：项目描述客户职责标准和过程的使用验收标准描述,小结（续）,要执行的验收计划包括以下活动：确定需要测试的软件元素指定软件验收测试期间的接受或拒绝标准在最终交付之前审核软件确定将在产品开发中执行的测试类型当整个软件达到其预定义验收标准时，将作出验收决定。,小结（续）,一些常见验收决定包括：客户在执行下一个活动之前接受软件中的所需更改。客户在首次审核中接受软件中的一些更改，并在下次审核中执行其他更改。继续软件验收活动，并行执行和接受软件中的更改。软件无需任何更改，因此可以执行软件验收。,小结（续）,在本单元中，您将学习：了解缺陷发现步骤了解用于跟踪缺陷的策略了解缺陷管理流程,目标,缺陷发现,缺陷是指软件产品或流程中所有不合规格的地方。 缺陷发现流程使您能够确定缺陷。 该流程包括揭示缺陷并且将缺陷通知开发团队。 然后，开发团队将确认缺陷是否有效并且修正这些缺陷。 测试员验证并在最后关闭缺陷。 以下是跟踪软件产品缺陷的工作流。,缺陷发现（续）,下图显示了跟踪软件产品缺陷的工作流。,缺陷生命周期,了解缺陷发现策略,发现缺陷并且将其通知开发团队是测试中不可缺少的部分。检测缺陷的方法主要分为 3 大类：静态技术：包括执行手动中间检查以检查正在开发的产品的质量。静态技术的示例包括审核、走查和检查。动态技术：指执行软件测试以查找缺陷的过程。 操作技术：包括最终用户在操作级别测试系统并发现在测试流程中未识别的缺陷。,分类缺陷,可以通过以下方式对缺陷分类： 基于功能根据安全性：高严重性中严重性低严重性根据优先级：高优先级中等优先级低优先级,确定缺陷,承认缺陷在软件测试环境中很常见。 测试团队确定软件项目中的缺陷并且将确定的缺陷通知开发团队。 这是必须的，因为测试员确定的缺陷可能源自于技术限制或者为支持软件所需功能而添加的功能部件。,小组讨论：设计测试环境,讨论在以下哪个 SDLC 阶段带入缺陷的百分比最高。,小组讨论：设计测试环境（续）,解决方案：大多数缺陷发生在 SDLC 的早期阶段，尤其是在需求阶段。统计数据显示在 SDLC 期间带入缺陷的百分比如下： 需求和功能： 50%实现功能： 10%结构缺陷： 10%实现： 9%数据： 4%集成： 7%实时和操作系统： 6%测试定义或执行缺陷： 4%所以，尽可能在 SDLC 的较早阶段发现缺陷是很重要的。发现缺陷越晚，修正的成本就越高。因此，所有负责的团队成员都应该定期审核设计和需求。,缺陷管理流程,缺陷管理流程包括使用缺陷跟踪工具进行缺陷记录、缺陷报告和缺陷跟踪。 缺陷记录用于描述和量化任何与测试需求偏离的情况，而缺陷报告用于报告测试状态。 缺陷跟踪工具可用于确定缺陷。,在测试流程的每个阶段确定并记录缺陷。 记录缺陷的主要目的是为开发过程中被确定为测试一部分的所有差异创建完整的记录。记录缺陷的主要目的有 4 个：为了纠正缺陷为了报告应用程序状态为了收集状态信息，这些信息将可供以后应用程序使用以开发缺陷解决方案为了进一步改进软件开发过程,缺陷记录,缺陷报告,必须将缺陷报告给开发团队以使其能够确定并修正缺陷。缺陷报告描述在完整软件功能以及文档产品中出现的缺陷。缺陷报告必须向测试团队以及负责修正缺陷的团队提供缺陷的完整信息。 报告需要提供缺陷的历史信息和修正计划并关闭缺陷。,缺陷报告（续）,缺陷报告通常包括以下信息：缺陷的唯一标识符缺陷名称和类型缺陷的源（例如测试用例）缺陷的严重性分配给缺陷的优先级缺陷的当前状态（带有一张提供缺陷状态历史信息的表）缺陷的详细描述实现的平台和操作系统当缺陷发生时执行的步骤缺陷位置，带有截屏负责测试的人和负责修正缺陷的人,缺陷报告（续）,缺陷报告的常见类型包括：缺陷密度报告：这些报告将缺陷数量显示为带有一个或两个默认参数（例如缺陷安全性和缺陷优先级）的函数。 缺陷潜伏期报告：这些报告是一种分布报告类型，它显示缺陷在某种状态的持续时间。 缺陷趋势报告：这些报告以时间函数的方式通过状态显示缺陷数量。这些报告可以是累计或者非累计报告。,缺陷报告（续）,有效的缺陷报告应该：减少从开发团队返回的缺陷数量。提高修正缺陷的速度。提高测试活动的可信性。加强测试和开发团队之间的团队合作。,在本单元中，您学习了：缺陷是指产品或流程中的所有与规范不一致的情况。缺陷发现过程包括解释缺陷、使缺陷引起开发团队的重视、确定缺陷有效。查找缺陷的常用技术有以下 3 种：静态技术动态技术操作技术根据其严重性，缺陷可分类为： 高严重性中严重性低严重性,小结,根据其优先级，缺陷可被分类为： 高优先级中等优先级低优先级开发团队必须确认测试团队报告的缺陷是否有效。用于确定缺陷原因的常用策略包括：修改软件代码以捕捉缺陷或未知情况发生时的环境状态。实现代码以验证缺陷是否存在。分析相同缺陷的各种报告。在测试流程的每个阶段确定并记录缺陷。,小结（续）,记录缺陷的主要目的有 4 个：为了纠正缺陷报告应用程序状态为了收集状态信息，这些信息将可供以后应用程序使用以开发缺陷解决方案为了进一步改进软件开发过程缺陷报告是用于表示缺陷测试影响的报告。缺陷报告有 3 种类型：缺陷密度报告缺陷潜伏期报告缺陷趋势报告制作一份优秀报告的关键是向开发人员提供尽可能多的信息以复制缺陷。,小结（续）,缺陷报告通常包括以下信息：缺陷的唯一标识符缺陷名称和类型缺陷的源（例如测试用例）缺陷的严重性分配给缺陷的优先级缺陷的当前状态（带有一张提供缺陷状态历史信息的表）缺陷的详细描述当缺陷发生时执行的步骤缺陷的位置负责测试的人员负责修正缺陷的人员,小结（续）,在本单元中，您将学习：说明缺陷跟踪流程了解缺陷更正流程说明缺陷预防活动,目标,缺陷跟踪,缺陷跟踪是观察并记录所有缺陷以确保正确修订这些缺陷的过程。 缺陷跟踪工具是带有缺陷报告数据库以及帮助执行以下任务的前端的工具：归档新缺陷报告更改状态以反映纠正缺陷的工作进度生成关于缺陷数据的报告,缺陷跟踪（续）,选择缺陷跟踪工具时需要考虑以下因素：系统架构操作系统后端数据库Web 服务器编程语言用户友好拥有成本,活动：确定缺陷类型,问题陈述：请考虑以下场景：Don 的团队测试 网站，发现左边的滚动条和上部框架未被启用。这导致试图阅读显示在页面上的服务列表的用户会遇到问题。Jim 测试了会计软件系统的“应支付账款”、“应收账款”和“分类账”模块并对其进行了审批。但是，当在 Windows 2000 上集成并运行所有这些模块时，系统无法运行。虽然保存了“应支付账款”的汇总记录，更改不会反映在“应收账款”或“分类账”模块中。总体来说，软件性能发生故障。,活动：确定缺陷类型（续）,Lara 的团队测试了为 Loren Horner 开发的电子邮件应用程序， Loren Horner 是一位法国籍商务人士，他每天收到超过 5,000 封电子邮件。Lara 知道他熟悉英式英语。然而，该需求未在规范文档中提及。因此，网站的内容以美式英语显示。虽然 Loren 对该产品不完全满意，但是他同意验收该产品。Greg 的团队收到了为一家服饰零售商店 Shopmagic Inc. 设计的软件应用程序。系统具有 3 个集成系统：购买系统、库存系统和安全系统。首先，对这 3 个系统进行了单独测试并对正确性进行了审批。然而，当它们被集成在一起并且再次被测试时，购买系统不接受输入值以及在库存系统中输入的其他文本信息。对于上述场景，确定缺陷类型并根据优先级将其分类。,活动：确定缺陷类型（续）,解决方案：这些测试场景中的缺陷如下：这是一个中优先级的轻微的导航缺陷。该缺陷与用于导航的滚动条有关。该缺陷是次要的，因为它并未大规模影响网页的工作。解决该缺陷的优先级为中等。这是高优先级的主要功能缺陷。该缺陷与应收账款、应付账款和分类账系统的功能有关。该缺陷很重要，因为一个系统的故障将导致其他两个系统不可用。解决该缺陷的优先级为高。,活动：确定缺陷类型（续）,这是低优先级的轻微缺陷。缺陷类型与界面无关，不是导航缺陷也不是功能缺陷。它是语言相关的问题并且与应用程序的运行无关。该缺陷的优先级为低。这是高优先级的主要界面缺陷。该缺陷是设计/开发级别的界面缺陷，是重要缺陷。该缺陷是阻止/停止显示缺陷，因为缺少系统之间交换的信息会影响构建系统的目的。因此，它是高优先级缺陷。,缺陷更正,确定了缺陷后，需要对其进行修正和测试。 修正可能会引起对软件其他部分的波动性影响并且可能会引入新的缺陷。 缺陷可能无法像预期那样被修正。因此，需要具备有系统化的缺陷更正方法。,测试缺陷更正,测试缺陷纠正流程所采用的策略如下：验证：它是系统或组件的评估过程，用于确定给定开发阶段的产品是否满足该阶段开始时定好的条件。 确认：它是在 SDLC 末尾评估软件以确保软件产品符合软件需求的过程。 回归测试：它是在修正后重新测试软件以确保软件中没有新的或遗漏的缺陷。,缺陷预防,缺陷预防注重于确定缺陷原因并预防缺陷的发生。 它包括分析过去发生的缺陷并采取特定的步骤以预防这些类型的缺陷在未来再次发生。 确定的缺陷可以是指在过去承担的项目中遇到的或者在当前项目的早期阶段发生的缺陷。,缺陷预防活动,缺陷预防活动是一个用于传播在项目中了解到的注意事项的机制。 缺陷预防流程的步骤如下：分析一段时间的缺陷趋势对已识别缺陷执行根本原因分析。建议预防措施以确保缺陷不会重复发生,活动：分类缺陷,问题陈述： 在线银行业务应用程序的测试团队测试了“账户汇总”模块并找到了以下缺陷：用户名与规范不匹配。当输入数字作为用户名的一部分时，未在屏幕上显示错误消息。将数字接受为用户名的一部分。当最终用户输入少于 8 个字符的密码时，未显示错误消息并且密码被设置。“打印对账单”选项卡不可用。“详细汇总”选项卡中“详细”的写法不正确。 工具栏中“刷新”选项未被禁用。Bob 是在线银行业务项目的测试员之一，他需要对为“账户汇总”模块确定的缺陷指定优先级。根据优先级对缺陷进行分类并且为测试团队提供帮助。,活动：分类缺陷（续）,解决方案：这是中优先级的次要的功能缺陷。这是次要的功能缺陷，因为它不会影响模块的运行。但是，该缺陷需要尽早被纠正，因为它可能会引发数据库级别的问题。这是中优先级的次要的功能缺陷。这是次要的功能缺陷，因为它不会影响模块的运行。但是，该缺陷需要尽早被纠正，因为它可能会引发数据库级别的问题。,在本单元中，您学习了：市场上有各种可用于缺陷跟踪的工具。但是，选择正确的工具是十分关键的。需要对已修正的缺陷进行测试以确保缺陷被消除。验证是系统或组件的评估过程，用于确定给定开发阶段的产品是否满足该阶段开始时强加的条件。验证包括审核需求、设计和关联文档以确保根据缺陷报告对其进行了正确更新。确认是在 SDLC 末尾评估软件以确保软件产品符合软件需求的过程。,小结,确认包括在更正过程结束时评估修正代码和相关文档以确保与软件需求一致。回归测试是在修正后重新测试软件以确保软件中没有新的或遗漏的缺陷。,小结（续）,在本单元中，您将学习：定义测试指标了解指标在测试时的重要性确定测试指标的类型确定测试指标对管理决策的影响,目标,测试指标,指标是衡量标准，对于测试生命周期非常重要。 测试指标用于衡量软件测试的有效性。 指标是了解流程是否在控制中并且流程的执行是否符合期望的最佳方法。,测试指标的需求,测试指标用于规划对软件产品执行的测试数量和测试类型。 测试指标用于评估各种组件，如对软件项目指定组件执行的测试覆盖。组织中使用测试指标的各种用途包括：评估基础状态报告标志操作确定风险,收集测试指标,使用正确的框架收集测试指标对于测试指标收集计划的成功非常重要。收集测试指标时，必须确保以下方面：专用资源的分配自动化工具的使用测试跟踪流程应侧重于测试目标,测试指标的类型,在软件开发项目中，可以收集各种类型的测试指标。大部分项目需要衡量质量、资源、时间和大小。 为了分析产品或流程的有效性，将针对组织创建的特定标准或基准来评估这些质量衡量的结果。,特定于测试的指标,特定于测试的常见指标包括：缺陷消除效率（DRE）：该指标在软件交付之前衡量缺陷。它为软件开发过程的项目级别以及流程级别带来了很多好处。缺陷密度（DD）：该指标衡量被衡量的软件实体大小中的所有已发现缺陷数。 平均故障时间（MTTF）：该指标衡量可靠性并计算出现第一次故障之前的平均时间。它提供对软件项目运行测试期间从一个故障到下一个故障的平均时间。,复杂性衡量,复杂度指标是一个组件级别的设计指标。 组件级别的设计指标有助于侧重于组件级别的软件内部特性。复杂度指标有各种用途。 这些指标提供诸如软件系统可靠性和可维护性的重要信息。,大小衡量,大小是另一个基础指标。 收集的大部分指标都按大小指标标准化。这提供软件项目的大小独立分析。计算软件大小的方式有以下几种： 代码行（LOC）：它用于衡量程序的大小。它们是用于对软件项目进行编码的行数。功能点（FP）：它用于通过量化为用户提供的功能来衡量软件大小。 标记：它们用来获取软件项目中的各种指标，如：软件词汇、长度和大小。,缺陷衡量,缺陷衡量是组织通常比较的另一个指标。 缺陷衡量是与缺陷数或类型关联的值，如“缺陷/1000 代码行”或“缺陷/100 功能点”。缺陷度量从开发生命周期的各个阶段收集。 缺陷衡量有助于评估各个流程。这些衡量通常用作其他指标的输入。,产品衡量,产品指标是用于软件产品的指标。 软件产品独立于流程，实现的目的是开发产品。,使用测试指标制定质量决策,指标可量化流程或产品的特征。 测试指标可以是可直接观察的数量，或是从一个或多个可直接观察的数量获得的值。 测试指标可作为管理层决策中所需的精确评估的基础。 测试指标为管理层提供了规划其当前和未来测试项目的基础。,测试指标对管理决策的影响,指标可用于量化地表现出软件流程或软件产品的不同方面。如果不使用指标，则评估软件解决方案的有效性将十分困难。 指标与四个管理功能相关，如下所示：规划组织控制改进,测试指标对管理决策的影响（续）,测试指标有助于管理层对以下因素进行跟踪和作出决策：进度工作量成本审核结果错误报告需求稳定性大小稳定性计算机资源利用率培训,活动：收集测试指标,问题陈述：WestSide 在线银行业务应用程序的测试已经结束。WestSide 银行在测试末尾测试了应用程序并发现了一些缺陷。测试团队修复了所有缺陷，并且 WestSide 银行接受了软件。Newways Solutions 的管理层现在想要分析 WestSide 项目的 QA 和测试流程的效率。此信息将用于确定团队需要改进的方面，能进一步提高 QA 及测试团队的效率。为了提供用于分析的数据，测试经理想要计算 DRE 和 DD。下表列出了整个开发周期中确定的缺陷。,活动：收集测试指标（续）,下表列出了整个开发周期中确定的缺陷。软件总大小为 483 个 FP。 计算项目的 DRE 和 DD 并帮助管理层分析数据。,活动：收集测试指标（续）,解决方案：,在本单元中，您学习了：指标是了解流程是否在控制中并且流程的执行是否符合期望的最佳方法。为了管理测试活动，需要有关测试流程和测试产品的可衡量数据。以下是收集测试指标时需要重点考虑的一些因素：专用资源的分配自动化工具的使用侧重于有关测试目标的测试跟踪流程有各种特定于测试活动的指标。以下是一些常用的特定于测试的指标：缺陷消除效率（DRE）缺陷密度 (DD)平均故障前时间 (MTTF),小结,复杂性衡量用于衡量开发、维护或使用软件产品时涉及的资源。大小指标作为使大部分测试指标标准化的基础。计算软件大小的方式有许多种。例如，代码行、功能点和标记可用于计算程序的大小。缺陷衡量是与缺陷数或类型关联的值，如“缺陷/1000 代码行”或“缺陷/100 功能点”。产品指标是用于软件产品的指标。例如，性能、可靠性、故障、可用性和质量。,小结（续）,测试指标使管理层能够对以下因素进行跟踪和作出决策：进度工作量成本审核结果错误报告大小和需求稳定性计算机资源利用率培训,小结（续）,在本单元中，您将学习：了解测试报告工具了解测试报告标准说明分析数据的各种统计工具的角色说明分析统计数据的各种方法,目标,创建测试报告,在测试软件应用程序的有效性和可靠性后，软件测试员需要为结果创建统一的报告。 此过程称为测试报告。 软件应用程序的开发人员和测试员使用测试报告来跟踪软件应用程序的状态。 测试报告包括将测试执行结果报告给相关的项目干系人。 以后会分析该报告以衡量测试流程的有效性以及软件的质量。 高级管理者使用该测试报告来确定开发过程中的漏洞并开始流程改进。,测试报告工具,可以采用特定的软件工具来使软件测试员有效地生成测试报告。 这些测试报告工具提供以下功能：生成测试报告格式提供测试结果的统计输出跟踪在测试过程中找到的缺陷记录测试结果测试报告工具的示例包括：分析工具数据库工具缺陷跟踪工具测试报告格式,测试报告标准,设计测试报告时，需要清楚地提供以下信息：在测试过程中检测到的缺陷的详细信息进行的测试类型检测到缺陷的环境和条件测试范围已测试模块的实际和期望结果之间的不一致测试报告示例：,测试报告标准（续）,问题陈述： 思考一个执行计算器功能的软件应用程序 AutoCal。已经对该应用程序执行了测试以验证应用程序的“加”和“减”功能。但是，在测试中发现了以下错误：进行两位数减法运算时，给出的结果是这两个数字的乘积。较小的数字减去较大的数字时，不显示负数结果。进行两个三位数的加法运算时，给出的结果是第一个数字的平方。 为以上相同情况开发测试报告。,测试报告标准（续）,解决方案：,测试报告中的统计分析,可以使用统计分析工具以有意义的方式表示并分析从测试报告中获得的结果。 在此部分中，将讨论以下统计分析工具：帕累托图直方图因果关系图散布图检查表运行图控制图,统计分析工具,帕累托图：帕累托图是一个图形工具，它用于对引起问题的原因从最重要到最不重要进行评级。 通过使用帕累托图分析数据，软件测试员能够：根据关键问题的重要性和发生频率对其进行分类，以此来关注软件项目中的关键问题。为问题或引起问题的原因指定优先级以有效地解决问题。重视对软件应用程序进行改进的效果。通过在对软件应用程序进行改进之前或之后开发帕累托图来达到这个目的。,统计分析工具（续）,直方图：直方图是可量化数据集的柱状图，它显示每种数据集类型的发生频率。 如果有充足的数据可用，则可以使用直方图来确定以下内容：数据集范围数据集含义数据集标准偏离频率曲线的偏斜,统计分析工具（续）,散布图：散布图通过在二维图上显示数据点来展示两个变量之间的关系。 散布图提供下列信息：被测试变量之间的关系强度变量之间的因果关系 - 某变量对另一个变量的影响变量之间的相互关系 - 正、负或零,统计分析工具（续）,因果关系图：因果关系图是以有条理的方式形象化、确定和分类问题的可能原因的有用工具。 它也称为“鱼骨图”或“石川图”。仔细分析因果关系图使团队成员能够：确定导致问题的最低级别的根本原因。确定需要立即对其采取措施的问题的关键原因。,统计分析工具（续）,检查表：检查表是以简便、系统和以及有组织的方式记录流程数据的工具。 检查表存储事件在指定时间段内的出现次数。 检查表是执行以下活动的最有效工具：获取评估问题或流程的对象以及准确数据。跟踪事件频率。为统计工具提供数据。使用检查表的好处包括：因为数据可被快速收集而提高了有效性。系统地、有组织地收集相关数据。简单地记录数据。,统计分析工具（续）,运行图：运行图以年代顺序表示示例数据，以显示关键趋势上的转变。 它是直线图的一种，用于检测一段时间内数据中的模式。运行图使您能够：在一段时间内跟踪事件或观察。监视流程性能。跟踪流程中的更改。,统计分析工具（续）,控制图：控制图有助于确定针对现有的控制限制，流程产生的数据值分布是否随时间而稳定。 它确定流程是否“受控制”或需要进行调整。控制图的目标是监视从统计角度上来说稳定的、具有重复活动的流程中的变量。 观察到的变量具有两种类型，即随机和唯一。 这些图用于评估各种变化以确定所需的修改。,分析统计数据,探索性分析：探索性分析是一种数据分析类型，它使用图形和描述性统计技术来执行以下任务：最大程度地观察数据集研究数据集结构抽取与数据集中变量相关的信息测试底层假设突出显示非常规情况,分析统计数据（续）,集群分析：集群分析将一组观察分类成两个或更多互斥组。 集群分析的目的是将系统组织观察分组，其中组的成员共享公共属性。 集群分析在以下情况中非常有效：确定子类中的共同特征，例如项目未按时完成和超出预算。确定多元关系，例如预算和日程安排关系,分析统计数据（续）,回归分析：回归分析是用于评估两个变量之间关系的统计技术。 它提供以下信息：显示两个变量之间关系的图形两个变量之间的本质关系，例如，如果知道一个变量的值，则可以推断出另一个变量的值两个变量之间的相关性回归分析用于：确定两个变量之间的因果关系。 根据多个变量确定项目性能。,活动：测试报告中的统计分析,问题陈述：在在线银行业务应用程序的验收测试阶段，发现了 40 个错误。Newways Solutions 的管理层希望制作一份关于开发人员常犯的错误类型的报告。此数据将在以后被用于为开发人员设计适当的培训。为了准备该报告，在线银行业务应用程序的测试经理收集了以下信息。创建帕累托图并确定发生最频繁的错误类型及其错误优先级。,活动：测试报告中的统计分析（续）,解决方案：要创建帕累托图，您需要为所有类别计算累积百分比。下表列出了帕累托图的计算数据。,活动：测试报告中的统计分析（续）,根据以上数据构建帕累托图。,活动：测试报告中的统计分析（续）,在对以上帕累托图进行分析后，您可以得出以下结论：文档中与界面相关的错误的数量最多。 文档中与功能相关的错误的数量最少。这表示虽然与功能相关的错误发生得最频繁，但不需要为它们指定高优先级。,在本单元中，您学习了：测试报告是指将测试执行结果报告给相关的项目干系人的任务。测试报告工具能够帮助软件测试员有效地生成报告。以下是测试报告工具的几种类型：分析工具数据库工具缺陷跟踪工具测试报告格式统计分析工具用于有效地表示并分析从测试报告中获得的数据。以下列出了一些统计分析工具：帕累托图直方图因果关系图,小结,散布图检查表运行图控制图可以使用以下工具来分析统计数据：探索性分析集群分析回归分析,小结（续）,在本单元中，您将学习：定义风险管理了解风险管理流程中的各个步骤了解测试中的各种风险类型确定测试中的风险确定方法了解软件测试中的风险分析方法了解如何防止确定风险,目标,风险管理介绍,大多数人在生活中会面临一个接一个的不确定因素。 如果您不计划应对这些不确定因素，它们可能就会伤害您。 规划应对不确定事件减少了它们的影响。 软件开发团队也可以计划应对可能影响项目的开发和测试的不确定事件。,风险管理流程,任何项目都可能会遇到以下不确定因素：成本上升日程安排延误质量问题风险管理是确定、控制和最小化可能影响项目的风险的过程。 风险管理流程包含以下三个主要步骤：风险确定风险分析风险缓解,确定软件测试中的风险,为了避免出现与测试流程相关的风险，首先需要确定这些风险。 风险确定指确定可能影响项目的风险的过程。 确定过程还包括确定项目测试流程并记录关联风险的特性。,对风险进行分类,风险大致可被分类为以下几种类型：软件风险业务风险过早发布的风险测试风险,分类风险（续）,软件风险：与被开发软件应用程序相关的风险称为软件风险。 这些风险可能导致编码错误，从而影响应用程序的功能。 以下是导致软件风险的因素：开发人员的技能雇员心情不愉快项目目标定义不足,分类风险（续）,业务风险：业务风险威胁正在开发的软件的可行性。 它们经常会使项目和软件产品暴露在各种威胁下。以下例举了一些业务风险示例：市场风险技术更改产品竞争管理风险预算风险,分类风险（续）,过早发布的风险：在某些情况下，公司会在软件应用程序完成之前就将其发布到市场。 以下列出了过早发布的风险的原因：超出了项目完成的最后期限。另一个公司正准备发布具有竞争力的产品。与类似软件产品相关的风险称为过早发布的风险。,分类风险（续）,测试风险：某些潜在风险可能会影响测试软件应用程序的流程。这样的风险被称为测试风险。 以下列出了可能导致测试风险的因素：预算不足测试环境不兼容工具和过程不恰当测试过程的重用性很低使用新技术测试员没有经验,确定风险的工具和技术,核对表：核对表有助于确定项目及其测试流程中的潜在风险。 核对表包含您可能在任何项目及其测试流程中碰到的最有可能发生的风险列表。 风险确定核对表包括特定的类别，例如：产品大小业务影响开发环境使用的技术员工特征客户特征,确定风险的工具和技术（续）,访谈：在该方法中，通过联系与项目直接或间接相关的人员来收集信息。 与测试过类似项目或在类似测试环境中工作的软件测试员进行访谈，这有助于收集相关信息。 它们可提供有关在测试流程中发生的风险类型的信息。 会谈过程中使用的调查问卷对确定风险也扮演很重要的角色。,确定风险的工具和技术（续）,调查问卷：调查问卷包含与特定风险相关的问题列表。 这组问题有助于确定与测试流程和项目相关的主要风险。 将根据在之前项目和测试流程中碰到的风险来定期更新调查问卷中的问题列表。,确定风险的工具和技术（续）,头脑风暴：头脑风暴用于在短时间内想出大量创意。它用于以下情况：希望整个组参加。希望拥有大量选项或创意。希望拥有直觉的、富有创造力或超乎寻常的创意。,确定风险的工具和技术（续）,观察：观察是用于收集与项目及其测试流程相关的风险信息的有效方法。 观察以下内容有助于软件测试员确定以下风险：软件开发的阶段类似项目的各个阶段类似项目的测试流程,确定风险的工具和技术（续）,审核：对项目进行频繁且定期的审核以确定类似项目及其测试流程中的潜在风险。 可以审查项目的下列部分以收集相关信息：项目计划流程开发的软件,软件测试中的风险分析,确定项目及其测试流程中的风险后，将分析风险。 不确定性和损失是风险的两个特性。 风险分析用于评估以下因素：确定风险的发生可能性确定风险对项目及其测试流程的影响风险分析包括确定以下组件： 风险可能性风险影响风险因素,风险可能性,风险分析流程的第一个步骤是确定项目及其测试流程发生确定风险的可能性。 以下是发生项目风险的可能性：很低低中高很高,风险影响,风险影响是风险对项目及其测试流程的影响程度。 项目和项目测试过程中发生风险的可能性有助于确定影响。 此外，还要量化并等级化风险对项目以下部分的影响：成本日程质量,风险因素,风险因素用于根据为项目确定的其他风险来指定某个风险的优先级。 根据发生项目风险的可能性和影响确定风险因子。风险因素计算为：风险因素 = 风险可能性 * 风险影响在风险分析中，每个任务的结果都将被记录到风险分析表中。 该表提供以下信息：风险描述发生可能性风险影响风险因素,风险缓解,风险缓解是一个规划过程。 该流程定义防止风险的以下备选方法并有以下好处：避免确定风险的发生。减少风险对项目的影响。风险缓解策略可能会启用以下 3 个风险管理措施：风险避免风险监视应急计划,风险避免,项目团队执行以下任务以避免风险的出现：在项目开始时规划风险管理活动。 确定项目中的潜在风险。这还包括项目测试流程中的风险。为在项目及其测试流程中确定风险指定优先级。准备用于管理风险的计划。该计划称为风险管理计划。,活动：风险避免,问题陈述：Janes Technologies 是一家软件产品和解决方案供应商。来自俄罗斯的一家运输公司希望 Janes Technologies 开发一个“日程安排遵循”系统。系统将帮助运输公司跟踪其车辆、监视特定位置的延迟并计划偏离。 “日程安排遵循”系统还将帮助运输公司确定与日程安排偏离相关的问题区域，从而使其可以调整日程安排或更改路径。Janes Technologies 的开发团队对客户指定的平台不太熟悉。因此，开发团队需要接受针对该平台的密集培训。,活动：风险避免（续）,在此项目过程中，期望开发团队管理大量数据。团队没有管理如此大量数据的经验。系统还需要使用此数据来生成与运输服务日程的延迟或遵循相关的各种 MIS 报告。 客户对 IT 不熟悉，因此无法通过一轮会议来清晰指定需求。客户需要在整个国家中跨洲实现系统。与系统相关的数据是保密的，因为它可能会为竞争者提供优势。项目必须在开始后的 6 个月内完成。 确定项目的潜在风险并准备所需的风险管理计划。,活动：风险避免（续）,解决方案：,风险监视,风险监视的主要目标如下：如果预计的风险真的发生，那么评估该风险确保正确实现为特定风险定义的风险避免步骤收集可供以后进行风险分析的信息,应急计划,应急计划指开发一个计划以指示在指定风险发生时用于确保项目成功的备选策略。应急应急计划划用于监视风险并调用预定义的响应。 开发应急计划包括以下步骤：确定需要具有应急计划的风险并对其指定优先级。如果可能，将类似风险归在一起以减少规划量。考虑可能的操作并选择最恰当的操作。此外，考虑标准以确定需对其采取的操作。,应急计划（续）,将操作分为以下几类：在事件之前执行在发生故障后执行在事件不发生时需要列出风险的可能原因。创建当风险事件出现时需要遵循的文档。考虑培训相关人员以使每个人都了解当风险发生时应该怎么做。,在本单元中，您学习了：风险是可能发生的事件。另外，类似事件的出现可能会对项目产生有害影响。风险管理是确定、控制和消除或最小化可能影响系统资源的风险的过程。以下列出了各种类型的风险：软件风险业务风险测试风险过早发布的风险风险确定是指确定风险的过程。,小结,以下列出了一些用于确定风险的方法：核对表会谈调查问卷头脑风暴审核观察风险分析指评估发生确定风险的可能性及其对项目的影响。风险缓解是考虑避免风险的备用方法的计划过程。应急计划指管理规划的开发。该计划确定在指定风险发生时用于确保项目成功的备选策略。,小结（续）,在本单元中，您将学习：了解预估测试工作量过程了解测试工作量预估中的挑战了解测试工作量预估技术,目标,测试工作量预估,在测试流程开始之前，公司需要评估测试项目所需的工作量。 该评估有助于根据小时数确定资源以及软件测试所需的技能。测试经理负责创建测试工作量预估。 准确的评估能够确保在软件测试过程中恰当地使用被评估的资源。,测试工作量预估步骤,步骤 1：确定要测试的组件测试工作量预估的第一步是确定软件程序中需要被测试的组件。软件程序具有一些公共组件，例如 GUI 控件、屏幕、函数和报告。步骤 2：确定测试策略要预估项目的测试工作量，需确定项目所需的测试策略。确定测试策略包括确定需要对组件进行测试的质量特征。,测试工作量预估步骤（续）,步骤 3：确定要执行的任务指定测试策略后，下一个步骤是确定需要在软件测试过程中执行的任务。这些任务可以是一次性任务或重复的活动。 步骤 4：根据复杂性计算软件大小为了预估测试工作量，需要估算软件大小。该大小取决于软件复杂性。应用程序的复杂性具有以下级别：低复杂度中等复杂度高复杂度,测试工作量预估步骤（续）,步骤 5：预估测试工作量在收集的步骤 1 到步骤 4 的输入基础上，估算项目的测试工作量。测试工作量通常基于测试所需的持续时间、小时、基础结构、资源和专门技术。步骤 6：根据输入准备测试计划测试工作量预估是准备测试计划的前期工作。 步骤 7：在项目结束时验证估算在完成项目并且准备将其交付给测试团队后，将重新验证测试工作量预估过程中进行的假设。,活动：测试工作量预估,基于测试工作量预估的活动。,测试工作量预估挑战,测试经理需要预期测试团队可能在实际测试阶段中碰到的挑战。 以下列出了这些挑战：不清楚应用程序的复杂度对测试工作量的预估不准确项目交付延迟缺乏对测试进行正确的规划缺乏测试专门技术选择了错误的测试数据缺乏对测试环境设置的正确计划,测试工作量预估技术,准确的测试工作量预估对于软件的实际测试来说非常重要。 如果测试工作量预估不准确，则可能影响测试的测试日程安排和质量。 实际测试工作量预估清楚地描述了要测试的组件、采取的策略、执行的任务以及测试所需的工作量。 行业中经常使用并且广为接受的技术有以下几种：功能点分析（FPA）测试点分析（TPA）构造性成本模型（COCOMO）,FPA,功能点（FP）评估技术是用于预估测试工作量的最流行的技术。 该技术将系统划分为小组件以理解并分析它们。FPA 技术将上述信息分类为以下 5 个主要组成部分： 外部输入（EI）外部输出（EO）外部查询（EQ）内部逻辑文件（ILF）外部接口文件（EIF）,FPA（续）,使用 FP 技术的优势如下：它独立于语言和技术。因此，该技术可用于预估任何类型的项目。它还可用于预估使用原型和螺旋模型的项目的工作量、成本和日程安排，因为类似项目的用户和需求不确定。 当预计将会在项目中间进行更改时，它有助于进行项目预估。,COCOMO 模型,COCOMO 模型是预估项目成本的技术。 原始 COCOMO 模型于 1981 年开发。该模型假设软件产品可归为以下 3 类：基本系统：指比较简单的项目，它们由一些有经验的团队成员在稳定的开发环境中开发，并且没有很紧迫的最后期限限制。 半独立系统：指介于基本系统和嵌入式系统之间的中间项目。嵌入式系统：指复杂项目，由大型团队在复杂的硬件开发环境中开发，并带有紧迫的最后期限限制。,TPA,TPA 是用于预估测试工作量大小的另一个技术。 它基于的原理是，测试工作量预估需要以下 3 个元素：需要测试的软件应用程序的大小确定的测试策略，它有助于计算测试工作量执行指定的测试工作量所需的时间TPA 技术的优势如下：TPA 独立于分析员。 TPA 测试验收测试和系统测试范围内的质量特征。,活动：测试工作量预估技术,测试您对测试工作量预估技术掌握程度的小测验。,在本单元中，您学习了：测试工作量预估是开始软件测试之前的关键阶段。测试工作量预估不准确可能会影响测试阶段和项目交付。软件工作量预估包含以下活动：确定需要测试的组件开发测试计划策略确定要执行的任务计算应用程序的大小进行测试工作量预估准备测试计划在项目结束时验证估算参数,小结,测试经理可能会在对项目进行所需的测试工作量预估时遇到以下挑战：测试员无法理解应用程序中的复杂功能项目交付延迟缺乏对测试进行正确的规划为项目提供了错误的手册脚本未考虑测试员的专门技术选择了错误的测试数据缺乏对测试环境设置的正确规划最常用的测试工作量预估技术包括：功能点分析（FPA）测试点分析（TPA）构造性成本模型（COCOMO）,小结（续）,在本单元中，您将学习：定义测试管理了解测试管理中涉及的活动说明软件测试经理特质,目标,软件测试管理,在竞争越来越激烈的 IT 世界中，软件测试领域正在进化为多阶段过程，其中测试与软件开发并行进行。 因此