|
|
|
在软件测试阶段，重点考查软件测试的目的、负载压力测试、测试V模型及测试的类型等知识点。
|
|
|
|
|
|
软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。
|
|
|
|
1983年，Bill Hetzel在《Complete Guide of Software Testing》一书中指出：“测试是以评价一个程序或系统属性为目标的任何一种活动。测试是对软件质量的度量”。Grenford J. Myers在《The Art of Software Testing》一书中指出：
|
|
|
|
|
|
（2）测试是为了证明程序有错，而不是证明程序无错误。
|
|
|
|
（3）一个好的测试用例在于它能发现至今未发现的错误。
|
|
|
|
（4）一个成功的测试是发现了至今未发现的错误的测试。
|
|
|
|
这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。
|
|
|
|
首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。
|
|
|
|
其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
|
|
|
|
因此，软件测试可以验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及软件质量特性的要求，为软件质量的评价提供依据。
|
|
|
|
软件测试只是软件质量保证的手段之一，不能单凭测试来保证软件质量。
|
|
|
|
|
|
|
|
|
|
动态测试是指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法等。
|
|
|
|
|
|
把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试，使用这种方法，为了做到穷尽测试，至少必须对所有输入数据的各种可能值的排列组合都进行测试。黑盒测试使用所有有效和无效的输入数据来测试程序是不现实的，所以黑盒测试同样不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。常用的黑盒测试用例的设计方法有等价类划分、边界值分析、错误猜测和因果图等。
|
|
|
|
.等价类划分：把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例，每一类代表性数据在测试中的作用等价于这一类中的其他值。
|
|
|
|
.边界值分析：这是一种补充等价类划分的测试用例设计技术，它不选择等价类的任意元素，而选择等价类边界的测试用例。实践证明，为检验边界附近的处理而专门设计测试用例，常常可以取得良好的测试效果。
|
|
|
|
.错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。基本思想是列举出程序中所有可能的错误和容易发生错误的特殊情况，再根据它们选择测试用例。
|
|
|
|
.因果图法：该方法从自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
|
|
|
|
|
|
把测试对象看做是一个打开的盒子，测试人员需了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，因此被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试及逻辑覆盖测试等。
|
|
|
|
.逻辑覆盖：以程序内部逻辑为基础的测试技术，常用的有语句覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖、点覆盖、边覆盖和路径覆盖等。
|
|
|
|
|
|
.基本路径：在程序控制流程图的基础上，通过分析控制结构的环路复杂性导出基本路径集合，然后设计测试用例，保证这些路径都至少通过一次。
|
|
|
|
|
|
灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
|
|
|
|
灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。
|
|
|
|
|
|
静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌前检查（Desk Checking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。
|
|
|
|
|
|
由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。检查项目如下所述。
|
|
|
|
.检查变量的交叉引用表。重点是检查未说明的变量和违反了类型规定的变量；还要对照源程序，逐个检查变量的引用、变量的使用序列，临时变量在某条路径上的重写情况，局部变量、全局变量与特权变量的使用等。
|
|
|
|
.检查标号的交叉引用表。验证所有标号的正确性；检查所有标号的命名是否正确，以及转向指定位置的标号是否正确。
|
|
|
|
.检查子程序、宏、函数。验证每次调用与被调用位置是否正确；确认每次被调用的子程序、宏和函数是否存在；检验调用序列中调用方式与参数顺序、个数和类型上的一致性。
|
|
|
|
.等值性检查。检查全部等价变量的类型的一致性，解释所包含的类型差异。
|
|
|
|
.常量检查。确认每个常量的取值和数制、数据类型；检查常量每次引用同它的取值、数制和类型的一致性。
|
|
|
|
.标准检查。用标准检查程序或手工检查程序中违反标准的问题。
|
|
|
|
|
|
.比较控制流。比较由程序员设计的控制流图和由实际程序生成的控制流图，寻找和解释每个差异，修改文档并校正错误。
|
|
|
|
.选择、激活路径。在程序员设计的控制流图中选择路径，再到实际的控制流图中激活这条路径。如果选择的路径在实际控制流图中不能激活，则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查，即桌前检查应至少是语句覆盖的。
|
|
|
|
.对照程序的规格说明，详细阅读源代码。程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则，仔细地阅读源代码，逐字逐句进行分析和思考，比较实际的代码和期望的代码，并从它们的差异中发现程序的问题和错误。
|
|
|
|
.补充文档。桌前检查的文档是一种过渡性的文档，不是公开的正式文档。通过编写文档，也是对程序的一种下意识的检查和测试，可以帮助程序员发现和抓住更多的错误。
|
|
|
|
由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多的检查时间，但应避免主观片面性。
|
|
|
|
|
|
代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。
|
|
|
|
第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
|
|
|
|
第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
|
|
|
|
在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。
|
|
|
|
|
|
|
|
第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
|
|
|
|
第二步，开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。
|
|
|
|
值得说明的是，使用静态测试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题也属于白盒测试的范畴。
|
|
|
|
|
|
为了保证系统的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格的技术评审。而软件测试则是为了发现错误而执行程序的过程。
|
|
|
|
根据测试的目的、阶段的不同，可以把测试分为单元测试、集成测试、确认测试和系统测试等几类。
|
|
|
|
|
|
单元测试又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，以及发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
|
|
|
|
单元测试根据详细设计说明书，包括模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试等。单元测试通常由开发人员自己负责。由于通常程序模块不是单独存在的，因此常常要借助驱动模块（相当于用于测试模拟的主程序）和桩模块（子模块）完成。单元测试的计划通常是在软件详细设计阶段完成的。
|
|
|
|
|
|
集成测试也称为组装测试、联合测试（对于子系统而言，则称为部件测试）。它将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。从组装策略而言，可以分为一次性组装和增量式组装（包括自顶向下、自底向上及混合式）两种。集成测试计划通常是在软件概要设计阶段完成的。
|
|
|
|
软件集成的过程是一个持续的过程，会形成多个临时版本。在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行“冒烟”测试，即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。
|
|
|
|
|
|
确认测试也称为有效性测试，主要包括验证软件的功能、性能及其他特性是否与用户要求（需求）一致。确认测试计划通常是在需求分析阶段完成的。根据用户的参与程度，通常包括以下4种类型。
|
|
|
|
（1）内部确认测试：主要由软件开发组织内部按软件需求说明书进行测试。
|
|
|
|
（2）α测试（Alpha测试）：由用户在开发环境下进行测试。
|
|
|
|
（3）β测试（Beta测试）：由用户在实际使用环境下进行测试。
|
|
|
|
（4）验收测试：针对软件需求说明书，在交付前以用户为主进行的测试。
|
|
|
|
|
|
如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列集成与确认测试。一般来说，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等。系统测试计划通常在系统分析阶段（需求分析阶段）完成。
|
|
|
|
|
|
性能测试是通过自动化的测试工具模拟多种正常、峰值及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行，统称为负载压力测试。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或不能接收的性能点来获得系统能提供的最大服务级别的测试。
|
|
|
|
|
|
性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，并优化软件，最后起到优化系统的目的。具体来说，包括以下几个方面。
|
|
|
|
（1）评估系统的能力。测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助做出决策。
|
|
|
|
（2）识别体系中的弱点。受控的负荷可以被增加到一个极端的水平并突破它，从而修复体系的瓶颈或薄弱的地方。
|
|
|
|
（3）系统调优。重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
|
|
|
|
（4）检测软件中的问题。长时间的测试执行可导致程序发生由于内存泄露等引起的失败，揭示程序中隐含的问题或冲突。
|
|
|
|
（5）验证稳定性和可靠性。在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
|
|
|
|
|
|
|
|
（1）负载测试：一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。
|
|
|
|
（2）强度测试：在系统资源特别低的情况下考查软件系统运行情况。
|
|
|
|
（3）容量测试：确定系统可处理的同时在线的最大用户数。
|
|
|
|
|
|
由于工程和项目的不同，所选用的度量及评估方法也有不同之处。不过仍然有一些通用的步骤可帮助我们完成一个性能测试项目。其步骤如下：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
系统的负载压力测试（负载测试）中的负载是指系统在某种指定软件、硬件及网络环境下承受的流量，例如并发用户数、持续运行时间、数据量等，其中并发用户数是负载压力的重要体现。系统在应用环境下主要承受并发访问用户数、无故障稳定运行时间和大数据量操作等负载压力。
|
|
|
|
|
|
（1）在真实环境下检测系统性能，评估系统性能是否可以满足系统的性能设计要求。
|
|
|
|
（2）预见系统负载压力承受力，对系统的预期性能进行评估。
|
|
|
|
|
|
在网络应用系统中，负载压力测试应重点关注客户端、网络及服务器（包括应用服务器和数据库服务器）的性能。应获取的关键测试指标如下。
|
|
|
|
（1）客户端：并发用户数、响应时间、交易通过率及吞吐量等。
|
|
|
|
（2）网络：带宽利用率、网络负载、延迟，以及网络传输和应用错误等。
|
|
|
|
（3）服务器：操作系统的CPU占用率、内存使用和硬盘I/O等；数据库服务器的会话执行情况、SQL执行情况、资源争用及死锁等；应用服务器的并发连接数、请求响应时间等。
|
|
|
|
|
|
验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求的那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统了，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能是否如同用户所合理期待的那样。
|
|
|
|
验收测试的结果有两种可能：一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足软件需求说明的要求，用户无法接受。项目进行到这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。
|
|
|
|
|
|
验收测试通常可以分为正式验收和非正式验收，具体选择的策略通常建立在合同需求、组织和公司标准，以及应用领域的基础上。
|
|
|
|
|
|
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。
|
|
|
|
在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。这种测试形式的优点是：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.可能无法发现软件中由于主观原因造成的缺陷，这是因为只查找了预期要发现的缺陷。
|
|
|
|
|
|
在非正式验收测试中，执行测试过程的限定不像正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，而且更为主观。
|
|
|
|
大多数情况下，非正式验收测试是由最终用户组织执行的。这种测试形式的优点是：
|
|
|
|
|
|
|
|
|
|
.与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。
|
|
|
|
|
|
|
|
|
|
.最终用户可能沿用系统工作的方式，并可能无法发现缺陷。
|
|
|
|
.最终用户可能专注于比较新系统与遗留系统，而不是专注于查找缺陷。
|
|
|
|
.用于验收测试的资源不受项目的控制，并且可能受到压缩。
|
|
|
|
|
|
在真正进行用户验收测试之前，一般应该已经完成了以下工作（也可以根据实际情况有选择地采用或增加）。
|
|
|
|
（1）软件开发已经完成，并全部解决了已知的软件缺陷。
|
|
|
|
（2）验收测试计划已经过评审和批准，并且置于文档控制之下。
|
|
|
|
|
|
|
|
|
|
（6）对单元、集成、系统测试计划和报告的审查已经完成。
|
|
|
|
（7）所有的测试脚本已完成，并至少执行过一次，且通过评审。
|
|
|
|
|
|
|
|
|
|
|
|
（1）软件需求分析：了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和验收要求。
|
|
|
|
（2）编制《验收测试计划》和《项目验收准则》：根据软件需求和验收要求编制测试计划，制定需测试的测试项，制定测试策略及验收通过准则，并制订出经过客户参与评审的计划。
|
|
|
|
（3）测试设计和测试用例设计：根据《验收测试计划》和《项目验收准则》编制测试用例，并经过评审。
|
|
|
|
（4）测试环境搭建：，建立测试的硬件环境和软件环境等（可在委托客户提供的环境中进行测试）。
|
|
|
|
|
|
（6）测试结果分析：根据验收通过准则分析测试结果，做出验收是否通过的决定，给出测试评价。
|
|
|
|
（7）测试报告：根据测试结果编制缺陷报告和验收测试报告，并提交给客户。
|
|
|
|
|
|
|
|
审查是指审查可执行程序、源程序、配置脚本、测试程序或脚本、主要的开发类文档和主要的管理类文档。
|
|
|
|
通常，正式的审核过程分为5个步骤，即计划、预备会议（可选）、准备阶段、审核会议和问题追踪。预备会议是指对审核内容进行介绍并讨论。准备阶段就是各责任人事先审核并记录发现的问题。审核会议是指最终确定工作产品中包含的错误和缺陷。
|
|
|
|
审核要达到的基本目标是根据共同制定的审核表，尽可能地发现被审核内容中存在的问题，并最终得到解决。在根据相应的审核表进行文档审核和源代码审核时，还要注意文档与源代码的一致性。
|
|
|
|
在实际的验收测试执行过程中，常常会发现文档审核是最难的工作，一方面，由于市场需求等方面的压力使这项工作常常被弱化或推迟，造成持续时间变长，加大文档审核的难度；另一方面，文档审核中不易把握的地方非常多，每个项目都有一些特别的地方，而且也很难找到可用的参考资料。
|
|
|
|
对软件需求说明书的审查，可以从清晰性、完整性、依从性、一致性、可行性和可管理性等几个方面考虑。对软件设计说明书（详细设计说明书、概要设计说明书）的审查，可以从清晰性、完整性、依从性、一致性、可行性、数据使用性、功能性、接口、可维护性、性能、可靠性、易测性和可追溯性等方面考虑。对测试计划（单元测试计划、集成测试计划、确认测试计划、系统测试计划）的审查，可以从完整性、依从性、一致性、正确性、详细级别／程度、易测性／可行性和可追溯性等方面考虑。对软件编码规范的审查，可以考虑源程序文档化、数据说明、输入输出等方面，评审的目的是为了使程序具有良好的风格，便于阅读。
|
|
|
|
|
|
在文档审核、源代码审核、配置脚本审核、测试程序或脚本审核都顺利完成后，就可以进行验收测试的最后一个步骤——可执行程序的测试了，包括功能、性能等方面的测试，每种测试也都包括目标、启动标准、活动、完成标准和度量5个部分。
|
|
|
|
不能直接使用开发方提供的可执行程序用于测试，而要按照开发方提供的编译步骤，从源代码重新生成可执行程序。
|
|
|
|
|
|
具体的测试内容通常可以包括安装（升级）、启动与关机、功能测试（正例、重要算法、边界、时序、反例、错误处理）、性能测试（正常的负载、容量变化）、压力测试（临界的负载、容量变化）、配置测试、平台测试、安全性测试、恢复测试（在出现掉电、硬件故障或切换、网络故障等情况时，系统是否能够正常运行）及可靠性测试等。
|
|
|
|
如果执行了所有的测试案例、测试程序或脚本，用户验收测试中发现的所有软件问题也都已解决，而且所有的软件配置均已更新和审核，可以反映出软件在用户验收测试中所发生的变化，用户验收测试就完成了。
|
|
|
|
|
|
第三方测试指独立于软件开发方和用户方的测试，也称为“独立测试”。软件质量工程强调开展独立验证和确认（IV&V）活动，是指由在技术、管理和财务上与开发组织具有规定程序独立的组织执行验证和确认过程。软件第三方测试是由相对独立的组织进行的软件测试，一般是在模拟用户真实应用环境下进行软件确认测试。
|
|
|
|
第三方测试机构是一个中介的服务机构，它通过自己专业化的测试手段为客户提供有价值的服务。但是这些服务不同于公司内部的测试，因为第三方测试机构的测试除了发现软件问题之外，还要科学公正地评价软件的职能，这就要求该机构要保持公正、廉洁、客观、科学且独立的态度。
|
|
|
|
第三方测试机构存在的价值主要是由软件公司、软件用户，以及国家的公正诉求所决定的。对于软件开发商来说，经过第三方测试机构的测试，不仅可以通过专业化的测试手段发现软件错误，帮助开发商提升软件的品质，而且可以对软件有一个客观且科学的评价，有助于开发商认清自己产品的定位。对于行业主管部门及软件使用者来说，第三方测试机构可帮助选择合适且优秀的软件产品。而对于一些信息工程项目来说，在验收之前，经过第三方机构的严格测试，可以最大程度地避免信息行业的“豆腐渣”工程。此外，经过国家认可的第三方测试机构，还为国家软件产品的质量监督抽查提供独立公正的测试支持。
|
|
|
|
在选择第三方测试机构时，主要查看其资质、信息系统工程测评经验、测试环境、测试工具及测试工程师队伍的素质等。
|
|
|
