CTI论坛(ctiforum.com)（编译/老秦）:当更改您的企业网站、IVR和其他影响客户通信的技术时，毫无疑问你应该进行全面的测试。然而，我们一次又一次地看到联络中心的测试被消减了。
　　对于那些不相信测试效果的人，或那些不相信企业会消减这至关重要一步的人，让我们回顾一些典型的例子。

　　2013年10月，美国联邦政府HealthCare.gov计划启动。技术故障导致了失败，其中尝试汇集了许多不同的功能。尽管开发阶段的时间超过了预期，团队却决定不改变发布的日期。正因为如此，就减少了测试的时间，它省略了完整的测试阶段。团队成员自行祈祷，希望一切都会工作正常。不幸的是，从开发到生产导致了灾难性的后果。各种组件拼凑导致不能正常协同工作，网站不能处理大量的流量。

　　我住的地方是在明尼苏达州，有一个全州的医疗保健计划。与HealthCare.gov完全一样，政府开发团队人员上线前没有测试网站和联络中心，他们没有意识到后果。

　　网站和联络中心测试--在上线前--可以揭示出各种各样的Bug，如潜在的配置问题或在您的环境中存在的潜在的平衡问题。

　　在一个通信环境的实例中，可以处理600个电话的IVR只能同时处理300个并发呼叫。这是一种典型的不匹配，一个人负责公共网络的连接，其他人负责应用程序的开发和配置。它不是人的错，但它是联络中心测试至关重要的原因。

　　构建一个复杂的数据处理或通信环境所面临的挑战是确保所有的组件有效地一起工作。这包括许多来自不同部门的不同的人所做的集成软件和系统开发，同时也与网络和数据库进行交互。每个组件都可以完美地工作，但集成会导致源于规模和APIs使用量所产生的问题。

　　有一系列的测试方法你应该在上线之前提前部署。我们至少强烈建议压力测试、负载和性能测试、浸泡测试和弹性测试。一旦系统上线，进行持续的心跳体验测试以确保系统24×7的体验。

　　压力测试是精心设计的，逐渐满足系统最大目标流量，从始至终确认功能和性能在高流量条件下从不妥协。远程压力测试过程产生虚拟客户语音通话，或web事务访问，就像真正的客户那样。负载测试重要的是流量需求是来自于实际的外网流量，这样可以检测出所有功能模块在公共电话网络和互联网环境下的体验是否跟在内部网络和系统组件环境下一样的出色。无论是声音、web或WebRTC交互，他们应该是实际使用环境中的真实表现，所以你才能在真实的高负载情况对你的系统可以有预期的信心。

　　浸泡测试的目的是验证系统在一个相对长的时间段里的稳定性表现。它是至关重要的，因为潜在的问题可能不会立即出现。当你在一些用户尝试一个新的电信系统或Web环境时可能感觉一切似乎都是伟大的，但你真正需要做的是让系统在全负荷环境下运行。系统应该体验这满载环境并持续一段时间，这样你就可以相信今后不会有大的问题。

　　弹性测试可以验证系统的高可用性。在面对出现问题的情况下，如网段中断、服务器或组件坏掉、或终止服务，系统是否能够自适应？加大流量负荷，然后禁用一个网段或服务器，或终止一个关键服务，然后观察系统适应被损害了的环境的能力。它是优雅地降低定义中的业务连续性计划，还是彻底崩溃？同样重要的是系统的恢复。任何组件是否需要一个额外的在线重启？是否可以恢复他们的正确配置？你需要对系统在现实世界中无论发生什么的情况下都充满自信。

　　目标瞄准已知高峰流量事件的健康检查是必需的，因为IVRs、网站和他们的底层基础设施是不断变化的。一个系统的长期闲置可能导致问题，这些问题在低流量时容易被忽视。在预测到有高峰流量到来之前进行一个健康检查可以确保你不会盲目地进入高峰流量窘境，高峰流量到来时希望什么都没有改变，因为你刚刚经历过最大的呼叫流量测试。

　　所有类型的测试重点是要从客户的角度去进行，因为你是对结果有预期的，而客户则没有。你的预期非常可能影响你的测试方法和结果。

　　请记住，首先你必须验证所有的组件在一起协同工作，人们能够有效地使用它们。其次，你必须确保你的技术可以一天24小时，一周7天地无休止工作。最后，必须定期确认--尤其是在已知的高峰流量事件即将来临之前--这样你就不会措手不及。

　　不管你运营的是自助服务环境、IVR或网站，或提供基于技能的座席路由和CTI屏幕弹出，你必须确保每一组件都处于正确和平衡的状态，从端到端的集成。所有的组件都应该在满负载条件下呈现出完美的功能特性。如果你在上线之前省略了负载测试或体验测试，你就会远离成功。

迈克·伯克（Mike Burke）

　　作者：迈克·伯克（Mike Burke）。迈克有超过40年电信、联络中心和网络方面的工作经验，曾经在霍尼韦尔、GTE、PNC Associates、Verizon、IQ Services工作，现在在IT Solutions就职。