软件测试基础和入门课件.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 可测试性是反映软件质量的一个内在属性，不会因为你使用了某种测试工具进行了测试行为，就使得被测试的软件具有了可测试性。如果被测试的软件本身并不具备可测试性，那么使用多么昂贵的测试工具进行测试所能够带来的收益都是微乎其微的。 * 在大多数的情况下，还是由于被测试的软件本身在设计时没有考虑到可测试性的问题。只不过这种不可测试性不是由于被测试的软件内部的过紧耦合造成的，而是和外部某些很难测试的部分耦合过紧，从而表现出被测试的软件本身很难测试。这些很难测试的部分比较常见的有：图形界面、硬件、数据库等。 * * * * * * * * * * * * * * * * * * * * * 其他开发模型 测试准备 测试代码点 测试执行 测试流程 其他流程（对设计流程） H 模型 迭代增量 模型 螺旋迭代 模型 * 系统分析 需求分析 概要设计 详细设计 验收测试计划 系统测试计划 软件集成 测试计划 模块与单元编码和测试 验收测试 系统测试 软件集成测试 交 付 各测试阶段的信息依据： 软件测试与开发各阶段的关系-1 * 软件开发过程是一个自顶向下，逐步细化的过程 软件计划阶段定义软件作用域 软件需求分析建立软件信息域、功能和性能需求、约束等 软件设计把需求转化为程序逻辑流程 编码把设计用某种程序设计语言转换成程序代码 软件测试与开发各阶段的关系-2 * 　　测试过程是依相反顺序安排的自底向上，逐步集成的过程。 软件测试与开发各阶段的关系-3 * 软件测试过程 测试计划 测试设计 测试开发 测试执行 测试评估 * 　软件测试过程 * 测试信息流－1 * 软件配置：软件需求规格说明、软件设计规格说明、源代码等； 测试配置：测试计划、测试用例、测试程序等； 测试工具：测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序、以及驱动测试的测试数据库等等。 测试信息流－2 * 测试结果分析：比较实测结果与预期结果，评价错误是否发生。 排错(调试)：对已经发现的错误进行错误定位和确定出错性质，并改正这些错误，同时修改相关的文档。 修正后的文档再测试：直到通过测试为止。 测试信息流－3 * 通过收集和分析测试结果数据，对软件建立可靠性模型 利用可靠性分析，评价软件质量： 软件的质量和可靠性达到可以接受的程度； 所做的测试不足以发现严重的错误； 如果测试发现不了错误，可以肯定，测试配置考虑得不够细致充分，错误仍然潜伏在软件中。 测试信息流－4 * 测试只能证明错误的存在，而不能表明程序中没有错误。 测试的两个作用是：确定程序中缺陷的存在；有助于判断该程序在实际上是否可用。 软件测试最困难的问题之一是知道何时停止测试(When to stop testing? ) 自己测试自己的程序是不可能的。 当一个软件被测出的缺陷数目增加时，更多的未被发现的缺陷存在的概率也随之增加。 并非所有的软件缺陷都能修复。 程序测试的过程具有破坏性 软件测试公理－1 * 一个好的测试用例应当是一个对以前未被发现的缺陷有高发现率的用例，而不是一个表明程序工作正确的用例。 要对有效的和无效的输入状况写测试用例。（测试用例要兼顾有效与无效的输入） 测试用例应由测试输入数据和对应的预期输出结果这两部分组成。 像做其它事情一样，测试在其一开始就必须要有一个目标。 完全测试程序是不可能的。 软件测试是有风险的行为。 测试无法显示潜伏的软件缺陷。 软件测试公理－2 * ? 软件测试最困难的问题之一是知道何时停止测试 发版决策依据：When to stop testing？ 每天不超过5个缺陷； 没有Critical Bug； 计划发版日期； 市场需求。 软件测试公理分析－1 * ? 完全测试程序是不可能的 输入量太大 输出结果太多 软件实现途径太多 软件说明书没有客观标准。从不同的角度看，软件缺陷的标准不同 软件测试公理分析－2 * ? 软件测试是有风险的行为 如果决定不去测试软件所有可能的情况，那就 是选择了风险。但是在上一条公理中指出：完全 测试程序是不可能的。在这种情况下，又不能全 部测试，不测试又会漏掉软件缺陷，怎么办？ 软件测试员要学会的一个主要的原则就是如 何把无边际的软件出现的可能情况减少到可以控 制的范围，以及如何针对风险制作出明智的抉择 去粗存精。 软件测试公理分析－3 * ? 测试无法显示潜伏的软件缺陷 软件测试工作与防疫员的工作级为相似，可以报告已发现的软件缺陷，却无法报告潜伏的软件缺陷。你可以进行测试