我们是否需要考虑所有手动测试用例才能产生完全自动化和非自动化测试用例？

Question

我正在领导我们的本地移动应用程序的手动测试主题。我的任务是向管理层提交一份报告，其中我们说的是全部人工案例、全部自动化案例和完全自动化案例。

这样，管理人员才能看到自动化的进展。

手动测试方法：

我们一共有618个手工测试用例作为一个单独的套件&每个案例都有一个优先级(1或2或3)与它相关。对于故事测试，除了新创建的故事测试用例外，我们还考虑来自特定模块的所有P1+P2+P3，这些模块与故事相关/受故事影响。在发布结束时，为了回归，我们考虑了所有模块中的所有P1情况。只有当它是一个主要版本时，在回归过程中，我们才会考虑来自所有模块的所有P1+P2+P3。

自动化范围：

在寻找自动化时，我觉得花时间考虑P2和P3的情况是不值得的，因为有两个原因

1. 这些将在蓝月我们只做99%的小版本中执行一次
2. 它们中的大多数实际上是丢弃测试用例，这些测试用例是作为用户故事测试的一部分创建的。

我们想在我们的自动化中实现什么？

我们希望解决QA的痛苦区域，在这里，一些P1案例需要通过20+语言进行测试，并占用手动测试时间。

因为我们没有像烟雾、回归等不同的套件，所以我们需要给测试人员在单个套件中的测试用例，只为了识别哪些是自动的，哪些不是自动的。是否值得考虑低优先级测试用例以及高优先级测试用例？

Answer 1

重新开始，回答你自己和管理层(答案可能不同)，为什么你要自动化任何事情。请记住，自动化有其成本，而且很多时候它比手动测试高很多倍--开发人员的时间是宝贵的，而且您永远无法达到100%的自动化(不管它是什么)，所以无论如何，一些手动测试都是必要的。您可以轻松地完成自动化维护和错误修复，从而减少自动化开发人员的时间。

从哪里开始？就像一个聪明的人曾经告诉我的--从路灯下开始，选择最简单、最快的方法来实现自动化。它将带来最快的ROI，更重要的是将建立与开发人员和管理层的信任。在进行此操作时，您将开发基础设施，如果操作正确，每个新场景将通过代码重用启用更多的新场景。

尽量避免复杂和脆弱的场景，它将消耗您在开发和维护方面的资源，更糟糕的是会扼杀您的管理人员和开发人员对您的自动化的信心。

尽管如此，您很有可能发现您的自动化工作落后，经常中断，您需要追逐开发人员和架构师，以便自动机与实际产品保持同步。

解决方案可能是Alan所称的现代测试，他的原则可能在一定程度上简化了问题和解决方案，但总的想法是，您(您的团队)将帮助开发人员自己编写测试。

您可能需要有人来启动测试框架和很少的示例测试用例，并帮助进行长期的维护和教育。显然，您需要您的管理支持来“浪费”开发人员的时间，特别是在一开始，但从长远来看，这可能是最好的可持续解决方案-您编写了它，您测试它。