本来计划测试作为版本的一个内容来说,结果发现版本废话有点多,太长了;而且测试要点也挺多的就还是分开了。在这里主要介绍一些与测试相关的内容。
在关于版本的总结中,已经说了对于一个版本提测,要有一个专门的提测流程。对于一些重点项还该有具体的说明(结合自身实际制定了一个提测前的版本checkList)。
让版本提测有一个标准化的提测流程,只有流程化了才能减少出错的机会,提高版本质量,降低开发和测试的工作量。
当然,对于我们来说,这个相对比较简单,内部有专门的系统去管理版本的提测,因此就已经有了一定的流程。我们的重点就变成了一些重点项的检查。目前的提测流程主要包括三部:
出自测版本包,根据版本功能完成功能自测和一些基础的自动化测试。
这可以理解为先消除一些最基本的问题,用一些自动化工具先检查一边。
检查版本提测前重点检查项并记录结果。这是提测前最重要的一环。
这也是保证版本出现低级错误的关键,我们根据一次次爬坑的经验总结了一系列的检查项(后面专门说明)。开发者可以根据自身需要制定自己的流程。
准备版本更新说明:这里要详细列举这次版本变更的内容以及对应的测试方法。
有时候有些功测试虽然知道需求,但是她并不知道怎么测试,写清楚详细的步骤有助于他们初步了解这个功能的具体实现。
出包、确定最终的版本代码tag,提交测试。
一般前两步确认没有问题以后,这一步几乎花不了多少时间。
接下来我会把上面四个流程中比较重要的环节再介绍一下:
早期,我们这一步几乎没有,这一步主要就是本地先验证下ant打包是不是正确,而具体的新功能自测和验证是放在checkList里面。后来我们做了一些基于UI的自动化测试,然后我们就把基础功能的自动化测试和mokeny性能测试提前到这里。所有工作通过一个脚本完成。下面就是某个SDK的出包验证和自动化测试的一个批处理程序。里面通过ant生成最终版本包,然后配合自动化测试完成一些版本正式提测前的基本功能验证。
call ant
call copy .\docs\AGSDKTest.apk .\bin
cd .\bin
adb uninstall com.example.agsdkdemo.test
adb install AGSDKTest.apk
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0b_svnlocal.apk
call adb shell am instrument -w com.example.agsdkdemo.test/ android.test.InstrumentationTestRunner
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0b_svnlocal.apk
adb shell monkey -p com.example.agsdkdemo 100 -v
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0t_svnlocal.apk
call adb shell am instrument -w com.example.agsdkdemo.test/android.test.InstrumentationTestRunner
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-debug-0.0.0b_svnlocal.apk
adb shell monkey -p com.example.agsdkdemo 10000 -v
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-test-inner.apk
call adb shell am instrument -w com.example.agsdkdemo.test/android.test.InstrumentationTestRunner
adb uninstall com.example.agsdkdemo
adb install AGSDKSample-test-inner.apk
adb shell monkey -p com.example.agsdkdemo 10000 -v
echo "succ" & pause>nul
之所以制定版本发布的checkList,就是因为经常会因为一些很小的问题而影响版本的质量。毕竟每次提交测试前需要确认的问题很多,例如功能验证、开发过程中一些临时增加的一些断点、为了配合开发做的一些调整等等。一个有效的checkList可以协助我们梳理所有容易犯低级错误的地方。这里就列举一下我们的checkList并做一个简单的说明。先列举一个完整的:
推荐做法之新版本、回归版本提测:
提测前版本相关重点检查项目:
对比TAPD需求单和BUG单, 确定是否完成所有需求以及所有BUG修复
自己根据TAPD需求单上的需求跑过一遍自测
检查文档是否对应新增的添加了功能接入说明
检查VERSION.md是否说明了所有更新内容
检查MSDK/assets/ 下面的msdkconfig.test.ini msdkconfig.debug.ini 是否正确设置。可选模块是否有开关完全关闭
检查版本号配置是否正确
检查第三方sdk的版本是否正确
保证自动化测试所有接口通过
版本通过金刚审计
按照冒烟测试测试用例完成冒烟测试
提测前代码Review重点检查项目:
发布前跑一遍FindBugs, 解决工具发现的所有BUG, 确认无需解决的BUG提示必须注释说明
检查资源文件使用方式, 必须使用反射方式调用
检查Logcat打印的内容, 避免在Log中打印关键信息
检查RDM打包版本号配置是否正确
检查避免使用硬编码值和魔法数字,如果有,必须说明 确认所有TODO标签已经完成, 没有遗漏, 确定要遗留的问题必须注释写明原因 检查相关的so是否都已经提交到SVN
推荐做法之紧急版本提测:
提测前版本相关重点检查项目:
检查文档是否对应新增的添加了功能接入说明
检查VERSION.txt是否说明了所有更新内容
检查代码中版本号配置是否正确
检查RDM打包版本号配置是否正确
保证自动化测试所有接口通过
对比TAPD需求单和BUG单, 确定是否完成所有需求以及所有BUG 已经修复
确认所有TODO标签已经完成, 没有遗漏, 确定要遗留的问题必须注释写明原因
检查相关的so是否都已经提交到SVN
按照冒烟测试测试用例完成冒烟测试
紧急版本一般都是bug修复,也不会有功能更新,也不会大的修改,因此只是把一些容易忽视的地方确认一次就可以了。
增加几点说明吧:
由于版本会有提测版本,回归版本或者紧急版本,因此我们对不同的版本也会有不同的ckecklist
checkList是我们为了提高版本质量而增加的,因此我们都会仔细核对,而不该是走个过场。
我们也会根据实际情况和测试协商对checkList做一些调整(这个list也是测试和我们根据经验具体总结的)
接下来我会对新版本提测的list做一个介绍:
上面啰啰嗦嗦说了一下我们目前版本提测的一些流程和提高版本质量的一些方法。下面就探讨一些没那么复杂(不过也挺复杂)的问题了。首先探讨一下开发和测试的关系。
可以明确开发和测试不应该是敌对关系,两者的共同目标都是为了出一个高质量的版本。
因此开发不要觉得测试追债一样,这个最重要。我们的测试有时候也会抓住一些小结不放,有时候也很不爽,但是很多时候还是有据可循,可以定位并说清楚的。
另外对于某些新功能模块,开发可以提供一些开发的设计思路给测试,协助测试完成测试用例的设计。
如果有遗漏,也不要沾沾自喜,还是要据实以告,否则万一漏了某个分支就是大问题。
这里主要是列举一些我们目前使用到的测试方法:
这里主要是指基于接口的测试,包括合法、非法参数、边界值的测试,这部分内容是确定的,因此我们都通过自动化测试实现。还有一个是版本代码比对。
我们的测试会比对当前版本与上个版本代码的差异(当然有些是看不懂的,但是不影响理解整个流程)。其实让测试看代码我觉得是一件很好的事情,如果遇到有些紧急版本,一对比代码就知道是怎么改的,一眼胜千言。
黑盒主要是指demo,我们会为游戏提供一套我们的接口调用的demo(我会在SDK开发经验之Demo和文档(点击查看)中描述demo的价值)。测试可以通过demo验证一些具体的功能表现,目前我们通用的功能的基于UI的测试也都已经是通过自动化测试。
不用多说,Android的兼容性和web前端的兼容性没啥区别。
这个最好有,尤其是作为SDK,游戏经常来问的最多的就是你们的包多大,加了以后对性能(CPU和内存)的占用量是多少等。这些有了才更专业啊。