没有自动化测试的软件开发周期

Question

我在为 WordPress 开发插件并将它们推送到我的 git 存储库时处于一个令人困惑的境地。 WordPress 在 AWS 服务器上，每次推送到 git 时，我都必须使用弹性 beanstalk 创建一个新环境。

一旦我推送到 git，我首先创建一个 DEV 环境并将我想要推送到生产的更改拉取。前任。我有更改：c1、c2、c3、c4、c5，我想推送 c1、c2、c3。我拉动更改并创建 DEV。然后我创建测试环境进行测试。一旦通过，我将创建 UAT（客户测试环境）。假设客户不喜欢 c3，要求我们只推送 c1 和 c2。在这种情况下，我必须重新创建 DEV、TEST 和 UAT 环境并重新测试，因为删除 c3 也可能会影响其他代码。我必须将代码发送到 UAT，因为那时我重新打包了代码，因此需要一个新的 UAT。

我正在寻找一种方法来减少向 UAT 发送相同代码的次数。从技术上讲，我不应该再次向 UAT 发送相同的代码。

我正在考虑单独推动每个更改，而不是将它们打包在一起；这将消除 UAT 中的冗余，但会增加测试团队的工作量，这将导致瓶颈。

PS。我无法创建自动化测试，因为更改主要是关于图形和视觉效果。此外，还有数千页要测试。为所有内容编写测试脚本是没有意义的。有什么建议吗？

Answer 1

从技术上讲，您不会向 UAT 发送相同的代码：在 c3 拒绝之后，您发送回 c1+c2，而不是 c1+c2+c3 - 不是相同的代码。

很遗憾，对于基于提交后验证的集成解决方案，并没有真正确定性的方法来最大限度地减少 UAT 提交的数量。那是因为您无法提前知道哪个提交会导致 UAT 拒绝。

正如您所注意到的，最可预测的前进方式也是最昂贵的 - 为每次更改运行 UAT。减少 UAT 提交的唯一方法是将多个更改捆绑在一起提交 - 捆绑包越大，提交的 UAT 越少。但这引发了一个冲突：UAT 失败的机会也随着包的大小而增加，识别罪魁祸首所需的二等分重试次数也会增加（假设每个包只有一个，如果有几个，那就更糟了） .

我会对最近 2-4 周左右的 UAT 提交进行分析，并确定在多大的捆绑包中 UAT 被拒绝的概率达到 30-50% 左右，然后选择 2 的最大幂低于该值（对于发生故障时需要执行的二等分更好）。例如，假设分析建议值为 5，然后选择 4 作为捆绑大小。

如果您没有足够的更改来填充捆绑包，我建议您再次选择 2 的最大幂并将其余部分留给下一个捆绑包 - 同时其他更改可能会合并，也许您可​​以填充它下一个捆绑包。除非您已经知道变更集之间的依赖关系，这需要它们在同一个包中一起使用，并且可能会使您处于首选值之间。是否将这些依赖项（风险较高）全部用于下一个捆绑包，由您决定。

您还应该继续监控捆绑包大小与 UAT 拒绝趋势的可能性（产品和 UAT 都在发展，情况会发生变化） - 您可能需要不时调整首选捆绑包大小。

旁注：您始终可以构建一些自定义 UAT 包装脚本，使其显示为可以连接到 CI/CD 管道的自动化测试。只有它会有不确定的队列等待和/或执行时间。而且，如果它确实是手动执行的，它也可能更不可靠。