测试项目管理.doc

TR4TR6阶段测试项目管理软件测试概念使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别.它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness)、完全度(completeness)和质量(quality)的软件过程；是SQA(softwarequalityassurance)的重要子域。GrenfordJ.Myers曾对软件测试的目的提出过以下观点:(1)测试是为了发现程序中的错误而执行程序的过程；(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；(3)成功的测试是发现了至今为止尚未发现的错误的测试。然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此!(1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进；(2)这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性；(3)没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法软件测试的内容软件测试主要工作内容是验证(verification)和确认(validation)，下面分别给出其概念：验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Dotherightthing)1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程；2.程序正确性的形式证明，即采用形式理论证明程序符号设一计规约规定的过程；3.评市、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。确认(validation)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Doitright)1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性；2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。从不同的角度出发，软件测试可以划分为不同的分类从是否关心软件内部结构和具体实现的角度划分A.白盒测试B.黑盒测试C.灰盒测试从是否执行程序的角度A.静态测试B.动态测试。从软件开发的过程按阶段划分有A.单元测试B.集成测试C.确认测试D.验收测试E.系统测试软件测试是软件开发过程的重要组成部分，是用来确认一个程序的品质或性能是否符合开发之前所提出的一些要求。软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生存期中横跨两个阶段：通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。编码和单元测试属于软件生存期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，这是软件生存期的另一个独立阶段，即测试阶段。一、软件测试的目的 软件测试的目的，第一是确认软件的质量，其一方面是确认软件做了你所期望的事情（Do the right thing），另一方面是确认软件以正确的方式来做了这个事件（Do it right）。 第二是提供信息，比如提供给开发人员或程序经理的反馈信息，为风险评估所准备的信息。 第三软件测试不仅是在测试软件产品的本身，而且还包括软件开发的过程。如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。因此软件测试的第三个目的是保证整个软件开发过程是高质量的。 软件质量是由几个方面来衡量的：一、在正确的时间用正确的的方法把一个工作做正确（Doing the right things right at the right time.）。二、符合一些应用标准的要求，比如不同国家的用户不同的操作习惯和要求，项目工程中的可维护性、可测试性等要求。三、质量本身就是软件达到了最开始所设定的要求，而代码的优美或精巧的技巧并不代表软件的高质量（Quality is defined as conformance to requirements, not as “goodness” or “elegance”.）。四、质量也代表着它符合客户的需要（Quality also means “meet customer needs”.）。作为软件测试这个行业，最重要的一件事就是从客户的需求出发，从客户的角度去看产品，客户会怎么去使用这个产品，使用过程中会遇到什么样的问题。只有这些问题都解决了，软件产品的质量才可以说是上去了。 测试人员在软件开发过程中的任务： 1、寻找Bug； 2、避免软件开发过程中的缺陷； 3、衡量软件的品质； 4、关注用户的需求。 总的目标是：确保软件的质量。二、软件测试的原则 软件测试从不同的角度出发会派生出两种不同的测试原则，从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷，从而考虑是否可以接受该产品，从开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户的需求，确立人们对软件质量的信心。 为了达到上述的原则，那么需要注意以下几点：1应当把“尽早和不断的测试”作为开发者的座右铭2程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完。3设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。4一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。5对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。6制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。7回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。8妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。/wiki/%E5%AF%B9%E8%B1%A1 target=_new class=innerlink对象软件测试并不等于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试的对象。 在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来。四、软件测试方法 软件测试的基本方法 单元测试的基本方法综合测试的基本方法确认测试的基本方法系统测试的基本方法软件测试的基本方法软件测试的方法和技术是多种多样的。对于软件测试技术，可以从不同的角度加以分类：从是否需要执行被测软件的角度，可分为静态测试和动态测试。从测试是否针对系统的内部结构和具体实现算法的角度来看，可分为白盒测试和黑盒测试；1、黑盒测试黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测等，主要用于软件确认测试。 “黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。2、白盒测试白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了一些与数据相关的错误。3ALAC(Act-like-a-customer)测试ALAC测试是一种基于客户使用产品的知识开发出来的测试方法。ALAC测试是基于复杂的软件产品有许多错误的原则。最大的受益者是用户，缺陷查找和改正将针对那些客户最容易遇到的错误。单元测试的基本方法单元测试的对象是软件设计的最小单位模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。单元测试任务单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素： 1 输入的实际参数与形式参数的个数是否相同； 2 输入的实际参数与形式参数的属性是否匹配； 3 输入的实际参数与形式参数的量纲是否一致； 4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同； 5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配； 6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致； 7 调用预定义函数时所用参数的个数、属性和次序是否正确； 8 是否存在与当前入口点无关的参数引用； 9 是否修改了只读型参数； 10 对全程变量的定义各模块是否一致； 11是否把某些约束作为参数传递。如果模块内包括外部输入输出，还应该考虑下列因素： 1 文件属性是否正确； 2 OPEN/CLOSE语句是否正确； 3 格式说明与输入输出语句是否匹配； 4缓冲区大小与记录长度是否匹配； 5文件使用前是否已经打开； 6是否处理了文件尾； 7是否处理了输入/输出错误； 8输出信息中是否有文字性错误；检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误： 1 不合适或不相容的类型说明； 2变量无初值； 3变量初始化或省缺值有错； 4不正确的变量名（拼错或不正确地截断）； 5出现上溢、下溢和地址异常。除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。?的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括： 1 误解或用错了算符优先级； 2混合类型运算； 3变量初值错； 4精度不够； 5表达式符号错。比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 1不同数据类型的对象之间进行比较； 2错误地使用逻辑运算符或优先级； 3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等； 4比较运算或变量出错； 5循环终止条件或不可能出现； 6迭代发散时不能退出； 7错误地修改了循环变量。一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题： 1输出的出错信息难以理解； 2记录的错误与实际遇到的错误不相符； 3在程序自定义的出错处理段运行之前，系统已介入； 4异常处理不当； 5错误陈述中未能提供足够的定位出错信息。边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。单元测试过程一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。综合测试的基本方法 时常有这样的情况发生，每个模块都能单独工作，但这些模块集成在一起之后却不能正常工作。主要原因是，模块相互调用时接口会引入许多新问题。例如，数据经过接口可能丢失；一个模块对另一模块可能造成不应有的影响；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全局数据结构出现错误，等等。综合测试是组装软件的系统测试技术，按设计要求把通过单元测试的各个模块组装在一起之后，进行综合测试以便发现与接口有关的各种错误。某设计人员习惯于把所有模块按设计要求一次全部组装起来，然后进行整体测试，这称为非增量式集成。这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是增量式集成方法，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，界面的测试亦可做到完全彻底。下面讨论两种增量式集成方法。1 自顶向下集成自顶向下集成是构造程序结构的一种增量式方式，它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。深度优先策略首先是把主控制路径上的模块集成在一起，至于选择哪一条路径作为主控制路径，这多少带有随意性，一般根据问题的特性确定。以下图为例，若选择了最左一条路径，首先将模块M1，M2，M5和M8集成在一起，再将M6集成起来，然后考虑中间和右边的路径。广度优先策略则不然，它沿控制层次结构水平地向下移动。仍以下图为例，它首先把M2、M3和M4与主控模块集成在一起，再将M5和M6 和其他模块集资集成起来。自顶向下综合测试的具体步骤为： 1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代； 2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块； 3 每集成一个模块立即测试一遍； 4 只有每组测试完成后，才着手替换下一个桩模块； 5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。下图中，实线表示已部分完成的结构，若采用深度优先策略，下一步将用模块M7替换桩模块S7，当然M7本身可能又带有桩模块，随后将被对应的实际模块一一替代。自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因此较早地发现错误。缺点是在测试较高层模块时，低层处理采用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，因此测试并不充分。解决这个问题有几种办法，第一种是把某些测试推迟到用真实模块替代桩模块之后进行，第二种是开发能模拟真实模块的桩模块；第三种是自底向上集成模块。第一种方法又回退为非增量式的集成方法，使错误难于定位和纠正，并且失去了在组装模块时进行一些特定测试的可能性；第二种方法无疑要大大增加开销；第三种方法比较切实可行，下面专门讨论。2自底向上集成自底向上测试是从“原子”模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。自底向上综合测试的步骤分为： 1 把低层模块组织成实现某个子功能的模块群（cluster）; 2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 3 对每个模块群进行测试； 4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。下图说明了上述过程。首先“原子”模块被分为三个模块群，每个模块群引入一个驱动模块进行测试。因模块群1、模块群2中的模块均隶属于模块Ma，因此在驱动模块D1、D2去掉后，模块群1与模块群2直接与Ma接口，这时可对MaD3被去掉后，M3与模块群3直接接口，可对Mb进行集成测试，最后Ma、Mb和 Mc全部集成在一起进行测试。 自底向上集成方法不用桩模块，测试用例的设计亦相对简单，但缺点是程序最后一个模块加入时才具有整体形象。它与自顶向综合测试方法优缺点正好相反。因此，在测试软件系统时，应根据软件的特点和工程的进度，选用适当的测试策略，有时混和使用两种策略更为有效，上层模块用自顶向下的方法，下层模块用自底向上的方法。此外，在综合测试中尤其要注意关键模块，所谓关键模块一般都具有下述一或多个特征：对应几条需求；具有高层控制功能；复杂、易出错；有特殊的性能要求。关键模块应尽早测试，并反复进行回归测试。确认测试的基本方法 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步确认测试即可开始。确认测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。1. 确认测试标准实现软件确认要通过一系列墨盒测试。确认测试同样需要制订测试计划和过程，测试计划应规定测试的种类和测试进度，测试过程则定义一些特殊的测试用例，旨在说明软件与需求是否一致。无是计划还是过程，都应该着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整、准确人机界面和其他方面（例如，可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。确认测试的结果有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；另一种是软件不满足?这个阶段才发现严重错误和偏差一般很难在预定的工期内改正，因此必须与用户协商，寻求一个妥善解决问题的方法。2. 配置复审确认测试的另一个重要环节是配置复审。复审的目的在于保证软件配置齐全、分类有序，并且包括软件维护所必须的细节。3. 、测试事实上，软件开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误的理解命令，或提供一些奇怪的数据组合，亦可能对设计者自认明了的输出信息迷惑不解，等等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”。验收测试既可以是非正式的测试，也可以有计划、有系统的测试。有时，验收测试长达数周甚至数月，不断暴露错误，导致开发延期。一个软件产品，可能拥有众多用户，不可能由每个用户验收，此时多采用称为、测试的过程，以期发现那些似乎只有最终用户才能发现的问题。测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为版本）进行测试，试图发现错误并修正。测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的 用户操作方式。经过测试调整的软件产品称为版本。紧随其后的测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对版本进行改错和完善。系统测试的基本方法 计算机软件是基于计算机系统的一个重要组成部分，软件开发完毕后应与系统中其它成分集成在一起，此时需要进行一系列系统集成和确认测试。对这些测试的详细讨论已超出软件工程的范围，这些测试也不可能仅由软件开发人员完成。在系统测试之前，软件工程师应完成下列工作： （1） 为测试软件系统的输入信息设计出错处理通路； （2） 设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助； （3） 参与系统测试的规划和设计，保证软件测试的合理性。系统测试应该由若干个不同测试组成，目的是充分运行系统，验证系统各部件是否都能政党工作并完成所赋予的任务。下面简单讨论几类系统测试。、恢复测试恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。、安全测试安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，想方设法截取或破译口令；专门定做软件破坏系统的保护机制；故意导致系统失败，企图趁恢复之机非法进入；试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。、强度测试强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；定量地增长数据输入率，检查输入子功能的反映能力；运行需要最大存储空间（或其他资源）的测试用例；运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。、 性能测试对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，但只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。五、软件测试的类型常见的软件测试类型有： BVT (Build Verification Test) BVT是在所有开发工程师都已经检入自己的代码，项目组编译生成当天的版本之后进行，主要目的是验证最新生成的软件版本在功能上是否完整，主要的软件特性是否正确。如无大的问题，就可以进行相应的功能测试。BVT优点是时间短，验证了软件的基本功能。缺点是该种测试的覆盖率很低。因为运行时间短，不可能把所有的情况都测试到。 Scenario Tests（基于用户实际应用场景的测试） 在做BVT、功能测试的时候，可能测试主要集中在某个模块，或比较分离的功能上。当用户来使用这个应用程序的时候，各个模块是作为一个整体来使用的，那么在做测试的时候，就需要模仿用户这样一个真实的使用环境，即用户会有哪些用法，会用这个应用程序做哪些事情，操作会是一个怎样的流程。加了这些测试用例后，再与BVT、功能测试配合，就能使软件整体都能符合用户使用的要求。Scenario Tests优点是关注了用户的需求，缺点是有时候难以真正模仿用户真实的使用情况。 Smoke Test 在测试中发现问题，找到了一个Bug，然后开发人员会来修复这个Bug。这时想知道这次修复是否真的解决了程序的Bug，或者是否会对其它模块造成影响，就需要针对此问题进行专门测试，这个过程就被称为Smoke Test。在很多情况下，做Smoke Test是开发人员在试图解决一个问题的时候，造成了其它功能模块一系列的连锁反应，原因可能是只集中考虑了一开始的那个问题，而忽略其它的问题，这就可能引起了新的Bug。Smoke Test优点是节省测试时间，防止build失败。缺点是覆盖率还是比较低。 此外，Application Compatibility Test（兼容性测试），主要目的是为了兼容第三方软件，确保第三方软件能正常运行，用户不受影响。Accessibility Test（软件适用性测试），是确保软件对于某些有残疾的人士也能正常的使用，但优先级比较低。其它的测试还有Functional Test（功能测试）、Security Test（安全性测试）、Stress Test（压力测试）、Performance Test（性能测试）、Regression Test（回归测试）、Setup/Upgrade Test（安?支持工具 一些受软件开发人员欢迎的软件测试工具为软件测试提供了强有力的支持。本文将介绍美国Rational公司的著名套装软件SQA和Pure Atria公司极具特色的Purify。 SQA SuiteSQA直接支持对客户/服务器应用软件的测试,它的一个重要特点是可以自动驱动被测程序的运行。SQA可以自动记录和重放程序执行过程,从而实现了对测试进行复查的自动化。 由于测试是一个需要反复进行的过程,常常要数十次甚至数百次地重复。因此,这一特性大大地提高了软件再测试(Re-Test)和回归测试(Regression)的自动化程度,把测试人员从繁杂的、重复性的手工测试中解脱出来,从而显著地提高软件测试效率。 除了这个最基本的自动录放功能外,它还提供了一系列的辅助支持功能,比如, 被录制的程序执行过程可以被自动转换成具有良好可读性的高级语言程序,从而使这个测试驱动程序可以由测试人员根据测试需要进行必要的修改,甚至完全用手工方式编制。 自动记录和分析比较测试的执行结果。不论是简单的正文方式的输出结果,还是任意的图表、声音、动画、图形用户界面(GUI)中的任一构件,都可以根据测试人员的指定被自动记录在测试结果库中,并可对两次测试的结果自动地进行比较,指出其差异部分。此项功能无疑对自动查找错误很有帮助。 调节和设定事件的发生时间和速度。 基本的测试库管理功能。 此外,SQA还支持软件测试人员进行以下工作: 制定测试计划和测试大纲,并将这些文档按照自然的树状结构分层地管理起来,并据此控制和驱动整个测试过程。 不仅能够自动记录各类测试结果,而且对其进行修改,从而使得测试人员可以在程序运行结果尚有许多错误的情况下,通过对所记录下的结果做适当修正来获得理想的期望结果 ,为测试结果的自动比较奠定基础。 测试问题报告的记录与管理。 总之,SQA Suite提供了一个比较完整的测试平台,以支持软件测试的各种基本活动,包括测试计划与测试大纲的制定、回归测试的自动化、测试结果的分析比较、软件问题报告的生成与自动分发和控制等。对于许多应用软件的开发无疑是个有力的测试支持工具。 Purify是原PureAtria公司(现已经与美国Rational公司合并,改名为美国Rational公司)于90年代初率先推出的专门用于检测程序中种种内存使用错误的软件工具。几乎所有使用过C语言开发软件的程序员都会有这样的体会,C语言中使用极为灵活的指针给程序员带来了很大便利,但同时也制造了许多的麻烦。由于指针使用不当而引起的错误通常是最难发现的,同时也是最难定位的一类错误。而Purify对多种常见的内存使用错误的检错能力和准确的定位,受到广大软件开发人员的青睐。 Purify可以自动识别出二十多种内存使用错误,包括 未初始化的局部变量 未申请的内存 使用已释放的内存 数组越界 内存丢失 文件描述问题 栈溢出问题 栈结构边界错误等 在下面的例子中,暗藏着两个内存使用错误。第一行为指针数组pp申请的空间尺寸不对。这类错误往往不易发现,因为在C语言中,一些轻微的内存越界可能被系统所容忍。但这往往是导致更严重错误的根源。例如,可能破坏其它数据区等。最后一行的错误是在释放pp 之前没有释放赋予它的字符串空间,从而把它们丢失了。这类错误犹如慢性自杀,它会逐渐消耗掉内存,降低系统的运行效率,直到完全崩溃。而真正的问题在于,这些程序中的恶性肿瘤用常规的测试手段和调试工具是极难发现和加以定位的。Purify则在此充分显示了它的强大功效,所到之处,即对所测试过的情况,上述各种常见的内存错误都可以被一一揭露出来,并且准确地指出错误的类型和位置。从而大大地提高了测试和纠错的效率,提高了软件的可靠性。 /to get 10 words and print them out/ if(!(pp=(char*)malloc(10) /*Size should be 10*sizeof(char*)*/ printf(Out of memory.n); exit(-1); for(i=0;iPure,包括支持内存检测的Purify ,支持路径覆盖的PureCoverage,支持多线程应用程序性能测试的Quantify,以及用以提高测试期间连接编译被测程序效率的PureLink等。Pure系列现已支持C、C 、FORTRAN语言,以及UNIX和Window NT等操作系统,如Sun OS、Solaris 2.3,HP-UX,Windows NT Server以及IBM A/ X等。 结束语 充分认识软件测试的重要性和复杂性,合理地选择测试方法,有效地组织测试人员和安排测试任务,并且尽量使用软件测试工具增强软件测试的自动化程度,无疑可以帮助软件开发和测试人员大大提高测试效率和软件的质量。七、软件测试的基本过程 软件测试是一个极为复杂的过程。如图一所示,一个规范化的软件测试过程通常须包括以下基本的测试活动。 拟定软件测试计划 编制软件测试大纲 设计和生成测试用例 实施测试 生成软件问题报告 对整个测试过程进行有效的管理实际上,软件测试过程与?早在需求分析阶段即应开始制定,其它相关工作,包括测试大纲的制定、测试数据的生成、测试工具的选择和开发等也应在测试阶段之前进行。充分的准备工作可以有效地克服测试的盲目性,缩短测试周期,提高测试效率,并且起到测试文档与开发文档互查的作用。 此外,软件测试的实施阶段是由一系列的测试周期(Test Cycle)组成的。在每个测试周期中,软件测试工程师将依据预先编制好的测试大纲和准备好的测试用例,对被测软件进行完整的测试。测试与纠错通常是反复交替进行的。当使用专业测试人员时,测试与纠错甚至是平行进行的,从而压缩总的开发时间。更重要的是,由于专业测试人员丰富的测试经验、所采用的系统化的测试方法、全时的投入,特别是独立于开发人员的思维,使得他们能够更有效地发现许多单靠开发人员很难发现的错误和问题。 软件测试大纲是软件测试的依据。它明确详尽地规定了在测试中针对系统的每一项功能或特性所必须完成的基本测试项目和测试完成的标准。无论是自动测试还是手动测试,都必须满足测试大纲的要求。 一般而言,测试用例是指为实施一次测试而向被测系统提供的输入数据、操作或各种环境设置。测试用例控制着软件测试的执行过程,它是对测试大纲中每个测试项目的进一步实例化。已有许多著名的论著总结了设计测试用例的各种规则和策略。从工程实践的角度讲有几条基本准则: 1.测试用例的代表性:能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等; 2.测试结果的可判定性:即测试执行结果的正确性是可判定的或可评估的; 3.测试结果的可再现性:即对同样的测试用例,系统的执行结果应当是相同的。八、制定成功的测试计划 “工欲善其事，必先利其器”。专业的测试必须以一个好的测试计划作为基础。尽管测试的每一个步骤都是独立的，但是必定要有一个起到框架结构作用的测试计划。测试的计划应该作为测试的起始步骤和重要环节。一个测试计划应包括：产品基本情况调研、测试需求说明、测试策略和记录、测试资源配置、计划表、问题跟踪报告、测试计划的评审、结果等等。 产品基本情况调研： 这部分应包括产品的一些基本情况介绍，例如：产品的运行平台和应用的领域，产品的特点和主要的功能模块，产品的特点等。对于大的测试项目，还要包括测试的目的和侧重点。 具体的要点有： 目的：重点描述如何使测试建立在客观的基础上，定义测试的策略，测试的配置， 粗略的估计测试大致需要的周期和最终测试报告递交的时间。 变更：说明有可能会导致测试计划变更的事件。包括测试工具改进了，测试的环境改变了，或者是添加了新的功能。 技术结构：可以借助画图，将要测试的软件划分成几个组成部分，规划成一个适用于测试的完整的系统，包括数据是如何存储的，如何传递的（数据流图），每一个部分的测试是要达到什么样的目的。每一个部分是怎么实现数据更新的。还有就是常规性的技术要求，比如运行平台、需要什么样的数据库等等。 产品规格：就是制造商和产品版本号的说明。 测试范围：简单的描述如何搭建测试平台以及测试的潜在的风险。 项目信息：说明要测试的项目的相关资料，如：用户文档，产品描述，主要功能的举例说明。 测试需求说明： 这一部分要列出所有要测试的功能项。凡是没有出现在这个清单里的功能项都排除在测试的范围之外。万一有一天你在一个没有测试的部分里发现了一个问题，你应该很高兴你有这个记录在案的文档，可以证明你测了什么没测什么。具体要点有： 功能的测试：理论上是测试是要覆盖所有的功能项，例如：在数据库中添加、编辑、删除记录等等，这会是一个浩大的工程，但是有利于测试的完整性。 设计的测试：对于一些用户界面、菜单的结构还有窗体的设计是否合理等的测试。 整体考虑：这部分测试需求要考虑到数据流从软件中的一个模块流到另一个模块的过程中的正确性。 测试的策略和记录： 这是整个测试计划的重点所在，要描述如何公正客观地开展测试，要考虑：模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响。要尽可能的考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备，测试记录重要包括的部分具体说明如下： 公正性声明：要对测试的公正性、遵照的标准做一个说明，证明测试是客观的，整体上，软件功能要满足需求，实现正确，和用户文档的描述保持一致。 测试案例：描述测试案例是什么样的，采用了什么工具，工具的来源是什么，如何执行的，用了什么样的数据。测试的记录中要为将来的回归测试留有余地，当然，也要考虑同时安装的别的软件对正在测试的软件会造成的影响。 特殊考虑：有的时候，针对一些外界环境的影响，要对软件进行一些特殊方面的测试。 经验判断：对以往的测试中，经常出现的问题加以考虑。 设想：采取一些发散性的思维，往往能帮助你找的测试的新途径。 测试资源配置： 项目资源计划：制定一个项目资源计划，包含的是每一个阶段的任务、所需要的资源，当发生类似到了使用期限或者资源共享的事情的时候，要更新这个计划。 计划表： 测试的计划表可以做成一个多个项目通用的形式，根据大致的时间估计来制作，操作流程要以软件测试的常规周期作为参考，也可以是根据什么时候应该测试哪一个模块来制定。 问题跟踪报告： 在测试的计划阶段，我们应该明确如何准备去做一个问题报告以及如何去界定一个问题的性质，问题报告要包括问题的发现者和修改者、问题发生的频率、用了什么样的测试案例测出该问题的，以及明确问题产生时的测试环境。 问题描述尽可能是定量的，分门别类的列举，问题有几种： 1、严重问题：严重问题意味着功能不可用，或者是权限限制方面的失误等等，也可能是某个地方的改变造成了别的地方的问题。 2、一般问题：功能没有按设计要求实现或者是一些界面交互的实现不正确。 3、建议问题：功能运行得不象要求的那么快，或者不符合某些约定俗成的习惯，但不影响系统的性能，界面先是错误，格式不对，含义模糊混淆的提示信息等等。 测试计划的评审： 又叫测试规范的评审，在测试真正实施开展之前必须要认真负责的检查一遍，获得整个测试部门人员的认同，包括部门的负责人的同意和签字。 结果： 计划并不是到这里就结束了，在最后测试结果的评审中，必须要严格验证计划和实际的执行是不是有偏差，体现在最终报告的内容是否和测试的计划保持一致，然后，就可以开始着手制作下一个测试计划了。九、报告软件测试错误的规范 报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误，从而有利于分析错误产生的原因，定位错误，然后修正之。因此，报告软件测试错误的基本要求是准确、简洁、完整、规范。需要掌握的报告技术归纳如下。 1. 描述 (Description)，简洁、准确，完整，揭示错误实质，记录缺陷或错误出现的位置 描述要准确反映错误的本质内容，简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。 2. 明确指明错误类型：布局、翻译、功能、双字节 根据错误的现象，总结判断错误的类型。例如，即布局错误、翻译错误、功能错误、双字节错误，这是最常见的缺陷或错误类型，其他形式的缺陷或错误也从属于其中某种形式。 3. 短行之间使用自动数字序号，使用相同的字体、字号、行间距 短行之间使用自动数字序号，使用相同的字体、字号、行间距，可以保证各条记录格式一致，做到规范专业。 4. UI要加引号，可以单引号，推荐使用双引号 UI加引号，可以容易区分UI与普通文本，便于分辨、定位缺陷或错误。 5. 每一个步骤尽量只记录一个操作 保证简洁、条理井然，容易重复操作步骤。 6. 确认步骤完整，准确，简短 保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短”即没有多余的步骤。 7. 根据缺陷或错误类型，选择图象捕捉的方式 为了直观的观察缺陷或错误现象，通常需要附加缺陷或错误出现的界面，以位图的形式作为附件附着在记录的“附件”部分。为了节省空间，又能真实反映缺陷或错误本质，可以捕捉缺陷或错误产生时的全屏幕，活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置，通常要求附加中英文对照图。 8. 附加必要的特殊文档和个人建议和注解 如果打开某个特殊的文档而产生的缺陷或错误，则必须附加该文档，从而可以迅速再现缺陷或错误。有时，为了使缺陷或错误修正者进一步明确缺陷或错误的表现，可以附加个人的修改建议或注解。 9. 检查拼写和语法错误 在提交每条缺陷或错误之前，检查拼写和语法，确保内容正确，正确的描述错误。 10. 尽量使用业界惯用的表达术语和表达方法 使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。 11. 通用UI要统一、准确 错误报告的UI要与测试的软件UI保持一致，便于查找定位。 12. 尽量使用短语和短句，避免复杂句型句式 软件错误管理数据库的目的是便于定