游戏软件测试 主讲人：徐丽.

Presentation on theme: "游戏软件测试 主讲人：徐丽."— Presentation transcript:

1 游戏软件测试 主讲人：徐丽

2 第一章 游戏软件测试技术 产生软件错误的原因 游戏软件测试技术的发展 静态测试方法和动态测试方法 游戏软件测试技术 游戏软件测试的重要性
第一章　游戏软件测试技术 产生软件错误的原因 游戏软件测试技术的发展 静态测试方法和动态测试方法 游戏软件测试技术 游戏软件测试的重要性 游戏软件测试的目的 游戏软件测试的原则 成功测试包括两个主要方面

3 1、产生软件错误的原因 交流不够、交流上有误解或者根本不进行交流 软件复杂性 程序设计错误 需求变化 时间压力 自负人更喜欢说:没问题……
代码文档贫乏 软件开发工具

4 2、游戏软件测试的发展历程 70年代以前：Ad-hoc testing，与调试没有区分；
70年代－80年代中期：测试基础理论和实用技术形成，测试作为软件质量保证（SQA）的主要职能；

5 80年代后期－90年代中期：测试工具在质量和数量上不断增长，测试与SQA（注重于过程和质量监督）分离，注重于工具对测试效率的影响；
90年后期－目前：关注有效的过程管理对于游戏软件测试的重要性，形成各种测试模型、测试能力成熟度模型。

6 3、静态测试方法和动态测试方法 静态方法：被测试程序不真正运行。 动态方法：被测试程序真正运行。

7 静态测试 不必执行程序，仅通过分析、检查系统的表示如需求文档、系统设计图、程序代码等来寻找程序中是否存在缺陷。

8 根据是否需要检查源码的语法又可以分为： 语法测试主要是非形式化的复审、走查和形式化的软件检查、证明。 语义测试主要是形式化方法，如正确性证明、验证程序的逻辑或功能。要求需求规约形式化，用程序执行前后的两个断言即前条件和后条件来表示规约，要证明软件执行后把前条件变成后条件。现在可作的工作是精化规约和设计，这样一来更容易证明正确性。

9 动态测试 生成测试用例执行程序，比较实际输出与预期输出，来发现存在的还未被揭示的错误，确定测试的成功与否。

10 根据是否需要检查源代码分为： 黑盒测试：开始于需求，基于规约进行测试，包括随机测试和功能测试，随机测试属于一种统计测试，功能测试属于确定性测试。 白盒测试：结构测试，属于确定性测试，开始于结构，基于结构进行测试，缺陷在于如果代码中就没有包含这个功能，则无法确定。

11 黑盒测试方法 黑盒测试也称功能测试（数据驱动测试、基于规格说明的测试），它是在已知产品所应具有的功能，依据需求规格说明通过测试来检测每个功能是否都能正常使用。

12 所有的测试和结果完全基于软件的外部行为，仅依赖于软件的输入和输出。黑盒测试不考虑软件的内部逻辑和具体实现，根据需求规范和设计文档来设计测试用例，因而又称为功能测试。
采用黑盒测试时，选择和设计测试用例的方法主要有等价分类法、边界值法、因果图法等方法，主要用于软件确认测试。

13 游戏软件测试方法：黑盒测试 输入 输出

14 白盒测试方法 白盒测试也称结构测试（逻辑驱动测试、基于程序的测试），它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行。是针对源程序实现的测试。

15 测试用例的选择依赖于测试对象的内部逻辑和结构，又称结构测试。实施白盒测试时需要指定覆盖准则，主要有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖和条件组合覆盖。主要用于软件验证。

16 游戏软件测试方法：白盒测试 应用程序

17 黑盒测试与白盒测试的比较 测试方式 特征 依据 人员 驱动程序 黑盒测试 只关心程序的外部表现，不关心内部设计与实现 软件需求
测试人员、用户 不需要编写额外的测试驱动程序 白盒测试 关注软件的内部设计与实现，要跟踪源代码的运行 设计文档 开发人员与测试人员 需要编写额外的测试驱动程序

18 有了黑盒测试为什么还需要白盒测试？ 黑盒测试只能观察软件的外部表现，即使软件的输入输出都正确,却不能说明软件是正确编码的,因为程序有可能用错误的计算方式得出正确的结果。 白盒测试能发现程序中的隐患,例如:内存泄漏、误差累计等问题,在这方面黑盒测试严重不足。

19 有了白盒测试为什么还需要黑盒测试？ 通过了白盒测试只能说明程序代码符合设计需求，并不能说明程序的功能符合用户的需求。如果程序的系统设计偏离了用户需求，即使100%正确编码的程序也不是用户所要的。

20 4、测试技术 功能测试:黑盒测试 回归测试:对软件作出修改后重新执行以前所做的所有测试，以确保修改没有带来新的缺陷。
入侵测试:模拟web用户恶意入侵。

21 业务功能/规则测试：验证软件提供预期的服务，包括有效/无效的条件、业务规则和工作流
兼容性:在不同的OS、支撑环境下运行检查其正确性 互操作性测试:不同版本软件中相同功能的互操作性

22 性能测试:验证响应/处理时间，主要是响应时间,包括不同系统组件优化响应时间,端端和/或特定子系统,使用可用软件功能的限定数目。
负载测试:验证是否支持同时使用系统的客户的所需数目,关注合适的功能和响应时间,包括不同的客户/事务(理想的和最差的),端端的测试,从不同执行者的工作中抽取的应用功能的大样本。

23 压力测试：验证遇到特定条件时系统功能的可接受性，包括低内存/磁盘空间，少的系统资源，数据库锁和网络带宽等共享资源的竞争。
容量测试：验证大容量数据的支持，主要是DBMS的实体和功能，包括DB中大容量数据，单次事务中的大容量数据。

24 配置测试：验证在不同的硬软件环境下系统合适的功能性，主要是可接受的功能性，包括所选的业务功能测试，特定硬软件环境下的测试
安装测试：验证软件在不同硬软件环境或配置下的安装，主要是安装过程，包括不同的安装选择（常规、自定义，网络，升级），不同的配置，所选的业务功能测试（回归测试）。

25 文档和帮助测试：验证文档传递正确、合适的信息。包括在线、书面、上下文敏感的帮助，是否最新的与软件功能一致。
故障恢复测试:系统出现故障时能够恢复程度的测试。 可靠性测试:系统与可靠性相关的测试。

26 5、游戏软件测试的重要性 游戏软件测试是一个必不可少的活动,是对软件需求分析、设计规约和编码的最终复审；是软件质量保证的关键步骤。游戏软件测试是根据软件开发各阶段的规约和软件的内部结构,精心设计一批测试用例(包括输入数据及其预期的输出结果),并利用这些测试用例去运行程序,以发现软件中不符合质量特性要求(即缺陷或错误)的过程。

27 6、游戏软件测试的目的 测试是程序的执行过程，目的在于发现缺陷； 一个好的测试用例在于能发现至今未发现的缺陷；
一个成功的测试是发现了至今未发现的多个缺陷的测试。

28 7、游戏软件测试的原则 (1)应当把“尽早地和不断地进行游戏软件测试”作为软件开发者的座右铭。
(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。 (3)程序员应该避免检查自己的程序。（注意不是指对程序的调试） (4)在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

29 (5)充分注意测试中的群集现象。 (6)严格执行测试计划，排除测试的随意性。 (7)应当对每一个测试结果作全面检查。 (8)妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

30 8、成功测试包括两个主要方面 被测试的程序段在足够多的测试数据上是正确的。
测试数据是充分的，即该程序段在测试数据上的动态行为能够充分反映质量特性的总体表现。