|
|
|
软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。
|
|
|
|
Bill Hetzel指出：“测试是以评价一个程序或系统属性为目标的任何一种活动。测试是对软件质量的度量”。Grenford J. Myers指出：
|
|
|
|
|
|
（2）测试是为了证明程序有错，而不是证明程序无错误。
|
|
|
|
（3）一个好的测试用例在于它能发现至今未发现的错误。
|
|
|
|
（4）一个成功的测试是发现了至今未发现的错误的测试。
|
|
|
|
这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。
|
|
|
|
首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理人员发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。
|
|
|
|
其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
|
|
|
|
：软件测试可以验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及软件质量特性的要求，为软件质量的评价提供依据。软件测试只是软件质量保证的手段之一，不能单凭测试来保证软件质量。
|
|
|
|
|
|
软件测试方法一般分为两大类，分别为动态测试和静态测试。
|
|
|
|
|
|
动态测试指通过运行程序发现错误，分为黑盒测试法、白盒测试法和灰盒测试法等。
|
|
|
|
（1）黑盒法。把被测试对象看成一个黑盒子，测试人员完全不考虑程序的内部结构和处理过程，只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试，使用这种方法，为了做到穷尽测试，至少必须对所有输入数据的各种可能值的排列组合都进行测试。黑盒测试使用所有有效和无效的输入数据来测试程序是不现实的，所以黑盒测试同样不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。常用的黑盒测试用例的设计方法有等价类划分、边界值分析、错误推测和因果图等。
|
|
|
|
等价类划分把程序的输入域划分成若干部分，然后从每个部分中选取少数有代表性的数据作为测试用例，每一类代表性数据在测试中的作用等价于这一类中的其他值。划分等价类时，首先把数目极多的输入分成若干个等价类。所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序中错误的作用是等效的。
|
|
|
|
边界值分析是一种补充等价类划分的测试用例设计技术，它不选择等价类的任意元素，而选择等价类边界的测试用例。实践证明，为检验边界附近的处理而专门设计测试用例，常常可以取得良好的测试效果。
|
|
|
|
错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，有针对性地设计测试用例的方法。基本思想是列举出程序中所有可能的错误和容易发生错误的特殊情况，再根据它们选择测试用例。
|
|
|
|
因果图法从自然语言书写的程序规格说明的描述中找出因（输入条件）和果（输出或程序状态的改变），通过因果图转换为判定表。
|
|
|
|
（2）白盒法。把测试对象看做一个打开的盒子，测试人员须了解程序的内部结构和处理过程，以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检验内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。由于白盒测试是结构测试，所以被测对象基本上是源程序，以程序的内部逻辑为基础设计测试用例。常用的白盒测试用例设计方法有基本路径测试、循环覆盖测试及逻辑覆盖测试等。
|
|
|
|
逻辑覆盖以程序内部逻辑为基础的测试技术，常用的有语句覆盖、判定覆盖、条件覆盖、条件判定覆盖、修正的条件判断覆盖、条件组合覆盖、点覆盖、边覆盖和路径覆盖等。
|
|
|
|
循环覆盖是指覆盖程序中所有的循环，包括单循环及嵌套循环。
|
|
|
|
基本路径法在程序控制流程图的基础上，通过分析控制结构的环路复杂性导出基本路径集合，然后设计测试用例，保证这些路径都至少通过一次。
|
|
|
|
（3）灰盒法。灰盒测试是一种介于白盒测试与黑盒测试之间的测试，它关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细且完整，而只是通过一些表征性的现象、事件及标志来判断程序内部的运行状态。
|
|
|
|
灰盒测试结合了白盒测试和黑盒测试的要素，考虑了用户端、特定的系统知识和操作环境，在系统组件的协同性环境中评价应用软件的设计。
|
|
|
|
|
|
静态测试指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态分析中进行人工测试的主要方法有桌前检查（Desk Checking）、代码审查和代码走查。经验表明，使用这种方法能够有效地发现30%~70%的逻辑设计和编码错误。
|
|
|
|
（1）桌前检查。由程序员自己检查自己编写的程序。程序员在程序通过编译之后，进行单元测试设计之前，对源程序代码进行分析、检验，并补充相关的文档，目的是发现程序中的错误。检查项目包括检查变量的交叉引用表；检查标号的交叉引用表；检查子程序、宏、函数；等值性检查；常量检查；标准检查；风格检查；比较控制流；选择、激活路径；对照程序的规格说明，详细阅读源代码；补充文档。
|
|
|
|
由于程序员熟悉自己的程序和自身的程序设计风格，这种桌前检查可以节省很多的检查时间，但应避免主观片面性。
|
|
|
|
（2）代码审查。代码审查是由若干程序员和测试员组成一个会审小组，通过阅读、讨论和争议，对程序进行静态分析的过程。代码审查分两步。
|
|
|
|
第一步，小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员，作为评审的依据。小组成员在充分阅读这些材料之后，进入审查的第二步。
|
|
|
|
第二步，召开程序审查会。在会上，首先由程序员逐句讲解程序的逻辑。在此过程中，程序员或其他小组成员可以提出问题，展开讨论，审查错误是否存在。实践表明，程序员在讲解过程中能发现许多原来自己没有发现的错误，而讨论和争议则促进了问题的暴露。
|
|
|
|
在会前，应当给会审小组每个成员准备一份常见错误的清单，把以往所有可能发生的常见错误罗列出来，供与会者对照检查，以提高会审的实效。这个常见错误清单也叫做检查表，它把程序中可能发生的各种错误进行分类，对每一类列举出尽可能多的典型错误，然后把它们制成表格，供在会审时使用。
|
|
|
|
（3）代码走查。代码走查与代码审查基本相同，其过程也分为两步。
|
|
|
|
第一步，把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会。
|
|
|
|
第二步，开会的程序与代码会审不同，不是简单地读程序和对照错误检查表进行检查，而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例，提交给走查小组。走查小组开会，集体扮演计算机角色，让测试用例沿程序的逻辑运行一遍，随时记录程序的踪迹，供分析和讨论使用。
|
|
|
|
：使用静态测试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。
|
|
|
|
|
|
为了保证系统的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格的技术评审。而软件测试则是为了发现错误而执行程序的过程，根据测试的目的、阶段的不同，可以把测试分为单元测试、集成测试、确认测试和系统测试等几类。
|
|
|
|
|
|
单元测试又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，以及发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例，多个模块可以平行地独立进行单元测试。
|
|
|
|
单元测试根据详细设计说明书，包括模块接口测试、局部数据结构测试、路径测试、错误处理测试和边界测试等。单元测试通常由开发人员自己负责。由于通常程序模块不是单独存在的，因此常常要借助驱动模块（相当于用于测试模拟的主程序）和桩模块（子模块）完成。单元测试的计划通常是在软件详细设计阶段完成的，单元测试一般使用白盒测试方法。
|
|
|
|
|
|
集成测试也称为组装测试、联合测试（对于子系统而言，则称为部件测试）。它将已通过单元测试的模块集成在一起，主要测试模块之间的协作性。从组装策略而言，可以分为一次性组装和增量式组装（包括自顶向下、自底向上及混合式）两种。集成测试计划通常是在软件概要设计阶段完成的，集成测试一般采用黑盒测试方法。
|
|
|
|
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其他模块。这些辅助模块分为两种：
|
|
|
|
（1）驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。
|
|
|
|
（2）桩模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。
|
|
|
|
|
|
|
|
|
|
在自底向上增殖式集成时，因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
|
|
|
|
：软件集成的过程是一个持续的过程，会形成多个临时版本。在不断的集成过程中，功能集成的稳定性是真正的挑战。在每个版本提交时，都需要进行“冒烟”测试，即对程序主要功能进行验证。冒烟测试也称为版本验证测试或提交测试。
|
|
|
|
|
|
确认测试也称为有效性测试，主要包括验证软件的功能、性能及其他特性是否与用户要求（需求）一致。确认测试计划通常是在需求分析阶段完成的。根据用户的参与程度，通常包括以下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）提高运行效率。由于自动化测试工具的运行，节省出的时间可以让测试人员重新计划和安排测试工作，设计新的测试用例，开发新的测试工具。
|
|
|
|
（3）保证测试结果的准确性。测试过程是枯燥而烦琐的，任何一点疏忽都可能导致测试结果不准确而需要返工。测试工具不同，完成的脚本会忠实地记录测试过程中发生的一切。
|
|
|
|
（4）连续运行测试脚本。测试工具可以24小时运行测试脚本，不间断地进行测试，这是测试人员所不能比拟的。
|
|
|
|
（5）模拟现实环境下受约束的情况。测试过程基本上是模拟真实环境执行相关操作，然而有些情况是很难完全模拟的。
|
|
|
|
引入自动化测试好处很多，但它不是解决所有测试问题的“银弹”，它不能做到：
|
|
|
|
（1）所有测试活动都可以自动完成。自动化测试不能代替人完成所有工作，是否需要自动化测试要根据实际需要来决定。
|
|
|
|
（2）减少人力成本。引入自动化测试只是测试过程规范化的一种必然结果，如果因此减少人力资源的话意味着测试过程的不完整，以及项目风险的提升。
|
|
|
|
（3）可以免费获得。测试人员对他们进行培训使其能够正确使用工具，培训测试人员是一个长期的过程，测试数据和代码的维护也需要占用资源，这些都需要成本。
|
|
|
|
（4）降低测试工作量。自动化测试的结果是需要进行分析和评估的，没有经过人工处理过的测试结果只是一堆垃圾。
|
|
|
|
由于软件项目或产品都面临时间有限和资源有限的两个问题，软件测试自动化也就需要从这两个方面着手进行选择。虽然自动化测试包含的内容涉及测试的许多方面，但可以总结为以下3个类别：分析自动化（静态分析、动态分析）、功能测试类和系统测试类。
|
|
|
|
选择测试工具主要应该考虑企业的情况，例如，企业规模、开发模式和对工具的实际需求等。目前测试工具提供商很多，Rational、Compuware、Mercury等都是不错的选择，选择时主要是比较成本，但更重要的是注意这些工具对系统特性方面的一些约束，例如，Rational支持的协议开放性就不是很强。
|
|
|
|
：对于产品相对单一，或者是开发周期长的项目，我们更倾向于自己开发测试工具，无论是从节省测试成本还是从企业长远发展考虑，这样做都是有利的。
|
|
|
|
|
|
在软件测试的过程中，就会发现软件中的一些错误，但是，这种错误的发生只是一种表象，错误究竟是由什么原因引起的，是由哪段代码引起的，这些问题就需要进行调试才能确定。
|
|
|
|
调试主要由3个步骤组成，它从表示程序中存在错误的某迹象开始，首先确定错误的准确位置，也就是找出哪个模块或哪个语句引起的错误。然后仔细研究推断代码以确定问题的原因，并设法改正，最后进行回归测试。总的来说有3种调试的实现方法，分别是蛮力法、回溯法、原因排除法。
|
|
|
|
蛮力法的调试可能是为了找到错误原因而使用的最普通但是最低效的方法了。当所有其他的方法都失败的情形下，我们才会使用这种方法。根据“让计算机自己来寻找错误”的思想，进行内存映像，激活运行时的跟踪。
|
|
|
|
回溯是在小程序中经常能够奏效的相当常用的调试方法。从发现症状的地方开始，开始（手工地）向回跟踪源代码，直到发现错误原因。
|
|
|
|
原因排除法是通过演绎和归纳，以及二分法来实现的。对和错误发生有关的数据进行分析可寻找到潜在的原因。先假设一个可能的错误原因，然后利用数据来证明或者否定这个假设。也可以先列出所有可能的原因，然后进行检测来一个个地进行排除。如果最初的测试表明某个原因看起来很像的话，那么就要对数据进行细化来精确定位错误。
|
|
|
|
上面的每一种方法都可以使用调试工具来辅助完成。我们可以使用许多带调试功能的编译器、动态的调试辅助工具（跟踪器）、自动的测试用例生成器、内存映象工具以及交叉引用生成工具。
|
|
|
|
|
|
（1）测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误。
|
|
|
|
（2）调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同。
|
|
|
|
（3）测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计。
|
|
|
|
（4）测试过程可以实现设计，进度可实现确定；调试不能描述过程或持续时间。
|
|
|
|
|
|
就每一项测试而言，软件测试过程包括测试计划、测试设计、测试执行和测试评估等阶段。测试设计是整个测试过程中非常重要的一个环节，测试设计的输出结果是测试执行活动依赖的执行标准，测试设计的充分性决定了整个软件过程的测试质量。为了保证测试质量，应从多方面来综合考虑系统需求的实现情况，从以下几个层次来进行测试设计：用户层、应用层、功能层、子系统层、协议层。
|
|
|
|
用户层测试是面向产品最终的使用操作者的测试，重点突出的是从操作者角度上，测试系统对用户支持的情况，用户界面的规范性、友好性、可操作性，以及数据的安全性等。主要包括用户支持测试、用户界面测试、可维护性测试和安全性测试。
|
|
|
|
应用层测试是针对产品工程应用或行业应用的测试，重点站在系统应用的角度，模拟实际应用环境，对系统的兼容性、可靠性、性能等进行测试。主要包括系统性能测试、系统可靠性、系统稳定性测试、系统兼容性测试、系统组网测试和系统安装升级测试。
|
|
|
|
功能层测试是针对产品具体功能实现的测试，主要包括功能覆盖测试、功能分解测试、功能组合测试和功能冲突测试。
|
|
|
|
子系统层测试是针对产品内部结构性能的测试，重点关注子系统内部的性能、模块间接口的瓶颈。主要包括单个子系统性能测试、子系统间的接口瓶颈测试和子系统间的相互影响测试。
|
|
|
|
协议层测试是针对系统支持的协议的测试，主要包括协议一致性测试和协议互通测试。
|
|
|
|
|
|
为了保证软件的开发质量，软件测试应贯穿开发的整个过程，包括对设计和所有实现结果的检测。因此，要成立专门的测试管理组，由测试管理组对测试进行统一、规范的管理。测试管理组包括评审小组、测试小组和支持小组。
|
|
|
|
软件测试管理的目的是确保软件测试技术能在软件项目的整个生命周期内得到顺利实施，并产生预期的效果。按照管理的对象不同，软件测试管理大致分为测试团队管理、测试计划管理、错误（缺陷）跟踪管理和测试件（testware）管理四大部分。
|
|
|
|
（1）测试团队管理。首先，一个好的测试团队要有一个具有极为丰富的开发经验、具有亲和力和人格魅力的带头人。其次，测试团队还应有具备一技之长（如对某些自动化测试工具运用娴熟或能轻而易举地编写自动化测试脚本）的成员。另外，测试团队还应有兼职的同行专家。
|
|
|
|
（2）测试计划管理。测试计划也称软件验证与确认计划，它详细规定测试的要求，包括测试的目的、内容、方法、步骤以及测试的准则等，以用来验证软件需求规格说明书中的需求是否已由软件设计说明书描述的设计实现。软件设计说明书表达的设计是否已由编码实现，编码的执行是否与软件需求规格说明书中所规定的需求相一致。由于要测试的内容可能涉及软件的需求和软件的设计，因此必须及早开始测试计划的编写工作。不应在着手测试时，才开始考虑测试计划。通常，测试计划的编写从需求分析阶段开始，到软件设计阶段结束时完成。
|
|
|
|
（3）错误（缺陷）跟踪管理。当测试团队发现文档或代码中存在缺陷以后，并不是交一份测试报告就草草了事，而是在递交报告以后继续督促开发团队及时改正已知错误。当开发团队改正了测试报告中的错误以后，测试团队还需进行回归测试以验证开发团队在改错过程中没有引入新的错误。
|
|
|
|
（4）测试件管理。测试件指测试工作形成的产品，包括测试团队在长期实践过程中逐步积累起来的经验教训、测试技巧、测试工具、规格文档以及一些经过少量修改能推广通用的测试脚本程序。测试件管理工作做得越好，测试团队在实际测试过程中就能越少走弯路，测试团队内部的知识交流和传递就越充分，测试脚本或规格文档的重复开发工作也就能被有效地避免。
|
|
|
