软件测试方法教材.ppt

用户可接受性测试（User Acceptance Testing）有时也叫验收测试。在通过了内部系统测试及软件配置审查之后，就可以开始该项测试了。验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。由用户参加设计测试用例，使用用户界面输入测试数据，并分析测试的输出结果，一般使用生产中的实际数据进行测试。在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。验收测试实际上是对整个测试计划进行一种“走读（Walkthrough）”。 用户可接受测试具有下列特点： 1.必须要有用户参与，且以用户为主； 2.可接受测试在不同的组织之间，随目标的不同及工作量的不同而不同； 3.在软件开发过程当中，可接受测试是最容易变化的一个测试； 4.用户可接受测试只有按照既定的目标进行的时候才能有真正的效果； 5.很少有组织能够真正理解如何处理测试中人的方面问题，他们同时还缺乏必要的培训来进行计划和执行一个有效的可接受性测试。 * * 2.4 黑盒测试——错误推测 使用边界分析法和等价划分技术，可以帮助开发人员设计具有代表性的、容易暴露程序错误的测试用例。但是，不同类型不同特点的程序通常有一些特殊的容易出错的情况。此外，有时分别使用每组测试数据时程序都能正常工作，这些输入数据的组合却可能检测出程序的错误。一般说来，即使是一个比较小的程序，可能的输入组合数也往往十分巨大，因此必须依靠测试人员的经验和直觉，从各种可能的测试用例中选出一些最可能引起程序出错的方案。对于程序中可能存在哪类错误的推测，是挑选测试用例时的一个重要因素。 2.4 黑盒测试——因果图 等价类划分和边界值分析这两种方法并没有考虑到输入情况的各种组合，也没有考虑到各个输入情况之间的依赖关系。输入条件之间的相互组合，可能会产生一些新的情况。用前面两种测试方法时可以检测到各个输入条件可能出错的情况，但却忽略了多个条件组合起来时出错的情况。但要检查输入条件的组合不是一件容易的事情，即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。这就需要利用因果图。 因果图考虑了多个输入之间的相互组合与相互制约关系，按一定步骤，高效率地选择测试用例，同时还能指出程序规格说明中存在的问题。 2.4 黑盒测试——因果图 利用因果图生成测试用例的步骤 （1）分析软件规格说明中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。 （2）分析软件规格说明中的语义。找出原因与结果之间，原因与原因之间对应的关系。根据这些关系，画出因果图。 （3）由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。 （4）把因果图转换为判定表。 （5）以判定表的每一列为依据来设计测试用例。 2.4 黑盒测试——因果图 因果图中的基本符号 2.4 黑盒测试——因果图 输入的约束条件 2.4 黑盒测试——因果图 因果图类型划分 （1）形象因果图 （2）数据因果图 2.4 黑盒测试——因果图 应注意的几个问题 （1）从作图的意图考虑，可以分为问题因果图和目标因果图。问题因果图是寻找问题的起因，回答“为什么”的问题。目标因果图是用来寻找解决某问题的方法或达到某个目标的途径，回答了“如何做”的问题。 （2）依照软件产品的特性不同，应选择不同的因素来进行分析。选择因素时要充分考虑问题所处的环境特点和影响等因素，不可以不经考虑随便套用，否则弄巧成拙，致使简单的问题更为复杂化。 2.5白盒测试 白盒测试要求测试人员清楚盒子内部的内容以及内部如何运作，也就是说白盒测试法是通过分析程序内部的逻辑与程序执行路线来设计测试用例的测试方法，因此白盒测试也被称为逻辑驱动测试，以测试的深度为主。由于这种方法按照程序内部的逻辑进行测试，检验程序中的每条通路是否都能按预定要求正确工作，所以白盒测试又称为结构测试。 2.5白盒测试 白盒测试的作用 由于软件可能存在缺陷，所以要花费时间和精力来测试逻辑细节，软件存在的缺陷主要包括： 1.逻辑错误和不正确的假设。当设计和实现主流之外的功能、条件、或控制时，往往出现错误。 2.主观相信不可能执行某条逻辑路径，但在正常的情况下可能被执行。同时控制流和数据流的一些无意识的假设可能导致设计的错误，只有通过路径测试才能发现这些错误。 3.随机的错误。当一个程序被翻译成程序设计语言的源代码时，有可能产生某些错误，多数可被语法检查机制发现，但是还有些只有在进行白盒测试时才可被发现。 2.5白盒测试 程序结构分析——控制流