javascript - 在将多变量测试引入动态 Web 应用程序时如何降低风险？

Question

我的公司正在与一家多元测试 vendor 合作(我现在还不能透露是哪一家)，我被要求将他们的系统集成到我们的旗舰 B2C 商务网站中。

通常，“集成”这个词是一个沉重的术语。不过这里的意思是加一个<script>标记多个 View ，然后从该点向前跳出循环。多变量实验将由我们的营销部门(和/或 vendor )设置。我们的开发团队不会参与其中，甚至可能不知道它何时发生。

基本上，我被告知要故意向我们的旗舰应用程序添加 JavaScript 注入(inject)攻击向量……并希望一切顺利。我担心的不是恶意代码，而是无意中搞砸了。我们的 CSS 和基本页面布局已经一团糟，我预计当其他人的多变量实验破坏了主页的外观等时会引起热议。更重要的是，有很多丑陋的 AJAX 和服务器端依赖于可预测的 HTML 元素，id属性等...因此，如果实验对 HTML 元素的更改过多，核心商务功能将以不可预测的方式完全中断。

由于缺乏真实的测试环境，我的担忧更加严重。 vendor 进行过滤，以便仅处理来 self 们生产 URL 的 AJAX 调用。来 self 们的开发或 QA 环境的调用将被忽略。但是，这与拥有测试环境不同。相反，这意味着生产现在是我们每个实验的测试环境。

考虑到以上所有情况，是否有任何实践可以减轻其中的一些风险？多变量测试是一个如此新的领域，Google 搜索的前几页由销售流行语的可疑顾问组成给 CIO 的。对于最终负责关注风险的内部技术读者的文章并不多。在上述限制下是否有任何方法可以进行适当的质量检查，或者在这种情况下除了推回 (*) 之外别无选择？

(*) 注意:考虑到 vendor 关系的政策，我们需要为推回建立一个非常严密的案例，无论如何它都可能被忽略。

Answer 1

您需要记住，多变量测试并不是您认为的(或者，它不应该是)意义上的测试。您不应该测试代码或内容。您正在测试访问者对该内容的 react 。

意思是...您的 vendor 要测试的内容在部署到他们的平台之前仍应通过一些质量保证流程。那么，这应该表明，减轻您所担心的风险的最佳方法是让自己进入他们的测试/预发布周期，以确保他们的代码在发布之前的安全性和稳定性。您不需要(也不想)用完整的回归测试或类似的东西来夸大他们的努力。但是您可以主动设置一组高度特定的测试，以便动态内容在投入生产之前通过测试。

如果 vendor 在 [在此插入任何 Material ] 中值得他们重视，那么他们应该已经在他们的流程中考虑到这一点，或者至少能够满足这样的要求。在注入(inject)任何具有入侵风险的代码之前，要求您获得一些鸟瞰图并不过分。

或者...签署一份弃权书，免除您在 vendor 演习期间的任何安全或性能责任。 :)