软件的最低测试方法

软件的最低测试方法

 

　　前言

　　1.1. 引言

　　对于大部分软件系统，如何测试及有效的测试，是一个很头痛的问题。在软件工程上，测试是软件工程中极其重要的一部分; 但在具体的实际情况上，无论是时间、人手及资源的调配等原因，使国内大部分软件公司没有进行过理论上的完整的测试。

　　本文想要描述的，就是一种简单可行，又能使软件系统达到最低质量要求的一组测试方法。

　　1.2. 测试目的

　　对于任何一款软件来讲，它的价值在于正确的实现了用户的需求，那么测试的最终目的，就是测试软件是否真正的对于用户的需求进行了实现，并使系统达到用户可以接收的程度。

　　1.3. 测试方法

　　用户对于软件的最终的认可程度及验收情况，就是对于一个软件的最终的认同，然后才能投入正确的使用。所以对于开发者来讲，最终将系统交付于用户前，是必须具备一整套科学的完善的内部测试的方法。内部测试时，开发商会一致要求测试人员从用户的角度来使用，并进行逐一的测试，测试通过后，才能把系统提交给用户。

　　也就是说内部的测试最少要进行系统的确认及系统的测试等相关的部分。

　　2. 内部测试流程

　　2.1. 测试前期准备

　　测试前首先要根据系统情况，准备相应的机器及 设备 ，还要建设相应的测试环境，配备相应的测试人员。

　　对于相应的测试人员必须从客户的角度进行测试，也就是说在测试前要非常明确系统要达到的功能目标，测试人员所具备的专业的鉴赏能力，应当明白重点及非重点。

　　测试人员对于需求的明确性是内部测试最低的要求 。

　　2.2. 编写测试计划

　　测试计划一定要包涵以下内容：

　　1 .确定测试人员并进行分工，明确各自的职责。

　　2 .明确的测试功能，进行功能的优先顺序排序。

　　对于测试工作安排一般次序如下：

　　? 系统安装

　　? 系统参数设置

　　? 遍历所有的业务功能，并明确是否实现了所有的需求

　　? 通过测试

　　? 准确性测试(含数据测试)

　　? 失败测试

　　? 状态测试

　　? 业务处理功能查询功能及报表功能

　　? 系统性能

　　3 .测试数据设计说明。

　　4 .培训及其它支持条件

　　2.3. 测试用例设计

　　2.3.1. 测试用例的编写

　　关键点

　　1. 测试用例的功能点必须由 SA 编写明确及进行解析，大量的测试案例由测试小组进行编写，最终的测试用例由 SA 进行签字确认

　　2. 当然如果 SA 不进行编码，那么测试组长由其担任是最为合适的。

　　3. 功能点的跟踪与变更必须即时更新，一般由 SA 或 PM 进行，测试案例也必须进行相应更新。

　　实际过程中需要根据可用的资源(人力、物力及时间等)用尽量少的测试用例，来发现更多的错误。给最终用户提供具有一定可信度的质量评价。如果想编写和测试所有的用例是不太现实的，下面是一个具体的例子，在实际测试过程中良好的程序员，也只能列出下面实际需要的测试用例的一半多一点。

　　2.3.2. 一个典例测试用例

　　程序：一个程序接受 3 个整型输入。 3 个整型值代有表三角形的 3 条边。根据这 3 个值，程序要确定出这个三角形是不等边三角形、等腰三角形还是等边三角形。

　　完整的测试用例：

　　测试用例的目的 注释

　　有效的不等边三角形 诸如 1 、 2 、 3 和 2 、 5 、 10 之类的测试用例不能保证“是”答案，因为不存在这样的三角形

　　有效的等边三角形

　　有效的等腰三角形 1 ， 1 ， 2 类测试用例不能计算在内，因为不存在这样的三角形

　　测试用例是有效的等腰三角形，从而就包括了两个等边的 3 个置换 例如： 3 、 3 、 4 ; 3 、 4 、 3 和 4 、 3 、 3

　　一个边是 0

　　一个边是负值

　　3 个大于 0 的整数，并且 2 个数的和与第 3 个数相等 如果程序认为 1 、 2 、 3 表示不等边三角形，则是一个 BUG

　　在上面测试中至少有 3 个测试用例，这样你便可以尝试 3 种排列。其中 1 个边的长度等于另外 2 个边和的长度

　　3 个大于 0 的整数，并且 2 个数的和小于第 3 个数 如： 1 、 2 、 4 和 12 、 15 、 30

　　在上面测试中至少有 3 个测试用例，这样你可以尝试 3 种排列 如： 1 、 2 、 4 ; 1 、 4 、 2 和 4 、 1 、 2

　　所有的边为 0

　　非整数值

　　输入数据的个数错误 如输入 2 个或多于 3 个数

　　是否规定了每一个测试用例的预期输出

　　(摘录自《软件验证与确认的最佳管理方法》)

　　2.4. 测试流程

　　测试的流程对于实际情况有两种 :

　　2.4.1. 开发小组程序员之间的联调

　　程序员之间的联调多发生在多个子系统构成的大系统或一个系统由多人根据功能分工编写的情况下。

　　测试流程一般由业务发起点的功能编写者发起测试，到达业务的终止点为结束。

　　具体形式如下：

　　起始点的开发者发起业务后，添写纸质的联调测试书，明确发起的内容，送到下一个处理环节的程序员处。

　　相应的下一环节程序员，进行相应的处理。处理完毕后，添加联调测试书中相应的部分或在联调测试书中签字说明已经完成相应的处理，再送下一处理环节的程序员处，通过这种类似层层审批的方式到达最终点，完成内部联调流程。

　　内部联调是对于每个程序员所编程序的测试，由于分工及技术水平的不同，一般容易产生每个程序员工作量及进展难于把握 的情况，所以对于联调测试期人员分工要进行灵活调动的方式。

　　2.4.2. 测试小组同程序开发小组的工作形式

　　1. 程序人员自我测试后提交项目经理 请求测试验收， 项目 经理文字或其他方式通知测试负责人准备提交测试，测试负责人到程序员处当场进行初验(程序员当场演示)，记录当场发现的 BUG 数(推荐每个程序员的办公桌前有一个 初验 BUG 数表 ，每次初验 BUG 数记录在文件内， 周报时通报 每周最高和最低的人员及 BUG 数，，最终测试期阶段初验 BUG 数据影响程序人员考核，用来加强程序人员进行初验前的自验重视程度)

　　2. 初验合格，程序员把项目文件(源程序包)及 EXE 文件(或安装程序包)打包在一个 ZIP 文件。发送给内部文件管理员或项目规定的测试文件存放目录，否则程序员进行修改后并重复第 1 步。

　　3. 文件管理员进行本次测试的版本文件归档后，文件管理员再通知测试负责人要进行测试的文件所存放的位置。

　　4. 测试负责人取相应的系统进行测试， 记录测试过程 ，最终提交测试结果形成 BUG 列表，传达给项目经理 , 项目经理审查后再传送给程序员。

　　5. 程序员根据 BUG 列表进行相应的程序修改，并对 BUG 列表文件进行更新，发送给项目经理，项目经理审核后再传送给测试负责人。

　　6. 重复第 1 步，后期的测试中测试人员将对原测试错误进行跟踪审查。

　　测试负责人及文件管理员可以是专人也可由项目经理或系统分析员兼任。

　　如果使用最终用户作为测试人员，千万注意，过多的 BUG (特别是对于金额的误差)的发现，会使用户对系统有恐惧心理，认为将来给他们的程序是一个大炸弹。所以在提交前，必须进行严格的自验。对于 BUG 的必需严肃的对待，不然将影响用户对系统的信心。对于由于不严谨产生严重的 BUG ，必须进行必要的批评(周会或小组会议)，使程序员加强自身的检查。

　　2.4.3. 测试小组工作要求

　　1 、 BUG 列表的提交及数据提交

　　A) 要求记录所有的 BUG 。

　　B) 重大 BUG 可即时提交由项目组解决，但必须作好 BUG 记录，并继续其它的测试 ( 除不能进行测试以 外 ) 。

　　C) 对于某些测试人员认为要进行的测试，若进行不了，应作 BUG 提交。

　　D) 数据的记录应详细，所作的所有操作关键数据均应记录。

　　2 、 BUG 的跟踪

　　A) 对自己发现的 BUG 已解决和未解决的问题进行跟踪。

　　B) 对新版本中仍未解决的问题应另外作 BUG 记录，并可注明“遗留问题”。

　　3 、测试任务分工

　　明确每人的测试重点，文件的保存位置，提交 BUG 的方式，所有的 BUG 由测试组长汇总后提交给项目组。

　　2.4.4. 测试组工作流

　　1. 项目组 PM 提交测试程序;

　　要求：包含所有工程文件和执行文件(第一次要求是项目组经过预测试的可运行程序)

　　2. 测试人员验收;

　　3. 测试人员将所有文件打进一个包;

　　4. 提交给项目配置库;

　　5. 测试执行

　　说明：测试人员按《测试任务分工》、《业务依赖关系》及相关的《需求文档》 执行测试

　　6. 填写《测试记录》与《 BUG 列表》

　　要求：《测试记录》在测试过程中按照要求即时、详尽的填写;《 BUG 列表》每天测试完成后按要求填写

　　7. 将《测试记录》与《测试 BUG 列表》提交测试组长(不长于 2 天提交一次);

　　说明：测试人员不长于 2 天完成一轮测试

　　8. 测试组长统计测试情况并及时将 BUG 列表提交项目组 PM

　　9. 项目组及时更改程序并跟踪记录 BUG 的解决情况;

　　要求：项目组不长于 2 天的时间，提交一次软件新版本(以日期定义版本)给测试小组进行测试。新版本软件提交到配置库并及时通知测试组

　　2.5. 常规问题

　　2.5.1. 程序人员自测不严

　　程序人员在有测试人员的情况下，对于编码后的程序常不行全面的测试后就会抛给测试小组进行测试，使测试小组承担过多的责任，解决方式：程序人员进行单元测试，提供单元测试记录，加强程序严谨性;在一定(一天或两天)时间程序进行代码暂时封冻，程序员进行互测，使其了解自己编的程序到底如何或给项目领导进行演示，破坏其自我优越感。

　　2.5.2. 数据约束的合理性是桌前检查第一步

　　数据是否是约定条件范围内;对于越界处理是否正常;默认、空白、 null 值、零值的处理是否正常。

　　3. 软件的测试标准

　　对于软件的测试从以下几个方面考虑：

　　1. 用户需求的完整性：

　　是否根据用户所要求的业务流程，进行了相应的具体系统的实现。

　　2. 文档的完整性：

　　是否已经完成合同及约定所明确的所有的文档。

　　3. 通过测试(含准确性测试)

　　测试的第一步，测试系统能做什么工作。

　　4. 条件覆盖测试

　　测试的第二步，测试系统多方面考虑进行的如何。通过一定的测试数据明确是否进行了足够的条件覆盖，使系统达到足够的质量。

　　5. 数据约束的合理性：

　　数据是否是约定条件范围内;对于越界处理是否正常;默认、空白、 null 值、零值的处理是否正常。

　　6. 状态控制

　　进行系统和功能在不同状态下的处理，如数据库关机，客户机开机是否可以正常。

　　7. 软件常规性能及其它：

　　软件所需的操作环境及易使用性，可移植性、兼容性、错误恢复能力和可维护性等等是否为用户认可。

　　对于测试的结果有两种可能，一种可能是各种方面(主要是功能和性能指标)满足软件需求说明的要求，用户接受系统;另一种可能是软件不满足软件需求说明的要求，用户无法接受。对于这个阶段才发现的严重错误(一般指重要的业务逻辑)一般很难在预定的时间改正，因此必须与用户协商，寻求一个妥善解决问题的方法。

　　关于作者：

　　王辉，具有八年的编程及系统管理经验，所使用的语言为 C 和 Java 编程语言。目前在深圳一家公司做项目经理，使用 C 和 ORACLE 数据库开发应用系统。可通过 ddxxkk@21cn.com 联系。

　　4. 附录

　　4.1. 测试计划大纲

　　摘自 计算机软件 产品 开发文件编制指南 GB 8567-88

　　这里所说的测试，主要是指整个程序系统的组装测试和确认测试。本文件的编制是为了提供一个对该软件的测试计划，包括对每项测试活动的内容、进度安排、设计考虑、测试数据的整理方法及评价准则。具体的内容要求如下：

　　17 . 1 引言

　　17 . 1 . 1 编写目的

　　17 . 1 . 2 背景

　　17 . 1 . 3 定义

　　17 . 1 . 4 参考资料

　　17 . 2 计划

　　17 . 2 . 1 软件说明

　　17 . 2 . 2 测试内容

　　17 . 2 . 3 测试 1 (标识符)

　　17 . 2 . 3 . 1 进度安排

　　17 . 2 . 3 . 2 条件

　　17 . 2 . 3 . 3 测试资料

　　17 . 2 . 3 . 4 测试培训

　　17 . 2 . 4 测试 2 (标识符)

　　......

　　17 . 3 测试设计说明

　　17 . 3 . 1 测试 l (标识符)

　　17 . 3 . 1 . 1 控制

　　17 . 3 . 1 . 2 输入

　　17 . 3 . 1 . 3 输出

　　17 . 3 . 1 . 4 过程

　　17 . 3 . 2 测试 2 (标识符)

　　.......

　　17 . 4 评价准则

　　17 . 4 . 1 范围

　　17 . 4 . 2 数据整理

　　17 . 4 . 3 尺度

　　4.2. BUG 列表必要内容

　　包括错误程序名称及版本，错误主题，错误严重级别，测试过程描述，测试人，测试时间，修改结果，修改人，修改时间。

　　对于错误严重级别的分类说明如下：

　　· 严重错误：导致系统无法实现功能目标，使测试无法继续进行。主要包括：程序不能起动、程序非正常终止、程序死机、关键需求未实现、严重的数值计算错误、安全性错误、文档与软件严重不符。

　　· 中等错误：导致系统无法正常实现功能目标，但知道如何通过其它途径来避免错误发生。主要包括：程序非正常终止但可避免、系统边界值错误、非关键需求理解错误、系统文档错误。

　　· 轻微错误：导致用户 / 操作员使用不方便，但不影响系统功能目标的实现。主要包括：查询报告格式错误、用户界面不很友好、显示格式错误、轻微的数值计算错误、系统处理未优化、系统文档存在轻微错误等。

　　· 建议：使系统更加完善的建设性意见等。

　　4.3. 常用名词定义

　　白盒测试 ：如果已知产品的内部活动方式，可以测试它的内部活动是否都符合设计要求，这种方法叫白盒测试，检查软件的内部逻辑结构，是以仔细检查过程的细节为基础，通过提供一组指定条件和循环的测试用例，对穿过软件的逻辑路径进行测试，可以在不同点检查程序的状态，以确定实际状态与预期状态是否一致。

　　黑盒测试 ：着眼于软件的外部特性，而不考虑软件的内部逻辑结构。指在软件的接口上进行测试，即看它能否满足功能要求，输入能否被正确地接收，并正确的输出结果，以及能否保持外部信息(如数据文件)的完整性等等。

　　单元测试(模块测试) ：相当于分调，即逐个模块考察，是以详细设计描述为指南，对重要的控制路径进行测试，用以发现错误。使用白盒子测试法。

　　集成测试(组装测试或联合测试) ：相当于联调，主要是考察模块间的接口和各模块间的联系

　　确认测试(有效性测试) ：是验证软件的功能和性能及其它特点是否与用户的要求一致。功能与用户的需求是否一致。使用黑盒测试。

　　系统测试(系统联调) ：是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行(使用)环境下，对计算机系统进行一系列的组装测试和确认测试。

　　验收测试： 由用户实施，通过所谓黑盒子测试，来证实软件功能与描述的需求是否一致

　　回归测试 ：重复以前进行过的部分或全部测试

　　恢复测试： 是一种系统测试，它以不同的方式强使软件出现故障，用来严整软件能否恰当地完成恢复

　　安全性测试： 就是试图去验证建立在系统内的预防机制，以防止来自非正常的侵入。

　　强度测试： 实在要求一个非常数量、频率或容量资源方式下运行一个系统。它实际上是一种叫做敏感性测试技术

　　性能测试 ：就是测试软件在给组装进系统的环境下运行时的性能。性能测试应覆盖测试过程的每一步

　　测试用例： 一组最有可能发现某个错误或某类错误的测试数据

　　4.4. 关于α、β测试

　　事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为α、β测试的过程，以期发现那些似乎只有最终用户才能发现的问题。

　　α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品(称为α版本)进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。