概要：移动社交应用的明确功能是发送和接收消息，推送通知以及共享媒体（如照片，音频和视频）的能力。在为这些应用创建测试策略时，跨平台兼容性是一个重要的考虑因素。以下是你应该包含在移动社交应用的测试策略中的一些场景。
随着无数的社交应用涌入市场，消费者被宠坏了（选择过剩）。这种压力使应用需要更加流畅和平滑，从而随时间可以保留用户的兴趣。
为了测试移动社交应用，测试人员需要能够像用户一样思考 - 无论如何，大多数人都可以 - 并且仍然能够想象出难以想象的并且想不到的想法。无论它们看起来如何美妙，识别和消除边缘情况，对于定义项目范围至关重要。
我们来看看测试移动社交应用所涉及的一些测试场景。
推送通知
简而言之，推送通知是由应用“推送”到你的设备的社交媒体或短信提醒。这可能是社交应用提示你的某些内容像“您有新消息”那样无害，或者它可能是一家零售商，告诉你有关可用的最新交易。
推送通知很有趣，因为他们从应用中了解你的参与历史，然后根据你的互动向你发送提示。
每个操作系统（Android，iOS，Windows和BlackBerry）都具有推送通知服务（PNS）。应用发布者必须注册他们打算发布应用的每个操作系统的推送通知服务。PNS反过来为应用提供了一个API。应用发布商将应用上传到应用商店，并将其提供给用户。
当用户下载并安装应用时，该用户和该设备的唯一ID将被发送到设备操作系统的推送通知服务。这些凭据存储在应用服务器中，以便验证后可以发送推送通知。由于证书是特定于设备ID的证书，因此应用程序必须部署到要测试的实际设备。
因此，当我们测试推送通知时，测试用例对于不同的操作系统可能是相同的，但行为可能不同。为了讨论这，我们来谈谈Android和iOS设备。
我们为应用可能在前台或后台运行时创建单独的测试用例。假设用户A正在与用户B聊天。对于iOS和Android设备，对于在同一个聊天线程中收到的消息，不会有视听警报。但是，在这段时间内，用户C会向用户A发送消息。在Android设备上，用户A将收到声音和视觉提示，而在iOS上，他们只会收到声音提醒。
当应用在后台运行时，在Android上，提醒将显示在通知面板上，直到用户通过应用访问这些提醒。在iOS上，提醒会在通知面板上显示几秒钟，然后会下降到桌面上的应用程序图标，并显示在接收消息的标记计数中。
Android和iOS即使显示来自多个发件人的邮件的方式也不尽相同。在Android上，消息将会聚集在一起并显示为，例如“来自2个对话的3条新消息”。在iOS上，来自单个发送者的邮件将分别显示在通知面板中，并显示来自每个发送者的最新消息。
在锁定屏幕上，如果用户选择显示推送通知，我们应该测试它们是否按设计显示，以及它们是否可操作 - 是否可以滚动浏览消息并仅在弹出框中回复，而无需解锁设备。
推送通知在不同平台、屏幕尺寸和分辨率下，对同一应用的行为可能会有所不同。
多设备
测试时，并不总是可以方便地拥有所有操作系统配置的设备。为了解决这个问题，我的团队使用了目标市场的使用情况报告。在此基础上，我们采用了每个正在使用的移动品牌的前四款机型。这个想法是测试每个设备的最新版本和它之前的一个版本，从而确保客户端的测试覆盖率达到80％。
对于第一个版本，我们的目标是覆盖率是50%。对于每一次的发布，计划将覆盖率提高5%到10%。发布后，着眼于衡量产品的成功与否，我们采取了用户的一部分——占据我们大部分消费者群体的用户，评估他们对该应用的接受程度。每次测试覆盖率的增加将取决于商业智能报告。
媒体传输
媒体传输是社交应用的重要方面。以原始未压缩形式传输媒体的成本非常高，因为它需要千兆字节的带宽并且更耗时。
对于社交应用，由于数字媒体内容在传输之前被压缩，因此数据质量在某种程度上会受到影响。每次数字内容被进一步分享时都会有部分数据丢失，但这几乎不引人注意。此外，数据的传输、存储和检索的便利性，弥补了数据质量的无穷小损失。
这里QA的作用是测试图像质量损失不应超过规定的限制。重点不在于测试媒体传输的质量，而在于传输的速度，这是通过负载测试来完成的。
我们还必须测试设备上的删除媒体。当你通过社交应用发送媒体并且接收者下载它时，其本地副本将在其（接收者）设备上创建。当你收到它时，你的设备中也会有一份副本，但你也将在设备中分别为每个收件人提供媒体资源，因为该应用会在设备上维护资源数据库。
如果你尝试从一个线程中删除媒体，则不应从其他线程中删除该媒体 - 只应删除该收件人的资源。即使你从所有收件人聊天线程中删除对该媒体的所有引用，仍会保留设备上的本地副本。只有在删除本地副本时，所有对该媒体的引用才会从设备中删除。
负载测试
对于负载测试，从QA角度来看，两个因素至关重要：速度和用户负载。为了测试这些方面，我的团队使用API工具在API调用中指定负载和预期响应时间，然后验证响应的结果。
假设我们必须在十秒内测试千位用户之间的媒体传输。我们将需要运行一千个API调用 - 这是API测试工具的用处。从这些API调用的结果中，我们可以计算出平均响应时间，并根据所传输数据的类型（文本，图像或视频）进行处理。
在本地运行API调用会使工作流程依赖于本地网络速度，因此测试工具服务器应该理想地位于API服务器所在的位置。如果测试团队进行远程操作，则应在API服务器中将测试服务器的IP地址列入白名单。
测试用例会因所共享的媒体类型而异。对于视频，我们应该测试：在每次连续传输之后，视频的播放长度被保留下来。或者，假设有一百名用户正在向一用户发送视频。使用我们的测试工具，运行该脚本，以使其表现得好像所有用户都在发送相同的视频文件，以便我们可以统一评估响应时间。
这里还有一个场景：用户同时上传视频时可以启动多少个聊天线程？他们可以将相同的视频上传到多个聊天线程，或者他们可能正尝试上传多个视频。对于这个项目，我的团队选择了最多四个线程的视频上传限制。
为了获得最佳的数字，我们开始增加用户的数量，直到我们识别出性能的恶化，然后停在那里。我们确定了该特定行动所需的时间，然后我们从响应时间的允许延迟开始反向工作。考虑到互联网速度，用户的状态变化应该在特定时间内可见 - 比如说1秒。因此，考虑到几乎90％的时间都消耗在互联网传输上，我们仅剩下10％的时间 - 即服务器处理消息的时间为十分之一秒。
考虑用户
有这么多流行的社交媒体应用，它们都有不同的功能。但是他们有一些共同的核心方面，用户希望这些方面能很好地为他们服务，无关他们的设备或操作系统，或者即使他们想同时发送四个视频。设计将主要移动社交应用功能考虑在内的测试场景是很重要的，这样每个用户都可以有一个好的体验。
由ruink翻译自 Krishnan Govindarajan 的《Designing Test Scenarios for Social Media Mobile Apps》一文。