测试工程师的工作流程，与公司的整体工作流程，项目的测试要求等因素相关。本文主要讨论测试工程师的一般工作流程。

做好测试准备

1)明确测试任务的范围

测试文档通常包括测试目的、测试环境、测试方法、测试用例、测试工具等。测试工程师首先要通读文档，对整个测试要求形成整体认识，明确测试目的，以及测试要求和测试重点，明确软件测试方法和使用的测试工具。

2)明确测试时间

明确测试周期和测试时间进度。如果是多人合作完成一个软件，则要首先明确属于自己的测试内容、根据测试内容和测试周期，估算自己每日应该完成的工作量。此外由于软件测试是群体协作的测试活动，需要明确哪些测试内容要与其他测试工程师协作才能完成。

3)设置测试环境

根据测试文档要求，设置测试需要的软件和硬件环境，包括操作系统，要测试的软件和其他必要的测试工具软件等。所有这些完成后，分别运行，查看是否能正确运行，保证符合测试文档要求的测试环境。

4)学习被测试软件

对于不太熟悉的软件，可以通过阅读软件自身的教程和帮助文件，学习本软件的一般操作方法，也可以参照相关的书籍资料等。另外，向熟悉测试软件的其他同事请教软件使用方法，也是学习软件的一条捷径。对软件使用越熟练，测试过程越顺利，测试效果越理想。

5)确认完全理解测试任务

软件测试最重要的要求就是确实明确了测试任务和要求，这包括正确理解了测试文档，确认可以按照测试进度要求，完成测试。对于测试工具要正确安装，熟练使用。如果有任何不明白之处，向软件测试负责人询问。切忌凭自己的理解和主观推测，自行其事。当然，真正测试中，往往会遇到各种新的小疑难问题，也需要及时向测试负责人请教，以保证测试顺利进行。

执行软件测试任务

1)按照测试文档要求，逐项认真测试

根据测试文档测试要求，按照测试步骤，逐项进行。通过运行软件，观察测试结果，与软件需求说明书的内容进行比较，找出软件错误。对于需要调用测试用例的测试，保证正确地调用了测试用例，注意观察和分析测试结果。某些不容易重复的错误，需要反复测试，总结重复该错误所需要的测试步骤，直到确认可以重复出现为止。

2)记录发现的错误，填写软件问题报告

为了纠正软件中的错误，测试工程师要正确记录发现的错误，将错误再现的步骤写入测试报告中，测试报告是程序测试的重要组成部分，正确书写测试报告是对测试工程师的基本要求。采用软件缺陷数据库管理测试中发现的软件缺陷，每一条错误作为数据库的一条记录，方便记录、修改、查询。

3)填写测试进度表和必要的测试内容记录表

每天将测试内容写入测试进度表文档，可以使测试负责人了解测试进度，控制测试周期内测试的连续性，增强测试过程控制性，保证测试的正常进行。测试记录要准确完整，实事求是，必要时插入测试注释，解释测试中的特殊问题。测试进度表是评价测试质量和工作内容的重要凭证，对于测试后发现的测试错误和失误，可以通过检查测试记录，寻找产生错误的原因。

4) 测试中发现疑难及时请教

测试是一个动态的过程，可能由于自己的错误操作或者测试文档内容的错误，使得测试过程中出现自己不能解释的现象或结果，出现与测试要求不符合的情形，这时可能需要与其他测试者协商或求助，如果问题仍然不能解决，应该及时请教，听取意见和建议，必要时反复讨论直到问题全面解决。

全面检查测试结果

1)对照测试文档要求，检查测试内容是否完整

测试完成后，要对照测试文档检查测试是否全部完成，保证没有丢失测试内容。如果某些内容，由于测试环境的要求不满足，或者由于测试时间短没有进行，则要写入测试进度表文档。

2)检验书写的软件问题报告的记录，使之确切、规范

正确书写测试记录是保证迅速定位软件错误，加快改正错误的必要前提。专业规范的软件记录报告是体现公司测试水平和专业实力的外在体现。认真检查书写的每条记录是否符合规范，格式、步骤、内容一一检查，必要时补充或删减。

上述三个阶段，相互联系紧密，其中准备是基础，测试是重点，检查是保证，应该根据测试的软件特点合理安排。

一、六大经验

      迭代式开发。在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。

      管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。

      基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

       可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。

      验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。

      控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。

二、统一软件开发过程RUP的二维开发模型

　　RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle)、阶段(Phase)、迭代(Iteration)和里程碑(Milestone)；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动(Activity)、产物(Artifact)、工作者(Worker)和工作流(Workflow)。如图1：

我们每个人，不会都是软件测试人员，但都是某些软件的用户。缺省或默认情况下，用户都会觉得买到的软件是没有问题的，一般不会去想这样的软件可能会有问题，用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现问题的时候，甚至会感到震惊。存在的问题很多都和测试的成效有关系，一般的软件产品存在的问题确实比较少，但我觉得即使是以前买的正版的金山快译2000都有着一些显而易见的bug。如果测试不充分，那么这些问题会潜伏在软件中，等到用户发现以后，再有开发人员进行维护，改正错误的费用一般是开发阶段的40倍到60倍。

人们对测试存在着一些误区，例如：
1 测试是想象到可能出现的问题，然后试图验证这些问题。
实际上能想象到的只是一部分的情况，随意性太大，还要取决于开发人员的经验，对业务的熟悉程度和他想象到的程度。
2 让时间有富裕的员工去做一些测试
表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。
3 测试是相对简单的工作。
实际上并非如此，要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题，也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。

测试的基本知识

让我们一起快速过一遍：

什么是软件测试：在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
测试的目标：以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。
从测试的类型来看，测试分为2种：黑盒测试和白盒测试。
黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。
白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。
测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直接决定了测试的效果和结果。
从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的。

单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。
集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。
确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。
系统测试：将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。

测试工作的文档主要有：测试计划、测试模型和用例设计或规格说明、测试分析报告等。从软件工程上说，这是属于软件配置的一部分。（我不知道，如果什么报告都没有，只是不断地摆弄执行程序，看到错误和问题就记下来，算不算真正的测试？）

测试需要一定的技术和工具

在用例设计过程中，可以考虑到很多方面，并且也有很多的指导方法和技术。

黑盒测试用例设计包括：

等价类划分：划分等价类--确立测试用例--设计用例
边界值分析：通过分析，考虑如何确立边界情况
错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。
因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试用例。这适合于检查程序输入条件的各种组合情况。

功能图FD：通过形式化地表示程序的功能说明，并机械地生成功能图的测试用例。

白盒测试用例设计包括：

1 逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下5种类型：

1.1 语句覆盖：每一条可执行语句至少覆盖一次；
1.2 判定覆盖（分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；
1.3 条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；
1.4 判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次；
1.5 条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值至少执行一次；
1.6 路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。

2 基本路径测试

在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下5个方面：
2.1 程序的控制流图：描述程序控制流的一种图示方法。
2.2 程序环境复杂性：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。
2.3 导出测试用例
2.4 准备测试用例，确保基本路径集中的每一条路径的执行
2.5 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。

程序的静态分析方法：

1 生成各种引用表、静态错误分析

2 人工测试：桌前检查、代码评审等

3 软件测试工具：包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境

3.1 静态分析工具：语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文，对程序的数据流和控制流进行分析，然后送出测试报告。

3.2 动态测试工具：通过选择适当的测试用例，实际运行所测程序，比较实际运行结果和预期结果，发现错误。

3.3 测试数据自动化生成工具：包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据

3.4 模块测试台是一种专门的测试用例描述语言，负责将输入数据传送到所测试模块中，然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较，发现错误。另外，也包括其它的功能：语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。

3.5 测试合成环境：包括环境模拟程序，代码检查程序，测试文档生成程序，测试执行严整程序，输出比较程序，程序正确性证明程序等，以及各种调试工具。而且还有集成系统，集成了多种工具，如SADAT、Microsoft Test for Windows和PureArtria等。
　
***********************************************************

测试的管理

作为项目或产品开发的一个必要的组成部分，需要良好的组织和管理。使用软件质量规范，编写和实现测试用例和模型，可以有效地组织测试。

一般的测试工作过程也可以是：计划-->配置（必要的软硬件资源下）-->开发（构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转）-->测试执行（进行测试、记录测试条件和问题，报告结果）。

测试管理也可以从测试经理和测试小组2个方面去看：

测试经理要管理好团队，很多人认为测试是枯燥乏味的事情，而且似乎低级的事情，所以测试经理应该不断地激励小组成员，为他们争取利益。在时间进度上保证稳步前进。就象赛跑，一开始就加班加点，只会导致极限的过早到来。
作为测试经理，应该有足够的质量意识。评价质量风险的方法是“失败模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范，以及项目小组假设。然后，按照风险级别进行分类，并按序排列。
实际上如果能得到充分的资源已是很困难的了，能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题，而实际上这对产品的长远发展，以及质量改进都没有太大好处。

测试过程中软件功能可能进行调整和变化，测试发现问题也会导致变化，需要重新的测试。对这些变更也需要进行管理。
另外，由于上层管理部门的不重视，必须想办法与之进行清楚而有效的沟通；同开发部门的沟通也非常重要，因为开发和测试在性质上是有些对立的，很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是，一般质量或测试部门和市场或销售部门的立场倒是比较一致的，如果双方都认为高质量的产品是市场战略中重要的品牌战略，彻底的测试对于达到这样的目标来说意义重大。因此，有必要和市场部门保持协作和交流。

测试经理可以经常问自己一些问题：

计划做哪些测试？实际完成了哪些测试？使用了多少用例？其中多少没有通过？管理部门是否有足够的支持？他们是否向你要过测试报告？开发部门的联络是否及时？等等。如果你是测试管理人员，应该可以想到更多的问题。

测试小组：

测试小组有多大的规模，一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等，也取决于你的准确的测试计划。
对一些项目来说，最好是在开始阶段就有测试人员有所介入。

如本文一开始所提到的，在测试小组中测试人员必须具备的素质包括：有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心（但不至于太强，以至于花太多精力去探究一个微小的问题），不应害怕提出尖锐问题引起麻烦，一定的责任心，
注意力能够高度集中，是职业悲观主义者（但不是抱怨和憎恶）。

以下是一些测试的方法和基本工具：

测试方案、测试模型和测试用例
测试就象是做实验一样，实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤，测试似乎也是同样的。另外，基于测试用例的测试和常见的随机性的测来测去也是完全不同的，尽管习惯于随机性测试的人，如果注意力集中的话，他的头脑里也是有一些测试用例的。

关于测试实验室，进行测试工作首先要争取到尽可能好的环境。如果可能，应该建立测试实验室，实验室包括必要的装备、工具软件（包括测试工具）和各种操作系统平台，保持实验室的实用、整洁，避免他人干扰甚至破坏测试环境。

关于测试跟踪软件，制作一个简单的测试问题跟踪软件，记录测试的结果，将测试发现的问题分类，并对测试发现的问题和模块、开发人员进行关联，有助于分析问题，并可有效记录测试的结果，形成测试报告，并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。

关于测试自动化，有一定的风险。对一个稳定的系统，甚至可以自己开发自动化软件，而对于正处于快速变形中的软件开发过程，接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。

以下是关于测试的一些技巧和经验：

在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；
测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。

由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些

识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。

错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。

对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。

有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。

测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免。

　
最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。

还有一种很奇特的感想，这种感想使我反而有些困惑不清了。我发现对测试来说，理论和实践的距离好象非常遥远，我先看了一本软件工程的书，然后写下了前面的一半内容，然后我又匆匆翻看了一本美国人的书，叫做《测试流程管理》，然后整理出了本文后一半的内容，该书中有着比本文多得多的各方面的实践经验。歌德说过，理论是苍白的，生命之树常青。我稍稍改变一下，就变成了：理论是苍白的，实践之树常青。也许测试是一种实践性很强的工作，大学教授们一般也不可能热衷于参加测试工作吧。

如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下内容，至少要做到几点：

1. 测试计划的编写(要结合测试的项目,能以此来控制和确定测试所需人员,设备及时间来管理测试时间)

2. 要熟悉BUG跟踪工具及软件测试流程.(如: TD, Bugzilla, CQ等)

3. 要熟悉配置管理工具. (如: CVS, VSS等)

4. 要熟悉自动化工具.(例如:WinRunner, QTP, Robot, RFT, Automation等,能结合录制完的脚本编写代

码)

5. 要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分

析出性能瓶颈)

6. 要熟悉或精通一门语言. (例如: Java, C++)

7. 要熟悉数据库.(例如: Oracle, DB2, SQLServer, MySQL)

8. 要熟悉主流操作系统. (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux,

Windows)

9. 能用英文流利的和老外交流以及往来Email.

10. 语言表达能力强,表达问题清晰明了.

11. 沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.

12. 学习技术的能力要强,能快速上手一个新的技术.

13. 乐于与人交流.

1.传统软件测试过程中的问题

　　测试在所有的软件开发过程中都是最重要的部分。在软件开发过程中，一方面要求我们通过测试活动验证所开发的软件在功能上满足软件需求中描述的每一条特性，性能上满足客户要求的负载压力和相应的响应时间、吞吐量要求；另一方面，面向市场和客户，开发团队还要满足在预算范围内尽快发布软件的要求。

　　传统的软件测试流程一般是先在软件开发过程中进行少量的单元测试，然后在整个软件开发结束阶段，集中进行大量的测试，包括功能和性能的集成测试和系统测试。随着开发的软件项目越来越复杂，传统的软件测试流程不可避免地给我们的工作带来以下问题：

　　问题一：项目进度难于控制，项目管理难度加大

　　如图一所示，大量的软件错误往往只有到了项目后期系统测试时才能够被发现，解决问题所花的时间很难预料，经常导致项目进度无法控制，同时在整个软件开发过程中，项目管理人员缺乏对软件质量状况的了解和控制，加大了项目管理难度。

图1：传统测试流程中存在的问题

　　问题二：对于项目风险的控制能力较弱

　　项目风险在项目开发较晚的时候才能够真正降低。往往是经过系统测试之后，才真正确定该设计是否能够满足系统功能、性能和可靠性方面的需求。

　　问题三：软件项目开发费用超出预算     

　　在整个软件开发周期中，错误发现的越晚，单位错误修复成本越高，如图二所示，错误的延迟解决必然导致整个项目成本的急剧增加。

图2：传统测试流程中存在的问题

2.采用软件自动化测试工具是解决传统测试问题的最佳成功经验

　　软件自动化测试技术核心的三个最佳成功经验是：尽早测试、连续测试、自动化测试，并在此基础上提供了完整的软件测试流程和一整套的软件自动化测试工具，使我们最终能够做到：一个测试团队，基于一套完整的软件测试流程，使用一套完整的自动化软件测试工具，完成全方位的软件质量验证。

　　成功经验一：尽早测试

　　所谓尽早测试是指在整个软件开发生命周期中通过各种软件工程技术尽量早的完成各种软件测试任务的一种思想。软件自动化测试工具主要在以下三个方面为我们提供的尽早测试的软件工程技术：

　　首先，软件的整个测试生命周期是与软件的开发生命周期基本平齐的过程，当需求分析基本明确后我们就应该基于需求分析的结果和整个项目计划来进行软件的测试计划；伴随着分析设计过程同时应该完成测试用例的设计；当软件的第一个发布出来后，测试人员要马上基于它进行测试脚本的实现，并基于测试计划中的测试目的执行测试用例，对测试结果进行评估报告。这样，我们可以通过各种测试指标实时监控项目质量状况，提高对整个项目的控制和管理能力。

　　其次，通过迭代是软件开发把原来的整个软件开发生命周期分成多个迭代周期，在每个迭代周期都进行测试，这样在很大程度上提前了软件系统测试发生的时间，这可以在很大程度上降低项目风险和项目开发成本。

　　最后，软件自动化测试工具的尽早测试成功经验还体现在它扩展了传统软件测试阶段从单元测试、集成测试到系统测试、验收测试的划分，将整个软件的测试按阶段划分成开发员测试和系统测试两个阶段，如图三所示，它把软件的测试责无旁贷地扩展到整个开发人员的工作过程。通过提前测试发生的时间来尽早地提高软件质量、降低软件测试成本。

作者：王静兰

转载者：孙小勇

摘  要

一个项目最终呈现在用户面前的质量，与测试执行的程度与力度是密不可分的。测试用例设计的基本目的，是确定一组最有可能发现某个错误或者某类错误的一组测试数据。测试用例构成了设计和制定测试过程的基础，因此测试用例的质量在一定程度上决定了测试工作有效程度。一个好的测试用例使得测试工作的效果事半功倍，并且能尽早的发现一些隐藏的BUG，测试用例的设计是软件开发中的重中之重。

关键词：软件测试，测试用例，TESTCASE，用例设计

A test case is a series of tests used to determine whether one particular thing works properly. Often that means trying the same operation over and over again with little in the procedure.

A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

 1  引言

1.1  测试用例在软件产品中的作用和意义

软件产品化之后给人们日常生活和工作带来了极大的便利。同样的，也使人们对软件产品的质量重视上升到了更进一步的高度。随着软件危机的不断出现以及人们对于软件更进一步的认识，测试的地位得到了前所未有的提高，并且人们意识到：测试开始的时间越早，软件的缺陷将越早被发现，带来整个软件开发中的成本也下降越多。软件测试是发现软件中缺陷的主要手段和唯一有效的方法。软件质量的重视度越高，软件测试工作在软件开发过程中就越重要。

完全覆盖测试又要求测试工作的力度和深度以及每一种现实中可能发生的操作都要保证正确，很多人觉得这个似乎是矛盾的。软件测试中永远不可能做到穷举测试，又想使得测试工作的效率达到最高，那么该如何兼顾工作量和效率的问题，往往成为测试工作中的瓶颈问题所在。如何测试，用什么方式来测试，在什么环境和什么样的条件下进行测试，测试的工作量和如何避免重复的测试，等等各种应该考虑的因素在测试工作中如何协调和同步，在测试用例中应该充分描述这些问题。

因此，软件测试工作中处于重中之重的测试用例的设计要求也随之上升到了更高的层次。测试用例不但构成了设计和制定测试过程的基础，而且测试的深度与测试用例的数量成正比。一般来讲，判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这个又是以确定、实施和（或）执行的测试用例的数量为依据的；测试工作量与测试用例的数量成比例；测试设计和开发的类型以及所需的资源主要都受控于测试用例。这些使得测试用例在整个的软件开发过程中处于更加重要的地位。

1.2  测试用例的定义

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

Robert V.Binder是这样描述的，测试实例：输入、执行条件，及为一个特殊目标所开发的预期结果的集合。一个定义IUT（被测实现，即被测代码）及其环境、测试输入或条件，及预期结果的测试前状态的表示或实现。

1.3  测试用例应该包含的要素

首先测试用例应该包含软件或者项目名称、所服务的范围、背景、作者、编写时间等文档类信息；根据测试用例的定义和目的，测试用例的内容应该有：标题和用例编号、版本号、修改记录，针对目标和假设前提/可能发现的错误，输入数据/代码，测试步骤，预期输出和错误发现方法。

1.4  测试用例中需要注意的问题

每个测试用例清楚地阐述了正在进行评估的用例、用例场景、测试目标或条件的有关说明。每个测试用例都描述了预期结果和评估该结果的方法。

对于每个测试需求，在测试用例中需要考虑在正面测试和负面测试的条件下的测试，或者通过确定两个测试用例来实现，一个测试用例代表预期的条件，它可用于核实行为是否正确或符合预期（正面测试）。另一个测试用例代表不可接受的、异常的或意外的条件，它可用于核实测试需求是否未以非预期方式执行（负面测试）。

在一般情况下，对于测试的每个需求来说，至少要有一个正面测试用例和为数较多的负面测试用例，以此来检查在异常情况下系统能否正常处理，或者用户进行了错误的操作时的友好提示等等。

测试用例已被确定用来执行测试目标中所有的产品需求行为，包括（视情况而定）： 功能 、数据确认 、业务规则实施 、测试目标工作流程或控制 、数据流 、对象状态 、性能（包括工作量、配置和强度） 、安全性/可访问性 、兼容性。每个测试用例都说明或者/代表一个唯一的输入集或事件顺序，它能够产生唯一的测试目标行为，复审那些产生相同行为的测试用例并判定它们是否等同，即它们是否都执行测试目标中的路径。

每个测试用例（或每组相关的测试用例）确定初始的测试目标状态和测试数据状态。测试用例名称和/或 ID 与测试工件命名约定一致。

2  测试用例的设计方法概述

根据测试的方法分为黑盒测试和白盒测试，相应的测试用例的设计方法也可以分为针对黑盒测试的用例设计和针对白盒测试的用例设计。

至今提出的测试用例设计方法有许多，下面简要的介绍一些比较重要的、常用的方法。

2.1  白盒测试的测试用例设计方法

2.1.1 逻辑覆盖

逻辑覆盖包括：语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖、路径覆盖，各自的定义简略描述如下：

语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。

判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。

条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。

判定－条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，每个判断中的每个分支至少执行一次。

条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。

路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。

2.1.2 基本路径测试

基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。

它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。

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

2.2.1 等价划分

所谓等价类划分是指一套被选择的值，这些值分别代表了许多众多的可能输入值，程序对其处理的方式都是一样的。

等价类划分的方法作为继边界值分析方法之后补充的测试用力设计试用的一种方法。划分等价类、确定测试用例

等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。

等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例

等价类的划分有两种不同的情况：
有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。

无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。

在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。

2.2.2 边界值分析

在设计测试用例确定输入和输出参数时，大多数情况下都是用边界值分析方法，采用边界值分析设计的测试用例发现程序错误能力最强。

边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。

2.2.3 错误推测法

人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。

错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

2.2.4 因果图

如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法。如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。

因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。

3  测试用例的评审及维护

3.1 测试用例的评审

测试用例在设计之后需要经过评审，需要评审的内容如下：

用例是否完整？是否每一个需求都有其对应的测试用例来验证？

是否每一个设计元素都有其对应的测试用例来验证？

事件顺序，能否产生唯一的测试目标行为？

是否每隔测试用例都阐述了预期结果？

是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？

测试用例是否包含了所有单一的边界？

测试用例是否包含了所有的业务数据流？

是否所有的测试用例名称，ID都与测试工件命名约定一致？

测试用例评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员

查看(575) 评论(0) 收藏 分享 管理

•   
•   1.You look great!你看上去很精神
  　　2.How's your business going?你的生意怎么样?
  　　3.How's everything going?一切都好吗?
  　　4.So far so good到目前为止还我不错
  　　5.Let's keep in touch让我们保持联系吧
     6.I have heard a lot about you久闻大名
  　　7.We have met我们见过面
  　　8.Can you spare me a few minutes?我能占用你几分钟时间吗?
  　　9.Give me a lift送我一程
  　　0.It's my treat this time这次我请客