《软件测试知识》word版.doc

软件测试知识以研促学、以产导研url=img,240,70gif/star7.gif/url-关于我们创业孵化实习实训师资培训课程开发在线培训课件下载您的位置：首页-行业知识站内搜索按标题搜索按内容搜索推荐信息A.menu2text-decoration：none；color：#000099；line-height：25pt；font-size：9ptA.menu2：hovertext-decoration：none；line-height：25pt；font-size：9pt；color：#ffffffA.menu2：visitedcolor：#FF66cFF；line-height：25pt；font-size：9pt学院结项项目情况通报关于组织申报2005年科研项目的通知关于开展产学研调查工作的通知电子技术多媒体教程课件评审会纪要我院召开计算机专业与就业大型知识讲座本周热点A.menu2text-decoration：none；color：#000099；line-height：25pt；font-size：9ptA.menu2：hovertext-decoration：none；line-height：25pt；font-size：9pt；color：#ffffffA.menu2：visitedcolor：#FF66cFF；line-height：25pt；font-size：9pt软件测试知识2003-2-12 ark前言计算机软件生产的方法学和计算机软件生产的管理学值得各类软件工作者关注，需要在实践与研究过程中不断发展理论和积累经验。缘于软件生产的特性，软件测试是软件生产的一个重点和难点。软件测试具有四个层次的作用：找错、确认、组装和评估1，其中确认和评估的意义与难度在规模化的软件生产中远远大于找错和组装。软件生产迫切需要脱离手工作坊方式的软件调试，在规范化软件测试的基础上实现规模化软件测试，达到提高软件产品质量、降低软件生产消耗的目的。软件测试的方法学和软件测试的管理学应是软件测试工作者关注的重点。软件测试的设计与组织我们从产品设计和生产组织的角度来分析和讨论软件测试流程、软件测试文档、软件测试用例、规模化软件测试和规范化软件测试。1.1软件测试的阶段划分可以从三个角度来将软件测试划分为多个阶段1：1.面向软件测试操作类型的划分，如调试、集成、确认、验证、组装、验收、操作；2.面向软件测试对象粒度的划分，如语句、结构、单元、部件、配置项、子系统、系统、大系统；3.面向软件测试实施者的划分，如开发者、测试者、验收者、使用者。1.2软件测试阶段的步骤每个软件测试阶段都要经历以下步骤：测试需求分析、测试过程设计、测试实现、测试实施、测试评价、测试维护。1.3软件测试角色每个测试步骤都对应一个测试角色，另外还定义测试配置管理的角色。表1软件测试角色的定义软件测试角色输入输出测试需求分析1.软件测试的方法与规范2.软件需求规格说明3.软件设计说明(概要设计说明和详细设计说明)软件测试计划：1)软件测试的定位2)软件测试线索3)软件测试环境的定义4)软件需求的追踪矩阵测试过程设计1.软件测试的方法与规范2.软件测试计划软件测试说明：1)软件测试步骤2)软件测试基准3)测试线索的追踪矩阵测试实现1.软件测试的方法与规范2.软件测试说明3.软件测试工具软件测试的实现配置：1)软件测试环境2)测试步骤的计算机表示(用于回归测试的测试代码/测试数据)3)测试基准的计算机表示测试实施1.软件测试的方法与规范2.软件测试说明3.软件测试的实现配置软件测试记录：1)测试运行结果的计算机表示2)测试比较结果的计算机表示3)测试日志4)软件问题报告测试评价1.软件开发文档2.软件测试文档3.软件测试配置4.软件测试记录软件测试报告：1)测试结果的统计信息2)测试结果的分析/评判测试配置管理测试配置管理项：1)软件测试的描述性表示(测试文档/文件)2)软件测试的计算机表示(测试代码/数据/结果)1.软件测试配置管理项的标识管理2.软件测试配置管理项的存储管理3.软件测试配置管理项的引用控制4.软件测试配置管理项的版本控制5.软件测试配置管理项的更动控制测试维护测试配置管理项1.测试配置管理项的使用报告2.测试配置管理项的软件问题报告3.测试配置管理项的更动控制文件明确区分各类测试角色，并明确定义其资源(人/物/时间)的安排，是保障软件测试工作有序开展、有效管理的关键。明确区分测试需求分析角色和测试过程设计的角色意义还在于：软件测试对软件功能/软件实现有了可追踪性，因而为准确评议测试用例的质量提供依据。1.4软件系统的测试流程显示了大型复杂软件系统MARA的测试流程。可以看到，结合测试操作类型和测试对象粒度的划分角度，MARA的测试阶段分为：单元测试、部件集成、部件确认、配置项组装、配置项确认、系统综合和系统验收。每个阶段都要经历2.2节说明的六个步骤。表2 MARA软件测试阶段的定义阶段标识被测对象目的完成后产品状态单元测试UT单元获得可组装的单元可执行的单元部件集成测试CI单元、三级部件、二级部件集成单元成部件二级部件环境中可执行的部件部件确认测试CV三级部件、二级部件确认将被组装的部件二级部件环境中满足文档要求的部件配置项组装测试II二级部件、一级部件、配置项组装部件成配置项配置项级环境中可执行的配置项配置项确认测试IV配置项、子系统确认配置项的功能和性能模拟环境中满足软件需求的配置项系统综合测试SI子系统系统动态协调开发环境下的各子系统仿实际运行环境中满足用户需求的子系统系统验收测试SA子系统系统关键配置项关键部件确认系统的功能和性能仿实际运行环境中满足用户需求的系统2软件测试文档显示了MARA的软件测试文档树。利用基于数据库的管理工具，软件测试文档可以自动/半自动生成。3软件测试用例3.1软件测试用例的定义软件测试用例可以被定义为如下六元组：(测试索引，测试环境，测试输入，测试操作，预期结果，评价标准)表3软件测试用例的定义软件测试用例元素含义给出定义的测试角色测试索引被标识过的测试需求测试需求分析测试环境进入测试实施步骤所需的资源及其状态。测试输入运行本测试所需的代码和数据，包括测试模拟程序和测试模拟数据测试设计(描述性定义)测试实现(计算机表示)测试操作建立测试运行环境、运行被测对象、获取测试结果的步骤序列预期结果用于比较测试结果的基准评价标准根据测试结果与预期结果的偏差，判断被测对象质量状态的依据3.2软件测试用例的生成和执行软件测试的核心任务是生成和执行软件测试用例。由表3知，在软件测试用例的六元组定义中：1.测试索引和测试环境在测试需求分析步骤中定义，是软件测试计划的内容；2.测试输入、测试操作、预期结果和评价标准的描述性定义在软件设计步骤中定义，是软件测试说明的内容；3.测试输入、测试操作、预期结果和评价标准的计算机表示(代码/数据定义)在软件测试实现步骤中给出，是软件测试程序产品。软件测试用例是软件测试结果的生成器，即每执行一次测试用例都产生一组测试结果。若测试用例被有效地由描述性定义转换为计算机表示，则测试的执行和结果的比较都可以利用软件测试工具自动或半自动地执行，在需要大量回归测试的复杂软件系统中，这种转换和自动执行是降耗增质的关键策略之一。3.3软件测试用例的配置管理基于以下原因，对软件测试用例的需要进行配置管理：1.大型复杂软件系统的功能/性能要求将对应于大量的软件测试用例，它们需要标识规则和规范的存储结构；2.软件测试用例也存在引用控制；3.软件测试用例也存在版本控制；4.软件测试用例也存在更动控制。软件测试用例的配置管理类似于一般软件的配置管理，可以实现安全存储、追踪变化和并行开发，其特色在于：区分测评人员和一般测试人员，前者独具生成和更新测试基准(预期结果的计算机表示)的权限。3.4软件测试用例的组织软件测试用例的设计和实现对应于被测对象的需求、设计和环境要求，因此同被测对象一样，软件测试用例可以被组织成层次结构，即：依据某种原则(如被测对象的层次或测试类型)将测试用例划分为测试用例组；测试用例组又可以划分为更高层次的测试用例组。显示了MARA中一个三级部件MRW的测试用例结构树。测试用例组反映多个测试用例/测试用例组之间的偏序关系，也标识了具有某种共性的测试用例的集合。测试实施时可以根据具体需要/环境，选择性地执行多个测试用例/测试用例组。3.5软件测试用例的复用测试用例的层次性还表现在：低层被测对象的测试用例或其部分内容可以复用在对高层被测对象的测试中。如：1.单元测试阶段的功能确认类测试用例组可以复用在部件集成测试阶段中；2.部件确认测试阶段可以复用单元测试阶段的测试输入；3.部件确认测试阶段的测试用例组可以复用在配置项组装测试阶段和配置项确认测试阶段中；4.配置项确认测试阶段的测试用例组可以复用在系统综合测试阶段和系统验收测试中。当然，每个测试阶段的对象和目标都不同，因此测试用例或其部分内容的复用通常有选择的、有限的和需更改的。4规模化软件测试与规范化软件测试软件测试的规模包括两层含义：被测软件的规模(有效代码量、结构/逻辑的复杂性、高性能/高精确性/高可靠性的需求)和测试消耗资源(人力/时间/测试频度)的规模，前者是定义后者的决定因素。可知，规模化软件测试应指：针对一定规模的软件消耗一定资源的软件测试。关于这两个一定，值得软件测试研究者探讨。实现规模化软件测试存在两种途径。表4规模化软件测试的两种实现途径规模化软件测试规范化软件测试无序逼近软件测试思路以规范化为基础的有效控制以资源消耗为前提的无序逼近理论基础以对元素运动的有序设定实现系统稳定(控制论)以大量元素的无序运动获得系统均衡(混沌学)测试流程可见性高低可控性高低测试用例准确性高低可信度高低有效性/数量高低覆盖率/数量高低可重用性高低测试结果可信度高低可重现性高低测试作用的实现代码找错好好部件组装好好需求确认好好质量评估好不好适用的软件系统有效代码量庞大庞大可靠性需求高性能需求高复杂性高高精确性高用户类型多样用户数量庞大应用环境复杂复杂使用频度高典型实例应用于航天/金融/国防/核能的大型实时控制系统1.商用软件的版本(所有用户为其规模化软件测试贡献了人力/时间/物力资源)2.大型软件的系统联调(以提高使用频度来增强对产品的信心)软件测试过程-从软件工程的角度出发，软件生命周期过程包括需求分析，分析设计，代码实现，测试，及应用部署。然而仅测试阶段就又一次完全体现了软件生命周期的全过程，这里涉及测试需求的定制，测试计划、测试过程的建立，测试的开发，测试的执行和测试结果的评估，所以软件测试是一个复杂的过程。在该过程中需要关注很多的内容，从白盒测试到黑盒测试，从静态分析到动态测试。从概念上，我们已经知道测试有两种方法，对那些已知产品的内部工作过程，通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查，这就是白盒测试。主要立足于对软件的过程性细节做到细致的检查，对程序的所有逻辑路径进行测试，通过在不同的点检查程序的状态，确定实际的状态是否与预期的状态一致。若已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求，为黑盒测试。这种测试要在软件的接口处进行，把被测对象看成一个黑盒子，不必考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。以上提到的两种测试方法我们可以在测试的不同阶段来实施，单元测试主要可以使用白盒测试，集成测试使用白盒测试和黑盒测试，确认测试和系统测试使用黑盒测试。由于测试是一个复杂的过程，而且需要反复的不断地对被测试应用施加测试，单纯通过手工的方式已经不能在交付时间上及测试的质量上给予保证。所以测试过程的自动化是测试的发展方向，在工具的分类上一般分为静态分析工具和动态测试工具。静态分析程序不需要执行所测试的程序，它扫描所测试程序的正文，对程序的数据流和控制流进行分析，然后送出测试报动态测试通过选择适当的测试用例，实际运行所测程序，比较实际运行结果和预期结果，以找出错误。动态测试分为结构测试与功能测试。在这里Compuware的测试工具覆盖了动态测试中的两种测试，即结构测试和功能测试。在结构测试工具中Compuware的Numega系列可以提供完善的支持。功能测试Compuware的QACenter系列可以解决功能性能问题。测试工作总体流程图软件开发全过程检测及软件测试自动化首先谈谈软件测试。这可以说是一个非常令人捉摸不定的领域。应该怎样对我们的产品进行测试?和怎样才算对产品进行了足够的测试?等问题，对于不同企业的不同类产品、同一企业的不同类产品、或不同企业的同一类产品，实际操作上都会有很大的不同。SEI的SW-CMM在它的成熟度第三级的软件产品工程关键过程域中，把软件开发周期中不同阶段的测试作为实施活动中的关键实践。(在SW-CMM版本2.0的讨论过程中，曾经有过提议，在成熟度第二级设立一个关键过程域软件测试管理。但在版本2.0的讨论稿C中，并没有这样做。从这里我们也可以看出，SW-CMM本身也是一个人为地制定的软件。)一般地，基于开发周期中不同阶段对不同对象所进行的测试，可划分为：单元测试(unit test)：由编程的开发人员自行计划与完成的，针对单个或相关联的一组程序单元的测试。组装测试(inegration test)：计划于设计阶段，由开发人员与测试人员合作完成的，针对结合起来的不同单元以及它们的接口的测试。系统测试(system test)：(可认为包括可用性与图形用户界面测试)测试整个系统，以证实它满足要求所规定的功能、质量和性能等方面的特性。回归测试(regression test)：用于验证改变了的系统或其组件仍然保持应有的特性。验收测试(acceptance test)：测试整个系统，以保证其达到可以交付使用的状态。关于上述各阶段的测试的具体内容及实现的方法，读者可参考SW-CMM及有关软件工程和软件测试的书籍。千万不要停留在只参考SW-CMM，因为该文件只讲述要做些什么，而没有介绍怎样做。同时，所有的资料中谈及的内容及方法，都是一般化的。对于一个特定软件的测试，必须经过使用者对通用的测试方法的改变及改进，才能有效和达到高效率。下面，谈谈软件测试的其他方面的一些问题。一个被人忽略的软件测试目的在谈到测试时，许多作者都引用了Grenford J.Myers就软件测试目的提出的以下观点：1.测试是程序的执行过程，目的在于发现错误；2.一个好的测试用例在于能发现至今未发现的错误；3.一个成功的测试是发现了至今未发现的错误的测试。这是一种比较狭窄的观点。作为一个清醒的、纵观全局的软件开发人员或管理者，我们应当从软件过程的角度来看测试。一个被人忽略的软件测试目的是：测试可以帮助发现当前开发工作所采用的软件过程(也是一个软件)的缺陷，以便进行改进。(在以下的讨论中，错误与缺陷基本上认为代表相同意义。)怎样理解这种说法呢?首先，测试并不仅仅是为了要找出错误。分析错误产生的原因和错误在开发的哪一个阶段产生，具有非常重要的意义。通过分析错误的原因，我们可以立即在开发行动中对其进行改正。同时，这种分析也能帮助我们推理出与所分析的错误有关联的潜在错误，从而有针对性地设计出检测的方法。通过分析错误产生于哪一个开发阶段、而又在哪一个阶段被发现，我们可以判断从错误的产生到错误的发现，跨越了多少个开发阶段。软件开发的一条重要原则是尽早发现与修正错误。(当然，更高的一条原则是尽量预防错误的出现。)一个错误能够超越本开发阶段而不被发现，就指明了该开发阶段的检测手段有缺陷，从而也不难有针对性地制定出加强的措施与办法。这也就是软件过程改进的一项重要内容。如果能做到在同一开发阶段发现及修正错误，该开发机构就可以预期有一个高质量的产品及一个低成本、高效率的软件过程。有些项目的主持人，认为以尽快的速度把测试之前的所有开发阶段完成(实际并没有完成)，早日开始测试，以图达到快速和高质量(因为似乎有更长的时间可用于测试)。实际的效果将会是俗语所说的欲速不达。从常识就可以知道，花开发时间去继续扩大发展前面阶段引入的错误，得出的只能是更大量的需要耗时修正的错误。因此，正确分析与利用测试的结果，我们可以非常有效地进行软件过程改进。软件开发全过程检测，力争本阶段修正错误从上面的讨论，我们很自然的就能领会到，软件错误的发现绝不能等到测试才开始(按常规，最早的测试就是编码后的单元测试)。因此，笔者提出一个软件工程的守则：软件开发全过程检测，力争本阶段修正错误。单元测试是在软件开发的实现阶段才开始的，在此之前的可行性研究与计划阶段，需求分析阶段，概要设计阶段，和详细设计阶段，都必须有非常明确切实的手段与措施对开发结果进行检验，以保证阶段的正确完成。怎样判断一个软件过程的优劣，怎样进行软件过程改进，都可以在这个守则的指导下进行。这个守则是简单明确的，但因企业背景、条件的不同，开发环境条件的不同，项目产品的不同，实际的软件过程的实现方法就会变化无穷。考虑实现这个原则的方法的时候，可以尽量多参考各种理论及经验，但在选择制定本企业开发实践中使用的软件过程时，就必须处处根据是否能给自身的项目带来好处，以及自身的条件进行考虑。千万不要仅仅为了满足某个标准的提法而做一些无实际意义的工作。要尽量避免烦琐，争取做到简单、有条理和有最大的效果。软件测试的自动化软件测试的工作量很大(据统计，会用到40%的开发时间；一些可靠性要求非常高的软件，测试时间甚至占到总开发时间的60%)，但测试却是在整个软件过程中极有可能应用计算机进行自动化的工作，原因是测试的许多操作是重复性的、非智力创造性的、需求细致注意力的工作。计算机就最适合于代替人类去完成这些任务。企业在这方面的投资，会对整个开发工作的质量、成本、和周期带来非常明显的效果。一些适于考虑进行自动化的测试操作为：1.测试个案的生成(包括测试输入，标准输出，测试操作指令等)。2.测试的执行写控制(包括单机与网络多机分布运行；夜间及假日运行。测试个案调用控制；测试对象、范围、版本控制等。)。3.测试结果与标准输出的对比。4.不吻合的测试结果的分析、记录、分类、和通报。5.总测试状况的统计，报表的产生。测试自动化与软件配置管理是密不可分的。与测试有关的资源都应在配置管理中进行统一的计划考虑。另外，测试工具的采用也是一个提高质量的关键，有些专用的测试工具能帮助发现一些用任何测试个案都难以触及的错误。常用测试软件工具BoundsChecker程序员在开发过程中可能会经常遇到这样的问题：调试时语法没有问题，代码也没有错误，但应用程序运行就是不正常甚至死机，其实这有可能是由于逻辑错误引起的内存溢出或资源泄露等问题,这些错误一般是不容易被检测出来的。而这类错误就是BoundsChecker错误检测范围之一。通过对被测应用程序的操作，BoundsChecker提供清晰的、详细的程序错误分析，自动查明静态的堆栈错误及内存/资源泄露，并能够迅速的定位出错的源代码，即使在没有源代码的情况下也可检查第三方组件的错误。BoundsChecker错误检测范围主要包括：1).指针和泄露错误l接口泄露l内存泄露l资源泄露l未分配的指针错误2).内存错误l动态存储溢出l无效的句柄被锁定l句柄没有被锁定l内存分配冲突l栈空间溢出l静态存储溢出3).API和OLE错误l API函数返回失败l API函数未执行l无效的变量(包括指针变量、字符串变量等)l OLE接口方法的变量无效l OLE接口方法失败l线程调用库函数错误BoundsChecker支持的语言和主机平台：Visual C+,Borland C+Builder,Delphi,Windows NT,Windows95/98/2000 TrueCoverage在开发过程中，对一个应用程序通过手工测试，总会有一部分代码功能没有被检测到，或者说逐个检测每一个函数的调用是相当费时间的；未被检测的代码我们不能保证它的可靠性，以后程序的失败可能往往就是由这部分未检测的代码造成的。我们可以用TrueCoverage来帮助我们解决这些问题，我们在测试程序时，每完成一次应用session，TrueCoverage就能够列出在这次对话中所有函数被调用次数、所占比率等，并可以直接定位到源代码，当然我们也可以合并多个应用session来进行检测。TrueCoverage能通过衡量和跟踪代码执行及代码稳定性，帮助开发团队节省时间和改善代码可靠性。TrueCoverage支持的语言和主机平台：C+,JAVA,Visual Basic,Windows NT,Windows95/98/2000 TrueTime代码运行效率是开发过程中一个重要问题。一个应用程序运行速度较慢，程序员不容易找到到底是在哪里出现了问题，如果不能解决应用程序的性能将降低并极大的影响应用程序的质量，于是查找和修改性能瓶颈是调整整个代码性能的关键。如何快速的查找性能瓶颈呢?在测试程序时，每完成一次应用session，TrueTime都能提供这次对话中函数的调用时间，提供详细的应用程序和组件性能的分析，并自动定位到运行缓慢的代码。这样就能帮助程序员尽快地调整应用程序的性能。TrueTime支持的语言和主机平台：C+,JAVA,Visual Basic,Windows NT,Windows95/98/2000 JCheck JCheck JCheck JCheck对于Java开发人员来说是一个功能强大的图形化的线程和事件分析工具，它提供了一个生动的图形化的方法来表现程序的线程的状态信息以及和Windows线程、同步对象、线程组等的交互作用信息，使开发人员能够直观地分析Java Applet或Application。通过这些形象化的图形显示，可以确定runtime错误，对执行和逻辑错误进行分析，立刻发现线程问题如死锁、活锁、资源缺乏和系统失败，诊断线程同步和时间选择问题，分析程序执行流程；而后JCheck对于那些错误可以定位和显示详细的信息并能定位到源代码。Jcheck极大地减少了程序的调试时间，改善了软件开发生产力。JCheck支持的语言和主机平台：Microsoft Visual J+,Windows NT,Windows95/98/2000 QARun QARun为客户/服务器、电子商务到企业资源计划提供重要的商务功能测试。通过将耗时的测试脚本开发和执行任务自动化，QARun帮助测试人员和QA管理人员更有效地工作，以加速应用开发。适用于所有关键业务应用测试的工具QARun允许在复杂的企业环境里测试各种各样的应用。QARun支持通过对Microsoft Windows图形用户界面的访问来测试应用，包括：l 4GL，如PowerBuilder、UNIFACE和Visual Basic l打包的应用包括：SAP、Siebel、Oracle Web Form和PeopleSoft lWindows2000控制l基于web的应用，如：ActiveX、Java、HTML和DHTML l客户/服务器应用l远程系统l通过一个基于Windows的终端仿真程序访问的mid-range和