|
LZ目前在一游戏公司供职，对比web、桌面传统软件测试，游戏业界内测试的技术含量要求低许多，记得刚进公司时，一行政就问我，你们测试是不是每天只要玩游戏就好了；其实这个问题每个人测试可能都碰过，做软件测试时被问，你们软件测试是不是只要每天点来点去，找问题就好了？ 其实问这些问题的意思都差不多，根底就是你们软件测试毫无技术含量，是个人都能去做，他们是这种心态。 关于这个也不多说了，其实在论坛、测试群里这个话题基本都讨论烂了； 相比软件测试，游戏测试被认为是游戏项目中最低一层的存在，大多公司都是这样；进入游戏行内两年，每次上游戏论坛，见过许多说想做游戏策划、设计游戏的人都在问，我想做策划是不是先要从游戏测试做起啊？ 而在我进入游戏行业后做过系统策划、配置管理、最后还是主做测试，当然系统策划是兼的，策划少人去补充下，而配置管理和缺陷系统搭建，发布测试版本，主程给个文档自己去架设测试服这些来讲也算理所当然，呵呵。 其实我想对那些想从测试做起的策划说声，这样是可以，但是你这个所谓的测试，我叫个不懂电脑的来培训他两个星期也能做到，而且你有这种想法最好是去小公司，还可以策划兼测试。 稍微大点的公司，如金山、蓝港你也可以去下，也是有发展前景的哈哈，别人做客服都能转策划呢。 而对那些真心想走测试这条路的，指明了和你说，别去游戏公司，特别是小作坊公司，当然你说暴雪、微软、EA这些游戏工作室你当我没说，我说的是国内的。 你宁愿去外包历练下也别刚毕业就跳到游戏公司这碗水里当测试。
说多了，下面写点常用的测试方法、笔记，不写自己都怕忘记了，哈哈。 软件测试进入游戏测试，HR通常会说，你以前虽然做过软件测试，可是我们是游戏测试，还是有些不同的；对于这句话，我想说，做过软件测试两三年的连目前国内游戏测试这个环境都呆不下，那么请服安眠药，没得说了。 测试万变不离其宗。
一、软件测试方法 1.测试的策略： （1）静态测试：不测试程序本身，而直接寻找程序中可能存在的缺陷或评估代码品质的行为。主要是在单元测试行为中，对技术、设计文件进行评核，程序无法执行或需要对原始程序进行规范符合性检查时该使用这种策略。 （2）动态测试：运作被测程序，输入测试资料，检查运作结果与预期结果的差异，从而判断系统中是否存在缺陷的过程。 2.动态测试的测试技术： （1）黑箱测试：测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能性说明的测试方法。主要是在系统测试阶段时采用。 （2）白箱测试：使用被测程序内部如何工作的资讯，允许测试人员对程序内部逻辑结构及有关资讯来设计和选择测试案例，对程序的逻辑路径进行测试。其测试基于覆盖全部代码、分枝、路径、条件。 （3）灰箱测试：基于被测试程序逻辑结构的基础上，从系统功能接口上设计测试案例。通常是作为黑箱测试的补充或在黑箱发现缺陷以后，回到原始代码分析原因确认问题时采用。
3.测试的阶段： （1）单元测试：为最小单位的测试。在单元测试行为中，各独立单元模块在与系统其他模块隔离的情况下进行测试，检查每个程序模块是否实现了规定的功能。 （2）整合测试：是在单元测试的基础上将已经通过测试的单元模块按照设计要求组装成系统或子系统进行测试的活动。测试着重在各模块、各子系统之间界面上的缺陷。 （3）系统测试：透过整合测试的软件，同其运作环境、资料和使用者结合在一起，在实际或模拟实际环境下，对系统进行全面的测试。目的在于通过与系统需求规格书进行比较，发现软件与系统定义不符合的地方。 （4）验收测试：为最后一个测试行为。它是以使用者为主的测试，由使用者设计测试案例，使用实际资料进行测试。
4.测试的方法： （1）功能测试：检查软件的功能是否符合规格说明书上的需求。 （2）性能测试：检察系统是否实现了规定的性能指标要求。
5.测试的实施组织划分： （1）开发者测试（α测试）：开发者透过检测和提供客观证据，证实软件的实现是否满足规定的需求。主要是在系统交付给第三方测试或验收测试之前进行的活动。 （2）使用者测试（β测试）：在使用者的应用环境下，透过使用检测软件来验证是否符合自己预期的需求。 （3）第三方测试（外包测试）：软件发展方和使用者方之间的测试团队进行的测试行为。
6.测试的其他概念： （1）人工测试：由测试人员来执行测试案例，然后根据实际的结果和预期的结果进行比较，并记录测试结果。 （2）自动化测试：透过回放录制或编写的自动化脚本，驱动系统运行的测试行为。 （3）回归测试：软件在修改以后再次运作之前，为寻找错误而执行程序曾用过的测试案例，以测试缺陷是否再次出现的行为。 （4）冒烟测试：软件版本交付后，对其重要的部分先进行大概的测试，检查主要功能是否正确，再进行后面的测试。 二、软件品质和缺陷报告 1.规范需求需包括： （1）使用者可能认为我们理解或遗漏的。 （2）行业规范。 （3）电脑IT领域的规范和习惯。 （4）客户对电脑技术的限制。 2.外部品质与内部品质模型的六种属性： （1）功能性： 适合 准确 互动 保密安全 功能依从 （2）可靠性： 成熟 容错 易回复 可靠依从 （3）易用性 吸引 易学 易理解 易操作 易用依从 （4）效率性： 时间特性 资源利用 效率依从 （5）维护性： 稳定 易分析 易改变 易测试 维护依从 （6）兼容性： 适用 相容 易安装 易替换 可兼容性 3.用户品质模型的四种属性： （1）有效性 （2）生产率 （3）安全性 （4）满意度 4.缺陷报告应填写的元素： （1）缺陷摘要 （2）缺陷所在的子系统（模块） （3）缺陷位置 （4）缺陷类型、原因 （5）缺陷状态 （6）详细描述 （7）严重程度 （8）紧急程度 （9）附件 （10）发现时的行为 （11）发现途径 （12）测试案例编号 （13）提交的版本 （14）提交的循环周期 （15）提交日期 5.缺陷处理后要填写的三项信息： （1）修复的版本 （2）修复人 （3）拒绝者 6.缺陷的六种状态(不同缺陷管理工具稍有不同)： （1）New：预设值，测试填写一个新缺陷报告时。 （2）Open：测试团队组长对缺陷进行审查后，将缺陷状态从「New」改为「Open」，并在一定的时间内指派给对应的开发工程师。 （3）Fixed：当缺陷被修复并通过了验证测试，开发工程师将缺陷状态从「Open」改为「Fixed」。 （4）Pending：当缺陷由于各种原因无法修复时，开发工程师或项目经理将缺陷状态从「Open」改为「Pending」。处在此状态的缺陷将等待条件具备时再进行修复。 （5）Closed：当缺陷在一个新建版本中完成了验证测试时，测试工程师将状态从「Fixed」改为「Closed」。 （6）Reopen：当缺陷验证失败时，测试工程师会将状态从「Fixed」改为「Reopen」。当以前已经关闭的缺陷又在测试过程中出现时，测试工程师会将状态从「Closed」改为「Reopen」。 三、文件审查和测试需求分析 1.业务规格需求说明书为整个软件生产活动的依据，其审查项目包括： （1）个业务功能和性能指标的描述是否清晰、明确。 （2）同需求描述之间是否存在矛盾和冲突。 （3）业务功能描述是否有遗漏。 （4）业务需求是否可以测量。 （5）业务功能描述是否会和行业规则、企业规范；国家法律规范、政策等发生冲突。 （6）需求中计算公式是否明确，公式中各因数是否明确。 （7）计算是否有精度要求。 （8）多角色和多使用者的系统角色、权限等是否合适。 （9）其引用的文件中是否正确且文件中是否有相应叙述。 2.概要设计文件为描述功能设计、资料结构、资料目录、性能指标等的文件，其审查项目包括： （1）设计是否涵盖了业务需求。 （2）功能模块设计和内外接口之间的资料交换是否明确。 （3）资料结构或类别图设计是否明确。 （4）资料库逻辑结构和物理结构设计描述是否正确，有无遗漏。 （5）应用逻辑设计、网路设计、安全设计是否正确。 3.安装部署文件为描述系统的部署，其审查项目包括： （1）文件阅读者为维护人员，所以要注意技术描述而非业务描述。 （2）开发团队使用的一些术语或缩写词语要有解释说明。 （3）部署中的硬件设备要与上线设备一致。 | 
发表于 2014-9-18 16:41:25