这是一个非常广泛的问题，如果没有对贵公司产品、质量目标和现有工具的更多了解，几乎不可能回答...但我有一些意见：tm：这可能会有所帮助，从一些哲学开始（对不起）。

你是为了什么

测试部门的职能不是测试，而是测试。目标是帮助公司对其产品交付充满信心。您的客户想知道您的软件是准确且稳定的。您的运营团队希望避免生产下降。您的开发人员希望对他们的更改有效并且不会产生任何负面影响充满信心。

我个人认为测试团队提供这种信心的最佳方式不是编写测试，而是编写测试。这是通过编辑它们。测试团队提供工具、指南和专业知识，以帮助其他工程部门使测试成为流程中不可或缺的一部分。

就像做饭一样。你不能通过切碎、炒炒和搅拌，然后把它交给主厨来品尝，来做一顿调味好的饭菜。你去的时候不断地品尝，因为你是知道食物应该是什么样子的人。主厨对您进行培训并就最后一道菜提供反馈，以便您学习如何正确调味。

选择工具

无关紧要。大多。

您的工具需要为您提供您所追求的东西，然后让您摆脱困境。目前，该公司几乎不知道它在追求什么，因此您甚至可以使用 Google Doc 来跟踪缺陷。

你一开始就不想妨碍任何人，否则他们会开始怨恨你。您的团队需要提供价值并开始赚取社会资本来改变工程流程以帮助实现您的目标。

因此，请使用任何已经在使用的文档共享工具；无论是 Wiki、Google、Dropbox 等。如果您因为没有协作而选择新的，我偏爱Notion。

如果您的团队已经有一个协作构建工具（例如 Jenkins、Travis），最好坚持使用它，并添加测试步骤。同样，您引入的摩擦越少，您的初始结果就越好。

我不会费心构建和维护测试网格；相反，要依靠像Sauce Labs这样的供应商来获得基础设施和专业知识。这样，您就可以轻松实现并行化、广泛的平台覆盖、测试资产收集、洞察力以及他们在支持测试团队方面的经验。免责声明：我是 Sauce Labs 的开发者关系经理，所以我可能有偏见；）

至于测试工具；如果您希望您的工程团队在测试生产上进行协作，您需要坚持他们可以使用的生态系统。这可能意味着他们已经在使用的任何东西。

您的组织非常想要测试，他们正在雇用您。这意味着他们想要避免再次发生的创伤性事件。所以，从那里开始。找出它是什么，并为它创建一个测试。

如果黑色星期五让他们的网站不堪重负，请进行负载测试。如果他们的构建总是中断，请专注于单元测试。如果功能在 Prod 中不起作用，请添加集成测试。

新玩家有一个陷阱，你可能会从你的开发者那里听到这个：

我们在测试覆盖率上远远落后，我们永远赶不上

这是绝对正确的......如果你从来没有开始！添加测试以防止在船上购买您的创伤并且您已经在增加价值；下次你会发现这个问题。

另一个陷阱是设置测试覆盖率目标。测试覆盖率是监控过程的好方法，但改进它的方法很糟糕。强迫你的团队增加测试覆盖率（或不让它溜走），他们会开始反感这个过程......并编写废话测试只是为了提高百分比。

相反，使用覆盖率来获得反馈。如果在提交期间覆盖率下降，请讨论原因并讨论如何改进它。如果它下降了，你可能想做点什么，但是在你开始的时候稍微下降是 A-OK。

假设你已经涵盖了让你被录用的创伤，那么最好在工作的基础上增加测试覆盖率。如果开发人员正在编写新代码，它会得到测试。如果开发人员正在修改旧代码，它会进行测试以（至少）证明修改工作，并且理想情况下证明它们也不会破坏旧功能。

您可能会遇到字面上无法测试的旧代码。这是重构该代码的好时机。如果人们害怕重构，因为它可能会崩溃，请指出这正是测试的目的。尝试拉出到可以测试的水平。如果您无法测试一个单元，请测试该类。如果您无法测试该类，请测试该包。然后，返回并开始重新工作。总有一天你必须这样做。

哦，不，我们很快就会用新的 Buzzshooper 实现替换 Fizzwangle；没有必要冒着重构可测试性的风险。

这是个谎言。即使他们说的是实话，那也是谎言。Buzzshooper 不会很快到来。重构那个狗屎。

您的测试需要像高质量代码一样对待。使用您在编写代码时使用的所有抽象，例如继承、多态性、模块化、可组合性。

查看用于前端测试的页面对象模型等技术。您的测试代码应该将实现细节知识（例如，元素定位器）限制在最少的地方，以便更改易于实现。

哦，还有，你的代码就是代码。了解然后帮助您的团队编写代码以实现可测试性和代码能力测试。构建您的测试和应用程序，以便您可以尽可能快地并行、可靠地进行测试：

查看过去的会议演讲，例如SauceCon Online。

Testing Talks Online有一些很棒的讨论，是我在 Covid 期间发现的最接近现实生活中的聚会。

测试部也有很多很棒的内容。