• gamma测试报告


    Gamma阶段测试报告

    测试计划及结果

    我们针对测试做了比较多的改进。

    测试代码分为针对纯java部分的单元测试和需要android运行环境的自动化仪器化测试

    单元测试

    这一部分基本继承Beta阶段的框架,使用junit框架,达到了80%以上的覆盖率。

    自动化测试

    除了beta阶段的单元测试以外,我们新增了自动化测试。

    使用google官方提供的espresso框架进行模拟点击,输入,监听等事件。

    另外兼容性测试中也有一部分的自动化测试,是利用monkey脚本测试应用在随机场景下的反应。

    场景测试

    为了保证我们应用的实用性,我们模拟了室外的场景测试。具体手段是在寝室里利用电脑产生的噪声伪装干扰,模拟室外的噪声,然后测试常用命令的输入准确性。

    不同类别的背景噪声下识别率差别较大,没有形成有效数据。但是可以基本得出结论50分贝的背景噪声基本没有影响,60分贝会对识别率造成巨大波动,70分贝以上几乎无法有效识别。所以建议使用时背景噪声控制在50分贝一下。

    兼容性测试

    我们使用了腾讯的wetest平台进行了多种机型的兼容性测试。

    测试结果如下:

    我们在所有的50种机型的随机测试中一共出现了两个问题

    安装失败

    可以发现出现问题的机型全部是低于安卓5的古老版本,这一点在我们的预料之中,我们的发布说明中有指明应用主要适配安卓7.0以上的机型。在实际试用中我们发现安卓5,6也能成功安装,但是只能使用前端的编辑器功能,无法使用后端shell(因为后端使用的包编译指定最低运行API版本是24)。可以把我们的应用当作一个语音记事本使用。

    UI异常(黑屏)

    出现黑屏的机型分布在各个版本和机型。经过我们的排查,测试平台将我们的shell界面识别成了黑屏,造成了这次乌龙。

    应用在其他手机上运行良好,所以我们可以初步判定我们通过了兼容性测试。

    压力测试

    nginx 压力测试

    工具 ab:
      This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
      Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
      Licensed to The Apache Software Foundation, http://www.apache.org/
    
    测试对象:

    http://butubs.cn: 腾讯云,1 核 2 GB Intel(R) Xeon(R) CPU E5-26xx v4 网络带宽 : 1 Mbps

    ab -c 500 -n 2000 http://butubs.cn/
      Server Software:        nginx/1.14.0 # 代理软件
      Server Hostname:        butubs.cn # 服务器主机名
      Server Port:            80 # 默认端口 html 80端口
      
      Document Path:          /  # url 请求路径
      Document Length:        388 bytes
      
      Concurrency Level:      500  # 一次请求的并发量,由-c指定
      Time taken for tests:   19.253 seconds # 测试总共耗时
      Complete requests:      2000 # 总共请求的数量,由-n指定
      Failed requests:        0	 # 是被的请求的数量
      Total transferred:      1050000 bytes # 传输字节数
      HTML transferred:       776000 bytes # HTML字节数
      Requests per second:    103.88 [#/sec] (mean) # 平均每秒完成103.88个请求
      Time per request:       4813.203 [ms] (mean) # 平均每个请求完成时间为4813.203毫秒
      Time per request:       9.626 [ms] (mean, across all concurrent requests)# 如果按照并发数来算的话,平均每个请求的完成时间就只有9.626毫秒
      Transfer rate:          53.26 [Kbytes/sec] received # 数据率,达到了1Mbps一般的带宽
      
      Connection Times (ms)
                    min  mean[+/-sd] median   max
      Connect:       45  203 832.8     47    7268
      Processing:    46 2805 4899.4    112   19099
      Waiting:       46 2789 4907.9    105   19099
      Total:         91 3007 4979.3    276   19148
      
      Percentage of the requests served within a certain time (ms) # 请求处理时间的分布
        50%    276 #  50% 的请求在 276 ms内处理完毕
        66%    895 #  60% 的请求在 895 ms内处理完毕
        75%   2554
        80%   7846
        90%  12285 #  90% 的请求在 12285 ms内处理完毕
        95%  14020
        98%  14821
        99%  15818
       100%  19148 (longest request)
    

    云端的监控:

    可以看出每秒处理一百多个请求还是很轻松的

    ab -g result.txt -t 50000 -c 1000 -n 5000 http://butubs.cn/
      Concurrency Level:      1000
      Time taken for tests:   54.514 seconds
      Complete requests:      4973 # 存在丢包情况,测试使用的北航校园网有点堵,但是不影响压力测试
      Failed requests:        0
      Total transferred:      2610825 bytes
      HTML transferred:       1929524 bytes
      Requests per second:    91.22 [#/sec] (mean)
      Time per request:       10962.023 [ms] (mean)
      Time per request:       10.962 [ms] (mean, across all concurrent requests)
      Transfer rate:          46.77 [Kbytes/sec] received
      
      Connection Times (ms)
                    min  mean[+/-sd] median   max
      Connect:       45  149 931.9     47   15407
      Processing:    46 7201 14740.4    106   53519
      Waiting:       45 7183 14748.6    105   53519
      Total:         91 7350 14773.2    158   53573
      
      Percentage of the requests served within a certain time (ms)
        50%    158
        66%    891
        75%   1990
        80%   7850
        90%  31691
        95%  46402
        98%  50941
        99%  52577
       100%  53573 (longest request)
      
    

    画一个简图:x为请求数,y为时延

    服务器端的监控:

    圆圈所在处,带宽占用达到0.692Mbps, CPU占用8.5%
    

    ab -c 1000 -n 10000 http://butubs.cn/

    再继续增加请求总数的话,丢包就比较严重了,带宽曾被占满,单纯就负载而言,nginx完全处理得过来,是带宽限制了处理请求的上限。

      Concurrency Level:      1000
      Time taken for tests:   94.015 seconds
      Complete requests:      9337
      Failed requests:        0
      Total transferred:      4901925 bytes
      HTML transferred:       3622756 bytes
      Requests per second:    99.31 [#/sec] (mean)
      Time per request:       10069.075 [ms] (mean)
      Time per request:       10.069 [ms] (mean, across all concurrent requests)
      Transfer rate:          50.92 [Kbytes/sec] received
    
      Connection Times (ms)
                    min  mean[+/-sd] median   max
      Connect:       45  103 595.4     47   15533
      Processing:    46 2430 9815.4    104   89275
      Waiting:       45 2407 9820.5    102   89275
      Total:         91 2532 9840.1    151   89325
    
      Percentage of the requests served within a certain time (ms)
        50%    151
        66%    387
        75%    400
        80%    892
        90%   3872
        95%  13729
        98%  31785
        99%  61269
       100%  89325 (longest request)
    

    Android 逆向分析

    最简单的逆向方式: Android Studio 逆向

    • 53% 资源,大小9.4MB, 有不少多余的资源占用
    • 30.7%lib,大小5.4MB, 包含了实际上很少使用到的x86体系的lib,市面上基本没有x86架构的android手机了,基本上都是aarch64
    • 12.4%class, 大小2.2MB, 这是类文件
    • 其他占用很小

    代码安全?

    如果代码没有加混淆,反汇编结果是这个样子的:
    各种类名,继承关系,函数调用都暴露在外。

    可以发现Activity的onCreate方法完全可以被找到,代码逻辑稍微梳理一下就能够弄清,这样的产品很很容易被截取核心技术。

    加入代码混淆:

    加了代码混淆的部分,包名文件名代码全都变得完全难以辨识, 能够有效保护代码和技术。

    不过混淆通常只能防住静态分析

    如果有熟悉动态调试的人员,同样可以在classes.dex加载到内存中时,找到合适的入口,篡改文件,达到想要的效果。不过我们毕竟是一个开源的项目,也没有什么需要保密的技术,所以有了代码混淆就足够了。

    回答问题

    1.在测试过程中发现了多少Bug

    没有新bug

    2.你是怎么进行场景测试(scenario testing)的?包括你预期不同的用户会怎样使用你的软件?他们有什么需求和目标?你的软件提供的功能怎么组合起来满足他们的需要?(仅描述新功能即可

    场景测试可以参见测试计划及结果的场景测试部分。我们新增了软件对于噪音的抗干扰能力的分析。

    角色 使用需求 新增功能设计
    张三 手部残疾,初学者 低门槛 我们新增了对于部分命令的模糊匹配,比如python会被识别成派森等,我们会将这种错误识别重定位成python。分析了适合语音识别功能使用的最佳场景。
    李四 程序猿 功能专业且方便 我们新增了文件管理功能,方便用户在GUI场景下管理自己的文件脚本,对文件进行复制剪切粘贴等操作,替代命令行操作。
    王五 普通人 使用简单,界面友好 我们新增了夜间模式,方便普通人在多种场景下的使用。

    3.你是否有回归测试确保新功能的加入没有影响已有功能?

    • 针对模糊识别
      • 为了保证模糊识别不影响正常的语音识别,我们首先在实现上进行了保证。首先模糊识别只有在shell模式下被识别成非英文输入时才会发挥作用。因为shell命令基本都是英文的,识别成的非英文大概率是错误识别,这个时候才会尝试进行模糊识别。而在编辑器中可能出现中英文混杂的情况下不会进行模糊识别,防止错误。
      • 在shell模式和编辑器模式下分别使用语音输入我们已经进行模糊识别的关键词,然后查看识别的正确率。
    • 针对文件管理
      • 新建文件和文件夹,然后通过各种复制粘贴剪切得到多个脚本。先在GUI下测试,然后在shell模式下运行。能正常运行视为通过了回归测试。
    • 针对夜间模式
      • 夜间模式和软件的基本功能基本独立,没有依赖性。所以经过兼容性测试,可以视为通过了回归测试。

    4.给出你的测试矩阵

    详见测试计划及结果的兼容性测试部分。使用腾讯的wetest平台进行多种机型的测试。具体矩阵如下:

    手机品牌 型号 系统版本
    Meitu M6 6
    华为 荣耀畅玩4C 增强版/电信4G 4.4
    华为 VCE-AL00 9
    华为 P8 mini 电信版 4.4
    Meitu M6S 6
    Vivo V1813BA 8.1
    华为 荣耀平板2 6
    OPPO N1 Mini 4.3
    华为 P9 Plus 6
    酷派 大神F2 HD 4.4
    三星 GALAXY Grand 2 联通版 4.3
    华为 荣耀 Note8 全网通 6
    三星 GALAXY Note 2 4.3
    三星 Galaxy Note 5 6
    ONEPLUS 1 4.4
    三星 GALAXY Mega 4.3
    华为 荣耀V8 高配版/全网通 8
    360 N5S 7.1
    三星 GALAXY Note 8 7.1
    魅族 M3X 6
    华为 P9 标准版 7
    小米 4c 5.1
    努比亚 Z11 标配版 6
    华为 Mate S 臻享版 双4G 6
    三星 GALAXY J7 5.1
    华为 荣耀9 全网通 7
    Meitu M8s 7.1
    三星 GALAXY On7 5.1
    小米 MI PLAY 8.1
    华为 nova 2 全网通版 7
    魅族 15 7.1
    三星 GALAXY J3 Pro 电信4G 5.1
    华为 荣耀Magic 6
    金立 金立天鉴W909 5.1
    三星 GALAXY S5 6
    华为 荣耀V8 /双4G 7
    华为 Mate S 臻享版 电信4G 6
    ZUK Z2 7
    HMD Global Oy 6 全网通 7
    华为 nova 2 Plus 移动版 7
    华为 P8 青春版 移动4G 5
    努比亚 M2 6
    小米 4S 5.1
    Philips X598 7
    华为 畅享7S 高配版 全网通 9
    YOTA Y3 7.1
    tencent WeTestE9 7
    三星 Galaxy S10 9
    三星 Galaxy S9 移动联通电信4G 9
    华为 荣耀6 Plus移动4G 4.4

    5.你的软件Gamma版本的出口条件

    通过beta,Gamma阶段的种种功能测试和兼容性测试,具备我们规划中的全部功能。

  • 相关阅读:
    MySql
    Zookeeper
    Kafka
    Mybatis
    Spring/Spring MVC
    Spring Boot/Spring Cloud
    网络
    设计模式
    Strassen algorithm(O(n^lg7))
    dynamic programming:find max subarray
  • 原文地址:https://www.cnblogs.com/bingduoduo/p/11013818.html
Copyright © 2020-2023  润新知