测试计划 边值分析 测试用例审查流程 测试计划 测试计划是描述软件测试领域和活动的详细文档。它概述了测试策略、目标、测试计划、所需资源（人力资源、软件和硬件）、测试估计和测试可交付成果。 测试计划是每个软件测试的基础。它是最重要的活动，可确保按适当顺序提供所有计划活动列表。 测试计划是一个模板，用于将软件测试活动作为由测试经理完全监视和控制的定义过程进行。测试计划由测试主管 (60%)、测试经理 (20%) 和测试工程师 (20%) 制定。 测试计划的类型 测试计划分为三种类型 主测试计划 阶段测试计划 测试类型特定的测试计划 主测试计划 主测试计划是一种具有多个测试级别的测试计划。它包括一个完整的测试策略。 阶段测试计划 阶段测试计划是一种测试计划，用于解决测试策略的任何一个阶段。例如，工具列表、测试用例列表等。 具体测试计划 为安全测试、负载测试、性能测试等主要类型的测试设计的特定测试计划。换句话说，为非功能测试设计的特定测试计划。 如何编写测试计划 制定测试计划是测试管理过程中最关键的任务。根据 IEEE 829，按照以下七个步骤来准备测试计划。 首先，分析产品结构和架构。 现在设计测试策略。 定义所有测试目标。 定义测试区域。 定义所有可用资源。 以适当的方式安排所有活动。 确定所有测试可交付成果。 测试计划组件或属性 测试计划由各个部分组成，这有助于我们推导出整个测试活动。 目标：由模块、特性、测试数据等信息组成，表明应用的目的，即应用行为、目标等。 范围：它包含需要使用相应应用程序进行测试的信息。Scope可以进一步分为两部分： 在适用范围 范围外 范围内：这些是需要严格（详细）测试的模块。 Out scope：这些是不需要严格测试的模块。 例如，假设我们有一个Gmail应用程序测试，其中的功能进行测试，如撰写邮件，发送邮件，收件箱，草稿和其无法测试功能，如帮助，等等，这意味着在规划阶段，我们将根据产品中给出的时间限制决定是否必须检查哪些功能。 现在我们如何决定不测试哪些功能？ 我们可以从以下几个方面决定不测试哪些功能： 正如我们在上面看到的，帮助功能不会被测试，因为它是由技术作家编写和开发的，并由另一位专业作家审查。 假设我们有一个具有P、Q、R 和 S特性的应用程序，需要根据需求进行开发。但在这里，S 功能已经被其他一些公司设计和使用。因此，开发团队将从该公司购买 S，并与 P、Q 和 R 等附加功能集成。 现在，我们不会对 S 特性进行功能测试，因为它已经被实时使用了。但是我们将在 P、Q、R 和 S 特性之间进行集成测试和系统测试，因为新特性可能无法与 S 特性一起正常工作，如下图所示： 假设在产品的第一个版本中，已开发的元素，例如P、Q、R、S、T、U、V、W.....X、Y、Z。现在客户将在第二次发布中提供改进产品的新特性的要求，新特性是A1、B2、C3、D4和E5。 之后，我们将测试计划中的范围写为 范围 待测试的功能 A1、B2、C3、D4、E5（新功能） P、Q、R、S、T 无需测试的功能 W.....X, Y, Z 因此，我们会先检查新特征，然后继续旧特征，因为添加新特征后可能会受到影响，这意味着它也会影响影响区域，因此我们将对P，Q进行一轮回归测试, R..., T 特征。 测试方法： 它包含有关在应用程序上执行不同类型测试（如功能测试、集成测试和系统测试等）的信息。在此，我们将决定进行何种类型的测试；我们将根据应用程序要求执行各种功能。在这里，我们还应该定义我们将在测试方法中使用什么样的测试，以便每个人，例如管理人员、开发团队和测试团队都可以轻松理解，因为测试术语是不标准的。 例如，对于Adobe Photoshop等独立应用程序，我们将执行以下类型的测试： 冒烟测试→功能测试→集成测试→系统测试→临时测试→兼容性测试→回归测试→全球化测试→可访问性测试→可用性测试→可靠性测试→恢复测试→安装或卸载测试 假设我们必须测试https://www.jeevansathi.com/应用程序，因此我们将执行以下类型的测试： 烟雾测试 功能测试 集成测试 系统测试 临时测试 兼容性测试 回归测试 全球化测试 可访问性测试 可用性测试 性能测试 方法 此属性用于描述应用程序在执行测试时的流程并供将来参考。 我们可以借助以下几个方面来了解应用程序的流程： 通过编写高级场景 通过编写流程图 通过编写高级场景 例如，假设我们正在测试Gmail应用程序： 登录 Gmail- 发送电子邮件并检查它是否在“已发送邮件”页面中 登录到 ……。 …… …… 我们写这篇文章是为了描述测试产品必须采用的方法，并且仅用于我们将编写高级场景的关键功能。在这里，我们不会专注于涵盖所有场景，因为可以由特定的测试工程师决定必须测试或不测试哪些功能。 通过编写流程图 编写流程图是因为编写高级场景需要一些时间，如下图所示： 我们正在创建流程图以实现以下好处，例如： 覆盖很容易 合并很容易 该方法可以分为以下两个部分： 从上到下的方法 自下而上的方法 假设 它包含有关在测试过程中可能发生的问题或问题的信息，当我们编写测试计划时，将做出有保证的假设，如资源和技术等。 风险 这些是我们在当前版本中测试应用程序时需要面对的挑战，如果假设失败，则涉及风险。 例如，申请的效果，发布日期被推迟。 缓解计划或应急计划 这是一个准备克服风险或问题的后备计划。 让我们一起看一个假设、风险和应急计划的例子，因为它们相互关联。 在任何产品中，我们都会假设所有 3 名测试工程师都会在那里，直到产品完成，并且每个人都被分配了不同的模块，例如 P、Q 和 R。在这种特定情况下，风险可能如果测试工程师在项目中途离开了项目。 因此，应急计划将为每个功能分配一个主要和从属所有者。因此，如果一名测试工程师离开，下级所有者将接管该特定功能并帮助新的测试工程师，以便他/她了解分配给他们的模块。 产品本身的假设、风险和缓解或应急计划始终是精确的。各类风险如下： 客户视角 资源方法 技术意见 角色与责任 它定义了需要由整个测试团队执行的完整任务。当一个大项目来临时，测试经理就是编写测试计划的人。如果有 3-4 个小项目，那么测试经理会将每个项目分配给每个测试主管。然后，测试负责人为他/她分配的项目编写测试计划。 让我们看一个示例，我们将在其中了解测试经理、测试主管和测试工程师的角色和职责。 Role: Test Manager Name: Ryan 责任： 准备（编写和审查）测试计划 与开发团队召开会议 与测试团队召开会议 与客户举行会议 每月举行一次站立会议 签署发行说明 处理升级和问题 角色： Test Lead Name: Harvey 责任： 准备（编写和审查）测试计划 举行每日站立会议 审查和批准测试用例 准备 RTM 和报告 分配模块 处理时间表 角色：测试工程师 1、测试工程师 2 和测试工程师 3 姓名：Louis, Jessica, Donna 分配模块：M1、M2 和 M3 责任： 编写、审查和执行由测试用例和测试场景组成的测试文档 阅读、审查、理解和分析需求 编写应用程序的流程 执行测试用例 各个模块的RTM 缺陷跟踪 准备测试执行报告并将其传达给测试主管。 日程 它用于解释工作的时间，需要完成哪些工作，或者该属性涵盖了每个测试活动应该何时开始和结束？并且还提到了特定日期的每个测试活动的确切数据。 因此，如下图所示，对于特定活动，将有开始日期和结束日期；对于特定构建的每次测试，都会有指定的日期。 例如 编写测试用例 执行过程 缺陷跟踪 它通常在工具的帮助下完成，因为我们无法手动跟踪每个错误的状态。我们还评论了我们如何传达在测试过程中发现的错误并将其发送回开发团队以及开发团队将如何回复。这里我们也提到了高、中、低等bug的优先级。 以下是缺陷跟踪的各个方面： 技术来跟踪bug ...... ...... ...... ...... 错误跟踪工具 我们可以评论工具的名称，我们将使用它来跟踪错误。一些最常用的错误跟踪工具是 Jira、Bugzilla、Mantis 和 Trac 等。< Severity 严重 程度可能如下： Blocker or showstopper ..... ..... （用测试计划中的例子说明） 例如，模块有缺陷；我们无法进一步测试其他模块，因为如果错误被阻止，我们可以继续检查其他模块。 严重 ………… ..（在测试计划中举例说明） 在这种情况下，缺陷会影响业务。 少校 …… …… （在测试计划中举例说明） Minor ..... ..... （在测试计划中举例说明） 这些缺陷是那些影响应用程序外观和感觉的缺陷。 优先级 高-P1 ... .. 中等-P2 ... .. 低-P3 ... .. ... .. P4 因此，根据高、中、低等bug的优先级，我们将其分为P1、P2、P3和P4。 测试环境 这些是我们将测试应用程序的环境，这里我们有两种类型的环境，分别是软件和硬件配置。 该软件配置是指对不同细节的操作系统，如Windows，Linux和UNIX和Mac和各种浏览器类似谷歌Chrome，Firefox, Opera，Internet Explorer，等等。 和硬件配置意味着有关不同尺寸的信息RAM，ROM，和处理器。 例如 该软件包括以下内容： 服务器 操作系统 Linux 网络服务器 Apache Tomcat 应用服务器 Websphere 数据库服务器 Oracle or MS-SQL Server 注：以上服务器为测试团队用于测试应用的服务。 客户 操作系统 Window XP、Vista 7 浏览器 Mozilla Firefox、Google Chrome、Internet Explorer、Internet Explorer 7 和 Internet Explorer 8 注意：以上详细信息提供了测试团队将在其中测试应用程序的各种操作系统和浏览器。 该硬件包括以下内容： 服务器: Sun StarCat 1500 测试团队可以使用这个特定的服务器来测试他们的应用程序。 客户： 它有如下配置，如下： 处理器 内置2GHz 内存 2GB …… …… 注意：它将提供测试团队的测试工程师的系统配置。 流程安装软件 ...... ... .. ... .. 开发团队将提供如何安装软件的配置。如果开发团队还没有提供流程，那么我们将在测试计划中将其写为基于任务的开发（TBD）。 进入和退出标准 它是一个必要条件，在开始和停止测试过程之前需要满足。 入学条件 参赛条件包含以下条件： 应该完成白盒测试。 理解和分析需求并准备测试文件或测试文件准备好时。 测试数据应该准备好了。 必须准备构建或应用程序 模块或功能需要分配给不同的测试工程师。 必须准备好必要的资源。 退出标准 退出标准包含以下条件： 当所有的测试用例都执行完毕。 大多数测试用例必须通过。 取决于错误的严重程度，这意味着不能有任何阻止程序或主要错误，而存在一些小错误。 在我们开始执行功能测试之前，应遵循上述所有进入标准。在我们进行功能测试之后，在我们进行集成测试之前，应该遵循功能测试的退出标准，因为退出标准的百分比是由开发和测试经理的会议决定的，因为他们的合作可以达到百分比。但是如果不遵循功能测试的退出标准，那么我们就无法进一步进行集成测试。 这里基于错误的严重性意味着测试团队会决定在下一阶段进一步进行。 测试自动化 在此，我们将决定以下事项： 哪些功能必须自动化而不是自动化？ 我们将在哪个自动化框架上使用哪个测试自动化工具？ 我们只在第一个版本发布后自动化测试用例。 这里出现的问题是，我们将根据什么决定必须测试哪些功能？ 在上图中，我们可以看到最常用的功能需要反复测试。假设我们必须检查 Gmail 应用程序，其中基本功能是Compose mail、Sent Items 和 Inbox。所以我们会测试这些功能，因为在进行手动测试时，需要更多的时间，而且它也变得单调乏味。 现在，我们如何决定不测试哪些功能？ 假设Gmail应用的帮助功能没有被反复测试，因为这些功能不经常使用，所以我们不需要经常检查。 但是如果某些功能不稳定并且有很多错误，这意味着我们不会测试这些功能，因为它必须在手动测试的同时进行一次又一次的测试。 如果有一个功能需要经常测试，但我们预计该功能的需求会发生变化，所以我们不会检查它，因为与更改自动化测试脚本相比，更改手动测试用例更舒适。 工作量估算 在此，我们将计划每个团队成员需要付出的努力。 测试可交付成果 这些是测试团队输出的文件，我们将它们与产品一起交给客户。它包括以下内容： 测试计划 测试用例 测试脚本 RTM（需求追踪矩阵） 缺陷报告 测试执行报告 图表和指标 发行说明 图表和指标 图形 在此，我们将讨论我们将发送的图表类型，我们还将提供每个图表的样本。 正如我们所看到的，我们有五个不同的图表显示了测试过程的各个方面。 图 1：在此，我们将显示每个模块中已识别出多少缺陷以及修复了多少缺陷。 图表 2：图 1 显示了每个模块已识别出的关键、主要和次要缺陷的数量，以及相应模块已修复的数量。 Graph3：在这个特定的图中，我们表示构建明智图，这意味着在每个构建中，每个模块有多少缺陷已被识别和修复。基于模块，我们已经确定了错误。我们将添加R以显示 P 和 Q 中的缺陷数量，我们还将添加S以显示 P、Q 和 R 中的缺陷。 图4：测试负责人将设计每个月创建的Bug 趋势分析图，并将其发送给管理层。这就像在产品结束时进行的预测一样。在这里，我们还可以对错误修复进行评分，因为我们可以观察到弧在下图中具有向上的趋势。 GRAPH5：该测试管理器设计这种类型的图表。该图旨在了解错误评估与实际发生的错误之间的差距，该图还有助于改进未来对错误的评估。 指标 如上所述，我们创建了错误分布图，如图 1 所示，并且借助上述数据，我们还将设计指标。 例如 在上图中，我们保留了特定项目中所有测试工程师的记录以及已识别和修复的缺陷数量。我们还可以将这些数据用于未来的分析。当新的需求出现时，我们可以根据上述指标，根据他们之前发现的缺陷数量来决定为谁提供具有挑战性的特性进行测试。我们将处于更好的状态，以了解谁能很好地处理有问题的功能并找到最大数量的缺陷。 发布说明：它是在产品发布过程中准备并由测试经理签署的文件。 在下图中，我们可以看到最终产品已开发并部署到客户，最新版本名称为Beta。 该版本资讯包括以下内容： 用户手册。 待处理和开放缺陷列表。 添加、修改和删除的功能列表。 测试产品的平台（操作系统、硬件、浏览器）列表。 产品未经测试的平台。 当前版本中修复的错误列表，以及先前版本中修复的错误列表。 安装过程 软件版本 例如 假设Beta是应用程序的第一个版本Alpha发布后的第二个版本。在第一个版本中发现的一些缺陷已经在后来的版本中修复了。而在这里，我们也会指出从 alpha 版本到 beta 版本的新增、修改和删除的功能列表。 模板 这部分包含了产品中会用到的文档的所有模板，所有的测试工程师在项目中只会使用这些模板来维护产品的一致性。在这里，我们有在整个测试过程中使用的不同类型的模板，例如： 测试用例模板 测试用例审查模板 RTM 模板 错误报告模板 测试执行报告 让我们看一个测试计划文档样本 第1页 第3-18页 第20页 在第 1 页中，我们主要只填写版本、作者、评论和审阅者字段，在经理批准后，我们将在批准者和批准日期字段中提及详细信息。 大多数情况下，测试计划由测试经理批准，测试工程师只对其进行审查。并且当新功能来临时，我们会修改测试计划并在Version字段中做必要的修改，然后再次发送给经理进一步审查、更新和批准。每当发生任何更改时，都必须更新测试计划。在第 20 页上，参考资料指定了我们将用于编写测试计划文档的所有文档的详细信息。 笔记： 谁编写测试计划？ 测试线→60% 测试经理→20% 测试工程师→20% 因此，从上面可以看出，在 60% 的产品中，测试计划是由 Test Lead 编写的。 谁来审核测试计划？ 测试线 测试经理 测试工程师 顾客 开发团队 测试工程师根据他们的模块观点审查测试计划，测试经理根据客户意见审查测试计划。 谁批准测试计划？ 顾客 测试经理 谁编写测试用例？ 测试线 测试工程师 谁来审查测试用例？ 测试工程师 测试线 顾客 开发团队 谁批准测试用例？ 测试经理 测试线 顾客 测试计划指南 收起你的测试计划。 避免重叠和冗余。 如果您认为不需要上面已经提到的部分，请删除该部分并继续。 请明确点。例如，当您指定一个软件系统作为测试环境的一部分时，请提及软件版本而不仅仅是名称。 避免冗长的段落。 尽可能使用列表和表格。 需要时更新计划。 不要使用过时和未使用的文档。 测试计划的重要性 测试计划为我们的思考提供了方向。这就像一本规则书，必须遵守。 测试计划有助于确定验证被测软件应用程序质量所需的努力。 测试计划帮助那些人了解与外部相关的测试细节，如开发人员、业务经理、客户等。 测试计划、测试策略、测试范围等重要方面都记录在测试计划中，以便管理团队可以审查它们并将它们重用于其他类似项目。 边值分析 测试用例审查流程
