一、软件测试概述
1.1 软件、软件危机和软件工程
程序是指按特定的功能和性能要求而设计的能够执行的指令序列；
数据是指程序能正常操纵、处理的信息及其数据结构；
文档是指与程序设计开发、维护和使用有关的图文材料。
软件危机：
（1）软件生产不能满足日益增长的软件需求，软件生产率远低于硬件生产率和计算机应用的增长率，社会出现了软件供不应求的局面。更为严重的是，软件生产效率随软件生产规模的增加和软件复杂性的提高而急剧下降。
（2）软件生产率随软件规模与复杂性提高而下降，智力密集型行业的人力成本不断增加，这些都导致软件成本在计算机系统成本构成中的比例急剧上升。
（3）软件开发的进度与成本失控。人们很难估计软件开发的成本与进度，通常情况是预算成倍突破，项目计划一再延期。软件开发单位为了赶进度、节约成本，往往只有降低软件质量。软件开发陷入成本居高不下、质量无保证、用户不满意、开发单位信誉降低的怪圈中。
（4）软件系统实现的功能与实际需求不符。软件开发人员对用户需求缺乏深入的理解，往往急于编写程序，闭门造车，最后完成的软件与用户需求相距太远。
（5）软件难以维护。程序中的错误很难改正，要想使软件适应新的运行环境几乎不可能，软件在使用过程中不能增加用户需要的新功能，大量的软件开发人员在重复开发基本类似的软件。
（6）软件文档配置没有受到足够的重视。软件文档包括开发过程各阶段的说明书、数据词典、程序清单、软件使用手册、维护手册、软件测试报告和测试用例等。这些软件文档的不规范、不健全是造成软件开发的进度、成本不可控制和软件的维护、管理困难的重要原因。
1.2 软件工程的目标及其一般开发过程
从狭义上说，软件工程的目标是生产出满足预算、按期交付、用户满意的无缺陷的软件，进而当用户需求改变时，所生产的软件必须易于修改。从广义上说，软件工程的目标就是提高软件的质量与生产率，最终实现软件的工业化生产。
一般软件生存周期包括问题的定义、软件开发、软件测试、软件使用与维护等几个阶段。
- 问题的定义可分为软件系统的可行性研究和需求分析两个阶段，其基本任务是确定软件系统的工程需求。可行性研究的任务是了解用户的要求及实现环境，从技术、经济和社会等几个方面研究并论证软件系统的可行性。需求分析的任务是确定所要开发软件的功能需求、性能需求和运行环境约束，编制软件需求规格说明书、软件系统的确认测试准则。
- 软件测试过程分单元测试、集成测试、系统测试以及验收测试4个阶段进行。
1.3 软件过程模型
-
瀑布过程模型
瀑布过程模型
-
螺旋过程模型
螺旋过程模型
螺旋过程模型优点：（1）规避风险；（2）在早期构造软件的局部版本时即交给客户以获得反馈；（3）避免像瀑布过程模型一样一次集成大量的代码。（4）能够在每次迭代中都收集到过程中产生的各种度量数据。
-
增量过程模型
增量过程模型
- 快速原型过程模型
在快速原型过程模型中，首先是快速进行系统分析，在设计人员和用户的紧密配合下，快速确定软件系统的基本要求，尽快实现一个可运行的、功能简单的原型系统，然后对原型系统逐步求精、不断扩充完善得到最终的软件系统。快速原型过程模型主要优点在于它是一种支持用户的方法，它使用户在系统生存周期的设计阶段起到积极的作用，并能减少系统开发的风险。 - 敏捷过程模型
在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
1.4 软件缺陷与软件故障
软件错误是指在软件生存期内的不希望出现或不可接受的人为错误，软件错误导致软件缺陷的产生。
软件缺陷是存在于软件（文档、数据、程序）之中的不希望出现或不可接受的偏差，软件缺陷导致软件在运行于某一特定条件时出现软件故障，这时软件缺陷被激活。
软件故障是指软件在运行过程中产生的不希望出现或不可接受的内部状态，对软件故障若无适当措施（容错）加以及时处理，就会使软件失效。
软件失效是指软件在运行时产生的不希望出现或不可接受的外部行为结果。
1.5 软件质量与质量模型
软件质量是与软件产品满足明确或隐含需求的能力有关的特征和特性的总和。
其含义有以下4个方面：
- 能满足给定需求的特性。软件需求是衡量软件质量的基础，不符合需求的软件就不具备好的质量。设计的软件应在功能、性能等方面都符合要求，并可靠地运行。
- 具有所期望的各种属性的组合的程度，即软件结构良好，合理地利用系统资源，易读、易于理解，并易于修改，方便软件的维护。
- 能满足用户综合期望的程度，软件系统具有友好的用户界面，便于用户使用。
-
软件的组合特性。软件生存周期中各阶段文档齐全、规范，便于配置管理。
常见的3个质量模型：McCall模型、Boehm模型和ISO 9126。
McCall模型
软件测试
软件测试定义：使用人工或自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果之间的差别。
软件测试的原则：
尽早测试；全面测试；全过程测试；独立的、迭代的测试；Pareto原则：测试发现的错误中80%很可能起源于20%的模块中；对测试出的错误结果一定要有一个确认的过程；制订严格的测试计划；完全测试是不可能的，测试需要终止；妥善保存一切测试过程文档；注意回归测试的关联性。
软件测试过程模型
-
V模型
V模型
V模型局限性：它仅仅把测试作为在编码之后的一个阶段，是针对程序运行的寻找错误的活动，而忽视了测试活动对需求分析、系统设计等活动的验证和确认的功能。
-
W模型
W模型
W模型局限性：在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发工作复杂多变的情况，W模型并不能解除测试管理面临的困惑。
-
X模型
X模型
-
H模型
H模型
软件测试的分类
（1）功能测试。功能测试主要针对产品需求说明书对软件进行测试，验证软件功能是否符合需求，包括对原定功能的检验以及测试软件是否有冗余功能、遗漏功能。
（2）健壮性测试。健壮性测试侧重于对程序容错能力的测试，主要是验证程序在各种异常情况下是否能正确运行，包括数据边界测试、非法数据测试、异常中断测试等。
（3）接口测试。接口测试是对各个模块进行系统联调的测试，包括程序内接口测试和程序外接口测试。在接口测试中，测试人员在单元测试阶段进行一部分工作，大部分工作是在集成测试阶段完成的。
（4）性能测试。性能测试主要测试系统的性能是否满足用户要求，即在特定的运行条件下验证系统的能力状况。性能测试主要是通过自动化的测试工具模拟正常、峰值以及异常负载状况，对系统的各项性能指标进行测试，测试中得到的负荷和响应时间等数据可以被用于验证软件系统是否能够达到用户提出的性能指标。
（5）强度测试。强度测试是一种性能测试，强度测试总是迫使系统在异常的资源配置下运行。强度测试的目的是找出因资源不足或资源争用而导致的错误。
（6）压力测试。压力测试是一种性能测试，主要是在超负荷环境中，检验程序是否能够正常运行。压力测试的目的是检测系统在资源超负荷的情况下的表现，是通过极限测试方法，发现系统在极限或恶劣环境中的自我保护能力。压力测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，压力测试还要评估软件的性能特征，例如响应时间、事务处理速率和其他与时间相关的性能特征。
（7）用户界面测试。用户界面测试主要对系统的界面进行测试，测试用户界面是否友好、软件是否方便易用、系统设计是否合理、界面位置是否正确等问题。
（8）安全测试。安全测试主要测试系统防止非法侵入的能力，例如测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何运行，是否能够保证数据的安全。
（9）可靠性测试。可靠性测试是指为了保证和验证软件的可靠性水平是否满足用户的要求而进行的测试，即确定软件是否满足软件规格说明书中规定的可靠性指标。软件可靠性测试的目的是给出可靠性的定量估计值，通过对软件可靠性测试中观测到的失效数据进行分析，可以评估当前软件可靠性的水平，验证软件可靠性是否达到要求。软件可靠性测试是一项高投入的测试工作，通常需要进行大量的测试。
（10）安装/反安装测试。安装测试主要检验软件是否可以正确安装，安装文件的各项设置是否有效，安装后是否影响整个计算机系统；反安装测试是逆过程，测试软件是否被删除干净，删除后软件是否影响整个计算机系统等。（11）文档测试。文档测试主要检查内部/外部文档的清晰性和准确性，对外部文档而言，测试工作主要针对用户的文档，以需求说明、用户手册、安装手册等为主，检验文档是否和实际应用存在差别，而且还必须考虑文档是否简单明了，相关的技术术语是否解释清楚等问题。
（12）恢复测试。恢复测试主要测试当出现系统崩溃、硬件错误或其他灾难性问题时系统的表现情况，以及系统从故障中恢复的能力。
（13）兼容性测试。兼容性测试主要测试软件产品在不同的平台、不同的工具软件或相同工具软件的不同版本下的兼容性，其目的是测试系统与其他软件、硬件兼容的能力。
（14）负载测试。负载测试是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征。例如，响应时间、事务处理速率和其他与时间相关的方面。
软件测试流程
制订测试计划、设计测试、测试准备、测试环境的建立、执行测试、评估测试和总结测试。
- 测试计划包括：
（1）软件测试背景。软件测试背景主要包括软件项目介绍、项目涉及人员（如项目负责人等）介绍以及相应联系方式等。
（2）软件测试依据。软件测试依据主要包括软件需求文档、软件规格书、软件设计文档等。
（3）测试范围的界定。测试范围的界定就是确定测试工作需要覆盖的范围。在实际工作中，人们总是不自觉地调整软件测试的范围，比如在时间紧张的情况下，通常优先完成重要功能的测试。所以测试计划者在接收到一项任务的时候，需要根据主项目计划的时间来确定测试范围。如果在确定范围上出现偏差，会给测试执行工作带来消极的影响。
（4）风险的确定。项目中总是有不确定的因素，这些因素一旦发生之后，会对项目的顺利执行产生很大的影响。所以在项目开发中，首先需要识别出存在的风险。
（5）测试资源。确定完成任务需要消耗的人力资源、物资资源，主要包括测试设备需求、测试人员需求、测试环境需求以及其他资源需求。
（6）测试策略。测试策略主要包括采取测试的方法、搭建哪些测试环境、采用哪些测试工具和测试管理工具、对测试人员进行培训等。
（7）时间表的制订。在识别出子任务和估计出测试资源之后，可以将任务、资源与时间关联起来形成测试时间进度表。
（8）其他。测试计划还要包括测试计划编写的日期、作者信息等内容。 - 设计测试
测试的设计阶段要设计测试用例和测试过程，要保证测试用例完全覆盖测试需求。
测试用例是为特定目标开发的测试输入、执行条件和预期结果的集合，这些特定目标可以是验证一个特定的程序路径，也可以是核实某项功能是否符合特定需求。
测试用例的标准： 是否可以发现尚未发现的软件缺陷？是否可以覆盖全部的测试需求？ - 测试准备和测试环境的建立
测试准备主要包括全面准确掌握各种测试资料，进一步了解、熟悉测试软件，配置测试的软、硬件环境，搭建测试平台，充分熟悉和掌握测试工具等工作。 - 测试评估
测试评估的主要方法包括缺陷评估、覆盖评测和质量评测。
（1）缺陷评估。严格的评估是用测试过程中缺陷达到的比率或发现的比率表示。
（2）覆盖评测。覆盖评测是对测试完全程度的评测，它是由测试需求和测试用例的覆盖与已执行代码的覆盖表示的。简而言之，测试覆盖是就需求（基于需求的）或代码的设计/实施标准（基于代码的）而言的完全程度的任意评测。
（3）质量评测。质量评测是对测试软件的可靠性、稳定性以及性能的评测，主要的性能评测包括动态监测、响应时间/吞吐量、百分位报告、比较报告以及追踪和配置文件报告。
网友评论