0

我处于一个令人困惑的境地，我为 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。我无法创建自动化测试，因为更改主要是关于图形和视觉效果。此外，还有数千页要测试。为所有内容编写测试脚本是没有意义的。有什么建议吗？

4

1 回答 1

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 管道的自动化测试。只有它会有不确定的队列等待和/或执行时间。而且，如果它确实是手动执行的，它也可能更不可靠。

于 2018-02-15T04:54:34.753 回答