软件的最低测试方法--黑盒測試與白盒測試

软件的最低测试方法(2008-02-20 11:13:37)

标签：it  

 

 前言 

　　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. 关于α、β测试

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

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

本文转自：http://www.testage.net/html/91/n-141991-2.html 

 

软件测试常用的功能测试方法(2008-02-20 11:18:13)

标签：软件测试 it  分类：IT

 

 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。针对Web系统的常用测试方法如下： 

　　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. 回车键检查：在输入结束后直接按回车键，看系统处理如何，会否报错。

本文转自:http://www.testage.net/html/64/n-141364-2.html

 

黑盒测试的测试用例设计方法(2008-02-20 11:23:28)

标签：黑盒测试 it  分类：IT

 

 

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

等价类划分

边界值分析

错误推测法

因果图

功能图

一、等价类划分

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

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

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

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

在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。

在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，则可以确立一个有效等价类和一个无效等价类。

在输入条件是一个布尔量的情况下，可以确立一个有效等价类和一个无效等价类。

在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可以确立n个有效等价类和一个无效等价类。

在规定了输入数据必须遵守的规则的情况下，可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。

在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。

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

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

为每一个等价类规定一个唯一的编号

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

设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

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

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

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

a) 整数

b) 3个数

c) 非零数

d) 正数

e) 两边之和大于第三边

f) 等腰

g) 等边

2）列出等价类表并编号

 

 

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

 

二、边界值分析法

使用边界值分析方法设计测试用例，首先：应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。其次，应但选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

基于边界值分析方法选择测试用例的原则：

如果输入条件规定了值的范围，应取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入的数据。

如果输入条件规定了值的个数，应用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试输入的数据。

根据规格说明的每个输出条件，使用前面的原则1。

根据规格说明的每个输出条件，使用前面的原则2。

如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例数据。

如果程序中使用了一个内部数据结构，应当选择这个内部数据结构边界上的值作为测试用例。

分析规格说明，找出其他可能的边界条件。

三、错误推测法

错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

基本思路：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例。例如：输入数据和输出数据为0的情况。

例：现有一个学生标准化考试批阅试卷，产生成绩报告的程序。其规格说明如下：程序的输入文件由一些有80个字符的记录组成，所有记录分为3组，如图：

 

 

1、标题：改组只有一个记录，其内容是成绩报告的名字。

2、各题的标准答案：每个记录均在第80个字符处标以数字2。该组的记录：

第一个记录：第1~3个字符为试题数（1~999）。第10~59个字符是1~50题的标准答案（每个合法字符表示一个答案）。

第二个记录：是第51~100题的标准答案。

…….

3、学生的答案：每个记录均在第80个字符处标以数字3。每个学生的答卷在若干个记录中给出。

学号：1~9个字符

1~50题的答案：10~59。当大于50题时，在第二、三、……个记录中给出。

学生人数不超过200，试题数不超过999。

程序的输出有4个报告：

a)按学号排列的成绩单，列出每个学生的成绩、名次。

b)按学生成绩排序的成绩单。

c)平均分数及标准偏差的报告

d)试题分析报告。按试题号排序，列出各题学生答对的百分比。

解答一：采用边界值分析方法，分析和设计测试用例。分别考虑输入条件和输出条件，以及边界条件。下表列出了输入条件及相应的测试用例。

 

下表为输出条件及相应的测试用例表。

 

 

解答二：采用错误推测法还可补充设计一些测试用例：

程序是否把空格作为回答

在回答记录中混有标准答案记录

除了标题记录外，还有一些的记录最后一个字符即不是2也不是3

有两个学生的学号相同

试题数是负数。

四、 因果图法

因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法。

利用因果图生成测试用例的基本步骤：

 分析软件规格说明描述中那些是原因，那些是结果，并给每个原因和结果赋予一个标识符。

分析软件规格说明描述的语义。找出原因和结果之间、原因和原因之间的关系，根据这些关系，画出因果图。

 在因果图上用一些记号表明约束或限制条件。

把因果图转换为判定表。

把判定表的每一列拿出来作为依据，设计测试用例。

例：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。

解1、画出因果关系表和因果图。

 

2、根据因果图建立判定表。

按条件的各种组合情况产生对应的动作。原因1和原因2不能同时成立，故可排除这种情况。

从判定表可设计出测试用例：6个测试用例是所需的数据。

 

本文转自:http://www.testage.net/html/64/n-18364.html

 

黑盒测试和白盒测试之间的区别

 

任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。

 

　　黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。

 

　　白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。

 

　　软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性

，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下

几类错误：

 

　　1、是否有不正确或遗漏的功能？

 

　　2、在接口上，输入是否能正确的接受？能否输出正确的结果？

 

　　3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

 

　　4、性能上是否能够满足要求？

 

　　5、是否有初始化或终止性错误？

 

　　软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有

关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称

为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：

 

　　1、对程序模块的所有独立的执行路径至少测试一遍。

 

　　2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

 

　　3、在循环的边界和运行的界限内执行循环体。

 

　　4、测试内部数据结构的有效性，等等。

 

　　以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测

试，在未发现错误时，不能说明程序中没有错误。

本文转自:http://www.testage.net/html/73/n-140373.html