软件测试技术

当前位置:首页 > 软件测试技术

《游戏测试精通》 第六章 续

6.5质量规划


项目期间,每个游戏项目应该确立对于质量监控和记录的规划。这通常在软件质量保证规划(SQAP)中得以记录。SQAP没有包含测试游戏的信息。那些是在游戏的软件测试规划中涵盖。一个SQAP应严格地关注独立监控、产品改正和过程质量问题。它应该处理如下主题,其中的大部分将在下面详细介绍。


●QA人员

●产品中用到的标准

●评价和审计

●QA记录和报告

●QA 问题报告和修正行为

●QA工具、技巧和方法

●QA矩阵

●供应商控制

●QA 记录集合、维护和保持

●必需的QA训练

●QA风险


本书的合作站点提供了遵循这个大纲的、来自Teraquest(www teraquest.com)的一个SQAP模版文件的链接。


6.5.1 QA 描述


以描述QA团队的组织结构作为开始本节。给出一线的 QA工程师为谁工作、QA的主管向谁报告的信息。辨别在哪个等级QA报告链是独立于游戏开发员工的负责人的。这帮助确立了提升QA问题的一个路径,并确立了项目期间哪个关键的关系应该得到培育和维持。QA经理和开发主管之间的和谐关系会对QA员工和开发员工有正面的影响。


描述项目的QA团队中每个人的主要角色。列举出每个人会涉入哪些活动中。尽可能地具体,这对针对公司的用户界面标准对用户界面屏幕进行审计和用一个静态代码分析工具来对代码采样,并对其进行检查的人来说都很重要。可以使用一个列表或表格来记录这个信息。


严格地说,QA和测试是分开的、截然不同的功能。QA更多关注审计、记录和报告, 而测试则是有关开发和执行的测试,执著地发现游戏中的操作缺陷。然而,依赖你游戏项目团队的大小和技能,你可能不会分开QA和测试团队。但如果这些人中的一些涉入了这两种工作,最好还是分开进行。


6.5.2 标准


有两类标准:生产标准和过程标准。生产标准应用于生产游戏项目功能的部分,包括代码、图形和印刷材料等。过程标准运用于事物被生产的方式,包括文件命名标准、代码格式标准和演化项目文档的维护,例如技术设计文档。所有包含这些标准的文档也应包含于那些它们运用的项目上。然后描述QA员工会怎样监控它们,并怎样对任何矛盾采取措施。


6.5.3 评价和审计


QA评价不同于开发者或测试员所做的代码或测试设计。一个QA评论通常是由一个单独的QA工程师完成,该工程师针对某种参照,例如清单列表或标准,评价一个产品或正在进行的过程。QA评论和审计跨越整个游戏项目中的阶段和团队。


项目文档、项目规划、代码、测试、测试结果、设计和用户文档都是QA评论的候选文件。QA也审计由团队使用的过程程序。包括代码检查过程、文件备份程序和衡量网络上的游戏表现。


评论和审计可以在过程的结果上执行,例如,检查所有在表格中必需的领域是否用正确类型的数据填写好了,以及必需的签名是否已被获得。另一种审计的方法是观察行动中的过程。这对于审计同行进行评论、测试程序和每周一次的备份而言是种好方法。频繁使用的程序,如从备份中恢复项目文件,QA可以确保它在需要时可用。


QA本身也能作为独立的评价规则2)。如果你有多个游戏项目在进行,每个项目的QA团队都能评论团队的工作,以提供反馈和建议来保证他们正在做他们所记录在SQAP中的事情。如果没有其他团队存在,你可以从其他功能诸如测试、艺术开发中选一个人, 让你使用一个清单列表来评论你的QA工作。


在SQAP的这个部分辨别出来的QA活动应该被放置在一个进度表上,以保证QA中的人们会有时间来做所有他们被要求做的事情。这些活动也应该与所有的项目进度和里程碑相协调,这样你能够根据实际情况审计可用的工作产品或活动能力。


对于已规划好的QA活动会打断人们的工作,例如恢复备份或跟人坐下来评论历时一个月的TDD升级,应该添加到整个项目的进度中,这样人们会能够留出一定量合适的时间来准备和参与审计或评论。这对于诸如坐下来评论代码之类的活动是不必要的,因为代码评论将会发生,不管你是否在那里。


6.5.4 反馈和报告


SQAP应该记录:什么类型的报告将被SQA所生成,以及它们将怎样被沟通。报告也应该包括针对计划的SQA活动的进程和状况。这些会记录在SQAP中,连同QA团队的结果的频繁程度以及报告方式都被记录下来。需要频繁注意的项目应该定期得到报告。不频繁的审计和评论能够在更长的时间间隔里得到总结。例如,QA团队可能产生对测试结果审计的每周一次的报告,但是对备份和恢复程序审计而言却每个季度报告一次。测试结果审计在测试开始之后要马上开始,备份和恢复审计能开始的早一些, 开发一开始就开始了。


SQA报告可以是正式的或不正式的。有些报告能够通过email发送到团队,而其他可能累积成季度结果,以便于在公司季度项目质量评论会上得以陈述。


6.5.5 报告问题和纠正行为


SQA不仅符合QA工程师的意愿为项目团队提供一个反馈环,这样他们就会明白正确的方式做事的重要性从而更尽责。这包括使重要的记录和文档保持完整和最新。指导团队或游戏公司决定哪些程序和工作产品获益最多,这取决于QA。一旦QA发现有些事情不一致,那么一个问题报告就生成了。


当测试发现软件中的一个缺陷时,问题报告跟你所写的bug报告非常相似。应包括哪个组织或个人会对解决问题负责,并为此描述一个时间框架。SQAP 应该定义在非一致性的问题上什么数据和统计该被报告,连同怎样和何时它们将与项目团队一起被评论。


不幸的是,历史已经证明有些项目成员可能会更不情愿花费时间来关闭SQA,因为它们有“真正的工作”要做——开发、测试和艺术创作等。因而,定义未被解决问题的标准和过程是个好主意。类似地,对于解决跟产品相关的问题应该有一个已定义好了的方式,而这些产品在游戏团队内不能被修正,例如软件工具或用户手册。


除了一次处理一个一致性问题之外,SQA也应该寻求否定趋势或模式的原因,并给出建议。这包括过程问题,例如进度损耗,和产品问题,例如仔细检查预算的游戏素材内存要求。SQAP应该对QA团队探测和处理此类问题原因的方式进行记录。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~