测试流程

耗子砍猫

我们是这样的:
审核需求和设计(测试计划编写与潜在风险评估和风险规避办法)—〉设计测试(测试用例设计)—〉实施运行测试(维护测试用例和写测试报告)
审核需求包括：
（1）由PM根据用户要求（信息来源于市场部门，用户支持部门、游戏设计部门、美术部门、程序部门等等）而编写的需求文本（Requirement   Specification）和测试计划；
（2）由Team Leader根据需求文本和开发团队(游戏设计、美术、程序)提供的游戏设计文本(Design Doc)编写（Functional Design  Specification）,定义测试重点和用例的编写重点；
（3）由Test CaseOwner根据功能文本而编写测试用例实施设计文本（Implementation Design  Specification）并完成测试用例设计,一般设计两套用例;一套只检查基本功能,另一套检查内容详细,从端到端,点到点都不放过,极其苛刻,尽可能做到最大覆盖。

对这些文件的管理与调配,TL完成功能设计文本,通过邮件发送给PM,并抄送手下组员,目的让大家了解这个Mliestone测试重点和相关测试功能模块PM对功能设计文本进行审核,并与设计团队和开发团队一起会审,评审所写的所有Case。发现问题或者有不清楚的地方,进行Review动作。一般一个用例从设计到最后被确定使用,会经过2~4次Review。

测试人员也要参与所有这些文本的审核,主要是与开发沟通,和成员内部进行交叉评审。作为测试人员，审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动。

2、当确定下测试用例后,定义优先级,用例的分配(分配到测试小组),由每个组的TL放入专门服务器,PM设置访问权限和修改权限,由PM统一管理,测试开始时会依据测试进度分发Case。

Mliestone开始之前,会召集所有测试人员进行战前部署,告诉大家这次测试的功能模块,自动化的测试、性能都会涉及。让每一个测试人员清晰了解测试的功能模块有哪些,需要注意什么,等等。

3、实施运行测试是最长最复杂的一个阶段。就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试脚本、反复运行自动化测试脚本，也包括阶段性执行手动测试用例。在Mliestone中,自动化测试和性能测试与手动测试同时进行,自动化测试这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，就是为了防止质量回归。

另外,非自动化的测试用例要进行维护,非常烦琐的工作,比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug（比如从客户报告来的,客户也会参与我们的测试），没有被现有测试用例所覆盖。当产品的功能设计出现更改时，所涉及的测试用例当然也要相应地修改。

我们还有一种特殊的方法,就是每个Milestone的末期,测试的任务已经完成95%,会组织一次大的Bug大扫除工作,所有的测试人员(包括测试管理人员),开发团队,甚至BOSS,都会参与其中,不使用任何用例,完全凭个人自由发挥,看谁找的BUG多对于发现严重BUG最多和严重等级的人给予奖励,这种大扫除一般持续2~3天,这种大扫除应该是对里程碑测试的补测,,这种大扫除测试是交叉测试的,每个人测试自己没测试过的功能模块,就是为了发挥主观能动性和集思广益。。

里程碑测试的同时,开发会查看我们上报的BUG,并开始修复,一般在里程碑测试完毕后,会出一个Build,告诉哪些修复了,我们会进行回归测试,对于一个里程碑里发现的所有BUG,不会在里程碑彻底结束前还保留,也就是说里程碑彻底结束后,我们在Milestone里的BUG都应该是修复状态,对于没修复的,有设计变动的,或者是有争议的,会进行3方会审,参与的人员有PM (PM和开发一起)、测试经理和测试人员、我们的客户也参与;审核这个BUG:1、是否接受?2、BUG的严重等级和优先级?3、处理意见和建议,以及交由哪个开发人,处理方式的建议等等。

当Milestone结束后,我们会对此次Milestone测试的过程中不完善的地方,已经做好的地方进行评估,让每个测试人员说自己在期间的感受和看到不足的地方,并加以筛选和改进,对于一些好的测试方法和技巧,会写成文档,记录进入知识库。

我们是游戏公司,其他游戏公司测试的流程不知道和我们是不是接近,有做游戏测试的吗,欢迎来讨论指教?

[ 本帖最后由 耗子砍猫 于 2008-10-15 21:08 编辑 ]