游戏测试用例 游戏测试用例设计实例

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

一、游戏软件与通用软件的区别 a) 通用软件的需求明确，游戏软件需求理想化 i. 通用软件中用户每步作的预期结果都是明确且有规范可参考的，而网游中并 不是所有的需求都有一个明确的预期结果，拿技能平衡性来说，我们所谓的平衡也只是相对的平衡，而非的平衡。没有什么明确的参考参数。只能根据以往游戏的经验获得一个感知的结果。 ii. 网络游戏中的某些功能是有预期结果可参考的。例如组队、交易，而另外一些 带有策划创意的功能，却是根据策划个人的理解，来确定其预期结果的。人的思考力都是有限的，所以不能保证在他的创意中会考虑到各种各样复杂的细节。也不能够保证这个创意就可以完全被用户所接受。 当你作为游戏测试人员时，很多时候你需要做的不仅仅是验证功能。也需要帮助开发者和用户找到一个互相容忍的平衡点。游戏软件的测试员带有对策划需求的怀疑，力求通过自己的努力在玩家和开发者之间将可能产生的矛盾减小。 b) 通用软件开发过程中需求变更少，游戏软件开发过程中需求便更快 i. 通用软件的使用人群和软件的功能针对性，决定软件从开始制作就很少再有新 的需求变更。而游戏软件，为了满足玩家对游戏的认可度，策划需要不断的揣摩玩家的喜好，进行游戏功能的改进。加之网游制作本身就是一个庞大复杂的工程，开发者不可能做到在开发的前期，就对游戏架构及扩展性做出的评估。所以导致为了满足用户的需求而不断的进行一些基础架构的修改，基础架构的修改必然导致某些功能的。所以就出现了，游戏开发过程中的一个恶性循环，当基础架构修改到满意了，玩家的需求又有了新的变化，随之而来的又要进行新的调整，再进行新的修改。终导致了游戏软件的开发周期不断加长。任何一个有经验的团队，对于每一个影响基础的改动都应该做出正确的评估。 二、网游有哪些测试内容 a) 性能 i. 客户端性能 ii. 端性能 1. 2. 数据库 iii. 网络 b) 功能 i. 从运行完.exe打开游戏界面后可进行的各种作、 ii. 界面 iii. 音乐 c) 自动化 i. 测试工作组织实施中需要的工具、软件、平台的开发 ii. 自动化的回归测试作用：游戏中基础的、变动不大的、出错率高的、可进行 checklist重复测试的功能、性能等自动化是一个好方法 iii. 任何时候自动化都取代不了人脑，它只是将一些重复性的劳动从我们测试人员 身上去掉，让我们有更多的时间做更有意义的事情，如果你觉得你做一件事情是重复的，且有规律可行的，不防考虑自动化 三、游戏中针对功能性测试测试用例编写浅谈

游戏测试用例 游戏测试用例设计实例

游戏测试用例 游戏测试用例设计实例

游戏测试用例 游戏测试用例设计实例

游戏测试用例 游戏测试用例设计实例

测试用例的基本要素包括哪些？

测试用例组成要素：用例名称、测试目的、测试级别、参考信息、测试环境、前提条件、测试步骤、预期结果、设计人员。

测试用例：是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式，同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的，不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。

回合制游戏战斗系统测试用例

你这要求的范围也太大了，一个游戏测试用例包括人物，技能，界面，常用功能，性能等等测试用例。我估计你想要的就是回合制游戏中的回合制战斗这块用例吧。

回合制游戏与普通2D,3D游戏不同的是战斗场景的切换，这点需要重点考虑。

大概的测试点：

1.场景切换后人物信息

2.场景切换前后功能互斥

3.新场景中的信息调用

4.场景切换前后状态存储

5.新场景中所有人物信息与战斗状态的同步

6.不同场景内外人物交互

暂时想到的就是这么多，其他的你应该与你们策划与程序讨论，一个游戏测试的测试用例需要与策划、程序多次讨论才能定型

什么是测试用例，它是由哪些基本元素组成

测试用例就是将测试系统的作步骤用文档的形式描述出来，让软件测试的行为具体化，来核实软件产品是否满足项目需求。测试用例是执行测试的依据。

测试用例的组成元素：

用例编号：编号是为了查找测试用例，便于测试用例的跟踪。

用例标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。

测试项目：测试项目对应的是测试用例中的子项名。如：系统测试用例、集成测试用例、单元测试用例。

前置条件：执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试。

输入数据：测试用例执行时，需要输入的外部信息。

作步骤：执行当前测试用例所要经过的作步骤，需要给出每一步作的详细描述，测试人员根据测试用例作步骤，完成测试用例的执行。

预期结果：当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。

优先级：定义测试用例的优先级别，可以分为”高“、”中“、”低“三个级别。

执行结果：执行用例后的结果。

编写人：由谁编写。

执行人：由谁执行。

在以上元素中，用例编号，测试项目、用例标题，前置条件，输入数据，作步骤，预期结果，优先级是每一条测试用例的必要元素。

1、测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

2、测试用例的基本元素：

测试索引，测试环境，测试输入，测试作，预期结果，评价标准。

知识点延伸：

测试用例是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。

测试用例是什么意思?

问题一：什么是测试用例 一个测试用例描述了针对某个目标对程序进行测试所采用的一组实际输入、程序执行条件、测试步骤和预期的输出，以核实某个程序或其中的特定路径是否满足特定需求。由于程序输入的范围会非常大，因此会导致一个软件可选的测试用例数目巨大（甚至是无穷的）。这时，需要恰当地设计和选择测试用例集，以在限定的资源和时间内，尽可能地暴露软件中的错误。因此，测试用例集的设计通常被认为是测试中重要、也是困难的方面。由于实际测试中使用的测试用例集的输入范围只是程序输入的子集，因此即使软件通过了测试，也无法保证程序一定是正确的。这说明测试本身是不完全的，不能证明程序无错。人们认为，软件测试活动从未间断，只是在软件交付用户使用后，将由用户扮演测试角色而已。 对每个测试用例都需要给出具体描述，表1给出了一个测试用例模版示例。 表1 测试用例模版用例标识：对该测试用例赋予一个标识用例开发者：谁编写的本用例 用例开发日期：编写用例的日期测试项：描述将被测试的具体特征、代码模块等对象测试输入：测试时为程序提供的输入数据前提条件：执行测试时系统应处于的状态或要满足的条件等环境要求：执行测试所需的软硬件环境、测试工具、人员等测试步骤：(1)……；（例如，点击“文件”菜单中的“新建”菜单项） (2)……；（例如，在“test case”目录下选择“test5.dat”文件）……预期输出：希望程序运行得到的结果 用例之间的依赖性：该测试用例依赖或受影响的其它测试用例 当测试用例数量多时，文档化的工作量就比较大。这时，模版内容在实际测试中可以根据需要进行简化，例如把各个测试用例所共有的内容单独列出来（如环境要求），并把所有测试用例用一张表格描述出来。

问题二：软件测试用例的依据是什么 1、软件的需求文档，开发的开发文档（如果有）（功能相关）

2、根据产品具体的使用环境设计相关用例（兼容性相关）

3、根据目标用户的特点设计用例（用户体验相关）

4、根据相关公司标准和业界、标准设计测试用例（性能。安全相关）

问题三：什么是测试用例？ 测试用例（Test Case）是将软件测试的行为活动做一个科学化的组织归纳，目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一，不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不同的趋势。

要使终用户对软件感到满意，有力的举措就是对终用户的期望加以明确阐述，以便对这些期望进行核实并确认其有效性。测试用例反映了要核实的需求。然而，核实这些需求可能通过不同的方式并由不同的测试员来实施。例如，执行软件以便验证它的功能和性能，这项作可能由某个测试员采用自动测试技术来实现；计算机系统的关机步骤可通过手工测试和观察来完成；不过，市场占有率和销售数据（以及产品需求），只能通过评测产品和竞争销售数据来完成。

既然可能无法（或不必负责）核实所有的需求，那么是否能为测试挑选适合或关键的需求则关系到项目的成败。选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。

我们公司于上使用日事清来进行编辑测试用例，同时执行测试用例，并取得不错的成效。日事清是专业的企业管理软件，可自动生成工作总结，进行日程、团队协作。

也可以算个人，也可以算企业，以为既可以管理个人的个人日程也可以管理整个团队里面的日程。

问题四：测试用例和用例规程有什么区别 首先说,测试文档与测试用例不是一个概念. 测试文档包括整个测试过程中的测试,测试方案,测试用例,测试规程,测试记录,测试报告,缺陷报告等.所有文档,每个文档所涉及内容不同. 而测试用例主要根据方案中的测试方法设计的测试执行步骤及预期结果,

问题五：什么是测试用例 不知道你是否了解测试用例的基本设计方法，包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交分析……刚进入软件测试，你说根据设计出的图来写测试用例更好一点，那你就用这种方法也行，主要目的是测到尽可能多的情况。用例来自需求，回归需求

问题六：什么是测试用例 什么是测试脚本 两者的关系是什么 测试需求是主要是整理测试焦点（包括一些界面、输入域、业务流程、数据等），并明确测试焦点的优先级，为测试用例的设计提供测试所需的功能点信息。测试需求的分析也会体现用例设计方法，有的测试需求分析文档中也会指导性的明确焦点的测试用例设计方法。 可以说，测试需求是告诉你要测什么，而测试用例是告诉你怎么测。 好的测试需求能发现需求中显性和隐性的测试焦点，从而能更好的指导测试用例的设计，能更好的提高被测模块整体功能的覆盖率。 测试需求分析会根据不同阶段的测试类型会有不同的侧重点。我是做系统测试的，主要注重系统或软件是否满足用户需求的情况。平时做测试需求时会比较明确系统的功能模块和测试点明细整理，也会把测试案例设计方法同时加入到分析文档中。

问题七：软件测试中，测试用例里的测试结果P/F，这“P/F”指的是什么？ P pass 通过

F Fail 失败

问题八：什么样的用例是好的测试用例 1、用例覆盖程度

毫无疑问，这一点应该是重要的，无需多说，覆盖率化是一套测试用例的重要评价标准，如果漏测就杯具了。2、用例是否已经达到工作量小化

在满足用例覆盖程度化的前提下，应该尽量减小执行用例所需要的工作量。这些方面的方法有不少，如条件覆盖，分支覆盖，正交覆盖等方法。面对不同的测试对象，也有不同的方法来保证：对于网页背后的php逻辑，可以通过在网页上测试后，用一些工具比如xdebug来统计代码覆盖率；对于向外提供接口的server

，采用的方式就是分析在外面暴露的接口设计用例，大致的通过接口参数来估计一下分支判断的情况。

3、用例的分类以及描述是否足够清晰

用例的分类，在这里是指相同类型的用例是否放在一起了。例如：接口类的用例，参数的取值范围是1-3，但是现在却传入4；数据类用例，状态机现在位于状态2，却要求状态跳转到无法到达的4；逻辑类用例，正常功能的产出等。将相同类型的用例放在一起，有助于理清思路，清楚了解用例设计是否完备。

用例的描述，是指描述的清晰程度是否能够形成文档。例如上面参数取值范围的例子，用例这样写：“传入错误的值”或者“传入非1-3的值”，明显没有写成“传入值4”有效。这与写程序一样，总是写闭区间的范围而不是开区间。4、用例是否表明了测试目的

写明用例的测试目的，对文档的易于理解性和工作交接的好处不言而喻，现代软件工程不可能只有一个人在做事情，项目于人员的变动也是难免的。在过程中留下足够的信息，可以在后续工作提高很多效率。5、测试用例的易于维护性

如果被测对象有所升级，测试用例的说明或者脚本是不是容易维护呢？例如在有状态机的情况下，测试用例之间是相互依赖的（即需要一定的执行顺序），这样被依赖的用例修改后，后端不需要同步根据修改。而如果用例之间没有相互依赖关系（如用例是自己造的数据，不是依赖于前端的产出），可能一旦有变化，就需要修改这两个。当然，这两种情况不能的说哪种好，是需要看实际使用时候的情况进行取舍的。

问题九：软件测试用例中报告结果的N/A是什么意思？ CMCC测试用例中的N/A，是指没有条件或者环境去测这一条CASE，比如某一条case需要某种辅助工具去测试，而这种辅助工具没有，那就是N/A。总之是不用测或者是没有测的意思

测试用例是什么意思？

软件测试用例就是指导你对软件执行作，帮助你证明软件功能或发现软件缺陷的一种说明。

他的形式一般是这样的

设一下吧。现在要求你测试一下百度知道的提交回答功能。

用例编号：提交问题001（编号通常会根据功能或模块编写）

测试目的：验证当用户回答完问题后，可以正常提交。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）

测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。

重要级别：像提交回答这条用例，多数会被列为别用例，因为是基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。

预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）

作步骤：1、将光标点入“我来帮他解答”下的输入栏。

2、输入想提交的

3、点击提交回答

4、验证提交后是否能显示到当前问题下

（输入数据多数时候是合并到作步骤中的，比如这条里的输入数据就是“”）

预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的可以正确显示……

其中所有的标题

为软件测试用例需要包含属性。冒号后面是对这一条用例的具体描述。

软件测试用例就是指导你对软件执行作，帮助你证明软件功能或发现软件缺陷的一种说明。

他的形式一般是这样的

设一下吧。现在要求你测试一下百度知道的提交回答功能。

用例编号：提交问题001（编号通常会根据功能或模块编写）

测试目的：验证当用户回答完问题后，可以正常提交。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）

测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。

重要级别：像提交回答这条用例，多数会被列为别用例，因为是基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。

预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）

作步骤：1、将光标点入“我来帮他解答”下的输入栏。

2、输入想提交的

3、点击提交回答

4、验证提交后是否能显示到当前问题下

（输入数据多数时候是合并到作步骤中的，比如这条里的输入数据就是“”）

预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的可以正确显示……

其中所有的标题

为软件测试用例需要包含属性。冒号后面是对这一条用例的具体描述。

软件测试用例就是指导你对软件执行作，帮助你证明软件功能或发现软件缺陷的一种说明。

他的形式一般是这样的

设一下吧。现在要求你测试一下百度知道的提交回答功能。

用例编号：提交问题001（编号通常会根据功能或模块编写）

测试目的：验证当用户回答完问题后，可以正常提交。（多数是会写需求规格的说明，总之要让人看明白你这条用例是想测什么）

测试标题：这个有时候就包含了测试目的，目的是可以不写的，但测试用例标题是必须的。

重要级别：像提交回答这条用例，多数会被列为别用例，因为是基本的功能。往往越是基本的，级别越高。原因在于，如果基本功能都有缺陷，那根本不用测别的功能，版本直接打回。

预制条件：1、百度知道运转正常。2、用户已登陆。3、进入了自己想要回答的问题页面。（也就是你做这条测试前必须要有的前提条件）

作步骤：1、将光标点入“我来帮他解答”下的输入栏。

2、输入想提交的

3、点击提交回答

4、验证提交后是否能显示到当前问题下

（输入数据多数时候是合并到作步骤中的，比如这条里的输入数据就是“”）

预期结果：1点击提交回答后，页面提示回答成功。2再次查看该问题时,刚刚的可以正确显示……

其中所有的标题

为软件测试用例需要包含属性。冒号后面是对这一条用例的具体描述。