《软件测试技术ppt课件讲解学习》由会员分享，可在线阅读，更多相关《软件测试技术ppt课件讲解学习（196页珍藏版）》请在金锄头文库上搜索。
1、软件测试技术,课程特点,用真实应用的案例和技术来讲解如何解决测试中的实际难题 课程的中心思想是如何建立质量保证体系，做到缺陷的预防 用一个大型的真实产品作为案例，讲解从立项计划到发布的每一步是如何实施的 对于同一个测试环节，开发人员、测试人员、测试管理者应该分别关注什么、做哪些工作来最终保证测试质量 不仅讲解要做好测试都需要做什么，更注重讲解怎么做、为什么这样做、如果不这样做会出现什么情况,课程安排,与实践相关的软件测试理论 这一部分只会用很少的一点时间，基础知识略过，仅对实践中最重要的、最容易混淆或最容易出问题的地方强调一下 测试计划 这部分内容将分别从测试执行者和测试管理者的角度出发，讲解
2、如何制定能覆盖到细节的测试计划，以及准备资源的依据，并最终评定每一个测试人员的测试执行情况,课程安排,测试用例设计方法 这部分内容会着重讲解如何进行深度验证和解决白盒测试的难点，以及各种用例设计方法的综合使用,课程安排,测试度量体系的建立这部分内容会在课程中分两个层面讲解。第一个层面是技术方面的，包括与缺陷相关的各种度量数据，软件可靠性分析 、缺陷分析等；第二个层面是管理方面的，包括如何应用数据进行辅助决策、需要积累和建立哪些数据内容、以及根据缺陷状态预估项目进度和质量等级等。,课程安排,自动化测试技术 这部分内容先从自动化测试技术的初级部分入手，介绍最新的自动化测试技术和挑选工具的方法，然后
3、分析自动化测试技术的核心价值,课程安排,缺陷预防的持续改进 这部分内容是核心中的核心，它是建立在前面用例设计、测试计划和各种测试方法的基础上的，可以说前面的内容都是在为这一块打基础,课程安排,测试管理 没有科学的测试管理就不可能建立完备的质量保证体系，这部分内容讲解在实践中如何进行缺陷的度量。软件质量的度量以及测试质量的度量,在课程中要逐一解决的问题,测试人员不足，尤其是有经验的测试工程师不足 团队对Bug的理解不一致，有时测试团队开的Bug开发团队不认可 没有有效的技术手段保证测试速度，甚至测试被认为额外增加了项目进度时间 测试量很大，测试报告不能及时反映最新版本中存在的问题 测试中重复劳动
4、太多，长期下来，测试工程师缺乏成就感和创造力 软件发布前是否经历了足够的测试？能否发布到底谁说了算？ 缺陷预防的持续改进 建立质量保证体系,第一章 软件测试基础理论,什么是软件测试,软件测试的引出 软件测试的定义 软件测试的存在阶段,软件测试的引出,什么是有效代码？怎么知道写出的代码是不是有效的？ 测试仅仅是一种技术吗？ 测试仅仅是一种活动吗？ 测试是在开发进度的基础上额外投入一块时间吗？ 测试是要建立起一套质量保证体系，使得项目按照既定的方向和标准前进,软件测试的定义,为了保证软件的质量和可靠性，应力求在分析，设计等各个阶段结束前，对软件进行严格的评审。也就是说软件测试是在软件投入运行前，对
5、软件需求分析，设计规格说明和编码的最终审查，它是软件质量保证的关键步骤。,软件测试的存在阶段,需求阶段的Spec Review 编码阶段的单元测试 编码完成后的各种综合测试 测试可以加速软件开发进度，在实践上必须让测试渗透到每一个阶段、每一个细节,什么是软件缺陷,缺陷的定义：软件缺陷这一概念用来描述各种软件错误，是所有软件错误的统称。 把符合下列5种特征之一的软件错误认为是软件缺陷： （1）软件未达到软件产品需求说明书中指明的要求； （2）软件出现了软件产品需求说明书中指明不会出现的错误； （3）软件功能超出了软件产品需求说明书中指明的范围； （4）软件未达到软件产品需求说明书中虽未指明但应达
6、到的要求； （5）难以理解、不易使用、运行速度缓慢或者最终用户认为不好的问题。,缺陷的分类,缺陷和BUG，它的分类要根据不同的公司不同的产品来确定，但是基本的分类思想是一致的。 Code bug Spec bug Performance Security UI Bug Accessibility,可能发生的风险,以下方面是很容易引入风险的： 软件在发布或交付使用之前没有经历足够的测试 采用产量很少的硬件、芯片，及即将停产的型号 购买刚被兼并的软件公司的产品 不明确的需求 未经充分论证的架构,Myers软件测试目的,1979年，Glenford Myers在The Art of Software
7、 Testing一书中提出“测试的目的是证伪”这一概念，推翻了过去“为表明软件正确而进行测试”的错误认识，为软件测试的发展指出了方向，软件测试的理论、方法在之后得到了长足的发展。,软件测试的原则,1. 应当把“尽早地和不间断地进行软件测试”作为测试团队的座右铭。 2. 如何做到尽早测试和不间断测试？ 3. 程序员应避免检查自己的程序。 4. 在设计测试用例时，应包括合理的输入条件和不合理的输入条件。,5. Bug的标准：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 6. 严格执行测试计划，排除测试的随意性。 7. 应当对每一个测试结果做全面检查。 8. 让数据说话：通过对测试用
8、例和Bug的追踪统计，看出项目组发生了什么、正在发生什么、甚至将会发生什么。测试团队需要建立Case管理平台和缺陷追踪体系,详细设计规格说明,概要设计规格说明,需求规格说明,怎样理解经典模型,Review,缺陷和Bug的区别 软件测试的意义,第二章 测试计划,如何在需求和设计阶段有效的介入 对需求和设计的频繁变更如何应对 测试文档的核心价值是什么？为什么要写测试计划？,测试文档,Test Spec,INTRODUCTION Objective Statement Related Documents and Links Glossary,Test Spec,SCOPE Goals Non-Goa
9、ls Dependencies and Partners Risks Assumptions and Limitations Assumptions Limitations,Test Spec,FEATURE OVERVIEW Feature Description Release Criteria Functional Area Breakdown Feature Data Flow Diagram (DFD),Release Creteria,CC：Code Complete Pass Rate：这是RC的核心衡量指标之一，我们的要求是必须保证95的case通过率 Case和Bug的级别：
10、允许存在5不通过的case，但这些case决不能是重要case ZBB：这是Zero Bug Bounce的缩写，意为“零Bug边界” Code Coverage：代码覆盖率,Test Spec,FEATURE VALIDATION For all features Overview Valid Scenario Invalid Scenarios,Test Spec,GENERAL APPROACHES Security Permission Help and documentation International Sufficiency (Globalization/localizatio
11、n) Accessibility Scalability/ Performance Stress Geo/Political/Legal Logging/ Message format Tracing/Counters( Diagnos ability) Testability Test Hooks,Test Spec,SCENARIO BASED TESTS Reliability/LongHaul Memory Usage CPU Usage Time Consumption Integration Interoperability Compatibility,Test Spec,TEST
12、 COMPONENT CHECKLIST tool/lib name Feature list,Test Spec,Topology requirements,Test Spec,OPEN ISSUES,Test Spec,SIGN-OFF CHANGE HISTORY,Review,一篇好的测试文档应当包含哪些内容、注意哪些方面,第三章 测试用例设计,测试用例设计,黑盒测试 等价类划分 边界值分析 错误推测法 因果图,白盒测试 逻辑覆盖 判定结构分析 循环结构分析 基本路径覆盖,黑盒测试,这种方法是把测试对象看做一个黑盒，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求和功能
13、规格说明，检查程序的功能是否符合它的功能说明。 黑盒测试叫做功能测试或数据驱动测试。 一种特殊的黑盒测试叫做接口测试，它不管程序的需求和实现细节，仅依据程序与其外部环境的接口来选择测试数据。,黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误: 是否有不正确或遗漏了的功能？ 在接口上，输入能否正确地接受？ 能否输出正确的结果？ 是否有数据结构错误或外部信息 (例如数据文件) 访问错误？ 性能上是否能够满足要求？ 是否有初始化或终止性错误？,用黑盒测试发现程序错误，必须在所有可能的输入条件和输出条件中确定测试数据，检查程序能否产生正确的输出。 但这是不可能的。例如，设一个程序P有输入量X
14、和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数，按黑盒方法进行穷举测试：可能采用的测试数据组个数：232232264 如果测试一组数据需要1毫秒, 一年工作36524小时，完成所有测试需5亿年。,白盒测试,此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。 通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。,软件人员使用白盒测试方法，主要想对程序模块进行如下的检查： 对程序模块的所有独立的执行路径至少测试一次 路径覆盖测试； 对所有的逻辑判定，
15、取“真”与取“假”的两种情况都至少测试一次 逻辑覆盖测试； 在循环的边界和运行界限内执行循环体 控制流测试； 测试内部数据结构的有效性 数据流测试、领域测试等。,对一个具有多重选择和循环嵌套的程序，不同的路径数目可能是天文数字。给出一个小程序的流程图，它包括了一个执行20次的循环。 包含的不同执行路径数达 520 条，对每一条路径进行测试需要1毫秒，假定一年工作36524小时，要想把所有路径测试完，需3170年。,灰盒测试,灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来
16、判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。,灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。 灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。,逻辑覆盖,语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 条件组合覆盖 路径覆盖,逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。,(A1) and (B=0),(A=2) or (X1),X = X/A,X = X+1,T,T,F,F,a,b,d,c,e,L1 ( a c e ) = (A 1) and (B = 0) and (A = 2) or (X/A 1) = (A 1) and
