第二测试技术.ppt
《第二测试技术.ppt》由会员分享,可在线阅读,更多相关《第二测试技术.ppt(109页珍藏版)》请在三一文库上搜索。
1、第二章 测试技术,第一节 简介 第二节 软件测试准则 第三节 软件测试的实际经验与常识 第四节 软件测试方法 第五节 软件测试的各个阶段 第六节 测试问题的分类和比较,定义软件测试 明确软件测试的准则 明确测试的方法* 描述软件测试的各个阶段 描述各个阶段中的测试内容,本章目标,回 顾,软件质量的衡量标准是可以准时地交付给用户,所耗费的 成本不超出预算,并且最重要的是,能够正常地运行 SQA 的目标是通过在开发周期的早期阶段发现错误来降低 解决问题的成本 SQA 应用于软件开发的每个阶段,每个阶段都有其自己的 质量标准 实施质量管理中,要注意构建自己的管理体系,包括:构 建质量计划、建立质量保
2、证、建立质量控制等,第一节 简介,软件测试( why、 what、who、 where、when 、 how?) 软件测试是软件工程过程中的关键组件 软件测试是软件质量保证的要素,可以将其描述为一个 运行程序以检测错误(如果有)的过程,编程大师说:没有错误的程序世间难求(编程之道) 你在学校里学过测试吗?(读到博士可能也不懂测试) 你所在的企业重视测试吗?(小公司程序员的技能更加 全面) 临时抱佛脚行吗?你以为有文档模板就会测试了吗? 软件测试就是调试?,第二节 软件测试准则,如果不懂得有效地进行测试,你不仅得不到功劳, 也没人欣赏你的苦劳,你拥有最多的将只是疲劳 职业软件工程师应当掌握需求开
3、发、系统设计、编 程、测试、维护 所有技能,测试的目的,著名软件测试专家迈尔斯(Grenford J. Myers)在软 件测试技巧一书中,就系统测试目的提出以下观点: 测试是为了发现错误而执行程序的过程; 测试是为了证明程序有错,而不是证明程序无错误; 一个好的测试用例,在于能够发现至今未能发现的错误; 一个成功的测试是发现了至今未发现过的错误,测试的目的是为了发现尽可能多的缺陷,不是为了说明 软件中没有缺陷 推论:成功的测试在于发现了迄今尚未发现的缺陷。所 以测试人员的职责是设计这样的测试用例,它能有效地 揭示潜伏在软件里的缺陷 千万不要将“测试”与“演示”混为一谈。例如科研鉴定会 如果产
4、品通过了严格的测试,大家不要不吭气,应当好 好地宣传一把,软件测试原则,应当把“尽早地和不断地进行软件测试”作为软件开发 者的座右铭。不应把软件测试仅仅看作是软件开发的一 个独立阶段,而应当把它贯穿到软件开发的各个阶段中。 坚持在软件开发的各个阶段的技术评审,这样才能在开 发过程中尽早发现和预防错误,把出现的错误克服在早 期,杜绝某些发生错误的隐患 测试用例应由测试输入数据和与之对应的预期输出结果 这两部分组成。测试以前应当根据测试的要求选择测试 用例(Test case),用来检验程序员编制的程序,因此 不但需要测试的输入数据,而且需要针对这些输入数据 的预期输出结果,程序员应避免测试自己的
5、程序。程序员应尽可能避免测 试自己编写的程序,程序开发小组也应尽可能避免测试 本小组开发的程序。如果条件允许,最好建立独立的软 件测试小组或测试机构。这点不能与程序的调试 (debuging)相混淆。调试由程序员自己来做更有效 在设计测试用例时,应当包括合理的输入条件和不合理 的输入条件。合理的输入条件是指能验证程序正确的输 入条件,不合理的输入条件是指异常的、临界的,可能 引起问题异变的输入条件。软件系统处理非法命令的能 力必须在测试时受到检验。用不合理的输入条件测试程 序时,往往比用合理的输入条件进行测试能发现更多的 错误,充分注意测试中的群集现象。在被测程序段中,若发现 错误数目多,则残
6、存错误数目也比较多。这种错误群集 性现象,已为许多程序的测试实践所证实。根据这个规 律,应当对错误群集的程序段进行重点测试,以提高测 试投资的效益 严格执行测试计划,排除测试的随意性。测试之前应仔 细考虑测试的项目,对每一项测试做出周密的计划,包 括被测程序的功能、输入和输出、测试内容、进度安排、 资源要求等,应当对每一个测试结果做全面检查。有些错误的征兆在 输出实测结果时已经明显地出现了,但是如果不仔细地 全面地检查测试结果,就会使这些错误被遗漏掉 妥善保存测试计划,测试用例,出错统计和最终分析报 告。按照测试计划要求,将所有测试过程进行详细记录, 并将测试文档资料完整保存,以便在以后的系统
7、维护中 查阅,完全测试程序是不可能的: 输入量太大 输出结果太多 软件实现途径太多 软件说明书没有客观标准。从不同角度看,软件缺陷的 标准不同 例如:WINDOWS自带的计算器,软件测试准则,软件测试是有风险的行为 测试主要原则:把无穷的可能减少到可以控制的范围, 如何针对风险制订出明确选择,去粗取精 测试无法显示潜伏的软件缺陷 唯一的方法:继续测试,可能还会找到一些 找到的软件缺陷越多,就说明软件缺陷越多 程序员倦怠 程序员往往犯同样的错误 某些软件缺陷其实是大灾难的征兆,并非所有软件缺陷都能修复 项目小组需要对一个软件缺陷进行取舍,根据风险决定 哪些修复,哪些不要 软件测试一项讲究条理的技
8、术专业 这将成为一个有前途的职业:需要训练、规范,在测试过程中一般把发现的错误按其严重性分为4类: 致命错误(系统崩溃或挂起、破坏数据) 严重错误(使系统不稳定、产生错误结果、菜单功能无 法实现) 一般错误(在完成某一功能时出现的错误,但并不影响 该功能的实现) 建议项 (软件不完善或用户使用不方便之处),软件测试应注意的问题,下面,对一些显而易见的、容易被开发者忽略的错误进 行列举和分析,这些错误一般很容易避免和修改,但会 给用户造成使用上的困难 易用性问题:用户无法使用或不方便使用 不符合用户操作习惯。如:快捷键定义不科学、不实用, 键位分布不合理、按键太多,甚至没有快捷键 界面中英文混杂
9、,界面元素参差不齐,文字显示不全 无自动安装程序或安装程序不完善 界面中的信息不能及时刷新,不能正确反映当前数据状 态,可能误导用户。如:数据库中剩余记录个数和参数 设置对话框中的预设值常常显示为历史值而不是当前值,提示信息意义不明或为原始的英文提示 要求用户输入多余的、本来系统可以自己得到的数据。 如:服务是否启动,安装后用户要手动修改某些配置文件 某一项功能的冗余操作太多。如:对话框嵌套层次太多 不能记忆用户的设置或操作习惯,用户每次进入都需要重 新操作一次初始环境 对复杂的操作无联机帮助,稳定性问题:影响用户正常工作 程序运行过程中不断申请但不完全释放资源,造成系 统性能越来越低,并出现
10、不规律的死机现象 不能重现的错误,有些与代码中的未初始化变量有关, 有些与系统不检查异常情况有关 对一般性错误的屏蔽能力较差 对输入的数据没有进行充分并且有效的有效性检查, 造成不合要求的数据进入数据库,其他问题: 用户文档问题:无标准,无新功能使用方法,无版本 改动说明。不仅要认为没有说明文档的产品不是一个 完整的产品,也要认为没有说明或没有正确说明的功 能是一个没有完全实现的功能,因为用户无法用得起来 兼容性问题:对硬件平台或软件平台的兼容性不好。 比如:在这台计算机上可以稳定运行,而在另一台上 运行就极不稳定 数据接口问题:未提供与一些常用的文件格式的接口。 如TXT文件、Word文件,
11、第三节 软件测试的实际经验与常识,测试能提高软件质量,但提高质量不能依赖测试 测试只能证明缺陷存在,不能证明缺陷不存在 测试的主要困难:不知如何有效测试,不知何时结束 开发人员应测试自己的程序,但不能当通过测试的依据 8020原则:80%缺陷聚集在20%的模块中 测试应当循序渐进,不要企图一次做完,程序 测试,静态分析 (程序不执行),动态测试 (程序执行),静态分析器分析 (自动方式),代码评审 (人工方式),黑盒测试(测试程序功能),白盒测试(测试程序结构),代码会审 代码走查 桌面检查,第四节 软件测试方法,白盒测试(开盒测试),软件测试员可以访问程序员的 代码,并通过检查代码来协助测试
12、可以看到盒子里面。 一般在单元测试中采用白盒测试,用于测试模块中所有可能 的路径、执行所有循环并测试所有逻辑表达式 使用白盒测试,软件工程师可以: 确保模块中的所有独立路径都至少测试了一次 从真和假检查所有逻辑判定 执行所有的循环并测试它们位于边界值时的操作 检查内部数据结构以确保它们的有效性,白盒测试侧重于程序细节 没有能够实现的自动工具或测试系统 白盒测试的主要方法:逻辑驱动、基路测试 例如:示例1 P19 、如图2.1,黑盒测试(功能测试)侧重软件的整体功能。 它不基于程 序的内部结构而基于系统功能。犹如一个人站在黑盒子外 面,只知道系统输入一定数据,得到一定的输出,而不必 清楚这个黑盒
13、子中进行了哪些操作和运算。如图2.2 能够发现的错误: 不正确或遗漏的功能 任何界面中的错误 数据结构或数据库中的错误 与性能和程序初始化或终止相关的错误,黑盒测试方法: 等价类划分 边界分析 因果图 猜测错误,静态检查: 审查:代码审查一般按代码审查单阅读程序,查找错 误。它以一系列典型问题为依据进行检测。分为:代 码会审、走查、桌面检查 检查代码和设计的一致性 检查代码的标准性、可读性 检查代码逻辑表达的正确性和完整性 检查代码结构的合理性等,走查:是一对一的审查,并且更加详细,找出不足, 保证读者正确理解了文档或被审查项 检查是否符合编程规范 寻找编译器中的设计陷阱 快速理解源代码,找出
14、流程设计中的问题 对原有代码的重构,回顾:发现软件的错误和缺陷,它是在软件正式执行之 前完成 功能遗漏 对需求的不恰当理解 程序本身的逻辑错误 检测程序细节:变量的命名正确、算法有效,动态检查: 动态测试是实际运行被测程序,输入相应的测试用例, 判定执行结果是否符合要求,从而检验程序的正确性、 可靠性和有效性。在生命周期中进行测试(运行)。 通常包括单元测试、集成测试、系统测试、用户的验 收测试,测试和测试: 如果软件是为多个客户开发,那么由每个客户都实施 正式的验收测试是不现实的。大多数软件产品的开发 人员采用所谓测试和测试的步骤,以便让最终用 户快速找出错误 测试是由一个用户在开发环境下进
15、行的测试,也可 以是公司内部的用户在模拟实际操作环境下进行的测 试。被测试的软件由开发人员安排在可控的环境下进 行检验,并记录发现的错误和使用中的问题,测试是由软件的多个用户在一个或多个用户的实际 使用环境下进行的测试。与测试不同的是,开发者 通常不在测试现场。因而,测试是在开发者无法控 制的环境下进行的软件现场应用。在测试中,由用 户记下遇到的所有问题,包括真实的以及主观认定的 ,定期向开发者报告,开发者在综合用户的报告之后 ,做出修改,最后将软件产品交付给全体用户使用,静态和动态测试进行结构和功能测试,测试技术,测试是不存在错误的证明,尽管有些软件经过“精心测 试”,但运行后还是不可靠 正
16、如迪杰斯特拉(Edsger W. Dijkstra)所述“测试可 能是一种表明存在错误的有效途径,但无法表明不存在 错误” 意思就是,如果一个软件用测试数据运行时输出发生错 误,则该软件必然存在着错误;但如果输出是正确的, 软件可能仍然存在错误;特定的测试只能显示软件在这 套特定的测试数据下能正确运行,测试情况设计,因此,在测试过程中,无论是采用人工测试还是计算机 辅助测试,其中最重要的问题就是设计有效的测试情况 常用的的测试情况设计方法有: 逻辑覆盖(白盒测试) 等价划分(黑盒测试) 边界分析(黑盒测试) 因果图 (黑盒测试) 猜测错误(黑盒测试),逻辑覆盖:它是对一系列测试过程的总称,它是
17、在使用 白盒测试法时,选用测试用例执行(即这里所说的覆盖) 程序逻辑路径的方法。覆盖程度由低到高分为: 语句覆盖。设计若干测试用例,使程序中每一可执行语 句至少执行一次 判断覆盖。设计用例,使程序中的每个逻辑判断的取真 取假分支至少经历一次 条件覆盖。设计用例,使判断中的每个条件的可能取值 至少满足一次,判断/条件覆盖。设计用例,使得判断中的每个条件的 所有可能结果至少出现一次,而且判断本身所有可能结 果也至少出现一次 条件组合覆盖。设计用例,使得每个判断表达式中条件 的各种可能组合都至少出现一次;显然,满足的测试 用例也一定是满足、的测试用例 路径覆盖。设计足够的测试用例,使程序的每条可能路
18、 径都至少执行一次 如果把路径覆盖和条件组合覆盖结合起来,可以设计出 检错能力更强的测试数据用例,等价类划分:它是用黑盒测试法设计测试用例的一种技 术。它是将程序(或者模块)输入定义域中的所有可能 的输入数据(含有效和无效)划分成若干个等价类,每 一类的一个代表性的数据在测试中的作用,就等价于这 一类中的所有其他数据。也就是说,如果某一类的一个 用例发现了错误,这一等价类中的所有其他用例也能发 现同样的错误,反之亦然。借以实现测试的经济性,大 大减少测试的工作量,【例7.1】某工厂公开招工,规定报名者年龄应在20周 岁至39周岁之间(到1999年6月30日止),即出生年月 不早于1960年7月
19、,不晚于1979年6月。报名程序具有自 动检验输入数据的功能。如出生年月不在上述范围内, 将拒绝接受,并显示“年龄不合格”等出错信息。试用等 价分类法设计对这一程序功能的测试用例,第一步:划分等价类。假定已知出生年月由6位数字字 符表示,前4位代表年,后2位代表月,则可以划分为3 个有效等价类,7个无效等价类,如表7-1所示,第二步:设计有效等价类需要的测试用例。表7-1中的 、等个有效等价类,可以公用一个测试用例, 例如: 测试数据 期望结果 测试范围 197011 输入有效 、,第三步:为每一无效等价类至少设计一个测试用例。本例具有个无效等价类,需要不少于个测试用例。例如 测试数据 期望结
20、果 测试范围 MAY,70 输入无效 19705 输入无效 1968011 输入无效 195512 年龄不合格 196006 年龄不合格 196200 输入无效 197222 输入无效 ,让几个有效等价类公用一个测试用例,可以减少测试次 数,有利而无弊;但若几个无效等价类合用一个测试用 例,就可能使错误漏检测。就上例而言,假定把 “195512”(对应无效等价类程序显示出“年龄不合格”处 仍不能证明程序对月份为“00”的输入数据也具有识别和 拒绝接受的功能。再进一步讲,其实在第一步“划分等 价类”时,就应防止有意或无意地将几个独立的无效等 价类写成一个无效等价类。例如,若在上例中把、 两个无效
21、等价类合并写成“末位的对应值为0或12”, 则与之相应的测试用例也将从原来的个减为个,对 程序的测试就不够完全了,边界分析: 经验表明,程序在处理边缘情况时常会出现错误,例如, 许多程序错误出现在数组下标,数据结构和循环等等的 边界附近 因此,设计检查边界值的测试用例暴露程序错误的可能 性会更大 所谓边界条件,是相对于输入情形输出等价类直接在其 边缘上,稍高于其边界和低于其边界的这些状态条件,使用边界值分析方法设计测试用例,通常输入等价类和 输出等价类的边界值,选取刚好等于、稍小于、稍大于 等价类边界值的数据作为测试用例 边界分析法与等价类法有两方面区别: 边界分析不是从某个等价中随便挑一个作
22、为代表,而是 选出一个或几个元素,使得这个等价类的每个边界都要 作为测试对象 边界分析不仅根据输入条件,还要根据输出的情况(按 输出等价类)设计测试用例,因果图: 因果图法也是较常用的一种黑盒测试技术 因果图是一种简化了的逻辑图 当被测程序具有多种输入条件,程序的输出又依赖于输 入条件的各种组合时,用因果图直观地表明输入条件和 输出动作之间的因果关系,能帮助测试人员把注意力集 中到与程序功能有关的那些输入组合,比采用等价分类 法有更高的测试效率,但这种方法的操作步骤比较复杂,猜错: 所谓猜错,就是猜测被测程序在哪些地方容易出错,然 后针对可能的薄弱环节来设计测试用例 它的基本想法是列举出程序中
23、可能有的错误和容易发生 错误的特殊情况,并且根据这些情况设计测试用例 显然,它比前种方法更多地依靠测试人员的直觉与经 验。所以,一般都先用前种方法设计测试用例,然后 用猜错法补充一些例子作为辅助的手段,为了保证测试质量,软件测试必须完成规定的文档,测 试文档资料属于软件文档里的管理文档,它主要是为软 件管理人员和开发人员提供服务 测试文档资料分为: 测试计划:包括测试的内容、进度、条件、人员、测试 用例的选取原则、测试结果允许偏差的范围等,测试计 划又可分为测试计划与测试设计说明、测试规程以及测 试用例几个部分 测试分析报告:需要对测试结果加以分析,并提出测试 的结论性意见。测试分析报告包括综
24、合测试报告和验收 测试报告,系统测试文档,为使测试文档起到桥梁的作用,使它有助于程序员编制 程序,有助于管理人员监督和管理软件的开发,文档的 编制必须保证一定的质量和规范。高质量、规范化测试 文档的编制应体现在以下几个方面: 精确性:文档的行文应当十分确切,不能出现多义性的 描述,同一测试课题的几个测试文档应当是协调一致、 没有矛盾的 清晰性:文档的编写应力求简明,如有可能,配以适当 的图表,以增强其清晰性,规范性:在软件测试的过程中,测试文档的编制应该规 范化,测试文档的测试计划、测试分析报告应有一定的 规范化标准,这样有利于测试人员和开发人员、管理人 员的沟通和理解,避免一些不必要的重复性
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第二 测试 技术
链接地址:https://www.31doc.com/p-2558956.html