本来计划测试作为版本的一个内容来说，结果发现版本废话有点多，太长了；而且测试要点也挺多的就还是分开了。在这里主要介绍一些与测试相关的内容。
在关于版本的总结中，已经说了让版本提测有一个标准化的提测流程，只有流程化了才能减少出错的机会，提高版本质量，降低开发和测试的工作量。
当然，对于我们来说，这个相对比较简单，内部有专门的系统去管理版本的提测，因此就已经有了一定的流程。我们的重点就变成了一些重点项的检查。目前的提测流程主要包括三部：
接下来我会把上面四个流程中比较重要的环节再介绍一下：
早期，我们这一步几乎没有，这一步主要就是本地先验证下ant打包是不是正确，而具体的新功能自测和验证是放在checkList里面。后来我们做了一些基于UI的自动化测试，然后我们就把基础功能的自动化测试和mokeny性能测试提前到这里。所有工作通过一个脚本完成。下面就是某个SDK的出包验证和自动化测试的一个批处理程序。里面通过ant生成最终版本包，然后配合自动化测试完成一些版本正式提测前的基本功能验证。
之所以制定版本发布的checkList，就是因为经常会因为一些很小的问题而影响版本的质量。毕竟每次提交测试前需要确认的问题很多，例如功能验证、开发过程中一些临时增加的一些断点、为了配合开发做的一些调整等等。一个有效的checkList可以协助我们梳理所有容易犯低级错误的地方。这里就列举一下我们的checkList并做一个简单的说明。先列举一个完整的：
增加几点说明吧：
接下来我会对新版本提测的list做一个介绍：
提测前版本相关重点检查项目:
提测版本前代码Review重点检查项目:
上面啰啰嗦嗦说了一下我们目前版本提测的一些流程和提高版本质量的一些方法。下面就探讨一些没那么复杂（不过也挺复杂）的问题了。首先探讨一下开发和测试的关系。
因此开发不要觉得测试追债一样，这个最重要。我们的测试有时候也会抓住一些小结不放，有时候也很不爽，但是很多时候还是有据可循，可以定位并说清楚的。
另外如果有遗漏，也不要沾沾自喜，还是要据实以告，否则万一漏了某个分支就是大问题。
这里主要是列举一些我们目前使用到的测试方法：
白盒
这里主要是指我们的测试会比对当前版本与上个版本代码的差异（当然有些是看不懂的，但是不影响理解整个流程）。其实让测试看代码我觉得是一件很好的事情，如果遇到有些紧急版本，一对比代码就知道是怎么改的，一眼胜千言。
黑盒
黑盒主要是指demo，我们会为游戏提供一套我们的接口调用的demo（我会在SDK开发经验之Demo和文档（点击查看）中描述demo的价值）。测试可以通过demo验证一些具体的功能表现，目前我们通用的功能的基于UI的测试也都已经是通过自动化测试。
兼容性
不用多说，Android的兼容性和web前端的兼容性没啥区别。
性能测试
这个最好有，尤其是作为SDK，游戏经常来问的最多的就是你们的包多大，加了以后对性能（CPU和内存）的占用量是多少等。这些有了才更专业啊。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/185352.html