SDK开发经验之测试

本来计划测试作为版本的一个内容来说，结果发现版本废话有点多，太长了；而且测试要点也挺多的就还是分开了。在这里主要介绍一些与测试相关的内容。

关于提测流程

在关于版本的总结中，已经说了对于一个版本提测，要有一个专门的提测流程。对于一些重点项还该有具体的说明（结合自身实际制定了一个提测前的版本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修复，也不会有功能更新，也不会大的修改，因此只是把一些容易忽视的地方确认一次就可以了。

增加几点说明吧：

1. 由于版本会有提测版本，回归版本或者紧急版本，因此我们对不同的版本也会有不同的ckecklist
2. checkList是我们为了提高版本质量而增加的，因此我们都会仔细核对，而不该是走个过场。
3. 我们也会根据实际情况和测试协商对checkList做一些调整（这个list也是测试和我们根据经验具体总结的）

接下来我会对新版本提测的list做一个介绍：

提测前版本相关重点检查项目:

• 对比TAPD需求单和BUG单, 确定是否完成所有需求以及所有BUG修复。 TAPD是内部一个管理需求和bug的系统，这里也就是说确认下这个版本计划的内容是否都已经完成。并根据实际修改需求或者bug单的状态。
• 自己根据TAPD需求单上的需求跑过一遍自测 第一步是确认所有的需求是否已经处理，而这里就是验证功能是否符合需求。这里我们会把一开始流程中提到的第三步在这里完成。边验证功能，边整理提供给测试的测试方法。一般这一步由对应模块的开发整理，然后汇总给版本负责人。
• 检查文档是否对应新增的添加了功能接入说明 我们的文档使用wiki，而且我们一般会再版本提测时提前告知新版本的内容，方便游戏提前了解。以前我们出现过版本发了，但是有一个模块的文档一直忘了写上去，那时候还不是wiki，文档是在版本包，为此还不得不再走一次打包提测的流程。所以直接增加进来。
• 检查VERSION.md是否说明了所有更新内容 初衷和原因与上面的文档一致
• 检查MSDK/assets/ 下面的msdkconfig.test.ini msdkconfig.debug.ini 是否正确设置。可选模块是否有开关完全关闭 这个可以理解为对外提供的配置是否正确。我们的SDK给测试和最终发布的包的配置并不一样，所以需要确认不同环境对外发布包的推荐配置是否正确，之前也遇到过某个默认关闭的开关再配置中写为打开。结果有游戏没有留意直接拷贝过去，导致功能被打开，但是游戏并没有接口权限，导致游戏接口被告警。
• 检查版本号配置是否正确 这里主要是检查代码中的版本号是否正确，我们为了确保版本号正确，有几个保护机制。这个在关于版本号的SDK设计心得之版本号（点击查看）会重点说明。
• 检查第三方sdk的版本是否正确 由于我们的SDK还接入不少SDK，因此需要确认第三方的版本是否正确。同时也是为后面游戏来咨询做准备。
• 保证自动化测试所有接口通过 这里是我们对于所有提供给游戏使用的外部接口的一个JUnit test单元测试。只是简单的合法参数调用测试，没有详细的边界和异常测试（这部分专业测试会做）。
• 版本通过金刚审计 金刚是一个内部漏洞扫描平台，我们会把demo应用提交平台来确认代码没有漏洞，这也是对外发布的其中一环。
• 按照冒烟测试测试用例完成冒烟测试 这个是指一些通用功能的测试，为了提高版本质量，测试会要求我们先对一些通过功能的正常逻辑进行验证（目前这部分我们已经通过自动化测试实现，测得时候盯着看，然后再看一遍日志就OK）

提测版本前代码Review重点检查项目:

• 发布前跑一遍FindBugs, 解决工具发现的所有BUG, 确认无需解决的BUG提示必须注释说明 主要是为了提高版本质量，不过目前这部分用的比较少，有时候改动不是很大，版本比较着急就不会用（不过测试还是会基于jar扫描）
• 检查资源文件使用方式, 必须使用反射方式调用 这个是我们项目特有的，由于我们项目的代码框架（这个我会在SDK设计心得之目录结构和资源文件（点击查看）里面说明）的特殊性，我们的SDK代码如果调用资源，只能通过反射获取，所以我们要确认是否正确。
• 检查Logcat打印的内容, 避免在Log中打印关键信息 我们的logcat有一次直接把网络请求加密前的内容打印了……你懂的
• 检查RDM打包版本号配置是否正确 RDM是一个内部自动打包系统，我们SDK的最终版本会对比这个系统配置的版本和我们代码中的版本，通过两个版本的一致性来确保版本的正确。
• 检查避免使用硬编码值和魔法数字，如果有，必须说明 关于硬编码和魔法数字举个例子。例如代码中有个定时器，默认是半个小时执行一次。我们开发中为了测试效果可能会调整到1分钟一次。如果版本周期比较长，可能最后就忘了修改这个数，一旦版本发布以后就更麻烦了。 好吧，我还是不回避这个问题了，就举自己的案例吧。当时我们某个版本忘了因为什么，访问后台的域名不但配置文件有，代码也有，而且优先使用代码中的，悲剧就这样开始了。开发完测试的时候代码用了测试环境的域名，功能正常。提测以后测试配置了测试环境的域名功能正常，也没发现，然后正好那个版本比较着急用就没灰度。发布后第三天好几个游戏来问，无论怎么配置都是测试环境……瞬间噶屁了。修改很简单，但是因为没有灰度，已经有比较多游戏在更新了，只能一个个去通知更换，然后被屌犯这么脑残的错误。 这个被坑过几次，感触颇深，不过这个可以配合todo标签来避免。
• 确认所有TODO标签已经完成, 没有遗漏, 确定要遗留的问题必须注释写明原因 关于TODO我会在SDK那些事之SDK开发中的一些开发经验（点击查看）专门说，一定要看，是干货。TODO标签的合理使用可以有效的解决很多问题。
• 检查相关的so是否都已经提交到SVN so文件在win下（mac默认ignore好像也有）坑爹的SVN不会提交，有一次忘了就给漏了！！给漏了！！！漏了！！！

关于开发和测试的关系

上面啰啰嗦嗦说了一下我们目前版本提测的一些流程和提高版本质量的一些方法。下面就探讨一些没那么复杂（不过也挺复杂）的问题了。首先探讨一下开发和测试的关系。

可以明确开发和测试不应该是敌对关系，两者的共同目标都是为了出一个高质量的版本。因此开发不要觉得测试追债一样，这个最重要。我们的测试有时候也会抓住一些小结不放，有时候也很不爽，但是很多时候还是有据可循，可以定位并说清楚的。

另外对于某些新功能模块，开发可以提供一些开发的设计思路给测试，协助测试完成测试用例的设计。如果有遗漏，也不要沾沾自喜，还是要据实以告，否则万一漏了某个分支就是大问题。

版本应该怎么测试

这里主要是列举一些我们目前使用到的测试方法：

白盒

这里主要是指基于接口的测试，包括合法、非法参数、边界值的测试，这部分内容是确定的，因此我们都通过自动化测试实现。还有一个是版本代码比对。我们的测试会比对当前版本与上个版本代码的差异（当然有些是看不懂的，但是不影响理解整个流程）。其实让测试看代码我觉得是一件很好的事情，如果遇到有些紧急版本，一对比代码就知道是怎么改的，一眼胜千言。

黑盒

黑盒主要是指demo，我们会为游戏提供一套我们的接口调用的demo（我会在SDK开发经验之Demo和文档（点击查看）中描述demo的价值）。测试可以通过demo验证一些具体的功能表现，目前我们通用的功能的基于UI的测试也都已经是通过自动化测试。

兼容性

不用多说，Android的兼容性和web前端的兼容性没啥区别。

性能测试

这个最好有，尤其是作为SDK，游戏经常来问的最多的就是你们的包多大，加了以后对性能（CPU和内存）的占用量是多少等。这些有了才更专业啊。