游戏测试的疑问及建议

游戏测试过程中遇到的问题

一、              策划文档修改不及时[lidq1] （我觉得策划变更若不已书面形式存档，会出现策划修改遗漏，修改前后不一致的情况

二、              编程人员没有认真研究策划文档，导致某些功能点的实现与策划文档不符合，由这个原因出现的bug是完全可以避免的

三、              新版本提交延迟[lidq2] ，导致测试人员等待时间过长，后续所留测试时间紧缩，这也是测试加班的主要原因o(∩_∩)o…（WY提出的解决方案就是：我们测试人员在实际中跟踪版本变化，参加组内会议，了解游戏进度，协助程序员调试，这个建议非常好）

四、              提交的新版本与策划给出的测试需求文档有不符合的地方，测试需求覆盖功能点>=提交版本实际完成功能点[lidq3] 

五、              还希望编程人员提交的版本[lidq4] 要保证基本流程的正常运行（编程人员若没有时间做单元测试，至少要把游戏流程跑一遍）

六、              测试人员提交的bug得不到即使[lidq5] 修改，这很考验测试人员与编程人员的沟通能力

七、              说了这么多策划、程序员的问题，其实作为测试人员我也有很多问题，问题如下：

1）                            测试思想的问题，测试思维局限，行业知识不扎实，对所侧对象不够了解（这个需要与策划的良好沟通），测试设计不能尽可能地覆盖所测对象，由于目前从事的是黑盒测试，本人觉得黑盒测试更强调测试设计[lidq6] ，能把所学的测试技术运用到设计中才是王道）

2）                            与编程人员的沟通问题，如何友好有效地说服编程人员保证进度及时修改bug是个永远值得学习的情商问题

---

 [lidq1]这个问题仍然很严重，发现整个公司的文档管理流程十分不规范（游戏没有详细设计文档，软件工程化管理方式难道只适合大型开发吗？）

 [lidq2]仍旧是进度控制的问题，这让我意识到测试管理远远重于且难于测试技术，本人的职业发展可以走管理路线（感觉我们公司，tester和QA的是两位一体的）

 [lidq3]测试需求邮件是测试人员制定测试计划，实施测试的依据，邮件的详细程度与准确程度是必须规范的，测试需求邮件功能点不完整，描述不清的地方，必须要求更改（感觉测试在整个团队的态度过于妥协，必须坚守原则）

 [lidq4]违反版本可测试标准的，坚决拒测

 [lidq5]邮件描述版本动态，抄送game_leader，当然用于要做到客观，不可人生攻击

 [lidq6]游戏架构了解，黑盒也不能黑得太过侧地；从过往bug中学习，积累经验

一个好的游戏团队所必备的

（仅仅是个菜鸟的建议，说的不对的地方，请给予严肃批评）

1）  PM（[lidq1] 控制整个项目的人）； 项目进度控制相当重要，若能使整个团队按进度严格执行，项目质量才能得到保证

2）  策划 [lidq2] ；按我一个月的工作观察，策划好像负责了整个游戏开发的进度，策划若不对自己的策划文档负责，如文档描述细致，更新及时，切莫口头不一致，后续出现的问题会减少很多，效率也会提高很多

3）  编程和美工[lidq3] ；我知道这两个岗位的工作相当繁忙，会劳累，劳累时有负面情绪是很正常的事，应该谅解，但是在开发工作初始阶段就能对策划文档完全熟悉，与策划人员及时沟通，也不会有后来的引文与策划文档不符合，反复修改程序；同时希望bug修改不遗留到下个版本，因为bug是具有传染性的，前面的毛病会传染后续所实现的功能点，要知道80%的bug都出现在前期，越早修改，产品质量越能得到保证

4）  测试人员[lidq4] ；测试人员处于项目开发的底层，在很多公司处于不被重视的地位，同时测试人员以“找茬者”出现，身份尴尬，需要在沟通上下很大功夫。以上两点都是外在因素，按马哲所说，内因决定外因，所以测试人员提高自身素质是最重要的。

        以下几点是我作为测试新人的感触和吸取的教训

（1）       作为测试人员首先要明白自己的工作职责，时刻记住，测试的最终目的是保证产品质量，不是找茬（本人觉得高度的责任心在生活中各个方面都是必须的，是保证社会团结稳定的基石，不好意思，扯远了）

（2）       与人沟通方面[lidq5] ，我不是个活跃分子，与人相处也是慢热型的，性格使然，对工作进展有阻碍作用，要我突然改变性格也是不可能的，我目前能做到的是有责任心，能站在他人角度考虑问题，做到宽容和严格的平衡，在坚持原则的基础上，主动帮组编程人员发现错误、定位错误。

（3）       测试技术方面[lidq6] ；在工作初期我认为测试技术是最重要的（请原谅我是个学院派），因此杂七杂八的看了些相关测试技术，（我觉得洪波说的很对，我学的杂，很浪费精力，而且所学知识也不扎实，要克服浮躁的心态，一步一个脚印的扎实学习，重质甚于重量），现在我觉得测试思想排在第一，测试经验第二，而测试技术只能排在第三。当然不是说测试技术不重要，最为测试人员，测试的基础是必须扎实的（作为黑盒测试人员，黑盒测试用例设计费那个方法不熟悉就如花样游泳运动员不会水一样），行业知识必须扎实，测试用例设计的评价标准之一就是测试覆盖度，对所测系统不了解，又如何尽可能的覆盖周全呢？

（4）       对某一版本的测[lidq7] 试必须彻底，这次由于连连看alpha 1 的积分功能未测，导致积分功能点bug修复不在close beta 计划中，从而影响了开发、测试进度，这个教训一定要吸取。

---

 [lidq1]期待TJ加入对版本进度控制的改善

 [lidq2]游戏开发过程中，需求变更是难免的（软件工程中需求变更管理是很重要的，有一套严格的管理流程，是项目管理的重要组成部分，是pm做的事，在没有pm的情况下，只能口头交代，提醒策划把变更用不同颜色在策划文档中标记出来）

 [lidq3]与测试组外同事之间的协作能力很重要，完善合适的流程控制，标准制定是保证沟通的良好保障，在没有这些保障的情况下，需要个人倾注更多的精力在沟通上

 [lidq4]测试工作不受重视，推测原因有二：一是测试工作不是创造型，生产型的工作，在一个处于发展中流程制度有待改善的地方，又急于看到谋利效果的地方，不受关注可以理解。二是测试小组本身没有做出可以让大家能看到的效果，技术含量低的工作被人看低也是情有可原的。

 [lidq5]希望pm的加入让测试工作更多的投入在如何高效的修改bug，而不是催促修改bug

 [lidq6]行业知识有待加强，若能了解游戏开发的知识会不会对bug定位有帮助？

 [lidq7]重复工作让人新生倦怠，要克服这点

我的建议：文档完善

我觉得保证测试有效性，测试管理工作是重点，以我的理解包括以下几个方面的管理：

（1）       测试进度控制（测试计划文档）

（2）       测试用例设计（用例设计报告）

（3）       Bug管理（bug提交、修改、回归、确认）

（4）       测试结果分析（测试报告文档）

说了这么多，其实保证团队质量的关键是人的因素，对人的管理若能有效，必须保证规范性，规范性即制度化，而制度化考察的依据是文档。所以我觉得文档至关重要。

我觉得文档的版本管理，有以下两点：

1）              版本一致性； 最起码要保证文档统一性，像目前文档存放地方一个是vss，一个是onenote，到底以哪个为准？

2）              版本更新； 版本变更必须及时出现在文档上，我建议策划人员能将变更点单独列出，这比阅读人员全篇通读效率要高的多。（我遇到过那种全篇变动就一句话的文档，从二三十页中找出一句不同处，这是很浪费时间的），除了单独列出变更点，最好能给组内成员发送更新通知邮件，由于工作繁忙没有及时看到更新的可能性很大。

以下针对不同文档的具体建议[lidq1] ：

1）  策划文档：对这个的要求我在前面已经提过，就不累述了；

2）  开发文档：虽然我没有大项目的开发经验但也明白对开发人员，项目的设计是至关重要的，好的设计决定一切，设计文档对整个开发过程起着纲领的作用，一些较大的项目就有概要设计文档、详细设计文档、数据库设计文档等等；对于小型游戏这种迭代式的快速开发模式，没有必要如此细分（也没有时间细分），但是提交一份模块调用流程和算法设计文档是必须的，游戏算法的测试是游戏功能点的测试基石，从算法本身找毛病，比单纯的重复操作来发现小概率问题要有效（对于这一点，温毅提出他的看法，他觉得这样做有两个弊端：第一：了解设计思路会封闭自己的测试思路，忽略很多反面问题；第二，游戏bug的不规律性是不能避免的，需要经验的积累）

3）  进度计划文档：开发、美工、测试三方面的进展进度最好细化到以小时为单位，功能点、资源列表也最好做到尽可能细化。

4）  测试用例设计文档：目前几款游戏测试都是需要多人联机测试，有时候本组人手不够，需要借调其他人员，而其他人员不可能完全熟悉所测对象，有一份针对该版本游戏测试需求的测试步骤文档会比较好。

---

 [lidq1]回过头，看这些建议，觉得很是挫败，工作流程的规范问题，不是测试能左右的事情。测试工作更多的是验证是否符合规范，而不是制定规范。