所以，我决定用我今年的No Jitter帖子来做这件事。如果你对以后的文章有什么建议，请告诉我。我将从测试的重要性开始。我关注的是UC部署测试，但这些原则对于其他IT项目也是合理的。
随着云计算的持续发展，我们现在越来越多地将通信作为一种服务而不是一个系统来购买。考虑到许多云通信服务已经有数千（如果不是数百万）用户在实时操作中，您可能会质疑是否需要自己进行测试。如果你听供应商的话，那么你应该知道“它只是工作！”但我的经验是，在某些情况下痛苦地学到的，仅仅因为某些东西对别人有效并不意味着它会自动对你有效。
从上世纪80年代我部署第一代数字PBX的那几天起，世界发生了翻天覆地的变化。我们甚至派出了一组步行者来测试每一部电话，以确保每一部电话都能拨打和接听电话，保持通话，并拥有与之相关的正确分机号码。这对于成千上万的用户同时进行“大爆炸”交换尤为重要。如果新的服务不起作用，那么我们的用户就会陷入混乱--一个跳线错误就可能导致数百个用户得到错误的电话号码。今天，这就像每个人都可以登录到其他用户的帐户一样！
在面向软件的现代世界中，由于各种设备都可以访问服务，因此不可能在每个场景中测试每个特性和功能。但那些大爆炸的老场景也不是那么常见。如今，实施计划更有可能在一段时间内分配给迁移用户，在旧系统退役之前，部署新的通信服务并与旧系统并行工作。因此，如果新的服务不起作用，那么用户总是可以依靠旧的服务--至少有一段时间。
但测试仍然至关重要。我学会了不相信任何人。每一个安装都会有问题，而让它们在业务照常（business-as-usual，BAU）操作中被发现，将在未来几年削弱用户对服务的信心。诀窍是考虑要测试什么，然后设计一个定制的测试计划，它不重复其他人已经做过的工作，而是关注用户的访问、定制和配置需求。我建议以下几点：
- 在测试中要有分寸和专注。不要什么都做。考虑哪些可能出错，哪些对用户和业务真正重要。
- 从一开始就考虑测试--将其纳入采购规范、工作说明书、实施计划和变更控制中。
- 不要做医生的工作。您有理由期望并要求您的提供商进行充分的测试，并将有效的服务移交给您。但一定要做到这一点。要求提供书面的测试结果。
- 分层组织测试。
- 系统测试应该测试一些重要的东西，比如连接和访问、兼容性（例如与桌面构建的兼容性）、恢复能力和故障转移。
- 用户测试应侧重于确保服务满足用例。实事求是，但在BAU测试时也要谨慎。考虑提前识别和模拟任何关键用例。
- 考虑压力/负载测试是否合适。对于基本的用户服务，您可能不需要它，但是对于任务关键型功能（如联络中心）来说，它是必不可少的。
- 不要忘记测试管理和报告系统。
- 不仅仅是技术问题。别忘了测试你的流程，比如入职和支持流程。
- 最后，测试灾难恢复（DR）和业务连续性（BC）。您确信服务提供商已备份并可以快速恢复您的配置吗？考虑一个完整的DR测试。一旦服务上线，这是非常困难的，而且可能无法孤立地完成。因此，请与您更广泛的IT和运营部门同事一起将其构建到完整的站点或组织范围的灾难恢复测试中。
如果测试失败了，事先想想你可能会采取什么行动。本地硬件问题应该很容易纠正。测试可能会突出显示配置问题。希望这些问题也能很容易解决。但是基本的软件/解决方案能力问题更具挑战性。在这种情况下，你需要改变你的操作过程或者管理你的用户期望，而不是等待一个软件修复或者可能永远不会出现的新特性。
最后，请记住，仅仅因为您的服务已经上线，测试的需求还没有结束。考虑作为变更控制的一部分，您需要运行哪些测试。主要的软件更新可以提供新的功能，但有时会破坏现有的功能。考虑是否应该在升级时对关键功能进行基线测试。
总之，有效的测试是不可替代的。你不能把责任让给你的供应商和服务提供商。你需要保持控制。但要相称，对所有功能测试一遍是不可能的。测试对用户真正重要的元素。
我的乌托邦梦想是认为测试是不合理的，因为安装应该是完美的。只是还没发生！
声明：版权所有 非合作媒体谢绝转载
作者：Dave Mailer
原文网址：
https://www.nojitter.com/ucaas/ucaas-testing-why-its-important-how-get-it-right
