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

时间:2012-02-08 13:37:54

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

我的公司正在与多元测试供应商合作(我暂时无法透露哪一个),并且我被要求将他们的系统集成到我们的旗舰B2C商务网站。

通常,“整合”这个词是一个重要的术语。但是,这意味着在多个视图上添加<script>标记,然后从该点开始循环。多元化实验将由我们的营销部门(和/或供应商)建立。我们的开发团队将不会参与其中,甚至可能不知道它何时发生。

基本上,我被告知故意在我们的旗舰应用程序中添加一个JavaScript注入攻击向量......并希望最好。我担心的不是恶意代码,而是无意中搞砸了。我们的CSS和基本页面布局已经很乱了,我预计当其他人的多变量实验爆炸出主页看起来很麻烦等时会产生热量。更重要的是,有很多丑陋的AJAX和服务器端这取决于可预测的HTML元素,id属性等等......因此,如果实验过多地改变HTML元素,核心商务功能将以不可预测的方式完全破坏。

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

鉴于上述所有情况,是否有任何可用于减轻其中一些风险的做法?多变量测试是一个新领域,Google搜索的前几页包含销售流行语的阴暗顾问对CIO来说。对于最终负责关注风险的内部技术受众而言,并没有太多的内容。在上述限制下是否有任何方法可以正确进行质量保证,或者在这种情况下是否只能推迟(*)?

(*)注意:鉴于供应商关系的政治性,我们需要建立一个非常密切的推回案例,无论如何它可能会被忽略。

1 个答案:

答案 0 :(得分:0)

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

含义......供应商要测试的内容在部署到其平台之前仍应通过一些质量保证流程。这应该表明,减轻您所担心的风险的最佳方法是让自己注入测试/预发布周期,以确保代码在发布之前的安全性和稳定性。你不需要(也不想)通过完整的回归测试或其他任何事情来努力。但是,您可以主动为动态内容设置一组高度特定的测试,然后再进行生成。

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

或者......在供应商的练习中获得豁免签署,以免您承担任何安全或履行责任。 :)