测试流程规范.docx

测试流程规范

立项

项目组通过讨论，会根据策划所写的策划书进行立项。（立项包括功能模块或者新项目）一般需要整个项目组开会决定，如果符合开发要求就会开发。

编写测试用例

当项目立项后，我们就必须更具SVN上面的策划书对相应的模块编写测试用例。（测试用例的相关标准我们会在其他文档中给出。）编写好测试用例后需要上传到SVN上面相应的测试文件夹内。（tips：SVN功能会在其他文档中介绍）如果后期的策划书由于各种愿意需要改动的话，我们也需要改动相应的测试用例，但是不能删除测试用例中以前有的用例，只能用颜色标注相关的东西

测试

功能性测试

当前期开发工作完成后，我们要对demo进行功能测试，测试的依据就是我们前期编写的测试用例，当我们执行完测试用例后，就会发现很多问题，这个时候我们争取对没个问题进行重现，然后在提交到bug系统中。

非正常测试

当程序能实现基本功能后，我们可以根据自己的习惯或者方法，进行一些非正常操作行为测试，这样可以发现一些可能存在的问题。但是是正常操作下不能重现的。（一般这种问题不容易重新，或者比较难出现，因此切忌，一定要描述清楚）

兼容性测试

当我们通过上面的测试后，在功能上我们就差不多可以实现了。这个时候我们就必须通过各种浏览器进行兼容性测试，各个浏览器可能出现的问题不同，这个时候就要总结出规律，把一类的问题统一提交，避免相关的问题重复提出。

安全测试

如果游戏中出现一些安全漏洞，我们需要用一些外挂或者脚本的东西进行测试。并且对相关的一些接口测试，一些升级或者其他用在本地服上面测试的接口绝对不能出现在外面的生产服上面。避免由于安全方面产生的损失。

回归测试

当程序或者策划那边回复了我们的bug，反馈到我们测试这边的时候，我们就需要对相应的bug进行回归测试。如果发现问题解决了就可以通过相关的负责Closed掉这些问题，如果发现还存在bug的话就需要Reopened。后面继续进行开发。

压力测试

后期我们会根据相关工具对游戏进行压力测试，这样就可以对服务器所能承受的压力有一个了解，看看是否需要在服务器这边做一些操作。

游戏评估

一个版本或者一个功能开发完成后，我们要根据相关的bug以及其他的信息来对这个版本或者功能进行评估，总结相关的开发经验，以及我们这边相关测试的问题，整理相关的文档，对以后开发做一个存档备份。

文档后期整理

前期我们写的文档可能会在后期由于各种问题需要更改的，我们都应该做好记录，对相应的文档更改，以后可以回过头来查看相应的文档，如果碰到类似的问题也就可以解决了。