测试计划是一份详尽的文档，概述了完成软件测试所需的测试策略、目标、时间表、估计、可交付成果和资源。测试计划帮助我们确定确认被测试应用程序质量所需的工作量。测试计划是将软件测试操作作为一个定义的过程进行的蓝图，测试经理密切监视和控制。
根据 ISTQB 的定义，“测试计划是一份详细说明预期测试活动的范围、策略、资源和时间表的文件”。
让我们看一个测试计划的示例/场景：您想在会议上与团队成员讨论测试计划，但他们不感兴趣。
在这种情况下你会怎么做？
我是经理；按照我的指示。
现在，让我解释一下为什么需要测试计划。
创建测试计划文档有几个优点。
帮助测试团队以外的其他人了解测试的细微差别，例如开发人员、业务经理和客户。
我们的思考以测试计划为指导。它类似于一组必须遵守的规则。
测试计划记录了重要的特性，例如测试估计、测试范围和测试策略，以便管理团队对其进行评估并重新用于其他项目。
您已经知道测试管理过程中最重要的职责是创建测试计划。要根据 IEEE 829 制定测试计划，请遵循下面概述的七个阶段。
检查项目。
创建测试策略
创建测试目标列表。
指定测试标准
组织资源
搭建测试环境
估计和时间表
建立测试可交付成果
如果您不知道产品是什么，您如何测试产品？答案是不可能。在评估产品之前，您必须首先了解有关它的所有信息。
测试产品是一个电子商务网站。您应该对您的客户和最终用户进行研究，以了解他们对应用程序的需求和期望。
谁将成为网站的目标受众？
它的目的是什么？
它将如何运作？
产品使用了哪些软件和硬件？
浏览此网站并查看产品文档。查看产品文档可以帮助您理解网站的所有功能以及如何使用它。如果您有任何问题，您可以采访客户、开发商或设计师以获取更多信息。
在软件测试中，决定测试策略是创建测试计划的重要一步。测试策略文档是通常由测试经理创建的高级文档。本文包含以下定义 -
项目的测试目标和实现方法
确定花费在测试上的时间和金钱。
回到您的项目，您需要为银行网站创建一个测试策略。应遵循以下步骤 -
步骤 2.1 - 定义测试范围
应在开始任何测试活动之前确定测试范围。你需要考虑一段时间。
定义了要测试的系统的“范围内”组件（硬件、软件、中间件等）。
不会被测试的系统组件也必须被明确地描述为“超出范围”。
对于所有利益相关者，定义测试项目的范围至关重要。您将受益于精确的范围。
为团队中的每个人提供有关您正在执行的测试的信心和准确信息。
团队中的每个人都会知道什么是被测试的，什么不是。
你用什么标准来定义你的项目范围？
您必须 - 确定范围。
客户规格非常具体。
项目预算
产品规格
您的测试团队的能力和才能
现在应该明确定义测试的“范围内”和“范围外”。
根据软件需求，该项目只专注于测试网站的所有功能，对外接口（范围内测试），压力、性能、逻辑数据库测试暂时不会进行。（不在本文件范围内）
问题示例
客户要求您测试他的 API。但是，项目预算不允许这样做。在这种情况下你会怎么做？在这种情况下，您需要说服客户 Api 测试是一项额外的工作，会占用大量时间和资源。给他证据来支持你的主张。告诉他，如果 Api 测试包括在范围内，预算会增加 XYZ。
客户端同意，并创建新的范围和范围外对象。
功能测试和 API 测试是范围内事物的示例。
数据库测试、硬件和任何其他外部接口不包括在范围内。
步骤 2.2 - 确定测试类型
测试类型是产生可预测测试结果的常规测试过程。每种测试都旨在发现产品中的某种类型的问题。然而，所有类型的测试都针对同一个目标：“在向客户发布产品之前及早发现任何问题。”
下图描述了经常使用的多种测试形式 -
单元测试
API测试
集成测试
系统测试
安装/卸载测试
敏捷测试
对于软件测试，有多种测试类型可供选择。您的团队将无法通过适当的努力来处理所有类型的测试。作为测试经理，您必须优先考虑测试类型。
当涉及到 Web 应用程序测试时，应该优先考虑哪种测试？
为了省钱，应该跳过哪种测试？
步骤 2.3 - 记录风险和问题。
风险是一种不可预测的未来事件，有发生的机会和潜在的损失。当危险发生时，它就变成了一个“问题”。
您之前在文章风险分析和解决方案中了解了“风险”分析并确定了项目中可能存在的危险。
您将在 QA 测试计划中记录这些风险。
| 风险 | 减轻 |
|---|---|
| Members of the team lack the necessary abilities for website testing. | 为您的团队计划培训课程以提高他们的技能。 |
| The project timetable is very tight; doing this job on time will be difficult. | 为每个测试活动建立一个测试优先级。 |
| The Test Manager is a bad manager. | 管理者应该接受领导力培训。 |
| Employee productivity suffers when there is a lack of collaboration. | 鼓励每个团队成员完成他或她的任务，并激励他们更加努力地工作。 |
| Cost overruns and incorrect budget estimates | 在开始工作之前，确定范围，密切关注项目计划，并定期跟踪和衡量进度。 |
步骤 2.4 创建测试物流
测试经理应在测试物流中回答以下问题 -
谁来考验自己？
什么时候进行测试？
谁来考验自己？
虽然您可能不知道将进行测试的测试人员的确切身份，但可以确定测试人员的类型。
在为特定任务选择正确的成员时，您必须检查他的专业知识是否适合这项工作并估算项目预算。
如果将错误的人分配给任务，项目可能会失败或延迟。
具有以下能力的人最适合进行软件测试 -
理解客户观点的能力
对卓越的强烈热情，以及对细节的敏锐眼光和合作意愿。
测试人员是负责项目中测试执行的团队成员。您可以根据项目预算选择内部或外包测试人员。
什么时候进行测试？
相关的开发工作必须与测试活动相关联。
当您拥有附图中显示的所有元素后，您就可以开始测试了。
测试执行的最终目的和实现被称为测试目标。测试的目标是发现尽可能多的软件缺陷，并确保被测产品在发布之前没有错误。
您应该执行以下两个步骤来确定测试目标。
列出需要测试的所有程序方面（功能、性能、GUI 等）。
根据上述特征定义测试的目的或目标。
让我们使用这些过程来确定您的测试项目的测试目标是什么。
您可以使用“自上而下”技术来定位需要测试的网站方面。您可以使用此策略将被测程序拆分为组件和子组件。
基于上面列出的功能，项目的测试目标可以定义如下 -
检查网站的功能（账户、存款等）是否在现实世界的商业环境中按预期工作，没有错误或缺陷。
检查网站的外部界面（例如 UI）是否正常运行并且满足消费者的需求。
检查网站的可用性。这些功能是否可能对用户有用？
测试方法或测试判断可能基于称为测试准则的标准或规则。以下是两种类型的测试标准
暂停标准
定义测试的关键暂停条件。如果在测试期间满足暂停条件，则主动测试循环将被中断，直到满足暂停标准。
测试计划示例 - 如果您的团队成员表示 40% 的测试用例失败，您应该停止测试，直到开发团队修复所有失败的实例。
退出标准
它描述了确定测试阶段是否成功完成的标准。退出标准是测试的预期结果，在进入下一个开发阶段之前必须满足这些条件。例如，所有关键测试用例必须在 95% 的时间内通过。
安抚目标运行率和通过率是定义退出标准的两种方法。
运行率是执行的测试用例数与测试规范中测试用例总数的比率。例如，测试规范要求总共 120 个 TC，但测试人员只完成了 100 个，导致运行率为 100/120 = 0.83。(83%)
通过的测试用例数量与进行的测试用例数量的比率称为通过率。例如，在进行的 100 多个 TC 中，有 80 个通过了，因此通过率 80/100 = 0.8（80%）。
资源计划是完成给定任务所需的所有资源的综合列表。人力资源，以及执行工作所需的设备和材料，都是资源。
资源规划是测试规划的一个重要方面，因为它有助于确定项目所需的资源（员工、设备等）数量。因此，测试经理可以创建准确的项目计划和估算。
本节列出了为您的项目推荐的资源。
人力资源管理
下表描述了项目团队的几个成员。
| 号码 | 成员 | 任务 |
|---|---|---|
| 1 | 测试经理 | Oversee the entire project. Define the project's goals. Obtain the necessary resources |
| 2 | 测试员 | Identifying and characterizing suitable testing approaches, tools, and automation architecture Examine and evaluate the Test Approach Execute the tests, keep track of the results, and report any defects. Depending on the project budget, testers might be in-house or outsourced. To save money on the project, I advocate using outsourced personnel for low-skilled tasks. |
| 3 | 正在测试的开发人员 | Execute the test cases, test program, and test suite, among other things. |
| 4 | 测试管理员 | Establishes and maintains the Test Environment as well as its assets. SupportTester will run tests in the test environment. |
| 5 | SQA 成员 | Assume responsibility for quality assurance. Check to see if the testing procedure adheres to the specifications. |
系统资源
您应该计划用于测试 Web 应用程序的资源，如下表所示 -
| 号码 | 资源 | 说明 |
|---|---|---|
| 1 | 服务器 | Install the test web application. If applicable, this comprises a separate web server, database server, and application server. |
| 2 | 测试工具 | The purpose of the testing tool is to automate testing, replicate user operations, and create test results. You may use a variety of test tools for this project, including Selenium, QTP, and others. |
| 3 | 网络 | To imitate the real-world company and user environment, you'll need a network that includes both LAN and the Internet. |
| 4 | 计算机 | The computer that people frequently use to connect to the webserver |
测试环境是什么？
测试环境是测试团队将在其上运行测试用例的软件和硬件配置。测试环境包括现实世界的业务和用户环境，以及服务器和前端操作环境等物理环境。
如何创建测试环境？
怎么搭建这个电商网站的测试环境，回到你的项目？
您需要测试团队和开发团队之间的良好协作才能完成这项任务。
要完全理解所测试的 Web 应用程序，您应该向开发人员询问某些问题。这里有一些问题需要考虑。当然，如果你需要，你可以问其他问题。
该网站可以处理的最大同时连接数是多少？
本网站的安装有哪些硬件和软件要求？
用户的机器访问网站有什么特殊需要吗？
您已经在测试估计一文中使用了各种方法来估计完成项目所需的工作量。您现在应该将该估计值与时间表一起添加到测试计划中。
假设您将整个项目拆分为多个小工作，并在测试估计阶段包括对每个工作的估计，如下所示。
| 任务 | 成员 | 估算工作量 |
|---|---|---|
| 制定测试规范。 | 测试设计师 | 170 hours of labor |
| 进行测试执行 | 管理员和测试员 | 80 hours of labor |
| 测试报告 | 测试员 | 10 hours of labor |
| 交付测试 | 20 hours of labor | |
| 全部的 | 280 小时的劳动 |
之后，您制定完成这些家务的计划。
在项目管理中，通常使用术语“制定计划”。测试经理可以利用在测试计划中创建的可靠计划作为监控项目进度和控制成本超支的工具。
测试经理将需要以下信息来构建项目进度表
员工和项目截止日期 - 工作日数、项目截止日期和资源的可用性都是影响时间表的因素。
项目估算：测试经理根据估算知道完成项目需要多长时间。因此，他将能够制定适当的项目时间表。
了解项目风险可以让测试经理为项目计划分配足够的时间来应对风险。
必须生成和维护以支持测试工作的所有文档、工具和其他组件的列表称为测试可交付成果。
软件开发生命周期的每个阶段都有自己的一组测试可交付成果。
在测试过程之前，提供测试可交付成果。
包含测试计划的文档。
包含测试用例的文档
测试设计规范
在测试期间，给出测试可交付成果。
测试脚本
模拟器
测试数据
测试可追溯性矩阵
错误日志和执行日志
测试数据：测试周期完成后，提供测试可交付成果 -
测试报告/结果
缺陷报告
安装/测试程序指南
发行说明