1、 本章介绍网上购物系统的测试用例的设计与编写。测试用例设计的目的是为每一个测试需求确定测试用例集（Test Case Suite）。本章重点：测试用例编写规范测试用例设计方法测试用例是为有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合，是测试的基础。设计测试用例是在了解软件业务流程的基础上进行的。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。工作任务2.1 Test Suite用户管理2.1.1 Test Suite添加注册信息1工作任务描述用户管
2、理是网上购物系统的基本模块，而添加用户注册信息是用户管理模块中的基本功能，也是必需的功能。当用户在浏览器的地址栏中输入本系统的网址时，系统弹出如图2-1所示的主页面。单击注册按钮，转到如图2-2所示的页面中，用户填写用户名、姓名、密码和邮寄地址等信息进行注册，填写完之后单击提交按钮进行注册。如果注册成功则会跳转到如图2-3所示的页面。由于系统会对注册信息进行一个简单的验证，如果验证注册信息失败，则系统会提示注册失败信息。图2-2 用户注册界面图2-3 注册成功界面本节任务就是对添加注册信息功能进行测试，编写测试用例集。在此我们使用了场景法、边界值法、错误推测法等测试用例设计方法。2工作过程编写
3、测试用例集：以下是用户管理模块中添加注册信息功能的测试用例集。详细测试用例参见教材25-32页.2.1.2 Test Suite管理员登录1工作任务描述在本系统中，管理员可以对商品信息和商品的类别信息进行管理。管理员登录界面如图2-4所示，当管理员成功登录后，则进入后台管理主界面如图2-5所示。图2-4 登录界面图2-5 后台管理主界面本节任务就是对管理员登录功能进行测试，编写测试用例集。在此我们使用了场景法、错误推测法等测试用例设计方法。2工作过程编写测试用例集。以下是用户管理模块的子功能管理员登录的测试用例集。详细测试用例参见书33-35页2.1.3 Test Suite注册用户登录1工作
4、任务描述用户注册成功后，就可以登录网站了，用户登录的页面如图2-6所示。登录成功后进入商品购买主界面如图2-7所示。本节任务就是编写已注册过的用户登录功能的测试用例集。在此我们使用了场景法、错误推测法、边界值法等测试用例设计方法。图2-6 主页面图2-7 商品购买主界面2工作过程编写测试用例集。以下是注册用户登录的测试用例集。详细测试用例参见书36-40页。2.1.4 Test Suite修改注册信息1工作任务描述用户成功登录系统后，可以对自己的信息进行修改。修改注册信息的界面如图2-8所示。本节任务就是编写修改注册信息功能的测试用例集。在此我们使用了场景法、错误推测法、边界值法等测试用例设计
5、方法。图2-8 修改注册信息2工作过程编写测试用例集。以下是修改注册信息的测试用例集。详细测试用例参见书41-45页2.1.5 应知应会1什么是测试用例测试用例（Test Case）是按一定的顺序执行的并与测试目标相关的测试活动的描述，它确定“怎样”测试。测试用例是有效发现软件缺陷的最小测试执行单元，是软件的测试规格说明书。目前也没有测试用例这个词汇的经典定义，常见的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略，内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。在测试工作中，测试用例的设计是非常重要的，是测试执行的正确性、有效
6、性的基础。如何有效地设计测试用例一直是测试人员所关注的问题，设计好的测试用例是保证测试工作的最关键的因素之一。如果问测试工程师测试用例如何编写，就像是问程序员如何编写代码得到的答案一样，每个人都会给出不同的编写方法，但实用的测试用例却像优秀的程序一样难以编写。目前在国内，测试工程师却时常要面对“已经延期几倍计划时间的项目”，测试用例如何发挥更大的作用，是一个迫切需要解决的问题。事实上，完全可以把测试用例看成是测试工程师编写的程序：这个“程序”是为了辅助测试工作的进行而开发的，目的是为了发现软件问题，同时“顺便”证明软件功能是否符合要求。测试用例主要用在集成测试、系统测试以及回归测试中。测试人员
7、按照已规定好的测试用例实施测试，而不得做随意的变动。因为测试用例是分测试等级的，集成测试应测试哪些用例，系统测试应包含哪些用例，以及回归测试又该实施什么样的测试用例，在设计测试用例时都是由专门人员明确规定并形成文档的。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试，并且要把测试结果详细记录下来，以便形成测试结果文档，等下一轮测试时作为参考之用。在本书给出的测试用例中，测试数据是给定的，但是有时候在实践当中，测试数据与测试用例是分离的，根据测试用例设计，需要准备大量原始数据及标准测试期望的结果，这些 数据包括各种情况下的输入数据尤其是必须设计出
8、大量的边缘数据和错误数据，这些设计用例的方法在后续内容中会有详细介绍。当测试实施完成后，对测试结果的评估是非常重要的。要判断软件测试是否完成，衡量测试质量需要一些量化的结果（测试覆盖率多少、测试合格率多少、重要测试合格率多少），这样把测试用例及实施结果作为度量标准使测试更加准确有效。通过实施测试用例，将系统缺陷（Bug）尽量收集全面，把测试用例和缺陷数据进行对比，分析是漏测还是缺陷复现，最终使系统逐步完善软件质量。当然，测试用例本身在形成文档后也是在不断修改更新与完善，原因有三个：第一，在测试过程中发现设计测试用例时考虑不周，需要完善；第二，在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例
9、存在漏洞造成的；第三，软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。一些小的修改直接在原测试用例文档里更正就可以了，但是文档中要有此次更正的记录。软件的版本是会升级更新的，测试用例也一样，随着软件的升级而编制新的版本。测试用例的形成可以分为简单的七个步骤：1理清模块需求2提出测试需求3设计测试思路4测试用例编写5测试用例评审6执行用例7用例效率计算在本书后续应知应会中会有详细用例编写的介绍，在此不再赘述。2测试的阶段和种类性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试，这么多眼花缭乱的测试类型名称，估计很少有人能准确地区分并说出定义来，至
10、于对应的测试用例如何编写和执行，就更不用说了。这里给读者做一下较为系统的说明。2测试的阶段和种类性能测试、压力测试、负载测试、强度测试、稳定性测试、健壮性测试、功能测试、接口测试，这么多眼花缭乱的测试类型名称，估计很少有人能准确地区分并说出定义来，至于对应的测试用例如何编写和执行，就更不用说了。这里给读者做一下较为系统的说明。（1）软件测试阶段软件的测试阶段就是测试将按照什么样的思路和方式进行。通常，软件测试要经过单元测试、集成测试、确认测试、系统测试以及验收测试。这些阶段和开发过程是相对应的。关于测试阶段的叫法有多种，比如测试类型，测试策略等。单元测试：单元测试是针对软件设计的最小单位程序模
11、块甚至代码段进行正确性检验的测试工作，通常由开发人员进行。集成测试：集成测试是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。由于在产品提交到测试部门前，产品开发小组都要进行联合调试，因此在大部分企业中集成测试是由开发人员来完成的。时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元
12、测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。a自顶向下集成自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先
13、的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以图2-9为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍然以图2-9为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6和其他模块集成起来。由于下文用到桩模块的概念，在此先向读者介绍一下。在集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，
14、这些专供测试用的“假”模块称为被测模块的桩模块。自顶向下综合测试的具体步骤为：以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代；依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块；每集成一个模块立即测试一遍；只有每组测试完成后，才着手替换下一个桩模块；为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。图2-9中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块替代。最后直至桩模块S4
15、被替代完毕为止。自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。b自底向上集成自底向上测试是从“原子”模块（即软件结构最低层的模
16、块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。自底向上综合测试的步骤分为：把底层模块组织成实现某个子功能的模块群（cluster）；开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；对每个模块群进行测试；删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。图2-10说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可将
17、D3去掉，将Mb与模块群3直接接口，对Mb进行集成测试。这样继续下去，直至最后将驱动模块D4、D5也去掉，最后Ma、Mb和Mc全部集成在一起进行测试。自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向下综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：对应几条需求；具有高层控制功能；复杂、易出错；有特殊的性能要求。关键模块应尽
18、早测试，并反复进行回归测试。系统测试：系统测试是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。它主要由测试部门进行，是测试部门最大最重要的一个测试，对产品的质量有重大的影响。计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其他成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作：为测试软件系统的输入信息设计出错处理通路；设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助
19、；参与系统测试的规划和设计，保证软件测试的合理性。系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能正常工作并完成所赋予的任务。下面简单讨论几类系统测试。a恢复测试恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点（checkpointing mechanisms）、数据恢复（data recovery）和重新启动（restart）等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间
20、，确定其是否在可接受的范围内。b安全测试安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。c强度测试强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；定
21、量地增长数据输入率，检查输入子功能的反应能力；运行需要最大存储空间（或其他资源）的测试用例；运行可能导致操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。d性能测试对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行操作系统，性能测试就是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。验收测试：验收测试（acceptance testing）以需求阶段的需求规格说明书为验收标准，测试时要求模拟实际用户的运行环境。对于实际项目可以和客户共
22、同进行，对于产品来说就是最后一次的系统测试。测试内容为对功能模块的全面测试，尤其要进行文档测试。验收测试是系统开发生命周期方法论的一个阶段，这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就
23、应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所期待的那样。通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。实现软件确认要通过一系列黑盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无论是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确，人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等
24、）是否令用户满意。确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收
25、测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为a、b测试的过程，以便发现那些似乎只有最终用户才能发现的问题。a测试是指软件开发公司组织内部人员模拟各类用户对即将面市的软件产品（称为a版本）进行测试，试图发现错误并修正。a测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。经过a测试调整的软件产品称为b版本。紧随其后的b测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用b版本，并要求用户报
26、告异常情况、提出批评意见。然后软件开发公司再对b版本进行改错和完善。a验收测试过程过程如下：（a）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。（b）编制验收测试计划和项目验收准则：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审。（c）测试设计和测试用例设计：根据验收测试计划和项目验收准则编制测试用例，并经过评审。（d）测试环境搭建：建立测试的硬件环境、软件环境等（可在委托客户提供的环境中进行测试）。（e）测试实施：测试并记录测试结果。（f）测试结果分析：根据验收通过准则分析测试结果，
27、做出验收是否通过及测试评价。（g）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。b验收测试的总体思路用户验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动。它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。需要根据事先制定的计划，进行软件配置评审、功能测试、性能测试等多方面检测。用户验收测试可以分为两个大的部分：软件配置审核和可执行程序测试，其大致顺序可分为：文档审核、源代码审核、配置脚本审核、测试程序
28、或脚本审核、可执行程序测试。要注意的是，在开发方将软件提交用户方进行验收测试之前，必须保证开发方本身已经对软件的各方面进行了足够的正式测试（当然，这里的“足够”，本身是很难准确定量的）。用户在按照合同接收并清点开发方的提交物时（包括以前已经提交的），要查看开发方提供的各种审核报告和测试报告内容是否齐全，再加上平时对开发方工作情况的了解，基本可以初步判断开发方是否已经进行了足够的正式测试。用户验收测试的每一个相对独立的部分，都应该有目标（本步骤的目的）、启动标准（着手本步骤必须满足的条件）、活动（构成本步骤的具体活动）、完成标准（完成本步骤要满足的条件）和度量（应该收集的产品与过程数据）。在实际
29、验收测试过程中，收集度量数据，不是一件容易的事情。（a）软件配置审核对于一个外包的软件项目而言，软件承包方通常要提供如下相关的软件配置内容：可执行程序、源程序、配置脚本、测试程序或脚本。主要的开发类文档：需求分析说明书、概要设计说明书、详细设计说明书、数据库设计说明书、测试计划、测试报告、程序维护手册、程序员开发手册、用户操作手册、项目总结报告。主要的管理类文档：项目计划书、质量控制计划、配置管理计划、用户培训计划、质量总结报告、评审报告、会议记录、开发进度月报。在开发类文档中，容易被忽视的文档有程序维护手册和程序员开发手册。程序维护手册的主要内容包括：系统说明（包括程序说明）、操作环境、维护
30、过程、源代码清单等，编写目的是为将来的维护、修改和再次开发工作提供有用的技术信息。程序员开发手册的主要内容包括：系统目标、开发环境使用说明、测试环境使用说明、编码规范及相应的流程等，实际上就是程序员的培训手册。不同大小的项目，都必须具备上述的文档内容，只是可以根据实际情况进行重新组织。对上述的提交物，最好在合同中规定阶段提交的时间，以免发生纠纷。通常，正式的审核过程分为5个步骤：计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是最终确定工作产品中包含的错误和缺陷。审核要达到的基本目标是：根据共同制定
31、的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面是由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。（b）可执行程序的测试在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤可执行程序的测试，它包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、
32、活动、完成标准和度量等五部分。要注意的是不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。在真正进行用户验收测试之前一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）：软件开发已经完成，并全部解决了已知的软件缺陷。验收测试计划已经过评审并批准，并且置于文档控制之下。对软件需求说明书的审查已经完成。对概要设计、详细设计的审查已经完成。对所有关键模块的代码审查已经完成。对单元、集成、系统测试计划和报告的审查已经完成。所有的测试脚本已完成，并至少执行过一次，且通过评审。使用配置管理工具且代码置于配置控制之下。软件问题处理流程已经就绪
33、。已经制定、评审并批准验收测试完成标准。具体的测试内容通常可以包括：安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）、可靠性测试等。性能测试和压力测试一般情况下是在一起进行，通常还需要辅助工具的支持。在进行性能测试和压力测试时，测试范围必须限定在那些使用频度高的和时间要求苛刻的软件功能子集中。由于开发方已经事先进行过性能测试和压力测试，因此可以直接使用开发方的辅助工具。也可以通过购买或
34、自己开发来获得辅助工具。具体的测试方法可以参考相关的软件工程书籍。如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。尽管测试阶段的划分十分明确，但是在具体的项目和产品的测试中，尤其在执行测试时，会根据实际需要来开展。关于软件测试阶段的理论可以参看朱少民写的全程软件测试一书中软件测试过程和开发过程的V模型关系。测试的各个阶段所用时间比例是不同的，根据该阶段的性质，确定时间长短。当然，具体情况要具体掌握，根据不同项目不同情况，各测试阶段所用时间长短可随时调节。图2-
35、11直观地描述出了测试各阶段所用的时间对比。图2-11 测试各阶段所用的时间（2）软件测试的种类对于测试种类的说法很多，最多的能达到几十种测试种类。但是实际工作中很多测试是互相包含的。按照企业中实际工作需要，通常主要进行下面几种类型的测试：功能测试、健壮性测试、接口测试、强度测试、压力测试、性能测试、用户界面测试、可靠性测试、安装/反安装测试、帮助文档测试。下面介绍几种重要的测试种类及其测试的内容：功能测试：功能测试主要针对产品需求说明书的测试，是验证功能是否适合需求，包括原定功能的检验、是否有冗余功能、遗漏功能。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作，他们
36、也需要进行基本功能的测试。接口测试：程序员对各个模块进行系统联调的测试，包含程序内接口和程序外接口测试。这个测试，在单元测试阶段进行了一部分工作，而大部分都是在集成测试阶段完成的。由开发人员进行。性能测试：在交替进行负荷和强迫测试时常用的术语。性能测试关注的是系统的整体。它和通常所说的强度、压力/负载测试有密切关系。所以压力和强度测试应该与性能测试一同进行。用户界面测试：对系统的界面进行测试，测试用户界面是否友好、是否方便易用、设计是否合理、位置是否正确等一系列界面问题。安装/反安装测试：安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后能否影响原系统；反安装是逆过程，测
37、试是否删除干净，是否影响原系统等。文档测试：主要测试开发过程中针对用户的文档，以需求、用户手册、安装手册等为主，检验文档是否和实际应用存在差别。文档测试不需要编写测试用例。测试种类的划分不要拘泥于上面的形式，总体来说应该服从于测试策略，可以根据具体工作的特点进行安排，为了工作更容易开展，完全可以把一些测试合并在一起进行。在后面的性能测试用例的编写上，充分体现了这一思想。综合上面的分析，测试种类、测试阶段以及执行人员具体的关系如表2-1所示。表2-1 测试的种类、阶段和执行人员的关系测 试 阶 段测 试 类 型执 行 者单元测试模块功能测试，包含部分接口测试、路径测试开发工程师集成测试接口测试、
38、路径测试，含部分功能测试开发工程师（如果测试人员水平较高，可以由测试人员执行）系统测试功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试测试工程师验收测试对于实际项目来说基本同上，并包含文档测试；对于软件产品，主要测试相关的技术文档测试工程师（根据实际需要，可能包含用户）总之，测试的种类应该尽量的少，这样每次都可以执行更多的测试内容。例如在进行功能测试的同时，完全可以进行健壮性的测试（当然如果产品健壮性方面要求较高，就可以把健壮性测试作为独立的测试）。也就是说测试各个阶段中对执行不同的测试种类采用不同的测试技术。关于测试技术下面进行讲解。3黑盒测试
39、中设计测试用例的基本方法白盒测试和黑盒测试是软件测试中的两大方法，有时也将兼具两者特点的方法叫做灰盒测试。但传统的软件测试活动基本上都可以划到这两类方法当中。黑盒测试注重于测试软件的功能性需求，也就是说黑盒测试要求软件工程师列出程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。黑盒测试主要用于测试的后期，一般由专门的测试人员来做。本课程主要来学习黑盒测试，培养专门的测试人员。黑盒测试概括起来主要用来发现下面这些类型的错误：功能错误或遗漏；界面错误；数据结构或外部数据库访问错误；性能错误；初始化和终止错误。测试用例可以分为基本事件、备选事件和异常
40、事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测
41、法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。黑盒测试方法主要有五种，分为等价类划分法、边界值划分法、错误推测法、因果图法和场景法。在实际测试用例设计过程中，不仅根据需要、场合单独使用这些方法，常常综合运用多个方法，使测试用例的设计更为有效。等价类法（1）等价类定义等价类划分法是黑盒测试的典型方法，是指某个输入域的子集合。在该集合中，各个输入数据对于揭露程序中的错误都是等效的。有效等价类：符合需求规格说明书，合理地输入数据集合。无效等价类：不符合需求规格说明书
42、，无意义地输入数据集合。（2）等价类划分的步骤划分有效等价类和无效等价类根据上面等价类的划分，确定测试用例例1：请用等价类和边界值方法编写163邮箱注册模块（简化版）的测试用例（假设没有重复的用户名），如下图所示。请注意带*的项目必须填写。输入条件有效等价类无效等价类用户名长度(1).318 之间(2).大于18(3).小于3用户名类型(4).用户名由字母，数字，点，减号或下划线组成 只能以数字或字母开头和结尾(5).用户名中含有空格(6).用户名中含有特殊字(7)用户名为空(8)不以数字和字母开头(9)不以数字和字母结尾是否区分大小写(10)不区分大小写(11)区分大小写（1）用户名：划分等
43、价类并编号，下表等价类划分的结果：（2）用户名：设计测试用例序号所属等价类输入数据预期输出结果11 a122333 该用户可以注册22123456aaaaaaaabbbb 提示请输入3-18个字符3312提示请输入3-18个字符46 12345 提示用户名格式不正确55 空格提示用户名格式不正确 66 汉字提示用户名格式不正确78 _234a 只能以数字或字母开头和结尾87 用户名不能为空99 A123456-只能以数字或字母开头和结尾1010Aaaaaa（用户名为aaaaaa）登陆成功输入条件有效等价类无效等价类密码长度(1)618(2).大于18(3).小于6 密码类型(4).以数字，字母
44、，特殊字符组成(5).用户名中含有空格 密码是否为明文(6).不是明文(7)是明文输入密码和再次输入密码是否一致(8).输入密码和再次输入密码一致(9).密码和在次输入密码不一致（3）密码：划分等价类并编号，下表等价类划分的结果：序号输入数据所属等价类预期结果1 1 a122333 该用户可以注册2 3 a1 提示请输入6-18个字符3 2 123456aaaaaaaajkkfhj 提示请输入6-18个字符45 空格提示密码格式不正确 5 4 1234a 该用户可以登录66 A1234123 该用户可以登录78密码和输入密码一致可以注册89密码和输入密码不一致不可以注册97*可以登录例2：设有
45、一个档案管理系统，要求用户输入以年月表示的日期，假设日期限定在2011年1月2099年12月，并规定日期由6位数字字符组成，前4位表示年，后两位表示月。现用等价类划分法设计测试用例，来测试程序的“日期检查功能”。输入条件有效等价类无效等价类日期的类型及长度 6位数字组成的字符有非数字字符少于6位数字字符多于6位数字字符年份范围在2011-2099之间小于2011大于2099月份范围在01-12之间等于00大于12（1）划分等价类并编号，下表等价类划分的结果：序号输入数据所属等价类测试方法预期输出结果1123456等价类可查询2A12346等价类日期格式不正确3122等价类日期格式不正确4123
46、4567等价类日期格式不正确52012等价类可查询62000等价类请输入2011-2099范围内的年份73000等价类请输入2011-2099范围内的年份806等价类可查询900等价类请输入01-12月份的数字1013等价类请输入01-12月份的数字（2）设计测试用例2边界值法边界值分析法是一种非常实用的测试用例设计技术，具有很强的发现程序错误的能力，它的测试用例来自于等价类的边界。大量测试工作的经验会告诉我们，大量的错误发生在输入或输出范围的边界上，而不是输入或输出范围的内部。边界值分析就是假定错误发生在输入或输出区间的边界上，因此使用边界值法设计测试用例，可以发现更多的错误。在使用边界值法
47、设计测试用例时，应该首先确定好输入边界和输出边界情况，然后选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。一般情况下，可以遵循以下几个规则来设计测试用例：如果输入条件规定了值的范围，应取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入的数据。如果输入条件规定了值的个数，应用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。根据每个输入条件，使用规则一或二。如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例数据。如果程序中使用了一个内部数据结构，应当选择
48、这个内部数据结构的边界上的值来作为测试用例。分析规格说明，找出其他可能的边界条件。下面举个例子让大家更深入地理解边界值法。用户登录网上购物系统要购买某种商品，假设该商品剩余数量为100件，且用户只会输入整数。则用户只能购买1100范围内的商品件数。使用边界值法设计测试用例，测试用户输入商品数量Q后，系统反应是否合乎标准。提出边界时，一定要测试邻近边界的合法数据，即测试最后一个可能合法的数据，以及刚刚超过边界的非法数据。越界测试通常简单地加1或者用最小的数减1。图2-12中，输入分区将1100分成三个区间，再考虑上恰好等区间边界的情况，我们可以考虑商品数量Q的输入区间如下：图2-12 边界值分析
49、 Q1 Q=1 1Q100根据上面的分析可以设计六个用例：Test Case 1：输入0，返回错误信息“您必须输入大于等于一个数量值”。Test Case 2：输入1，页面正确运行。Test Case 3：输入2，页面正确运行。Test Case 4：输入99，页面正确运行。Test Case 5：输入100，页面正确运行。Test Case 6：输入101，返回错误信息“您所选购的商品数量仅剩100件”。测试员可以将上面的信息填入用例设计表格中，形成标准的测试用例。3错误推测法错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。使用错误推测法时，可
50、以凭经验列举出程序中所有可能有的错误和容易发生错误的特殊情况，帮助猜测错误可能发生的位置，提高错误猜测的有效性，根据他们选择测试用例。例如：输入表格为空格；输入数据和输出数据为0的情况。4场景法场景是通过描述经过用例的路径来确定的过程，这个过程要从用例开始到结束遍历其中所有基本流和备选流。场景法就是根据这些基本流和备选流的流动过程来设计测试用例。目前的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到
