测试什么是黑色星期五

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制定端到端测试计划,其中生产测试是必不可少的组成部分网络和运营发布和部署SCALEOFTEST开发和测试测试实验室试运行生产(100%+++)缓慢网页内存泄漏垃圾收集默认配置设置缓慢的第三方插件超过最大插槽数自动扩展故障负载平衡器配置与其他应用冲突网络带宽网络配置系统之间的延迟方法级调整低效数据库查询数据库线程计数服务资源不足搜索技术限制全球延迟差异不平衡的Web服务器防火墙最大容量DNS路由CDN文件放置测试规模阶段&团队上图展示了实验室中和生产中不同类型的测试如何可以帮助您确定在实现最佳性能过程中必须解决的具体问题.

性能实验室中测试实验室中的持续性能测试有助于应用程序工程团队评估随时间不断变化的性能,并在导致中途故障的性能错误进入生产环境之前帮助捕获这些错误.
此外,实验室还提供了一个进行性能测试编码和配置更改的位置,以便在发布生产变更之前和正常版本周期之外进行性能回归测试.
这可能包括页面中的快速错误修复,或者是可能会对性能产生影响的看似轻微的配置更改.
通常情况下,这些类型的更改在部署前很少甚至没有进行过测试,后来因为出现性能问题而返回来执行这些测试.

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

了解在线零售网站在遇到故障时如何进行响应以及如何从故障中进行恢复是非常重要的.
没有人希望实时生产网站出现故障.
零售网站和应用性能测试完整指南8AkamaiCloudTest方法是一个软件QA性能测试策略,它具有一套轻量级流程,可确保在线应用程序为峰值使用量做好准备AkamaiCloudTest方法策略实施执行评估定义人员定义分析集成流程设计测试评估调整生产中测试(是的,可以完成)真正建立对网站的信心的唯一方法,是在现实环境中对该网站进行测试.

由于在任何给定时间访问网站的用户数量庞大,很少有公司可以在模拟环境中或性能实验室中复制生产环境.
生产中测试是真正了解现实世界中容量和性能的最佳方式.
而且这是确保在线应用程序按预期执行的唯一方式.

传统上,测试仅限于进行推断,在实验室的几台服务器上测试的应用可以支持要高得多的生产中的负载量.
没有进行适当的测试,这些类型的假设通常会遭遇意想不到的障碍.
有些问题只能通过生产中测试才能发现以下是实验室测试中无法发现的问题的列表:实验室中不存在的批量作业(日志轮换、备份等),或妨碍性能的其他在线系统的影响负载平衡器的性能问题,如配置错误的算法设置网络配置问题,如交换机上100MB设置而不是1GB设置,以及路由问题带宽限制数据管道未配置为"可处理突发流量",无法处理流量高峰应用程序内部和外部系统之间的延迟配置错误的应用程序服务器或Web服务器CDN未配置为提供新内容根据数据库大小,性能截然不同零售网站和应用性能测试完整指南9内容交付网络(CDN)绝大多数测试实验室没有将CDN作为基础设施的一部分.
因此,如果没有进行生产中测试,无法测试CDN如何影响性能.
当零售公司在生产中进行测试时,它可以充分测试其CDN的缓存/卸载功能.
这对于了解生产环境的真实性能至关重要.
当准备在生产中进行测试时,必须让CDN提供商较早地参与此过程,从而确保生产测试得到CDN提供商的支持.
(Akamai制定了一套包含CDN资产的测试最佳实践.
)有一家Akamai客户,是年营业额高达数十亿美元的零售商,拥有两千多家店面,它的一位性能工程师考虑将纳入CDN视为生产测试的重要组成部分:"在执行生产中测试时,我们通常会启用Akamai缓存.
这肯定会影响对访问源站(主要站点)的请求数量的测试,也会影响依赖于从何处提供页面(Akamai或源站)的响应时间的测试.
在实验室中,我们很可能不会包括Akamai.
这意味着我们必须将CDN纳入我们的生产测试,否则就没办法真正了解我们的生产性能.
"第三方内容许多在线零售网站使用第三方提供商来提升其整体网站内容.
在制定策略时,让可能对性能产生影响的第三方提供商参与进来至关重要.
另一方面,您通常不会将GoogleAnalytics或Omniture等域指标作为测试的一部分.
他们不想被测试弄得一惊一乍,或者因虚假交易而使服务或网站停止运行.
在过程中较早请第三方提供商参与有助于确保获得他们的支持.
他们甚至也可能希望在此过程中对自己进行评估.
毕竟,他们也希望获得性能良好的网站.

对实时客户的潜在影响生产中测试可以在环境中有或没有实时用户的情况下进行.
*(注意:借助AkamaiCloudTest进行生产中测试的大多数客户在实时环境中也是这样做的.
)建立维护页面或暂停服务页面,等到所有现有用户会话完成后发布,这种情况可能发生,但是并非总是可行.
实际上,这种方法很少使用,因为合适的工具和方法相互配合,可以在除了最极端的情况之外的所有网站环境中,在网站上仍有活动用户的情况下进行测试.
一家Akamai客户如此评价,"不测试的成本远远大于对实时客户的潜在影响".
借助正确的方法,您可以在测试的同时赚取收益.
还可以在低流量时段划分一部分实时环境,并允许在此子环境中进行测试.
或者测试一个数据中心,而将实时用户都路由到另一个数据中心.
通常,在负载平衡器上配置单独的IP地址,并将服务器从实时池中移出放入到测试池.
有时需要对其他共享组件进行配置更改.
这是一个成本更高的方法,因为需要额外的硬件和维护开销.
这种方法也有点不太可靠,因为您会开始偏离实际的生产配置,无法测试真正的规模.
但这种测试比实验室中的简单测试更贴合现实.

零售网站和应用性能测试完整指南10成功实时测试的三项要求1.
实时分析能够通过实时客户进行大规模测试的第一个要求,是在您的测试工具中进行实时分析.
借助网站性能的最新信息,您可以快速判断网站是开始经历性能不佳,还是变得完全无响应.
2.
出色的"实验安全开关"您必须能够在运行的性能测试中按"停止"或"中止"以立即停止负载.
带宽、并发连接、正在使用的线程和其他典型的棘手问题将全部恢复正常.
3.
可靠的内部监控实践最后,内部进行良好的监控实践,最好与测试解决方案集成在一起,可以避免您因为实时用户的影响而中止测试的需要.
实时了解诸如CPU利用率、堆使用情况、垃圾收集以及负载平衡器或防火墙的连接计数等指标,可以帮助防止这些阈值被日常测试所侵扰.
安全和性能测试人们往往会忽视安全性,直至问题真正出现.
我们很少会看到有关某家公司在保证客户数据安全方面表现如何出色的新闻故事.
但是您会看到一家公司让客户数据落入坏人之手的故事.
数据安全性是性能测试中的关键问题之一.
公司不希望其企业数据处于公司防火墙保护范围之外.

您的性能测试解决方案应该:通常根据您的业务和安全要求生成合成数据或使用已净化数据;仅捕获关键的HTTP/HTTPS指标和用于报告、分析和诊断目的的统计数据;且制定严格的安全策略,以确保您的数据保持安全.
它不应该:要求您将数据或应用程序导出到防火墙之外;且在测试服务器或结果数据库中保存任何响应内容.
零售网站和应用性能测试完整指南11附录A:Akamai性能测试方法Akamai的方法强调在不同的地方进行各种测试,来找到类似于大海捞针的问题点.

AKAMAICLOUDTEST方法Akamai性能测试方法是一种软件QA性能测试策略,具有适用于软件开发生命周期的一套轻量级流程,可确保在线应用程序为高峰使用做好准备.
该方法包括在防火墙内的实验室环境中测试应用程序,以及测试客户使用的生产基础设施的过程.
云测试利用云的效率测试Web应用程序和网站.
通过使用AmazonWebServices和Rackspace等公司提供的基础设施和服务,Akamai客户可以降低负载和性能测试的成本,同时提高网站实际流量信息的准确性.
CloudTest是一种分布式架构,可以完全部署在防火墙后面,或将本地和基于云的配置相结合.
基于多年来从云测试的经验,并利用现有的最佳实践和经过验证的性能测试方法,Akamai方法对传统方法进行了扩展来应对新的机遇和挑战.
这其中包括:在实验室进行测试,同时在生产中利用实时基于Web的应用程序进行测试利用云在典型和高峰流量水平进行测试,从数百个用户到数百万用户通过使敏捷性能测试成为现实的替代方案来应对开发周期时间的加速生成地理上分散的负载,以最准确地描述现实世界的流量生成内部和外部负载,同时针对实验室和生产环境进行测试,以获得最高效和最有效的结果实时分析性能情报以加快问题解决策略与规划Akamai的性能工程方法要求制定全面策略与相关的个体测试计划.
测试计划从整体着眼,确保对关键创收应用程序按预期运行充满信心.
结果是形成整个网站演变过程中持续的性能工程策略.
它包括一些以个人目标为中心的测试计划,如为假期高峰做好准备、主要的架构更改或主要版本的代码发布.

制定包含明确测试计划的详细策略,为业务和工程领导提供运营准备过程中的高度自信.
使用此方式可让您更深入地了解应用程序的性能.
使用测试计划中的迭代过程来实现所定义的目标,从而支持所测试的应用程序中的一系列持续改进.

这个过程从测试定义开始,以获取可操作性的情报结果结束.
创建测试计划的过程从定义阶段开始.
在此阶段中,定义在网站的整个过程中要测试的流程,并制定要监控的指标,同时达成对测试的成功标准的一致意见.
在设计阶段,进行用户场景的撰写,并设置测试参数.
还包括设计执行应用程序不同部分测试的用户组合、虚拟用户的目标以及用户增加的时间.
测试阶段是执行测试以及收集数据以供评估的阶段.
最后是评估阶段,有些部分可能在测试执行期间发生过,是在整个测试执行期间收集的数据用于提供可操作性的情报的过程.
零售网站和应用性能测试完整指南12附录B:CloudTest性能数据问答什么是性能数据有许多不同类型的性能数据作为性能测试的一部分被利用.
性能数据可以分为三大类:主数据、用户生成的数据和外部数据.
主数据通常存在于客户的数据库中,并且是开展业务所必需的数据(用户名、密码等).
用户生成的数据是用户在应用程序的可编辑字段中输入的内容(新的电子邮件地址、新地址等).
在执行应用程序时提供外部数据(确认号码、会话ID等).
测试期间要使用哪些数据数据要求取决于被测应用程序和业务流程.
例如,静态站点可能不需要任何性能数据,只需访问网站以进行请求,而更复杂的应用程序可能需要所有这三种类型的性能数据.
收到的响应数据如何处理在负载测试期间,所有客户相关的响应数据都将从CloudTest服务器中丢弃.
只保留与该响应数据相关的性能数据(响应时间、错误等).
此外,如上所述,CloudTest服务器是每次测试后丢弃的临时实例,只有性能指标保留在结果数据库中.
但是,在脚本创建和调试期间,所有客户和外部数据都存储在CloudTest服务器上.
用于创建脚本的数据可以在完成脚本创建后删除,以确保没有客户数据存储在Akamai服务器上.
如何处理用于捕获数据信息的日志文件或其他指标在负载测试期间,Akamai不会保留用来捕获有关客户数据信息的日志文件或其他指标.
但是如前所述,我们在脚本创建期间存储这种类型的数据.
哪些数据会发回到CLOUDTEST服务器在负载测试期间,仅保留关键外部数据,例如HTTP响应代码、Cookie、会话ID等.
所有数据都将发送回CloudTest服务器进行解析,此时它将从任何Akamai服务器完全丢弃.
已净化数据与合成数据之间有什么不同已净化数据位于客户数据库中,并且已经经历过整个过程,因此不再包含任何真实的客户数据;实质上是从实际客户数据转换和/或创建而来的数据.
合成数据是全新生成的,准确地反映了客户生产数据库.