1、测试基础讲座,,陆浩 2009-7-31 Simlink_,内容,,什么是软件测试,所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。 使用人工或者自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别. 它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度(correctness) 、完全度(completeness)和质量(quality)的软件过程；是SQA(software quality assurance)的
2、重要子域。,,什么是软件测试工程师,软件测试工程师（Software Testing Engineer）的主要工作职责是，理解产品的功能要求，并对其进行测试，检查软件有没有错误（Bug），决定软件是否具有稳定性（Robustness），写出相应的测试规范和测试用例。简而言之，软件测试工程师在一家软件企业中担当的是“质量管理”角色，及时纠错及时更正，确保产品的正常运作。,,软件测试基础,,软件测试的目的,Glenford J.Myers曾对软件测试的目的提出过以下观点: 测试是为了发现程序中的错误而执行程序的过程； 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案； 成功的测试是发现了至
3、今为止尚未发现的错误的测试。,,软件测试的目的,然而,这种观点指出测试是以查找错误为中心,而不是为了演示软件的正确功能.但是只从字面意思理解,可能会产生误导,认为发现错误是软件测试的唯一目的,查找不出错误的测试就是没有价值的测试,实际上并非如此! 测试并不仅仅是为了找出错误.通过分析错误产生的原因和错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺陷,以便及时改进； 这种分析也能帮助测试人员设计出有针对性的测试方法,改善测试的效率和有效性； 没有发现错误的测试也是有价值的,完整的测试是评定软件质量的一种方法,,软件测试的原则一,原则1.测试用例中一个必须部分是对预期输出或结果进行定义
4、。 这条显而易见的原则在软件测试中是最常犯的错误之一。同样，这个问题也是基于人们的心理的。如果某个测试用例的预期结果事先没有得到定义，由于“所见即所想”现象的存在，某个似是而非，实际上是错误的结果可能会被解释成正确的结论。换句话说，尽管“软件测试是破坏性”的定义是合理的，但人们在潜意识中仍然渴望看到正确的结论。克服这种倾向的一种方法，就是通过事先精确定义程序的预期输出，鼓励人们对所有的输出进行仔细检查。因此，一个测试用例必须包括两个部分： 1.对程序的输入数据的描述。 2.对程序在上述输入数据下的正确输出结果的精确描述。,,软件测试的原则二,原则2.程序员应当避免测试自己编写的程序。 如果我们
5、对软件项目关注的重点发生变化，就会产生另外一个问题。当成员“建设性”地设计和编写完程序之后，很难让他突然改变视觉角度以一种“破坏性”的眼光来审查程序。 大多数程序员都不能有效地测试自己编写的程序，因为他们无法改变思维方式来尽力暴露自己程序中的错误。另外，程序员可能会下意思地避免找出错误来，担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚。 由于程序员错误地理解了疑难定义或规范，导致程序中存在错误。如果情况是这样，程序员可能会带着同样的误解来测试自己的程序。 这并不意味这着程序员测试自己的程序是不可能的。当然让其他人来测试程序会更加有效，也会更容易测试成功。 测试不等于调试，调试由程序
6、的编写人员来完成会有效得多。,,软件测试的原则三,原则3.编写软件的组织不应当测试自己编写的软件。 一个软件项目或编程组织是一个有机的机构，具有与各地程序员相似的心理问题。而且在大多数情况下，主要是根据其在给定时间特定成本范围内开发软件的能力来衡量编程组织或项目经理。其中的一个原因是，度量时间和成本目标比较容易，而定量地衡量软件的可靠性则极其困难。即便是合理规划和实施的测试过程，也可能被认为降低了完成进度和成本目标的可能性，因此，编程组织难以客观地测试自己的软件。 更经济的方法是由客观、独立的第三方来进行测试。,,软件测试的原则四,原则4.应当彻底检查每个测试的执行结果。 这个原则可能是最显而
7、易见的原则，但也同样常常被忽视。我们见过大量的例子，即便错误的症状在输出清单中可以清楚地看到，但还是没有找出那些错误来。换言之，在后续测试中发现的错误，往往是前面的测试遗漏掉的。,,软件测试的原则五,原则5.测试用例的编写不仅应当根据有效和遇到的输入情况，而且也应当根据无效和未遇到到的输入情况。 在软件测试时，有个自然的倾向，即将重点集中在有效和预期的输入情况上，而忽略了无效和未预料到的情况。此外，在软件产品中突然暴露出来的许多问题是当程序以某些新的或未预料到的方式运行时发现的。因此，针对未预料的和无效输入情况的测试用例，似乎比针对有效输入情况的那些用例更能发现问题。,,软件测试的原则六,原则
8、6.检查程序是否“未做其应该做的”仅是测试的一般，测试的另一半是检查程序是否“做了其不应该做的” 这条原则是上条原则的必然结果。必须检查程序是否有我们不希望的负作用。比如，某个工资管理程序即便可以生成正确的工资单，但是如果也为非雇员生成工资单或者它覆盖掉了人员文件的第一条记录，这样的程序仍然是不正确的程序。,,软件测试的原则七,原则7.应避免测试用例用后即弃，除非软件本身就是一个一次性的软件。 这问题在采用交互式系统来测试软件时最常见。人们通常会坐在终端前，匆忙地编写测试用例，然后将这些测试用例交由程序执行。这样做的问题在于，饱含我们宝贵投入的测试用例，在测试结束后就消失了。一旦软件需要重新测
9、试，又必须重新设计这些测试用例。情况往往是这样的，由于重新设计测试用例需要投入大量的工作，人们总是避免这样做。因此，对该程序的重新测试极少会同上次一样严格。这就意味着，如果对成功需的更改导致了程序某个先前可以执行的部分发生了故障，这个故障往往是不会被发现的。保留测试用例，当程序其他部分发生变动后重新执行，这就是我们所谓的“回归测试”。,,软件测试的原则八,原则8.计划测试工作时不应默许假定不会发现错误。 项目经理经常容易犯这个错误，这也是使用了不正确的测试定义的一个迹象也就是说，假定“测试是一个证明程序正确运行的过程”。 所谓测试，是为了发现错误而执行程序的过程。,,九,原则9.程序某部分存在
10、更多错误的可能性，与该部分已发现错误的数量成正比。 假如某个程序由两个模块、类或子程序A和B组成，模块A中已经发现了5个错误，而模块B中仅仅找到了一处错误。如果模块A所经过的测试并不是故意设计的更为严格，那么改原则告诉我们，模块A与模块B相比，存在更多错误的可能性要大。 错误总是倾向于聚集存在，而在一个具体的程序中，某些部分要比其他部分更容易存在错误，尽管没有人能够对这种现象给出很好的解释。如果一个程序的某个部分远比其他部分更容易产生错误，那么这种现象告诉我们，为了使测试获得更大的成效，最好对这些容易存在的错误的部分进行额外的测试。,,十,原则10.软件测试是一向极富创造性、极具智力挑战的工作
11、。 测试一个大型软件所徐奥的创造性很可能超过了开发该软件所需要的创造性。要充分测试一个软件以确保所有错误都不存在是不可能的。,,软件测试的内容,软件测试主要工作内容是验证(verification)和确认(validation )，下面分别给出其概念：,,软件测试的内容验证,验证(verification)是保证软件正确地实现了一些特定功能的一系列活动，即保证软件做了你所期望的事情。(Do the right thing) 确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程； 程序正确性的形式证明，即采用形式理论证明程序符号设计规约规定的过程； 评市、审查、测试、检查、审计等
12、各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。,,软件测试的内容确认,确认(validation)是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式来做了这个事件(Do it right) 静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性； 动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。,,软件测试的内容,软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期问各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程
13、序。,,软件测试的分类,从是否关心软件内部结构和具体实现的角度划分 白盒测试 黑盒测试 灰盒测试 从是否执行程序的角度 静态测试 动态测试 从软件开发的过程按阶段划分有 单元测试 集成测试 确认测试 验收测试 系统测试,,软件测试过程,测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确
14、。 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。,,软件测试模型,,V型模型,,V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。 从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。 左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。 需求分析和系统设计 验收测试 概要设计 确认测试和系统测试 详细设计 集成测试 编码 单元测试,V模型问题,V模型问题： 测试是开发之后的一个阶段。 测试的对象就是程序本
15、身。 实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。 整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度,,W模型,,W模型,W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利
16、于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。 不能支持迭代、自发性以及变更调整。,,H模型,,H模型,H模型中, 软件测试过程活动完全独立,贯穿于整个产品的
17、周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说, 只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。 H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备, 尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就
18、可以开展。 软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的 在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。,,X模型,,X模型-探索性测试,X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试
19、的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。,,前置模型,,前置模型,前置测试模型则体现了开发与测试的结合,要求对每一个交付内容进行测试。前置测试模型是一个将测试和开发紧密结合的模型，此模型将开发和测试的生命周期整合在一起，随项目开发生命周期从开始到结束每个关键行为。,,前置模型,前置测试模型体现了以下的要点：
20、开发和测试相结合 对每一个交付内容进行测试 在设计阶段进行计划和测试设计 测试和开发结合在一起 让验收测试和技术测试保持相互独立 反复交替的开发和测试 发现内在的价值 前置测试定义了如何在编码之前对程序进行测试设计，开发人员一旦体会到其中的价值，就会对其表现出特别的欣赏。前置方法不仅能节省时间，而且可以减少那些令他们十分厌恶的重复工作。,,测试模型比较,测试模型使用软件在实际工作中应灵活地运用各种模型的优点 V模型: 强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试 W模型: 补充了V模型中忽略的内容
21、，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明 H模型: 强调测试是独立的，只要测试准备完成，就可以执行测试,,软件测试过程模型选取策略,前面介绍的测试过程模型中，V模型强调了在整个项目开发中需要经历的不同的测试级别，但忽视了测试的对象不应该仅仅是程序。而W模型在这一点上进行了补充，明确指出应该对需求、设计进行测试。但是V模型和W模型都没有将一个完整的测试过程抽象出来，成为一个独立的流程，这并不适合当前软件开发中广泛应用的迭代模型。H模型则明确指出测试的独立性，也就是说只要测试条件成熟了，就可以开展测试。 在实际测试工作中我们应该尽可能地去
22、应用各模型中对项目有实用价值的方面，不能强行的为使用模型而使用模型。在测试实践中，我们采用的方法是：以W模型作为框架，及早的、全面的开展测试。同时灵活运用H模型独立测试的思想，在达到恰当的就绪点时就应该开展独立的测试工作，同时将测试工作进行迭代，最终保证完成测试目标。,,测试过程管理理念,生命周期模型为我们提供了软件测试的流程和方法，为测试过程管理提供了依据。但实际的测试工作是复杂而烦琐的，可能不会有哪种模型完全适用于某项测试工作。所以，我们应该从不同的模型中抽象出符合实际现状的测试过程管理理念，依据这些理念来策划测试过程，以不变应万变。当然测试管理牵涉的范围非常的广泛，包括过程定义、人力资源
23、管理、风险管理等等，本节仅介绍几条从过程模型中提炼出来的，对实际测试有指导意义的管理理念。,,测试过程管理理念,尽早测试 “尽早测试”并非盲目的提前测试活动，测试活动开展的前提是达到必须的测试就绪点。 全面测试 “全面测试”有助于全方位把握软件质量，尽最大可能的排除造成软件质量问题的因素，从而保证软件满足质量需求。 全过程测试 “全过程测试”有助于及时应对项目变化，降低测试风险。同时对测试过程的度量与分析也有助于把握测试过程，调整测试策略，便于测试过程的改进。 独立的、迭代的测试 “独立的、迭代的测试”着重强调了测试的就绪点，也就是说，只要测试条件成熟，测试准备活动完成，测试的执行活动就可以开
24、展。,,软件测试职业发展前景,初级测试工程师：初级职位，开发测试脚本，执行测试 测试工程师 / 程序分析员：编写自动测试脚本程序 高级测试工程师 / 程序分析员：确定测试过程并指导初级测试工程师 测试组负责人：监管 1-3 人工作，负责规模 / 成本估算 测试 / 编程负责人：监管 4-8 人，安排和领导任务完成，提出技术方法 测试 / 质量保证 / 项目经理：负责 8 名以上人员的一个或多个项目，负责全生存期 业务 / 产品经理：负责多个项目的人员管理，负责项目方向和业务盈亏,,测试工程师的发展,注重自己在团队中的价值发挥（关注自己是否是个对团队有用的人，而不是做完委派的工作任务） 注重在实战中积累（不是做过就完事，强烈追求下次做的更好） 关注行业发展（有一些同行好友，经常切磋交流，而不是井底之蛙） 关注自己的能力发展（有相对清晰的自我学习发展目标并定计划挤时间学习）。,,测试技术网站,http:/ http:/ 讨论问题,,谢谢！,
