新書推薦：
《
站在自己这边
》
售價：HK$
60.5
《
micro：bit 硬件编程快速入门与综合实战
》
售價：HK$
74.8
《
南宋新出碑志文献辑补
》
售價：HK$
217.8
《
香港私募基金合规运营Q&A
》
售價：HK$
79.2
《
故宫博物院百年百事
》
售價：HK$
140.8
《
天下的当代性：世界秩序的实践与想象
》
售價：HK$
94.6
《
中国ESG卓越实践（2024） 探索创新ESG中国实践的路径和方法
》
售價：HK$
217.8
《
大浪淘沙：从五代到十国（王宏杰五代史三部曲系列 一部生动而富有深度的乱世长卷 一幅反映人性的丰富画卷
》
售價：HK$
105.6
|
| 內容簡介： |
|
《软件测试与质量保证》*先从工程导入软件测试；其次从软件测试与软件生命周期的关系，循序渐进介绍软件测试的内容；*后从软件质量的角度阐述软件质量保证体系，明确软件测试与软件质量保证的关系，旨在为软件行业培养其需要的软件测试人才。《软件测试与质量保证》配套有完整的课程资源，包括课程标准、教学大纲、教学课件等。
|
| 目錄：
|
|
目录第1章 导论 11.1 软件工程与软件测试 11.1.1 工程 11.1.2 软件工程 11.1.3 软件测试 21.1.4 软件生命周期 31.2 软件质量与软件测试 61.2.1 质量革命 61.2.2 软件质量 61.2.3 SWEBOK中的软件质量与软件测试 71.3 软件缺陷 81.3.1 软件缺陷案例 81.3.2 软件失败、错误、故障、缺陷 101.3.3 软件缺陷的定义 111.4 软件测试与软件质量保证 111.5 确认与验证 111.6 测试用例 121.7 软件测试人员与组织 121.7.1 关于测试的错误认知 121.7.2 优秀软件测试人员应具备的素质 131.7.3 软件测试人员的组织 141.7.4 软件测试人员的职业发展路径 15本章小结 16本章思考题 16第2章 软件测试分类 172.1 基于测试阶段的划分 172.1.1 单元测试 172.1.2 集成测试 182.1.3 系统测试 182.1.4 验收测试 182.2 基于测试目标或特性的划分 192.2.1 功能测试 192.2.2 非功能测试 192.3 基于测试方法的划分 212.3.1 静态测试 212.3.2 动态测试 212.3.3 白盒测试 212.3.4 黑盒测试 222.4 基于被测对象的划分 222.5 其他类型的测试 232.5.1 回归测试 232.5.2 冒烟测试 232.5.3 国际化测试 242.5.4 即兴测试 242.5.5 云测试 242.5.6 众包测试 242.5.7 配置测试 252.5.8 探索性测试 262.5.9 智能化测试 26本章小结 27本章思考题 28第3章 软件测试的理论及测试有效性 293.1 三个著名的测试理论 293.1.1 Goodenough和Gerhart理论 293.1.2 Weyuker和Ostrand理论 323.1.3 Gourlay理论 333.2 测试的足够性 343.3 测试的局限性 35本章小结 35本章思考题 35第4章 软件测试方法与测试用例设计 374.1 白盒测试方法 374.1.1 控制流与数据流 374.1.2 逻辑覆盖法 394.1.3 基本路径测试 424.1.4 数据流测试 424.2 黑盒测试方法 444.2.1 等价类划分法 444.2.2 边界值分析法 484.2.3 决策表法 494.2.4 因果图法 524.2.5 功能图法 564.2.6 场景法 574.2.7 错误推测法 584.3 测试用例设计的测试方法选择策略 59本章小结 59本章思考题 59第5章 单元测试 605.1 静态单元测试 605.1.1 人工静态测试 605.1.2 静态分析工具 615.2 动态单元测试 635.2.1 桩模块 645.2.2 驱动模块 645.3 单元测试框架XUnit 645.3.1 JUnit 645.3.2 NUnit 645.3.3 CppUnit 655.3.4 PHPUnit 65本章小结 65本章思考题 65第6章 集成测试与系统测试 666.1 集成测试 666.1.1 接口类型和接口错误 666.1.2 集成测试粒度 676.1.3 集成测试目标 676.1.4 集成测试开展 676.1.5 集成测试方法 686.1.6 集成测试策略 696.1.7 集成测试优点 716.2 系统测试 726.2.1 功能测试 726.2.2 健壮性测试 726.2.3 性能测试 726.2.4 安全性测试 756.2.5 兼容性测试 766.2.6 可恢复性测试 776.2.7 用户界面测试 786.2.8 文档测试 81本章小结 82本章思考题 82第7章 软件测试过程与缺陷管理 837.1 测试基本过程 837.1.1 软件测试需求分析 837.1.2 软件测试计划 857.1.3 软件测试设计 867.1.4 软件测试实现与测试环境搭建 887.1.5 软件测试执行 897.1.6 软件测试评估 917.1.7 软件测试总结和报告 927.2 缺陷管理 937.2.1 软件缺陷管理流程 937.2.2 缺陷报告 997.2.3 缺陷确认 1047.2.4 缺陷解决 1047.2.5 缺陷测试 1057.2.6 缺陷关闭 105本章小结 107本章思考题 107第8章 自动化测试与测试自动化 1088.1 概述 1088.1.1 自动化测试的概念 1088.1.2 测试自动化的概念 1098.1.3 自动化测试的优势 1108.2 自动化测试的实施及实例 1118.2.1 实施自动化测试的前提条件 1118.2.2 自动化测试过程 1128.2.3 自动化测试实例 1178.3 自动化测试工具与测试自动化框架 1298.3.1 自动化测试工具 1298.3.2 测试自动化框架 1308.3.3 常用的自动化测试/测试自动化框架与工具 132本章小结 139本章思考题 140第9章 软件质量保证 1419.1 软件质量与质量保证 1419.1.1 软件质量 1419.1.2 软件质量保证 1439.2 软件质量保证体系 1459.2.1 软件质量管理标准 1479.2.2 能力成熟度模型 1519.3 软件过程改进 1549.4 软件过程质量度量 156本章小结 158本章思考题 159参考文献 160
|
| 內容試閱：
|
|
第1章 导论 当你翻开一本软件测试的书籍时会看到很多定义和术语，或者是当初次接触一个程序或者系统的测试时，你都会对软件测试的概念感到有些似是而非。软件测试究竟是什么？本书力图从工程的角度，追溯软件测试的发展和历史，多维度地思考，探索软件测试的全貌。 1.1 软件工程与软件测试 众所周知，软件测试是软件工程的一个分支，随着互联网和信息技术的快速发展，软件渗透到各行各业的各个领域，软件产品的需求量呈爆发式增长，为了给用户提供满意的软件产品，软件测试的重要性变得尤为突出。在本书开端，我们从工程开始娓娓道来，让读者对软件测试和软件工程的关系有初步的认识。 1.1.1 工程 工程在英文中称为engineering，和科学science有着截然不同的含义。工程是科学和数学的某种应用，通过这一应用，人类可以使自然界的物质和能源通过各种结构、机器、产品、系统和过程，以*短的时间和*少的人力、物力做出高效、可靠且有用的东西。工程是将自然科学的理论应用到具体工农业生产部门中形成的各学科的总称。 在现代社会中，“工程”一词有广义和狭义之分。就狭义而言，工程定义为“以某组设想的目标为依据，应用有关的科学知识和技术手段，通过有组织的一群人将某个(或某些)现有实体(自然的或人造的)转化为具有预期使用价值的人造产品的过程”。广义而言，工程则定义为“由一群人为达到某种目的，在一个较长时间周期内进行协作活动的过程”。 从这些定义中可以看到工程需要人和团队的协作，工程的最终产出物是产品，工程是一个活动的过程，这些要素在后述软件工程中也会涉及。 工程发展到今天有很多分支，常见的有化学工程、建筑工程、机械工程、电子工程等，软件工程也是其中的一个分支。 1.1.2 软件工程 从工程的广义概念引申出来，软件工程就是一群人为了生产软件产品，在一个较长时间周期内进行协作活动的过程。那什么是软件呢？举个例子，Windows和MacOS是操作系统软件，微软的Office是应用软件，腾讯微信是手机软件。很多人把软件这个术语和计算机程序混淆，Ian Sommerville(萨默维尔)在《软件工程》一书中给出了答案，软件是计算机程序和所有使这个程序正确运行所需的文档和配置信息。 很多人都编写过程序，例如业务人员编写电子表格程序来简化工作，科学家编写程序来处理实验数据等。然而绝大多数的软件开发是个专业化的活动，是为了特定的业务目的，作为软件产品进行开发的，如信息系统、嵌入式软件系统等。因此软件工程的目的是支持专业化的软件开发，而不是个体编程。它包括支持程序描述、设计和进化的相关技术。 计算机科学研究的是构成计算机和软件系统基础的有关理论与方法，而软件工程研究软件制作过程中的实际问题。理论上，所有软件工程都应该以计算机理论为坚实的基础，然而实际情况并非如此，软件工程人员常常需要用特定的方法和工具去开发软件。对于实际、复杂的问题，计算机科学的**理论不可能总是适用的，这就需要应用软件工程的方法去解决。 因此，软件工程发展到今天已经成为一门工程学科，它是研究如何用系统化、规范化、数量化等工程原则和方法去进行软件开发与维护的学科。 1.1.3 软件测试 在早期的软件开发中，软件大多结构简单、功能有限，那时的测试几乎等同于调试，调试倾向于解决编译和单个方法的问题。到20世纪50年代左右，随着软件规模越来越大，仅仅依靠调试无法解决软件可能存在的问题，还需要验证接口逻辑、功能模块，以及不同功能模块之间的耦合等，因此在这个阶段，人们往往将开发完成的软件产品进行集中测试，而此时由于还没有形成测试方法论，对软件测试也没有明确定位与深入思考，因此测试方法依旧较为简单，测试完成后还是可能存在大量问题。 之后，人们开始思考软件测试的真正意义，不同的概念和定义被不断提出。1973年，Bill Hetzel(黑泽尔)博士**次对软件测试进行了定义：软件测试是对程序或系统能否完成特定任务建立信心的过程。这个观点在软件质量概念提出后就不适用了。 1975年，John Goodenough(古迪纳夫)和Susan Gerhart(格哈特)在IEEE(Institute of Electrical and Electronics Engineers，电气与电子工程师学会)上发表了文章《测试数据选择的原理》，从此时开始，软件测试正式被确定为一个研究方向[1]。 1979年，G.J.Meyers(迈耶斯)博士等在《软件测试的艺术》一书中认为“软件测试是为了寻找错误而执行程序的过程”[2]。 1983年，IEEE在北卡罗来纳大学*次召开了关于软件测试的技术会议，对软件测试进行了如下定义：软件测试是使用人工或自动手段运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差异。IEEE的概念指明了测试是为了检验软件是否满足需求，它是一个需要经过设计、开发和维护等完整阶段的过程。 1983年，黑泽尔博士对其进行了修改：软件测试是一项鉴定程序或系统的属性或能力的活动，其目的在于保证软件产品的质量[3]。 2005年，Ron Patton(巴顿)在《软件测试(第2版)》中提出软件测试的目标是尽可能早地发现软件缺陷，并保证其得以修复[4]。 由此可见，软件测试的概念和定义随着时间的推移而不断发展和变化。为了尽可能早地发现软件错误，有必要把软件测试延伸到软件的需求分析、设计的整个软件生命周期，如需求分析文档和设计文档的评审。我们把传统的为了寻找错误而执行程序的过程的软件测试称为狭义的软件测试，把涉及整个软件生命周期的软件测试称为广义的软件测试。本书所说的软件测试都是指广义的软件测试。 1.1.4 软件生命周期 软件工程涉及软件产品生产的各个方面，软件工程中系统化的方法有时也称为软件过程(process)。软件过程是指软件产品的一组活动及其结果，这些活动主要由软件工程人员来完成。软件测试作为软件工程的一个分支，自然要涉及软件过程。 软件过程是复杂的，与所有创造性过程一样，依赖于人们的决策和判断，并不存在什么理想的软件过程，大多数机构都有自己的软件开发过程。虽然没有“理想”的软件开发过程，但在许多机构中仍然存在很大的改进软件过程的空间。关于软件过程改进我们会在后续的章节进一步介绍。 涉及软件产品生产的软件过程有时也称为软件生命周期。因为软件开发过程描述了软件产品从概念到实现、交付、使用和维护的整个过程。因此，有时把软件开发过程称为软件生命周期(software life cycle)。在有的书籍中也称为软件生存周期或者软件开发生命周期，在本书中统称为软件生命周期。 软件工程的研究人员对软件过程进行建模，在众多的软件工程文献中我们会看到常见的几种软件过程模型。在过程模型的介绍中可以看到软件测试和软件生命周期之间的关系，作为身处软件生命周期中的软件测试人员可以从中理解自己的角色和位置。 1.瀑布模型 瀑布模型(waterfall model)是研究人员提出的第一个模型，也是*传统的模型。如图1.1所示，它将软件的开发阶段描述为从一个阶段瀑布般地转换到另一个阶段，一个开发阶段必须在另一个开发阶段开始之前完成。 瀑布模型清晰地描述了软件过程的每个阶段的内容，所以一直用来规范软件开发活动。在帮助开发人员布置工作时它非常有用，它的简单性使得开发人员很容易向不熟悉软件开发的客户做出解释。很多其他更复杂的模型其实是在其基础上的润色，如加入反馈循环或者额外的活动。 传统的软件测试活动在瀑布模型中也清晰地分为单元测试、集成测试、系统测试、验收测试几个阶段。 图1.1 瀑布模型 2.V模型 V模型是瀑布模型的变种，它说明了测试活动是如何与分析和设计相联系的。如图1.2所示，编码处于V模型的顶点，分析和设计在左边，测试和维护在右边。单元测试和集成测试针对的是程序设计的正确性，即在单元测试和集成测试的过程中，编码人员和测试人员应当确保程序设计的所有方面都已经在代码中正确实现。同样地，系统测试应当遵循系统设计，保证系统设计的所有方面都得到了正确实现。验收测试是由客户而不是开发人员进行的，它通过把测试步骤与需求规格说明中的每一个要素关联起来对需求进行确认。这种测试检查在接收系统前，所有需求是否都已经完全实现。 图1.2 V模型 V模型中连接V形符号左右两边的连线意味着，如果在验证和确认期间发现了问题，那么在再次执行右边的测试步骤之前，重新执行左边的步骤以修改和改进需求、设计和编码。换言之，V模型使得隐藏在瀑布模型中的迭代和重做活动更加明确，瀑布模型关注的通常是文档和制品，V模型关注的则是活动和正确性。 3.敏捷方法 20世纪70—90年代提出的许多软件开发方法都试图在软件构思、文档化、开发和测试过程中加强严格性。然而在20世纪90年代后期一些抵制这种严格性的开发人员，系统地阐述了他们的原则，试图强调灵活性在快速有效的软件开发中的作用，这些思想被整理为“敏捷宣言”，概括为以不同的方式思考软件开发的四个原则。 (1)相对于过程和工具，更强调个人和交互的价值。 (2)更喜欢在生成运行的软件上花时间，而不是在编写各种文档上。 (3)将精力集中在与客户的合作上，从而让客户成为软件开发过程的一个关键方面。 (4)专注于对变化的反应，而不是创建一个计划，然后遵循这个计划，因为不可能在开发初期就预测到所有的需求。 敏捷开发的总体目标是“尽可能早地、持续地交付有价值的软件”，使客户满意。很多客户都有一些随时间变化的业务需求，不仅是在新发现的需求上，也有对市场快速变化的反应上。 目前典型的敏捷过程的方法有极限编程(extreme programming，XP)、水晶法、并列争球法和自适应软件开发(adaptive software development，ASD)。每一种方法都基于一套原则，这些原则体现了敏捷方法所宣称的理念(敏捷宣言)。 由于提出敏捷宣言的都是开发人员，在上述的原则中没有直接阐述软件测试的问题，但是有开发就有测试，伴随着敏捷开发的提出，敏捷测试也产生了。根据敏捷宣言的原则，可以概括出敏捷测试的特点如下。 (1)敏捷测试是敏捷开发的一部分，应符合敏捷宣言的思想，也遵守敏捷宣言的原则。强调测试人员的个人技能，始终与客户、其他人员(尤其是业务人员、产品设计人员等)紧密协作，建立良好的测试框架以适应需求的变化，更关注被测系统的本身而不是测试文档。 (2)敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发(test driven development，TDD)、验收测试驱动开发(acceptance test driven development，ATDD)。测试驱动开发是敏捷测试的核心，或者说单元测试是敏捷测试的基础。没有足够的单元测试就无法应对需求的快速变化，无法实现持续的交付。在敏捷测试中，开发人员可以承担更多测试，可以没有专职的测试人员，每个人都可以去完成设计、开发或者测试任务。测试人员可以像开发人员的结对编程那样，实践结对测试—一个测试人员对应一个开发人员或者一个测试人员对应另一个测试人员。 (3)敏捷测试无处不在、无时不在。在传统测试中也提倡尽早测试，如需求和设计的评审等，但传统测试中的阶段性特征更突出一些。在敏捷测试中，团队每一天都在一起工作，一起讨论需求，一起评审需求。在敏捷测试中这种持续性更为显著。 (4)敏捷测试是基于自动化测试的。自动化测试在敏捷测试中占有绝对的主导地位，敏捷测试的持续性迫切要求测试的高度自动化。没有自动化就没有
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
