|
1、审核需求和设计—〉设计测试—〉实施运行测试
审核需求包括:
(1)由PM根据用户要求(信息来源于市场部门,用户支持部门、游戏设计部门、美术部门、程序部门等等)而编写的需求文本(Requirement Specification);
(2)由Team Leader根据需求文本和开发团队(游戏设计、美术、程序)而编写的功能设计文本(Functional Design Specification);
(3)由Test CaseOwner根据功能文本而编写的实施设计文本(Implementation Design Specification)
(4) 由Test CaseOwner完成测试用例设计,一般设计两套用例;一套只检查基本功能,另一套检查内容详细,从端到端,点到点都不放过,极其苛刻,尽可能做到最大覆盖。
对这些文件的管理与调配,TL完成功能设计文本,通过邮件发送给PM,并抄送手下组员,目的让大家了解这个Mliestone测试重点和相关测试功能模块M对功能设计文本进行审核,并与设计团队和开发团队一起会审,评审所写的所有Case。发现问题或者有不清楚的地方,进行Review动作。一般一个用例从设计到最后被确定使用,会经过2~4次Review。
测试人员也要参与所有这些文本的审核,主要是与开发沟通,和成员内部进行交叉评审。作为测试人员,审核重点是检查文本对用户需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动。
2、当确定下测试用例后,定义优先级,用例的分配(分配到测试小组),由每个组的TL放入专门服务器,PM设置访问权限和修改权限,由PM统一管理,测试开始时会依据测试进度分发Case。
Mliestone开始之前,会召集所有测试人员进行战前部署,告诉大家这次测试的功能模块,自动化的测试、性能都会涉及。让每一个测试人员清晰了解测试的功能模块有哪些,需要注意什么,等等。
3、实施运行测试是最长最复杂的一个阶段。就是将上一步设计的测试用例按计划付诸实施的过程。这包括编写自动化测试脚本、反复运行自动化测试脚本,也包括阶段性执行手动测试用例。在Mliestone中,自动化测试和性能测试与手动测试同时进行,自动化测试这里有一点要特别指出,有很多测试用例是要反复运行的,特别是基本的自动化测试每一天,每一个Build上都要运行。尽管这些测试大多数情况下都是通过的,很少再发现新的Bug,就是为了防止质量回归。
另外,非自动化的测试用例要进行维护,非常烦琐的工作,比如通常以下两种情况下要新增一些测试用例,一是对于当初测试设计不周全的领域,二是对于外部的Bug(比如从Beta客户报告来的),没有被现有测试用例所覆盖。当产品的功能设计出现更改时,所涉及的测试用例当然也要相应地修改。
我们是游戏公司的测试,希望各位讨论下这种方法的利弊。 |
|