您的问题似乎提出了两个问题：哪个测试过程最有效，哪个测试过程对您的测试人员最满意（或最不令人沮丧）？您可能认为这些问题相互关联密不可分，但您的管理层可能有不同的看法。你说选项 1 没有给测试人员足够的信息来确定软件是否正常运行，选项 3 很耗时。您说选项 2 让测试人员感到沮丧（甚至是侮辱），而您为问题命名的方式强化了这种情绪。但是，您没有说选项 2 是否有效。如果选项 2 是有效的——如果它发现了足够多的错误——那么也许你的组织需要比你当前的测试人员更喜欢猴子测试的测试人员。

鉴于您的时间限制，如果选项 2 无效，我将很难改进选项 3。在某些组织中，测试人员通过与项目团队的其他成员参加会议来了解应用程序。但是，如果选项 3 的会议时间过长，我怀疑测试人员也没有时间参加项目会议。

您没有提到您的开发团队如何测试他们的工作。如果这四个选项都不可行和/或无效，您可能需要将更多的测试工作推回给开发人员。以我的经验，这是一个薄弱的解决方案——许多开发人员不想进行测试，尤其是不定期进行测试——但它可能会在短期内有所帮助，直到您可以雇用更多的测试人员或给当前的测试人员更多的时间去做他们的工作。

任何列出的方法都可以在合适的岗位上与合适的人一起工作。
但是，您需要了解：

1. 如果做得好，通过详细的测试用例提供约 100% 的产品覆盖率是一个全职职位（甚至 2 个或更多）。把这个任务分配给PM是浪费钱。
2. 资历过高的人很快就会变得不开心做猴子的工作。
3. 自动化测试套件是一个独立的项目，有自己的 bugs/debugs/releases/roadmap，它需要
   ：需求（主要是详细的测试用例）。
   湾。开发人员/操作员，他们将运行套件和文件/修复/修补程序/hack-real-time-workarounds 发现一段时间的问题。
   C。编码技能，以便能够在初始作者退出后的第二天使用/修复/改进此套件。

因此，如果您有 1 个忙碌的 PM 和一群中级测试人员，请考虑以下情况：

1. 项目经理通过简短的描述优先考虑功能。
2. 在测试人员之间拆分产品模块，让每个测试人员用测试覆盖他/她自己的模块。
3. 当回归测试时间到来时，让测试人员测试其他人的模块。每次轮换作业。

这将产生一些：

1. 项目经理的空闲时间直接负责。
2. 测试人员的创造性和快乐时光，以及所有权自豪感的提升。
3. 测试人员之间的反馈和知识转移，导致文档质量提高。

听起来你在疯狂的土地上工作......

我的第一个问题是你们的测试仪有多贵？PM 坐下来编写所有测试怎么能更便宜，他没有更好的事情要做（比如管理项目）吗？

听起来您需要有人坐在 PM 和测试人员（例如测试经理）之间，他们可以与 PM 密切合作，以确保他们已将所有知识转移给测试人员。测试经理还可以与开发团队联系，了解他们已经实现了什么（它可能与 PM 所设想的不同），理想情况下让用户确切地找出他们想要的东西（同样可能与开发人员和 PM 已经完成）。

一些积极的方面（可能不是全部）：

• 测试经理应该一直在测试人员那里，而 PM 由于其角色的性质而将有有限的时间。

• 测试经理可以定期向 PM 提供有关测试进展情况的最新信息，并且应该在他们一直与测试人员一起工作时了解对产品状态的总体感觉（这对于可能不会从他们通常会接触到测试团队的有限曝光中获得产品好/坏的真实感受）。

一些负面影响：

• 如果你遇到了一个沟通能力很差的测试经理，或者有人想把信息集中在自己身上而不把它传递给你，那么你就会遇到真正的问题（但是这个人首先不应该是测试经理） .

测试人员应该为回归包编写脚本（或者更好地自动化它们并让它们在 CI 系统上运行），并执行尽可能多的探索性测试（因为那是你发现真正错误的地方）。