信息系统测试(谢石长生)

《信息系统测试》 读书报告

学 生 姓 名：谢石长生 学 班 号：[1**********]0 级：1430601

指 导 教 师：吴志强

2016 年 12 月 28 日

前言

本系统测试报告将对信息系统测试这门课做一个总体概要及总结，对系统测 试的定义、方法、类别、步骤流程等做一个梳理，让同学们对这门课有更清楚的 认识， 同时还对不同的方法进行一个具体的实例测试， 以此对各测试方法进行对 比。

一、学习心得

软件测试是软件开发过程中的一个重要组成部分，是贯穿整个软件开发生命 周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程，其目的是尽 快尽早地发现在软件产品中所存在的各种问题——与用户需求、 预先定义的不一 致性。 软件测试的主要分类 1、从是否需要执行被测试软件的角度分类（静态测试和动态测试）。 2、从测试是否针对软件结构与算法的角度分类（白盒测试和黑盒测试）。 3、从测试的不同阶段分类（单元测试、集成测试、系统测试、验收测试）。 常见测试方法： 回归测试，功能测试，压力测试，负载测试，性能测试，易用性测试，安装与反 安装测试，回复测试，安全性测试 ，兼容性测试，内存泄漏测试 ，比较测试， Alpha 测试，Beta 测试，测试信息流。 测试流程依次如下： 1.需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。 --testing team 2.测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点 划分、如何合理分配安排资源等。---testing leader or testing manager 3.用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。 ---testing leader, senior tester 4.执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要 是初级测试人员) 5.执行结果记录和 bug 记录：对每个 case 记录测试的结果，有 bug 的在测试管 理工具中编写 bug 记录。--every tester(主要是初级测试人员) 6.defect tracking： 追踪 leader 分配给你追踪的 bug.直到 bug fixed。 --every tester 7.测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重 大 bug. 8.用户体验、软件发布等„„ 通过此次学习，对整个软件测试行业的了解大大的加深。以前认为软件测试 只是枯燥的反复的使用被测试软件来发现异常的问题，以为软件测试并不重要， 低开发一等。 现在认识到了软件测试的重要性，软件测试是软件产业向软件工业 化生产时代迈进不可缺少的重要组成部分， 是保证软件质量达到客户需求不可缺 少的环节。软件测试在国内是一个新的职业，发展得比较晚，但它的重要性正在 为行业所重视。 在学习过程中，我了解了作为一个合格的测试人员所应具备的 素质与技能。 其中个人素质在测试工作中起到了非常重要的作用，它包括你的信 心、耐心、细心和与人交流沟通的能力，它将贯穿你工作生涯的整个过程。在测

试理论上，我们系统学习了软件测试的流程，各种测试阶段和测试方法，以及测 试工具的使用。通过这些课程的学习，让我们对软件工程也有了更深刻的理解， 为以后的测试工作作了很好的理论储备和技能的提升。 软件测试作为软件开发 过程中一个非常重要的环节， 越来越成为软件开发商和用户关注的焦点。完善的 测试是软件质量的保证， 因此软件测试就成了一项重要而艰巨的工作，要做好这 项工作当然也绝非易事，我在做软件测试工作中总结出了一些经验和技巧。 1.功能点的细化。在进行测试前，先将所要测试的功能细分，填写《测试 用例表》 ，有针对性的运行功能测试案例，逐个对每个功能细分点进行测试。在 每次运行测试案例之前， 明确此次运行的目的和预期的输出结果， 并要做好记录。 2.注意测试中的错误集中发生的现象有一些错误是和程序开发人员的编程 水平和习惯有很大关系的。例如程序中的拼写错误，习惯用法等。注意收集并记 录这些现象，有助于更快、更多地发现类似的错误。 3.尽可能多的使用非常规的测试，充分考虑到各种合法的输入和不合法的输 入以及各种边界条件。 边界值往往是最容易出现异常的情况，特殊的情况下甚至 要制造极端的状态和意外状态，比如网络突然中断，和电源突然断电等情况。 4.对测试错误结果一定要有一个确认的过程，一般有 A 测试出来的错误，一 定要有一个 B 来确认。 5.制定严格的测试计划。测试时间安排的尽量宽松，不要希望在极短的时间 内完成一个高水平的测试。 6.回归测试的关联性一定要引起充分的注意。在开发人员刚修复 Bug 之后的 地方， 再找一找， 往往开发人员只修复报告出来的缺陷而不去考虑别的功能在修 改时可能会重新造成错误。修改一个错误而引起更多的错误出现的现象并不少 见。 7.测试文档要尽可能详细。 《测试用例表》中的功能点可尽量的详细，如实、 详细地记录每次运行测试案例的输入数据，输出数据，出错提示，进行测试的时 间，完成测试的时间等，便于以后对测试工作的回溯。 8.重视交流和沟通。 包括和程序开发人员的交流， 同是测试人员之间的交流， 网上技术论坛和网友的交流，和客户的交流等。多思考，多交流，多提问，通过 多种沟通交流的途径，可以少走很多弯路，同时可以学到很多东西。 9.善于总结。在测试过程中发现的所有问题，异常情况，发现程序开发人员 易犯，常犯的错误，各种有价值的经验教训，使用系统和操作数据库时发现或者 学到的技巧， 使用测试工具时的心得等等， 都可以随手记录在笔记本或者电脑上。 这些都将是今后工作中可以参照的珍贵资料，同时也会成为自己的宝贵经验。 这次软件测试实训为我们以后从事软件测试工作打下了良好的专业基础，为 我们的进一步学习提高打下了扎实的理论基础。对测试过程有了初步的认识，测 试计划、测试设计、测试开发、测试执行、测试评估、测试报告贯穿整个软件开 发过程。单元测试、集成测试、系统测试、验证测试每个阶段都应以用户需求为 依据。这些基本的概念虽然比较抽象，但对以后的实践是大有益处的。 总的来 说，这次培训效果不错，对自己有一定的提升，这完全不同与学校的学习，因为 它更加贴近工作， 针对以后工作的内容作了很多实例的练习与工具的使用，为我 们更快的加入工作提供的很好的前提。接下来一段时间，我将利用假期进入相关 测试部门进行实际项目的训练， 我相信在我有了很好的理论基础后，会在工作中 很好的加以应用，让测试工作做得更好。同时，我会更加努力的学习与工作，遇 到问题会及时多渠道寻找解决方法，积极上进，希望早日成为一名优秀的测试人

员。

二、具体实例

黑盒测试 黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。 在测试中， 把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内 部特性的情况下， 在程序接口进行测试，它只检查程序功能是否按照需求规格说 明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。 黑盒测试着眼于程序外部结构， 不考虑内部逻辑结构，主要针对软件界面和软件 功能进行测试。 黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出 发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误， 用黑盒测试方法是发现不了的。 边界值分析法 所谓边界值分析，就是选择这样的测试用例，它能使被测程序在边界值及其 附近运行，从而更有效地暴露程序中隐藏的错误。因为经验告诉我们，程序常常 在处理边界情况时易于犯错误， 所以检查边界情况的测试用例往往是高效的。所 以输入等价类和输出等价类就是我们应着重测试的边界情况。应当选取正好等 于、 刚刚大于或刚刚小于边界的值作为测试数。 边界值分析法与等价类划分法 有两个方面的区别： （1）边界值分析法不是从某个等价类中随便设计一个数据作为测试用例，而是 选出一个或多个数据，使得这个等价类的每个边界值都要作为测试数据； （2）边界值分析法不仅要考虑程序的输入空间，而且要根据输出空间设计测试 用例。 用边界值分析法设计测试用例时，有以下几条原则： （1）如果输入条件规定了值的范围，则取刚达到这个范围的边界的值，以及刚 刚超出范围的无效数据作为测试用例。 例如输入值的范围为-100~+100，则可 以选取-100、+100、-101、+101 作为测试数据。 （2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多 1、比最小个数少 1 的数作为测试用例。 例如有规定“某文件可包括 1 至 255 个记录„” ，则测试数据可选 1 和 255 及 0 和 256 等值。 （3） 对每个输出条件使用第 （1） 条原则。 例如有个程序计算每月的保险金额， 若最小额是 0 元， 最大额是 1000 元，那么就应设计导致扣除 0 元和 1000 元的测 试数据。另外还应考虑是否可设计使程序扣除负额或大于 1000 元的测试数据。 （4）对每个输出条件使用第（2）条原则。 例如一个情报检索系统根据某一输 入请求，显示有关文献的摘要，但不能多于 4 条摘要，那么就可以设计一些测试 用例，使得程序分别显示 1 篇、4 篇或 0 篇摘要，并设计一个有可能使程序错误 地显示 5 篇摘要的测试用例。 （5）如果程序的输入域或输出域是个有序集合，则应选取集合的第一个元素和 最后一个元素作为测试用例。 （6）如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边 界上的值作为测试用例。 例如，如果程序中定义了一个数组，其元素下标的下 界是 0，上界是 100，那么应选择达到这个下标边界的值，如 0 与 100 作为测试 用例。 （7）分析规格说明，找出其它可能的边界条件。

测试用例及结果 例：有函数 f(x,y,z)，其中 x∈[1900,2100]，y∈[1,12]，z∈[1,31]的。请写 出该函数采用边界值分析法设计的测试用例。 用例编号 1 2 3 4 5 6 7 8 测试用例编号 输入 x=1900 y=1 z=1 x 1900 2100 1899 2101 1900 1900 2100 2100 y 1 12 1 12 0 1 13 12 1 操作 函数调用并计算 预期输出 f(1900,1,1) 实际输出 f(1900,1,1) z 1 31 1 31 1 0 31 32

测试用例编号 输入 x=2100 y=12 z=31

2 操作 函数调用并计算 预期输出 f(2100,12,31) 实际输出 f(2100,12,31)

测试用例编号 输入 x=1899 y=1 z=1

3 操作 函数调用并计算 预期输出 Error 实际输出 Error

测试用例编号 输入 x=2101 y=12 z=3

4 操作 函数调用并计算 预期输出 Error 实际输出 Error

测试用例编号 输入 x=1900 y=0 z=1

5 操作 函数调用并计算 预期输出 Error 实际输出 Error

测试用例编号 输入 x=1900 y=1 z=0

6 操作 函数调用并计算 预期输出 Error 实际输出 Error

测试用例编号 输入 x=2100 y=13 z=31

7 操作 函数调用并计算 预期输出 Error 实际输出 Error

测试用例编号 输入 x=2100 y=12 z=32

8 操作 函数调用并计算 预期输出 Error 实际输出 Error

因果图法 定义：从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果 （输出或程序状态的改变），可以通过因果图转换为判定表。因果图法即因果分 析图，又叫特性要因图、石川图或鱼翅图，它是由日本东京大学教授石川馨提出

的一种通过带箭头的线， 将质量问题与原因之间的关系表示出来，是分析影响产 品质量的诸因素之间关系的一种工具。 有一个处理单价为 5 角钱的饮料的自动售货机软件测试用例的设计。 其规格说明如下： 若投入 5 角钱或 1 元钱的硬币，押下〖橙汁〗或〖啤酒〗的按钮，则相应的饮料 就送出来。若售货机没有零钱找，则一个显示〖零钱找完〗的红灯亮，这时在投 入 1 元硬币并押下按钮后，饮料不送出来而且 1 元硬币也退出来；若有零钱找， 则显示〖零钱找完〗的红灯灭，在送出饮料的同时退还 5 角硬币。 1、分析这一段说明，列出原因和结果： 这本身只是一个实例，只是用来学习，其实其设计说明还是存在好多漏洞的，例 如：如果售货机里没有饮料了怎么办？ 原因： 1、售货机有零钱找 2、投入 1 元硬币 3、投入 5 角硬币 4、押下橙汁按钮 5、押下啤酒按钮 结果： 21、售货机〖零钱找完〗灯亮 22、退还 1 元硬币 23、退还 5 角硬币 24、送出橙汁饮料 25、送出啤酒饮料 2、画出因果图，如图 3-2 所示。 所有原因结点列在左边，所有结果结点列在右边。建立中间结点，表示处理的中 间状态。中间结点： 11、投入 1 元硬币且押下饮料按钮 12、押下〖橙汁〗或〖啤酒〗的按钮 13、应当找 5 角零钱并且售货机有零钱找 14、钱已付清

图 3-2 售货机因果图 3、转换成判定表：

白盒测试 白盒测试 (White-box Testing，又称逻辑驱动测试,结构测试) 是把测试 对象看作一个打开的盒子。 利用白盒测试法进行动态测试时，需要测试软件产品 的内部结构和处理过程， 不需测试软件产品的功能。白盒测试又称为结构测试和 逻辑驱动测试。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。 其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合 覆盖和路径覆盖。 例：输入 x,y 的值，求出 m.n 及 logic 的值，并求判定路径。

本文将用语句覆盖及判定覆盖两种测试方法对该案例进行测试，并得出测试 结果。 语句覆盖是指选择足够的测试用例，使得程序中每个语句至少执行一次。如 上例选择测试用例 x=1,y=1 和 x=1,y=-1 可覆盖所有语句。

x=1,y=1;

x=1,y=-1;

判定覆盖是指选择足够的测试用例，使得程序中每一个判定至少获得一次 “真”值和“假”值，从而使得程序的每个分支都通过一次（不是所有的逻辑路 径） 。选择测试用例 x=1,y=1 和 x=1,y=-1 可覆盖所有判定。

x=1,y=-1;

x=-1,y=-1;

大爆炸集成：一次性的将所有的模块集成在一起，发现并清除在模块连接过程中出现的问题得到最终要求的软件系统。

优点：

① 可以并行调试所有模块。

② 需要的测试用例数目少。

③ 测试方法简单、易行。

缺点:

① 不能充分对各个模块之间的接口进行充分测试。

② 不能很好的对全局数据结构进行测试。

③ 在出现错误时，定位错误比较困难。

④ 即使集成测试通过，也会遗漏很多错误。

自顶向下集成：自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。

优点：

① 在测试的过程中，可以较早地验证主要的控制和判断点。

② 选择深度优先组合方式，可以首先实现和验证一个完整的软件功能。 ③ 能够较早的验证功能可行性，给开发者和用户带来成功的信心。

④ 只有在个别情况下，才需要驱动程序（最多不超过一个），减少了测试驱动程序开发和维护的费用。

⑤ 可以和开发设计工作一起并行执行集成测试，能够灵活的适应目标环境。 ⑥ 容易进行故障隔离和错误定位。

缺点：

① 底层组件的需求变更可能会影响到全局组件，需要修改整个系统的多个上层模块。

② 要求控制模块具有比较高的可测试性。

③ 可能会导致底层模块特别是被重用的模块测试不够充分。

自下而上集成：自底向上集成是从系统层次结构图的最底层模块开始进行组装和集成测试的方式。

优点：

① 最先对下层模块进行测试，减少了回归测试的成本。

② 可以并行测试，提高了测试的效率。

③ 支持故障隔离。

缺点：

① 上层驱动模块的开发工作量大。

② 不能被及时发现高层模块设计上的错误，修改设计代价大。

③ 上层系统复杂，对于底层的异常将很难覆盖。

集成测试

集成测试案例：拼图游戏

其案例测试的相关函数名、参数、作用见下图