Testing 启动测试部门

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

---

谢谢

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

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

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

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

选择工具 无关紧要。大部分

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

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

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

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

我不会费心构建和维护测试网格；相反，在基础设施和专业知识方面依赖于类似的供应商。通过这种方式，您可以轻松实现并行化、广泛的平台覆盖、测试资产收集、洞察以及他们在支持测试团队方面的经验。免责声明：我是沙司实验室的开发者关系经理，所以我可能有偏见；）

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

如何开始测试 选择要测试的内容 你的组织非常需要测试，他们正在雇用你。这意味着有一个创伤事件，他们希望避免再次发生。所以，从这里开始。找出它是什么，并为它创建一个测试

如果黑色星期五淹没了他们的网站，请进行负载测试。如果他们的构建总是失败的，那么集中精力进行单元测试。如果功能在Prod中不起作用，请添加集成测试

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

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

这是绝对正确的。。。。如果你从未开始！加上防止你在船上遭受创伤的测试，你已经在增加价值；下次你会发现那个问题的

另一个陷阱是设置测试覆盖率目标。测试覆盖率是监视流程的一个很好的方法，但却是改进流程的一个糟糕的方法。强迫你的团队增加测试覆盖率（或者不让它溜走），他们就会开始对这个过程感到不满。。。写垃圾测试只是为了提高百分比

相反，使用覆盖率作为反馈。如果在提交过程中覆盖率下降，请讨论原因并讨论如何改进。如果它下降的方式，你可能想做一些事情，但一点点下降，而你开始是好的

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

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

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

这是一个谎言。即使他们是真心的，那也是谎言。Buzzshooper近期不会来了。重构那些垃圾

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

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

哦，还有，你的代码就是代码。学习