我加入了一家公司，他们没有任何正式的测试设置。他们希望我成立一个测试部门。我对手动和自动测试有很好的理解。不确定如何启动或使用哪些工具进行文档共享、错误跟踪。请尽可能多地提供信息。感谢

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

你的目的

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

我个人认为，测试团队提供这种信心的最佳方式是而不是编写测试；这是通过编辑它们。测试团队提供工具、指导方针和专业知识，帮助其他工程部门将测试作为流程的组成部分。

这就像做饭。你不能通过切碎、炒制、搅拌，然后交给主厨品尝来做出一顿调味良好的饭。你边吃边不断品尝，因为你知道食物应该是什么样子的。主厨会对你进行培训，并对最后一道菜提供反馈，让你学会如何正确调味。

选择工具

无关。主要地

你的工具需要给你想要的东西，然后让开。目前，该公司几乎不知道自己在追求什么，所以你甚至可以使用谷歌文档来跟踪缺陷。

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

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

如果你的团队已经有了一个协作构建工具(例如Jenkins、Travis)，那么最好坚持使用它，增加测试步骤。同样，你引入的摩擦越小，你最初的结果就越好。

我不会麻烦构建和维护测试网格；相反，在基础设施和专业知识方面，可以依靠Sauce Labs这样的供应商。通过这种方式，您可以轻松地进行并行化、广泛的平台覆盖、测试资产收集、见解，以及他们在支持测试团队方面的经验。免责声明：我是Sauce Labs的开发者关系经理，所以我可能有偏见；)

至于测试工具；如果你想让你的工程团队合作进行测试生产，你需要坚持他们可以使用的生态系统。这可能意味着他们已经在使用什么。

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

如果黑色星期五让他们的网站不堪重负，请进行负载测试。如果他们的构建总是被破坏，那么集中精力进行单元测试。如果功能在Prod中不起作用，请添加一个集成测试。

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

我们的测试覆盖率远远落后，我们永远无法赶上

这是绝对正确的。。。。如果你从不开始！再加上防止创伤的测试，你已经在增加价值；下次你会碰到那个问题的。

另一个陷阱是设置测试覆盖率目标。测试覆盖率是监控您的流程的好方法，但也是改进的糟糕方法。迫使您的团队增加测试覆盖率(或不让它溜走)，他们会开始怨恨流程。。。写垃圾测试只是为了提高百分比。

相反，使用覆盖范围进行反馈。如果在提交过程中覆盖率下降，讨论原因并讨论如何改进。如果覆盖率下降，你可能想做点什么，但在开始时稍微下降是可以的。

假设你已经涵盖了被雇佣的创伤，那么增加测试覆盖率最好是在工作的基础上进行。如果开发人员正在编写新代码，则会进行测试。如果开发人员正在修改旧代码，它会通过测试(至少)来证明修改是有效的，最好是证明它们也不会破坏旧功能。

您可能会遇到无法测试的旧代码。现在是重构代码的好时机。如果人们害怕重构，因为它可能会崩溃，请指出这正是测试的目的。试着把自己拉到一个可以测试的水平。如果你不能测试一个单元，那就测试这个类。如果不能测试类，请测试包。然后，回去重新开始工作。总有一天你必须这么做。

哦，不，我们很快就会用新的Buzzshooper实现取代Fizzwangle；没有必要为了可测试性而冒重构的风险。

这是个谎言。即使他们说的是实话，那也是一个谎言。Buzzhooper不会很快来。重新扮演那个混蛋。

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

看看像页面对象模型这样的前端测试技术。测试代码应该将实现细节知识(例如，元素定位器)限制在最少的位置，这样更改就很容易实现。

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

查看过去的会议讨论，如SauceCon Online。

在线测试会谈有一些很棒的讨论，是我发现的最接近新冠肺炎期间现实生活中聚会的事情。

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