问在自动化之前，您应该创建一个手动测试脚本吗？

EN

这件事没有一个答案。这在很大程度上取决于你工作的环境。

例如，我在不同程度的规范领域工作过，在这些领域，从需求和变更到测试用例执行的可跟踪性是至关重要的。在这些情况下，将测试用例记录在测试用例管理工具中并为自动化选择合适的测试用例往往是一个很好的解决方案。在测试用例管理工具中使用测试用例还具有一些优点，可以跟踪测试结果，因为我所使用的工具集成了这些工具，以允许跟踪测试用例的执行时间、执行对象、pass/files状态以及附加输出(例如屏幕截图、控制台输出或日志文件)。

不过，有几个因素需要考虑。

有些测试是“一次性”测试。它们可能需要很少被执行。如果它们不是标准测试套件的一部分，那么自动化的优先级就会降低。然而，需要考虑的其他问题是设置和执行测试的困难--繁琐的测试，即使是那些不常见的测试，也可能从自动化中受益。

也有不同级别的测试。单元测试、集成测试和验收测试并不都需要被同等对待。更多的形式倾向于系统测试和验收测试。尽管如此，随着系统的临界性或围绕故障的风险的增加，您可能希望围绕需求/更改、测试和代码更严格(甚至是双向)可跟踪性。

你应该看看你的背景。在自动化之前，将测试用例编写为手动执行，这样会有什么好处吗？这些好处是否超过了与增加这些步骤相关的成本？那么不首先编写用于手动执行的测试的风险或成本又如何呢？在自动化之前创建书面测试脚本是否意味着测试必须手动运行，还是仅仅是将测试脚本与外部工具链接起来的一种方式？如果您的系统进行了扩展，那么流程规模(同时增加了系统复杂性和支持更复杂的系统所需的任何组织更改)吗？有很多问题要考虑。

在作证中，一切都取决于背景。除非你说出以下几点，否则很难提出优点和缺点：

1. 你在哪种方法工作(敏捷还是瀑布?)
2. 你的冲刺长度是多少？
3. 你有多少时间来测试
4. 你的责任是什么(只是手动的，自动化的还是两者兼而有之？)
5. 团队的规模是多少？
6. 发布计划是什么？

，但我建议使用以下方法作为最佳实践

1. 调整TDD，在这里创建与开发并行的测试用例。因此，当开发sprint开始时，并行地启动测试sprint，并使用时间创建表格测试用例。
2. 不要等到得到实际的产品来编写测试用例并开始测试。
3. 如果当前sprint大小不足，则需要更多时间以表格格式记录测试用例。
4. 首先，只需写下所有出现在你脑海中的用例(意思是标题)。否则你会觉得工作单调乏味。首先，写下所有用例，一旦您对您决定的用例感到满意，就开始以表格格式编写测试步骤和其他细节。
5. 在团队成员之间划分特性，让每个团队成员负责测试特定的特性。这将给您更多的时间来集中精力并记录特定功能的测试场景，而不是对整个产品感到紧张。
6. 为测试文档保留最初的几天，并且只在它完全完成之后才开始执行。不要并行地做，否则你在测试时失去了注意力

的缺点：

1. 如果您是一个短跑小组中的单个QA，这将是非常繁忙的任务，您可能会失去对实际测试的关注，从而影响测试质量。
2. 如果您是负责自动化和手动操作的单个QA，那么这将是对时间和精力的浪费。对于这种做法，应该是完全否定的。如果有人真正想知道正在测试的用例，只需复制粘贴测试脚本标题即可。如果他们仍然坚持要求更多的成员加入团队

对于它没有具体的规则，因为最终的决定(手动测试第一或自动化脚本)归结为情况。作为软件测试服务的指导方针，可以说，对于一个新特性，即使在开发之前，手动测试也是第一位的。这与TDD是一致的。这些测试通常作为开发人员和测试人员关于该特性实现情况的度量。稍后，基于这些手动测试，可以编写自动化脚本。目前唯一的问题是自动化是否是最优的。然而，在实践中，这一顺序基本上没有被遵循，因为情况通常要求在工作方法中具有灵活性。