下午好，我叫Alexander Ulanov，我是Odnoklassniki的测试工程师。 在本文中，我想谈一谈我参与的项目之一。 我会立即警告您：在本文中，您不会发现任何发现或测试方法的复杂方法。 但是，本文中描述的开发和测试过程可能对某人很有趣甚至有用。
第1集：OTRS中的恐惧与厌恶
OTRS是一个请求处理系统，它使参与任何项目的技术支持的组织可以共同解决用户问题。 该系统是用Perl编写的，开发人员一直支持到2017年11月。
这是我们多年来使用的OTRS系统，用于处理来自用户的所有呼叫。 多年前就决定使用OTRS。 然后有一个简单的任务：找到现成的解决方案并迅速使其适应我们的目标。 太糟糕了，我将解释原因：
- 我们根据需要使用了OTRS系统的定制版本，因此（直到2017年秋季）对其进行更新（从某种程度上来说）非常困难；
- 随着时间的流逝，我们开始理解该系统依靠其“天花板”负载而停止应对来自用户的应用程序数量；
- OTRS系统以完全依赖OK.ru社交网络更新的方式集成到整个基础结构中。 这使得每周仅一次更新OTRS成为可能；
- 90名支持人员只能在几个小时内提供投诉的答案；
- 我们身边对系统的每次更新的测试都变成了一场噩梦，因为 即使最小的更改也可能破坏任何节点上的系统。 当添加新功能时，开发和测试过程变成了数周的系统调试。
- OTRS本身是用Perl编写的。 OK.ru项目中几乎未使用的语言会带来其他问题；
- 也许主要的问题是邮件！ OTRS以电子邮件形式处理投诉。 这是在2016-2017年！ 因此，大量设置，使用邮件服务的功能以及长时间等待用户回答的问题，在通过邮件与支持人员进行通信时是不可避免的。
第2集：我们想要得到的
自2015年以来，公司开始提出完全脱离OTRS的想法。 关键任务：摆脱邮件的使用，并提供快速而及时的响应用户的能力，而无需增加支持人员的数量。 最明显的解决方案是在线支持服务。
同样，没有人愿意在全新的系统上花费资源。 使用您的内部服务更为合理，因为内部服务的功能已经具有经验和测试覆盖范围。 加上纯粹的技术要求：能够随时对新系统进行更新，而不必依赖其他团队。 是什么使我们能够灵活地进行开发和测试。
大约在同一时期，OK.ru看到了邮件系统的全球现代化。 基于新消息，决定实施新的在线支持系统（以下称为“ oSupp”）。
第3集：策划
在开发oSupp的早期阶段，以及无数次会议的结果，我们看到了许多问题。 主要的问题是不可能立即立即将所有工作从OTRS切换到oSupp：
- 有必要全面评估新系统如何应对技术负担（回想一下，我们正在谈论每天处理10-12K投诉）；
- 有必要培训员工在新系统中工作；
- 有必要对用户和支持员工进行A / B测试，并评估他们将如何应对负载；
- 技术限制：OK.ru消息传递从未与未经授权的用户一起使用。 在支持工作中，与未经授权的用户进行交流几乎占所有投诉的三分之一。
- 要测试系统，您需要提供一个与真实环境尽可能相似的环境，但不能访问实时用户。
我们认为最好的方法是分三个阶段实施和实施oSupp：
- 原型开发和测试。
- 实施oSupp来处理来自OK.ru授权用户的呼叫。
- 新的oSupp系统可全面覆盖所有呼叫。
第4集：测试和调试
为了测试原型，创建了一个测试环境，该环境能够生成来自测试用户的调用，并且能够将oSupp连接到OK.ru测试环境。 在此应注意，新系统的设计方式是直到与操作员直接通信之前，用户方面都不会改变。 保留了熟悉的“帮助”部分，保留了网站上可识别的主题类型和FAQ。
到目前为止，测试方面没有任何改变。 自动测试的所有测试计划和覆盖范围均未更改。 U-方便！
用户找到上诉主题并填写必填字段后，该消息落入oSupp系统，并且用户与“消息”部分中的一名支持员工进行了聊天。 当系统中有免费操作员时，对话立即开始。 否则，还将创建聊天，并且用户会收到一条自动的第一条消息：“操作员会尽快与您联系。”
再次-测试过程中的最小变化。 这是定期的聊天，对他而言，没有必要制定新的测试计划。 U-方便！
但是为了确保员工的工作，该系统是从头开始创建的。 所需要的是一种快速的系统，该系统应允许在线数十名员工同时工作，并且每天能够处理数千个呼叫。
开发和测试是迭代的。 大约每周一次，我们向系统添加了新的功能模块，这使我们无法保存任务，并逐渐通过测试覆盖系统。 我编写了文本案例进行测试，同时突出显示了可以自动化的案例。 开发功能全面的原型的过程花了我们大约五个月的时间。
结果，我们得到了一个Web服务，操作员-操作员可以登录并接受用户的处理请求。 对于一组支持人员，我们进行了几次A / B测试，以了解在此阶段他们在新系统中工作的便利性和可理解性。 这是一次有益的经历。 我们能够在测试环境的人为创建的负载上测试oSupp系统。 但是，这不能保证在现实世界中我们不会遇到问题。
2017年2月，我们开始在产品环境中引入新系统。 如我先前所写，联系客户支持时，用户必须选择联系主题。 对于系统在实际用户上的首次测试，我们选择了几个负载最小的主题。 该系统以这种形式工作约一周。 用户不需要A / B测试，因为 门户的功能几乎没有变化。 在oSupp方面，三个在线运营商负责处理负载。 我们迅速跟踪了可以立即解决的问题，因为 新的oSupp系统不再与主门户网站的更新捆绑在一起。 现在，我们可以更新系统并在需要时解决问题。 U-方便！
逐渐地，我们增加了通过新系统处理的主题数量。 有了如此平稳的部署，我们不仅可以控制负载，而且可以逐步培训支持人员以使用新系统，而无需分散他们的工作量。 到2017年夏中，大约35％的请求已由在线服务转移到处理中。 我们已有三分之一的员工通过oSupp工作。 系统涵盖了文档，测试计划和最低限度的自检，这些都是在更新系统时启动的。 到2017年12月，我们在线转移了授权用户的所有应用程序。
接下来的重要步骤是为遇到身份验证问题的用户提供在线支持。 与那些忘记密码，被黑，被阻止或者只是非标准呼叫用户的人有关。 此阶段的关键技术问题-OK.ru消息传递系统历来被设计为对应于“ OK用户（在我们的情况下为支持操作员）-OK用户”形式的通信。 但是我们需要确保“用户可以（操作员）-未经授权的用户”这种情况的工作。
支持团队开始与OK.ru消息团队紧密合作。 结果，发明了解决方案，使得可以直接在OK.ru登录屏幕上接收与支持服务运营商的在线聊天。 同时，已经存在且已调试的oSupp系统不需要更改。 在线聊天的新本质在改进的OK.ru消息传递引擎上起作用。 U-方便！
我们于2018年初开始执行此决定。 在测试方面，也没有特殊困难，因为 这样的聊天功能很少。 首先，我们为网络上未经授权的用户的投诉提供了支持。 目前，正在对来自移动应用程序的此类投诉提供支持。
第5集：摘要
从原型状态到全面运营服务，oSupp移至2018年夏季。 截至2019年3月，通过在线支持处理了60％的请求。 工作人员没有改变。 90位在线支持服务员工每天处理大约6,000起用户投诉。 在门户网站的高峰活动期间，等待操作员响应最多需要10分钟。 在正常工作量下，操作员会在1-2分钟内做出响应。 由于转为实时在线交流，成功恢复了用户对个人资料的访问权限已增长了15％。
现在，我们拥有自己产品的100％，我们可以随时随时对其进行修改。 该团队不再依赖于OK.ru门户的更新。 新的应用程序处理系统用Java编写，它实现了许多OK.ru服务。 测试案例完全涵盖了oSupp系统的测试过程，并且通过自动测试确保了其更新。
我必须指出，我们还没有完全放弃OTRS。 离线支持系统于2017年中被冻结，目前正在扮演保险的角色。 有一些不道德的用户打来电话，他们喜欢漫无目的地发送垃圾邮件给支持服务。 OTRS还处理由于特定原因无法在线处理用户的呼叫。 现在，我们团队的计划包括实现处理来自移动应用程序的呼叫以及实现聊天机器人系统。
但是，我们的主要目标已经实现-我们正在远离邮件的使用。 现在，为解决问题，我们的用户会收到快速，及时的答复。
我们的主要成就：用户大大减少了等待响应和获得帮助的时间。