呼叫中心IVR性能分析与优化.docx

呼叫中心IVR性能分析与优化研究IVR的重要性IVR系统是呼叫中心的重要组成部分，现在已成为解决用户问题的主要方法，在呼叫过程中起着不可替代的作用，为呼叫中心和用户都提供了极大的方便。据统计，呼叫中心90%以上的用户问题通过IVR获得解决。但是随着服务业的发展，用户的需求越来越多，越来越广泛，原来的固定IVR配置方案已经过时，需要新的IVR设置。现在的IVR菜单系统庞大复杂,用户大多会因IVR操作过于繁琐或者找不到其所需要的菜单功能而放弃，转向人工热线服务，最后导致IVR利用率的降低。因此对IVR的性能、用户行为模式等进行分析，建立高效的IVR的菜单配置是目前对IVR改进的主要方向。IVR性能分析和优化方法简介对IVR分析主要采用数据挖掘的手段，通过对用户日志的深层次的挖掘分析，不仅可以获取IVR的运行效能，找出IVR业务流程中的瓶颈，而且能够获取用户对IVR使用的行为模式，从而设计出好的IVR配置方案。通过对用户使用IVR后完成任务情况的分析，可以获取IVR节省的人工时间，将这些节省的人工时间转化为人力费用，从而使得管理人员能够从宏观上了解IVR带来的经济效益。采用用户路径图的方式可以可视化地将用户对IVR的使用情况显示出来。用户路径图可以充分展示IVR各菜单的访问次数，使用成功率，放弃率等，还可以显示关联菜单节点之间的联系状况。通过对用户路径图的分析，可以找出其中的使用低效的菜单节点和业务流程，从而找出IVR设计的不足。此外，通过用户路径图可以挖掘出用户使用IVR的主要行为模式，给IVR的重新设计提供用户使用方面的信息。通过对用户访问的IVR的节点数的统计，按照一定的计算规则，建立IVR使用复杂性指标。从而对IVR日志分析之后，可以量化IVR的使用复杂性情况，反映出IVR在使用性能上的评价。通过对不同品牌、不同时间、不同设计的IVR的使用记录分析，管理人员能够对各种情况下的IVR进行比较分析，从而找出最合适的设计方案。IVR性能分析和优化给呼叫中心和用户带来的效益对IVR的经济效益以及IVR的使用复杂性评价可以为管理人员了解IVR性能提供重要的参考依据，并且可以以此为指标对不同的IVR设计提供评价标准。用户路径图可以揭示IVR设计的不足，通过改进这些缺陷能够提升IVR的使用效率，提高用户使用的满意度和自助率，从而减少转向人工服务的概率，降低呼叫中心的客服人员的人力成本。通过用户路径图的深层次挖掘，还可以建立用户使用的基本模式，这可以为设计良好的IVR提供参考。服务级：1.线程数初始调整：150200除ag未作变动，其他server均按以上做了调整。2.启动脚本的permsize:256m,Xms:1024m,Xmx:1024m3.Servlet Reload Check (in seconds),Resource Reload Check (in seconds),JSP Page Check (in seconds)设置为-1系统级：=linux: (以下均未设置)/sbin/ifconfig lo mtu 1500 当前16436/etc/sysctl.conf: (sysctl -p to reload or reboot the system for change to take effect)kernel.msgmni 1024kernel.sem 1000 32000 32 512fs.file-max 65535kernel.shmmax 2147483648net.ipv4.tcp_max_syn_backlog 8192=HP:核心参数maxfiles 2048maxfiles_limit 4096 (满足大多数情况要求，根据实际运行情况更改，如8192，maxfiles_limit=maxfiles)tcp_conn_request_max 4096 (如8192,16384.) 当前4096tcp_ip_abort_interval 60000 当前 600000tcp_time_wait_interval 60000 当前 60000tcp_keepalive_interval 900000 当前 7200000tcp_xmit_hiwater_def 1048576 当前32768tcp_rexmit_interval_initial 4000 当前3000交换机的优势：系统容量：支持上千座席，适合大规模的呼叫中心应用。IP组网： 具有很强IP组网能力，可以构成多址虚拟呼叫中心。智能路由和技能路由： Definity系列企业通信服务器内置的自动呼叫分配（ACD）软件包为客户服务中心提供了基于分组及基于业务代表技能的呼叫分配方案，保证了对客户的高质量服务和业务代表工作负荷的合理分配。其主要功能包括： 呼叫引导(Call Vectoring)-可根据每天不同的时间，每周不同的工作日，业务代表人数，呼叫等待的数量，排队等待时长等多种因素，动态调整呼叫处理，以平衡呼叫负载。 预计呼叫等待时长(EWT)-使用Avaya实验室获专利的算法，不间断地计算呼叫等待时间，根据等待时间为队列中的呼叫做出路由选择。通过播报客户的等待时间，给客户提供更多的便利； 专家业务代表选择(EAS)-将有特殊需要的来话者与具有最合适技能的业务代表相联接，从而实现对业务代表资源的有效管理。Avaya的EAS允许每个座席最多可同时拥有20项技能；CentreVu Advocate - Avaya实验室的专利呼叫等待及分配算法，使企业可以对客户业务代表和业务目标的需求做出细致的平衡，全面表现出其战略意图，并可利用多种不同的技术优化客户服务。升级费用：硬件卡板全部兼容通用。需对座席、IVR端口按数量收取软件许可费用，ACD软件须按座席数量收取费用。市场情况：是国内金融领域首选平台，占有很大市场份额。交换机是传统的电话接入设备，通过交换机可以将用户的呼叫接入到后台的座席人员，同时，通过CTI服务器，对交换机进行有关的控制。目前，国际上的呼叫中心绝大部分实施的是基于交换机的呼叫中心方案。其特点如下: n 既保留了通信系统和计算机系统的独立性,又综合了两者的功能。n 各子系统的功能明确,有成熟的国际标准,易于扩展和升级。n 由于有明确的技术分工,有利于各子系统的生产厂商形成规模产业,从而降低系统的综合成本。 n 对于各子系统,生产厂商一般都有较长的技术积累期,因而具有可靠性较高的技术指标。 1. 基于交换机的解决方案是现阶段企业级客户的优选在现阶段国内一体化方案的呼叫中心还有一些无法解决的问题：n 由于程控交换机已经发展了几十年，可以达到工业级的可靠性；一体化方案仅发展了几年，其可靠性及成熟度相对而交换机而言要差一个数量级。n 交换机的交换是用硬件实现的，而一体化机的交换是通过软件实现，交换速度还是硬件实现得快。n 交换机的语音质量较一体化机好。n 由于交换机方案各相关模块相对独立：只要交换机不出问题，其他部分出了问题不会影响电话的呼入。而一体化方案系统一旦出现问题，就会直接影响到电话的呼入。n 交换机方案在实施和升级时，可以循序渐进，而且不影响正常的电话呼入。综上所述，虽然一体化呼叫中心是未来的发展方向，但是CTI领域存在着前人种树，后人乘凉的尴尬状况。一体化方案正在完善和发展中，像Avaya公司也正在投入力量开发一体化产品，整个技术正在完善中，标准规范尚未形成。因此我们建议用户在选择一体化方案时需要慎重一点，同时，选择基于交换机的呼叫中心方案不失为一种稳妥的考虑。2. 国内一体化呼叫中心的发展现状虽然不容否认一体化的呼叫中心是未来呼叫中心的发展方向，但是国内的发展现状却不尽如人意。市场出现了越来越多的呼叫中心一体化平台产品，但是他们间的差别也是很大的，主要表现在以下几个方面：n 系统软件的成熟度和稳定性不同，既产品化的程度不同。有的平台软件或中间件往往是针对客户的项目所开发的应用软件，各功能模块是组合在一起，而不是融为一体，应用与平台也是很难分开的，呼叫中心应用的改变可能需要软件底层的大动作。n 软件整合的功能有多有少，比如录音没有的话，集成商还需要在外部集成第三方的产品。n 硬件的整合度不同，有的整合度比较低的，通过外部集成多台电脑或外部设备实现一些功能。整合得最好的，在一台专用服务器内实现所有功能。n 软件架构的不同直接影响到二次开发的时间和成本，以及未来是否顺利升级。n 客户化开发平台的完整性和便捷性不同。n 硬件与软件间的缝隙不同：由于呼叫中心有关的标准还远未统一，要想中间件做到与硬件无关，短期内是不可能的。软件与硬件的缝隙是决定平台性能的一个重要方面。n 底层技术的融合程度不同，融合的越好，平台实现同样的功能所消耗的资源越少，如硬件和电脑资源。另外，国内很多一体化产品是仅仅是基于板卡的技术升级而已，有的厂商将微机更换成稳定一些的工控机，有的厂商为了降低开发成本甚至只是将微机更换一个外壳。交换机方案基于CTI-Link标准，其核心思想是在专用交换机+自动话务分配的基础上扩展路由和统计功能,开放CTI -Link接口, 由专业通信和计算机厂商利用各自优势分工合作，运用计算机电话语音集成技术实现通信和计算机的紧密结合,再配以必要的语音和数据库系统,从而以强大的通信和计算机功能满足呼叫中心的要求。交换机方案在结构上可清晰地分为计算机系统和通信系统两部分，CTI服务器是协调控制二者的连接设备,保证座席和交互语音应答(IVR)可以充分利用数据资源和呼叫处理资源。结构图如图所示。交换机方案的优点：1. 既保留了通信系统和计算机系统的独立性，又综合了两者的功能。2. 子系统的功能明确，有成熟的国际标准，如CSTA179及CSTA180标准。3. 有明确的技术分工，有利于各子系统的生产厂商形成规模产业，可靠性较高。1. 概述本报告的目的在于对中国民航信息网络股份有限公司（以下简称中航信）呼叫中心项目Call Center平台实施工作以及投产应用情况进行总结。2. 实施工作中航信呼叫中心项目Call Center平台主要包括PBX、CTI、IVR、FAX、VoiceLink和座席等功能模块。如下图所示：l 系统采用了业内技术领先的Avaya S8700交换机 + Avaya G650媒体网关，可以保证客户呼入电话的高接通率，同时使用户在呼入后能得到最快的响应。Avaya S8700交换机可提供300,000BHCC（繁忙时段呼叫完成次数。它指的是系统所能支持的最大实际呼叫完成次数）值适用于具有很高呼叫量的呼叫中心用户向融合网络过渡的客户正在高速发展的客户l 系统采用业内领先的CTI产品Genesys CTI。使航信的呼叫中心系统可以采用适用于航信业务的定制路由策略，确保每通电话可以最大可能地被最合适的座席接起，同时保证服务质量的最优。l 系统采用业内领先的IVRGenesys GVP，可以保证系统7*24小时的语音服务，用户在任何时段打进电话都会听到航信的热情欢迎。IVR系统提供人性化的人机会话界面，用户可以轻松有效地找到解决问题的通道，选择恰当的选项进入并得到优质的服务。系统提供可定制的广告语音，也可用来发布紧急通知或者故障报告。用户可以通过IVR系统自助服务完成操作，比如收发传真，这样可以节约航信呼叫中心宝贵的座席资源并完成更有效的工作。l 对VIP客户实现个性化服务，让VIP客户感受到航信客服中心的关怀。系统能够实现黑名单功能，能够有效的屏蔽骚扰电话，最大可能地利用呼叫中心资源。l 系统能完成满意度调查的工作，在座席解决客户问题提供服务后，可以让客户选择对服务的满意程度。如果在客户呼入电话的时候没有空闲座席，系统会提示用户是继续等待还是录音留言，如果客户选择录音留言，可以留下信息等待座席的回拨。l 系统在客服中心现场采用大屏幕的形式显示客服中心目前的工作情况，包括座席目前的话务状态（是否登录、是否就绪、是否通话等等）、当前排队数、分时间段的话务统计以及对座席组的话务统计等等。这对于指导座席工作、反映客服中心当前工作情况、协助领导决策等工作都非常有效。l 博雅思对航信客服中心的业务流程也进行了咨询和指导，也有效地提高了航信客服中心的服务水平。座席的开场白以及服务用语的规范化，能够使客户感受到呼叫中心的服务水平提升。当客服代表无法解决问题，需要电话转给其他客服代表或班长席时，能让客户感到处理流程的改变和畅通，更能感觉到有了尽早解决问题的保障。当客户需要在线等候查询的时候，我们座席服务用语的技巧和态度，让客户感到我们航信客服中心服务的效率3. 投产应用情况自系统投产以来，截至11月14日，总共3个月左右的时间，系统IVR进话量已经达到73702，IVR的应答率4个月保持在99%以上，座席进话量也有56431，应答量为42045，座席放弃量为5567，剩下的差额为客户放弃量。同时可以看到从八月份到11月份，座席应答率从83.5%已经提高到89.4%。转传真数量为9443，其中传真成功的数量为7499，每天平均收到100份左右传真。座席技能组的话务统计如图所示：工作率=（通话时间+事后处理时间）/登入时间4. 后续工作呼叫中心Call Center平台的搭建工作已经完成，优化完善工作在11月份也已经基本完成。后续工作包括对系统的维护以及某些模块或者软件的升级工作。性能优化与容错处理建议程序设计与资源管理问题Edify的应用开发，采用面向对象、基于组件的开发环境，目前IVR系统常用的与系统资源相关的组件如下：组件关系资源的操作资源释放问题预分配（Preallocate）手动分配(Allocate/De-)AgentSSXML处理计算等结束子程序时选择Return Current Error结束主程序时须Terminate OK同左TELEPHONESS摘机/挂机结束程序时须挂机手动申请/释放,结束时须挂机NTDLLSSNTDLL资源申请/释放自动手动申请/释放通常地，主程序IVR-Main，管理电话资源，电话资源是一个全局资源，在整个呼叫中都会存在，如果将处理电话事件的程序划分成不同的模块，电话资源对象的资源实例的可以通过参数传递给子程序或其他AO程序。请务必注意，不要将DLL资源放入主程序的对象实例中，否则整个呼叫，DLL资源如果电话资源一样，造成在整个的客户呼叫的流程中NTDLL都不能释放，即Telephone:NTDLL=1:1，非常浪费系统资源。建议将使用NTDLL方式通信的交易操作，封装到一个AO中，关于该DLL异常的处理也在该AO中处理干净，这样的话NTDLL对象实例在该AO被调用完成后，NTDLL资源可以立刻被Edify释放，下次调用时在由Edify系统申请、调用、再释放。这样的话Edify中电话资源与NTDLL资源的比例，可以降到4：1到3：1的程度（根据调用该NTDLL资源的频繁程度逐渐递增），大大的节省IVR系统对计算机系统的内存需求量。通常我们将NTDLL通信如下方式进行程序的AO规划。l Interface-TTS，管理TTS通信的DLL库资源申请释放；l Interface-Tuxedo, 管理与后台Tuxedo的DLL的资源申请释放；l Interface-CTI, 管理与后台CTI的DLL的资源申请释放；其他程序只是调研该AO获取相关的信息。AO程序划分建议：业务应用（App）：负责业务应用电话资源(Telephone)：负责DTMF输入采集，语音播报,录音；后台组（BackEnd）：负责与后台通信的交易；如TTS，交易。公用模块(PubAPI)：负责XML报文的拆解，系统时间日期处理、字符串处理，结构对象（如PackgeList等）的处理等。性能优化的几点建议a) 资源采用预分配方式，特殊要求除外（如某后台通信开发厂商要求采用手动分配，而非预分配；b) 与后台通信的DLL采用进程方式。容错设计与处理通常主程序AO（如C语言的Main函数），处理电话资源的异常，由它调用的AO可以传送电话资源，但建议子程序不要处理异常，只返回异常，由主程序统一处理所有关于子程序的电话事件异常。一般来说，Edify不挂断用户来电，如果发生系统超时，交易失败将主动通知客户，即使客户操作错误次数太多（如用户名/密码输入），也应该返回主菜单。只有当用户菜单选择失误太多安全原因或其他特殊情况（如系统维护升级）将挂断用户来电。AO异常处理需要注意以下几点：a) 用户不正常挂线，主程序能够及时释放电话资源；b) 通信异常，能够播报提示音，并能够及时挂线释放电话资源。c) 如果读写本地文件，特别注意不要让两个AO或程序同时写一个文件，出现写死锁的现象；d) Edify系统的异常处理一般用于返回代码，建议通过Select Last Err来截获异常，并处理。不要通过异常处理的代码进行循环，否则Edify会认为系统出现死循环，那样的话，Edify将走缺省的Default Handler流程，进行挂线和释放资源的操作。资源使用异常的诊断观察正在使用（In Use）的Agent、DLL和Telephone资源使用情况，如果发现：a、Agent正在使用(Running状态)的资源数与Telephone正在使用资源数相当，DLL正在使用的资源数10个数左右（次数具体根据调用的频繁程度，依次增加）或以内：说明应用运行正常。b、Agent正常使用（Running状态）的资源数远远大于Telephone正在使用的资源数;或者DLL资源正常使用的资源数等于预分配的资源数（!DLL资源用尽!）,或者Agent、DLL资源都用尽。此时虽然大部分电话资源（Telephone）的Device State状态虽为IDLE状态，但存在某个或大部分的IVR端口的Agent应用仍然继续运行；说明没有正常处理挂机事件。导致Agent和DLL不断被启用，但是没有释放和结束程序。如果解决？从IVR主程序的异常处理、IVR应用与后台接口的通信异常处理与IVR应用与后台通信的接口DLL三个层面进行展开：a. 仔细检查主程序（处理Telephone接入的程序）的异常处理模块，将End函数，设置为Terminal OK，而非Return Last Error。b. 仔细检查与后台通信的应用模块（包括CTI通信），如果发现通信异常，建议采用报“系统忙”，并提示用户进行重试，或者立即进行挂线（Hangup）处理，并迅速结束该端口的IVR Agent应用。C、仔细检查IVR与后台通信程序的是否有超时处理，并建议无法是客户端还是服务端都应有超时处理，同时将它调整到：客户服务等待的最佳体验时间（如3秒）时，IVR与后台程序通信需要的等待时延。d、检查在线程方式是否存在由某一个NTDLL线程发现死锁（从Edify进程状态可以观察到一直为Processing的状态（持续时间较长，最长有1个多小时的情况）时，其他NTDLL也跟着为Processing的状态，而非IDLE状态。如Genesys的DLL出现Processing状态时不释放，后台通信的线程方式的NTDLL不论是运行状态，还是Debug调试状态，将出现Processing状态，且在调试状态下，系统会停留在Load或第一个调用该DLL的操作上停止不前。如果发生将不同DLL文件调用的资源都变为进程方式，其他特殊要求为线程方式的DLL变为线程方式，同时建议系统只有一个DLL文件调用为线程，其他的不同DLL文件调用都采用进程方式。几点建议：1、 通过检查IVR系统的使用Agent、DLL、Telephone资源数（使用、空闲），鉴别IVR系统的问题还是IVR应用模块设计的问题（包括IVR与后台接口连接的问题）；2、 异常处理与应用流程设计一样，同样是系统设计的重点，关系到系统性能和可靠性，作为IVR应用不仅要考虑菜单设计、同时要设计异常处理，最好能够做到：异常处理统一入口（判别异常类型，并进行相应处理），统一出口（释放资源如电话、后台通信DLL等，结束Agent应用），并对重要事件进行日志。3、 关注不同应用层面等待时间的关系及其处理，处理好IVR接入的等待时间、IVR与后台通信的等待时间，以及后台各子系统的等待时间。建立这些等待时间的关系，并优化它们的组合，在IVR应用设计，DLL程序设计中予以体现。最终提供给客户一个最少等待时长的体验。4除CTI通信要求为线程外，其他NTDLL调用都采用进程方式，同时不同DLL文件调用，采用不同的分组，不要混合使用。系统性能测试测试说明由于NTDLL使用的DLL大部分为非Edify的第三方开发，有的是由系统集成商开发，为了保证在未来生产环境下保证IVR系统的高可用性，提前对NTDLL对象在高压力呼叫量的情况下，是否出现内存泄露问题是非常重要的。测试问题将会分为3个种类：l 级别A 最危急的问题： 影响系统的功能及不能再使用。此包括的系统问题如系统出错、系统停顿、致命问题和相似的问题。l 级别B 最严重的问题：功能上的问题但可以继续使用。l 级别 C 较轻微的问题：基本上是不会影响系统功能。在用户采纳系统前，ITApps 将负责维修由于级别A发生的问题。安装测试测试目的通过Edify的安装后的测试，检验Edify各部件是否安装正确。测试用例测试用例编号：01-01描述：测试系统能够正确接收DTMF应用：测试人：日期：参考项目： 版本：测试步骤编写一个AO，该AO能够正确接受DTMF，可以按键打断，可以超时打断预计结果正确接受DTMF，程序继续实际结果可以接受用户按键。 通过 失败如果失败需要采取的步骤修改责任人：修改结果：审核人：测试用例编号：01-02描述：测试系统支持接口DLL应用：测试人：日期：参考项目： 版本：测试步骤编写一个AO，调用DLL预计结果正确调用DLL实际结果能够正常调用tcp_client.dll与后台AppServer进行交易。 通过 失败如果失败需要采取的步骤修改责任人：修改结果：审核人：测试用例编号：01-05描述：测试系统支持XML应用：测试人：日期：参考项目： 版本：测试步骤编写AO处理预计结果单步执行能够正确处理XML实际结果SendDTMF AO可以随机读入各种交易的菜单的DTMF和延迟的XML文档，进行自动的外拨到IVR的IVRMain程序中，模拟人工输入按键进行相关交易。 通过 失败如果失败需要采取的步骤修改责任人：修改结果：审核人：测试用例编号：01-06描述：测试系统能够支持外拨应用：测试人：日期：参考项目： 版本：测试步骤编写AO或用Sendcall命令测试外拨内线、外线、长途、手机预计结果正确外拨实际结果Sendcall X953856008拨打本地电话成功;Sendcall X9013912345678拨打外地手机或电话成功。 通过 失败如果失败需要采取的步骤修改责任人：修改结果：审核人：测试用例编号：01-07描述：测试系统能够正确发送接收传真应用：测试人：日期：参考项目： 版本：测试步骤系统发送传真和接收传真预计结果能够正确发送和接收传真实际结果SendFax 到X95533可以进行正常传真收发; 通过 失败如果失败需要采取的步骤修改责任人：修改结果：审核人：集成测试测试用例编号：02-02描述：测试系统能够与CTI正确集成应用：测试人：日期：参考项目： 版本：测试步骤执行CTI提供的测试AO，（该测试需要CTI厂商配合）预计结果正确执行各项操作实际结果能够进行IVR转人工的操作 通过 失败如果失败需要采取的步骤修改责任人：修改结果：实际结果 通过 失败如果失败需要采取的步骤修改责任人：修改结果：审核人：异常处理测试测试目的通过.输入差错测试（意外值和边际值测试） 在每一功能的正常操作后，进行差错处理测试，从反方向检验系统的准确性和容错性。注：在生产环境下进行。测试用例测试项目测试步骤预期测试结果真实测试结果备注按键打断播报拨打95533按1听到欢迎词后，按键打断。 通过 部分通过 未通过进线的欢迎词应当和主菜单结合在一起，可以打断。多次错误输入拨打95533按1输入错误账号三次或以上提示“错误次数太多”，并挂机。 通过 部分通过 未通过输入错误帐号(太短)拨打95533按1输入错误账号提示“位数不足，或错误账号”，并提示重新输入。 通过 部分通过 未通过输入错误帐号(不存在)拨打95533按1输入不存在账号系统播报“无此帐号，请重新输入，请输入帐号或卡号的后四位，按键结束” 通过 部分通过 未通过模块压力测试测试内容在IVR业务应用编写之前，编写公用AO，并编写相应的测试代码对其中的：l 公用AOl 第三方接口进行集成性、稳定性测试。注：在测试环境下进行。测试目的通过对系统的公用AO的压力测试，检验系统在大容量呼叫下的可靠性。测试方法测试项目测试步骤预期测试结果真实测试结果备注测试后台交易的稳定性1. 配置30DLL资源，提交120个测试AO进行随机交易。2. 在Edify中纪录交易结果3. 持续测试一周左右；1. 能够正确处理交易。2. 出错时，能够返回相关错误代码。3. CPU和进程资源使用情况正常。4. 持续正常工作。 通过 部分通过 未通过建议：后台的Appserver在运用状态，同时提交后台日志以作比较分析。测试TTS后台的稳定性4. 配置5DLL资源，提交5个测试AO进行随机交易。5. 在Edify中纪录交易结果6. 持续测试一周左右；5. 能够正确处理交易。6. 出错时，能够返回相关错误代码。7. CPU和进程资源使用情况正常。8. 持续正常工作。 通过 部分通过 未通过测试Genesys后台通信的稳定性配置30DLL资源，提交120个测试AO随机拨打电话，正确获取CTI信息。1. 能够正确处理交易。2. 出错时，能够返回相关错误代码。3. CPU和进程资源使用情况正常。4. 持续正常工作。 通过 部分通过 未通过测试记录记录方式，每隔48小时截图一次，记录包括CPU的占用情况、DLL进程境况和Edify各组件的状态。日志如下：任务提交时间：2005年1月8日任务最新截图时间：2005年1月13日2005年1月8日 1. CPU 使用情况2. DLL进程内存使用情况3. Edify工作情况：整体压力测试测试原理在一台IVR（模拟程序平台）设备上编写模拟程序，程序按照手工操纵IVR应用的时机和顺序，向另外一台IVR（客户的IVR应用平台）送DTMF信号，模拟手