专项测试案例--上传成功率对比专项测试

前言

今天分享一个专项测试的一个解决案例，是项目上一阵子重构后某逻辑模块的一次专项对比测试，最近终于有了时间，赶紧写下来。
然后，吐槽一下结果，对的，逻辑维持原样，无法推动任何人去做逻辑优化的事，也就是本篇提出的改进建议没有采纳。虽然创业公司不重视质量和测试，但是我还是坚持做下去。(气愤x3)

一明确客户反馈的问题–分享总是失败

在版本发出去之后，总是有用户反馈：分享又失败了，然后截图给我们，我们也很汗，因为之前从没有过上传方面的类似经验，负责这块的测试同学也只是在功能层面模拟不同网络和不同资源上传成功就行了，在弱网下研发给出的解释就是，网络不行，我们用的是sdk上传，换个正常的网络就行了。
作为专业的测试怎么能相信开发的说辞呢，于是进行了一次针对性的专项对比测试

二结合竞品分析成功率低的原因

在所有工作开始前，我们必须先理解项目的分享流程，以下是一个简略的上传流程图：
【上传流程图】
first，app需要向服务器拿一些认证信息，这些认证信息可以理解为上传所必须要的一些值
second，客户端需要导出全景资源的一些文件，也就是一个全景资源将会生成4个不同的文件，其中3个是比较小的图片文件，另外一个是比较大的原图/原视频文件。
third，调用服务商提供的sdk依次上传这4个文件。
fouth，后台生成分享链接，返回客户端。
在理解了整个上传的概要后，我们正式进入测试。

为了更好地发现问题，我们先模拟用户进行了网络拥塞和低网速上传的测试。
关于测试方法，如果方便的话可以考虑去繁忙的购物中心，如果不方便可以通过软件模拟，笔者弱网是通过限速wifi热点的方式模拟的，虽然不能100%模拟用户的使用环境，但是胜在方便。

在经过一轮测试之后，可以发现一些问题，如图：
【不同网络下】

那么我们可以从图中我们得出一些结论：
1.抖动的网络下100%失败
2.在较低网速下高概率失败

同时结合平时测试中的体验发现，在传输大文件失败后(比如一个N分钟的视频),我们提供重试的机制，点击重试按钮都是恢复到最初始的流程，于是第3个结论：
3.大文件失败率高，失败后重新上传所有资源

为了得到解决问题的信息，我们研究下上传相关的代码：

public void uploadFile(final String bucket, final String objectKey, final File file) {
        ... ...

        OSSClient ossClient = new OSSClient(context, endpoint, credentialProvider);

        PutObjectRequest request = new PutObjectRequest(bucket, objectKey, file.getAbsolutePath());
        if (progressCallback != null) {
            request.setProgressCallback(progressCallback);
        } else {
            request.setProgressCallback(this);
        }

        task = ossClient.asyncPutObject(request, successCallback);

        ... ...
    }

用了阿里云的服务器，经过查询阿里的相关文档，我们发现这种上传方式是最基本的上传流程，采用的是默认定义的配置，然后我们还发现，阿里定义了一个配置类给我门调用：

public class ClientConfiguration {
    private static final String DEFAULT_USER_AGENT = VersionInfoUtils.getDefaultUserAgent();
    private static final int DEFAULT_MAX_RETRIES = 2;
    private int maxConcurrentRequest = 5;
    private int socketTimeout = 15000;
    private int connectionTimeout = 15000;
    private int maxErrorRetry = 2;
    private List<String> customCnameExcludeList = new ArrayList();
    private String proxyHost;
    private int proxyPort;

阅读相关的参数可以发现阿里默认的配置重试次数和超时时间是偏短的，于是可以通过配置相关参数提高抖动失败的概率，经过修改第1个问题基本解决。

第二个问题，这个目前没啥办法，因为查找相关资料并未发现优化的地方，再加上这么弱的网络用户基本不会有耐心在这么弱的网络上传的操作，所以问题不大。

第三个问题，笔者开始参照竞品针对大文件的处理逻辑进行对比。

在竞品方面，笔者参考的是米家全景相机app和GeerVR社区，原因是这两个软件知名度比较高，并且支持全景视频的上传分享。

在参考米家的上传的时候，发现米家在上传资源的时候，会有预转码操作：
【米家预上传】
对比我们的产品是用户输入完分享标题的时候，手动点击才去执行转码上传，那么对于用户的直接体验就是，米家的上传速度会优于我们的上传速度(实测的速度其实差不多，但是体验上会给用户造成错觉)。

接下来再来分析GeerVR社区的文件上传，使用了断点续传功能，使用断点续传功能，可以最大地节省用户流量，同时因为是分段，上传这一过程可以被中断，体验是比较好的。当然了，有利有弊，上传每一个分段就相当于上传一个新的文件，流量以及耗时会上升。

三提出优化建议，解决问题

在知己知彼后，我们总算对自己和别人家的产品有个大概的映象，接下来我们需要制定优化建议帮助app进行调优。

在经过步骤二的测试对比分析后，我们得出以下优化结论，除了固有的建议外，还额外结合项目的实际逻辑加了两条优化建议：

1.可以考虑在分享的时候，加上预导出和预上传逻辑，加快用户体验
2.区分视频和图片，获取区分大小，使用不同的上传策略，加入断点续传功能

同时，结合实际的项目需求，提供了失败重传的机制，当时为了快速发版，重试机制点击重试是整个流程重试，而没有加入单个环节重试，具体原理如下：
【分享流程改进】
可以看出，优化前不需要判断流程的进度，直接全部reset，而优化后是需要程序控制知道你走到哪，哪里失败重试哪里，于是给出了这个结论：
1.优化失败重试机制，已经导出/上传过的资源不重复上传

最后，经过上面的一轮测试，我们可以汇总一下结论：

1.在资源上传之前，计算待上传资源的md5，如果服务器存在，那么触发秒传逻辑
4.针对超过一定大小的大资源视频，加入断点续传
1.可以考虑在分享的时候，加上预导出和预上传逻辑，加快用户体验
2.区分视频和图片，获取区分大小，使用不同的上传策略，加入断点续传功能
5.上传失败后，重试应该从某个失败的节点开始重试，而不是全部重试(业务逻辑相关)

嗯，最后把测试过程整理，附上专项测试报告，抄送全组同学，大功告成！
这里写图片描述

PS：竟然写了2k字，上学的时候写个800字的作文都要命 (┬＿┬)