成为测试主管第一步--制作测试流程(2)

　　服务器的稳定性，网络流量，与安全是游戏最至关重要的，(往往有很多游戏不是不好玩，而是太不稳定);

　　游戏由于有及时的即时更新，会经常在同时修改缺陷的时候，还在同一模块下增加新功能;

　　好的网络游戏开发，其的功能必然会是迎合玩家的需求(游戏性分析)。;

　　对于游戏软件产品来说，这些需要特别注意重点控制的点关键，要求测试团队必需要加强以下几个方面，性能测试，代码的融合、相关性影响面的判断、版本的变更与控制，还有游戏性的分析与测试。性能测试主要加强以下几点，则需要注意在并发下服务器的稳定性监控，、网络流量与游戏客户端在大场面下的表现。;而版本控制在游戏软件的过程中，其意义更多——则会避免已经改了的问题重复出现，或是改了更新上去问题还是存在，如何高效的合并代码，、合成游戏资源、图片与角本脚本还是一个比较难度很高的事情，尤其涉及到多个部门。;而游戏性测试主要是避免那种些与游戏风格相背的情况，或是开发团队累死累活拼命完成得功能性任务做出的功能没有可延续性。

　　性能测试与版本控制，在大多数软件的测试流程中都会涉及，但是在不同的软件产品/项目中都有其特点。一般属于通用软件测试流程的部分，但而游戏性测试则需要对游戏感觉很好有比较深刻的了解，并由真正懂懂得的玩家的人来担任，。某些时候，他甚至可以不是一个很好的软件测试人员，但他一定是一个真正懂游戏的人，这里有一些扯远，但这里，本文稍后一节，将我会在后面会强调人的因素也决定了流程的实施。

　　下图是游戏迭代开发模型图

　　如果你去做电子商务，或是做门户，这些项目的适时性，高性能，复杂的功能会给你更高的技术要求，更高强的时间性效率挑战，对测试的设计，、执行，、与性能测试提出更高的要求。其实在大多数互联网公司经常会出现这样的情况：刚出去的功能又撤下来修改，或是性能达不到要求仍需要又要调优。许多一些人都会犯这样一个错，认为测试的时间不够，就只要测试执行，而忽略了其他几个环节就可以了，不做细致的分析与设计，为后续工作带来很大压力。其实，一个充分测试过的有质量保证的产品，可以减轻客服，、市场，、等各方面很多的压力。产品在用户和研发之间，反复，几次不如晚一些上提供给用户。从另外一方面看，这还需要测试主管能顶住某些压力。时间紧迫当然这不是理由，如何在流程上保证测试的需求分析，、用例的设计与研发在开发时同步进行是最重要的，这时你要加强早期的测试介入，明确卡住需求确认这一部分，。这样，在研发进入开发阶段时，测试团队也能进入测试设计，。当研发开发完成时，你测试团队事实上已经其本基本上完成了大部分的测试设计，并准备进入测试执行，。不要在开发提交后再去想如何测测试，抱怨之声也就不绝于耳了。这样才可能测试好一个时间比较紧的项目不管在用于测试的时间上，还是测试的质量上都无法满足要求。

　　，同时测试设计的很好，不仅可以节约测试执行的时间，也可以在反复提交的过程中，由于用例执行的一致性，保证了测试在多次的执行中的质量，;。同时也有发布的标准，一是缺陷的情况，二是用例的执行与覆盖。同时由于研发给的测试时间比较紧，所以有两件事情就必需作做好，：一是明确产品提交测试时间，并在研发延迟时给自己争取时间;二是在质量达不到要求的情况下，时间及时的做出反应，不要到最后在研发不了解项目质量的情况下建议研发延迟项目。为了达到上面的要求你必需要一个很好的测试平台，把设计，测试用例管理，执行与用例的联动，缺陷管理与报表统计打通，尽可能的利用平台解决事务性工作，降低流程执行的成本，。也就是说，既让测试人员可以集中精力去测试，同时又能够让研发管理人员随时获取正在进行测试的进度与质量，。当这些工作做到透明化时以后，就算让研发延迟发布，研发部门也会接收接受，。下图是这一阶段的大致流程

　　在这里可以跟大家说一下，我就曾经在产品发布权限不在测试这里部门的情况下，成功的让研发决定推迟发布了大约一半以上的项目,。大多数的测试部门主管，很难顶住来自项目/技术经理的压力是有理由的，因为他们根本不了解你做了哪些工作。有时候一些情况下，看似不可能的事情任务要想做成完成，关键要看在于事情的技巧，。流程表示了只是一个大方向的东西，而且，你永远也无法将责任推卸给流程也许是对的，更多情况下，作为测试主管，需要但将做事的方法与风格可以影响到推广到测试流程的推广中。

　　在测试互联网项目时，还有一个更重要的就是如何保证性能，。

　　也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测试主管，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么办，?其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与评审,，从而避免大部分性能问题。

　　上面分析了不同公司根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团队与研发团队，则仍需要精心的调整，。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。

　　这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试，。好像在我的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励鼓励是比职责更加有效的工作方式。这可能是一个放之四海皆准的工作态度。，指责只能加深对立，。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核了解，可能大多数情况下是：原则上没有问题就通过了，。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚，。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为认为无法做工作无法继续下去。，等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。

原文转自：http://www.ltesting.net