我正在寻求一些“智慧的人群”估计或有关洞察力的权威参考的指针
，尽管有许多不同类型的测试，但下面列出了这些列表：
手动探索性测试（通过用户界面或API进行随机即席测试）
手动端到端测试（预定义的用户界面驱动测试）
自动化端到端测试
手动集成测试
自动化集成测试
自动化单元测试
，并给出了以下技术和应用： >面向消费者的电子商务网站
基于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
就我建议的一种更好的做法，我希望看到更多类似的东西：
后记：
后记：我对整个“主观”事物感到困惑，并试图根据SQ的六项准则来提出这个问题（请注意，这个问题对程序员来说是封闭的，所以这不是答案）。无论如何，鉴于六项准则，我认为这使他们感到满意。只需回顾一下：
启发解释“为什么”和“如何”的答案-诚然在这里有些薄弱，但是我很清楚地要求“如何”需要长短不短的答案-再次，有人可以用五个数字组成的字符串来回答，但我希望能对他们为什么选择这种特定组合有一些见识。希望提供我目前的情况和希望的情况的估计不会破坏这种特征
鼓励经验多于观点-我认为这很清楚地要求人们正在做些什么以及为他们做什么工作
坚持观点得到了事实的支持-我希望人们能说出他们的测试组合的真相（分析确定他们的组合成功的原因将是额外的收获，请参阅＃1,2和4）
好玩-我希望在这里学到一些东西
#1 楼
您在问一个独角兽问题。为什么？
，因为您已经跳过了所有工作的重点。如果您不知道利益相关者想从中了解什么信息，那么您进行不同类型的测试的比例如何，组织是什么都无关紧要，所使用的技术也不重要。您的测试。
就这样。那很重要。而且，如果不从此开始，无论您做什么，都将注定失败。您可能会提供一些有用的信息，但这将是偶然的，而不是设计的。
找出您的利益相关者，您的产品所有者，内部消费者，开发人员想知道的内容。什么问题对他们来说很重要，不是我，不是Sam，不是这个星球上的其他任何人。您可以向他们提供哪些信息，这将使他们对自己的建筑做出不同的决定。
测试本身并不能使任何事情变得更好。它只是向那些将要变得更好，并且会变得更好的人提供有用的信息。如果您不知道最关注哪种问题，哪种错误将代表对产品价值的最大威胁，那么您就无法选择测试类型的组合来最大程度地发现问题这些问题。除此之外，没有最佳实践，那就是：做有用的事情，迭代，保持思考，与利益相关者保持对话。都没有附加数字。
恐怕您是从错误的结尾开始的。我同意user246，这里没有人可以给您这些答案。除了你。
评论
我希望我可以多次投票赞成。安娜在这里提出了几点要点。
– Bj Rollison
2011年10月21日23:25
#2 楼
我无法确定您是在寻找倡导某种资源组合的研究，还是只是在描述某种资源组合的经验的研究。除了可以在Google搜索中找到的内容外，我还不知道有任何此类研究。他们倾向于专注于难以手动测试并且不太可能在开发过程中进行测试的事物：例如压力测试。我们没有使任何UI测试自动化，因为它变化如此频繁，以至于我们不认为自动化值得投资。开发人员有时会编写API级的单元测试，但通常不会。在那家公司，我相信我们的资源组合已经接近您公司的当前组合。在您的问题中，您说您想将大部分测试资源从手动测试转移到自动测试。您组织的正确组合取决于此论坛中没有人可以衡量的考虑因素：例如，组织中的技能，组织的兴趣水平以及自动化的维护成本（您没有提及在您的问题中）。我认为您描述了一个合理的目标，但我建议您从您认为最简单和/或最有价值的目标开始逐步实现它。我相信这会增加您成功的机会。当出现问题和机会时，它还将使您有机会进行中途更正。
#3 楼
我会回答一个问题。我认为其中一些不属于我，其中一些我需要分为几个问题：我的测试应该占多大比例1）探索性测试2）端到端测试3）集成测试。不幸的是，该问题的答案很大程度上取决于产品本身，应在产品计划阶段确定并记录在测试计划中。
一个完全独立的问题是-我应将测试的百分比自动化吗？
答案很简单。如果自动化测试用例比手动测试能获得更好的投资回报，则可以自动化。这意味着，如果开发自动测试，维护该测试并执行该测试所需的时间少于在产品的整个生命周期中运行手动测试的总时间，那么将其自动化是有意义的。其他可能起作用的因素是对自动测试还是手动测试的信心。人类可以犯错误，跳过步骤，将测试标记为通过（即使他们没有真正通过），错误地解释指令等。类似地，自动化可能会出现错误，并且您认为正在测试的自动化测试可能会完全跳过重要的验证。 。
单元测试和探索性测试似乎并不适合我。几乎所有可以进行自动化单元测试的东西都应该具有自动化单元测试。此处的目标是100％，不包括任何主要障碍。通常，在我将其余大部分测试自动化后，我会尝试做更多尝试。在这里，您可以找到大多数错误，并在其中找到其他测试用例，以将它们添加到列表中以在构建之上运行。通过探索性测试找到的新测试用例可以随后实现自动化。回归测试，无论是手动还是自动的，很少会发现新的错误，它可以防止回归，并为您提供覆盖范围和信心。
#4 楼
没有确定百分比和分布的黄金法则。这取决于组织中遵循的应用程序，复杂性，技术，测试过程
这必须根据您当前的团队组合，曝光度，经验
从建议的分布，自动单元测试和自动插入测试中确定。需要一个很好的飞跃。这表明您对自动化感兴趣。
您尝试过使用免费工具来自动化您的应用程序吗？不仅仅是您的组织试图为工具/自动化资源提供资金。我建议您自动化回归案例。这也将显示出强调管理需求/对自动化投资的方法
从60％的手动探索性测试减少到5％是一个大目标。我建议以较小的里程碑进行评估。尝试每月实现5-10％的自动化并将其定位。确定要自动化的测试用例/需要花费时间来学习/开发自动化
您还可以组成一个对自动化开发感兴趣的测试人员小组。来自您的学习/作为一个团队。您可以共同启动这项计划
，因为它是面向客户的电子商务网站，您是否尝试过评估Selenium使其自动化
#5 楼
这个话题让我想起了关于Testivus的有趣故事，他是大师级回答“需要多少测试覆盖率”的问题。对于每一个要求的学生，Testivus都有不同的答案。答案取决于提出问题的人。
开个玩笑，对于我们的应用程序（面向Web应用程序的用户，js / java / apache / tomcat / oracle），我们将针对UT的自动化测试的目标定为50％，将功能/ api的目标定为30％，将系统级别的目标定为20％回归。最重要的是，我们添加了手动回归测试以确认自动化的结果，并且实际的外观/感觉是正确的。在该项目的生命周期中。早期，主要是探索性的手动测试。随着项目的发展，越来越多的自动化被添加。
关于您的问题，您正在询问资源分配。资源分配很难回答。您可能需要一段时间“自动化”自动化才能赶上您想要的位置。但是，这需要平衡您提供新内容的需求。
祝你好运。
评论
我认为更多的背景信息可能会有所帮助。根据应用程序的类型，所使用的技术等，答案可能是相反的。我同意Lyndon希望提供您的环境的详细信息。如果您使用的是Web服务，则它与旧订单输入系统有很大不同！
这样做的问题是它会导致列出各种答案。更好的问题可能是“什么是良好的测试范围？”，可能包含有关系统类型，团队技能水平等方面的详细信息。某些问题可能只有一个“最佳”答案。而且，我的团队所做的并不是我所说的最好。我们采取捷径并且做事不完美，因为我们的质量检查流程还不太成熟。
我认为这个问题的部分原因在于这是变相的讨论，StackExchange不太适合。也许您最好在聊天中讨论这个问题？恕我直言，这样更有可能获得您可用的反馈。
感谢所有提供答案并参与“非对话”的人。