1、测试基础,内容提要,软件测试概论测试方法运用、技巧与常见误区,内容提要,软件测试概论测试方法运用、技巧与常见误区,软件测试概论,测试的定义 测试的地位 测试的目标 测试的基本原则 软件测试技术 软件测试策略 软件质量要求,测试的定义,测试是指由给定产品、过程或按照规定的规程服务的一个或多个特性的测定组成的技术操作。,测试的定义2,测试相关术语： 测试计划：为测试和评价某一系统应建立详细的需求、准则、一般方法、职责和一般大纲的计划。 测试方法：规定技术规程以执行某一测试。 测试数据：用于检验问题的数据。 测试用例：测试者使用的文档化的细则，其规定如何对某项功能或功能组合进行测试。,测试的定义3,
2、测试用例通常包含下列内容的详细信息： 测试目标； 需测试的功能； 测试环境和其他条件（配置细节和准备工作）； 测试数据； 过程； 系统的预期行为。,测试的地位,测试是软件生存周期中一个独立的，关键的阶段，是保证软件质量的重要手段。测试代表了规约、设计和编码的最终检查，是软件质量保证的最后一个环节。,测试的目标,测试的目标是设计出最可能发现最多数量错误，并耗费最少时间和最小代价的测试。 （测试无法说明错误不存在，它只能表示错误已经出现。）,测试的基本原则1,所有的测试都应追溯到用户需求。我们的产品最终是为了给用户使用，测试人员应该把自己看做是用户的代表，从 用户的角度来测试产品，而对用户来说，最
3、严重的错误是那些导致程序不能够满 足他们的需求的错误。对于我们测试的产品来说，测试的依据是：有标准协议的依据标准协议，无标准协议的以用户需求（用户感受）为准。,测试的基本原则2,所有的测试活动都应该是有计划的。测试不仅是应该有计划的，而且要在测试工作真正开始的较长时间就应该进行计划。测试计划可以在需求一确定，需求模型一完成就开始，总之要在代码产生之前就 应该开始。测试计划包括测试设计，产品的质量是设计出来的，同样，测试的质量也是设计出来的。测试不但要有计划，还需有详细计划，也就是我们常说的测试规程，或者叫做测试用例设计。要坚决反对无计划的、无目的的、随意的测试活动，这样的测试或许能发现一些错误
4、，但决不是一种有效的工作方法。,测试的基本原则3,软件测试的Pareto原则。Pareto是一种理论，也就是“二八原理”，最初用于研究社会问题，后来广泛运用于各个领域，同样也适用于测试领域。测试中的Pareto原则是指：80的故障起源于程序模块中的20。理解了Pareto原则有助于我们在测试过程中抓住重点，只有抓住了系统的薄弱环节，然后在此深入下去，测试才有成效。,测试的基本原则4,测试应从“小规模”开始，然后转向“大规模”。最初的测试应该把焦点放在单个程序模上，然后是集成测试，最后转向整个系统的测试,测试的基本原则5,穷举测试是不可能的，然而，充分覆盖程序逻辑，确保程序设计中使用的所有条件是
5、有可能的。我们的产品运用于不同的环境和条件下，要做到穷举是不可能的，但是我们应该提高测试的覆盖率，保证程序的每一个逻辑判断分支可以测试到。,测试的基本原则6,为了达到最佳效果，应该由独立的第三方来构造测试。我们目前正是这么做的。,软件测试技术,白盒测试 黑盒测试 其他测试技术,白盒测试,白盒测试注重于程序控制结构。 基本路径测试 控制结构测试条件测试目的：测试程序条件的错误和程序的其他错误条件测试策略：分支测试、域测试 数据流测试循环测试,黑盒测试1,黑盒测试发现功能需求错误，而不考虑程序的内部工作。黑盒测试试图发现以下类型错误：功能不对或遗漏界面错误数据结构或外部数据库访问错误性能错误初始化
6、和终止错误,黑盒测试2,黑盒测试通常用于回答以下问题： 如何测试功能的有效性？ 何种类型的输入会产生好的测试用例？ 系统是否对特定的输入值尤其敏感？ 如何分隔数据类的边界？ 系统能够承受何种数据率和数据量？（处理能力、容量） 特定类型的数据组合会对系统产生何种影响？,黑盒测试3,等价划分法定义：等价划分法是将程序的输入域划分为数据类，以便导出测试用例。试图定义一个测试用例以发现各类错误，从而减少必须开发的测试用例。理解：用最精简的、最有代表性的输入设计测试用例，达到最大的覆盖率。应用：被测对象具有对称性、传递性、自反性的关系连接，即存在等价类。典型地，输入条件为一个特定的值、一个数值域、一组相
7、关值或一个布尔条件。指南：如果输入条件代表一个范围，可以定义一个有效等价类和两个无效等价类。 如果输入条件需要特定的值，可以定义一个有效等价类和两个无效等价类。 如果输入条件代表集合的某个元素，可以定义一个有效等价类和一个无效等价类。如果输入条件是布尔式，可以定义一个有效等价类和一个无效等价类。,黑盒测试4,边界值分析（BVAboundary value analysis）边界值分析是一种补充等价划分的测试用例设计技术。指南：1.如果输入条件代表一组值，测试用例应当执行其中的最大值和最小值，还应当测试略大于最小值和略小于最大值的值。例子1：数据配置中有一个局容量配置，列举了一些参数的最大值，如
8、：邻接局最大数255，交换局网络类型最大数8，GT翻译表容量4096，7号路由最大数512， 等等，是否测试了所有的边界值呢？例子2：一个SMP设计容量为20万，那么就要测试最大容量时系统的处理和相应的指标，如CPU，MEM占用情况等,黑盒测试5,2.指南1也适用于输出条件。3.如果程序数据结构有预定义的边界（如数组有100项），要测试其边界的数据项。常见错误：数组越界，循环变量错导致死循环典型例子1：咸宁HLR7月份出现业务处理机反复重起。原因：循环 变量定义错，原定义BYTE，结果取值超过255。典型例子2：在受理台端执行批量查询，有的时候正常，有的时候出现很多无效的用户号码(譬如全0或乱
9、码)，问题出在DBIO的代码中， 从数据库中取数据时错误地赋值导致数组越界，覆盖调了其后内存空间的数据.,黑盒测试和白盒测试的比较1,白盒测试：使用白盒测试技术可以保证一个模块中的所有独立路径被执行一遍，特别是检验逻辑错误、不正确的假设条件（设计错误）下程序的处理。黑盒测试：通常不考虑控制结构，而是注意信息域。黑盒测试不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。,黑盒测试和白盒测试的比较2,推荐方法：白盒测试与黑盒测试的结合。运用白盒测试技术分析程序控制结构和逻辑关系，（对于协议程序来说，通常理解协议流程就可以了，但我们现有的协议程序中，加入了大量的非协议内容，所以白盒技术还
10、是需要使用的。）在运用白盒技术的基础上，列出测试的项目（分支覆盖、异常情况），再运用黑盒技术设计测试分项目（等价划分、边界值）。,其他软件技术,黑盒测试和白盒测试是传统的测试方法，可以用于所有的环境、体系结构和应用程序，但随着软件技术的复杂，有时还需要运用许多专门的测试技术。 面向对象测试技术 （嵌入式）实时操作系统测试技术 C/S体系结构测试技术 GUI测试技术 帮助（文档）测试技术,软件测试策略,制定测试策略在设计测试方案，制定测试策略之前，以下问题必须考虑：1.明确测试目标，并用可度量的术语来描述。可度量的术语包括：测试有效性、测试覆盖率、故障出现的平均时间、允许剩余的缺陷，每次回归测试
11、的测试时间等。2.分析软件应用的实际环境以及交互情况。在测试前，一定要有针对性，详细分析合同配置容量规划、组网模式、开通业务等。有的放矢才有成效。,软件测试策略,制定测试策略在设计测试方案，制定测试策略之前，以下问题必须考虑： 1. 明确测试目标，并用可度量的术语来描述。可度量的术语包括：测试有效性、测试覆盖率、故障出现的平均时间、允许剩 余的缺陷，每次回归测试的测试时间等。 2. 分析软件应用的实际环境以及交互情况。在测试前，一定要有针对性，详细分析合同配置容量规划、组网模式、开通业务等。有的放矢才有成效。,软件测试策略,3. 建立一个强调“快速循环测试”的测试计划。一定要考虑回归测试。 4
12、. 使用有效的正式技术复审来评估测试策略和测试用例本身。对测试方案和测试规程进行评审，评审输入必须有测试依据（协议或研制规范、用户资料分析等）和相应的测试方案/规程。 5. 总结与分析。在测试过程中应收集相关数据，进行统计与分析，作为软件测试的统计过程控制方法的一部分。,单元测试1,单元测试包括： 对模块接口的测试 对局部数据结构的检查 对边界条件的测试 对独立路径的（基本路径）测试 对错误处理路径测试,单元测试2,单元测试的最主要任务是路径测试，即采用分支覆盖等方法保证每条语句被执行一遍。而单元测试是针对模块的，为了保证这个模块在孤立的情况下能够执行，必须为该模块提供一个“驱动器”（用来模拟
13、输入、输出）和/或“稳定桩”（用来模拟被调用的模块），开发这些模拟程序往往开销是很大的，通常只做一些相对简单的模拟（针对比较简单、独立的模块），而复杂的模拟由于开销太大，这部分的覆盖执行测试被放到后面的集成测试中去。,集成测试,集成测试是通过测试发现和接口有关的问题来构造程序结构的系统化技术。集成测试就是接口测试。通常开发部的联调就是一种集成测试。当集成测试时，测试人员应当能够识别系统的关键模块，对关键模块要尽早测试，并且要充分测试。对于协议软件来说，标准的接口都有协议要求，那么对接口的测试就表现在协议顺从上：是否正确理解了协议并按照协议编程。很多情况下，错误产生于对协议的理解不一致或顺从协议
14、不严格。 集成测试还应注重于内部接口的测试，如相关模块间接口、前后台接口。对于开发人员来说，和外部接口一样，明确规范内部接口间协议，同步修改是避免接口错误的最有效方法。,确认测试,定义：确认测试即确认软件是否可以按照用户合理的期望的方式来工作。 谁或者什么来作为用户合理的期望的裁定者？测试依据？对于有协议标准的，以协议标准为裁定者；对于无协议标准的，以研制规范中的软件需求规约为裁定。（软件需求规约是在软件工程早期阶段对用户需求进行收集分析获得的，针对我们目前的状况，需求分析较差，那么测试人员作为软件的第一用户，站在用户的角度考虑需求；用服人员作为和用户最接近的部分，充分考虑用服部门的意见。 确
15、认测试主要用来发现程序实现与用户需求之间的偏差。,系统测试1,恢复测试系统的容错性测试，系统必须在一定的时间内从错误中恢复（包括自动恢复和手工恢复）过来。 安全测试用来验证集成在系统内的保护机制是否能够在实际保护系统中不受到非法侵入。（要把系统设计为想要攻破系统而付出的代价大于攻破系统之后得到的信息的价值）我们的系统安全性不是重点，但也存在一些保密措施，如VLR容量表配置、安全管理中的变量控制。,系统测试2,压力测试压力测试是在一种需要反常数量、频率或资源的方式下执行系统。“看看能将系统折腾到什么程度而不会出错？”例子：模块间通讯流量测试时，将每秒发送包数不断增大。性能测试性能测试用于测试软件
16、在集成系统中的运行性能。性能测试常常和压力测试一起进行，在一种苛刻的环境中衡量资源的使用。通过对系统的检测，可以发现导致效率降低和系统故障的情况。对于实时系统和嵌入系统来说，满足性能需求尤其重要。更高质量的软件需要更系统化的测试方法。我们需要的是贯穿整个测试过程的一个整体策略，而且在方法学上应当象基于分析、设计和编码的系统化软件开发一样进行周密的计划。,内容提要,软件测试概论测试方法运用、技巧与常见误区,测试方法运用、运用和常见误区,常见故障分类 运用白盒测试技术 运用黑盒测试技术 系统测试阶段的白盒技术运用 关于定位问题的方法 测试中的常见误区,常见故障分类,通过对测试故障的分析，常见程序故
17、障原因如下： 越界，包括数组下标越界，内存拷贝越界等等 变量定义类型不匹配，变量取值超出定义类型范围，造成上溢/下溢。 逻辑判断错误 函数调用错误，调用函数未处理返回值失败情况 指针、变量没有初始化 申请的内存不释放,常见故障分类,异常处理错误包括：非法输入不防范临界点、边界值处理出错过负荷未保护对误操作的保护 可维护性错误，不能提供有效的告警、日志等记录供分析定位错误。,常见故障分类,界面错误包括：提示信息错窗体标题错窗体或对话框显示不完整字体不符合要求按钮的大小、颜色快捷方式不起作用按钮功能无效下拉菜单或下拉框问题操作程序繁杂，不符合用户习惯。,运用白盒测试技术,白盒测试技术主要运用于单元
18、/集成测试阶段。使用白盒测试技术可发现上面所列的很多问题。使用白盒测试时，可针对以下问题进行测试。,运用黑盒测试技术1,黑盒测试强调程序实现的功能和用户需求的满足，而不注重程序内部实现，因此运用黑盒测试时，了解系统的所有实现功能和用户需求是前提。注意：黑盒测试时，了解系统不能实现的功能和了解能够实现的一样重要，因为问题往往就发生在当功能不能实现时，系统出现异常甚至崩溃。如我们现在做的流量控制和过负荷控制就是对系统在不能实现更大流量和负荷时的一种保护。,运用黑盒测试技术2,在黑盒测试时，应该考虑以下问题： 1.用户需要的功能是否可以实现？ 2.用户使用这些功能的环境和条件？ 另外：所有的异常都是
19、可能的，多想想一些“不可能”的异常吧。,运用黑盒测试技术3,黑盒测试中的常用方法：逆向思维与边界值分析所谓逆向思维就是凡事都从反面想一想，如果条件成立，程序是这样处理的，如果条件不成立呢？MSC和BSC之间局间信令要配成“BSC地面电路CCS7-SCCP”，如果不配成这个，选择其它选项呢？前后台链路正常时，处理正常，如果断链呢？正常情况下，消息交互时有应答消息，如果因为某种原因，应答消息丢失呢？程序启动时可能需要读一个文件，假如文件不存在呢？ 总之，要养成逆向思维的习惯，任何条件都可以假设不成立。（不要去过多考虑现实情况中有没有这种逆向条件的可能）。,运用黑盒测试技术4,边界值分析是指对条件的
20、极端情况的分析测试，如条件是一段数值，则对两端的极点的分析。需要指出的是，边界值分析并不仅仅限于一些数值条件，经常还包括一些隐含条件。,运用黑盒测试技术5,推荐技巧：经常看看别人填写的故障单，对自己会很有帮助。根据Pareto原理，80的故障源于20的原因，所以经常看看别人报告的故障（包括用服报告的故障），然后举一反三，这些根源导致的故障很可能在自己所测的模块里也存在。,运用黑盒测试技术6,不是技巧的技巧：看看你所测的模块，它的开发者是谁？这个技巧看上去有些势利，但是事实就是，没有经验的新手，出错的可能性就是大，包括一些很低级的错误。所以对于新手做的东西，一定要采取不放心的心理测，甚至是一些曾
21、经改过的故障也有可能会重现。（当然，这并不是说有经验的开发人员不会出错，他们只是错误少一些，往往这些错误也隐藏的深一些，所以基本上不要期望在他们那里发现一些肤浅的错误。）,关于定位问题的方法,有时在实验室发现可疑现象，但无从下手，这里介绍一种非常有效的方法：排除法。很多问题不能从正面去定位，必须排除掉一切可能排除的原因，缩小问题范围。在排除时，常用的方法是用已知正确的部分替换怀疑部分。举个很小的例子，有时在测试时发现放音有问题，那么有多种可能，一是硬件故障，音板有问题，二是装载的音不正确，版本错误，也有可能是数据配置错误，当然最后，有可能是脚本错误或程序处理错误。在这种情况下，首先是检查配置，
22、有没有配音板？是否正确？然后检查装载的音文件是否正确？再检查音板有没有问题？换一个音子单元呢？或者换一块音板呢？以上原因都排除，才将问题的焦点集中到程序上。总之，排除法非常有效，经常使用排除法是一种很好的定位问题的方式。,测试中的常见误区,测试中经常会陷于一些误区，这些不正确的心理和做法，往往导致问题从眼前溜过或测试工作做不到点子上。,测试中的常见误区1,误区1：以开发人员的设计文档为测试依据。这是比较严重的一种现象，我们的新员工在接受培训时，往往从设计文档开始熟悉产品，久而久之，这些文档就变成了“依据”和“标准”。当然，大多数情况下，这些设计文档是没有问题的，但是对于测试人员来说，作为独立的
23、第三方测试人员，测试依据应该是标准协议和用户需求分析。系统部、开发部提供的文档仅仅是作为一种必不可少的熟悉产品的渠道，而不是测试的依据。如果以设计文档为测试依据，那么当设计人员对协议和用户需求理解有偏差时，我们的测试也就有偏差了。测试应该做确认工作（是否实现了正确的产品），而不仅仅是验证工作（是否正确地实现了产品）。,测试中的常见误区1,例子：容灾功能中按照开发的设计方案同步模块的处理速度为20-30次/秒，但是实际上如果测试机房使用大话务登记，200毫秒8次，实际上就是每秒40次（HLRE更多），该登记产生的消息在同步模块就很难处理，如果这个时候在主用局受理台放号，什么时间会同步到容灾局就很
24、难说了。如果测试按照设计文档这样处理是没有问题的，但是实际上不能满足现网络的性能要求，因此需要仅仅依据设计文档是不能发现这个问题的。,测试中的常见误区2,误区2：测试目标不明确或不符合用户需求，测试的优先级不清晰有时候我们测试忙的要死，抓了一堆BUG，自我感觉很有成就感，开发人员改起来也是忙的要命，但是版本到投放使用时，却会出现一些不该发生的问题引起了用户的投诉。为什么？（当然测试是无法保证问题不存在的，但是应该保证将关键的问题降至最少）。因为虽然我们在测试时发现了很多错误，但也许相当部分并不是用户关心的问题。当然，严格来说，不管是什么BUG，是大虫子还是小虫子，都是应该揪出来的。但是当测试时
25、间不充分时，千万注意：将测试时间留在用户关心的关键业务上。,测试中的常见误区2,所以说测试一定要测在点子上，特别是当测试时间紧迫时。也就是说，测试一定要目标明确，并且符合用户需求！我希望每一位测试人员在开始测试之前，都能够问自己这两个问题：1.我为什么要测这个新版本？为了满足用户哪些要求？如果新版本仅仅是改错，那么很简单，是因为要修正错误。如果是添加了新功能，要明确：为什么要加这些功能？什么地方的用户提出的？用户出于何种目的要求实现这些功能？,测试中的常见误区2,2.这个版本的测试重点是什么？是否真正满足了用户的需求？无论负责哪一个模块的测试，都应该有一个重点。当测试时间不够充分时，要保证对这
26、些重点关键的部分进行充分测试。（对于软件来说，测试永远都没有结束的时间，对于测试人员来说，测试结束时间就是市场需要，时间不够的时候）。另外，还要考虑，实现的功能是否真正满足了用户的要求。测试目标的不明确，往往会导致工作没有重心，工作效率的降低。举几个例子。,测试中的常见误区2,例子1：OMC版本每次都能发现很多故障，而这些故障用户不一定关心，用户真正关心的，我们反而没测。 例子2：302版本刚刚开始测的时候，我们的测试人员仍然按照212的测试规程去测版本，而没有去了解为什么推出302版本？302版本与212版本的本质区别？结果导致一些很关键的错误很晚才测出。,测试中的常见误区2,例子3：测试数
27、据库割接的时候，测试内容为每个表、每个数据库字段的正确性，但是由于时间和工具上的原因，并不能做到覆盖每个用户，这个时候就要先保证每个用户重要字段的正确性，例如CFIND这个字段，是一个组合值，关系到多个补充业务，当时我们把测试重点放在比较某个用户每个补充业务的字段上，而忽略了每个用户这个字段的正确性，导致在现场很多用户的补充业务虽然本身字段正确，但是业务不能实现的问题。 这些例子再次说明：要从用户的角度出发去明确测试目标，按照测试用户关心的程度为优先级来安排测试，有利于版本快速稳定，更好地满足用户要求。,测试中的常见误区3,误区3：盲目相信开发人员的解释测试人员在发现故障现象时，听从开发人员的
28、解释而不再仔细分析研究。当然，很多时候，开发人员的解释是对的，测试人员报告的故障现象属于误操作、误配置等人为导致。但是，当听完开发人员的解释后，应该再仔细分析考虑一下，就算是错误配置导致，是否应该有合理的避免方式，特别是没有协议标准的功能，一定要慎重考虑。下面举几个例子说明这个问题：,测试中的常见误区3,例子1： 测试部很早之前曾就欠费用户不能拨打免费号码填过一张故障单。但当时相关人员解释为：欠费限制我们是采用ODB方式实现的，而协议规定ODB限制的用户就是不能拨打免费号码。此故障作为无效故障返回。但是今年就有吉林用户提出欠费用户要求可以拨打充值查询号码。此问题的关键是：虽然协议规定ODB用户
29、不能拨打免费号码，但协议没有要求欠费限制一定要以ODB方式实现。所以当初开发人员的解释是有漏洞的。,测试中的常见误区3,例子2：深大割接测试时，测试部已经发现数据割接后用户位置信息中的短消息地址类型不正确，但是开发人员解释说这个字段我们这边不用，所以测试人员没有再追究，但是实际上在现场正好出现这个问题。,测试中的常见误区3,例子3：在测试2.0版本HLR批量鉴权与放号功能时，速度特别慢，好几秒才放一个号，并且时常中断。当时开发人员的解释是服务器配置太差，在外面开局都是高档配置，不会有这种情况。并且举例说明已在开局现场放过1万个号，没问题。当时测试人员找来了机房最好配置的机器，并且将数据库建在磁
30、盘阵列上，但是放号速度仍然没有任何改观。经过测试人员和开发人员的共同努力，终于发现还是程序的问题，经过对执行脚本和触发器的优化，批量放号速度提高了好几十倍，即使在低档机器上也能顺利进行。,测试中的常见误区4,误区4：没有恒心，轻易放弃测试一定需要恒心和耐心。机房环境复杂，有时候问题稍纵即逝，或者诸多现象掺杂在一起，问题越弄越多。特别是有时环境不争气，怎么也折腾不好。这种情况下千万不能放弃，理清思路，扩大视野，群策群力，一步步检查，往往柳暗花明又一村。,测试中的常见误区12,例子1：支持T1功能测试时当时涉及到多个环境，当时出现的问题是选择64k，链路正确，一旦选择56k链路怎么都调不通的现象，
31、最初怀疑后台配置中存到数据库的数据不正确，排除后怀疑同步到前台的数据不正确，但是通过探针发现这些数据都是正确的，检查数据、检查版本、检查硬件连线，种种方法都尝试过，折腾了好几天，还是一筹莫展。但是我们的测试人员还是不放弃，最后发现原因是3G平台时隙分配器之间对应关系有误，产生了时隙和通道的偏移，导致链路不能进入服务。,测试中的常见误区13,例子2： 在测试排队机部分的业务时，因为涉及到的东西很多，而且经常会有一些特殊的要求，排队机部分又不是我们开发的，涉及到一些深层次的问题经常会难以解决（有时请求IN产品现场技术支援还会有一定困难），此时，就得考验我们的恒心和解决问题的能力。在测试上海中英文人工台时，业务加载后无论怎样折腾都没法正常放音，将前台数据删除后重传，重启前台，重装CTI SERVER，业务卸载再加载，换音板，查数据配置等等方法，均没有用，经过一天多的时间也没有找到问题之根结。最后考虑到排队机部分除了后台服务器没有重新安装，其他部分均彻底重新装过，虽然后台服务器部分的程序与业务基本没有相关性，而且在加载之前均正常，还是决定重新安装后台服务器，结果重新安装后，配置数据没有任何变化，问题消失了！虽然问题之真正根源没有找到，但至少将测试中遇到的环境问题解决掉，能够将测试继续下去，不会影响到产品正常的流程。,
