工程师软件测试用例设计方法研讨.ppt

软件测试工程师培训 软件测试用例的设计方法 回顾—软件测试的流程 测试模式 测试用例的定义和特征 测试用例的定义： （1）测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。 （2）测试用例是执行的最小实体。 测试用例的特征： （1）最有可能抓住错误的； （2）不是重复的、多余的； （3）一组相似测试用例中最有效的； （4）既不是太简单，也不是太复杂。 设计测试用例的基本准则 测试用例的代表性： 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。 测试结果的可判定性： 即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。 测试结果的可再现性： 即对同样的测试用例，系统的执行结果应当是相同的。 设计测试用例的着眼点 根据产品规格，测试基本功能； 考虑设计一般用户（非专业人员）的使用方案； 考虑设计稀有或特殊的使用方案； 与系统其他组成部分的配合（如FAX和上网可能要用到MODEM，测试中考虑对设备的共享）； 考虑特殊情况（如内存和硬件的冲突等）； 设计极端情况（如内存泄漏、破坏性测试等）； 好的测试用例集能花费最小的代价（人力、物力、财力、时间）做最好的测试。 什么是软件缺陷 软件未达到产品说明书标明的功能。 软件出现了产品说明书指明不会出现的误。 软件功能超出产品说明书指明范围。 软件未达到产品说明书虽未指出但应达到的目标。 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。 为什么会出现软件缺陷 导致软件缺陷最大的原因是产品说明书。 软件缺陷的第二大来源是设计方案。 编写代码 其他 软件缺陷的修复费用 从开始到计划、编制、测试、一直到公开使用的过程中，都有可能发现软件缺陷。 随着时间推移，修复软件缺陷的费用呈几何数级地增长。 什么是黑盒测试 黑盒测试法把程序看成一个黑盒子，完全不考虑程序内部结构和处理过程。 黑盒测试是在程序接口进行测试，它只是检查程序功能是否按照规格说明书的规定正常使用。 黑盒测试又称功能测试。 黑盒测试 主要是为了发现以下几类错误： ①是否有不正确或遗漏了的功能？ ②在接口上，输入能否正确地接受？能否输出正确的结果？ ③是否有数据结构错误或外部信息（例如数据文件）访问错误？ ④性能上是否能够满足要求？ ⑤是否有初始化或终止性错误？ 什么是通过测试 在设计和执行测试用例时，总是首先进行通过测试。在破坏性试验之前看看软件基本功能是否实现是很重要的，否则在正常使用软件时就会奇怪为什么有那么多软件缺陷。 什么是失败测试 确信软件在普通情况下正确运行之后，就可以采取各种手段通过搞垮软件来找出缺陷。纯粹为了破坏软件而设计和执行的测试用例称为失败测试或迫使出错测试 为什么做测试用例 完全测试是不可能的： 输入量太大； 输出结果太多； 软件实现途径太多； 软件说明书没有客观标准。从不同角度看，软件缺陷的标准不同。 什么是测试用例 为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据，称之为测试用例。 我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。 一个好的测试用例是在于它能发现至今未发现的错误。 使用测试用例的好处 在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。 在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。 功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。 测试用例的设计过程 测试设计员（分析设计员）依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。 测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员，则可用分析设计员代替。 针对白盒，还应有驱动程序和桩模块。 测试点的确定 ISO 质量体系： 在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。 CMM 质量体系： 在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程，每一个用例模型为一个测试点，用例模型中每一个测试需求至少应有两个测试用例。 理解上的误区 测试用例应由测试设计员或分析设计员来制定，而不是普通的测试员。 测试点应由分析设计员确立，与测试人员无关。 测试工作展开于项目立项后，而不是代码开发完成之后。 测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概