目前本人负责测试一款Flash游戏—挖金矿，虽然此游戏在互联网上已经很流行，并且功能点相对于网络游戏而言不算很大，但通过执行测试直到项目结束测试，发现了很多对功能测试没有深刻认识的地方，现对这些问题进行总结，希望能通过此篇心得来跟大家进行沟通交流：
n 从需求设计开始测试
以前由于未深刻认识测试的整个流程，很理所当然地认为测试人员扮演重要角色的阶段是在开发人员提交测试版本的时候，但通过挖金矿的测试，发现测试人员其实在项目的需求分析阶段，就要根据自己的经验和分析对需求进行严格的审查。
测试人员需要很认真地对待需求讨论，因为需求是整个项目的出发点，如果源头上出现问题的话，后续的设计、开发、测试也会相应地出现偏离。并且这种错误很难去发掘，往往在功能基本已经完成或者项目已经上线之后才能体现出来，因此测试人员在评审需求说明书的时候，就要开始细心地发现不足与需求缺陷，通过挖金矿的需求评审，本人总结的经验主要有：
1) 首先需要对项目的功能、游戏道具、道具效果如何叠加、游戏角色、项目性能资源指标进行具体的检查分析；
2) 在需求当中如果涉及到数据，就需要仔细检查是否写明了数据的格式、取值范围；
3) 如果功能之间有关联的话，要考虑到其中一个功能内容的修改会导致其关联功能哪些内容的相应变更，这样在编写测试用例的时候才能考虑全面；
4) 在进行需求评审时，多多考虑一些特殊场景，特别是游戏道具，比如买了强力药剂，则下一关的抓取速度会提高，但如果在游戏过程中抓取运气袋的时候，也随即到了强力药剂的时候，此时是应该出现叠加效果，使得抓取速度更快，还是应该给予玩家其他奖励；
5) 需求说明书中对于用户操作需要说明其业务流以及响应时间，整个项目的CPU占用、内存消耗等性能指标也需要说明，游戏的日志需要记录这些数值，便于测试人员在测试过程中进行检验。
n 测试过程中细化思路
在执行测试过程中，经常维护自己的测试用例也比较重要，因为在未进行测试时所编写的测试用例比较抽象，与开发人员的认识也存在差异，往往接触到测试版本之后，才会对项目有直观的认识，发现之前编写的测试用例考虑不够全面的地方。
以这次挖金矿的测试来说，在中间的关卡中出现了游戏时间有所变快的bug，但自己在之前编写的用例中未完全考虑此种情况，只是主要到时间的数值是否符合需求的每个关卡120秒的要求，因此在涉及到时间的测试时，不但需要注意范围，也要注意其节奏是否正确，同时未考虑细致的地方，通过测试用例的补充，在测试后期总结时期，也便于让自己的测试思路变得更加缜密。
n 测试需要考虑用户体验
测试人员在进行测试时，不能完全止步于发现需求考虑不完善、功能缺陷、性能未达标的bug，测试的目的除了发现项目的缺陷之外，还需要对项目的整体质量情况进行评估。因此测试过程中还要注意到项目的用户体验、操作简便性方面的问题。
还是以自己挖金矿的测试体验来做反面教材，在测试的后期组织其他客服人员进行体验，在收集的反馈意见中，对于甩出钩子的时延、说明文字的理解歧义问题比较多，说明当用户在操作游戏过程中，往往操作响应、界面展现是最关注的，说明测试人员在进行测试时，也需要关注此方面可能隐藏的问题。
由于体验方面的问题属于比较主观的，在不同人眼中也会有产生争议的观点，但作为测试人员，对于此类问题也需要进行记录，建议放在组内或测试部中进行讨论，当问题达成共识的时候，可以由小组负责人进行汇总反映，通过这些问题的认识，帮助项目更贴近用户，也使得自己测试的视角更加广阔。
n 理解版本配置管理
版本配置管理也属于测试部的工作内容，虽然配置管理不是由我负责，但通过别人的指导了解之后，也认识到管理好版本也是测试过程中的重要环节。版本配置管理其目的是为了防止版本出现混乱，同时也方便人员对版本的质量情况进行跟踪分析，我们公司的版本按照项目来进行划分，并且每个项目分为代码库和文档库两大类：
代码库
主要分为开发库、基线库、产品库。其中开发库供开发人员提交代码、基线库供测试人员获取测试版本、产品库为现网版本的整理，整个代码库的管理过程如下：
文档库
| 欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) | Powered by Discuz! X3.2 |