软件测试的基本理论和方法1

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,软件测试培训,测试的基本理论及方法,测试的基本理论及方法,对软件测试的误解,如何理解软件测试,软件测试的定义,软件测试的对象,测试的目的,软件测试的分类,测试类型的解释,黑盒测试的几种典型方法,测试的分类与比较,测试流程,测试规范,软件测试的文档和模版,软件系统的主要测试内容及技术,WEB,应用的测试,测试工作中需要注意的问题,企业的测试策略,关于测试的几个问题,对软件测试的误解,如果发布出去的软件有质量问题,那是软件测试人员的错,.,软件测试技术要求不高,至少比编程容易多了,.,软件测试随便找一个能力差的人就能做,.,有时间就多测试一些,来不及就少测试一些,.,软件测试是测试人员的事,与开发人员无关,.,设计,-,实现,-,测试,软件测试是开发后期的一个阶段,如何理解软件测试,软件测试是一种有效的提高软件质量的手段,但即使在投入上有所保证,测试也不能百分百发现所有质量隐患,.,况且软件质量并不仅仅是测试出来的,.,很多人认为软件测试就是运行一下软件,看看结果对不对,.,但实际上,如何在有限的投入下,提高软件测试的效率和产出是一件很见功底的事,.,好的测试人员不仅要掌握各种测试技术,还要具备丰富的编程经验和对,BUG,的敏感,.,测试的复杂之处,除了测试技术问题之外,还有测试管理问题,.,测试不是可有可无,随心所欲的,.,规范化的软件开发需要对软件测试早做计划,分配必要的时间,人力和财力等资源,并将其作为项目管理的一个部分加以控制和协调,.,开发和测试是软件项目相辅相成的两个过程,人员间的交流,协作和配合是提高整体效率的重要因素,.,软件产品开发完毕,再进行测试的观念是有悖于生命周期理论的,.,软件产品质量问题越晚发现,修复的代价越大,.,需求,设计,编程,内部测试,外部测试,发布,修正,BUG,的代价,一些常识和经验之谈,测试能提高软件的质量，但是提高质量不能依赖测试。,测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。,测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。,每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。,80-20,原则：,80,的缺陷聚集在,20,的模块中，经常出错的模块改错后还会经常出错,测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。,软件测试的定义,软件测试是为了发现错误而执行程序的过程,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例,(,即输入数据及其预期的输出结果,),并利用这些测试用例去运行程序,以发现程序错误的过程,软件测试就是在软件投进运行前，对软件需求分析、设计规格说明和编码的终极复审，是软件质量保证的关键步骤。,软件测试不等于程序测试,.,软件测试贯穿于软件定义和开发的整个期间,.,需求分析,概要设计,详细设计,以及程序编码等各个阶段所得到的文档,包括需求规格说明,概要设计规格说明,详细设计规格说明以及源程序,都是软件测试的对象,.,软件测试的对象,软件生存各个阶段间的确认和验证,软件配置：包括软件需求规格说明、软件设计规格说明、源代码等；,测试配置：包括测试计划、测试用例、测试驱动程序等。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。,测试工具：为提高软件测试效率，可使用测试工具支持测试工具。例如：测试数据自动生成程序、测试结果分析程序等。,测试的目的,关于测试的目的，一般的观点认为，测试主要是为了查找软件中存在的错误。实际上，软件测试的目的不仅于此，具体如下：,验证需求与设计的正确性；,发现软件存在的错误；,为软件开发商、用户确立关于软件质量的信心。,软件测试的分类,软件测试是一项复杂的系统工程，从不同的角度考虑可以有不同的划分方法，对测试进行分类是为了更好的明确测试的过程，了解测试究竟要完成哪些工作，尽量做到测试的全面性。,软件测试,按是否查看代码划分,按阶段划分,按是否运行程序划分,其他,动态测试,静态测试,验收测试,系统测试,集成测试,单元测试,灰盒测试,白盒测试,黑盒测试,冒烟测试,回归测试,随机测试,兼容性测试,安装测试,易用性测试,界面测试,逻辑测试,性能测试,功能测试,压力测试,负载测试,稳定性测试,一般性测试,测试类型的解释,名称,说明,静态测试,静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试,结果可用于进一步的差错,并为测试用例选取提供指导。,动态测试,动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。,单元测试,主要测试软件模块的源代码。一般由开发人员而非独立测试人员来执行，因为测试者需要懂得该单元的设计与程序实现，测试者可能需要编写额外的测试驱动程序。,集成测试,将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可以是程序模块、客户机服务器程序等等。,名称,说明,系统测试,测试软件系统是否符合所有需求，包括功能性需求与非功能性需求。一般由独立测试人员执行，通常采用黑盒测试方式。,验收测试,由客户或最终用户执行，测试软件系统是否符合需求规格说明书。,回归测试,回归测试是指对某些已经被测试过的内容进行重新测试。每当软件增加了新的功能，或者软件中的缺陷被修正，这些变更都有可能影响软件原有的功能和结构。为了防止软件的变更产生无法预料的副作用，不仅要对新内容进行测试，还要对某些老,内容进行回归测试。,Alpha,测试,一种先期的用户测试，此时系统刚刚开发完成。,Alpha,测试是由一个用户或多个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操纵环境下进行的受控测试，,Alpha,测试不能由该系统的程序员或测试员完成。,Beta,测试,一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。,测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，,Beta,测试不能由程序员或测试员完成。,名称,说明,白盒测试,是结构测试，也是逻辑驱动测试。,基于软件内部设计和程序实现的测试方式。,白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定,/,条件覆盖、条件组合覆盖和路径覆盖。,黑盒测试,是功能测试，也是数据驱动测试。,基于软件需求所进行的测试。不关心软件内部结构、程序实现的算法。,灰盒测试,是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。,压力测试,压力测试是对系统不断施加压力的测试，通过确定一个系统的瓶颈或者不能接收的性能点来获得系统能提供的最大服务级别的测试。是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行软件压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽。目的是：需要了解AUT(被测应用程序)一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。,负载测试,负载测试（,Load testing,），通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。,名称,说明,性能测试,测试软件在各种状况下的性能，如在正常或最大负载下的状况。包括负载测试、压力测试。,易用性测试,测试软件是否易用，主观性比较强。一般要根据很多用户的测试反馈信息，才能评价易用性。,安装与反安装测试,测试软件在“全部、部分、升级”等状况下的安装,/,反安装过程。,恢复测试,测试该系统从故障中恢复过来的能力。,安全性测试,测试该系统防止非法侵入的能力。,兼容性测试,测试该系统与其它软件硬件兼容的能力。,比较测试,通过与同类产品比较，考察该系统的优点、缺点。,可移植性测试,可移植性测试是指测试软件是否可以被成功移植到指定的硬件或软件平台上。,用户界面测试,-UI,测试,用户界面是指软件中的可见外观及其底层与用户交互的部分（菜单、对话框、窗口和其它控件）。,用户界面测试是指测试用户界面的风格是否满足客户要求，文字是否正确，页面是否美观，文字、图片组合是否完美，操纵是否友好等等。,UI,测试的目标是确保用户界面为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操纵性测试。,黑盒测试的几种典型方法,名称,说明,等价划分测试,等价划分测试是根据等价类设计测试用例的一种技术。是黑盒测试的典型方法之一，通过把被测试程序所有可能的输进数据域划分成若干部分。从每一部分中选取少数有代表性的数据作为测试用例，可有效减少测试次数，提高软件测试效率，缩短软件开发周期。,等价划分测试的目的就是为了在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果。,等价类在测试数据设计上，分为有效等价类和无效等价类。有效等价类中的数据代表的是一组符合需求文档的正确的有意义数据。无效等价类则正相反,边界条件测试,等价划分方法的一种补充,由长期的测试工作经验得知，大量的错误是发生在输进或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。,测试的分类与比较,黑盒测试与白盒测试的比较,白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档,黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档,测试方式,特征,依据,测试人员,测试驱动程序,黑盒测试,只关心软件的外部表现，不关心内部设计与实现。,软件需求,任何人（包括开发人员、独立测试人员和用户）,一般无需编写额外的测试驱动程序,白盒测试,关注软件的内部设计与实现，要跟踪源代码的运行。,设计文档,由开发人员兼任测试人员的角色,需要编写额外的测试驱动程序,不同阶段测试作用的比较,单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。,单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。,集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。,系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。,验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。,开发与测试的,V,型关系,如果软件开发过程采用严格的瀑布模型，那么开发与测试有“,V”,型的对应关系 。,需求开发,高层设计,详细设计,编程,单元测试,集成测试,系统测试,验收测试,测试流程,测试流程,第一步：制定测试计划。该计划被批准后转向第二步。,第二步：设计测试用例。该用例被批准后转向第三步。,第三步：如果满足“启动准则” ，那么执行测试。,第四步：撰写测试报告。,第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。,制定测试计划,设计测试用例,执行测试,写测试报告,消除软件缺陷,审批,审批,回归测试,完成,测试,完成准则,启动准则,测试的信息流,测试信息流如下图所示：,软件测试的策略,在软件工程中，测试过程应该按,4,个步骤进行，即单元测试、组装（集成）测试、确认测试和系统测试。下图给出了软件测试经历的,4,个步骤。,测试规范,测试启动准则,同时满足以下条件，允许开始测试：,（,1,）测试计划已经制定并且通过了审批；,（,2,）测试用例已经设计并且通过了审批；,（,3,）被测试对象已经开发完毕并等待测试。,( 4) 被测试对象基本满足需求需要。,（）,测试完成准则,对于非严格系统可以采用“基于测试用例”的准则。同时满足以下条件允许结束测试：,（,1,）功能性测试用例通过率达到,100,；,（,2,）非功能性测试用例通过率达到,90,时。,对于严格系统，应当补充“基于测试期缺陷密度”的规则：,（,3,）相邻,n,个,CPU,小时内“测试期缺陷密度”全部低于某个值,m,。例如,n,大于,10,，,m,小于等于,1,。,软件测试的文档和模版,测试计划,：指明范围、方法、资源，以及相应测试活动的时间进度安排表的文档。,一个测试计划应包括：产品基本情况描述、测试需求说明、测试策略描述、测试资源配置、计划表、问题跟踪报告、停测标准、风险分析等,测试方案,：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。测试方案一般主要包括以下几个方面：测试配置要求、软件结构介绍、各测试阶段测试用例等。,测试用例,：指明为完成一个测试项的测试输入、预期结果、预期执行条件等因素的文档。,测试用例文档结构一般包含以下几个方面：编写目的,、,被测对象分析,、,测试预置条件,、,测试用例列表,、,测试用例,。,测试报告,：指明执行测试结果的文档。,测试计划,测试计划一般从测试的目的、范围、背景、测试策略、测试人员的组织、测试启动准则与结束准则，以及测试任务，测试中可能遇到的问题与对策等多方面来写测试计划。,测试计划的目的,收集并分析被测软件的需求情况；,细化待测的需求，如动态需求、性能需求等；,尽量量化测试需求，并给出测试标准；,制定停测标准，控制测试成本；合理配置测试资源；,评估测试风险，尽量避免或减少风险带来的损失。,测试计划内容,定义测试需求,需要考虑的测试内容,:,软件功能；用户界面；软件性能；配置测试；安装卸载测试；安全性测试等。,测试设计的目标,:,定义手动测试过程、自动测试过程、选择适当的测试用例、组织测试过程信息,并传递给测试开发人员。,评审测试计划,涉及评审的问题,评审测试的开始时间是否会延期,有没有抵触评审的角色,一段时间内是否很难得到工作的检查信息,更换工具有可能导致他们反感评审工作,评审结果可能会影响对个人的工作评价,对于最终成品的检查,项目的需求规格说明书,软件返工,/,维护的文档,升级后的技术文档,被更改的源程序,测试计划,用户手册（包括在线帮助）,测试方案,测试方案的目的,根据测试计划，规划测试内容，并且详细制定被测需求的测试方法。,测试方案内容,确定测试手段，确定在各个阶段使用何种测试方法。,测试通过准则界定。,各测试阶段所用测试用例，如单元测试阶段、集成测试阶段等。,测试用例,测试用例设计方法,一般的测试用例设计方法有等价类、边界值、错误推断、因果图、比较测试法、决策表等。,测试用例文档结构,测试用例文档结构一般包含以下几个方面：编写目的、被测对象分析、测试预置条件、测试用例列表、测试用例。,被测对象分析,对每个被测对象的分析描述，描述影响被测对象行为的各个因素，及其各个因素可能的取值。,测试预置条件,描述执行本测试用例需要预置的条件，例如数据库中需要存在什么数据、需要配置什需要处于什么状态。,测试用例,测试用例主要包括如下内容：,描述测试用例类别：功能、容错、性能等,测试用例编号,被测对象名称,子功能名称,测试阶段,测试目标（功能验证，容错处理,）,输入数据及操作步骤，需要描述每个步骤使用什么命令、需要什么操作、需要什么样的输入数据、对于输入数据需要具体说明数据格式以及内容,预期结果,测试用力注意事项,如果测试用例执行有特殊要求，必须说明。,测试用例要覆盖到所有需求，且与需求保持一致。,测试用例之间不重复、无冗余。,每个测试用例都描述正确。,每个测试用例要保证测试执行者在每次测试时依照同样的环境、同样的步骤、同样的数据进行测试。,保证不同的测试执行者的测试执行过程一致，或者同一个测试执行者在多次的测试执行中保持一致。,测试用例,测试报告的目的,总结当前的软件测试工作，对被测软件的版本质量作出评估，给产品能否发布一个参考值。,测试报告里的内容其实不复杂，重点是我们如何对当前的测试版本进行分析，一般地我们从下面几个方面分析。,缺陷分布：所谓缺陷分布，就是统计软件产品中缺陷的分布情况，看哪些功能模块存在的缺陷较多。,缺陷修复情况：缺陷修复情况同样是我们测试报告中必不可少的一个分析点。通过缺陷的修复情况，我们来决定测试是否终止。,遗留缺陷：遗留缺陷是对当前测试版本中尚未解决的缺陷进行的分析统计。通过分析得知，哪些问题没有解决，是什么原因，这些问题对软件的质量影响有多大等。,质量评估：质量评估是测试组对被测对象质量的一个综合的总结。,软件系统的主要测试内容及技术,接口与路径测试,功能测试,健壮性测试,性能测试,用户界面测试,信息安全测试,压力测试,可靠性测试,安装,/,反安装测试,接口与路径测试,数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。每个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不少。根据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。如果实际输出与期望的输出不一致，那么说明程序有错误。白盒方式的接口测试和黑盒方式的功能测试，其方法十分相似。,一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。,对于非严格系统而言，在分析路径,方面花费很多精力是不值得的。我认为在构造接口测试的同时已经建立了测试路径。因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。由于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，用不着费煞苦心地去找测试路径。,路径测试的检查表,数据类型、变量值、逻辑判断、循环、内存管理、文件,I/O,、错误处理,由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。预防措施有：,观察是否有程序语句从来没有被执行过。如果发生这种情况，要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一些路径。,要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。,接口与路径测试用例的参考模板,功能测试,功能测试的基本方法是构造一些合理输入（在需求范围之内），检查输出是否与期望的相同。如果两者不一致，即表明功能有误。也有例外的情况，如,需求规格说明书,中的某个功能写错了，而实际上软件的功能却是正确的，这时要更改的是,需求规格说明书,。,功能测试看起来比较简单，只要看得懂,需求规格说明书,，谁都会做。难点在于如何构造有效的输入。由于输入空间通常是无限的，穷举测试显然行不通。那么随便输入一些东西，碰运气行不行？,功能测试有两种比较好的测试方法：,等价划分法,和边界值分析法。,等价划分是指把输入空间划分为几个“等价区间”，在每个“等价区间”中只需要测试一个典型值就可以了。等价划分法来源于人们的直觉与经验，可令测试事半功倍。,“缺陷遗漏在角落里，聚集在边界上”。边界值测试法是对等价划分法的补充。如果,A,和,B,是输入空间的边界值，那么除了典型值外还要用,A,和,B,作为测试用例。,例如测试函数。凭直觉，等价区间应是（,0, 1,）和（,1, +,）。可取典型值,x=0.5,以及,x=2.0,进行“等价划分”测试。再取,x=0,以及,x=1,进行“边界值”测试。,功能测试用例的参考模板,健壮性测试,健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。,容错性测试通常构造一些不合理的输入来引诱软件出错，例如：,（,1,）输入错误的数据类型。如“猴”年“马”月；,（,2,）输入定义域之外的数值。如上海人常说的“十三点” 。,粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试客户机服务器模式的软件时，把网络线拔掉，造成通信异常中断。,恢复测试重点考察以下几项：,（,1,）系统能否重新运行；,（,2,）有无重要的数据丢失；,（,3,）是否毁坏了其它相关的软件硬件。,目标,当在进行安装或组装操作过程中，文件丢失时或发生意外后系统有能力重新进行操作,如何使用,程序的安装，运行方式，工具的使用和关键技术经过足够的评估,系统开发完毕后，介绍一下发生失败后的处理过程,例子,人为的使一个系统在安装或者组装过程中产生错误,什么时间去使用,当操作的连续性是个重点的时候,健壮性测试用例的参考模板,性能测试,性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。,有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。,在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。,性能测试的一些注意事项：,不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。,应当测试软件在标准配置和最低配置下的性能。,为了排除干扰，应当关闭那些消耗内存、占用,CPU,的其它应用软件（如杀毒软件）。,不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从,100K,到,1M,可以分成若干等级。,由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。,目标,确定系统达到了希望达到的性能水平,如何使用,使用软件和硬件的监视器,使用模拟的监控模型，对关心的性能指标进行监控,创建一个小程序,例子,计算通信的时间,单位时间处理的信息量,用户界面测试,绝大多数软件拥有图形用户界面。图形用户界面的测试重点是正确性、易用性和视觉效果。在评价易用性和视觉效果时，主观性非常强，应当考虑多个人的观点。,用户界面测试用例的参考模板：,信息安全测试,信息安全性（,security,）是指防止系统被非法入侵的能力，既属于技术问题又属于管理问题。,信息安全性测试有如下步骤：,为非法入侵设立目标，例如“盗窃某个文件”或“更改数据库记录”等。,邀请（或悬赏）一些人扮演黑客，让他们想尽办法入侵系统，实现“目标”。,如果有人成功了，请他详述入侵的过程。别忘了给予奖励。,目标,安全性的缺陷很难被发现,大多诉的情况下组织能够防止一般性的破坏者,如何使用,对安全性的需求进行审评,分析与安全性有关的处理流程,转包给专业的人员,例子,定义了被保护的资源,，权限进行了控制，日志文件和审查追踪是可能的,什么时间使用,当被保护的资源对于组织具有重要的价值的时候,信息安全性测试用例的参考模板,压力测试,压力测试也叫负荷测试，即获取系统能正常运行的极限状态。了解“极限”是很有价值的，例如潜艇下潜极限深度,。,压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚好不瘫痪。,压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动会导致系统的表现（如性能）发生急剧的变化。敏感测试目的是发现什么样的输入可能会引发不稳定现象。,目标,模拟出实际用户环境,怎么用,产生测试数据,测试组模拟用户处理被创建的数据,例子,确定是否分配了足够的磁盘空间,通讯的容量是否足够,测试系统过载的情况,什么时间使用,当关于容量的信息不确定的时候,压力测试用例的参考模板,可靠性测试,可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠性测试可能会花费很长时间。,比较实用的办法是，让用户使用该系统，记录每一次发生故障的时刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和“平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“可靠”的程度。,可靠性测试用例的参考模板,安装,/,反安装测试,安装,/,反安装测试的目的：避免“大风浪都挺过来了，却在阴沟里翻了船”,目前市面上有非常流行的、专门制作安装,/,反安装程序的一些工具，如,Install Shelled,。制作安装,/,反安装程序不再是件难事，关键是不要麻痹大意。主要测试工作：,（,1,）至少在标准配置和最低配置两种环境下测试；,（,2,）如果有安装界面，应当尝试各种选项，如选择“全部”、“部分”、“升级”等。,安装,/,反安装测试用例的参考模板,WEB,应用的测试,一、功能测试,1,、链接测试,链接是,Web,应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证,Web,应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的,URL,地址才能访问。,链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个,Web,应用系统的所有页面开发完成之后进行链接测试。,2,、表单测试,当用户给,Web,应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。,3,、,Cookies,测试,Cookies,通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用,Cookies,访问了某一个应用系统时，,Web,服务器将发送关于用户的信息，把该信息以,Cookies,的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。,如果,Web,应用系统使用了,Cookies,，就必须检查,Cookies,是否能正常工作。测试的内容可包括,Cookies,是否起作用，是否按预定的时间进行保存，刷新对,Cookies,有什么影响等。,4,、设计语言测试,Web,设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的,HTML,等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了,HTML,的版本问题外，不同的脚本语言，例如,Java,、,javascript,、,ActiveX,、,VBScript,或,Perl,等也要进行验证。,5,、数据库测试,在,Web,应用技术中，数据库起着重要的作用，数据库为,Web,应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在,Web,应用中，最常用的数据库类型是关系型数据库，可以使用,SQL,对信息进行处理。,在使用了数据库的,Web,应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。,二、性能测试,1,、连接速度测试,用户连接到,Web,应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果,Web,系统响应时间太长（例如超过,5,秒钟），用户就会因没有耐心等待而离开。,另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。,2,、负载测试,负载测试是为了测量,Web,系统在某一负载级别上的性能，以保证,Web,系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问,Web,系统的用户数量，也可以是在线数据处理的数量。例如：,Web,应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？,Web,应用系统能否处理大量用户对同一个页面的请求？,3,、压力测试,负载测试应该安排在,Web,系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个,Web,系统能同时处理的请求数量将远远超出这个限度，所以，只有放在,Internet,上，接受负载测试，其结果才是正确可信的。,进行压力测试是指实际破坏一个,Web,应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试,Web,应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到,Web,应用系统崩溃，接着当系统重新启动时获得存取权。,压力测试的区域包括表单、登陆和其他信息传输页面等。,三、可用性测试,1,、导航测试,导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个,Web,应用系统是否易于导航：导航是否直观？,Web,系统的主要部分是否可通过主页存取？,Web,系统是否需要站点地图、搜索引擎或其他的导航帮助？,在一个页面上放太多的信息往往起到与预期相反的效果。,Web,应用系统的用户趋向于目的驱动，很快地扫描一个,Web,应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉,Web,应用系统的结构，因此，,Web,应用系统导航帮助要尽可能地准确。,导航的另一个重要方面是,Web,应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道,Web,应用系统里面是否还有内容，内容在什么地方。,Web,应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。,2,、图形测试,在,Web,应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个,Web,应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：,（,1,）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。,Web,应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。,（,2,）验证所有页面字体的风格是否一致。,（,3,）背景颜色应该与字体颜色和前景颜色相搭配。,（,4,）图片的大小和质量也是一个很重要的因素，一般采用,JPG,或,GIF,压缩。,3,、内容测试,内容测试用来检验,Web,应用系统提供信息的正确性、准确性和相关性。,信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用,Microsoft Word,的,“,拼音与语法检查,”,功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般,Web,站点中的所谓,“,相关文章列表,”,。,4,、整体界面测试,整体界面是指整个,Web,应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览,Web,应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个,Web,应用系统的设计风格是否一致？,对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般,Web,应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。,对所有的可用性测试来说，都需要有外部人员（与,Web,应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。,四、客户端兼容性测试,1,、平台测试,市场上有很多不同的操作系统类型，最常见的有,Windows,、,Unix,、,Macintosh,、,Linux,等。,Web,应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。,因此，在,Web,系统发布之前，需要在各种操作系统下对,Web,系统进行兼容性测试。,2,、浏览器测试,浏览器是,Web,客户端最核心的构件，来自不同厂商的浏览器对,Java,，、,javascript,、,ActiveX,、,plug-ins,或不同的,HTML,规格有不同的支持。例如，,ActiveX,是,Microsoft,的产品，是为,Internet Explorer,而设计的，,javascript,是,Netscape,的产品，,Java,是,Sun,的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和,Java,的设置也不一样。,测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。,五、安全性测试,Web,应用系统的安全性测试区域主要有：,（,1,）现在的,Web,应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。,（,2,）,Web,应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如,15,分钟）没有点击任何页面，是否需要重新登陆才能正常使用。,（,3,）为了保证,Web,应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。,（,4,）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。,（,5,）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。,测试工作中需要注意的问题,了解开发人员的测试心理,测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩子一样难以接受。,开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患，他本人很难发现这,类错误。,开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己的程序不具备典型性。,结论：开发人员应当测试自己的程序，这是他分内的工作。但是开发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具有说服力。,不同测试阶段的测试依据、人员、方式及内容,接口,与路径测试。,功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装,/,反安装测试,测试阶段,主要依据,测试人员、测试方式,主要测试内容,单元测试,系统设计文档,由开发小组执行白盒测试,接口测试、路径测试,集成测试,系统设计文档,需求文档,由开发小组执行白盒测试和黑盒测试,接口测试、路径测试,功能测试、性能测试,系统测试,需求文档,由独立测试小组执行黑盒测试,功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装,/,反安装测试,验收测试,需求文档,由用户执行黑盒测试,如何组织测试人员：应当视企业的人力资源而定,条件特别好的公司，可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高，可以完成单元测试、集成测试和系统测试工作，能够实现开发与测试同步进行。,条件比较好的公司，可以设置一个独立的测试小组，该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。,条件一般的公司，养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从项目外抽调一些人员，加上开发人员，临时组织系统测试小组。,条件比较差的公司，也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方的程序。如果人员实在太少了，只好让开发者测试自己的程序，有测试总比没有测试好吧！,避免开发人员与测试人员,产生矛盾,开发人员不能很好地测试自己的程序是因为做不到“无情”。但如果测试人员真的做到了“无情”却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在“对立”关系，开发人员与测试人员很容易产生矛盾，这对项目而言是一种伤害。,开发,人员的注意事项：,（,1,）不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职责。不要以为测试人员吃饱了没事干，存心找茬。,（,2,）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。,测试人员的注意事项：,（,1,）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是,Bug,。,（,2,）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷。,（,3,）不要相互指责、嘲讽、抱怨对方。,尽量不要相互讽刺对方，例如：,A,对,B,说：你唯一的特点就是无能。,B,对,A,说：你唯一的特点就是粗鲁。,还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的时候“手下留情”，这对项目也是一种伤害。,企业的测试策略,理念：,企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。,用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。,如何合理地减少测试工作量,减少冗余的测试,白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。,在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。,减少无价值的测试,无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了,100,次，那么其中,99,次就是无价值的。,如何“偷工减料”,有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要部分可以忽略或将来再测试。,“偷工减料”方法的测试优先级：,哪些功能是软件的特色？,哪些功能是用户最常用的？,如果系统可以分块卖的话，哪些功能块在销售时最昂贵？,哪些功能出错将导致用户不满或索赔？,哪些程序是最复杂、最容易出错的？,哪些程序是相对独立，应当提前测试的？,哪些程序最容易扩散错误？,哪些程序是全系统的性能瓶颈所在？,哪些程序是开发者最没有信心的？,测试何时结束？,一、基于测试用例,的规则,先构造测试用例（并请有关人员进行评审）。,在测试过程中，当测试用例的不通过率达到,20,时，则拒绝继续测试，待开发人员修正软件后再进行测试。,当功能性测试用例通过率达到,100,，非功能性测试用例通过率达到,90,时，允许正常结束测试。,该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。,二,、基于“测试期缺陷密度”的规则,把测试一个,CPU,小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间缺陷数”的关系图，如果在相邻,n,个,CPU,小时内“测试期缺陷密度”全部低于某个值,m,时，则允许正常结束测试。例如,n,大于,10,，,m,小于等于,1,。该规则比较适用于系统测试阶段。,三,、基于“运行期缺陷密度”的规则,把软件运行一个,CPU,小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间缺陷数”的关系图，如果在相邻,n,个,CPU,小时内“运行期缺陷密度”全部低于某个值,m,时，则允许正常结束测试。例如,n,大于,100,，,m,小于等于,1,。该规则比较适用于验收测试阶段，即客户试运行软件期间。,需求经常变更怎么办,需求变更可能会让项目所有成员遭殃，如何“预防变更”以及“降低变更的代价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。,需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。,测试人员不要只是自认倒霉，应当主动作些应变：,（,1,）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。,（,2,）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。,（,3,）向领导反映需求变更对测试造成的影响，为自己争取余地。,（,4,）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。,引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办？,如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反正是“锦上添花”，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。,关于测试的几个问题,问题,1,：有了“黑盒”测试为什么还要“白盒”测试？,黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。,白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。,问题,2,：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？,如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。,问题,3,：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？,要把,N,个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。,问题,4,：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试,?,不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。,问题,5,：既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？,首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢,?,所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。,不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。,问题,6,：能否将系统测试和验收测试“合二为一”？,系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。,系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。,