• 1. 软件测试基础理论概述
  • 2. 进制转换 一、任意进制数转换成十进制数 方法:按权展开求和 使用每一位的系数乘以该位的权(几进制数,底就为几,右侧第一位次幂为0,右侧第二位次幂为,…….),进行相加运算 二、十进制数转换成其它进制数 方法:除基取余逆排法 使用要转换的十进制数,反复除以基数(2进制的基数为2,十六进制的基数为16),求每一次的商和余数;直到商为0,再把余数反向排列。 注意: 对于十六进制,当余数为10——15时,要使用A——F替代
  • 3. 三、二进制数与十六进制转换 十进制 十六进制 二进制 0 0 0000 1 1 0001 2 2 0010 3 3 0011 4 4 0100 5 5 0101 6 6 0110 7 7 0111 8 8 1000 9 9 1001 10 A 1010 11 B 1011 12 C 1100 13 D 1101 14 E 1110 15 F 1111 16 10 10000
  • 4. 1、二进制数转十六进制数:方法:从低位(右侧)起每四位数分成一组,最高位不够四位补零,然后顺序写出对应的十六进制数。(4 合 1) 十六进制数转二进制数: 方法:用四位二进制数表示一位十六进制,去掉最高位零,然后顺序排列二进制数。(1 分 4) 四、二进制数与八进制转换 十进制 八进制 二进制 0 0 000 1 1 001 2 2 010 3 3 011 4 4 100 5 5 101 6 6 110 7 7 111 1、二进制数转八进制数:方法:从低位(右侧)起每三位数分成一组,最高位不够三位补零,然后顺序写出对应的八进制数。(3 合 1) 2、八进制数转二进制数: 方法:三位二进制数表示一位八进制,去掉最高位零,然后顺序排列二进制数。(1 分 3)
  • 5. 内容软件测试的定义 软件测试的目标 软件测试的对象 软件测试的原则 软件测试的方法 软件的生命周期 软件的测试流程 软件测试评测方法
  • 6. 软件测试的定义软件的定义 软件(software)是计算机系统中与硬件(hardware)相互依存的 另一部分,它是包括程序(program)、文档(document)的完整集合。 软件=程序+文档 软件测试的定义 简单的说,软件测试就是在现有软件中寻 找缺陷的过程。
  • 7. 软件类型 计算机软件分为系统软件和应用软件两大类。 按照软件结构分类 (看软件的运行是否基于网络,不是——单机软件,是——分布式软件) 单机软件:只要在一台机器上安装好就可以使用 分布式软件: 基于网络,分成“服务器端”程序和“客户端”程序,按照客户端不同,又可分为: C/S(client/Server客户端/服务器)结构 B/S(browser/Server浏览器/服务器)结构 你所测试的软件是什么类型? 如何区分B/S和C/S结构的软件 如果客户端只使用“浏览器”这个软件——B/S 网站程序、论坛、百度 如果客户端需要安装专门的软件才能享受服务——C/S QQ、MSN、联众游戏
  • 8. 测试人员的主要工作职责1、编写测试计划 2、编写测试用例 3、执行测试,发现缺陷提交缺陷报告 4、验证所发现的缺陷是否得到修改 5、编写测试总结报告
  • 9. 测试计划什么是测试计划? 测试计划Testing plan,描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险,保障计划的顺利实施。   测试计划编写6要素?(5W1H)   1)why——为什么要进行这些测试;   2) what—测试哪些方面,不同阶段的工作内容;   3) when—测试不同阶段的起止时间;   4) where—相应文档,缺陷的存放位置,测试环境等;   5) who—项目有关人员组成,安排哪些测试人员进行测试   6) how—如何去做,使用哪些测试工具以及测试方法进行测试。
  • 10. 缺陷报告示例缺陷报告 1缺陷标题除数为零时程序异常关闭缺陷发现者张三日期2012-2-1 所属模块除法发现缺陷的版本V1-2-1指派给谁处理李四缺陷状态新提交New严重程度 非常严重VeryHigh优先级本版本修改VeryHigh缺陷描述1、在第一个数中输入102、在第二个数中输入0 3、点击除法“/”按钮后,提示“除数为零”4、在错误提示框中点击“确定”按钮后,程序关闭预期结果:程序应该正常运行 实际结果:程序非法关闭
  • 11. 缺陷报告的重要组成1、缺陷编号(Defect ID) 2、缺陷标题(summary) 3、缺陷的发现者(Detected By) 4、发现缺陷的日期(Detected on date) 5、缺陷所属的模块(subject) 6、发现缺陷版本(Detected in release) 7、指派给谁处理(Assigned to) 8、缺陷的状态(status) 描述缺陷此时所处的状态 例如: 新提交的缺陷——new 打开的缺陷——open 被拒绝的缺陷——rejected 已经被修改完的缺陷——fixed 重新打开的缺陷——reopen 关闭的缺陷——closed
  • 12. 缺陷报告的重要组成9、缺陷的严重程度(severity) 指明该缺陷对软件造成的影响程度有多大 例如: 造成死机或影响开发、测试进度的问题——Urgent 非常严重的功能问题——Very High 大的功能问题——High 中等程度的功能问题——Medium 小的功能问题——Low 10、缺陷的优先级(priority) 希望该缺陷什么时间内或者哪个版本程序员可以解决 例如: Urgent——立刻修复 Very High——本版本修复 High——下一个版本修复 Medium——发布之前修复 Low——允许在发布产品中存在 同样,每个单词代表的具体含义每个公司可能是不一样,应该在测试计划或是在专门的文档中定义好
  • 13. 缺陷报告的重要组成11、缺陷描述(description) 把发现这个缺陷的具体步骤记录下来,使开发人员通过你的描述可以看到这个缺陷,以便他去解决这个缺陷 要求:描述清晰、准确、易读,使开发人员容易读懂,并可以重现缺陷——初学者练习的重点、难点 缺陷报告的用途 记录软件缺陷 对缺陷进行分类 跟踪软件缺陷 用于缺陷的分析、总结 软件缺陷的识别 通过测试用例中的预期结果进行识别 通过需求规格说明书进行识别 通过和开发人员、需求人员、用户沟通进行识别 写缺陷报告时注意的问题 一个报告只提交一个缺陷 缺陷描述清晰、准确、易读,使用最少、必须的步骤,保证缺陷可以再现 对缺陷的严重性、优先级的划分准确、客观 在提交缺陷报告之前一定要认真审核,确保提交的缺陷是有效的,而不是因为自己的疏忽或操作不正确造成的“假缺陷” 不要为了引起开发人员的重视而夸大缺陷 小的缺陷也要报告 及时报告缺陷 对于不可重现的缺陷也要报告 不做任何评价
  • 14. 软件测试的定义一:使用人工或自动化的方式来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别. 二:软件测试是贯穿整个软件开发生命周期,对软件产品(包括阶段性产品)进行验证和确认的的活动过程。 验证:是为确定某一开发阶段的产品是否满足在该阶段开始时提出的要求而对系统或部件进行评估的过程. 确认:是在开发过程中或结束时对系统或部件进行评估,以确定其是否满足需求规格的过程。 三:软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例,并利用这些测试用例来运行软件,以发现软件错误的过程。
  • 15. 软件测试目标第一:确保软件质量。 第二:通过信息。 第三:保证整个软件开发过程是高质量的。
  • 16. 软件测试的对象软件测试的对象不仅仅是程序,还包括整个软件生命周期中所有的文档。 如:在软件定义阶段产生的可行性报告,项目实施计划,软件需求说明书或功能说明书。 在软件开发阶段产生的概要设计说明书和详细设计说明书、源程序。
  • 17. 软件测试的原则原始要求需求分析正确的规格说明错误的规格说明设计正确的设计错误的设计 错误的设计 对错误说明的设计编码正确的编码错误的编码错误编码对错误设计的编码对错误说明的编码测试主要功能可改正的错误不可改正的错误潜伏的错误 不完善的产品
  • 18. 软件测试的方法单元测试集成测试系统测试验收测试概念单元测试又称模块测试,是针对软件设计的最小单位——程序模块进行正确性检验的测试工作集成测试也叫做组装测试。通常在单元测试的基础上,将所有的程序模块进行有序的、递增的测试。系统测试是在真实或模拟系统运行的环境下,检查完整的程序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、连接,并满足用户需求。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审,决定是否接收或拒收系统 测试时机编码之后,代码通过编译在单元测试之后集成测试之后系统测试后期,软件正式交付使用之前测试人员白盒测试工程师或开发人员白盒测试工程师或开发人员 黑盒测试工程师用户和黑盒测试工程师测试依据1,源程序本身,包括代码和注释 2,详细设计文档1,单元测试的模块 2,概要设计文档需求规格说明书需求规格说明书测试通过标准1,单元测试用例执行率100,通过率为95% 2,语句的覆盖率为100% 3,分支覆盖率达到85%1,各个单元模块结合到一起能够协同配合,正常运行 2,测试用例执行率100%,通过率95%1,系统功能、性能满足需求规格说明书中的要求 2,测试用例执行率100%,通过率95% 1,系统功能、性能满足需求规格说明书中的要求 2,测试用例执行率100%,通过率95% 主要方法
  • 19. 软件测试方法静态测试是指不实际运行被测软件,而只是静态地检查程序代码、界面或文档中可能存在错误的过程。 动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现
  • 20. 软件测试的分类测试阶段静态测试动态测试可行性评审Y需求评审Y设计评审Y单元测试Y集成测试Y系统测试Y验收测试Y
  • 21. 软件测试方法 黑盒测试 白盒测试概念黑盒测试法把测试对象看成一个黑盒子,完全不考虑程序内部结构和处理过程,通过软件的外部表现来发现其缺陷和错误。白盒测试可以把程序看成装在一个透明的白盒子里,也就是清楚了解程序结构和处理过程,检查是否所有的结构及路径都是正确的,检查软件内部动作是否按照设计说明的规定正常进行。 测试人员黑盒测试工程师或用户白盒测试工程师或开发人员测试依据需求规格说明书1,源程序,包括代码和注释 2,详细设计文档主要方法等价类划分,边界值分析,因果图,判定表,错误推测法,场景法等逻辑覆盖,循环覆盖,基本路径覆盖应用软件确认测试软件验证测试
  • 22. 软件测试的分类功能测试: 根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们是否满足设计需求。又可细分为: 逻辑功能测试:假设一个软件输入1就运行A流程,输入2就运行B流程,输入3就 提出。那么对于测试人员来说,输入1~3就执行不同的逻辑。你也可以输入0,4来检验程序是否做了保护处理。 界面测试、安装测试、易用性测试、兼容性测试 性能测试: 评价一个产品或组件与性能需求是否符合的测试。包括负载测试、压力测试、数据库容量测试等。可分为: 一般性测试、稳定性测试、负载测试、压力测试。 回归测试是指对软件的新版本测试时,重复执行上一个版本测试时的用例 冒烟测试是指在对一个新版本进行系统大规模的测试之前,先验证一下软件的基本功能是否实现,是否具备可测性 随机测试也称为猴子测试,是指测试中所有的输入数据都是随机产生成的,其目的是模拟用户的真实操作,随意向系统输入操作
  • 23. 软件生命周期软件的生命周期:即一个软件从功能确定、设计、开发成功、投入使用并在使用中被不断地完善、维护直到被新的需要替代而停止使用的过程。 软件的生命周期包括软件开发生命周期和软件测试生命周期。 计划需求设计编码测试运维
  • 24. 瀑布模型瀑布模型的优点: 1、强调开发的阶段性,各阶段具有顺序性和依耐性 2、推迟编码的实现,主张早期调研和需求分析。 3、质量保证的观点,要求每个阶段的产品在评审之后才能进入下一个阶段 4、“线性逻辑”容易掌握及应用。 5、可在复杂的非线性模型中应用 瀑布模型的缺点: 1、文档驱动,用户无法及时了解产品的情况 2、 当需求变更时会导致阶段反复而且都要重复需求、设计、编码、测试的过程 3、早期的错误要到后期才能发现,无法全面保证质量,控制风险。 4、流程单一,不可逆。 5、严格线性运行,无法在人员、工作量上实现最优搭配。严重影响工作效率和进度。 瀑布模型适应范围:需求稳定的产品。
  • 25. V模型用户需求需求分析概要设计详细设计编码单元测试集成测试系统测试验收测试
  • 26. V模型练习题V模型指出,A对程序设计进行验证 A. 单元和集成测试 B. 系统测试 C. 验收测试和确认测试 D. 验证测试 V模型指出,对系统设计进行验证B A. 单元测试 B. 集成测试 C. 功能测试 D. 系统测试 V模型指出,应当追朔到用户需求说明C A. 代码测试 B. 集成测试   C. 验收测试 D. 单元测试 典型的瀑布模型的四个阶段是:( ABCD ) A、分析 B、设计C、编码D、测试 E、需求调研 F、实施
  • 27. V模型练习题说出软件测试过程V模型,并说明它存在的缺点,可以画图。 V模型是软件测试过程中常见的一种模型,它反映了了开发过程和测试过程的关系,在测试软件的过程中起着重要的作用。在这种模型的测试过程中,首先,进行可行性研究需求定义,然后以书面的形式对需求进行描述,产生需求规格说明书。之后,开发人员根据需求规格说明书来对软件进行概要设计,测试人员根据需求规格说明书设计出系统测试用例。概要设计之后,开发人员根据概要设计对软件进行详细设计,测试人员根据概要设计设计出集成测试用例。详细设计之后,开发人员根据详细设计进行编码,测试人员根据详细设计设计出单元测试用例。编码完成之后,测试人员根据单元测试用例对设定的软件的测试单元进行测试,单元测试完成之后,进行集成测试,然后进行系统测试,最后进行验收测试。 测试是开发之后的一个阶段。 § 测试的对象就是程序本身。 § 实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
  • 28. V模型的特点V模型的优点: 明确标明了测试过程中存在的不同级别 清楚地描述了测试阶段与开发过程各阶段的对应关系 V模型的测试策略既包括了低层测试(代码级的测试),又包括了高层测试(需求级的测试) V模型的缺点: 它仅仅把测试过程作为需求分析,概要设计,详细设计、编码之后的一个阶段,容易让人理解为测试是软件开发的最后一个阶段。 没有明确说明早期的测试,不符合越早测试和不断地进行测试的原则。
  • 29. W模型
  • 30. 软件测试的流程
  • 31. 软件测试流程—需求评审需求评审注意事项: 一、注意对需求规格说明的正确性进行评审 1、是否冲突或者重复 2、是否清晰、简洁、无二义性。 3、是否有内容和语法错误。 4、是否合理的确定了性能指标 5、是否合理的确定了安全性指标。 二、注意对需求规格说明的完整性进行评审。 1、是否包含所有已知客户需求或系统需求。 2、所有需求的详细程度是否合适,是否能为设计提供足够的基础 3、是否定义了每个需求的实现优先级 4、是否把不确定的需求确定为遗留问题,而不是直接舍弃。 5、每个需求在特定的输入条件下是否给出已知的输出结果。 测试人员参加“需求评审”要达到的目标: 1、充分理解用户需求 2、确保需求的可测试性
  • 32. 软件测试流程—测试计划编写测试计划的目的: 1、领导能够根据测试计划做宏观调控,进行相应资源配置 2、测试人员能够了解整个项目测试情况以及项目不同阶段要进行的工作等。 3、便于其他人员了解测试人员的工作内容,进行有关配合。 什么时候开始编写测试计划? 尽早开始,原则上是需求定义完成后开始编写测试计划。对于开发过程不是十分清晰和稳定的项目,测试计划也可以在总体设计完成后开始编写。 由谁编写测试计划? 具有丰富经验的测试负责人。 测试计划的编写策略: 1、明确测试计划目标,增强测试计划实用性 2、坚持5W1H,明确内容与过程。 3、采用评审和更新机制,保证测试计划满足实际需求。 4、分别创建测试计划与测试详细规格。
  • 33. 软件测试的流程—测试设计过程分解测试对象定义测试用例建立需求覆盖设计测试步骤分析测试用例更新测试用例
  • 34. 软件测试的流程—测试设计测试用例主要记录了测试的过程、步骤、输入的数据、预期结果等内容。它是在执行测试之前由测试人员编写的指导测试的重要文档。 解决要测什么、怎么测和如何衡量的问题 测试用例用途 核实需求:要使最终用户满意,首先就是要对用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性 监督过程:可以准确、有效的评估测试的工作量 评估结果:对产品进行评估,对测试完成情况进行评价 准确回归:快速的进行正确的回归 防止遗漏:使软件测试的实施重点突出、目的明确,确保需求功能不被遗漏。 提高效率:避免盲目测试 缩短周期:版本更新和升级时,只需修正少部分测试用例,资源复用。
  • 35. 测试用例的概念及作用测试用例主要记录了测试的过程、步骤、输入的数据、预期结果等内容。它是在执行测试之前由测试人员编写的指导测试的重要文档。 解决要测什么、怎么测和如何衡量的问题 作用: 便于团队交流 便于重复测试 便于跟踪统计 便于用户自测 测试用例由什么人来编写:测试设计人员。 编写测试用例的依据: 参考相关文档 需求文档 开发文档 用户手册 如果有软件的早期版本,尽快熟悉软件的使用 与相关人员讨论
  • 36. 测试用例包含的内容测试用例 项目名称(版本)-模块名称-测试功能项 测试人员-测试时间 测试目的-预置条件-其他参考信息 用例编号-相关用例 用例说明-输入条件-执行方法 预期结果 测试结果 缺陷编号 最佳方案:为每个被测需求最少设计两个测试用例,正面测试用例和负面测试用例。
  • 37. 测试用例的要求1、基本要求 在编写一条测试用例时,要求步骤描述清晰、准确、易读,预期结果明确 如果有特殊的设置、预置条件等,要明确写出 如果有输入数据,一般要给出输入数据取值 如果有附件,要给出附件存放位置,名称 检验标准 写完用例后,让别人照着自己的用例去执行测试,可以很顺畅的执行下来 2、高标准要求 测试用例编写的有条理、逻辑性强 可以按照功能点分类、操作顺序等逻辑编写,而不要无头绪的乱测 功能覆盖全面、深入,能够发现软件中更多的缺陷 检验标准 能把软件中的缺陷尽可能多的找出来,按照你的测试用例测试完的软件,遗留的缺陷最少——要求测试人员最终达到的目标,是一个需要长期练习、积累的过程。
  • 38. 测试用例的练习题1.什么是测试用例,主要包含哪些内容? 测试用例主要记录了测试的过程、步骤、输入的数据、预期结果等内容。它是在执行测试之前由测试人员编写的指导测试的重要文档。 2.如果说只让你保留两个内容,你认为测试用例应由那两部分组成? 测试用例由输入数据 和预期的输出结果 两部分组成。 3.设计用例的方法、依据有那些 参考相关文档: 1)需求文档、开发文档、用户手册 2) 如果有软件的早期版本,尽快熟悉软件的使用 4.一个测试工程师应具备那些素质和技能 熟练进行测试用例的编写,掌握3种以上自动化测试工具(测试管理工具),应具备素质逻辑能力 和细心
  • 39. 一、白盒测试; 逻辑覆盖方法:以程序的内部逻辑结构为基础。有以下6种: 语句覆盖:设计若干测试用例,运行被测程序,使程序中每个可执行语句至少执行一次 判定覆盖:设计若干测试用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次,即判断真假值均曾被满足 条件覆盖:在实际程序代码中,一个判定中通常都包含若干条件。 条件覆盖的目的是设计若干测试用例,在执行被测程序后,要使每个判定中每个条件的可能值至少满足一次。
  • 40. 4.判定-条件覆盖:设计足够的测试用例,使得判定中每个条件的所有可能取值至少满足一次,同时每个判定的可能结果也至少出现一次。 5.条件组合覆盖:设计足够的测试用例,使得所有可能的条件取值组合至少执行一次 6.路径覆盖:设计所有的测试用例,来覆盖程序中的所有可能的执行路径 。 基本路径测试:在程序控制流程的基础上,分析控制构造的环路复杂性,导出基本可执行路径集合,从而设计测试用例。
  • 41. 发现错误能力标 准含 义 1(弱)语句覆盖每条语句至少执行一次 2判定覆盖每一判定的每个分支至少执行一次 3条件覆盖每一判定中的每个条件,分别按“真”、“假”至少各执行一次4 判定/条件覆盖同时满足判定覆盖和条件覆盖的要求5 (强) 条件组合覆盖求出判定中所有条件的各种能组合值,每一可能的条件组合至少执行一次
  • 42. 二、黑盒测试 黑盒测试法把测试对象看成一个黑盒子,完全不考虑程序内部结构和处理过程,通过软件的外部表现来发现其缺陷和错误。 黑盒测试是在程序界面处进行测试,它只是检查程序是否按照需求规格说明书的规定正常实现。黑盒测试一般也称功能测试 常用方法:等价类划分、边界值分析法、因果图法、状态图测试法 综合策略:每种方法都能设计出一组有用例子,用这组例子容易发现某种类型的错误,但可能不容易发现另一类型的错误,因此在实际测试中,联合使用各种测试方法,形成综合策略,通常先用黑盒法设计基本的测试用例,再用白盒法补充一些必要的测试用例。
  • 43. 1、明确测试任务的范围 2、明确测试时间 3、搭建测试环境 4、学习被测软件 5、确认完全理解测试任务软件测试流程—测试前的准备
  • 44. 软件测试的流程—测试执行全方位观察测试用例的执行结果 进行测试过程记录 及时确认发现的问题 及时更新测试用例
  • 45. 软件测试流程—缺陷管理缺陷:软件未实现需求规格说明书要求的功能 软件出现了与需求规格说明书中不一致的情况 软件功能超出了需求规格说明书的范围 软件没有达到用户的期望目标(未明确提及但应该实现的目标) 软件难以理解、不易使用、运行缓慢(从测试人员的角度或客户的角度来看)
  • 46. 软件测试的流程—缺陷管理一个完整的缺陷报告通常由以下几部分组成: 缺陷编号 缺陷标题 测试的软件和硬件环境 测试的软件版本 缺陷的类型 缺陷的严重程度 缺陷的优先级别 缺陷出现的频率 缺陷的状态 重现缺陷的操作步骤 缺陷的实际结果描述 期望的正确结果描述 注释及附件
  • 47. 软件测试的流程—缺陷管理编写缺陷报告的技巧: 1.每个缺陷报告中只写一个缺陷或错误 2.对每个缺陷的描述做到中立、简洁、准确、完整,揭示缺陷实质 3.明确指明缺陷类型和严重程度 4.每一个步骤尽量只记录一个操作 5.缺陷复现的步骤要完整、准确、简短 6.附加必要的缺陷特征图像 7.附加必要的测试用例 8.尽量使用短语或短句,避免复杂句型结构
  • 48. 软件测试的流程—缺陷管理软件缺陷管理过程 1.提交缺陷 2.分析和定位缺陷 3.提请修改缺陷 4.修改缺陷 5.验证修改后的缺陷 6关闭缺陷
  • 49. 软件测试流程—测试报告测试报告是把测试的过程和结果写成文档,并对发现的问题和缺陷进行分析,为纠正软件 存在的质量问题提供依据,同时为软件验收和交付打下基础 一份完整的测试报告应该包含以下内容: 1.编写目的 2.项目背景 3.系统简介 4.测试时间、地点、及人员 5.测试环境与配置 6.测试方法与工具 7.测试工作量统计 8.缺陷统计 8.1发现缺陷统计 8.2解决缺陷统计 8.3遗留缺陷统计 9.测试结论与建议 10.附录
  • 50. 软件测试的评测测试的主要评测方法包括覆盖和质量 覆盖是对测试完全程度的评测 质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测
  • 51. 软件测试评测—覆盖评测最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖 基于需求的测试覆盖 基于需求的测试覆盖在测试生命周期中要评测多次,并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行、已成功的测试数) 计算公式:测试覆盖=T/RfT 其中:T是测试用例表示的测试数(可以是已计划、已实施的、已执行、已成功的测试数) 基于代码的测试覆盖 基于代码的测试覆盖是评测测试过程中已经执行的代码的多少和待执行的剩余代码的多少 计算公式:测试覆盖=I/TIic 其中I是代码语句、代码分支、代码路径、数据状态判定点或数据元素名,表示已执行的项目数 TIic (Total number of Item in the code)是代码中的项目总数
  • 52. 软件质量评测—质量评测
  • 53. (本页无文本内容)
  • 54. 结束语 THANK YOU 再见