作为一个组织，我们希望转向持续集成/持续交付，在这种情况下，对代码更改进行自动测试，例如通过詹金斯。将来，我们可能会使用CD来自动发送这些更改
使用CI / CD时，您是否还需要测试计划？您如何确保已正确测试产品，包括功能和非功能测试？使用CI / CD时，质量检查可以提供什么监督？
#1 楼
我认为CI / CD与非CI / CD流程没有什么不同，测试只是由非人类实体运行。您是否需要测试计划（或计划测试）？当然，您确实需要这样做，您需要考虑将什么自动化，以及应该手动完成还是在生产中进行测试（A / B测试，遥测），分析与以这种方式而不是另一种方式进行测试相关的风险，并评估测试水平在每个阶段。
您可以像使用前的报告，仪表板一样监视结果的质量，并分析日志，数据和用户错误报告
#2 楼
使用CI / CD时是否还需要测试计划？
是的。因为测试计划将至少告诉您您在问题中未指定的内容：您打算多长时间运行一次测试？哪些测试将以哪个周期运行？
也许每天晚上都有常规做法。对您的项目可行吗？您有哪些选择？为什么一种方法比另一种方法更好/更坏？
哪个测试将“连续”执行？顶层/功能相关？建筑的？单元测试？
您可以自动测试所有内容吗？您的系统是否依赖于其他系统？如何管理和测试其他系统的更改？
即使“连续”听起来如此之好，也根本不是连续的。充其量是周期性的。这就是为什么您实际上需要提前计划的原因。
另一个问题：当某些测试用例失败时会发生什么？
连续的与周期性的
河流是连续的。即使上面有冰。测试不能连续进行。
代码必须先达到一定的“成熟度”，然后才能进行测试。最小的先决条件是它是可编译的。
交付的最小先决条件是某些测试用例必须通过。如果失败，则说明该产品不安全。
测试套件需要时间。您不会在任何时间执行所有操作。它开始，然后结束，然后从存储库中获取新的SW版本，并且测试再次开始并再次结束...
因此，只有在以下情况下，此类系统才能称为“连续”系统：现实的许多实际细节都被忽略了，因为通常是出于营销和广告目的。
评论
“它根本不是连续的。充其量是周期性的”您是否表示不能实现每个代码库快照的交付，而只能在特定时间段内实现？
–JoãoFarias
19-10-15在7:06
@JoãoFarias一方面，对代码库的更改是在不连续的阶段进行的，所以-从某种意义上讲，它只能是逐步的而不是连续的。更一般而言，运行一套测试将花费一定的时间，因此新的“测试版本”不能持续可用，只能定期使用（最短的时间取决于测试完成所需的时间） ）。
– TripeHound
19-10-15在8:34
@JoãoFarias：我在答案中添加了澄清“连续的”还是“定期的”。抱歉，我从一开始就没有这样做-对我而言，我的主意总是很明显:)
– virolino
19-10-15在8:39
@TripeHound：完全是我的意思-我们同时添加了解释。 +1
– virolino
19-10-15在8:39
好吧，如果我们看原子水平，那条河流会离散地流动。一切都取决于POV。在持续交付中，可部署单元定义为绿色提交。如果为每个新的绿色提交创建了一个新部署，则在其创建（编码+测试）后立即进行部署。如果您累积要一起部署的绿色提交，则不是。
–JoãoFarias
19-10-15在9:03
#3 楼
不，您需要一个测试策略。一个计划表明它已经结束了，而您的产品SDLC却是无限的。测试策略应该成为团队的指导方针，他们应该执行哪种类型的测试以及它带来什么价值，而不是如何以及何时进行。自动构建管道，例如：渗透测试
风险分析（例如GDRP数据保护影响评估）
质量社区等。 。
#4 楼
作为“传统”测试计划的替代方法（我们将做的事情-基于清单），您可以专注于建立测试策略（我们想做的事情-基于准则）。已知的模型是启发式测试策略模型：
HTSM将测试创建思路划分为不同的分析轴，当统一起来时，测试人员可以创建整体测试策略。这些轴如下：
项目环境包括资源，约束以及项目中可能启用或阻碍我们测试的其他元素。有时测试人员必须挑战约束，有时甚至接受约束。
产品元素是您要测试的东西。软件是复杂且不可见的。请谨慎地涵盖所有重要的软件，而不仅仅是易于理解的部分。
质量标准是规则，价值和来源，可让您作为测试人员确定是否产品有问题。质量标准是多维的，通常是隐藏的或自相矛盾的。
测试技术是用于创建测试的试探法。所有技术都涉及对项目环境，产品元素和质量标准的某种分析。
感知质量是测试的结果。您永远无法知道软件产品的“实际”质量，但是通过应用各种测试，您可以对其进行明智的评估。 （完成的工作）并限制团队的工作方式，您可以是外部人，着眼于提出问题，使团队可以反映他们的行为是否与HTSM相符。本身将成为一个自组织的实体，能够理解其上下文并执行需要完成的工作（这使您可以自由地做其他事情）。
评论
正如答案所说，是的。但是，请确保重点始终放在测试增加的价值上，并不断对其进行审查。尽管需要测试计划，但它可能是创建大量测试套件（无论是手动还是自动）的开始，并且要逐渐地重构和删除测试以保持套件的快速和精简，这需要成熟。只要在每次有新功能或更改功能时添加更多测试，就可以迈向缓慢。考虑限制测试运行时间以强制选择的KPI。这将迫使更多的单元测试，因为它们是如此之快。接近/使用CI / CD进行测试的详细信息也应该成为高级测试计划的一部分。