游戏回归测试如何进行

Ⅰ 什么是回归测试，回归测试不通过如何处理

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。1.回归测试是指重复以前的全部或部分的相同测试。2.新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。3.回归测试的重心，以关键性模组为核心。

Ⅱ 什么是回归测试

回归测试是指开发修改了旧代码后，测试重新进行测试以确认开发本次修改没有引入新的错误或导致其他代码产生错误。常见的回归测试包含：
1.BUG回归
2.旧功能回归
每一次开发提测即意味着需要测试开展之前版本的回归测试，具体需要开展几轮回归测试可以参考以下因素：
1.取决于项目的复杂度、规模
2.N版本，要进行N-1次回归测试
很明显回归测试的工作量很大，行业里面好的做法是会采取自动化测试来大幅降低系统测试、维护升级等阶段的成本。
如果小伙伴想深入的学习可以参考黑马程序员软件测试的相关知识进行加强

Ⅲ 回归测试需要注意什么因素，怎么设计回归测试用例

此时，就势必要进行回归测试。而且系统越成熟，回归测试的比重也会越大。这将会对测试工作带来不小的挑战。 在实际工作中，经常是一方面求全，希望覆盖面尽量广，避免漏测。另一方面求产出，大量的回归测试用例，可能只发现很少的问题，投入与产出不太匹配，会影响测试人员的士气，甚至测试管理者也会对这种投入产出有所质疑。并且，设计大量的自动化测试脚本，会占用大量的时间。 引子就说这么多，看看大家对这一普遍问题有什么看法和建议。 会员卖烧烤的鱼的精彩回答: 最近刚到新公司上班，面临的比较突出的问题是人力紧张，由于公司的产品用在Windows mobile，MTK，Kjava，Symbian，website几部分，测试人员<5(+上我)，如何高效的组织测试团队确实是个挑战?回归测试属于软件测试环节比较重要的部分，所以花费了一些时间总结此文，希望能给测试人员稀少，产品或项目众多的公司，提供一些建议 所谓回归测试，即就是在软件生命周期中，只要软件发生了改变，就可能给该软件产产生问题;所以，每当软件发生变化时， 我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否破坏原有的正常功能。 其实仅单纯从英文单词Regress很好理解:return to a worse or less developed state.即是退化，衰退的意思， 检查软件从正常的稳定状态退化或是衰退到不正常工作的不稳定状态。 注意:回归测试不仅仅是针对在系统测试阶段，而是在软件生命周期中^_^ 如果以上的定义均明确后，有效的回归测试应从这几方面: 其实最有效的回归测试方法建立在开发测试库的基础上;开发在创建测试库，每次生成程序的新版本时都可以运行这些用例。 只有有效的从源头避免风险才能有效的进行回归测试(目前国内的公司，能从事此级别的，太少) 1 强调单元测试时加强回归测试，引入代码评审，引入自动测试; 2 集成和系统级的测试时，加强测试用例评审，回归测试用例的选择; 具体的选择可以参考以下几点: 1 开发设计测试用例时制定优先级，如高，中，低，方便以后自动化或是策略选择; 2 配置管理时，引入测试用例基线管理，有效管理测试用例; 3 定期维护测试用例增，删，保持最新状态; 回归测试时需考虑效率和覆盖度有效配合，通常的策略有以下几种: 基于风险选择测试: 开发人员修改的局部程序时，可能已经处理了症状，所以主要测试其被改变的模块和它的接口上; 但是也可能存在未触及到根本原因，所以需要测试周边程序及相互依赖性的部分; 错误本身可能得到了修复，但修复也可能造成其他错误，所以有必要为每个修复的错误，设计回归测试。 基于全面测试策略: 如果时间充足，资源齐全，可以进行全面测试,最低的遗漏回归错误的风险，但测试成本最高，非上策! 其它的回归测试: 1 基于GUI方式的自动化回归测试技术 2 基于Ad Hoc 回归测试:增加随机测试，避免回归测试肓点3 基于交叉测试:多人互动的回归测试，尤其在核心的功能点，交互性比较的

Ⅳ 什么叫回归测试

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

(4)游戏回归测试如何进行扩展阅读：

回归测试可遵循下述基本过程进行：

1、识别出软件中被修改的部分。

2、从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。

3、依据一定的策略从T0中选择测试用例测试被修改的软件。

4、如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。

5、用T1执行修改后的软件。

第1和第3步测试验证修改是否破坏了现有的功能，第4和第5步测试验证 修改工作本身。

Ⅳ 回归测试的策略和区别是什么

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
冒烟测试冒烟测试(smoke test)在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。
冒烟测试是自由测试的一种。

Ⅵ 回归测试测多久,测几轮

一个周期左右，具体几轮看具体情况。
在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。

Ⅶ 回归测试是什么意思

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

测试用例库的维护：

为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。

随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。

Ⅷ 什么是回归测试，回归测试的策略

回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重

Ⅸ 面试题: 如何对一个游戏进行设计测试用例.

一、游戏软件与通用软件的区别 a) 通用软件的需求明确，游戏软件需求理想化 i. 通用软件中用户每步操作的预期结果都是明确且有规范可参考的，而网游中并 不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非绝对的平衡。没有什么明确的参考参数。只能根据以往游戏的经验获得一个感知的结果。 ii. 网络游戏中的某些功能是有预期结果可参考的。例如组队、交易，而另外一些 带有策划创意的功能，却是根据策划个人的理解，来确定其预期结果的。人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。也不能够保证这个创意就可以完全被用户所接受。 当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。也需要帮助开发者和用户找到一个互相容忍的平衡点。游戏软件的测试员带有对策划需求的怀疑，力求通过自己的努力在玩家和开发者之间将可能产生的矛盾减小。 b) 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快 i. 通用软件的使用人群和软件的功能针对性，决定软件从开始制作就很少再有新 的需求变更。而游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改进。加之网游制作本身就是一个庞大复杂的工程，开发者不可能做到在开发的前期，就对游戏架构及扩展性做出最好的评估。所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的颠覆。所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。最终导致了游戏软件的开发周期不断加长。任何一个有经验的团队，对于每一个影响基础的改动都应该做出正确的评估。 二、网游有哪些测试内容 a) 性能 i. 客户端性能 ii. 服务器端性能 1. 服务器 2. 数据库 iii. 网络 b) 功能 i. 从运行完game.exe打开游戏界面后可进行的各种操作、玩法 ii. 界面 iii. 音乐 c) 自动化 i. 测试工作组织实施中需要的工具、软件、平台的开发 ii. 自动化的回归测试作用：游戏中基础的、变动不大的、出错率高的、可进行 checklist重复测试的功能、性能等自动化是一个好方法 iii. 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员 身上去掉，让我们有更多的时间做更有意义的事情，如果你觉得你做一件事情是重复的，且有规律可行的，不防考虑自动化 三、游戏中针对功能性测试测试用例编写浅谈
国际体验设计协会IXDC 历届大会精彩集锦
游戏用户体验大会 互联网产品大会 交互设计体验周
作者：sunli 制作时间：2008年10月份 个人空间地址：
[url]http://www.51testing.com/?89706[/url] 本文档仅供学习参考，请误擅自转载
2 / 3 先了解下游戏中有哪些功能： a) 游戏发开中的功能有哪些 i. 不同的游戏对于功能的划分不同，但是目前主流一些功能划分中有以下内容： 1. 基础操作 2. Npc 3. 地图 4. 装备 5. 剧情 6. 技能 7. 人际 8. PVP 9. …… 这样我们很简单的将整个游戏的功能进行了划分，划分完毕，下来的工作就是针对某个功能的测试了。很多人都问过一个问题，游戏测试中测试用例到底有什么用。下面继续~ b) 游戏测试的测试用例有什么作用 i. 测试执行过程中，按照用例指示的操作检查操作结果是否正确，记录测试过程 中发现的bug ii. 按照用例的执行结果确认功能的通过与否，也有的按照用例的覆盖率来确定单 服测试的通过与否 iii. 便于回归测试的执行 这样讲应该比较明白了吧。 c) 测试用例应该包括什么——测试执行过程中所需的所有信息，举例说明下。例如： i. 表头：功能名称、案例编写人员、编写时间、测试人员、测试时间 ii. 正文：功能点、测试点、测试输入、预期结果、实际结果 iii. 用例执行结果统计 d) 功能点模块化理念 都知道一个复杂庞大的系统，程序在实现时会将其分成若干模块按照模块功能优先级进行实现。我们测试过程中也采用这种方法，将复杂的功能点按照实现功能进行分类，分类后的测试点，再进行分类，直至细分成为一条条用例。就像庖丁解牛那样。 按照等价类划分法，将同一判断条件的测试点组成一个集，在这个条件基础上再次判断的条件，我们假设它已经成立。这样在用例设计过程中就需要测试人员清楚的知道，哪些条件是一类需优先确认的，哪些是以这类条件为基础的。我们最终形成的测试用例一定确保的是一条用例只检查一个测试点。 这样设计也有另外一个好处，如果一条用例不能走通，其它的还可以继续检测，经常会遇到测试过程中由于一个bug，导致测试工作停滞。现在这样子我们就可以采取脚本调试，或者其它方法跳过有bug的测试内容，继续进行其它测试点的测试了。 e) 场景测试法协助功能点细分 游戏测试中，场景测试方法是经常用到的一种方法，什么是场景测试法，及按照功能设计要求，在脑中模拟出来的一个功能使用时的操作流程。按照每步操作的针对点，将针对点划分为所用例设计时的小功能点。划分时需每步针对点的各种检查点分到该功能点内设计为该功能点的检查点。再根据检查点进行测试输入（及操作过程）的编写。用例编写过程中的思考方式就如上了。讲起来比较抽象，希望对
作者：sunli 制作时间：2008年10月份 个人空间地址：
[url]http://www.51testing.com/?89706[/url] 本文档仅供学习参考，请误擅自转载
3 / 3 大家有所帮助。 f) 用例的设计原则——一直有人问到底要详细到什么程度 i. 我们不期待用例编写到任何人都可以执行，也没有这个必要 ii. 我们针对的是网游的测试人员，至少是玩过网游的人，这些人对于游戏中的基 础设定都有认识，我们不可能对着一个不知道任务界面是什么的人大讲怎么测试任务。所以我们用例编写的原则就是针对我们测试组内的测试人员。 iii. 但是，请不要简略到别的测试人员看不懂，特别是当你是专职的用例编写人员 时，编写时请多考虑下语言描述的方式。请让你的同伴可以看懂，你所要表达的意思。 iv. 用例是没有固定格式的，它的主要原则就是，测试中所需所有信息，我通过你 的文档都能够获取到。所以不要再执着的像别人要模板。模板你自己都可以设计，发挥你的创意。 四、编写过程注意事项 与设计人员的沟通 拿到一份文档时请不要急于编写，在这之前很多事情需要做，请先将文档阅读至少三遍，然后思考下，你自己大脑中是否有你所看文档功能点的一个流程图，当确认已经准备好了。开始设计用例，用例设计的过程就是与设计人员不断沟通，深入了解功能的过程。你会发现，或许跟你之前流程图中想象的并不完全一样。这个时候不必惊讶，去找他们核对就好。不怕发现问题，就怕没有发现问题，最终做了很多无用功。编写过程中发现的没有预期结果的内容，请及时与策划人员、程序人员核对，必须三方核对。核对完毕提醒策划人员及时更新设计案，提醒程序人员设计案新修改内容。这样你会发现，设计测试用例过程的本身就是发现策划案不完善的过程。 请运用你的思维，采用边界法、等价类划分法、错误推断法、以及以往的经验，将每一个测试点的所有需检查点进行充分的设计。发挥你的主动性，和测试组内其它人探讨你认为可能存在风险的测试点，以便得到更多有价值的信息

Ⅹ 关于软件回归测试问题。

一般就是先进行冒烟测试，首先确定这些测试的软件能够运行，然后进行第1轮测试，测出来问题之后经过项目经理签字确认后发给每个程序员进行修改，确认回归测试的日期，回归测试时主要测试修改过的部分，同时兼顾不能引发其他方面的问题。一般情况第1轮回归完成之后不在出现问题，但是实际过程中会出现第2轮回归测试，如果出现第3轮回归测试，我们将提交问题到质量问题报告中。