您的团队使用不同类型的软件测试的比例是多少？

Question

注意:我已经在SO和p.SE上问过这个问题了，它被关闭了。我不是在玩游戏，我只是想找个家:)

我正在寻找一些“人群智慧”的估计，或者是一个权威参考的指针，以洞察测试中分配精力的最佳实践。

虽然有各种各样的不同类型的测试，但考虑到以下列表：

• 手工探索性测试(通过用户界面或APIs进行随机即席测试)
• 手动端到端测试(预定义的用户界面驱动测试)
• 自动化端到端测试
• 人工集成测试
• 自动集成测试
• 自动化单元测试

并考虑到下列技术和应用：

• 一种灯罩
• 面向消费者的电子商务网站
• 基于REST的业务逻辑中间层，供网站和内部面向后台的应用程序使用
• 后台应用程序(库存/订单管理、仓库物流、BI)

并考虑到以下组织：

• 定义面向用户的网站的产品管理
• 前端的每个人都是PHP编码器，有些人还擅长javascript/css
• 中间层是java。
• 后台应用程序目前是PHP并迁移到java。
• 后台应用程序由内部消费者(采购、金融、仓库等)定义。

让我们考虑一下执行测试活动所花费的总时间(开发人员创建单元和集成测试，测试工程师创建和执行测试计划，测试工程师创建工具和工具并运行它们)。

问题：

有没有人有关于这种资源分配的权威研究的指针？

例如，在我的公司，我猜这就是我们目前的组合：

60% Manual exploratory testing
10% Manual end-to-end testing
10% Automated end-to-end testing
 5% Manual integration testing
 5% Automated integration testing
 5% Automated unit testing

至于我关于更好地练习的建议，我更希望看到这样的东西：

 5% Manual exploratory testing
 5% Manual end-to-end testing
10% Automated end-to-end testing
 5% Manual integration testing
20% Automated integration testing
55% Automated unit testing

我会非常感激任何帮助找到一些肩膀站起来，以帮助指导我的团队。

Postscript:我对整个“主观”的问题感到困惑，并试图按照SQs的六条准则来构思这个问题(请注意，这个问题是针对程序员的，所以这不是答案)。不管怎么说，考虑到这六条准则，我认为这让他们满意。只想回顾一下：

• 启发解释“为什么”和“如何”的答案
• 需要长而不短的答案
• 有建设性的、公平的、公正的语气--我希望提供我目前和希望的情况的估计不要破坏这一特性。
• 鼓励经验而不是意见--我认为这很清楚地要求人们做什么，为他们做什么。
• 坚持意见是有事实根据的--我希望人们能说出他们的测试组合的真相(分析他们的组合成功的原因将是一种奖励，见#1,2和4)。
• 不只是无聊的社交活动--我希望在这里学到一些东西

Answer 1

你在问独角兽问题。

为什么？

因为你已经跳过了所有的工作。您所做的不同类型的测试中，有多大比例并不重要，不管您的组织是什么，如果您不知道您的利益相关者希望从测试中发现什么信息，那么使用什么技术也无关紧要。

就这样。这才是最重要的。如果你不从那开始，不管你做什么，你都注定要死。您可能会提供一些有用的信息，但这将是偶然的，而不是通过设计。

了解您的利益相关者，您的产品所有者，您的内部消费者，您的开发人员想知道什么。什么问题对他们来说是重要的，不是我，不是山姆，也不是地球上的任何人。你能向他们提供什么样的信息，使他们对你所建立的一切做出不同的决定。

测试本身并不能使任何事情变得更好。它只是提供有用的信息给人们谁将作出更好的事情，使事情更好。如果你不知道什么样的问题最让你担心，什么样的错误会对你的产品的价值构成最大的威胁--那么你就不能选择你的测试类型来给你找到这类问题的最佳机会。没有最好的实践，除了:做有效的事情，迭代，不断思考，继续与你的利益相关者交谈。所有这些都没有附加号码。

恐怕你的出发点是错误的。我同意user246的观点，这里没有人能给你那些答案。除了你。

Answer 2

我不知道你是在寻找倡导某种资源组合的研究，还是仅仅是描述某种资源组合的经验的研究。除了我在谷歌搜索中会发现的以外，我不知道有任何这样的研究。

在我之前的一份工作中，QA人员中有几个非常有才华的开发人员。他们倾向于专注于那些既难以手工测试又不太可能在开发过程中被测试的事情:例如，压力测试。我们没有自动化任何UI测试，因为它变化太频繁，以至于我们不认为自动化值得投资。开发人员有时会编写API级别的单元测试，但通常没有。在那家公司，我相信我们的资源组合更接近于贵公司目前的资源组合。

在您的问题中，您说您希望将大部分测试资源从手动测试转移到自动化测试。组织的正确组合取决于本论坛中没有人能为您衡量的考虑因素:例如，组织中的技能集、组织中的兴趣水平以及您的自动化的维护成本(您的问题中没有提到这一点)。我认为你描述了一个合理的目标，但我建议你逐步接近它，从你认为最容易和/或最有价值的目标开始。我相信这会增加你成功的机会。当问题和机会出现时，它也会给你机会进行中途修正.

Answer 3

• 没有金科玉律来决定百分比和分配。这取决于组织中遵循的应用程序、复杂性、技术、测试过程
• 这必须根据你目前的团队组合、暴露程度、经验来决定。
• 从您建议的发行版来看，Automated测试和Automated测试取得了很大的飞跃。这表明了你对自动化的兴趣。
• 您是否探索过，尝试过免费的工具来自动化您的应用程序。超过您的组织试图资助一个工具/自动化资源。我建议你用自动回归的方法。这也将显示如何突出管理需求/效益投资于自动化。
• 从60%的手工探索性测试减少到5%是一个大目标。我建议用较小的里程碑来评估。试着每月实现5-10%的自动化，并瞄准它。识别要自动化的测试用例/投入时间学习/开发自动化是必需的
• 您还可以组成一个对开发自动化感兴趣的测试人员小组。从你的学习/作为一个团体工作。你们可以一起工作来启动这项计划。
• 由于它是一个面向客户的电子商务网站，您是否尝试过评估Selenium来实现它的自动化。