1、以独立模块为索引

　　2、以操作流程为索引。

　　其各种利弊在MM图上标明，不多言。其实我认为测试用例设计的初衷是为了帮助查找更广更深入的问题。一味的追求格式的统一有方便部门整体工作的优势，但强调过头即也不值当。只要我们遵循几点：

　　1、实操人员看的懂，看的省事。提出补充可方便更新且不打乱主题结构。

　　2、编写人员要互相更换不同类型模块，并互相审核。

　　3、格式应根据测试模块可作细微调整。

　　4、有独立突出地方存放特殊用例即只有在具体测试过程中才能发现和能发现价值bug的用例。

　　5、用例的从诞生到后确认过程，应跟随项目的变化，策划案的变化，周遭其他因素的变化而变化，从理念上排除尽早确定已做好测试准备的想法。实际情况中，用例和策划案确定一样，是相对而非。所以至少应经过5轮真正意义上的修改包括审核。

　　游戏白盒测试

　　相关游戏的白盒测试。多体现在项目研发初期游戏架构和逻辑模块开发阶段。对于此类测试工作没必要退避三舍，不必有非有程序能力才可做的想法。当然在实操过程中积极的学习是很关键的，这个比在大学里学到的更实用和快速。一些白盒测试工具我认为实际应用价值不是很大。所以从架构而言我们可以关注游戏各组件的协同工作关系，从中查找瓶颈，如修改数据库数据，单独加压崩溃聊天服务器而查看区域服务器情况，断开通信服务器查看协议包的处理情况等等。从逻辑模块初期测试而言，我们可以在非完整客户端的环境下改变模块某些变量参数来校验功能模块的整体功能，同时考虑各接口应用，调用的关系。避免模块终的互相功能影响。

　　我们掌握了基本游戏测试技能后，我们何去何从？

　　1、职业经理人

　　2、职业工程师

　　这只是个方向。是否能做好，取决于你的业务面是否宽广，所以无论你已经是部门主管，经理，总监或是测试工程师。发挥部门价值才能突显自我价值是不变的道理。而通俗的多做事是好的办法。有几个业务是可以考虑的。

　　游戏评测

　　这也是一个比较悲催的职业，当然是国内而言。我们现在的游戏对bug都可笑之放过何况可玩性。毕竟这是个策划一家独大的时代。对于“反策划”而产生的工作实际当中难免是道理站得住脚，实操无人支持的尴尬境地。想要改变这个现状只能是上面的那个经理总监或工程师以利弊关系和专业的报告和BOSS交涉。仁者见仁吧，这里说明评测的几个基点。

　　1、将结论前置，开头突出关键点

　　2、观点鲜明，数据论证，切忌个人观点描述冗余

　　3、考虑整体，好的独立设计未必适合

　　4、考虑游戏生存的大环境

　　5、分析现象发生原因。切忌一味描述现象

　　6、明确自身定位，切忌使用高端玩家身份

　　7、切忌将个人习惯引导评测思路

　　8、避免以点盖面，细小问题单一处理，不影响整体评价。并保持真实，认真对待

　　9、“二八定律”利用20%时间发现问题，80时间引用数据论证和解决方案提供

　　10、要提出分期处理建议。以实际进度落实不同解决方式。

　　还要注意的是针对的部门和人群。对策划，运营，市场，玩家，BOSS有具体的报告关键点。把握好这些才能输出一份合理专业的报告，并将转为实操。

　　其他测试

　　除了游戏测试意外。公司必然有其他业务，如工具，平台开发等等。既然是QA部门，应该经质量意识贯穿整个公司行为中，所以只要用到的东西都必须经过QA之手，此也对QA的专业多面性提出的要求。

　　QA在公司其他职能？

　　记得一点，你该做什么事情不要老倚仗别人告诉你。将部门放在公司发展的高度想问题。会发现你可以在产出部门设立各种标准，可以给人事考核部门提供相应考核的数据等等。只要你做这个行业，应该不断问自己，如果你是BOSS，你如何让公司快速高效有价值的发展，哪些是你能以部门之力能做到的？

　　一篇不成熟的文章，一点不成熟的见解！

　　欢迎批评更正。