如果您有无限数量的合格员工，时间和金钱，您当然可以没有测试策略。 简而言之，多年来减少一次发布的能力。 在这种假设的理想条件下，不需要采取任何策略，因为您可以按照自己喜欢的任何时间对产品进行测试，可以以任意顺序，多次应用这些技术，并且早晚以某种方式获得生产就绪的质量。
实际上，项目总是会耗费最后期限，团队的工作能力/技能不是决定性的，产品要求也在不断发展-在这里，您不能没有一个好的计划。 因此，需要采取一种测试策略。
在本文中，我们将提供一些需要讨论的问题，以制定一种测试策略，并举例说明在特定情况下如何制定有关测试工具的决策。
0.让我们在岸上弄清楚
为什么我们需要测试策略？
- 在资源有限的情况下组织流程。 因此，首先，很高兴认识到我们拥有哪些资源。
- 为了使所有项目参与者都了解测试的作用，测试的作用，我们将从中获得的收益。 使每个人对质量控制领域的期望具有相同的期望和理解。 并且确定在讨论过程中不可避免地会变得明显的可能问题。
谁来制定策略？
首先，当然要进行质量检查，而且必须是项目经理。
因此，请手牵着测试人员项目经理或测试人员经理，倒咖啡，拿纸，记号笔，笔记本电脑，然后……走吧！
1.我们将在项目上使用哪种类型的测试以及为什么
从一开始，我们就提供召回
所有现有测试类型并决定每种
测试的方式 ：我们将使用它以及为什么使用它。 让我们看一些示例，说明如何确定特定类型的测试的需求。
测试版本安装
无论如何，即使该应用程序是全新的并且是首次安装（部署），您也需要检查其运行方式：是否启动，是否可以开始使用它。 无论是移动应用程序，台式机还是网络。
对于Web应用程序，讨论我们如何验证更新后的数据不丢失是很有用的。 我们希望活动会话具有什么样的行为。
对于台式机和移动应用程序，您需要考虑一种将新分发分发给用户以及由用户启动的更新过程的方法。
对于所有项目，讨论诸如热身系统之类的事情是很有用的：安装目录，设置用户以及用户开始使用系统所需的其他数据。
性能测试
这些因素将影响决策：系统中将有多少用户工作，将处理多少数据。
| 给定 | 解决方案 |
|---|
| 我们知道将有10个人使用该产品。 而且我们知道他们将交出几千条记录的表格。 | 计划使用大量数据进行批量测试是有意义的。 |
| 我们知道，在使用产品的过程中，用户会将许多媒体文件上传到客户的服务器上。 | 您需要找出此服务器设计用于哪种负载，并牢记这些数据。 |
| 该应用程序每周有几个人使用，数据量很少。 | 不需要性能测试。 |
回归测试
对整个系统进行全面检查通常会花费很多时间。 因此，要做出决定，有必要评估适当性：完全回归需要多少时间，以及如果不进行回归可能会发生的风险。
| 给定 | 解决方案 |
|---|
| 我们推出产品或程序模块的第一个版本。 | 不需要回归测试。 |
| 该项目非常大，在发布新功能之前要进行完全回归需要花费与开发阶段相当的时间。 所需的供应率不允许这样做。 | 我们决定不进行回归测试，而是更多地关注其他类型的测试和监视。
|
| 合同测试涵盖了微服务之间的交互。 | 完全回归是不切实际的。 在手动测试的框架中，我们根据开发人员的建议对功能进行了回归。 |
整合测试
为了确定集成测试的必要性，列出产品与之交互的所有外部系统并指出我们接收和传输的数据非常有用。
| 给定 | 解决方案 |
|---|
| 来自门户的销售数据被传输到分析系统。 | 重要的是，不仅要验证销售是否正确，格式正确，而且要以正确的格式销售-在此过程中，没有任何损失。 |
本地化测试
回答有关项目的问题很重要：
- 应该支持哪些语言
- 在解决方案运行期间我们是否提供其他本地化的连接，
- 我们的用户将在哪些国家/地区工作，
- 是否会有销售以及以什么货币表示
- 您需要使用时区吗？
| 给定 | 解决方案 |
|---|
| 该系统有2种语言：俄语和英语。 | 讨论我们将如何理解以哪种语言向用户展示的界面是有意义的。 |
| 客户要求使该应用程序具有多种语言。 | 值得您自己回答以下问题：我们将如何验证文本，从何处获取阿拉伯文本，如何调整屏幕以适应从右向左书写的文本。 |
跨浏览器和跨平台
通常，我们无法在所有设备上验证移动应用程序的正确运行。 对于Web应用程序，问题立即出现：我们将支持IE9吗？ 在将这种类型的测试纳入策略之前，我们分析（如果解决方案已经在起作用）或假设（如果解决方案已经不起作用）他们将如何使用它。
| 给定 | 解决方案 |
|---|
| 移动应用程序用户是全国各地的员工。 | 我们查看有关应用程序平台使用情况的现有统计信息，并确定我们将测试哪些平台。 |
| 我们的应用程序吸引了固定机器上的企业用户。 | 我们很可能建议仅使用一种浏览器。 从而减少了测试时间和对跨浏览器兼容性的支持。 |
同样，您需要解析所有其他类型的测试：
- 功能性（已实施或未实施），
- 接受（由谁进行以及如何进行），
- UX / UI（良好界面的客观标准是什么）
- 模块化和单元（谁编写合同测试，谁编写单元测试以及我们是否完全编写），
- 安全测试（谁保证数据安全以及系统对黑客攻击的抵抗力），
- 故障和恢复（系统在紧急情况下的行为）
和其他。
2.测试重点
不可抗力会在所有项目中发生，因此备有精心设计的备忘单很有用，而不是随意抓住按钮。
在正常模式下，有意义的优先级也很重要。 例如，在计划自动测试的开发时应考虑优先级：首先，最关键的场景是自动化的（烟雾测试）。
| 给定 | 解决方案 |
|---|
| 我们的程序在机场用于在登机时向乘客出售服务。 而且，如果此时发生某种错误，那么我们将没有时间进行热修复。 因此，应该没有错误！ | 我们首先检查在机场的使用场景。 |
3.工作环境
有必要考虑并与团队协调工作需要哪些环境以及由谁来使用。 通常，2-3个环境和销售量就足够了。
| 给定 | 解决方案 |
|---|
| 在CD / CI项目中，编写了烟雾测试以进行功能的初始测试。 | 我们需要一个环境来在一个分支中进行代码的初级汇编，运行冒烟测试，在该环境中，外部系统由存根关闭。 您还需要一个用于与客户服务（QA）进行手动和集成测试的环境。 |
| Beta测试会议定期举行。 | 我们需要一个在外部可见的环境，比QA环境更稳定。 |
4.测试人员在项目上的工作
事先讨论我们希望测试人员在项目上进行的所有活动是有意义的，因为它们不一定在所有项目上都相同。 对于团队中的某人来说，测试人员正在做某事或没有做某事可能会感到惊讶。
该项目将帮助管理人员了解测试人员需要什么能力，以及预计需要多少时间。 对于现有项目，重要的是要表明我们（QA）有能力，以便经理了解他的意思。
例如，可能是：
- 评估冲刺目标的完整性和一致性，
- 评估测试的人工成本，
- 准备测试清单（或测试用例），
- 自动测试脚本审查
- 编写功能自动测试，
- 直接手动测试，
- 部署对环境的更改，
- 更新测试策略等
5.测试项目文档
有必要达成共识，并且可能会进一步定期检查测试文档的格式：
- 我们将在项目中执行哪些测试文档，
- 我们会写测试用例吗
- 做清单
- 以及更新此文档的频率。
| 给定 | 解决方案 |
|---|
| 已经为该系统功能的三分之一编写了大约300个测试用例。 它们不仅必须定期审查，而且还需要不时更新。 | 在资源有限的情况下，我们决定不使用测试用例，而是限制自己检查每个特定任务的清单。 结果，我们节省了支持文档的时间，而又不损失测试质量。 |
6.如何生成测试用例
操作条件和方案取决于特定的解决方案，因此请务必讨论：
- 使用什么测试设计技术才有意义。 作为本段的一部分，列出应用程序可以使用的对象及其等效类的列表很有用。
- 启发式和平庸的生活经验有助于为特定项目提供测试脚本。 对于移动应用程序，可以方便地使用标准启发式方法，例如“ I SLICED UP FUN”。
| 给定 | 解决方案 |
|---|
| 在保险项目中，用户（代理人）必须检查机器，在此期间需要拍照并将其上传到服务器。 常识表明，车库几乎没有wifi。 有时，没有移动连接。 | 因此，您不仅需要在使用3G时检查应用程序，还需要在没有通讯的情况下检查应用程序。 |
| 航空公司的移动应用程序中的任何用户操作都是方案的一部分。 例如，您必须先创建预订才能发行票证。 | 因此，使用“用例”技术是合乎逻辑的。 |
7.使用跟踪器的过程
在不同的跟踪器中，任务的可能性和类型不同。 根据跟踪器的功能，我们建议您就谁和通过什么原则确定任务的优先级，在哪种类型的任务中安排错误和任务达成一致。
与团队讨论要点：
- 我们如何区分我们发现的错误和客户发现的错误（以及是否需要区分它们），
- 如何进行改进
- 是否有必要将我们自己发明的改进与客户要求的改进区分开来。 怎么了
- 如果不再发生错误，该怎么办？
- 什么状态被视为最终状态。
| 给定 | 解决方案 |
|---|
| 测试人员会创建一个错误。 开发人员无法复制它，将其转换为拒绝状态。 | 如果错误确实消失，测试人员将重新检查任务并将状态设置为“已关闭”（最终），或优化描述并将其返回“新建”。 |
| 客户设置要修订的任务。 开发人员知道他没有足够的数据来实施。 | 开发人员将任务置于“反馈”状态。 |
（我们在
本文中写了更多有关描述错误和用户故事的方法）。
8.开始和结束测试的标准
如果测试人员随时执行任何任务，这不是命令，而是混乱。 因为任务可能尚未准备好。 还是准备好了，但不是免费的。 或已准备就绪，已部署，但取决于尚未完成的其他任务。 结果，测试人员会花时间和精力来寻找并修复错误，但实际上您只需要等待。 因此，我们同意任务的质量检查责任区域在什么时候开始和结束。
在项目开发的早期阶段，任务/版本的准备情况取决于目光。
随着自我意识的增强，我们知道我们需要明确的标准来准备任务/版本。 因此，该决定对每个人都是透明的，而不是“测试人员感到一切正常”。 例如，在经过调整的CD中，我们认为该任务一旦部署到QA环境并具有“已解决”状态，就可以进行测试了。
| 给定 | 解决方案 |
|---|
| 在项目上建立了一个过程，为每个修订版本编译了一个检查清单。 | 如果我们通过了清单上的所有要点，我们认为任务已验证。 |
| 该项目正在进行冲刺。 | 如果所有改进均处于“已关闭”状态且优先级为“正常”或更高，则没有错误，则认为Sprint已准备就绪。 |
| 该项目按优先级编制了功能列表。 | 我们认为，如果列表开头的功能可以成功运行，则该版本已准备好发布。 |
| 该项目已编写测试用例并在发布之前进行了回归测试。 | 如果基于回归测试的结果，没有发现优先级为Normal或更高的错误（或不成功方案的百分比不超过5），则认为该版本已准备就绪。 |
9.工作工具
然后，本部分很有用，以便在测试计划阶段就已经将任务（由管理员和经理负责）并在工作开始之前获得所有必要的工具。
值得讨论以下问题：
- 我们需要哪些工具来进行测试文档，
- 哪些工具可以准备测试数据，
- 自动化需要哪些工具。
| 给定 | 解决方案 |
|---|
| 为了描述所实现的功能，我们决定使用思维导图。 | 团队中的人在不同的平台上工作，因此您需要选择可在Windows，Linux和Mac中使用的思维导图文件格式。 |
| 我们同意我们需要该项目的自动化。 | 因此，我们需要一些工具，这些工具将允许我们准备测试数据（例如，将脚本滚动到数据库中），允许我们在管道中启动（例如，newman）以及允许我们创建存根（例如，WireMock）。 |
10.项目质量评估和监测工具
在本节中，我们建议就什么KPI用于评估应用程序的运行状况达成共识（除了显而易见的测试覆盖率计算）。 该指标应是可衡量和可实现的。 尤其要理解并回答以下问题：
- 我们将如何跟踪产品中的错误
- 我们将如何收集用户的反馈意见，
- 我们将如何收集有关功能使用情况的统计信息。
| 给定 | 解决方案 |
|---|
| 在发布系统的新功能之后，将配置使用情况监视（例如，服务销售数量）。 | 下降是调查的诱因。 该功能可能无法按预期运行，或者我们未实现脚本的一部分。 |
| 我们已经配置了程序以监视执行基本操作的速度。 | 工作质量的标准是，随着用户的涌入，执行速度不会下降。 |
结论
没有适合所有人的单一通用测试策略。 它是为每个项目单独设计的。
- 重要的是要理解，策略本身不应成为目的-它只是使我们实现目标的工具。
- 并非总是能够立即回答所有提出的问题是很正常的。 这是再次与产品的客户或用户交谈的机会。
- 该项目正在发展，如果昨天对生产率感到困扰还为时过早，那么明天可能就该了。 因此，在制定战略之后，定期更新和补充战略并为团队带来变化非常重要。
- 编写策略后，通常可以清楚地知道测试的失败位置和需要执行的操作。 这是设定目标，观察动态并在一段时间后更新策略的机会。