软件测试设计与用例.ppt

《软件测试设计与用例.ppt》由会员分享，可在线阅读，更多相关《软件测试设计与用例.ppt（26页珍藏版）》请在三一文库上搜索。

1、软件测试基础,课程内容,测试设计 测试方法 回归测试 验收测试 和测试,测试用例,测试用例定义： 目前没有经典的定义。是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。比较通常的说法是：指对一项特定的软件产品测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 为什么QA需要测试用例： 组织测试 回归复用 结果跟踪 提供测试依据,测试用例的八大要素,用例编号 测试项目 测试标题 重要级别 预置条件 测试输入 操作步骤 预期输出,测试用例模板,课程内容,测试设计

2、 测试方法 回归测试 验收测试 和测试,黑盒测试和白盒测试,黑盒测试（功能性测试）和白盒测试（结构性测试）这两种测试方法设计出来的测试用例在表现形式上是相同的，没有什么区别 黑盒测试与白盒测试的区别在于，黑盒测试方法通过程序的规格说明来识别测试用例。白盒测试根据程序的内部代码结构（分支，循环，条件）来识别测试用例。,黑盒测试,黑盒测试（Black Box Testing）又叫功能测试（Functional Testing），这是因为在黑盒测试中，主要关注于被测软件的功能实现，而不是内部逻辑。黑盒测试是与白盒测试截然不同的一个测试概念，也是在软件测试中使用得最早，也是最广泛的一类测试。在黑盒测试

3、中，被测对象的内部结构，运作情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。就像对一台自动售货机，为了验证其能否自动售出货物，你可以指定需要购买的物品，塞入钱币，然后观测售货机能否输出正确的货物并找出正确的零钱。在这个过程中你不需要关注自动售货机是如何判定钱币数额，如何选择货物，如何找出零钱等内部操作。这是白盒测试关注的范围，黑盒测试关注的是结果。 黑盒测试试图发现以下类型的错误： 1）功能错误或遗漏； 2）界面错误； 3）数据结构或外部数据库访问错误； 4）性能错误； 5）初始化和终止错误。,系统测试的维度分析与质量模型,ISO9126软件质量模型由

4、6个特性、27个子特性组成。这个模型是软件质量标准的核心，今后测试工作需要从这6个特性、27个子特性去测试、评价一个软件,黑盒用例设计方法,边界值 等价类 正交试验法 因果图 判定表 状态迁移 业务流 错误猜测,白盒测试,白盒测试是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例 使用白盒测试方法产生的测试用例能够： 1、保证一个模块中的所有独立路径至少被使用一次； 2、对所有逻辑值均需测试true和false； 3、在上下

5、边界及可操作范围内运行所有循环； 4、检查内部数据结构以确保其有效性。,白盒测试与逻辑覆盖,语句覆盖 语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次 分支覆盖 设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次 条件覆盖 设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次 路径覆盖 设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的基本路径,动态测试与静态测试,动态测试是一种通过执行程序而进行测试的技术。 功能测试 压力测试 单元测试 ,静态测试是一种不通过执行程序而进行测试的技术。

6、 软件代码审查（又称代码走查） 软件编程规范检查（c+ test、jtest) PC-LINT检查技术 同行评审,代码走读和文档评审,准备,预审,审查会议,第三小时,修改,启动会,跟踪到关闭,会议介绍,复查并记录普遍异常,复查并记录特定异常,复查异常记录,作出决议,诸葛亮会,延续会议,两 小 时 以 内,计划、分发材料,可选：15分钟左右,代码: 100L/h；文档: 5P/h 问题太多的话可取消评审,代码：100L/h 文档： 5P/h,为过程改进和缺陷预防建言献策,讨论未决问题或解决方案,通过评审、修改后通过修改后重新评审,课程内容,测试设计 测试方法 回归测试 验收测试 和测试,回归测试

7、（Regression Test),软件在测试或其他活动中发现的缺陷经过修改后，应该进行回归测试（Regression Testing）。目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能 回归测试可以发生在任何一个阶段，包括单元测试、集成测试和系统测试,回归测试的策略,完全重复测试： 重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散局部影响性 选择性重复测试： 即有选择地重新执行部分在前期测试阶段建立的测试用例，来测试被修改的程序,覆盖修改法： 即针对被修改的部分，选取或重新构造测试用例验证没有错误再次发生的用例选择方法。即这类回归测试仅根据修改的

8、内容来选择测试用例，这部分测试用例仅保证修改的缺陷或新增的功能被实现了。这种方法的效率是最高的，然而风险也是最大的，因为它无法保证这个修改是否影响了别的功能。该方法在进度压力很大，或者系统结构设计耦合性很小的状态下可以被使用。,回归测试的策略,周边影响法： 该方法不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对那些受到修改间接影响的部分选择测试用例验证它没有受到不良影响。该方法比覆盖修改法更充分一点。这类回归测试需要分析当前的修改可能影响到哪部分代码或功能，对于所有受影响的功能和代码，其对应的所有测试用例都将被回归。如何判断哪些功能或代码受影响依赖于开发过程的规范性和测试分析人员（

9、或开发人员）的经验。对于开发过程有详细的需求跟踪矩阵的项目而言，在矩阵中分析修改功能所波及的代码区域或其它功能是比较简单的，同时有经验的开发人员和测试人员能够有效的找出受影响的功能或代码。对于单元测试而言，代码修改的影响范围需要充分考虑到一些对公共接口的影响，例如：全局变量、输入输出接口变动、配置文件等。该方法是业界推荐的方法，适合于一般项目的使用。,回归测试的策略,指标达成方法： 这是一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。,回归测试的策略,课程内容,测试设计 测

10、试方法 回归测试 验收测试 和测试,验收测试,当软件产品是为了特定用户开发的时候，需要进行一系列的验收，让用户验证软件产品是否满足了所有的需求。 如果，软件是为多个用户开发的，让每个用户逐个正式的验收测试是不切合实际的，这时候，往往采用和测试，以发现可能只有最终用户才能发现的问题。 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产实践中的实际数据进行测试。再测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能进行确认。验收测试原则上在用户所在地进

11、行，但如经用户同意也可以在公司内模拟用户环境进行。 验收测试根据合同、需求规格说明书或验收测试计划对成品进行验收测试 验收测试的结果有两种情况： 软件功能、性能等质量特性与用户的要求一致，软件可以接受 软件功能、性能等质量特性与用户的要求有差距，不被用户接受,课程内容,测试设计 测试方法 回归测试 验收测试 和测试,测试,测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试； 测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题，在受控制的环境下进行的测试； 测试的目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能等），尤其注重产品的界面和特色； 测试人员是除产品研发人员之外最早见到产品的人，他们提出的功能和修改建议是很有价值的；,测试,测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签订了支持产品预发行合同的外部用户，他们要求使用该产品，并愿意返回所有错误信息给开发者。 与测试不同的是，测试时开发者通常不在测试现场。因而，测试是在开发者无法控制的环境下进行的软件现场应用。 在测试中，由用户记录下遇到的所有问题，包括真的和主观认定的，定期向开发者报告，开发者在综合用户的报告后，作出修改，再将软件产品交付给全体用户使用。,答疑,