• 1. 第九章 软件测试 测试的基本概念 黑盒测试 白盒测试 测试用例设计 软件的纠错 多模块程序的测试策略 面向对象系统的测试
  • 2. 软件测试的目的基于不同的立场,存在着两种完全不同的测试目的。 从用户的角度出发,普遍希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可接受该产品。 从软件开发者的角度出发,则希望测试成为表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确立人们对软件质量的信心。
  • 3. Myers软件测试目的(1) 测试是程序的执行过程,目的在于发现错误; (2) 一个好的测试用例在于能发现至今未发现的错误; (3) 一个成功的测试是发现了至今未发现的错误的测试。
  • 4. 换言之,测试的目的是 想以最少的时间和人力,系统地找出软件中潜在的各种错误和缺陷。如果我们成功地实施了测试,我们就能够发现软件中的错误。 测试的附带收获是,它能够证明软件的功能和性能与需求说明相符合。 实施测试收集到的测试结果数据为可靠性分析提供了依据。 测试不能表明软件中不存在错误,它只能说明软件中存在错误。
  • 5. 测试信息流
  • 6. 测试信息流软件配置:软件需求规格说明、软件设计规格说明、源代码等; 测试配置:测试计划、测试用例、测试程序等; 测试工具:测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。
  • 7. 测试结果分析:比较实测结果与预期结果,评价错误是否发生。 排错(调试):对已经发现的错误进行错误定位和确定出错性质,并改正这些错误,同时修改相关的文档。 修正后的文档再测试:直到通过测试为止。
  • 8. 通过收集和分析测试结果数据,对软件建立可靠性模型 利用可靠性分析,评价软件质量: 软件的质量和可靠性达到可以接受的程度; 所做的测试不足以发现严重的错误; 如果测试发现不了错误,可以肯定,测试配置考虑得不够细致充分,错误仍然潜伏在软件中。
  • 9. 软件测试的原则1. 应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。 2. 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 3. 程序员应避免检查自己的程序。 4. 在设计测试用例时,应包括合理的输入条件和不合理的输入条件。
  • 10. 5. 充分注意测试中的群集现象。 经验表明,测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。 6. 严格执行测试计划,排除测试的随意性。 7. 应当对每一个测试结果做全面检查。 8. 妥善保存测试计划,测试用例,出错统计和最终分析报告,为维护提供方便。
  • 11. 测试的特性挑剔性:测试是证明程序有错,而不是证明程序无错; 复杂性:设计测试用例是一项需要细致和高度技巧的工作,不亚于程序的开发; 不彻底性:不可能让被测程序在一切可能的输入情况下全部执行一遍。
  • 12. 测试的种类程序测试静态分析 (程序不执行)动态分析 (程序执行)静态分析器分析 (自动方式)代码评审(人工方式)代码会审走查办公桌检查黑盒测试(测试程序功能) 白盒测试(测试程序结构)
  • 13. 软件测试的对象 软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间。 需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档,包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序,都应成为软件测试的对象。
  • 14. 从源程序的测试中找到的程序错误不一定都是程序编写过程中造成的。 据美国一家公司的统计表明,在查找出的软件错误中,属于需求分析和软件设计的错误约占64%,属于程序编写的错误约占36%。
  • 15. 为把握软件开发各个环节的正确性,需要进行各种确认和验证工作。 确认(Validation),是一系列的活动和过程,目的是想证实在一个给定的外部环境中软件的逻辑正确性。 需求规格说明确认 程序确认 (静态确认、动态确认) 验证(Verification),试图证明在软件生存期各个阶段,以及阶段间的逻辑协调性、完备性和正确性。
  • 16. (本页无文本内容)
  • 17. 测试与软件开发各阶段的关系软件开发过程是一个自顶向下,逐步细化的过程 软件计划阶段定义软件作用域 软件需求分析建立软件信息域、功能和性能需求、约束等 软件设计 把设计用某种程序设计语言转换成程序代码
  • 18. 测试过程是依相反顺序安排的自底向上,逐步集成的过程。返
  • 19. 测试用例设计两种常用的测试方法 黑盒测试 白盒测试
  • 20. 动态黑盒测试 —闭着眼睛测试软件软件输入 不深入代码细节的测试方法称为动态黑盒测试。 软件测试员充当客户来使用它。输出
  • 21. 动态白盒测试 —带上X光眼镜测试??????????????3581322.293419985680302829734315250*(1+0.015)*((1+0.015)^360-1)/0.015250*(1+0.015)*((1+0.015)^360-1)/0.015 假如知道一个盒子包含一台计算机,而另一个 盒子是人用纸笔计算,就会选择不同的测试用例了解软件的运作方式会影响测试手段
  • 22. 黑盒测试这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。 黑盒测试又叫做功能测试或数据驱动测试。
  • 23. 黑盒测试方法是在程序接口上进行测试,主要是为了发现以下错误: 是否有不正确或遗漏了的功能? 在接口上,输入能否正确地接受? 能否输出正确的结果? 是否有数据结构错误或外部信息(例如数据文件)访问错误? 性能上是否能够满足要求? 是否有初始化或终止性错误? 
  • 24. 用黑盒测试发现程序中的错误,必须在所有可能的输入条件和输出条件中确定测试数据,来检查程序是否都能产生正确的输出。 但这是不可能的。
  • 25. 假设一个程序P有输入量X和Y及输出量Z。在字长为32位的计算机上运行。若X、Y取整数,按黑盒方法进行穷举测试: 可能采用的 测试数据组: 232×232 =264 如果测试一组数据需要1毫秒,一年工作365× 24小时,完成所有测试需5亿年。
  • 26. 白盒测试此方法把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。 通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
  • 27. 软件人员使用白盒测试方法,主要想对程序模块进行如下的检查: 对所有的逻辑判定,取“真”与取“假”的两种情况都至少测试一次, 称逻辑覆盖测试。 对程序模块的所有独立的执行路径至少测试一次,称路径测试。
  • 28. 对一个具有多重选择和循环嵌套的程序,不同的路径数目可能是天文数字。给出一个小程序的流程图,它包括了一个执行20次的循环。 包含的不同执行路径数达520条,对每一条路径进行测试需要1毫秒,假定一年工作365 × 24小时,要想把所有路径测试完,需3170年。
  • 29. (本页无文本内容)
  • 30. 黑盒测试与白盒测试比较 黑盒测试是从用户观点,按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序外部特征进行测试。 白盒测试是根据程序内部逻辑结构进行测试。
  • 31. 黑盒测试与白盒测试 不论黑盒还是白盒测试都不能 进行穷尽测试, 所以软件测试不可 能发现程序中存在的所有错误, 因 此需精心设计测试方案,力争尽可 能少的次数,测出尽可能多的错误。
  • 32. 等价分类法把输入数据的可能值划分为若干等价类,使每类中的任何一个测试用例,都能代表同一等价类中的其他测试用例。换句话说,如果从某一等价类中任意选出一个测试用例未能发现程序的错误,该类中的其他测试用例也不会发现错误。 不仅考虑有效等价类,还要考虑无效等价类。
  • 33. 如何划分等价类?有效等价类(合理等价类) 无效等价类(不合理等价类) 划分等价类的标准: 覆盖 不相交 代表性
  • 34. 划分等价类的规则(1)如果输入条件规定了取值范围, 可定义一个有效等价类和两个无 效等价类。例 输入值是学生成绩,范围是0~1000 100 有效 等价类 1≤成绩≤100无效等价类 成绩>100 无效等价类 成绩<0
  • 35. (2)如果某个输入条件规定了输入数据的个数,则可划分为一个有效等价类和两个无效等价类。 例如:每名学生一学期内只能选修1~3门课程。 有效等价类 :选修1~3 无效等价类:不选修和选修超过3门划分等价类的规则
  • 36. 划分等价类的规则(3)如规定了输入数据的一组值,且程序对不同输入值做不同处理,则每个允许的输入值是一个有效等价类,并有一个无效等价类(所有不允许的输入值的集合)。 例:输入条件说明学历可为:专科、本科、硕士、博士四种之一,则分别取这四种这四个值作为四个有效等价类,另外把四种学历之外的任何学历作为无效等价类.
  • 37. 划分等价类的规则:(4)如果某个输入条件规定了一组必须成立的条件,则可定义一个有效等价类和一个无效等价类。 例如,标志符的第一个字符必须是字母。 有效等价类:第一个字符是字母 无效等价类:第一个字符不是字母
  • 38. 划分等价类的规则:(5)如果某个输入条件是一个布尔量,则可定义一个有效等价类和一个无效等价类。
  • 39. 划分等价类的规则:(6)如果规定了输入数据为整数,则可以划分为正整数、零和负整数三个有效等价类和一个无效等价类。
  • 40. 用等价类划分法设计测试用例步骤(1)形成等价类表,每一等价类规定 一个唯一的编号; (2)设计一测试用例,使其尽可能多 地覆盖尚未覆盖的有效等价类, 重复这一步骤,直到所有有效等 价类均被测试用例所覆盖; (3)设计一新测试用例,使其只覆盖 一个无效等价类,重复这一步骤 直到所有无效等价类均被覆盖;
  • 41. 例:某报表处理系统要求用户输入处理 报表的日期,日期限制在2001年1 月至2005年12月,即系统只能对该 段期间内的报表进行处理,如日期 不在此范围内,则显示输入错误信 息。 系统日期规定由年、月的6位数字 字符组成,前四位代表年,后两位 代表月。 如何用等价类划分法设计测试用例, 来测试程序的日期检查功能?
  • 42. 第一步:等价类划分输入等价类 有效等价类 无效等价类 报表日期的 类型及长度6位数字字符(1)有非数字字符 (4) 少于6个数字字符 (5) 多于6个数字字符 (6)年份范围在2001~2005 之间 (2)小于2001 (7) 大于2005 (8)月份范围在1~12之间(3)“报表日期”输入条件的等价类表小于1 (9) 大于12 (10)
  • 43. 第二步为有效等价类设计测试用例 对表中编号为1,2,3的3个有效等价类 用一个测试用例覆盖: 测试数据 期望结果 覆盖范围200105 等价类(1)(2)(3) 输入有效
  • 44. 第三步:为每一个无效等价类设至少设计一个测试用例 测试数据 期望结果 覆盖范围001MAY等价类(4)输入无效20015等价类(5)输入无效2001005等价类(6)输入无效200005等价类(7)输入无效200805等价类(8)输入无效200100等价类(9)输入无效200113等价类(10)输入无效不能出现相同 的测试用例本例的10个等价类至 少需要8个测试用例
  • 45. 例:某工厂招工,规定报名者的年龄应在16~35岁之间,若不在此区间,拒绝接受,并显示“年龄不合格”等信息。 解:第一步:划分等价类输入数据有效等价类无效等价类出生年龄① 6位数字字符② 有非数字字符 ③ 少于6个数字符 ④ 多于6个数字符对应数值⑤ 在196702~198603之间⑥ <196702 ⑦ >198603月份对应数值⑧ 在1 ~12之间⑨ 等于“0” ⑩ >12
  • 46. 第二步:设计有效等价类的测试用例。 测试数据 期望结果 测试范围 ------------------------------------------------------------------------------------------------------------------------------------------- 197011 输入有效 ①、⑤、⑧ 第三步:为每一无效等价类至少设计一个测试用例。 测试数据 期望结果 测试范围 ------------------------------------------------------------------------------------------------------------------------------------------- MAY, 70 输入无效 ② 19705 输入无效 ③ 1968011 输入无效 ④ 195512 年龄不合格 ⑥ 196006 年龄不合格 ⑦ 196200 输入无效 ⑨ 197222 输入无效 ⑩
  • 47. 实践表明,在处理边界情况时,易发生编码错误。 边界值分析法,就是要选择测试用例,使得被测程序能在边界值及其附近运行,从而有效地暴露程序中潜在的错误。边界值分析法
  • 48. A、按照输入值范围的边界。 例如:输入值的范围是-1.0至1.0,则可选择用例 –1.0、1.0、-1.001、1.001。 B、按照输入/输出值个数的边界。 例如:输入文件可有1-255个记录,则 设计用例:文件的记录数为 0个、1个、255个、256个。 C、输出值域的边界。 例如:检索文献摘要,最多4篇。设计用例:可检索0篇、1篇、4篇,和5篇(错误)。 D、输入/输出有序集(如顺序文件、线性表)的边界。 应选择第一个元素和最后一个元素。边值分析法举例
  • 49. 输入等价类测试用例说明测试数据期望结果出生年月1个数字字符 5个数字字符 7个数字字符 1个非数字字符 全是非数字字符 6个数字字符 5 19705 168011 19705A August 196702 输入无效 输入有效对应数值35周岁 16周岁 > 35周岁 < 16周岁 196702 198603 196702 198604月份对应数值月份为1月 月份为12月 月份>1 月份<12 196702 198603 196700 197413合格年龄不合格年龄输入有效输入无效
  • 50. 错误猜测法所谓猜错,就是猜测被测程序在哪些地方容易出错,然后针对可能的薄弱环节来设计测试用例。这种方法更多依靠测试人员的直觉与经验。 上例中可补充一些测试用例: ① 出生年月为“0” ② 漏送“出生年月” ③ 年月次序颠倒
  • 51. 例如:测试一个排序子程序,可考虑如下情况: 输入表为空; 输入表只有一个元素; 输入表的所有元素都相同; 输入表已排好序。 又如,测试二分法检索子程序,可以考虑如下情况: 表中只有1个元素; 表长为 2n; 表长为 2n-1 表长为 2n+1
  • 52. 白盒测试通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
  • 53. 逻辑覆盖 语句覆盖 判定覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。
  • 54. 语句覆盖 语句覆盖就是设计若干个测试用例,运行被测程序,使得每一可执行语句至少执行一次。(若逻辑运算有问题) TFA∧BA∧B=. T .
  • 55. 判定覆盖判定覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次。 判定覆盖又称为分支覆盖。TFA∧BA∧B=. T . A∧B=. F .
  • 56. 条件覆盖条件覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断的每个条件的可能取值至少执行一次。TFA∧BA=. T . A=. F . B=. T . B=. F .
  • 57. 判定-条件覆盖 判定-条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次,每个判断中的每个分支至少执行一次。TFA∧BA∧B=. T . A∧B=. F . A=. T . A=. F . B=. T . B=. F .
  • 58. 条件组合覆盖条件组合覆盖就是设计足够的测试用例,运行被测程序,使得每个判断的所有可能的条件取值组合至少执行一次。 TFA∧BA=. T . ∧ B=. T . A=. T . ∧ B=. F . A=. F . ∧ B=. T . A=. F . ∧ B=. F .
  • 59. 例(A>1) and (B=0)(A=2) or (X>1)X=X/AX=X+1TTFFabdce
  • 60. L1 ( a  c  e ) = {(A>1) and (B=0)} and {(A=2) or (X/A>1)} = (A>1) and (B=0) and (A=2) or (A>1) and (B=0) and (X/A>1) = (A=2) and (B=0) or (A>1) and (B=0) and (X/A>1)
  • 61. L2 ( a b  d ) = not{(A>1) and (B=0)} and not{(A=2) or (X>1)} = { not (A>1) or not (B=0) } and { not (A=2) and not (X>1) } = not (A>1) and not (A=2) and not (X>1) or not (B=0) and not (A=2) and not (X>1)
  • 62. L3 ( a b e) = not {(A>1) and (B=0)} and {(A=2) or (X>1)} = { not (A>1) or not (B=0)} and {(A=2) or (X>1)} = not (A>1) and (A=2) or not (A>1) and (X>1) or not (B=0) and (A=2) or not (B=0) and (X>1)
  • 63. L4 ( a c  d ) = {(A>1) and (B=0)} and not {(A=2) or (X/A>1)} = (A>1) and (B=0) and not (A=2) and not (X/A>1)
  • 64. 语句覆盖 语句覆盖就是设计若干个测试用例,运行被测程序,使得每一可执行语句至少执行一次。 在图例中,正好所有的可执行语句都在路径L1上,所以选择路径 L1设计测试用例,就可以覆盖所有的可执行语句。
  • 65. 测试用例的设计格式如下 【输入的(A, B, X),输出的(A, B, X)】 为图例设计满足语句覆盖的测试用例是: 【(2, 0, 4),(2, 0, 3)】  覆盖 ace【L1】(A=2) and (B=0) or (A>1) and (B=0) and (X/A>1)
  • 66. 判定覆盖判定覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次。 判定覆盖又称为分支覆盖。 对于图例,如果选择路径L1和L2,就可得满足要求的测试用例:
  • 67. 【(2, 0, 4),(2, 0, 3)】覆盖 ace【L1】 【(1, 1, 1),(1, 1, 1)】覆盖 abd【L2】(A=2) and (B=0) or (A>1) and (B=0) and (X/A>1) not (A>1) and not (A=2) and not (X>1) or not (B=0) and not (A=2) and not (X>1)
  • 68. 如果选择路径L3和L4,还可得另一组可用的测试用例: 【(2, 1, 1),(2, 1, 2)】覆盖 abe【L3】 【(3, 0, 3),(3, 0, 1)】覆盖 acd【L4】 not (A>1) and (X>1) or not (B=0) and (A=2) or not (B=0) and (X>1)(A>1) and (B=0) and not (A=2) and not (X/A>1)
  • 69. 条件覆盖条件覆盖就是设计若干个测试用例,运行被测程序,使得程序中每个判断的每个条件的可能取值至少执行一次。 在图例中,我们事先可对所有条件的取值加以标记。例如, 对于第一个判断: 条件 A>1 取真为 ,取假为 条件 B=0 取真为 ,取假为
  • 70. 对于第二个判断: 条件A=2 取真为 ,取假为 条件X>1 取真为 ,取假为 测试用例 覆盖分支 条件取值 【(2, 0, 4),(2, 0, 3)】 L1(c, e) 【(1, 0, 1),(1, 0, 1)】 L2(b, d) 【(2, 1, 1),(2, 1, 2)】 L3(b, e) 或
  • 71. 测 试 用 例 覆盖分支 条件取值 【(1, 0, 3),(1, 0, 4)】 L3(b, e) 【(2, 1, 1),(2, 1, 2)】 L3(b, e) 判定-条件覆盖 判定-条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次,每个判断中的每个分支至少执行一次。
  • 72. 测 试 用 例 覆盖分支 条件取值 【(2, 0, 4),(2, 0, 3)】L1(c, e) 【(1, 1, 1),(1, 1, 1)】L2(b, d) (A=2) and (B=0) or (A>1) and (B=0) and (X/A>1) not (A>1) and not (A=2) and not (X>1) or not (B=0) and not (A=2) and not (X>1)
  • 73. 判定—条件覆盖从表面上看测试了所有条件的取值,但实际某些条件掩盖了另一些条件。 例如:对表达式(A>1)and(B=0)来说,若(A>1)的测试结果为真,则还要测试(B=0),才能决定表达式的值;而若(A>1)的测试结果为假,可立刻确定表达式的结果为假。这时就不再测试(B=0),因此条件(B=0)就没有被检查,因此采用判定-条件覆盖,逻辑表达式的错误不一定能检查出来。
  • 74. andorA>1TB=0TX=X/ATFFA=2TFX>1FX=X+1
  • 75. 条件组合覆盖条件组合覆盖就是设计足够的测试用例,运行被测程序,使得每个判断的所有可能的条件取值组合至少执行一次。 记 ① A>1, B=0 作 ② A>1, B≠0 作 ③ A≯1, B=0 作 ④ A≯1, B≠0 作
  • 76. ⑤ A=2, X>1 作 ⑥ A=2, X≯1 作 ⑦ A≠2, X>1 作 ⑧ A≠2, X≯1 作 测 试 用 例 覆盖条件 覆盖组合 【(2, 0, 4), (2, 0, 3)】(L1) ①, ⑤ 【(2, 1, 1), (2, 1, 2)】(L3) ②, ⑥ 【(1, 0, 3), (1, 0, 4)】(L3) ③, ⑦ 【(1, 1, 1), (1, 1, 1)】(L2) ④, ⑧
  • 77. 条件组合覆盖测试也并不完全,有可能漏掉某些路径。
  • 78. 路径测试路径测试就是设计足够的测试用例,覆盖程序中所有可能的路径。 1、程序图(Program Graph)
  • 79. 1、程序图(Program Graph) 的优化 ① 顺序执行的多个结点,可合并成一个结点。
  • 80. A≥BQ② 含有复合条件的判断框,可分解成几个简单条件的判定框PA>BQPA=BP
  • 81. 路径测试的特征 路径测试,就是对程序图中每一条可能的程序执行路径至少测试一次。如果程序中含有循环,则每个循环至少执行一次。 满足结构测试的最低要求。 语句覆盖又称点覆盖。 判定覆盖又称边覆盖。 满足语句覆盖和判定覆盖为完全覆盖。 满足路径覆盖,就满足完全覆盖,也就是满足了白盒测试的最低要求。
  • 82. 例如: 2134abcde测试路径覆盖结点/边覆盖标准acd①,②,③,④点覆盖acd, bea, b, c, d, e边覆盖acd, be ae, bcd①,②,③,④ a, b, c, d, e路径覆盖
  • 83. 循环测试路径选择循环分为4种不同类型:简单循环、嵌套循环、连锁循环和非结构循环。 (1) 简单循环 ① 零次循环:从循环入口到出口 ② 一次循环:检查循环初始值 ③ 二次循环:检查多次循环 ④ m次循环: 检查在多次循环 ⑤ 最大次数循环、比最大次数多一次、少一次的循环。
  • 84. ① 对最内层循环做简单循环的全部测试。所有其它层的循环变量置为最小值; ② 逐步外推,对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值,所有其它嵌套内层循环的循环变量取“典型”值。。 ③ 反复进行,直到所有各层循环测试完毕。(2) 嵌套循环
  • 85. (本页无文本内容)
  • 86. ④ 对全部各层循环同时取最小循环次 数,或者同时取最大循环次数 (3) 连锁循环 如果各个循环互相独立,则可以用与简单循环相同的方法进行测试。但如果几个循环不是互相独立的,则需要使用测试嵌套循环的办法来处理。 (4) 非结构循环 这一类循环应该使用结构化程序设计方法重新设计测试用例。
  • 87. 测试用例设计黑盒测试用例设计: 现有以下的三角形分类程序。该程序的功能是,读入代表三角形边长的3个整数,判断它们能否组成三角形。如果能够,则输出三角形是等边、等腰或任意三角形的分类信息。
  • 88. A
  • 89. aikjbcdfemptqnS123456910711812Ewghlr程序图
  • 90. 第一步:确定测试策略。 ① 判断是否组成三角形 ② 识别等边三角形 ③ 识别等腰三角形 ④ 识别任意三角形 第二步:用黑盒法设计输入 ① 用等价类法划分有效和无效等价类 ② 用边界值法和③猜错法作补充
  • 91. 有效等价类 输入三个正整数: 3 数相等 ① A、B相等② 3 数中2数相等 B、C相等③ C、A相等④ 3 数均不相等 ⑤ 最大数为 A ⑥ 2 数之和不大于第3数 最大数为 B ⑦  最大数为 B ⑧ 边界值:2数之和等于第3数 ⒁ 猜错法:输入3个零⒂      输入3个负数⒃等价分类法无效等价类 含有零数据⑼ 含有负整数⑽ 少于3 个整数⑾ 含有非整数⑿ 含有非数字符⒀
  • 92. 第三步:提出一组初步的测试用例序号测试内容测试数据期望结果abc1等边5, 5, 5等边三角形2等腰4, 4, 55, 4, 44, 5, 4等腰三角形3任意3, 4, 5任意三角形4非三角形9, 4, 44, 9, 44, 4, 95退化三角形8, 4, 44, 8, 44, 4, 86零数据0, 4, 54, 0, 54, 5, 0不是三角形70, 0, 08负数据-3, 4, 53, -4, 53, 4, -59-3, -4, -510遗漏数据3, 4, 运行错误11非整数3.3, 4, 512非数字符A, 4, 5(类型不符)
  • 93. 测试用例设计白盒测试用例设计: 学生成绩查询程序。存放100个学生的成绩,按学号排序。如果输入的学号在这批学生内,就输出该学生的成绩,否则便回答“学号没有找到”。 ① 程序由内外两层循环嵌套而成 ② 键入学号为“0”,结束查找 ③ 内层循环执行“折半查找”
  • 94. INTEGER first, last, middle, Studntno, num DIMENSION studntno(100), score(100) Read (*, *) k Read (*, *) (studntno(i), score(i), i=1, k) Read (*, *) num Do 30, While (num .NE. 0) First=1 last=k middle=(first+last)/2 IF (num .EQ. Studno(middle) .OR. First .EQ. Last) GOTO 20 10 IF (num .LT. Studntno(middle)) Then last=middle
  • 95. Else first=middle+1 EndIF middle=(first+last)/2 GOTO 10 20 CONTINUE IF (num .EQ. Studntno(middle)) Then Write(*,’(1X,’student number’,I6,2X,’score=‘, I3)’) num, score(middle) Else Write(*,’(1X,’student number’,I6,2X,’not found,’)’) num EndIF Read(*, *) num 30 CONTINUE END
  • 96. 调整first开始num<>()查找结束?在上半部分?TF调整last读入成绩表 读入numFirst,last, Middle 赋初值F内T重算middleTF123外
  • 97. 印出“未找到”结束找到所查学号?打印分数读入下一个numTF123
  • 98. abcdfe12345697108gh程序图qmnjki
  • 99. 第一步:确定测试策略。 折半查找是实现查找的一种算法。用路径覆盖作为测试策略 第二步:令成绩表的长度为1项和5项,在成绩表的不同位置查1±1个学生情况: ①成绩表只有1项,查0个学生 ②成绩表只有1项,查1个在成绩表中的学生 ③成绩表只有1项,查2个都不在成绩表中的学生 ④成绩表只有5项,查1个学生(正好是表的中间项) ⑤成绩表只有5项,查1个学生(在表的上半部分) ⑥成绩表只有5项,查1个学生(在表的下半部分) ⑦成绩表只有5项,查1个学生(不是表中的学生)
  • 100. 测试数据覆盖的结点 ①②③④⑤⑥⑦⑧⑨⑩测试数据 a b c d e f g h I j k l m n qK=1, studntno={100} Num={0} ={100, 0} ={90, 110, 0} K=5, studntno={2,4,6,8,10} Num={6, 0} {2, 0} {8, 0} {9, 0} √√ √ √√√√ √√√ √√√√√ √√√ √√√√ √√√ √√√√√√√√√√ √√√√√√√√√√√√√√√√√√√√ √√ √ √√√√ √ √ √√ √√√√ √ √√√ √√√√ √ √ √√ √√√√√√√ √√ √ √√ √√√√√√ √√√ √ √√ √√√√√√ √√ √ √√√
  • 101. 调试的步骤(1) 从错误的外部表现形式入手,确定程序中出错位置; (2) 研究有关部分的程序,找出错误的内在原因; (3) 修改设计和代码,以排除这个错误; (4) 重复进行暴露了这个错误的原始测试或某些有关测试。
  • 102. 从技术角度来看,查找错误的难度在于: 现象与原因所处的位置可能相距甚远。 当其它错误得到纠正时,这一错误所表现出的现象可能会暂时消失,但并未实际排除。 现象实际上是由一些非错误原因(例如,舍入不精确)引起的。
  • 103. 现象可能是由于一些不容易发现的人为错误引起的。 错误是由于时序问题引起的,与处理过程无关。 现象是由于难于精确再现的输入状态(例如,实时应用中输入顺序不确定)引起。 现象可能是周期出现的。在软、硬件结合的嵌入式系统中常常遇到。
  • 104. 纠错的策略纠错 策略试凑法正向跟踪反向跟踪(回溯法)适用于 小程序跟踪法推理法归纳推理演绎推理适用于 大、小程序
  • 105. 试凑法: 一种“边试边瞧”的做法。首先设定可疑区,然后插入打印语句,看是否可以发现错误。 跟踪法: 跟踪执行可疑的程序段,实行单步执行,每执行完一条语句,就停下来检查执行的结果,确认正常后再继续执行,是对小型程序纠错的常用策略。 如:For i:=1 to 10 ix=iy/(k\n) (其中k=5, n=6)
  • 106. 归纳法调试 归纳法是一种从特殊推断一般的系统化思考方法。归纳法调试的基本思想是:从一些线索(错误征兆)着手,通过分析它们之间的关系来找出错误。 收集有关的数据 列出所有已知的测试用例和程序执行结果。看哪些输入数据的运行结果是正确的,哪些输入数据的运行结果有错误。
  • 107. 组织数据 由于归纳法是从特殊到一般的推断 过程,所以需要组织整理数据,以 发现规律。 常以3W1H形式组织可用的数据: “What” 列出一般现象; “Where”说明发现现象的地点; “When” 列出现象发生时所有已知情况; “How” 说明现象的范围和量级;
  • 108. (本页无文本内容)
  • 109. “Yes”描述出现错误的3W1H; “No”作为比较,描述了没有错误的3W1H。通过分析找出矛盾来。 提出假设 分析线索之间的关系,利用在线索结构中观察到的矛盾现象,设计一个或多个关于出错原因的假设。如果一个假设也提不出来,归纳过程就需要收集更多的数据。此时,应当再设计与执行一些测试用例,以获得更多的数据。
  • 110. 证明假设 把假设与原始线索或数据进行比较,若它能完全解释一切现象,则假设得到证明;否则,就认为假设不合理,或不完全,或是存在多个错误,以致只能消除部分错误。
  • 111. 开始提出假 想错误能测试纠错收集错 误症状归纳症状不能证明假 想错误找到真 实错误结束能不能归纳纠错法
  • 112. 演绎法调试 演绎法是一种从一般原理或前提出发,经过排除和精化的过程来推导出结论的思考方法。演绎法排错是测试人员首先根据已有的测试用例,设想及枚举出所有可能出错的原因做为假设;然后再用原始测试数据或新的测试,从中逐个排除不可能正确的假设;最后,再用测试数据验证余下的假设确是出错的原因。
  • 113. 列举所有可能出错原因的假设 把所有可能的错误原因列成表。通过它们,可以组织、分析现有数据。 利用已有的测试数据,排除不正确的假设 仔细分析已有的数据,寻找矛盾,力求排除前一步列出所有原因。如果所有原因都被排除了,则需要补充一些数据(测试用例),以建立新的假设。
  • 114. 改进余下的假设 利用已知的线索,进一步改进余下的假设,使之更具体化,以便可以精确地确定出错位置。 证明余下的假设
  • 115. 演绎纠错法开始有余下 病因?有测试纠错罗列可能 的病因排除矛盾的病因无能证实病因确定真 实病因结束能不能
  • 116. 1、插入打印语句 Sum=0 : score=0 : num=0 While score<>999 Input ‘score=‘; score sum=sum+score num=num+1 Wend average=sum/num Print average 90 End常用的纠错技术
  • 117. 在程序中插入打印语句 Print num, score, sum Score=70 1 70 70 Score=80 2 80 150 Score=90 3 90 240 Score=999 4 999 1239 309.75
  • 118. 2、设置断点 在程序的可疑区设置断点,每当程序执行到设置的断点时,就会暂停执行,以便观察变量的内容和分析程序的运行状况。 Dim a(5) For i=1 to 10 let a(i)=I Next I End 常用的纠错技术
  • 119. 3、隐蔽部分程序 把不需要检查的程序隐蔽起来,只让可疑的部分程序反复运行。 可使用如下方法隐蔽程序: ①在要隐蔽的程序前加注释符,变成注释语句。 ②把要隐蔽的程序段置于“常假”的选择结构中,使它总没机会执行。 ③用GOTO语句跳过要隐蔽的程序段。
  • 120. 4、蛮力纠错技术 打印或转存可疑区的全部数据,供纠错者使用。 优点:信息齐全,只要有耐心,一定能找出错误。 缺点:数据量大,效率低。
  • 121. 多模块程序测试的策略测试过程按4个步骤进行,即单元测试、组装测试、确认测试和系统测试。 开始是单元测试,集中对用源代码实现的每一个程序单元进行测试,检查各个程序模块是否正确地实现了规定的功能。
  • 122. (本页无文本内容)
  • 123. 组装测试把已测试过的模块组装起来,主要对与设计相关的软件体系结构的构造进行测试。 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求,以及软件配置是否完全、正确。 系统测试把已经经过确认的软件纳入实际运行环境中,与其它系统成份组合在一起进行测试。
  • 124. 程序错误的类型语法错误 编译是发现语法错误的最好工具,应注意一处语法错误会产生多条错误信息,只要改正该错误,所有错误信息就可能全部消失。 结构性错误 包括结构异常、结构不全和结构多余等错误。
  • 125. 开始y<0Tx←x+yRead y结束Fx←yy>0Tx ← yRead yFx < 0TFx未赋初值就引用x变量未使用该路径永远不会执行结构性错误:
  • 126. 功能性错误 指程序功能与用户需求不相符合引起的错误。 功能性错误主要靠动态测试来发现。 发现错误的时间越早越好。 接口错误 调用函数和子程序时,实参和形参的类型、个数及顺序不一致。 全局变量引用不当。 集成测试的重点是检测接口错误。
  • 127. 单元测试 (Unit Testing)单元测试又称模块测试,是针对软件设计的最小单位 ─ 程序模块,进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
  • 128. 1、测试内容模块模块接口测试局部数据结构测试重要路径测试错误处理测试边界条件测试I/O 参数值的个数、类型、次序、格式是否正确,I/O文件属性、操作是否正确等。数据说明是否正确、一致,变量及其初值定义是否正确等。检查“错误处理程序”本身的错误。边界条件常包括循环边界,最大最小值、控制流中等于、大于、小于的比较值等。重要路径通常是指完成模块功能的主要路径,一般是控制结构。单元测试(unit testing )
  • 129. 单元测试的步骤编译 静态分析器检查 代码评审 动态测试 编译 编译程序检查代码中的语法错误。 静态分析器 以检查结构性错误为主,节省人力。 代码评审 办公桌检查 走查 代码会审
  • 130. 1. 桌前检查(Desk Checking) 这是一种传统的检查方法。由程序员自己检查自己编写的程序。程序员在程序通过编译之后,进行单元测试设计之前,对源程序代码进行分析,检验,并补充相关的文档,目的是发现程序中的错误。检查项目有: (1)检查变量的交叉引用表──重点是检查未说明的变量和违反了类型规定的变量;还要对照源程序,逐个检查变量的引用、变量的使用序列;临时变量在某条路径上的重写情况;局部变量、全局变量与特权变量的使用; (2)检查标号的交叉引用表──验证所有标号的正确性:检查所有标号的命名是否正确;转向指定位置的标号是否正确。 (3)检查子程序、宏、函数──验证每次调用与被调用位置是否正确;确认每次被调用的子程序、宏、函数是否存在;检验调用序列中调用方式与参数顺序、个数、类型上的一致性。
  • 131. (4)等值性检查──检查全部等价变量的类型的一致性,解释所包含的类型差异。 (5)常量检查──确认每个常量的取值和数制、数据类型;检查常量每次引用同它的取值、数制和类型的一致性; (6)标准检查──用标准检查程序或手工检查程序中违反标准的问题。 (7)风格检查──检查在程序设计风格方面发现的问题。 (8)比较控制流──比较由程序员设计的控制流图和由实际程序生成的控制流图,寻找和解释每个差异,修改文档和校正错误。 (9)选择、激活路径──在程序员设计的控制流图上选择路径,再到实际的控制流图上激活这条路径。如果选择的路径在实际控制流图上不能激活,则源程序可能有错。用这种方法激活的路径集合应保证源程序模块的每行代码都被检查,即桌前检查应完成至少是语句覆盖。 (10)对照程序的规格说明,详细阅读源代码── 程序员对照程序的规格说明书、规定的算法和程序设计语言的语法规则,仔细地阅读源代码,逐字逐句进行分析和思考,比较实际的代码和期望的代码,从它们的差异中发现程序的问题和错误。
  • 132. (11)补充文档── 桌前检查的文档是一种过渡性的文档,不是公开的正式文档。通过编写文档,也是对程序的一种下意识的检查和测试,可以帮助程序员发现和抓住更多的错误。管理部门也可以通过审查桌前检查文档,了解模块的质量、完全性、测试方法和程序员的能力。这种文档的主要内容有: ·建立小型的数据词典,描述程序中出现的每一种数据结构、变量和寄存器的用法,建立相应的各种交叉引用表格。 ·描述主要的路径和异常的路径,为覆盖准备条件。 ·当测试采用逻辑驱动时,即利用判定表或布尔代数方法来确定逻辑覆盖时,应讨论逻辑情况。此外,在状态测试情形,即考虑模块中状态的组合和状态的迁移时对状态控制变量进行设计,以及利用语法制导的测试,也都要讨论逻辑情况。要使文档编制适应测试技术。 ·以纯粹的功能术语来描述输入与输出。 ·描述全部已知的限制和假定。 ·描述全部的接口和对接口的假定。 这种桌前检查,由于程序员熟悉自己的程序和自身的程序设计风格,可以节省很多的检查时间,但应避免主观片面性。
  • 133. 2. 代码会审(Code Reading Review) 代码会审是由若干程序员和测试员组成一个会审小组,通过阅读、讨论和争议,对程序进行静态分析的过程。 代码会审分两步:第一步,小组负责人提前把设计规格说明书、控制流程图、程序文本及有关要求、规范等分发给小组成员,作为评审的依据。小组成员在充分阅读这些材料之后,进入审查的第二步:召开程序审查会。在会上,首先由程序员逐句讲解程序的逻辑。在此过程中,程序员或其他小组成员可以提出问题,展开讨论,审查错误是否存在。实践表明,程序员在讲解过程中能发现许多原来自己没有发现的错误,而讨论和争议则促进了问题的暴露。例如对某个局部性小问题修改方法的讨论,可能发现与之牵连的其它问题,甚至涉及到模块的功能说明、模块间接口和系统总体结构的大问题,从而导致对需求的重定义、重设计和重验证,进而大大改善了软件质量。
  • 134. 在会前,应当给会审小组每个成员准备一份常见错误的清单,把以往所有可能发生的常见错误罗列出来,供与会者对照检查,以提高会审的实效。 这个常见错误清单也叫做检查表,它把程序中可能发生的各种错误进行分类,对每一类列举出尽可能多的典型错误,然后把它们制成表格,供在会审时使用。这种检查表类似于本章单元测试中给出的检查表。在代码会审之后,需要做以下几件事: ① 把发现的错误登记造表,并交给程序员; ② 若发现错误较多,或发现重大错误,则在改正之后,再次组织代码会审; ③ 对错误登记表进行分析、归类、精炼,以提高审议效果。
  • 135. 3. 走查(Walkthroughs)走查与代码会审基本相同,其过程分为两步。 第一步也把材料先发给走查小组每个成员,让他们认真研究程序,然后再开会。开会的程序与代码会审不同,不是简单地读程序和对照错误检查表进行检查,而是让与会者“充当”计算机。即首先由测试组成员为被测程序准备一批有代表性的测试用例,提交给走查小组。走查小组开会,集体扮演计算机角色,让测试用例沿程序的逻辑运行一遍,随时记录程序的踪迹,供分析和讨论用。 走查着重于从流程的角度来考察程序,借助于程序流程图来进行数据流和控制流的分析。
  • 136. (本页无文本内容)
  • 137. 2. 驱动模块和桩模块模块并不是一个独立的程序,在考虑测试模块时,同时要考虑它和外界的联系,用一些辅助模块去模拟与被测模块相联系的其它模块。 驱动模块 (driver) 桩模块 (stub) ── 存根模块
  • 138. (本页无文本内容)
  • 139. 2、模块测试步骤 考虑到被测模块与其它模块的联系,因此测试时需要使用两类辅助模块来模拟其他模块。 驱动模块(driver)— 模拟主程序功能,用于向被测模块传递数据,接收、打印从被测模块返回的数据。 桩模块(stub)— 又称为假模块,用于模拟那些由被测模块所调用的下属模块功能。 一般,驱动模块比桩模块容易设计。但都是额外开销。测试方法以白盒法为主。被测模块驱动模块桩模块桩模块桩模块
  • 140. 集成测试(Integrated Testing)集成测试 (组装测试、联合测试) 通常,在单元测试的基础上,需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是: 在把各个模块连接起来的时侯,穿越模块接口的数据是否会丢失; 一个模块的功能是否会对另一个模块的功能产生不利的影响;
  • 141. 各个子功能组合起来,能否达到预期要求的父功能; 全局数据结构是否有问题; 单个模块的误差累积起来,是否会放大,从而达到不能接受的程度。 在单元测试的同时可进行组装测试, 发现并排除在模块连接中可能出现 的问题,最终构成要求的软件系统。
  • 142. 1、组装测试的任务 ①确定模块组装方案,将经过测试的模块组装为一个完整的系统。组装方案分为渐增式及非渐增式。 ②测试方法以黑盒法为主,按照组装方案进行 测试。 重点测试模块的接口部分,需设计测试过程使用的驱动模块或桩模块。问题:渐增式与非渐增式各有何优、缺点?为什么通常采用渐增式?
  • 143. 2、渐增式组装测试 渐增式是先进行模块测试,然后将这些模块逐步组装成较大的系统,每连接一个模块进行一次测试。两种方案:设计驱动模块或桩模块,对每一个新组装的子 系统进行测试,对发现问题较多的子系统或模 块应该用白盒法作回归测试。自顶而下增值 自底而上增值
  • 144. 自顶而下增值M1M4M3M2M6M5程序模块示意图S5M1S1S1S1S2S2S2S3S3S3第一步,测试主控模块M1设计桩模块S1、S2、S3,模拟被M1调用的M2、M3、M4。第二步,依次用M2、M3、M4替代桩模块S1、S2、S3,每替代一次进行一次测试。S4S4S4S5S5第三步,对由主控模块M1和模块M2、M3、M4构成的子系统进行测试,设计桩模块S4、S5。第四步,依次用模块M5和M6替代桩模块S4、S5,并同时进行新的测试。组装测试完毕。
  • 145. 自底而上增值M3M6M5D1D2D3D1D1D2D2D3D3M2M4M1第四步,把已测试的子系统按程序结构连接起来完成程序整体的组装测试。D4D4D4D5D5D5M1M4M3M2M6M5程序模块示意图第一步,对最底层的模块M3、M5、M6进行测试,设计驱动模块D1、D2、D3来模拟调用。第三步,设计驱动模块D4、D5 和D6模拟调用,分别对新子系统进行测试。第二步,用实际模块M2、M1和M4替换驱动模块D1、D2、D3。D6
  • 146. 深度优先与宽度优先 无论是自顶而下增值还是自底而上增值,还可选择 深度优先或者宽度优先增值。举例:按自顶而下增值法,写出下图中分别按照深度优先或者宽度优先增值的模块组装次序。 ABCDHGJEFIKLMN
  • 147. 问 题 (1)自顶而下增值与自底而上增值各有何优、缺点? (2)为什么在实际的组装测试中,都应该采用混合增值的方法? (3)请自己设计 2-3个混合增值的测试方法。
  • 148. 确定集成过程的原则 自顶而下增值 优点:能够尽早发现系统主控方面的问题。 缺点:无法验证桩模块是否完全模拟了下属模块的功能。 自底而上增值 优点:驱动模块较容易编写桩模块,能够尽早查出底层涉及较复杂的算法和实际的I/O模块中的错误。 缺点:最后才能发现系统主控方面的问题。
  • 149. 集成过程的原则① 尽早测试关键模块。 ② 尽早测试包含I/O的模块。
  • 150. 3、混合增值常见的混合增值方案: 衍变的自顶而下 先自底而上集成子系统,再自顶而下集成总系统。自底而上—自顶而下增值 对含有读操作的子系统采用自底而上。 对含有写操作的子系统采用自顶而下。 回归测试 在回归测试中自底而上,对其余部分(尤其是对修改过的子系统)采用自顶而下。
  • 151. 1. 一次性组装方式 (big bang)它是一种非增殖式组装方式。也叫做整体拼装。 使用这种方式,首先对每个模块分别进行模块测试,然后再把所有模块组装在一起进行测试,最终得到要求的软件系统。
  • 152. (本页无文本内容)
  • 153. 2. 增殖式组装方式这种组装方式又称渐增式组装 首先对一个个模块进行模块测试,然后将这些模块逐步组装成较大的系统 在组装的过程中边连接边测试,以发现连接过程中产生的问题 通过增殖逐步组装成为要求的软件系统。
  • 154. (1) 自顶向下的增殖方式这种组装方式将模块按系统程序结构,沿控制层次自顶向下进行组装。 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。 选用按深度方向组装的方式,可以首先实现和验证一个完整的软件功能。
  • 155. (本页无文本内容)
  • 156. (2) 自底向上的增殖方式这种组装的方式是从程序模块结构的最底层的模块开始组装和测试。 因为模块是自底向上进行组装,对于一个给定层次的模块,它的子模块(包括子模块的所有下属模块)已经组装并测试完成,所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
  • 157. 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。 一般来讲,一种方式的优点是另一种方式的缺点。
  • 158. (3) 混合增殖式测试衍变的自顶向下的增殖测试 首先对输入/输出模块和引入新算法模块进行测试; 再自底向上组装成为功能相当完整且相对独立的子系统; 然后由主模块开始自顶向下进行增殖测试。
  • 159. 自底向上自顶向下的增殖测试 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试; 然后对含写操作的子系统做自顶向下的组装与测试。 回归测试 这种方式采取自顶向下的方式测试被修改的模块及其子模块; 然后将这一部分视为子系统,再自底向上测试。
  • 160. 关键模块问题在组装测试时,应当确定关键模块,对这些关键模块及早进行测试。 关键模块的特征: ① 满足某些软件需求; ② 在程序的模块结构中位于较高的层次(高层控制模块); ③ 较复杂、较易发生错误; ④ 有明确定义的性能要求。
  • 161. 确认测试(Validation Testing)确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
  • 162. (本页无文本内容)
  • 163. 1. 进行有效性测试(黑盒测试)有效性测试是在模拟的环境 (可能就是开发的环境) 下,运用黑盒测试的方法,验证被测软件是否满足需求规格说明书列出的需求。 首先制定测试计划,规定要做测试的种类。还需要制定一组测试步骤,描述具体的测试用例。
  • 164. 通过实施预定的测试计划和测试步骤,确定 软件的特性是否与需求相符; 所有的文档都是正确且便于使用; 同时,对其它软件需求,例如可移植性、兼容性、出错自动恢复、可维护性等,也都要进行测试
  • 165. 在全部软件测试的测试用例运行完后,所有的测试结果可以分为两类: 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合,从而这部分程序被接受。 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致,因此要为它提交一份问题报告。
  • 166. 2. 软件配置复查 软件配置复查的目的是保证 软件配置的所有成分都齐全; 各方面的质量都符合要求; 具有维护阶段所必需的细节; 而且已经编排好分类的目录。 应当严格遵守用户手册和操作手册中规定的使用步骤,以便检查这些文档资料的完整性和正确性。
  • 167. 验收测试(Acceptance Testing)在通过了系统的有效性测试及软件配置审查之后,就应开始系统的验收测试。 验收测试是以用户为主的测试。软件开发人员和QA(质量保证)人员也应参加。 由用户参加设计测试用例,使用生产中的实际数据进行测试。
  • 168. 在测试过程中,除了考虑软件的功能和性能外,还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。 确认测试应交付的文档有: 确认测试分析报告 最终的用户手册和操作手册 项目开发总结报告。
  • 169. 系统测试(System Testing)系统测试,是将通过确认测试的软件,作为整个基于计算机系统的一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起,在实际运行环境下,对计算机系统进行一系列的组装测试和确认测试。 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
  • 170. 常见系统测试类型恢复测试 系统出错时,能否在指定时间内修正错误并重新启动。 安全性测试 检查系统对非法侵入的防范能力。 强度测试 检查程序对不正常情况的承受能力。 性能测试 保证系统的性能,有时与强度测试同时进行。
  • 171. α测试和β测试在软件交付使用之后,用户将如何实际使用程序,对于开发者来说是无法预测的。 α测试是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。
  • 172. α测试的目的是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。尤其注重产品的界面和特色。 α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。
  • 173. β测试是由软件的多个用户在实际使用环境下进行的测试。这些用户返回有关错误信息给开发者。 测试时,开发者通常不在测试现场。因而,β测试是在开发者无法控制的环境下进行的软件现场应用。 在β测试中,由用户记下遇到的所有问题,包括真实的以及主观认定的,定期向开发者报告。
  • 174. β测试主要衡量产品的FLURPS。着重于产品的支持性,包括文档、客户培训和支持产品生产能力。 只有当α测试达到一定的可靠程度时,才能开始β测试。它处在整个测试的最后阶段。同时,产品的所有手册文本也应该在此阶段完全定稿。
  • 175. 面向对象系统的测试随着OO技术的成熟,复用的软件不断增加,可是OO软件系统的测试不但没有减少,反而有所增加。 OO 测试应扩展到OOA和OOD阶段,以便及早发现错误。 由于OO软件是基于类/对象的,也增加了测试的复杂性。
  • 176. 面向对象软件的测试策略单元测试 (类测试) 在面向对象环境下,最小的可测试的单元是封装了的类或对象,而不是程序模块。 面向对象软件的类测试等价于传统软件开发方法中的单元测试。但它是由类中封装的操作和和类的状态行为驱动的。 完全孤立地测试类的各个操作是不行的。
  • 177. 考虑一个类的层次。在基类中我们定义了一个操作X。 每一个派生类都使用操作X,它是在各个类所定义的私有属性和操作的环境中使用的。因使用操作X的环境变化太大,所以必须在每一个派生类的环境下都测试操作X。 在面向对象开发环境下,把操作完全孤立起来进行测试,其收效是很小的。
  • 178. 集成测试 因为面向对象软件没有一个层次的控制结构,所以传统的自顶向下和自底向上的组装策略意义不大。 每次将一个操作组装到类中(像传统的增殖式组装那样)常常行不通,因为在构成类的各个部件之间存在各种直接的和非直接的交互。 对于面向对象系统的组装测试,存在两种不同的测试策略。
  • 179. 基于线程测试 (Thread-based Test) 它把为响应某一系统输入或事件所需的一组类组装在一起。每一条线程将分别测试和组装。 基于使用的测试 (Use-based Test) 它着眼于系统结构,首先测试独立类,这些类只使用很少的服务器类。再测试那些使用了独立类的相关类。一系列测试各层相关类的活动继续下去,直到整个系统构造完成。
  • 180. 确认测试 在进行确认测试和系统测试时,不关心类之间连接的细节。着眼于用户的要求和用户能够认可的系统输出。 为了帮助确认测试的执行,测试者需要回到分析模型OOA阶段,根据那里提供的事件序列(脚本)进行测试。 可以利用黑盒测试的方法来驱动确认测试。
  • 181. 系统测试 系统测试应该尽量搭建与用户使用环境相同的测试平台。 应该保证被测系统的完整性,对临时没有的系统设备部件,也应有响应的模拟手段。 应参考OOA的分析结果,检测软件是否能够完全“再现”问题空间。
  • 182. 面向对象软件测试用例设计OO概念对测试用例设计的影响 测试要检查数据成员是否满足封装的要求。 继承的成员函数需要测试(子类和父类所处的环境不同) 子类的测试用例可以参照父类用例 类测试用例的设计 基于故障的测试用例设计 基于用例的测试用例设计 类间测试用例设计
  • 183. 基于故障的测试用例设计 通过对OOA/OOD模型的分析,找出可能存在的故障,并以此故障设计测试用例的方法。 缺点:不能发现由错误的功能描述或子系统间交互引起的问题 基于用例的测试用例设计 关心用户做什么而不是软件做什么,它通过用例捕获用户必须完成什么任务,并以此为依据设计所涉及的各个类的测试用例。