【问题标题】:How do you mitigate risk when introducing multivariate testing into a dynamic web application?在将多变量测试引入动态 Web 应用程序时,您如何降低风险?
【发布时间】:2012-02-08 13:37:53
【问题描述】:

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

通常,“集成”这个词是一个沉重的术语。然而,这里的意思是在几个视图上添加一个<script> 标签,然后从那一点开始退出循环。多变量实验将由我们的营销部门(和/或供应商)设置。我们的开发团队不会参与其中,甚至可能不知道何时发生。

基本上,有人告诉我要故意将 JavaScript 注入攻击向量添加到我们的旗舰应用程序中......并希望最好。我的担忧与其说是恶意代码,不如说是无意中搞砸了。我们的 CSS 和基本页面布局已经一团糟,我预计当其他人的多变量实验炸毁主页外观等时会引起热议。更重要的是,有很多丑陋的 AJAX 和服务器端依赖于可预测的 HTML 元素、id 属性等的杂乱无章的东西......因此,如果实验对 HTML 元素进行过多更改,核心商务功能将以不可预知的方式完全崩溃。

由于缺乏真正的测试环境,我的担忧被放大了。供应商进行过滤,以便只处理来自我们生产 URL 的 AJAX 调用。来自我们的开发或 QA 环境的调用将被忽略。但是,这与拥有测试环境不同。相反,这意味着生产现在是我们每个实验的测试环境。

鉴于以上所有情况,是否有任何可用于减轻其中一些风险的做法? 多变量测试是一个如此新的领域,Google 搜索的前几页由销售流行语的阴暗顾问组成给 CIO 的。对于最终负责关注风险的内部技术受众,没有太多的文章。有没有办法在上述限制下正确地进行质量检查,或者在这种情况下除了推回(*)之外别无选择?

(*) 注意:鉴于供应商关系的政治性,我们需要建立一个非常严密的案例来进行回击,并且无论如何都可以忽略它。

【问题讨论】:

    标签: javascript html testing google-website-optimizer multivariate-testing


    【解决方案1】:

    您需要记住,多变量测试并不是按照您的想法(或者不应该)进行测试。您不应该测试代码或内容。您正在测试访问者对该内容的反应。

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

    如果供应商在 [在此处插入任何材料] 中值得他们重视,那么他们应该已经在他们的流程中考虑到这一点,或者至少能够满足这样的要求。在注入任何入侵风险代码之前,要求您获得一些鸟瞰签名并不过分。

    或者... 签署一份弃权书,免除您在供应商练习期间的任何安全或性能责任。 :)

    【讨论】:

    • 谢谢。事实证明,供应商确实有办法在启动时使实验“处于非活动状态”,但如果我们的 QA 团队向我们的站点 URL 添加特殊的 CGI 参数,他们仍然可以查看。我们还应该能够“激活”实验,以便它们会根据我们的 QA 和 UAT 服务器的请求触发。我不太高兴我们现在需要在进行每次更改之前与外部方进行协商和协调(希望他们为我们做同样的事情)......但这并不是完全就像我昨天早上的印象一样可怕。
    • 开销更大,但理论上对每个人都更好。任何时候企业可以量化他们依赖轶事或主观信息的东西,这都会改善事情。如果您有任何跟进,请随时联系我!
    猜你喜欢
    • 2014-05-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-05-23
    • 2021-02-09
    相关资源
    最近更新 更多