质量模型——功能测试

《质量模型——功能测试》由会员分享，可在线阅读，更多相关《质量模型——功能测试（8页珍藏版）》请在金锄头文库上搜索。

1、游戏中的场景测试游戏中的场景测试 场景测试就是基于场景的测试。 什么是场景，就是一段假想出来的在现实中可能发生的故事（有联系的连续行为） ，用来帮助人们理解一个问题或者系统。举一个简单的例子说明：玩家背包满时去领取道具，这就是一个场景。 为什么要使用场景测试？为什么要使用场景测试？ 1. 便于学习学习产品 对游戏测试而言，除了需要熟悉所测试功能外，还需要对周边的系统功能，甚至整个游戏有较深入的了解。如果能假想自己是一个玩家，模拟玩家可能的操作，这样就能减少从单一功能点角度出发去了解一个功能的枯燥性，并且可以提升对功能系统内部以及功能点之间关联的理解程度。 2. 将需求文档和测试联系起来 在策划

2、文档中，会对规则进行详细的定义和说明，但是，对于这些规则下的玩法则需要在测试中体现出来。测试人员除了要对策划案中所列出的规则进行测试外，还需要考虑玩家所有可能的操作。由这些操作，就组成了我们测试的场景。 3. 暴露产品设计上的缺陷 缺陷不仅仅是存在于代码层面上，产品设计上也可能会有不合理的地方。我们常用的测试方法，一般都是针对如何发现代码问题的，在发现涉及上的缺陷方面有局限。要发现设计上的问题，就需要从玩家的角度出发，结合玩家的玩法，设计出特定的场景，在这样的场景下进行测试。 4. 探索产品的用法 对游戏测试，规则是死的，玩家是活的。玩家的行为是不可预期的，玩法是多种多样的。把规则转化为玩法，

3、建立对应的测试场景，就可以预先把这些可能的玩法在测试时过一遍，更有利于保证我们游戏产品的质量。这些场景还可以保留下来，作为既定玩法，还能应用于其他系统功能的测试中。 5. 将需求相关的问题引出到台面上 场景测试能有效暴露出产品设计上的缺陷。需求是抽象的，有时只有在实际的运行过程里面才能暴露出问题。这个实际的运行过程，就是场景测试。 综上，在游戏测试时，引入场景测试，对提升游戏的品质是十分必要的。 创建游戏场景的方法创建游戏场景的方法 1. 写出功能系统中对象的生命历程。 2. 列出可能的玩家群体，分析他们的兴趣和目标。 3. 考虑恶意玩家，他们可能怎么攻击你的游戏，怎么利用现有规则。 4. 列

4、出系统事件，考察系统怎么处理这些事件。 5. 列出特殊事件，考察系统怎么容纳这些事件。 6. 列出收益并创建端到端的任务来检查他们。 7. 与玩家沟通，找出原有功能 or 系统中他们最不满意的地方。 8. 与玩家一起参与，观察他们是怎么玩游戏的，经常做些什么。 9. 参考本游戏中类似的系统会做什么。 10. 研究对这个系统以前版本和竞争对手的不足。 11. 创建模拟的外网玩家群体（可使用随机导入外网账号的方式），使用这个模拟玩家群体，模拟外网真实情况。 一个完美的场景测试应包含几个特征：一个完美的场景测试应包含几个特征： 1. 一个基于真实玩家怎么玩游戏的场景，包括玩家的动机。 2. 场景具有

5、感染力，有影响力的干系人会促使让这个场景测试失败的原因得到修复。 3. 场景要可信，不仅在真实的世界中可能发生，而且将很可能发生。 4. 场景包含对游戏的复杂的操作，或者复杂的环境或者一套复杂的数据。 5. 测试结果容易评估 质量模型质量模型功能测试功能测试 概述概述 功能性 当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。 注 1： 本特性与软件为满足要求要做什么有关， 而其他特性则主要与何时满足要求以及如何满足要求有关 注 2： B .21 中对于质量定义的注解适用于本特性中的明确和隐含的要求 注 3： 对于用户操作的系统，功能性、可靠性、易用性和效率的组合可以通过使

6、用质量从外部测量。 外部功能性度量宜对这样的属性进行测量，即包含该软件的系统的功能行为。系统的行为可以从下列方面加以观察： a）当前实际执行的结果与质量需求规格说明之间的差别； 注 ：功能性质量需求规格说明通常描述为功能需求规格说明 b）实际用户在操作期间检测到的功能欠缺，这些功能是在规格说明中未明确但却是隐含的需求。 注 ：当隐含的操作或功能被检测出后，宜评审、批准它们，并在规格说明中陈述。就其实现程度达成一致意见。 适合性 软件产品为指定的任务和用户目标提供一组合适的功能的能力 注 1： 适合程度的例子如面向任务的由子功能构成的功能组合是否合适以及表的容量是否合适等 注 2： 适合性相当于

7、 IS0 9241- 10 中任务的适合性。 注 3： 适合性也影响易操作性。 外部适合性度量宜对这样的属性进行测量，即在测试和用户运行系统期间出现未满足的功能或不满意的操作。 未满足的功能或不满意的操作可能是： a）功能或操作未能按照用户手册或需求规格说明中规定的那样执行； b）功能或操作未能提供合理的和可接受的结果以实现用户任务所期望的特定目标。 比如：功能的充分性、功能实现的完整性、功能实现的覆盖率、功能规格说明的稳定性（挥发度） 。 准确性 软件产品提供具有所需精度的正确或相符的结果或效果的能力 外部准确性度量宜对这样的属性进行测量，即用户遇到不准确的事项的频率。这包括： a）由于不充

8、分的数据引起的不正确或不精确，如数据的有效数字太少不足以做精确的计算； b）实际的操作规程与操作手册上描述的规程不一致； c）在运行期间所执行的任务的实际结果与预期的结果有差别。 比如：预期的准确性、计算机的准确性、精度。 安全保密性 软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问。 G B/ T 8566- 2001 注 1： 这 也适用于传送中的数据。 注 2： 安全性（safety）定义为使用质量的一个特性，因为它不仅仅与软件有关，而且与整个系统有关。 外部安全保密性度量宜对这样的属性进行测量，即带有安全保密问题的功能

9、或事件的数目，包括： a）未能防止安全保密输出信息或数据的泄露； b）未能防止重要数据的丢失； c）未能防止非法的访问或非法的操作。 注 1：建议执行模拟攻击的人侵式测试，因为这种危及安全保密的攻击在通常测试中一般不会发生.真正的安全保密性度量只有在“实际生存系统环境”中，即“使用质量”中才会执行。 注 2：从独立存在的系统的情况到与互联网相连的系统的情况，对安全保密保障的需求变化很大.确定所需的功能性及确保这些功能的有效性已经在相关标准中广泛阐明对于那些任何损害造成的影响是重大或是关键的情况，本部分的用户宜使用适当方式和标准来确定安全保密性功能。对于其他情况，用户可以限制其范围为通常接受的“

10、信息技术（IT）”的保护测量，即抗病毒的备份方式及访间权限的控制. 具体的内容比如：访问的可审核性、访问的可控制性、防止数据讹误。 注：本部分软测有很好的讲述，以软测为主 互操作性 软件产品与一个或更多的规定系统进行交互的能力。 注：用互操作性代替兼容性是为了避免可能与易替换性的含义产生混淆。 外部互操作性度量宜对这样的属性进行测量，诸如涉及数据和命令的通信缺失的功能数或事件数，而这类数据和命令在该软件产品和与之相连的其他系统、其他软件产品或设备之间应易于传送。 比如：数据的可交换性（基于数据格式）、数据的可交换性（基于用户的成功尝试）。 数据的可交换性（基于数据格式） 度量目的：对于规定的数

11、据传输、交换接口的功能已经被实现的正确程度如何？ 应用的方法：按照数据字段规格说明，测试系统的每一个下游接口功能输出记录的格式。对在测试数据交换中正式能与其他软件或系统交换的数据格式的数目进行计数，并与数据交换的总数相比较。 数据的可交换性（基于用户的成功尝试） 度量目的：最终用户不能在目标软件与其他软件之间交换数据的频度如何？在目标软件与其他软件之间数据成功传送的程度如何？用户能否经常成功地交换数据？ 应用的方法：对使用接口功能和失败次数进行计数。 从定义看来，主要是针对系统之间的接口，比如 foxmail 中导出的邮件能否导入 outlook，侧重于软件。类似于系统之间的接口测试。那么系统

12、内部的接口测试呢？比如系统与 OS、系统内部模块该怎么归类？ 互操作性测试的概念和分类 协议是计算机网络和分布式系统中各通信实体间相互交换信息时所应遵守的一组规则。协议是构建网络分布系统的基础，其在网络和分布系统的发展中，一直处于核心地位。协议测试是指按照协议标准，通过控制观察被测协议实现的外部行为对其进行评价。 按照 ISO 9646 规范， 协议测试包括四个方面的内容： （1）一致性测试：目的在于检测所实现的系统与协议规范的符合程度； （2）性能测试：用于检测协议实体或系统的性能指标（数据传输率、连接时执行速度、吞吐量等）； （3）互操作性测试：检测同一协议不同实现版本之间、或同一类协议不

13、同实现版本之间互通能力和互连操作能力； （4）鲁棒性测试：检测协议实体或系统在各种恶劣环境下的运行的能力。 互操作性测试作为一致性测试的补充，力图进一步提高系统互操作性的置信度。它检验两个或多个同一个协议的实现之间的互操作的可能性。 什么是互操作性呢？互操作性本身来自于开放系统，它是开放系统的一个特性。几个典型的互操作性定义如下： SPAGISO：当两个产品相互台作， 协同地为各自所面向的用户提供某个指定的服务时，所表现出的能力称为互操作性。 YS IEEE：互操作性是指两个或多个系统相互使用已被交换了的信息的能力。 再看看各现场总线对互操作性的定义： FF：互操作性意味着来自不同厂家的多个设

14、备能在同一个系统中相互正常操作，而不会损失其设备功能。 LonWorks：保证多个节点（来自同一个或不同的制造商）能够集成于一个阿培而无需客户进行节点或工具开发。 SPAGISO 和 US IEEE 的定义首先是说明互操作性是发生在多个（至少两个）产品（或系统）之间的一种关系，其本质就是从异种系统（异种机， 异种网， 异种数据库等）中可获得 资源透明动用的能力现场总线对互操作性的定义实际上是 SPAGISO US IE 既的定义的子集， 对系统的通信体系结构进行了限制 不可互操作的具体原因 对不可互操作的原因进行分析可进一步加深对互操作性的理解，对提高互操作性的可能性也有重大帮助。不可互操作的

15、原因主要有： 1）服务问题。由于服务的不可用而造成互操作发生问题 2）协议问题。两个不同系统的协议实现中的选项和参数如果不兼容， 则会导致互操作性问题。 3）资源问题。系统之间的互操作都需要资源，但资源是有限的，如果在某些情况下，出现资源不够就可能台导致互操作性问题。这种资源可以是硬件资源，如物理内存，物理缓存，CPU 时间等，也可以是软件资源， 如一些应用对象等。 4）时间问题。所有的通信都需要确定时间参数。时间问题可分成晟大时间，最小时间以及持续时间的不能匹配问题。时间参数不兼容，就会出现互操作问题。特别是象现场总线这种对实时性要求比较高的系统，在这方面出现问题的可能性也较大。 5）应用程

16、序问题或用户配置问题。这实际上并非是 OSI 范围内的问题，但却最终让用户感觉是出现了互操作性问题。 6）接口问题。根据 OSI 的基本参考模型和分层原则，对于 N 层实体来说，它为上层实体提供服务及其接口，同样通过下层实体的接口来使用该层服务。如 N 层通信对等实体之间出现互操作问题， 则可能出现问题的地方有：N 层实体本身对 N 层协议的实现错误 N 层实体使用下层实体的接口不当，下层实体的实现正确但提供的接口错误及下层通信对等实体存在互操作问题。 7）协议自身实现问题。 这也是最主要的问题，它是由于实现者的错误实现而造成的。可以将这样的实现错误问题进行具体分类。表 1 就是其中的一种分类描述。 根据以往的经验，系统出现的互操作性问题在各层上出现的概率有所不同 一般说来，在上几层（包括应用层，台话层等）出现的概率较大，而在下几层（如物理层，数据链路层等）出现的概率要小。因此，为提高系统的互操作性， 需要加强对上层协议， 特别是应用层协议中有关提高互操作性方面的设计和测试。 功能性的依从性功能性的依从性