• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 软件测试流程

  2007-11-09

  一、概述

   

  一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：

  需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.

   

  在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

  说明：

  1．以上流程各环节并未包含软件测试过程的全部，如根据实际情况还可以实施一些测试计划评审、用例评审，测试培训等。在软件正式发行后，当遇到一些严重问题时，还需要进行一些后续维护测试等。

   

  2．以上各环节并不是独立没联系的，实际工作千变万化，各环节一些交织、重叠在所难免，比如编写测试用例的同时就可以进行测试环境的搭建工作，当然也可能由于一些需求不清楚而重新进行需求分析等。这就和我们国家提出建设有中国特色的社会主义国家一样，只所以有中国特色，那是因为国情不一样。所以在实际测试过程中也要做到具体问题具体分析，具体解决。

   

  二、测试流程

   

  

   

      

  需求分析

   

  需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。

  可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！

   

  一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

   

  其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！

   

  既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。

   

  总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

   

  测试计划

    

  测试计划（Test Plan）一般由测试负责人来编写。

   

     测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：

   

  1．  测试背景

  a.       软件项目介绍；

  b.       项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

  2．  测试依据

  a.       软件需求文档；

  b.       软件规格书；

  c.       软件设计文档；

  d.       其他，如参考产品等。

  3．  测试资源

  a.       测试设备需求；

  b.       测试人员需求；

  c.       测试环境需求；

  d.       其他。

  4．  测试策略

  a.       采取测试方法；

  b.       搭建哪些测试环境；

  c.       采取哪些测试工具以测试管理工具；

  d.       对测试人员进行培训等。

  5．  测试日程

  a.       测试需求分析；

  b.       测试用例编写；

  c.       测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

  6．  其他。

   

  测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

  计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。

   

  测试设计

   

  测试设计主要包括测试用例编写和测试场景设计两方面。

   

  一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

   

  测试场景设计主要也就是测试环境问题了。

   

  测试环境搭建

   

  不同软件产品对测试环境有着不同的要求。如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。

   

  测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。

   

  为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。

   

  测试执行

     　

  测试执行过程又可以分为以下阶段：

   

  单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

   

  从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？

   

  从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：

  1．  当测试人员测试的执行不到位、敷衍了事时该如何解决？

  2．  测试效率问题，怎样提高测试效率？

  3．  根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？

  4．  当测试过程中遇到一些偶然性随机问题该怎样处理？

  5．  当版本中出现很多新问题时该怎样对待？测试停止标准？

  6．  ……

  总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。

   

  测试记录

   

  缺陷记录总的说来包括两方面：由谁提交和缺陷描述。

   

  一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。

   

  在缺陷的描述上，至少要包括以下一些方面内容：

  序号

  标题

  预置条件

  操作步骤

  预期结果

  实际结果

  注释

  严重程度

  概率

  版本

  测试者

  测试日期

   

  以上是描述一个bug时通常所要描述的内容，当然在实际提交bug时可以根据实际情况进行补充，如附上图片、log文件等。

   

  另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。

   

  缺陷管理

   

  缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有Test Director、Bugfree等。

   

  下图是一个bug从提出到close所经过的一些流程，其他比如keep No action\keep spec等一些状态流程都未包含在内，在此仅做示范说明。

   

   

  注：软件缺陷和bug两者在含义上有着细微差别，本文统称缺陷。

   

  软件评估

   

  这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。

  软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。

   

  测试总结

   

  每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成RTM后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。

   

  测试维护

   

     由于测试的不完全性，当软件正式release后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。

  查看(235) 评论(0)

• 软件自动化测试流程

  2007-11-09

  软件自动化测试工具的软件测试流程，不仅仅包含完整的软件测试流程框架，同时还提供了内嵌软件测试流程的测试管理工具的支持，包括完整的测试评测方法。

  1. 软件自动化测试工具软件测试流程框架

        软件自动化测试工具标准流程提供了一套完整的测试流程框架，软件测试团队可以以它为基础，根据业务发展的实际要求，定制符合团队使用的软件测试流程。软件自动化测试工具标准流程中的软件测试流程如图所示：

  

        每个测试环节的具体阐述如下：

  • 制定测试计划的目的是确定和描述要实施和执行的测试。这是通过生成包含测试需求和测试策略的测试计划来完成的。可以制定一个单独的测试计划，用于描述所有要实施和执行的不同测试类型，也可以为每种测试类型制定一个测试计划。
  • 设计测试的目的是确定、描述和生成测试过程和测试用例。
  • 实施测试的目的是实施（记录、生成或编写）设计测试中定义的测试过程。输出工件是测试过程的计算机可读版本，称为测试脚本。
  • 执行测试的目的是确保整个系统按既定意图运行。系统集成员在各迭代中编译并链接系统。每一迭代都需要测试增加的功能，并重复执行以前版本测试过的所有测试用例（回归测试）。
  • 评估测试的目的是生成并交付测试评估摘要。这是通过复审并评估测试结果、确定并记录变更请求，以及计算主要测试评测方法来完成的。测试评估摘要以组织有序的格式提供测试结果和主要测试评测方法，用于评估测试对象和测试流程的质量。

  2. 软件自动化测试工具的评测方法

        软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测，它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象（系统或测试的应用程序）的可靠性、稳定性以及性能的评测，它建立在对测试结果的评估和对测试过程中确定的变更请求（缺陷）分析的基础上。

        2.1覆盖评测

        覆盖指标提供了“测试的完全程度如何？”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测，如用例的核实（基于需求的）或所有代码行的执行（基于代码的）。

  • 基于需求的测试覆盖

        基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和成功的测试覆盖）。 测试覆盖通过以下公式计算：

        测试覆盖 = T^(p,i,x,s) / RfT

        其中：

        T 是用测试过程或测试用例表示的测试 (Test) 数（已计划的、已实施的或成功的）。RfT 是测试需求 (Requirement for Test) 的总数。

  • 基于代码的测试覆盖

        基于代码的测试覆盖评测测试过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。基于代码的测试覆盖通过以下公式计算：

        测试覆盖 = I^e / TIic

        其中：

        I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。TIic (Total number of Items in the code) 是代码中的项目总数。

        2.2质量评测

        测试覆盖的评估提供对测试完全程度的评测，对在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标，所以在这种环境中，缺陷被标识为一种更改请求，该更改请求中的测试对象与需求不符。

  • 缺陷报告

        一般，可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。

  • 性能评测

        评估测试对象的性能行为时，可以使用多种评测，这些评测侧重于获取与行为相关的数据，如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在“评估测试”活动中进行评估，但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。

        主要的性能评测包括：

  • 动态监测 - 在测试执行过程中，实时获取并显示正在执行的各测试脚本的状态。
  • 响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。
  • 百分位报告 - 数据已收集值的百分位评测/计算。
  • 比较报告 - 代表不同测试执行情况的两个（或多个）数据集之间的差异或趋势。

  查看(42) 评论(0)

• 软件测试缺陷报告实用写作技术

  2007-11-09

  提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。由此导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。

  因此，软件测试工程师必须认识到书写软件缺陷报告是测试执行过程的一项重要任务，首先要理解缺陷报告读者的期望，遵照缺陷报告的写作准则，书写内容完备的软件缺陷报告。本文将阐述软件测试缺陷报告的读者，描述软件缺陷报告的主要组成部分和各部分的书写要求，指出某些常见错误和实用改进方法，最后总结了缺陷报告的写作要点。

  1. 缺陷报告的读者对象

  在书写软件缺陷报告之前，需要明白谁是缺陷报告的读者对象，知道读者最希望从缺陷报告中获得什么信息。通常，缺陷报告的直接读者是软件开发人员和质量管理人员，除此之外，来自市场和技术支持等部门的人也可能需要查看缺陷情况。每个阅读缺陷报告的人都需要理解缺陷针对的产品和使用的技术。另外，他们不是软件测试人员，可能对于具体软件测试的细节了解不多。

  概括起来，缺陷报告的读者最希望获得的信息包括：

  • 易于搜索软件测试报告的缺陷；
  • 报告的软件缺陷进行了必要的隔离，报告的缺陷信息更具体、准确；
  • 软件开发人员希望获得缺陷的本质特征和复现步骤；
  • 市场和技术支持等部门希望获得缺陷类型分布以及对市场和用户的影响程度。

  软件测试人员的任务之一就是需要针对读者的上述要求，书写良好的软件缺陷报告。

  2. 缺陷报告的写作准则

  书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。 它也减少了工程师以及其它质量保证人员的后续工作。
  为了书写更优良的缺陷报告，需要遵守“5C”准则：

  • Correct（准确）：每个组成部分的描述准确，不会引起误解；
  • Clear（清晰）：每个组成部分的描述清晰，易于理解；
  • Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
  • Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
  • Consistent（一致）：按照一致的格式书写全部缺陷报告。

  3. 缺陷报告的组织结构

  尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是基本组织结构都是大同小异的。一个完整的软件缺陷报告通常由下列几部分组成：

  • 缺陷的标题；
  • 缺陷的基本信息；
    • 测试的软件和硬件环境；
    • 测试的软件版本；
    • 缺陷的类型；
    • 缺陷的严重程度；
    • 缺陷的处理优先级。
  • 复现缺陷的操作步骤；
  • 缺陷的实际结果描述；
  • 期望的正确结果描述；
  • 注释文字和截取的缺陷图像。

  对于具体测试项目而言，缺陷的基本信息通常是比较固定的，也是很容易描述的。实际书写软件缺陷报告容易出现问题的地方就是标题、操作步骤、实际结果、期望结果和注释部分。下面针对这些“事故多发地带”具体论述如何提供完整的信息，由于英文是软件开发的主要语言，以下的软件缺陷报告的信息都使用英文书写。

  4. 缺陷报告的写作技术

  4.1 标题（Title）

  标题应该保持简短、准确，提供缺陷的本质信息，并且便于读者搜索查寻。

  良好的缺陷标题应该按照下列方式书写：

  • 尽量按缺陷发生的原因与结果的方式书写（“执行完A后，发生B，”或者“发生B，当A执行完后”）；
  • 避免使用模糊不清的词语，例如“功能中断，功能不正确，行为不起作用，”等。应该使用具体文字说明功能如何中断，如何不正确，或如何不起作用；
  • 为了方便搜索和查询，请使用关键字；
  • 为了便于他人理解，避免使术语、俚语或过分具体的测试细节。

  请查看下面的表格，该表格列出了有问题的标题，给出了如何改进的示例。

  原始描述	错误原因	改进的标题
  Hyphenation does not work	描述太笼统。什么时候不起作用？	Text breaks at line's end, but no hyphen appears
  Incorrect behavīor with paragraph alignment	描述太笼统。不正确的行为是什么？	Justified alignment leaves gaps in text composition when tracking is also applied
  Assert:CmdAssertHereInsertSomethingBad-Happens	没有包含原因与结果信息。断言（Assert）太长。	Assert, "SomethingBad" when attempting to update linked bitmap stored on server
  After each launch then clicking edit and then copy/paste, there is too much delay	没有指明原因与结果，包含了过分详细的细节信息。	Performance slows noticeably after ?rst launch and copy/paste
  Quotes appear as symbols when they are imported	信息没有充分隔离。所有的引号都如此吗？什么类型的符号？	Imported smart quotes from Word appear as unrecognized characters

  提示

  使用"after"，"when"或"during"等连结词有助于描述缺陷的原因和结果，例如：

  • Application crashes after input any letters in numeric field.
  • Internal error occurs when closing application.
  • Application suspended during email transmission."

  4.2 复现步骤（Reproducible Steps）

  复现步骤包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。

  但是实际软件测试过程中，总是存在一些不良的缺陷报告，主要的问题在于以下三个方面：

  • 复现步骤包含了过多的多余步骤，而且句子结构混乱，可读性很差，难于理解；
  • 复现步骤包含了过少的信息，丢失操作的必要步骤。由于提供的步骤不完整，开发人员经常需要种种猜测，努力尝试复现的步骤，浪费了大量时间。由于缺少关键步骤，这些缺陷通常被工程师以“不能复现”为由再次发送给测试人员；
  • 测试人员没有对软件缺陷发生的条件和影响区域进行隔离，软件开发人员无法判断该缺陷影响的软件部分，不能进行彻底修正。

  为了避免出现这些问题，良好的复现步骤应该包含本质的信息，并按照下列方式书写：

  • 提供测试的预备步骤和信息；
    • 环境变量。例如，如果默认项或预设、调试版本或发布版本等存在问题，请指明使用的操作系统和应用程序的环境变量；
    • 设置变量：指明哪种打印机、字体或驱动程序是复现Bug所必需的信息；
    • 复现路径。如果有多种方法触发该缺陷，请在步骤中包含这些方法。同样地，如果某些路径不触发该缺陷，也要包含这些路径。
  • 简单地一步一步地引导复现该缺陷；
  • 每一个步骤尽量只记录一个操作；
  • 每一个步骤前使用数字对步骤编号；
  • 尽量使用短语和短句，避免复杂句型和句式；
  • 复现的操作步骤要完整，准确，简短；
  • 没有缺漏任何操作步骤；
  • 每个步骤都是准确无误的；
  • 没有任何多余的步骤；
  • 将常见步骤合并为较少步骤，例如：

    1. Create text frame.
    2. Add text.

  可以简单的合并成一步：

  1. Create a new text frame and add text.

  • 只记录各个操作步骤是什么，不要包括每个操作步骤执行后的结果

  需要再次引起注意的是，缺陷报告的读者对技术有基本的了解，但是对软件测试的细节可能所知有限。因此，一方面，没有必要在缺陷报告中告诉启动产品或者如何打开一个文件等简单操作方法。另一方面，不要包含软件测试过分详细的技术细节，除非这些是缺陷至关重要的信息。

  4.3 实际结果（Actual result）

  实际结果是执行复现步骤后软件的现象和产生的行为。

  实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。

  如果一个动作产生彼此不同的多个缺陷结果。为了易于阅读，这些结果应该使用数字列表分隔开来。例如：

  Actual result:

  1. Assert “CmdLineofCodeHere…”
  2. Assert “AlsoBrokenHere…”

  有时，一个动作将产生一个结果，而这个结果又产生另一个结果。这种情况可能难以清晰、简洁地总结。例如：

  Actual Result：

  1. Assert:“CmdLineofCodeBlahBlah…”
  2. When this assert is dismissed, app becomes active but all text is unrecognizable.
  3. After selecting the text by dragging the text tool, the text appears normally once again.

  对于这些较难处理的情况，有多种使之易于阅读的解决方法：

  • 尽可能将缺陷分解成多个缺陷报告，并使用交叉引用说明彼此之间的联系。这些动作的结果通常比较相似但缺陷不同。首先进行更多的隔离测试，缩小产生缺陷的范围，查看是否产生多个缺陷；
  • 在实际结果部分，仅列出缺陷的一到两个表现特征。使用注释（Notes）部分列出缺陷的其它问题；
  • 在缺陷的第一个表现特征后，将随后的步骤和缺陷表现特征移到注释部分。重要的信息几乎总是包含在第一个断言或错误里，其它错误都是第一个错误的变种。

  4.4 期望结果（Expected result）

  期望结果的描述应该与实际结果的描述方式相同。通常需要列出期望结果的应该是什么，并且给出期望结果的原因，可能是引用的规格说明书、前一版本的表现行为、客户一般需求、排除杂乱信息的需要等等。

  为了更清楚地理解良好的期望结果应该包含什么信息，请看下面的例子：
  
  Expected result：

  The text that appears should be fully highlighted so that if the user wishes to make changes, they don’t have to manually highlight and then type (as in Mac OS 10.x and Windows behavīor.)

  为什么说这个例子很好呢？因为它包含了如下内容：

  • 应该产生的正确现象：The text that appears should be fully highlighted
  • 为什么应该产生：…so that if the user wishes to make changes, they don’t have to manually highlight and then type.
  • 给出了具体得参考对象：As in OS 10.x and Windows behavīor.

  4.5 注释（Notes）

  注释应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。

  注释部分可以包含以下各方面的内容：

  • 截取缺陷特征图像文件（Screenshots）；
  • 测试过程需要使用的测试文件；
  • 测试附加的打印机驱动程序；
  • 再次描述重点，避免开发人员将缺陷退回给测试人员补充更多信息；
  • 再次指明该缺陷是否在前一版本已经存在；
  • 多个平台之间是否具有不同表现；
  • 注释包含缺陷的隔离信息，指出缺陷的具体影响范围。

  例如，缺陷的注释可能包含下面的内容：

  Notes：

  1. Text displays outside frame in Win2000 and WinXP, but not Win98.
  2. Does not happen after screen has redrawn.
  3. Does not occur when two documents are open.
  4. Refer to attached screenshots and testing file

  5. 缺陷报告的写作注意事项

  提高缺陷报告的写作水平是不断积累经验，循序渐进的过程。在正式提交缺陷报告前，请对缺陷报告的内容和格式进行自我检查，避免很多不必要的错误。

  5.1 自我检查和提问

  • 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
  • 一个缺陷报告中是否之报告了一种缺陷？
  • 读者是否能容易的搜索该缺陷？
  • 步骤是否可以完全复现而且表达清楚吗？
  • 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
  • 缺陷的标题是按照原因与结果的方式书写的吗？
  • 实际结果和期望结果是否描述不够清楚而容易引起歧义吗？

  5.2 避免常见的错误

  • 使用“I（我）”、“You（你）”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替；
  • 使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽；
  • 使用诸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含义模糊的词汇，而需要报告确定的缺陷结果；
  • 包含认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可；
  • 将不确定的测试问题（Issues）放在缺陷管理数据库中。如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性。

  查看(41) 评论(0)

• 界面测试

  2007-11-09

  界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
  　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
  1：易用性：
  　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
  易用性细则：
  1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
  2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
  3):按功能将界面划分区域块，用Frame框括起来,并要有功能说明或标题。
  4):界面要支持键盘自动浏览按钮功能，即按Tab键、回車鍵的自动切换功能。
  5):界面上首先要输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
  6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
  7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
  8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。

  9):可寫控制項檢測到非法輸入後應給出說明並能自動獲得焦點。
  10):Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
  11):核取方塊和選項框按選擇幾率的高底而先後排列。
  12):核取方塊和選項框要有默認選項，並支援Tab選擇。
  13):選項數相同時多用選項框而不用下拉清單框。
  14):界面空间较小时使用下拉框而不用选项框。
  15):选项数較少时使用选项框，相反使用下拉列表框。
  16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词语。
  2： 规范性：
  通常界面设计都按Windows界面的规范来设计，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
  规范性细则：
  1):常用菜单要有命令快捷方式。
  2):完成相同或相近功能的菜单用横线隔开放在同一位置。
  3):菜单前的图标能直观的代表要完成的操作。
  4):菜单深度一般要求最多控制在三层以内。
  5):工具栏要求可以根据用户的要求自己选择定制。
  6):相同或相近功能的工具栏放在一起。
  7):工具栏中的每一个按钮要有及时提示信息。
  8):一条工具栏的长度最长不能超出屏幕宽度。
  9): 工具栏的图标能直观的代表要完成的操作。
  10):系统常用的工具栏设置默认放置位置。
  11):工具栏太多时可以考虑使用工具箱。
  12):工具箱要具有可增减性，由用户自己根据需求定制。
  13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
  14): 状态条要能显示用户切实需要的信息，常用的有：
  目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
  15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
  16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
  17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
  18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
  19): 右键快捷菜单采用与菜单相同的准则。
  3：帮助设施：
  系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
  帮助设施细则：
  1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
  2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
  3)：操作时要提供及时调用系统帮助的功能。常用F1。
  4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
  5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
  6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
  7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
  8)：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。

  4：合理性：
  屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
  合理性细则：
  1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
  2)：子窗体位置应该在主窗体的左上角或正中。
  3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
  4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
  5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点击的位置。横排开头或最后与竖排最后为易点位置。
  6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
  7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
  8)：非法的输入或操作应有足够的提示说明。
  9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
  10): 提示、警告、或错误说明应该清楚、明了、恰当。
  5：美观与协调性：
  界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
  美观与协调性细则：
  1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
  2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
  3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
  4): 按钮的大小要与界面的大小和空间要协调。
  5): 避免空旷的界面上放置很大的按钮。
  6)：放置完控件后界面不应有很大的空缺位置。
  7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
  8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
  9): 如果使用其他颜色，主色调要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
  10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
  11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
  12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
  13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
  14): 通常父窗体支持缩放时，子窗体没有必要缩放。
  15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
  6：菜单位置：
  菜单是界面上最重要的元素，菜单位置按照按功能来组织。
  菜单测试细则：
  1): 菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
  2): 常用的有“文件”、“編輯”，“查看”等，幾乎每個系統都有這些選項，當然要根據不同的系統有所取捨。
  3): 下拉菜单要根据菜单选项的含义进行分组，並且按照一定的规则进行排列，用横线隔开。
  4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
  5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
  6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
  7): 菜单深度一般要求最多控制在三层以内。
  8): 对常用的菜单要有快捷命令方式，组合原则见8。
  9): 对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
  10): 菜单前的图标不宜太大，与字高保持一直最好。
  11): 主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
  12): 主菜单数目不应太多，最好为单排布置。

  13):菜单条是否显示在合适的语境中？

  14):应用程序的菜单条是否显示系统相关的特性（如时钟显示）？

  15):下拉式操作能正确工作吗？

  16):菜单、调色板和工具条是否工作正确？

  17):是否适当地列出了所有的菜单功能和下拉式子功能？

  18):是否可能通过鼠标访问所有的菜单功能？

  19):相同功能按钮的图标和文字是否一致？

  20):是否能够用其他的文本命令激活每个菜单功能？

  21):菜单功能是否随当前的窗口操作加亮或变灰？

  22):菜单功能是否正确执行？

  23):菜单功能的名字是否具有自解释性？

  24):菜单项是否有帮助，是否语境相关？

  25):在整个交互式语境中，是否可以识别鼠标操作？

  26):如果要求多次点击鼠标，是否能够在语境正确识别？

  27):如果鼠标有多个按钮，是否能够在语境中正确识别？

  28):光标、处理指示器和识别指针是否随操作恰当地改变？        
  7:独特性：
  如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
  测试细则：
  1):　安装界面上应有单位介绍或产品介绍，并有自己的图标。
  2):　主界面，最好是大多数界面上要有公司图标。
  3):　登录界面上要有本产品的标志，同时包含公司图标。
  4):　帮助菜单的“关于”中应有版权和产品信息。
  5):　公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。

  8：快捷方式的组合
  在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些在西文Windows及其应用软件中快捷键的使用大多是一致的。
  菜单中：
  1):面向事务的组合有:
  Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl –H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。
  2)：列表:
  Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
  3):编辑:
  Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
  4)文件操作:
  Ctrl-P 打印；Ctrl-W 关闭。
  5):系统菜单
  Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
  6):MS Windows保留键:
  Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作；Shift-F1 上下文相关帮助。
  按钮中：
  可以根据系统需要而调节，以下只是常用的组合。
  Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
  这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
  9:安全性考虑：
  在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
  安全性细则：
  1)：最重要的是排除可能会使应用非正常中止的错误。
  2)：应当注意尽可能避免用户无意录入无效的数据。
  3)：采用相关控件限制用户输入值的种类。
  4)：当用户作出选择的可能性只有两个时,可以采用单选框。
  5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
  6)：当选项特别多时，可以采用列表框，下拉式列表框。
  7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
  8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
  9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
  10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
  11)：对错误操作最好支持可逆性处理，如取消系列操作。
  12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
  13):对可能造成等待时间较长的操作应该提供取消功能。
  14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!
  ,.。?/还有空格。
  15)：与系统采用的保留字符冲突的要加以限制。
  16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
  17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
  10:多窗口的应用与系统资源：
  设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
  1)：在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
  2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
  3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
  4)：尽量防止对系统的独占使用。

  5)：窗口能否基于相关的输入或菜单命令适当地打开？

  6)：窗口能否改变大小、移动和滚动？

  7)：窗口中的数据内容能否使用鼠标、功能键、方向箭头和键盘访问？

  8)：当被覆盖并重调用后，窗口能否正确地再生？

  9)：需要时能否使用所有窗口相关的功能？

  10)：所有窗口相关的功能是可操作的吗？

  11)：是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口可用，并适当地显示？

  12)：显示多个窗口时，窗口的名称是否被适当地表示？

  13)：活动窗口是否被适当地加亮？

  14)：如果使用多任务，是否所有的窗口被实时更新？

  15)：多次或不正确按鼠标是否会导致无法预料的副作用？

  16)：窗口的声音和颜色提示和窗口的操作顺序是否符合需求？

  17)：窗口是否正确地关闭？

  查看(19) 评论(0)

• 常用的功能测试方法

  2007-11-09

    功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
  1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
  2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
  3. 检查按钮的功能是否正确：如update, cancel, delete, SAve等功能是否正确。
  4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
  5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
  6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
  7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
  8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致。
  9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
  10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
  11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
  12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
  13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
  14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
  15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
  16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
  17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
  18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*。
  19. 快捷键检查：是否支持常用快捷键，如Ctrl+C Ctrl+V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
  20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.
  （smartbaby）
  网友回复：
  你所寫的有點近似乎測試用例,不過不同的產品有不同的測試意用,我個人覺得,站在黑盒測試的角度來說,應主要盡可能的貼近用戶的角度去測試,把自己看做是一位挑剔的用戶,並持"這個產品是世界上最差的,我要在雞骨頭裡挑出刺來"的心理去從事這項工作,要認真,且須有強烈的責任心,隻有這樣才能把測試做好。（johnnedy_angel）
  如果是想做好测试，当然要从不同的角度来想和进行测试。站在用户的角度是其中的一个方面啊～^_^
  两者没有任何冲突的。
  前面这个文章的目的只是为了给无从下手的人一个小小的建议和参考方法～
  大家可以一起讨论来让它更丰满，更充实啊～～ （smartbaby） 
  文章中都是些很具体实用的东西 不错啊！:)
  johnnedy_angel——“這個產品是世界上最差的,我要在雞骨頭裡挑出刺來" ～～～      值得学习的观念啊……;) （ting_yt2）
  补充：搂主总结的很好也很全面，不过我这儿还有一点点上面没有写到的，我来补充上。
  1：web测试的一般都会提供翻页功能，对可以选择增加的页面，要多增加一   些 记录，保证第二页以后的数据也可以选择增加。
  2：对系统间相互引用的数据，要注意之间的先后关系，及增删改对数据的影响，对应的位置应该有的变化。例如：系统1增加的数据，系统2要引用，在2的操作没有完成之前，1中备2引用的数据就不能删除，同时，一中相应的修改，也应该体现在2中，或者由时间来控制是否体现。（panda）
  总结的真不错，特别适用b/s结构系统的测试，也特别适合刚做测试工作的新手！
  在下补充几小点：
  第6条标点符号检查，还要包括常用的特殊中英文字符的检查，如$ &AMp; ￥ 等
  第10条检查删除功能，还要检查在进行删除操作时，一定要有确认删除的提示信息。
  第17条上传下载文件检查，对上传下载的文件名也要进行检查，有时下载下来的文件名是乱码。 （annie）
  写的虽然不是很全,但是很细哦,值得学习.
  补充一点:
  查询条件的选择,查询后条件栏是否产生乱码,查询信息是否正确
  翻页中页码,或者翻页按钮,还有enter键
  信息的排序等（luckhj）
  想到几点补充 ,说的不对请指正 !
  1 对于控件的话要检测控件显示出的内容是否正确,那些无效的的或者禁用的是否也显示出来了 .
  2对于日期也要注意,开始日期绝对不可以在截止日期后面,还有日期的格式,我们公司是用日期的控件来解决这个问题的  .
  3还有就是汇总的数据问题,是否计算正确 .
  4数据的测试,例如计算数据是按小数点两位的还是小数点四位的, 页面上显示的为小数点几位. 还有金额数据关于千分位的问题 

  查看(27) 评论(0)

• 软件测试技术研究

  2007-11-09

  一、软件测试
  1、软件测试的目的
  软件测试是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，它是软件质量保证的关键步骤。测试要求以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。
    软件测试的目的决定了如何去组织测试。如果测试的目的是为了尽可能多地找出错误，那么测试就应该直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测试目的是为了给最终用户提供具有一定可信度的质量评价，那么测试就应该直接针对在实际应用中会经常用到的商业假设。这里引用Grenford J. Myers在《The Art of Software Testing》一书中的观点：
  　　①、软件测试是为了发现错误而执行程序的过程；
  　　②、测试是为了证明程序有错，而不是证明程序无错误。
  　　③、一个好的测试用例是在于它能发现至今未发现的错误；
  　　④、一个成功的测试是发现了至今未发现的错误的测试。
  软件测试是一项细致并需要高度技巧的工作，稍有不慎就会顾此失彼，发生不应有的疏漏。软件工程的总目标是充分利用有限的人力和物力资源，高效率、高质量地完成测试。为了降低测试成本，选择测试用例时应注意遵守"经济性"的原则。
  
  2、软件测试的分类
  从测试的类型来看，测试分为2种：黑盒测试和白盒测试。
  黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
  白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。
    从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。
  单元测试针对每个模块进行的测试，通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。集成测试在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。确认测试验证软件的功能和性能及其它特性是否与用户的要求一致，系统测试是在实际运行环境下进行一系列的测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的
  
  3、软件测试工作的流程：
  
  测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性地检测方法，改善测试的有效性。
  
  没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。由此可见，软件测试工作应该贯穿于整个软件开发阶段。
  
  下面是软件测试工作的总体流程图和每个主要阶段的流程图：
  
  
  二、单元测试
  
  1、 什么是单元测试
  单元测试是在软件开发过程中要进行的最低级别的测试活动，测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。
  　　在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中，要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。
  　　单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。
  　　经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。
  
  2、单元测试任务　
  　单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。
  　　模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：
  　　1 输入的实际参数与形式参数的个数是否相同；
  　　2 输入的实际参数与形式参数的属性是否匹配；
  　　3 输入的实际参数与形式参数的量纲是否一致；
  　　4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；
  　　5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；
  　　6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；
  　　7 调用预定义函数时所用参数的个数、属性和次序是否正确；
  　　8 是否存在与当前入口点无关的参数引用；
  　　9 是否修改了只读型参数；
  　　10 对全程变量的定义各模块是否一致；
  　　11是否把某些约束作为参数传递。
  如果模块内包括外部输入输出，还应该考虑下列因素：
  　　1 文件属性是否正确；
  　　2 OPEN/CLOSE语句是否正确；
  　　3 格式说明与输入输出语句是否匹配；
  　　4缓冲区大小与记录长度是否匹配；
  　　5文件使用前是否已经打开；
  　　6是否处理了文件尾；
  　　7是否处理了输入/输出错误；
  　　8输出信息中是否有文字性错误；
  
  检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：
  　　1 不合适或不相容的类型说明；
  　　2变量无初值；
  　　3变量初始化或省缺值有错；
  　　4不正确的变量名（拼错或不正确地截断）；
  　　5出现上溢、下溢和地址异常。
  　　除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。
  　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：
  　　1 误解或用错了算符优先级；
  　　2混合类型运算；
  　　3变量初值错；
  　　4精度不够；
  　　5表达式符号错。
  　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误：
  　　1不同数据类型的对象之间进行比较；
  　　2错误地使用逻辑运算符或优先级；
  　　3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；
  　　4比较运算或变量出错；
  　　5循环终止条件或不可能出现；
  　　6迭代发散时不能退出；
  　　7错误地修改了循环变量。
  　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：
  　　1输出的出错信息难以理解；
  　　2记录的错误与实际遇到的错误不相符；
  　　3在程序自定义的出错处理段运行之前，系统已介入；
  　　4异常处理不当；
  　　5错误陈述中未能提供足够的定位出错信息。
  边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。
  
  3、单元测试的过程与环境
  　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。
  　　应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为"主程序"，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，"主程序"打印"进入-退出"消息。
  　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。
  　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。
  
  
  
  
  三、集成测试的基本方法
  
    时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。　
  　某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。
  下面讨论两种增量式集成方法。
  1、自顶向下集成　　
  自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。　　
  自顶向下综合测试的具体步骤为：　　
  1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；　　2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；　　3 每集成一个模块立即测试一遍；　　4 只有每组测试完成后，才着手替换下一个桩模块；　　5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。　　 从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。　
  　自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。
  
  2、自底向上集成　　
  自底向上测试是从"原子"模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。　　
  自底向上综合测试的步骤分为：　　
  1 把低层模块组织成实现某个子功能的模块群（cluster）;　　2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；　　3 对每个模块群进行测试；　　4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。　　从第一步开始循环执行上述各步骤，直至整个程序构造完毕。　　下图说明了上述过程。首先"原子"模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。
     
  自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。
  　　此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：①对应几条需求；②具有高层控制功能；③复杂、易出错；④有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。
  
  四、确认测试的基本方法
  
  
  通过集成测试之后，软件已完全组装起来，接口方面的错误也已排除，确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
  
  1. 确认测试标准　　实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。　　确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
  2. 配置复审　　确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。
  3. α、β测试　　事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列"验收测试"。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。　　α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
  
  五、系统测试的基本方法
  
  计算机软件是基于计算机系统的一个重要组成部分，在系统测试之前，软件工程师应完成下列工作：　　
  为测试软件系统的输入信息设计出错处理通路；　
  设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；　　
  参与系统测试的规划和设计，保证软件测试的合理性。　　
  系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。
  下面简单讨论几类系统测试。
  １、恢复测试　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
  ２、安全测试　　安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
  ３、强度测试　　强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
  ４、 性能测试　　对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。
  
  六、软件测试自动化的一些具体做法
  因为软件测试的工作量很大（40% 到60% 的总开发时间），而又有很大部分适于自动化，因此，测试的改进会对整个开发工作的质量、成本和周期带来非常显著的效果。　　
  　 下面举出一些测试自动化的例子：
  1.   测试个案（test case ，或称为测试用例）的生成　　
  用编程语言或更方便的剧本语言（scrīpt language 例如Perl等）写出短小的程序来产生大量的测试输入（包括输入数据与操作指令）。或同时也按一定的逻辑规律产生标准输出。输入与输出的文件名字按规定进行配对，以便控制自动化测试及结果核对的程序易于操作。　　这里提到测试个案的命名问题，如果在项目的文档设计中作统一规划的话，软件产品的需求与功能的命名就应该成为后继开发过程的中间产品的命名分类依据。这样，就会为文档管理和配置管理带来很大的方便，使整个产品的开发过程变得更有条理，更符合逻辑。任何新手半途加入到开发工作中也会更容易进入状态。
  2.   测试的执行写控制　　
  单元测试或集成测试可能多用单机运行。但对于系统测试或回归测试，就极有可能需要多台机在网络上同时运行。记住一个这样的原则，在开发过程中的任何时候，如果你需要等候测试的运行结果的话，那就是一个缩短开发时间的机会。对于单个的测试运行，挖潜的机会在测试的设置及开始运行和结果的对比及显示。有时候，需要反复修改程序，重新汇编和重新测试。这样，每一个循环的各种手工键入的设置与指令所花费的时间，加起来就非常可观。如果能利用make或类似的软件工具来帮助，就能节省大量的时间。 对于系统测试或回归测试这类涉及大量测试个案运行的情况，挖潜的的机会除了利用软件工具来实现自动化之外，就是怎样充分利用一切硬件资源。往往，就算是在白天的工作时间内，每台计算机的负荷都没有被充分利用。能够把大量测试个案分配到各台机器上去同时运行，就能节省大量的时间。另外，把大量的系统测试及回归测试安排到夜间及周末运行，更能提高效率。如果不购买商品化的工具的话，应当遵从正规的软件开发要求来开发出好的软件测试自动化工具。在实践中，许多企业自行开发的自动化工具都是利用一些现成的软件工具再加上自己写的程序而组成的。这些自己开发的工具完全是为本企业量身定做的，因此可用性非常强。同时，也能根据需要随时进行改进，而不必受制于人。在设计软件自动测试工具的时候，路径（path）控制是一个非常重要的功能。理想的使用情况是：这个工具可以在任何一个路径位置上运行，可以到任何路径位置去取得测试用例，同时也可以把测试的结果输出放到任何的路径位置上去。这样的设计，可以使不同的测试运行能够使用同一组测试用例而不至于互相干扰，也可以灵活使用硬盘的空间，并且使备份保存工作易于控制。同时，软件自动测试工具必须能够有办法方便地选择测试用例库中的全部或部分来运行，也必须能够自由地选择被测试的产品或中间产品采作为测试对象。
  3.   测试结果与标准输出的对比　
  　 在设计测试用例的时候，必须考虑到怎样才能够易于对此测试结果和标准输出。输出数据量的多少及数据格式对比较的速度有直接影响。而另一方面，也必须考虑到输出数据与测试用例的测试目标的逻辑对应性及易读性，这将会大大有利于分析测试所发现的不吻合，也有利于测试用例的维护。　　许多时候，要写一些特殊的软件来执行测试结果与标准输出的对比工作，因为可能有部分的输出内容是不能直接对比的（比如，对运行的日期时间的记录，对运行的路径的记录，以及测试对象的版本数据等），就要用程序进行处理。
  4.   不吻合的测试结果的分析、分类、记录和通报　　
  上一点所谈到的，用于对测试结果与标准输出进行对比的特殊软件，往往也同时担任对不吻合的测试结果进行分析、分类、记录和通报的任务。"分析"是找出不吻合的地方并指出错误的可能起因。"分类"包括各种统计上的分项，例如，对应的源程序的位置，错误的严重级别（提示、警告、非失效性错误、失效性错误；或别的分类方法），新发现的还是已有记录的错误，等等。"记录"，是按分类存档。"通报"，是主动地对测试的运行者及测试用例的"负责人"通报出错的信息。　　 这里提到测试用例的"负责人"的概念。是用以指定一个测试用例运行时发现的缺陷，由哪一个开发人员负责分析（有时是另外的开发人员引进的缺陷而导致的错误）及修复。在设立测试用例库时，各用例均应有指定的负责人。　　最直接的通报方法是由自动测试软件发出电子邮件给测试运行者及测试用例负责人。邮件内容的详细程度可根据需要灵活决定。
  5.   总测试状况的统计，报表的产生　　
  
  这些都是自动测试工具所应有的功能。目的是提高过程管理的质量，同时节省用于产生统计数据的时间。产生出来的统计报表，最好是存放到一个约定的路径位置，以便任何有关人员都知道怎样查阅。同时，可按需要用电子邮件向适当的对象（如项目经理，测试经理和质量保证经理）寄出统计报表。

  查看(26) 评论(0)

• 黑盒测试的测试用例设计方法

  2007-11-09

  目前黑盒测试的测试用例设计方法有5种：

  1. 等价类划分
  2. 边界值分析
  3. 错误推测法
  4. 因果图
  5. 功能图

  一、等价类划分

  等价列划分设计方法是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少量具有代表性的数据作为测试用例。

  等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其他值的测试。

  等价类划分有两种不同的情况：有效等价类和无效等价类。设计时要同时考虑这两种等价类。

  下面给出6条确定等价类的原则：

  1. 在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
  2. 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。
  3. 在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。
  4. 在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。
  5. 在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。
  6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

  在确立了等价类后，可建立等价类表，列出所有划分出的等价类。然后从划分出的

  等价类中按以下的3个原则设计测试用例：

  • 为每一个等价类规定一个唯一的编号
  • 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止。
  • 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

  例：程序规定；输入三个整数作为三边的边长构成三角形。当此三角形为一般三角形、等腰三角形、等边三角形时，分别作计算。用等价类划分方法为该程序进行测试用例设计。

  解：设a、b、c代表三角形的三条边。

  1）分析题目中给出的和隐含的对输入条件的要求：

  a) 整数
  b) 3个数
  c) 非零数
  d) 正数
  e) 两边之和大于第三边
  f) 等腰
  g) 等边

  2）列出等价类表并编号

  
  
  3）列出覆盖上述等价类的测试用例，如下表：