gamma测试报告

最新推荐文章于 2021-09-23 21:11:31 发布

weixin_30338743

最新推荐文章于 2021-09-23 21:11:31 发布

阅读量624

点赞数

文章标签： shell 运维测试

原文链接：http://www.cnblogs.com/bingduoduo/p/11013818.html

版权

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阶段的种种功能测试和兼容性测试，具备我们规划中的全部功能。

转载于:https://www.cnblogs.com/bingduoduo/p/11013818.html

weixin_30338743

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
gamma测试报告

Gamma阶段测试报告测试计划及结果我们针对测试做了比较多的改进。测试代码分为针对纯java部分的单元测试和需要android运行环境的自动化仪器化测试单元测试这一部分基本继承Beta阶段的框架，使用junit框架，达到了80%以上的覆盖率。自动化测试除了beta阶段的单元测试以外，我们新增了自动化测试。使用google官方提供的espresso框架进行模拟点击，输入，监听等事件...
复制链接

扫一扫