AKAMAI 白皮书

零售网站和应用性能 测试完整指南

目录

零售网站和移动设备测试入门 ...................................................................................................... 1

在线零售商面临的一些常见性能挑战有哪些？ .............................................................................. 2

入门：性能测试检查表 .................................................................................................................. 2

在线零售的主要业务指标有哪些？ ............................................................................................... 3

到底多快才算足够快？ ................................................................................................................. 3

测试团队应包含哪些人员？ .......................................................................................................... 4

测试时要注意什么 ........................................................................................................................ 5

性能测试类型 ............................................................................................................................... 6

生产中测试与实验室中测试比较 ................................................................................................... 6

性能实验室中的测试 .................................................................................................................... 7

生产中测试（是的，可以完成） ..................................................................................................... 8

安全和性能测试 ..........................................................................................................................10

附录 A：Akamai 性能测试方法 ...................................................................................................11

附录 B：CloudTest 性能数据问答 ................................................................................................12

零售网站和应用性能测试完整指南 1

零售网站和移动设备测试入门在压力重重的在线零售业中开展竞争的零售商面临着很多挑战。您不仅需要提供有趣和吸引人的

购物体验，还需要让这种体验快速可靠。

几乎一半的在线购物者说，如果页面的加载时间超过 2 秒，他们会放弃加载页面。在传统的实体

店场景中，如果要放弃一家店而选择另一家店，那么消费者就要从出口离开，再走到竞争对手的

店里。而在网络上，只要点击几下鼠标就可以转投竞争对手。

提高页面加载速度是经过事实验证的一种提高转化率和收入的策略。

在 Walmart.com，加载时间每加快 1 秒相当于转化率

提高 2%。Staples.com 每次将平均中间加载时间节省 1

秒，则意味着转化率提高 10%。

网站缓慢或不可用可能会对客戶保持率产生持久的 影响。

页面中断和延迟不仅仅影响收入。Akamai 研究了页面中

断与加载缓慢对在线零售网站放弃率的影响。他们的发现

让人吃惊：出现故障的网站永久放弃率平均达到 9%。运

行缓慢的网站永久放弃率达到 28%。

生产中测试是确保在线应用程序按预期运行的唯一方法。

针对生产基础设施的外部测试是真正了解实际容量和性能的最佳方式。（当然，这并不排除在实验室环境中进行测试的

需要，也不能泯灭在实验室环境中进行测试的好处。在两者之间保持连续性非常重要。）

那么，您如何树立这样的信心，您的在线商店将提供出色的购物体验，并可以应对因季节性上涨、活动和促销引起的流

量高峰？您应如何衡量成功？

本指南旨在回答以下问题，从而帮助您开始：

• 在线零售商面临的一些常见性能挑战有哪些？

• 您的性能测试检查表主要包含哪些内容？

• 在线零售的主要业务指标有哪些？

• 测试团队应包含哪些人员？

• 您应该运行什么类型的测试？

• 测试时应该注意什么？

• 为什么要在实验室里测试？为什么还要在生产中测试？

让我们开始吧！

44%的用户表示，缓慢的在

线交易让他们无法确定

交易是否能成功。

零售网站和应用性能测试完整指南 2

在线零售商面临的一些常见性能挑战有哪些？在线商店努力模仿他们自己的实体店。这是因为购物者习惯于去实体店，并且在作出决定之前可以用眼睛看、用手触

摸，与产品亲密接触。

网页不能提供与实体店同样水平的互动性，但是得益于许多出色功能，如视频、推荐引擎、用户评论、多角度展示产品

的高分辨率图像，以及让您“试穿”服装的工具，零售网站提供了前所未有的购物体验。

此外，在线传达您的品牌理念也不无挑战。样式表和自定义字体可以控制您品牌的呈现方式，但是这些功能可能会以降

低网站的性能和可用性为代价。

平衡性能与旨在实现特定设计目标的丰富内容十分困难。

在幕后，用于支付处理、授权、库存检查等功能的后端系统也可能增加性能挑战。

最后，许多这些功能 - 从用户评论到自定义字体再到付款处理 - 都由第三方创建和托管。这些内容可能会为您的网站添

加功能或信息，但同时也带来了难以控制的流量和复杂性。

了解所有这些内容的影响对于管理网站的整体性能至关重要。

入门：性能测试检查表制定成功的测试策略是成功的性能测试参与的关键。首先了解您的用户如何与您的在线零售网站互动。

例如，以下信息对于定义测试参与策略至关重要：

• 网站访问者遵循的主要业务流程

• 用户在网站上停留的平均时间

• 完成购买的用户与仅浏览的用户的平均百分比

• 放弃率以及用户在流程的哪个位置放弃

• 每小时并发用户的平均数和峰值数

• 每分钟/每小时的平均页面浏览量和峰值页面浏览量

• 每分钟/每小时的平均订单量和峰值订单量

• 针对特定活动（如黑色星期五或网购星期一）的上述指标的流量模式差异

• 网站流量来源的地理区域

• 来自移动设备的流量百分比、设备类型、用户流的差异以及对上述指标的影响

• 如果使用 CDN，则包括从 CDN 提供的内容的百分比

此信息有助于定义成功的性能测试策略，并推动测试的构建和执行方式。

零售网站和应用性能测试完整指南 3

在线零售的主要业务指标有哪些？ 在线零售网站具有特定的关键性能指标 (KPI)，这些指标可帮助您测量网站的性能：

• 每分钟订单数量 — 对于在线零售网站，在一段时间内完成的订单是黄金标准 KPI。订单直接转化为收入。

• 每小时或每分钟的网页浏览量 — 客户只能在有效使用网站的情况下才能完成订单。确保用户在搜索、比较和交互

时，在线零售网站能够服务 Web 内容至关重要。

• 每小时会话数 — 会话是个人用户或系统与网站之间的交互。确保这些用户在交互期间能够建立和维持会话非常

重要。

• 错误 — 虽然看似显而易见，但跟踪总体错误率和您收到的错误类型至关重要。并非所有的错误都是同等重要的。

• 平均响应时间 — 了解平均需要多长时间来提供页面和页面资产对于发现潜在瓶颈至关重要。它也是许多客户衡量

在线零售网站效用的基础。

• 90% 的响应时间 — 这在响应时间方面提供了更精细的粒度级别。90% 排除了最慢的 10% 响应时间。这消除了超

时（超时平均为 120 秒），同时给出了 90% 的用户所获得的响应速度的真正指标。

到底多快才算足够快？追求良好网站性能的零售商的平均响应时间小于 3 秒，90% 的响应时间小于 2.75 秒。

对于希望确保其网站在性能方面保持领先的零售商而言，他们需要了解到底多快才算足够快。

值得注意的是，对不同类型的页面用户的期望不同。例如，浏览网站的用户期望闪电般的响应时间，而结账过程的最后

一步通常需要更长的时间。

如果一个在线零售网站可以在使用 150-200% 的预期峰值负载进行测试的情况下保持目标性能水平，那么零售商可以更

自信地应对任何营销活动或假期高峰。

零售网站和应用性能测试完整指南 4

测试团队应包含哪些人员？让合适的人参与测试执行非常重要。

当合适的人员组合在一起时，测试的效率会更高。在出现问题时，拥有合适的团队可以使这些问题得到迅速处理，并在

提供可靠的情报时制定决策。

您的公司和员工的规模、网站的规模、测试的复杂性，您是否外包开发或在您的网站中部署第三方应用程序，使用托管

服务提供商负责基础设施等等，所有这一切都影响到参与测试的人数。

某些情况下，测试由一到两个人负责。在其他情况下，如完全重建一个网站或测试一个受欢迎的网站以进行季节性的准

备，此时就会有许多人各负其责，从架构师到负责基础设施特定元素的人员。

作为测试策略的一部分，有很多责任需要承担：

• 协调 — 与所有关键利益相关者协调测试活动。这包括应用程序工程、运营、供应商和第三方连接服务，以及业务

和高级领导。

• 沟通 — 测试结果、问题、问题解决计划、业务总体策略进度和工程技术领导的沟通。

• 策略 — 总体策略的定义包括建立应用程序业务流程、关键性能指标、容量计划、监控覆盖率以及参与软件开发生

命周期性能管理方面的个人测试计划。

• 架构 — 提供有关为新项目创建高性能应用程序和基础设施架构或改进现有应用程序的最佳实践。

• 测试创建 — 将业务流程定义转变为可执行测试，通过容量计划创建单个性能测试工作负载，并持续维护当前的测

试用例库。

• 测试执行 — 在性能实验室和生产环境中执行持续性能测试，并提供测试结果。

• 分析 — 查看所有环境的测试结果，并分析与以前测试相关的性能。对任何违反既定成功标准、可能违反关键性能

指标的阈值，或偏离以前的基准测试的行为负责。

• 诊断 — 对可能出现的瓶颈或性能问题进行根本原因分析。使用领域知识和专业工具，如剖析工具、内存泄漏检测

器和监控工具来确定问题领域。

• 调整 — 调整涉及应用最佳实践、调整建议，并拆分出可优化容量或性能的应用程序或基础设施部分。

• 测量 — 除了为优化所有策略性或战术活动提供流程改进建议之外，还包括负责进行分析活动以及整体策略的

推进。

在小型企业中，一个人可以承担所有这些责任，通常由 Akamai 协助进行测试创建、执行和分析，以及测试策略的制定

和推进。

零售网站和应用性能测试完整指南 5

部分或全部角色可能外包，通常是为了充分利用专业知识，着重强调缺乏关注的领域，和/或为了降低成本。

人员和角色通常是彼此结合的。例如，项目经理、性能工程师和/或专家的存在将消除对技术主管的需求，或有助于该

人员填补该流程中的其他缺口。以下是常见的角色/职务，以及它们如何映射到各种职责：

• 项目经理 — 协调、沟通

• 技术负责人 — 协调、沟通、策略、架构、分析、诊断、调整、测量

• 架构师 — 基础设施架构、应用架构

• 性能工程师 — 制定策略、架构、分析、诊断、调整、测量

• 测试工程师 — 测试创建、执行、分析

• 专家 — 诊断、调整

测试时要注意什么了解什么影响在线零售网站的运行速度快慢，有助于弄清测试工作的重点。

许多在线零售网站相当复杂，由几个不同的组件和应用层组成。了解这些组件中的每一个以及它们之间如何相互作用非

常重要。

测试时要特别注意的一些常见领域是：

• 应用程序问题 — 世上根本没有十全十美的代码。注意低效代码、同步问题、垃圾收集、内存泄漏和应用程序死锁

等问题。

• 数据库性能 — 这是性能的核心。注意锁定和争用、缺少索引、低效查询、内存管理、连接管理以及数据未受管控

的增长。

• 配置设置 — 默认设置很少是最佳的。检查环境之间的差异，并了解架构中各种设备的调整选项和最佳实践。

• 负载平衡 — 有效地使用硬件。查找未优化和未充分利用的特征和功能的算法。

• 连接性 — 通信至关重要。确保系统能够以最小的延迟进行通信，防火墙拥有足够的容量，系统针对移动网络进行

了优化，DNS 路由是正确的，并且 CDN 缓存进行了优化。

• 带宽 — 能否连接到您的网络？确保网络带宽能够容纳足够大的流量。审查构成页面的内容。丰富的内容可能意味

着较高的数据和带宽要求。验证该网站是否可以支持不同的连接类型/速度，包括移动设备。

• 架构 — 将车辆与发动机匹配。注意不平衡等级、不匹配的技术选择，或进入死胡同的可扩展性路径。

• 第三方服务 — 最慢的页面资源决定了您的速度。确保分析和跟踪、支付系统、聚合内容、社交网络或 CDN 不会减

慢您的网站速度。

零售网站和应用性能测试完整指南 6

性能测试类型经常出现的一个问题是“需要运行什么样的测试？”

有多种测试选项可供您选择 - 基准、压力、峰值、耐力和故障转移。对于零售商来说，所有这些测试都是有价值的。

基准在“平均负载”下，零售商需要建立一个可接受的网站性能的基准。我们建议您使用前六个月的分析数据和每天最繁忙

的时段，并将其作为页面浏览量/小时和订单/分钟的平均负载值。

压力零售商需要进行压力测试，以确保在长时间承受沉重负载时，站点性能不会下降。内存泄漏或垃圾回收错误引起在进行

压力测试之前无法预见的性能问题并不常见。Akamai 建议压力测试在 150-200% 的预期峰值负载下进行。

峰值峰值测试是当大量用户激增或几乎同时访问时采用的一种测试。对于零售商来说，峰值测试至关重要。许多零售商都有

引起流量峰值的活动 - 闪电促销、黑色星期五、网购星期一、情人节等 - 这些活动可能会使网站瘫痪。零售商必须确保

在此类活动期间，订单不会丢失或用户不会离去。Akamai 建议峰值测试在 200% 的预期峰值负载下运行。

耐力耐力测试与压力测试的规模不同。虽然压力测试将具有非常高的页面浏览量和订单数，耐力测试将模拟在更长的时间内

稍微有所减弱的负载。这些测试具有很大的价值，因为它们可以发现在长时间内性能下降的其他领域。批处理作业、数

据库备份和缓存刷新，可以重复排定和运行。在几个小时内运行耐力测试可能会显示这些类型的活动会影响到性能。

故障转移大多数零售商都有在发生故障时立即采取行动的灾难恢复或故障转移服务器。如果在沉重的负载期间发生硬件故障，备

份硬件是否足以应对问题？除非执行故障转移测试，否则无法知道这种方式是否可行。

在早期测试中，目标通常只是了解网站的性能特征。对于这些测试，用户增加速率可能更慢，更具系统性。

一旦建立了这些基准，并且您对网站可以处理的内容有一个很好的了解，那么尽可能按实际情况执行测试就变得至关重

要了。这包括拥有现实的用户级别和增加速率。审查前几年的分析将有助于您建立用户增加级别。

测试中不能采取欺骗手段。不要改变思考时间或删除测试的关键组件。删除或更改它们只会曲解结果并削弱测试的

价值。

生产中测试与实验室中测试比较要实现成功测试，您需要制定一个有效的在线零售测试策略。安排合适的团队实施策略将有助于确保测试成功执行。成

功测试意味着了解生产中和性能实验室中测试的价值。

在不同环境中执行不同类型的测试是发现和解决在线零售网站构成架构中瓶颈的关键因素，这通常是相当复杂的。

零售网站和应用性能测试完整指南 7

制定端到端测试计划，其中生产测试是必不可少的组成部分

网络和运营

发布和部署

SCALE OF TEST

开发和测试

测试实验室 试运行 生产 (100%+++)

缓慢网页

内存泄漏

垃圾收集

默认配置设置

缓慢的第三方插件

超过最大插槽数

自动扩展故障

负载平衡器配置

与其他应用冲突

网络带宽

网络配置

系统之间的延迟

方法级调整

低效数据库查询

数据库线程计数

服务资源不足

搜索技术限制

全球延迟差异

不平衡的 Web 服务器

防火墙最大容量

DNS 路由

CDN 文件放置

测试规模

阶段

& 团

队

上图展示了实验室中和生产中不同类型的测试如何可以帮助您确定在实现最佳性能过程中必须解决的具体问题。

性能实验室中测试实验室中的持续性能测试有助于应用程序工程团队评估随时间不断变化的性能，并在导致中途故障的性能错误进入生产

环境之前帮助捕获这些错误。

此外，实验室还提供了一个进行性能测试编码和配置更改的位置，以便在发布生产变更之前和正常版本周期之外进行性

能回归测试。这可能包括页面中的快速错误修复，或者是可能会对性能产生影响的看似轻微的配置更改。通常情况下，

这些类型的更改在部署前很少甚至没有进行过测试，后来因为出现性能问题而返回来执行这些测试。

在实验室中执行的测试也能让您在无需担心影响用户的前提下暂停系统。

了解在线零售网站在遇到故障时如何进行响应以及如何从故障中进行恢复是非常重要的。没有人希望实时生产网站出现

故障。

零售网站和应用性能测试完整指南 8

Akamai CloudTest 方法是一个软件 QA 性能测试策略，它具有一套轻量级流程，可确保在线应用程序为峰值使用量做好准备

Akamai CloudTest 方法

策略 实施 执行 评估

定义 人员 定义 分析

集成 流程 设计

测试

评估

调整

生产中测试（是的，可以完成）真正建立对网站的信心的唯一方法，是在现实环境中对该网站进行测试。

由于在任何给定时间访问网站的用户数量庞大，很少有公司可以在模拟环境中或性能实验室中复制生产环境。生产中测

试是真正了解现实世界中容量和性能的最佳方式。而且这是确保在线应用程序按预期执行的唯一方式。

传统上，测试仅限于进行推断，在实验室的几台服务器上测试的应用可以支持要高得多的生产中的负载量。没有进行适

当的测试，这些类型的假设通常会遭遇意想不到的障碍。

有些问题只能通过生产中测试才能发现

以下是实验室测试中无法发现的问题的列表：

• 实验室中不存在的批量作业（日志轮换、备份等），或妨碍性能的其他在线系统的影响

• 负载平衡器的性能问题，如配置错误的算法设置

• 网络配置问题，如交换机上 100 MB 设置而不是 1 GB 设置，以及路由问题

• 带宽限制

• 数据管道未配置为“可处理突发流量”，无法处理流量高峰

• 应用程序内部和外部系统之间的延迟

• 配置错误的应用程序服务器或 Web 服务器

• CDN 未配置为提供新内容

• 根据数据库大小，性能截然不同

零售网站和应用性能测试完整指南 9

内容交付网络 (CDN)

绝大多数测试实验室没有将 CDN 作为基础设施的一部分。因此，如果没有进行生产中测试，无法测试 CDN 如何影响

性能。

当零售公司在生产中进行测试时，它可以充分测试其 CDN 的缓存/卸载功能。这对于了解生产环境的真实性能至关

重要。

当准备在生产中进行测试时，必须让 CDN 提供商较早地参与此过程，从而确保生产测试得到 CDN 提供商的支持。

（Akamai 制定了一套包含 CDN 资产的测试最佳实践。）

有一家 Akamai 客户，是年营业额高达数十亿美元的零售商，拥有两千多家店面，它的一位性能工程师考虑将纳入 CDN

视为生产测试的重要组成部分：

“在执行生产中测试时，我们通常会启用 Akamai 缓存。这肯定会影响对访问源站（主要站点）的请求数量的测试，也

会影响依赖于从何处提供页面（Akamai 或源站）的响应时间的测试。在实验室中，我们很可能不会包括 Akamai。这意

味着我们必须将 CDN 纳入我们的生产测试，否则就没办法真正了解我们的生产性能。”

第三方内容

许多在线零售网站使用第三方提供商来提升其整体网站内容。在制定策略时，让可能对性能产生影响的第三方提供商参

与进来至关重要。

另一方面，您通常不会将 Google Analytics 或 Omniture 等域指标作为测试的一部分。他们不想被测试弄得一惊一乍，

或者因虚假交易而使服务或网站停止运行。

在过程中较早请第三方提供商参与有助于确保获得他们的支持。他们甚至也可能希望在此过程中对自己进行评估。毕

竟，他们也希望获得性能良好的网站。

对实时客户的潜在影响

生产中测试可以在环境中有或没有实时用户的情况下进行。*（注意：借助 Akamai CloudTest 进行生产中测试的大多数

客户在实时环境中也是这样做的。）

建立维护页面或暂停服务页面，等到所有现有用户会话完成后发布，这种情况可能发生，但是并非总是可行。实际上，

这种方法很少使用，因为合适的工具和方法相互配合，可以在除了最极端的情况之外的所有网站环境中，在网站上仍有

活动用户的情况下进行测试。

一家 Akamai 客户如此评价，“不测试的成本远远大于对实时客户的潜在影响”。

借助正确的方法，您可以在测试的同时赚取收益。还可以在低流量时段划分一部分实时环境，并允许在此子环境中进行

测试。或者测试一个数据中心，而将实时用户都路由到另一个数据中心。

通常，在负载平衡器上配置单独的 IP 地址，并将服务器从实时池中移出放入到测试池。有时需要对其他共享组件进行配

置更改。这是一个成本更高的方法，因为需要额外的硬件和维护开销。这种方法也有点不太可靠，因为您会开始偏离实

际的生产配置，无法测试真正的规模。但这种测试比实验室中的简单测试更贴合现实。

零售网站和应用性能测试完整指南 10

成功实时测试的三项要求

1. 实时分析能够通过实时客户进行大规模测试的第一个要求，是在您的测试工具中进行实时分析。借助网站性能的最新信息，您可

以快速判断网站是开始经历性能不佳，还是变得完全无响应。

2. 出色的“实验安全开关”您必须能够在运行的性能测试中按“停止”或“中止”以立即停止负载。带宽、并发连接、正在使用的线程和其他典型

的棘手问题将全部恢复正常。

3. 可靠的内部监控实践最后，内部进行良好的监控实践，最好与测试解决方案集成在一起，可以避免您因为实时用户的影响而中止测试的需

要。实时了解诸如 CPU 利用率、堆使用情况、垃圾收集以及负载平衡器或防火墙的连接计数等指标，可以帮助防止这

些阈值被日常测试所侵扰。

安全和性能测试人们往往会忽视安全性，直至问题真正出现。我们很少会看到有关某家公司在保证客户数据安全方面表现如何出色的新

闻故事。但是您会看到一家公司让客户数据落入坏人之手的故事。

数据安全性是性能测试中的关键问题之一。公司不希望其企业数据处于公司防火墙保护范围之外。

您的性能测试解决方案应该：

• 通常根据您的业务和安全要求生成合成数据或使用已净化数据；

• 仅捕获关键的 HTTP/HTTPS 指标和用于报告、分析和诊断目的的统计数据；且

• 制定严格的安全策略，以确保您的数据保持安全。

它不应该：

• 要求您将数据或应用程序导出到防火墙之外；且

• 在测试服务器或结果数据库中保存任何响应内容。

零售网站和应用性能测试完整指南 11

附录 A：Akamai 性能测试方法

Akamai 的方法强调在不同的地方进行各种测试，来找到类似于大海捞针的问题点。

AKAMAI CLOUDTEST 方法

Akamai 性能测试方法是一种软件 QA 性能测试策略，具有适用于软件开发生命周期的一套轻量级流程，可确保在线应

用程序为高峰使用做好准备。该方法包括在防火墙内的实验室环境中测试应用程序，以及测试客户使用的生产基础设施

的过程。

云测试利用云的效率测试 Web 应用程序和网站。通过使用 Amazon Web Services 和 Rackspace 等公司提供的基础设施

和服务，Akamai 客户可以降低负载和性能测试的成本，同时提高网站实际流量信息的准确性。CloudTest 是一种分布式

架构，可以完全部署在防火墙后面，或将本地和基于云的配置相结合。

基于多年来从云测试的经验，并利用现有的最佳实践和经过验证的性能测试方法，Akamai 方法对传统方法进行了扩展

来应对新的机遇和挑战。这其中包括：

• 在实验室进行测试，同时在生产中利用实时基于 Web 的应用程序进行测试

• 利用云在典型和高峰流量水平进行测试，从数百个用户到数百万用户

• 通过使敏捷性能测试成为现实的替代方案来应对开发周期时间的加速

• 生成地理上分散的负载，以最准确地描述现实世界的流量

• 生成内部和外部负载，同时针对实验室和生产环境进行测试，以获得最高效和最有效的结果

• 实时分析性能情报以加快问题解决

策略与规划

Akamai 的性能工程方法要求制定全面策略与相关的个体测试计划。

测试计划从整体着眼，确保对关键创收应用程序按预期运行充满信心。

结果是形成整个网站演变过程中持续的性能工程策略。

它包括一些以个人目标为中心的测试计划，如为假期高峰做好准备、主要的架构更改或主要版本的代码发布。

制定包含明确测试计划的详细策略，为业务和工程领导提供运营准备过程中的高度自信。使用此方式可让您更深入地了

解应用程序的性能。

使用测试计划中的迭代过程来实现所定义的目标，从而支持所测试的应用程序中的一系列持续改进。

这个过程从测试定义开始，以获取可操作性的情报结果结束。

创建测试计划的过程从定义阶段开始。在此阶段中，定义在网站的整个过程中要测试的流程，并制定要监控的指标，同

时达成对测试的成功标准的一致意见。在设计阶段，进行用户场景的撰写，并设置测试参数。还包括设计执行应用程序

不同部分测试的用户组合、虚拟用户的目标以及用户增加的时间。

测试阶段是执行测试以及收集数据以供评估的阶段。

最后是评估阶段，有些部分可能在测试执行期间发生过，是在整个测试执行期间收集的数据用于提供可操作性的情报的

过程。

零售网站和应用性能测试完整指南 12

附录 B：CloudTest 性能数据问答

什么是性能数据？

有许多不同类型的性能数据作为性能测试的一部分被利用。性能数据可以分为三大类：主数据、用户生成的数据和外部

数据。主数据通常存在于客户的数据库中，并且是开展业务所必需的数据（用户名、密码等）。用户生成的数据是用户

在应用程序的可编辑字段中输入的内容（新的电子邮件地址、新地址等）。在执行应用程序时提供外部数据（确认号

码、会话 ID 等）。

测试期间要使用哪些数据？

数据要求取决于被测应用程序和业务流程。例如，静态站点可能不需要任何性能数据，只需访问网站以进行请求，而更

复杂的应用程序可能需要所有这三种类型的性能数据。

收到的响应数据如何处理？

在负载测试期间，所有客户相关的响应数据都将从 CloudTest 服务器中丢弃。只保留与该响应数据相关的性能数据（响

应时间、错误等）。此外，如上所述，CloudTest 服务器是每次测试后丢弃的临时实例，只有性能指标保留在结果数据

库中。但是，在脚本创建和调试期间，所有客户和外部数据都存储在 CloudTest 服务器上。用于创建脚本的数据可以在

完成脚本创建后删除，以确保没有客户数据存储在 Akamai 服务器上。

如何处理用于捕获数据信息的日志文件或其他指标？

在负载测试期间，Akamai 不会保留用来捕获有关客户数据信息的日志文件或其他指标。但是如前所述，我们在脚本创

建期间存储这种类型的数据。

哪些数据会发回到 CLOUDTEST 服务器？

在负载测试期间，仅保留关键外部数据，例如 HTTP 响应代码、Cookie、会话 ID 等。所有数据都将发送回 CloudTest 服

务器进行解析，此时它将从任何 Akamai 服务器完全丢弃。

已净化数据与合成数据之间有什么不同？

已净化数据位于客户数据库中，并且已经经历过整个过程，因此不再包含任何真实的客户数据；实质上是从实际客户数

据转换和/或创建而来的数据。合成数据是全新生成的，准确地反映了客户生产数据库。

如何创建合成数据？

Akamai 与您的应用程序团队紧密合作，确保创造出丰富的代表性数据。所创建的数据也用来定位被测业务流程，并可

以随着测试的扩展而不断扩展。

测试结束后会如何处理数据？

测试完成后，CloudTest 服务器仅存储与测试运行相关的性能指标数据。CloudTest 服务器上不会保留公司数据。

测试数据如何存储在云中？

对于由 Akamai 执行的测试，测试结果存储在云中。结果将存储在测试活动结束时拆卸下来的 Linux 服务器上。这些服

务器仅在测试会话期间或在分析结果时可用。在大多数情况下，结果数据存储在 EBS（弹性数据块存储）的 EC2 中的关

系数据库中。仅 Akamai 员工可以获取此数据。

零售网站和应用性能测试完整指南 13

我们帮助像 Apple、Target、Etsy 和 Microsoft 这样的公司持续测试、监控和优化他们的 Web 和移

动应用程序。

我们也可以帮助您。

立即开始使用 CloudTest！

作为全球规模最大、最值得信赖的云交付平台，Akamai 可帮助其客户更轻松地在任何设备上随时随地提供最出色、最安全的数字体验。Akamai 的大型分布式平台拥

有无与伦比的规模，在 130 个国家/地区部署了超过 200,000 台服务器，为客户缔造超凡性能和卓越威胁防护。Akamai 将 Web 和移动性能、云安全、企业访问和视

频交付解决方案组合在一起，并通过出色的客户服务及全天候监控提供支持。如需了解顶级金融机构、电子商务领先企业、媒体和娱乐提供商以及政府机构为何如此

信赖 Akamai，请访问 www.akamai.com/cn 或 blogs.akamai.com，或者扫描下方二维码，关注我们的微信公众号。您可访问 www.akamai.com/locations 查询我们的

全球联系信息。发布时间：2017 年 07 月。

可以从云中删除测试结果数据吗？

可以，可以根据客户的请求从云中删除结果。当客户请求时，只有在完成结果报告后结果才会被删除。一旦结果被删

除，它们被永久删除：已删除的结果没有备份。请注意，删除结果限制了比较以前和未来测试结果的功能。一旦结果被

删除，比较结果的唯一方法是查看结果报告。

测试结果数据可以从云中导出用于非现场存储吗？

可以。所有结果都可以采用 XML 格式导出。结果可以从云导出，并移动到客户定义的位置进行保管。根据测试的时

长和与测试相关的性能数据量，从云中导出数据并移动到安全位置可能需要 24-48 小时。结果也可以选择性地从云中

删除。

扫码关注·获取最新 CDN 前沿资讯