hp惠普软件测试讲义(ppt)

1、Software Product Testing Framework-Zeng,qi(AMS-ATS)1Software Product Testing ActivityAuthor: Department: AMS-ATS软件产品的定义书写或其他手段记录信息、概念、事物或程序组成的产品 平台软件：平台软件是一种以业务为导向，可快速构建应用软件的平台，典型如操作系统类软件及其他可供二次开发的软件。应用软件：为实现特定应用功能或目的而开发的应用程序,应用程序可运行于平台软件之上。软件测试的定义 软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作结果的过程,所谓控制条件应包括正常条件与

2、非正常条件 1.程序测试是为了发现错误而执行程序的过程 G.J.Myers 2.评价一个程序和系统的特性或能力，并确定它是否达到预期的结果。软件测试就是以此为目的的任何行为 -Dr. Bill Hetzel 3.就是在既定的状况条件下，运行一个系统或组建，观察记录结果，并对其某些方面进行评价的过程 -IEEE/ANSI标准 1990.软件测试的目的 软件测试的目的是为了保证软件产品的最终质量，在软件开发的过程中，对软件产品进行 质量控制。软件测试应由独立的评测部门负责，严格按照软件测试流程，制定测试计划、测试方案、测试规范，实施测试，对测试记录进行分析，并根据回归测试情况撰写测试报告。 测试是

3、为了证明程序有错，而不能保证程序没有错误 Software Product Testing Framework-Zeng,qi(AMS-ATS)5软件测试方法依照测试手法分为白盒测试 (White-box or Glass-box)黑盒测试 (Black-box)灰盒测试 (Gray-box)有效用例 (Valid-Case)边界条件 (Boundary-Case)等价类 (Equivalent-Classes)依照测试目的分为功能测试性能测试依照测试阶段分为UATRegressionUnit .白盒测试 白箱测试或白盒测试(White-box testing 或glass-box testi

4、ng)是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。 黑盒测试 黑箱测试或黑盒测试(Black-box testing)是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件或某种软件功能的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。通常测试人员在进行测试时不仅使用肯定出正确结果的输入数据，而且还会使用有挑战性的输入数据以及可能结果会出错的输入数据以便了解软件怎样处理各种类型的数据。灰盒测试 灰箱测试或灰盒

5、测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能。有效用例 有效用例(Valid case)或者叫合法输入用例:是那些已知软件程序能正确地处理的测试用例。一般是指软件输入的测试用例。比如说，在 Microsoft Excel 中，用键盘输入“=1+1”, 看到的结果是“2”。

6、这里输入的有效用例是“=1+1”。无效用例(Invalid case有人叫不合法输入用例)或者出错用例(error case):是那些事先就知道软件程序不支持处理的测试用例。比如说在 Microsoft Excel 中，用键盘输入“=a+1”, 看到的结果是“#NAME?”。这里输入的“=a+1”既是无效用例同时也是出错用例。 边界条件 边界条件(Boundary Cases):环绕边界值的测试。通常意味着最大值，最小值或者所设计软件能够处理的最长的字符串等等。比如说某软件字体的字号支持范围是:从8到72。那么边界测试用例应该包括:小于8, 等于8, 等于72 和大于72。有效性 等价类(eq

7、uivalent classes):等价类测试用例指的是如果有很多测试用例执行再多也不会找到新的缺陷。因为虽然输入和输出结果有所不同，但是它们都通过同样的软件的源代码路径。通常只要一个源代码程序的路径是用于处理一定数值范围内的所有数值，那么除了边界值以外，在边界值范围以内的所有数值一般都属于等价类。因为如果软件程序能正确处理一个值，也就意味着该程序能正确处理在这个范围内的除了边界值以外的其他任何有效输入值。我们来用以上软件字体的字号来举例说明。软件支持的字号范围是:从8到72。那么8和72之间的所有支持的字号都可以被认为是等价类的测试用例。再比如:测试超链接时两个用例http:/ 和 http

8、:/ 也是等价类的测试用例。软件测试方法没有完全标准化和统一化 Software Product Testing Framework-Zeng,qi(AMS-ATS)13Testing is to establish confidence that a program does what it is supposed to do. http:/ Activity In ATS Software Product Testing Framework-Zeng,qi(AMS-ATS)14Traditional Testing Model in SDLCValidationVerificationLL

9、DHLDSystem testplanningIntegration testplanningUnit test planningUnit testingIntegrationTestingSystem TestingCodingDeliveryproductiondeploymentMaintenanceand enhancementURSUATplanningSRS User AcceptanceTestingWhy not make testing an independent lifecycle?Software Product Testing Framework-Zeng,qi(AM

10、S-ATS)15Comprehensive Capability ManagmentToolProcessPeopleSoftware Product Testing Framework-Zeng,qi(AMS-ATS)16ATS Automated Testing life cycle ManagmentToolProcessPeopleSoftware Product Testing Framework-Zeng,qi(AMS-ATS)17Operating Model (Integrated)CustomerRequirementsPrioritizationAcceptance Cri

11、teriaSchedulesReviews & ApprovalsDevelopment TeamDev &Testing SkillsDelivery MgmtTools & FrameworksDomain KnowledgeProcess EnablersSoftware Requirement AnalysisDesign (HLD & LLD etc.,)Development & Unit TestingIntegration & Defect FixingTest Requirement AnalysisTest Plan, Env

12、., and Automation)Test Design, Development & Base liningTest Execution, Defect Reporting & TrackingChange Mgmt, Configuration Mgmt, Risk Mgmt, Defect Mgmt and Release Mgmt etc Project Life CycleATS PracticeSoftware Product Testing Framework-Zeng,qi(AMS-ATS)18Operating Model (Dedicated)Custom

13、erRequirements & DocsPrioritizationAcceptance CriteriaSchedulesReviews & ApprovalsTest Requirement AnalysisTest Plan, Env., and Automation)Test Design, Development & Base liningTest Execution, Defect Reporting & TrackingChange Mgmt, Configuration Mgmt, Risk Mgmt, Defect Mgmt and Rele

14、ase Mgmt etc DevelopmentTeamIndependent Testing Life CycleATS PracticeTesting SkillsDelivery MgmtTools & FrameworksDomain KnowledgeProcess EnablersSoftware Product Testing Framework-Zeng,qi(AMS-ATS)19Operating Model (Managed)Quality of DeliverablesOptimizing productivityOptimizing resource utili

15、zation Optimizing turnaround timeTestRequirementsATS ProgramManagement Group Project plan (ITLC) Resource requirementsStrategyOperating model ScheduleProcess DeliverablesResource Loading PlanRelease planConfig planAssignmentsTest Bed PreparationTest Design/ scriptingTest ExecutionDefect ManagementAU

16、T 1AUT 2AUT 3AUT AUT nTest Lead 1Test Lead 2Test Lead 3Test Lead .Test Lead nSOP and Test Tools CMM/ISO based HP IQMS Processesand ProceduresBest Practices of ATS PracticeProven Methodologies & Customized Test StrategiesReview & ApprovalsPrioritizationSchedulesAcceptance CriteriaRequirements

17、 & DocsCustomerSoftware Product Testing Framework-Zeng,qi(AMS-ATS)20Practice In Software Product TestingSoftware Product Testing Framework-Zeng,qi(AMS-ATS)21软件产品开发模型Software Product Testing Framework-Zeng,qi(AMS-ATS)22软件产品开发Software Product Testing Framework-Zeng,qi(AMS-ATS)23软件产品的特点1.周期延续性:软件产品

18、开发周期长 测试切入点早2.功能稳定性:软件产品发布后对稳定性要求更高 一旦发生招回成本无法估量3.功能扩展性:便捷的接口 便于功能拓展和二次开发4.环境兼容性:对使用环境的软硬件要求较好的兼容性5.需求市场+主观导向且相对稳定6.客户群体多样行 面向行业多样性:产品的易用性和广泛适用性7.安全性:加密 知识产权 防破解防盗版8.主动Software Product Testing Framework-Zeng,qi(AMS-ATS)24软件项目的特点（相较于软件产品）周期延续性:项目开发时间短 测试切入点晚功能扩展性:通常无须考虑功能拓展和二次开发集成特性:多种软件产品的集成 在已知环境下配

19、置安装需求客户导向变更大且频繁客户群体固定或已知被动Software Product Testing Framework-Zeng,qi(AMS-ATS)25软件产品测试的特点1.通常为黑盒 遵循使用说明2.站在市场、超用户超行业的角度 偏重用户的视角3.各种软硬件环境下的兼容性测试4.稳定性测试5.需求变更少导致测试用例可重用性高 Software Product Testing Framework-Zeng,qi(AMS-ATS)26软件产品测试的方法两类经典的测试方法验证软件是工作的 目前的主流和行业标准 第一类测试可以简单抽象地描述为这样的过程：在设计规定的环境下运行软件的功能,将其结

20、果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug,这一过程的终极目标是将软件的所有功能在所有设计规定的环境全部运行. 测试软件产品前期验证软件是不工作的一个成功的测试必须是发现Bug的测试，不然就没有价值。如同一个病人（假定此人确有病），到医院做一项医疗检查，结果各项指标都正常，那说明该项医疗检查对于诊断该病人的病情是没有价值的，是失败的,没有没有bug的程序.通过BUG数量来衡量测试人员的工作量. 测试软件产品后期Software Product Testing Framework-Zeng,qi(AMS-ATS)27软件产品测试的方法两类经典的测试方法的优劣比较虽然

21、软件测试总的目的是为了软件产品的质量，这两类测试方法在具体目标、或指导思想上截然相反。由此也决定了它们在思路、过程和测重点上有很大的差别，并各有利弊的。一类测试方法以需求和设计为本，有利于界定测试工作的范畴，更便于部署测试的侧重点，加强针对性。这一点对于应用程序的测试，尤其是在有限的时间和人力资源情况下显得格外重要。而二类测试方法与需求和设计没有必然的关联，如果计划管理不当，测试活动很容易丢失重点。一类测试方法可以与软件的架构和软件开发的计划相配合，使软件测试活动逐层次的展开，从而使软件的功能和质量有计划地逐步完善和提高。（二类测试方法不具备这种过程的渐进性）一类测试方法的缺点是缺乏灵活性，不

22、利于测试人员主观能动性的发挥，不容易找到软件的错误。而这方面正是二类测试方法的长处。Software Product Testing Framework-Zeng,qi(AMS-ATS)28我们的策略以一类测试方法为基础和主要线索阶段性地运用二类测试方法Software Product Testing Framework-Zeng,qi(AMS-ATS)29一类测试流程一、审核需求和设计一类测试是以需求和设计为本来验证软件的正确性。需求和设计本身也有正确性的问题。依据不正确的需求和设计不可能开发出正确的软件产品，测试也将是徒劳的。因此验证需求和设计是进行一类测试的第一步。这里所说的需求和设计具

23、体说来它一般包括：（1）由项目经理根据用户要求（信息来源于市场部门，用户支持部门等等）而编写的需求文本（Requirement Specification）；（2）由项目经理根据需求文本而编写的功能设计文本（Functional Design Specification）；（3）由开发人员根据功能文本而编写的实施设计文本（Implementation Design Specification）。测试人员要参与所有这些文本的审核。作为测试人员，审核重点是检查文本对需求定义的完整性、严密性和功能设计的可测性。同时这种审核对于测试人员也是一种热身活动，使他们尽早地进入技术和业务状态。Software

24、 Product Testing Framework-Zeng,qi(AMS-ATS)30一类测试流程二、设计测试测试人员根据已审核通过的需求和设计编制测试计划，设计测试用例。在前面提到的三种文本中，功能设计文本是主要依据。这类测试关心的是软件是否能正确地实现功能，而不是这些功能如何被具体实施的。这是典型的“黑盒测试”。软件产品的测试主要是从用户角度进行的黑盒测试。这一步的完成就意味着“测试计划”和“测试用例设计”两个文本的完成。“测试计划” 文本主要阐述测试的范畴、领域、方法、工具、资源和计划时间表等等。“测试用例设计”文本要列出测试用例、每个用例的设置、执行步骤和预期结果。测试的这两个文本

25、也要被项目经理和开发人员审核。这样经过各种相互的审核，大家对项目形成了基本的共识。 Software Product Testing Framework-Zeng,qi(AMS-ATS)31一类测试流程三、实施运行测试 实施运行测试是整个开发过程中最长最复杂的阶段。从总体上说就是将上一步设计的测试用例按计划付诸实施的过程。 这包括编写自动化测试程序、反复运行自动化测试程序，也包括阶段性执行手动测试用例。这一阶段的测试必须在周密的计划下进行，这正是第一类测试的特点和长处。这种计划性首先体现在开发和测试的相互协调配合，根据产品的架构和功能模块的依赖关系，按照项目的总体计划共同推进。从测试的过程来看

26、，总是先运行或执行简单用例，然后再复杂用例；先验证单一的基本功能，再综合的端到端的功能；先发现解决表面的，影响面大的Bug，再深层的，不容易重现的Bug。因此随着项目开发和测试的进程，产品的功能不断完善，质量不断提高。这里有一点要特别指出，有很多测试用例是要反复运行的，特别是基本的自动化测试每一天，每一个Build上都要运行。尽管这些测试大多数情况下都是通过的，很少再发现新的Bug，但其价值是显而易见的，就是为了防止质量回归。这一阶段测试人员还有一项繁琐但却很重要的工作，就是对已有的测试用例的维护。比如通常以下两种情况下要新增一些测试用例，一是对于当初测试设计不周全的领域，二是对于外部的Bug

27、（比如从Beta客户报告来的），没有被现有测试用例所覆盖。当产品的功能设计出现更改时,所涉及的测试用例当然也要相应地修改。 Software Product Testing Framework-Zeng,qi(AMS-ATS)32二类测试流程阶段性测试根据需要而带有随机性和突击性。对于这类测试，有一个专门的名称：“Bug Bash（Bug大扫除）”。Bug Bash通常发生在产品开发各阶段（里程碑）的末期，比如Beta版发布前，划出一个专门的时间段（通常1-3天），在这期间所有参与项目的人员，集中全部精力，运用各方面的知识来搜寻项目的Bug。一般有以下要点：1）尽管这是一个测试活动，但参与者并

28、不仅限于测试人员。项目经理，开发人员甚至于高层管理人员都应参加，如同全民动员。目的是要集思广益； 2）鼓励各部门，领域交叉搜索，新的思路和视角通常有助于发现更多的Bug； 3）分专题展开，比如安全性、用户界面可用性、国际化和本地化等等。4) 专业性的测试，如针对安全性攻击测试。可邀请公司内部，或业界的专家来搜寻产品的漏洞。Software Product Testing Framework-Zeng,qi(AMS-ATS)33测试与开发的融合Software Product Testing Framework-Zeng,qi(AMS-ATS)34测试与开发流程融合趋势有意整合测试和开发融合的手

29、段1、测试活动的早期展开，让测试人员参与用户需求的验证，参加功能设计和实施设计的审核。2、如测试人员与开发人员的密切合作，随着开发进展而逐步实施单元测试、模块功能测试和系统整合测试。以上都是测试与开发融合的表现形式，而且初期的融合也只反映在这个层次上。90年代以后，软件的规模和复杂程度迅速提高，这种形式上的融合也迅速走向更深层次，更具实际意义。具体地说这种融合就是整个软件开发活动对测试的依赖性。传统上认为，只有软件的质量控制依赖于测试，但是现代软件开发的实践证明，不仅软件的质量控制依赖于测试，开发本身离开测试也将无法推进，项目管理离开了测试也从根本上失去了依据。Software Product

30、 Testing Framework-Zeng,qi(AMS-ATS)35测试在产品开发团队中的作用1、协调开发 在微软，这种协调是通过测试来实现的。具体来说就是：每日建造+自动化测试。就是每天都建造一个新版本，每个版本都要运行通过一定量的自动测试用例，以检验当天工作的质量。这里所说的质量有一般意义上质量的概念，同时它也反映项目在开发过程中的整体协调性。 自动测试的最大优点在于它的高度可重复性。一个理想的自动测试系统能够让人随时、方便和迅速的运行大量的测试用例。因此一个开发人员可以通过检查当天的自动测试结果来分析前一天代码的质量（事后检查），也可以在当天存入代码前，先运行自动测试以进一步确保存

31、入代码的质量（事前检查）。 在微软，每日建造都是在午夜开始，完成后紧接着就是全面的自动测试，到早晨上班时间之前就会把结果自动通过e-mail等方式发送出来。开发人员上班后的第一件事往往就是检查测试结果。如果没有问题就会开始新的工作。如果有测试有用例没有通过，开发人员则必须协同测试人员一起立刻找出原因，解决后才能开始新的代码。有时一个小的失误会引起大面积的测试用例失败，很大一部分开发团队会受到影响。为尽量避免这种情况，要求开发人员在存入代码之前先在自己的个人建造版本上运行一定量的自动测试，全部通过后在存入。如开发人员没有按照这样的要求，而擅自存入质量不高的代码而造成大量测试失败，这种不负责任的行为是要受到严厉批评的。从这一过程可以看出，开发人员依赖测试来保证开发工作的质量，使开发整体地协调地向前推进。Software Product Testing Framework-Zeng,qi(AMS-ATS)36测试在产品开发团队中的作用1、协调开发 当开发进入后期阶段，尽管项目已总体成型，开发人员也会不时遇到一些技术上的挑战。比如一些Bug的解决涉及对项目深层次结构的调整；由于客户反馈的意见造成设计的修改。每一次这样的修改和调整事实