开源软件测试模型

一、模型概览

开放源码软件测试模型以“满意测试”为基本原则，强调迭代发展。

“满意测试”基本定义

是一个过程，通过该过程可以合理的成本获取足够的产品质量评价信息，从而使得与产品有关的决策更为明智和及时。

模型基本需求

以下给出开源软件测试模型应满足的一些基本要求，将在实践中不断丰富和完善：

1. 应充分考虑开放源码的早发布和常发布特点，对每一次代码的提交、滞后、变更能够作出适当反应，允许对仍处于开发、尚未集成的元素进行及时测试；

2.明确鼓励测试人员在进行测试设计时充分利用各种信息源，而不仅限于项目文档；

3.允许测试工作由于较差的或滞后的项目文档而受负面影响，但应防止完全阻塞测试工作的情况发生；

4. 允许每个测试案例可以利用不同的信息源进行设计，允许在获得新的信息源时对测试进行重新设计；

5. 应包含反馈机制，使得测试执行过程中的发现可被及时考虑到测试设计中；

开放源码软件测试模型框架

以上述需求为基础并结合开放源码特点，给出开放源码软件测试模型。该模型是一个软件测试启发式模型，基本目标是用于提醒测试人员在创建测试时应着重考虑的各种因素，进而可被用来定制测试。

      1.协商并理解项目的测试目标；

2.理解并协商与测试技术选择相关的各种因素，理解与测试工作有关的限制、要求和可用资源，从而使得测试更为高效；

3.在充分考虑和利用其他各种因素的前提下选择合适的测试技术以达到测试目标；

4. 随时监控项目项目的状态，并在需要时调整测试计划，以使得目标、测试技术的选择和各种因素保持统一。

 

测试目标明确项目测试应优先考虑的任务和侧重点。

测试环境包括资源、限制和其他可能影响测试执行效果的外部力量，应确保在限制范围内充分利用了各种可用资源。

产品元素指被测试的对象，应确保检查了产品所有方面，包括软件、硬件和操作。

质量准则包括各种可用来确定产品是否存在问题的规则和数值，具有多维特点，并且常常是隐含的或相互矛盾的。

测试技术选择给出各种创建测试的策略和方法，在对测试目标、测试环境、产品元素和质量准则进行综合分析的情况选择和使用，并根据测试执行情况及时调整。

二、测试目标

· 发现重要问题                                                · 评估质量/风险

· 标准符合性认证                                             · 完成过程委托监理

· 让受益人满意                                                · 责任担保

· 针对QA的改进建议                                         · 针对测试的改进建议

· 针对质量的改进建议                                       · 效率最大化

· 成本最小化                                                   · 时间最小化

三、测试环境

有许多因素对于项目测试工作能否成功完成具有重要影响，在此将这些因素统称为测试环境。下面给出一些通用的信息类别，考虑其中各个因素对于测试工作是起促进作用还是阻碍作用，最大限度利用各种可用资源，同时将各种阻碍因素的影响最小化。

3.1 受益人

指任何对于产品质量能够发表意见以施加影响的人。所有的需求都直接或间接地来源于一个或多个受益人，软件测试人员在整个测试过程中作为受益人的代理。

3.2 测试信息

指测试工作所需要的与产品或项目有关的信息。

  进度

• 测试：何时开始测试以及要持续多长时间？
• 开发: 何时构建可以被测试、何时增加新功能、何时冻结代码，等等？
• 文档: 何时用户文档可被评审？

 预算

• 需要购买或开发的测试资源和材料的费用如何？

过程

• 项目管理：项目采用的生命周期模型、项目计划和监控手段如何。

• 配置管理：项目配置管理方法和实施如何？

 测试条目

• 可用性：能否获得被测产品？能否从开发人员或其他人员那里获得测试所需信息？

• 易变性：获取的信息是否最新？如何获得有关新信息或信息变更方面的通知？产品设计和实现经常变更吗？

• 可测试性：产品是否足够可靠以便于进行有效测试？

• 交付性：需要生成何种的报告，是否要共享中间测试结果还是仅提交最终结果？
• 
  

3.3 测试团队

指任何将要执行或支持测试的人员。

 

工作负载

是否有足够人力按来照期望时间完成所有计划好的测试工作？

专家能力

是否拥有与项目有关的正确知识以很好地完成计划好的测试工作？

组织

所有测试工作是否得到有效协调并目标一致？

3.4 测试工作平台

指用于支持和管理测试的软硬件平台。

测试平台——是否拥有测试执行所需的全部设备和平台？

测试工具——需要那些测试工具？他们是否可用？

测试库——是否测试过程中的任意文档和结果均要保存并进行跟踪吗？

错误跟踪系统——如何进行错误报告和跟踪？

四、产品元素

     软件产品最终体现为提供给客户的一种操作经历或解决方案，包括支撑平台、软件元素和用户操作，以及相互之间的数据交互，具有多维的特点。为了测试工作取得成效，必须综合考虑这些层面。以下给出软件产品应包含的一些重要的元素类别，如果仅注意测试其中几个类别则可能会遗漏重要错误。这些类别提供了一个起始点，需要在特定环境中细化。

4.l 支撑平台

指软件产品所依赖的任何事物。

• 外部硬件。用于支撑软件产品工作的硬件元素和配置，不作为产品的组成部分，如CPU、内存、键盘等。

•  外部软件。用于支撑软件产品工作的其他软件元素和配置，不作为产品的组成部分，如操作系统、驱动程序、字体等等。

4.2 软件元素

 

结构

指组成软件产品的任何事物。

• 代码：组成产品的任何代码结构，从可执行码直至单个例程。
• 接口：子系统之间的连接和通信点。
• 硬件：任何作为为产品组成部分的硬件元素。
• 非执行文件：除程序外的任何文件如文本文件、样本数据、帮助文件等等。
• 其他介质：软件和硬件之外的任何介质，如纸面文档、Web连接和内容、包装、许可证协议等等。

功能

指产品要完成的任何事情。

• 用户接口：任何协调与用户交换数据的功能。
• 系统接口：任何协调与用户之外的其他实体（如其他程序、硬盘、网络、打印机等等）交换数据的功能。
• 应用：任何用于定义产品、区分产品或完成核心需求的功能。
• 错误处理：任何检测错误和从错误中恢复的功能，包括所有的错误消息。
• 可测试性：任何支持测试该产品的功能如诊断程序、日志文件、声明、测试菜单等等。

 

数据

指产品要处理的任何任何事物。

• 输入：产品要处理的任何数据。
• 输出：经产品处理后产生的任何结果数据。
• 预置值：要作为产品的一部分提供给客户、或直接构建在产品内部的任何数据如预制数据库，缺省值等等。
• 固定值：存储在内部、在多个操作中应保持一致的任何数据，包括产品模式或状态如选项设置、视图模式、文档内容等等。
• 时序：数据和时间之间的任何关系，如每秒击键次数、文件的时间戳、或分布式系统的同步。
• 非法：任何能够触发错误处理函数的数据或状态。

4.3 操作

指产品将被如何使用。

使用情景——与时间相关的操作模式，包括产品在相关领域要典型处理的数据模式，随用户而变化。

物理环境——产品运行的物理环境，比如噪音、照明等等。

五、质量准则

当声称一个产品是“高质量”时，意味着“高度”满足了该产品的受益人所定义的质量准则。测试工作常常不得不在质量准则不很明确的情况下进行，以下所给出的准则类别可帮助进行“头脑风暴式”思考或揭示那些需要知道的问题，尤其适合根据实际项目进行定制。建议同时参考ISO 9126质量特性标准或其他相关软件工程标准。

5.1 操作准则

 

 

能力——产品能否执行要求的功能？

可靠性—— 在所有要求的情况下产品均能正常工作并抵御失败吗？

• 错误处理：产品在错误的情况下可抵御失败，失败时能够妥善应对并很容易恢复。

• 数据完整性：产品可防止系统数据的丢失或损坏。

• 安全（Security）：产品可防止未授权用户的访问。

• 保险（Safety）：产品的失败不会造成生命或财产的损失。

可用性—— 产品是否很容易被真实用户使用？

• 易学习性：产品操作可很快被潜在用户掌握。
• 易操作性：产品的操作只需付出很少努力，不会引起混乱。

性能—— 速度和相应能力如何？

可安装性—— 是否能很容易地安装在目标平台上？

 

 

兼容性—— 能否与外部元素和配置协同一致地工作？

• 应用兼容性：产品能够与其他软件产品一起工作。
• 操作系统兼容性：产品可与某种特定操作系统协同工作。
• 硬件兼容性：产品可与某种特定硬件平台元素和配置协同工作。
• 后向兼容性：产品能够与其早期版本协同工作。
• 资源使用：产品不会滥用内存、存储介质或其他系统资源。

5.2 开发准则

 

可支持性—— 产品技术支持工作的经济性如何？

 

可测试性—— 产品测试工作的有效性如何？

 

可维护性—— 产品构建、纠错或功能增强的经济性如何？

可移植性—— 移植或在其他环境下重用产品相关技术的经济性如何？

可定域性—— 以其他语言发布产品的经济性如何？

六、测试技术选择 

• 需求：包括产品元素、质量准则、测试环境和参考资料，从总体上表达了受益人的愿望以及各种资源限制。完整需求的获得决非易事，并随着受益人经验的增加或环境的改变而处于连续变化当中。参考资料是任何可用作需求来源的文档或实体，包括显式参考（由受益人明确指定）和隐式参考（任何其他未指定的有用资料）。

• 定义测试预期：测试预期是用于判定一个测试通过与否的策略，测试的主要任务之一就是根据产品真实需求来确定测试预期，受到测试目标的影响。

• 定制测试模型：根据项目特点构造一个测试模型——描述将采用何种测试方法，以及该方法相配合的测试“覆盖”内容。比如：采用基于风险的测试方法时，同时应制定相应的风险领域列表。在后面罗列一些通用测试技术以供选择使用。

• 选择覆盖范围：确定产品的哪些部分必须被测试，哪些可暂不考虑。

• 配置系统：为测试工作准备产品和平台，确保系统处于开始测试的正确状态。

• 操作系统: 为系统提供必需的输入和控制以执行测试，对于某些测试类型可能需要特殊工具支持。

• 观察系统：监控系统操作过程中的输出或任何其他相关结果。对于哪些隐含变量或微妙结果的观察可能需要特殊工具支持。

• 评估结果：利用测试预期来评估测试结果，需要时执行附加的测试以验证评估。及时反馈评估结果给开发人员，必要时应调整测试计划。

 

附录：通用测试技术

每种测试技术是一种创建测试的方式，其种类难以胜数。以下给出一些简单、实用的通用测试技术，每种技术既可以通过所谓“快速但不洁（quick and dirty）”的方式执行，也可以更为正式地执行，还可以相互结合（比如基于风险的回归测试等）。

 

域测试——依据等价类和边界值对产品不同域测试

1. 确定要测试的域；

2. 分析每个域的限制和特性；

3. 确定要测试的域组合；

4. 应用所选择的测试策略。

例如，穷尽值，典型值，边界值，随机值，非法值。

容量测试——在“超负荷”状态下使用系统

1. 选择要“超负荷”测试的条目和功能；

2. 确定与其相关的数据和平台元素；

3. 选择或生成用来运行测试的具有挑战性的数据和平台配置。

例如，很大或复杂的数据结构，高负载，长时间运行，大量测试用例，低内存条件

线索测试——按照某种逻辑顺序对系统进行测试

1. 定义测试程序或高层测试用例，将多个测试按照一个接一个的方式结合在一起；

2. 不要在测试之间重置系统；

3. 将时间因素考虑进来；

4. 与其它技术结合。

例如，用户线索，容量线索，基于风险的线索。典型情况下，线索测试通过“场景”来定义。所谓“场景”，就是一步一步的详细指令序列，它描述了哪些数据要输入哪些字段，以及要按下什么按钮等。一般应包含：（1）该场景使用的数据描述（2）描述该场景的前提：那些动作必须在之前执行；（3）动作序列描述：如，按下“确认”按钮，在用户号字段内输入456等；（4）预期结果描述；（5）与某功能有关的场景可能要跨越“几天”时间：数据进入系统后可能今天后结果才有效，后续动作也才能执行。“场景”应当覆盖系统所有应完成的功能。

用户测试——模拟真实用户的操作方式、数据

1. 确定用户分类；

2. 确定每一类用户要做什么、如何做以及怎样评价；

3. 获得真实的用户数据，或让真实用户进行测试；

4. 否则，系统化地模拟真实用户的行为（注意：不要误以为自己就是真实用户）。

回归测试——对于变更及影响部分的重复测试

1. 确定哪些产品元素发生变更；

2. 确定哪些元素受到这些变更的影响；

3. 选择测试内容，比如最近修复的错误，以前修复的错误，新代码，敏感代码，或所有代码。

基于风险的测试——依据产品潜在风险的高低确定测试重点，首先发现重大错误

1. 分析测试环境、产品元素和质量准则以确定各种风险源；

2. 将测试集中在具有潜在高风险的领域；

3. 利用测试结果来精练风险分析结果；

4. 注意不要完全忽视低风险领域——因为风险分析结果可能是错误的。

声明测试——验证每一个与产品有关的声明

1. 确定那些包括产品声明（显式的和隐式的）的参考资料；

2. 分析每一个声明，澄清模糊的声明；

3. 验证每个声明；

4. 如果是利用显式的规格说明进行测试，保证它与产品本身保持一致。

探索式测试——在不断探索的过程中（迭代和并发行为）进行测试设计和执行

1. 产品探索，发现和记录产品目标、功能、处理的数据类型和潜在不稳定域；

2. 测试设计，确定产品操作、观察和评估的策略；

3. 测试执行，操作产品，观察结果，并使用这些信息形成产品应如何工作的假设；

4. 启发式规则，利用各种指导性原则帮助决定应做什么；

5. 可评审的结果，探索式测试是一个结果导向的过程，应确保测试结果可被评审以资证明。