#26 楼 @xuben 我们这的自动化效果是从满足测试需求出发，不服务于项目测试需求的自动化都是白搭。

#25 楼 @xuben 我的理解：自动化是服务于手工测试，解放重复性固定的测试工作，及稳定的专项测试的自动化。机械化的自动化思维可以减少固定 case 的漏测。

#24 楼 @xuben 我们的自动化团队是测试需求服务团队，从测试需求出发提供辅助的自动化测试方案和测试工具，除了自己 cover 测试任务，也要交付稳定的自动化测试方案。还有就是测试工具方案推动研发自测的需求，具体的实现入口就是 apk 启动选择测试 case 启动测试任务。

#21 楼 @xuben 我们的录制回放根本需求是：解决手工测试组可以简单的建立测试脚本实现多次压力测试及多 case 的依次测试的需求，易于生成脚本执行，易于维护。把简单自动化用例的编写及执行放给手工组测试人员。

#20 楼 @xuben 暗自庆幸，我的领导自上而下都是重视自动化，而且也对自动化程度的认知很到位，在推动自动化上支持力度很高。在推动手工组执行，我是从压力测试入手，解决手工压力他们的配合程度很高的。至于自动化 smoke 和 mtbf 我们是 cover 在自己的手里控制，稳定成熟后才交付。

#29 楼 @xuben 我们在实践简化生成 case 的方式，使手工测试人员使用录制方式设计 uiautomator 的 case，使用回放工具解析录制的 xml 进行 case 的执行。出发点还是让不懂代码的可以直接设计简单的 uiautomator case。实现简单 case 可独立完成自动化测试及多次压力。

#34 楼 @alfor 重构了之前的就删了 (https://testerhome.com/topics/3685)

#11 楼 @anikikun 确实，适合初入手自动化的闲时翻翻，工作忙时没时间看， 我就是挑标题感兴趣的点看了看。回复只是为了顺便说下想买的没必要去 jd，jd 贵。

亚马逊买了一本，本来想看看录制回放怎么做的，结果没什么实质收货，放一边闲置中。亚马逊和淘宝会便宜一些

#9 楼 @yuwuhen333 涉及音频的不多，只是涉及重复播放，遍历播放操作类的压力测试，音质还是已人工测试为主，音量曲线调整也是功能感官验证，bsp 人员调音量曲线。

#7 楼 @monkey release 用户版本之前，dailybuild 和用户版本测试，辅助黑盒的手工验证，为评估 app 集成和用户版本是否发布的相关工作，服务于手工组，自动化工具推动研发在 release 前自测，回归用户反馈

#5 楼 @monkey 我们测试的是设备端，数据上报是研发自己解决，再有就是乐视云负责数据收集，另外的独立部门负责的。我们测试中心不涉及数据上报的处理

维护更新了脚本：
1、去 root，使用 push 的 busybox，需要无 root 情况，可以正常执行 moneky 和 input 命令
2、root 情况也可执行区别在于会保存 trace 和 tombstone 文件，否则只能从 moneky 的 log 或 bugreport 中获取
3、bugreport 文件较大压缩保存
4、监控负载优化，去除并发进程的获取方式，用类型参数控制是否抓取 heap

#13 楼 @walkwall 你在 busybox 官网下个对应版本 busybox push 到手机上实际试下不就清楚了。
adb push busybox /data/local/tmp
adb shell chmod 755 /data/local/tmp/busybox

我主要需要用它做字符串处理的一些事情，还有 top 等不需要权限的命令。

#9 楼 @tbya 我这边也在想遍历测试这事，因为没完全想好解决方式，还是在现有的随机 monkey 的方式上进行改善。

我这边测试中心是系统测试为主，monkey 的压力测试上既有评估上线版本需求，也有平时压测需求，所以控制了下交付方式，不一定让执行人员十分清楚 monkey，知道怎么执行和分析结果就把活干了。

测试评估上按压测总时长内发生异常情况的统计为衡量对象。

#7 楼 @seveniruby 写这篇是说下目前重构了之前写的 shell 管理 monkey 压力测试，及重构过程和重构结果。没有侧重交付使用的表达，交付使用是我们内部专项的内容，写的内部 PPT 交付的手工测试执行组。付的源码中有说明，而且代码中有注释就没细写这部分内容。之前在犹豫是不是要把自己写的内部 PPT 发出来，是目前两项专项测试项内容。考虑自己写的是内部文档就没放出来。
使用方式就是设计主控逻辑的脚本进行测试，监控都是独立进程写的。脚本是设备端的 shell 脚本，用途是设备端后台执行，不用长连接 PC
两行代表一项测试

# 执行实例：
# 方式1 执行case.sh已写好的case：$1时长?秒; $2-用例编号；$3-用例参数
# monkey_test 60 0 "com.letv.app.appstore"
# monkey_timeout 60 
# 方式2 按参数执行moneky语句：$1-时长; $2-限制范围；$3-事件比例; $4-monkey log文件名
# monkey_test 60 "-p com.letv.games" "--pct-touch 20 --pct-trackball 5 --pct-motion 35 --pct-flip 5 --pct-appswitch 30 --pct-anyevent 5" "letv_games"
# monkey_timeout 60 

组件形式 APP 需要三行

monkey_test 7200 0 "com.letv.lesophoneclient"
##保持am唤起主activity，间隔1S如不显示则唤起
longam "com.letv.lesophoneclient" 7200 "com.letv.lesophoneclient/.ui.MainActivity"
monkey_timeout 600

#5 楼 @tbya monkey 是按事件比例配置的：touch、motion、trackball、syskeys、nav、majornav、appswitch、flip、anyevent、pinchzoom
用事件比例控制测试事件类型

#1 楼 @lihuazhang 控制了读写量，log 采用筛查方式，连续做个一两天的 monkey 压力，总体记录的量还可以承受。TV 和盒子可以直接写外接 u 盘里。目前实际使用中 30 几小时的压力测试没什么问题。

逻辑上通过 SurfaceFlinger 判定界面显示状态，未锁屏则发键值 26 锁屏；锁屏壁纸界面则滑屏就是打开，挺好实现的逻辑。
设备端 shell 脚本我是这么写的，逻辑上是这样的，写成 java 脚本也可以。

#锁屏函数$1:0--lock;1--unlock
#屏幕物理分辨率
export wm_size_x=`wm size|busybox awk -F" |x" '{print $(NF-1)}'`
export wm_size_y=`wm size|busybox awk -F" |x" '{print $NF}'`
lock(){
while true;do
    case `dumpsys SurfaceFlinger|grep "|....|"|busybox awk 'BEGIN{r="o"}{if($NF=="com.android.systemui.ImageWallpaper")r="l"}END{print NR-1 r}'` in
        "1o")
            local state=0
        ;;
        "3l")
            local state=1
        ;;
        *)
            local state=2
        ;;
    esac
    case $1 in
        0)
            if [ $state -ne 0 ];then
                input keyevent 26
            else
                break
            fi
            sleep 1
        ;;
        1)
            if [ $state -eq 0 ];then
                #我这是上滑屏解锁，其他的改下参数就好了
                input keyevent 26&&sleep 1&&input swipe $((wm_size_x/2)) $((4*wm_size_y/5)) $((wm_size_x/2)) $((wm_size_y/5))
            elif [ $state -eq 1 ];then
                input swipe $((wm_size_x/2)) $((4*wm_size_y/5)) $((wm_size_x/2)) $((wm_size_y/5))
            else
                break
            fi
            sleep 1
        ;;
    esac
done
}

#23 楼 @andyguo 开始写的时候测试的是高通取的 cpu 温度，实际测试 cpu 温度和电池温度一直一样，后来发现 MTK 不兼容就做了兼容处理，全部取了电池问题，模板没改还是 cpu 温度。
下面是取温度的兼容，看注释。存在哪个取哪个，毕竟不同平台情况互斥，不会共存。
# 判定高通和 MTK 兼容获取电池温度不同
if [ -f /sys/class/power_supply/battery/temp ];then
temp="/sys/class/power_supply/battery/temp"
elif [ -f /sys/class/power_supply/battery/batt_temp ];then
temp="/sys/class/power_supply/battery/batt_temp"
fi

#23 楼 @andyguo 。。。。。。你取的是电压。voltage_now，你这精度是μV，看清英文 battery/voltage_now，电池当前电压

#21 楼 @andyguo 可以移植到 PC，如果 PC 是 linx 的话，很容易直接把 busybox 的换成 pc 本地的命令，把权限受限无法使用的去除，windows 改成 bat 写起来会麻烦点，不过也是很容易可以实现的。就是连 PC 长时间跑的话，需要解决供电，需要购买 2A 输出的带外接电源的 hub。

把当前我自己在项目中使用的实例发上来了，可以参考，定制为所需的执行逻辑。

monkey 压力执行脚本：(http://pan.baidu.com/s/1jG2dtHG)
筛查异常：（logcat -v time）(http://pan.baidu.com/s/1gdg4K99)
BTM（电量 - 电压 - 温度监控）：(http://pan.baidu.com/s/1kT92OJX)

其中把结果保存在/data/目录下是由于测试了文件管理和图库，结果放 sdcard 下可能被 monkey 操作。就换了文件管理类 app 控制不了的 data 目录保存结果。