How to Write Test Strategy Document（如何编写测试策略文档）

How to Write Test Strategy Document（如何编写测试策略文档）

1 – Scope and Overview （范围和概述）
Project overview along with information on who should use this document. Also, include details like who will review and approve this document. Define testing activities and phases to be carried out with timelines with respect to overall project timelines defined in the test plan.
（项目概述以及谁应该使用此文档的信息。此外，还应包括谁将审查和批准此文档之类的细节。根据测试计划中定义的总体项目时间线，定义要执行的测试活动和阶段。）

2 – Test Approach（测试方法）
Define testing process, level of testing, roles, and responsibilities of every team member. For every test type defined in test plan (Example: unit, integration, system, regression, installation/uninstallation, usability, load, performance, and security testing) describe why it should be conducted along with details like when to start, test owner, responsibilities, testing approach and details of automation strategy and tool if applicable.
（定义测试流程、测试级别、每个团队成员的角色和职责。测试计划中定义的每个测试类型(例如:单元、集成系统、回归、安装/卸载、可用性、负载、性能、安全测试)描述为什么它应该进行，开始时间,测试负责人,职责,测试方法和如果适用自动化的话，自动化的策略和工具等细节。）

In test execution there are various activities like adding new defects, defect triage, defect assignments, re-testing, regression testing and finally test sign-off. You must define exact steps to be followed for each activity. You can follow the same process which worked for you in your previous test cycles.
（在测试执行中有各种各样的活动，比如添加新的缺陷、缺陷分类、缺陷分配、重新测试、回归测试以及最后的测试结束签字。您必须为每个活动定义要遵循的确切步骤。您可以遵循在以前的测试周期中相同的过程。）
A Visio presentation of all these activities including several testers and who will work on what activity is very helpful to quickly understand roles and responsibilities in the team.
Example: defect management cycle – mention the process to log the new defect. Where to log in, how to log new defects, what should be the defect status, who should do defect triage, whom to assign defects after triage etc.
（通过Visio表示所有这些活动，包括几个测试人员以及谁将从事什么活动，对于快速理解团队中的角色和职责非常有帮助。
例子:缺陷管理周期——提到记录新缺陷的过程。在哪里登录，如何登录新的缺陷，缺陷状态应该是什么，谁应该做缺陷分类，谁应该在分类之后分配缺陷等等。）

Also, define change management process. This includes defining change request submission, template to be used, and process to handle the request.
3 – Test Environment
（同样，定义变更管理流程。这包括定义变更请求提交、要使用的模板和处理请求的流程。）

Test environment setup should outline information about several environments and required setup for each environment.
（测试环境设置应该概述关于不同环境的信息，以及每个环境所需的设置。）

Example: one test environment for functional test team and another for UAT team. Define the number of users supported on each environment, access roles for each user, software and hardware requirements like operating system, memory, free disk space, number of systems etc.
Defining test data requirements is equally important. Provide clear instruction on how to create test data (either generate data or use production data by masking fields for privacy).
（例如:一个测试环境用于功能测试团队，另一个测试环境用于UAT团队。定义每个环境支持的用户数量、每个用户的访问角色、操作系统、内存、空闲磁盘空间、系统数量等软硬件需求。
定义测试数据需求同样重要。提供如何创建测试数据的清晰说明(或是生成数据，或是使用加工（make field for privacy）后的生产数据）。 ）

Define test data backup and restore strategy. Test environment database may run into problems due to unhandled conditions in the code. I remember the problems we faced on one of the projects when there was no database backup strategy defined and we lost whole data due to code issues.
Backup and restore process should define who will take backups when to take a backup, what to include in backup when to restore the database, who will restore it and data masking steps to be followed if the database is restored.
（定义测试数据备份和恢复策略。由于代码中未处理的条件，测试环境数据库可能会遇到问题。我记得我们在一个项目中遇到的问题，当时没有定义数据库备份策略，由于代码问题，我们丢失了整个数据。
备份和恢复过程应该定义谁将在何时进行备份，何时恢复数据库时在备份中包含什么，谁将恢复数据库，以及在数据库恢复时要遵循的数据屏蔽步骤。）

4 – Testing Tools （测试工具）
Define test management and automation tools required for test execution. For performance, load and security testing describe the test approach and tools required. Mention whether it is open source or commercial tool and how many users are supported on it and plan accordingly.
Whether you are doing manual or automated testing (or a combination) a test management tool like XXXX can help you organize the team and increase productivity.
（定义测试执行所需的测试管理和自动化工具。对于性能，负载和安全性测试描述了所需的测试方法和工具。说明它是开源的还是商业工具，以及有多少用户支持它，并据此制定计划。
无论您正在进行手动测试还是自动测试(或组合测试)，像XXXX这样的测试管理工具都可以帮助您组织团队并提高生产力。）
For example, you can record details about test cases or scenarios with screenshots and expected results, and then set up test plans and test runs. When testing starts, track the status of individual tests and measure progress with informative dashboards and activity reports.
Deliver fast feedback on application quality with XXXX’s powerful reports and metrics. Track team workload to adjust assignments and resources, and work more productively with personalized to-do lists, filters, and email notifications.
（例如，您可以用截图和预期结果记录关于测试用例或场景的细节，然后设置测试计划和测试运行。当测试开始时，跟踪单个测试的状态，并使用信息指示板和活动报告度量进度。
利用XXXX强大的报告和指标，提供关于应用程序质量的快速反馈。跟踪团队的工作负载，以调整分配和资源以便于更加有效的并个性化的工作通过待办事项列表，过滤器，和电子邮件通知。）

5 – Release Control （版本控制）
As mentioned, unplanned release cycle could result in different software versions on test and UAT environments. Release management plan with proper version history will ensure test execution of all modifications in that release.
（如前所述，计划外的发布周期可能导致测试和UAT环境上的不同软件版本。具有版本历史记录的版本管理计划将确保所有修改的测试执行在正确的版本上。）

Example: set build management process which will answer – where new build should make available, where it should be deployed, when to get the new build, from where to get the production build, who will give the go, the no-go signal for production release etc.
（例如:设置构建管理流程，该流程将回答以下问题:新构建应该在何处可用、应该在何处部署、何时获得新构建、从何处获得生产构建、谁将同意进行构建、生产发布的禁止放行信号等等。）

6 – Risk Analysis （风险分析）
List all risks that you envision. Provide a clear plan to mitigate these risks and also a contingency plan in case if you see these risks in reality.
(列出你预想的所有风险。提供一个清晰的计划来减少这些风险，如果你在现实中看到这些风险，也要提供一个应急计划。)

7 – Review and Approvals (审查和批准)
When all these activities are defined in test strategy plan it needs to be reviewed for sign-off by all entities involved in project management, business team, development team, and system administration (or environment management) team.
(当所有这些活动都在测试策略计划中定义时，需要由项目管理、业务团队、开发团队和系统管理(或环境管理)团队中的所有实体进行评审并签字。)
Summary of review changes should be tracked at the beginning of the document along with approver name, date and comment. Also, it’s a living document meaning this should be continuously reviewed and updated with the testing process enhancements.
(评审变更的摘要应在文档的开头进行跟踪，同时跟踪批准人的姓名、日期和评论。而且，它是一个活文档，这意味着应该通过测试过程的增强不断地检查和更新它。)

以上信息来源于一个特别好的测试相关的网站，分享给大家~~https://www.softwaretestinghelp.com/