软件测试-14-测试用例设计

软件测试方法和技术第2版第14章设计和维护测试用例本章要解决的问题为什么我们要使用测试用例?测试用例有哪些基本元素组成?测试用例编写和设计时需要遵循哪些基本的原则?白盒测试用例和黑盒测试用例设计的基本方法测试用例设计，组织和测试过程组织之间的关系和实践过程。跟踪和维护测试用例。第14章设计和维护测试用例14.1测试用例构成及其设计14.2测试用例的组织和跟踪14.1测试用例构成及其设计14.1.1测试用例的重要性14.1.2测试用例设计书写标准14.1.3测试用例设计考虑因素14.1.4测试用例设计的基本原则什么是测试用例测试用例可以独立进行测试执行的最小单元测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例测试用例就是将软件测试的行为活动转化为规范化的文档测试用例的元素14.1.1测试用例的重要性如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障测试用例的作用有效性可复用性易组织性客观性可评估性可管理性知识传递重要参考依据，提高测试质量14.1.2测试用例设计书写标准p310标志符（Identification）测试项（TestItems）测试环境要求输入标准（InputCriteria）输出标准（OutputCriteria）测试用例之间的关联示例p311-312良好测试用例的特征可以最大程度地找出软件隐藏的缺陷可以最高效率的找出软件缺陷可以最大程度地满足测试覆盖要求既不过分复杂、也不能过分简单使软件缺陷的表现可以清楚的判定测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了不包含重复的测试用例测试用例内容清晰、格式一致、分类组织14.1.3测试用例设计考虑因素具有代表性、典型性寻求系统设计、功能设计的弱点P.313测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生P.315考虑用户实际的诸多使用场景14.1.4测试用例设计的基本原则p316尽量避免含糊的测试用例尽量将具有相类似功能的测试用例抽象并归类尽量避免冗长和复杂的测试用例单个测试用例的质量要求具有可操作性具备所需的各项信息各项信息描述准确、清楚测试目标针对性强验证点完备，而且没有太多的验证点没有太多的操作步骤，例如不超过7步符合正常业务惯例。整体测试用例的质量要求覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提高测试用例的可维护性。14.2测试用例组织和维护14.2.1测试用例的属性14.2.2测试套件及其构成方法14.2.3跟踪测试用例14.2.4维护测试用例14.2.5测试用例的覆盖率14.2.1测试用例的属性一些属性说明目标性，包括功能性、性能、容错性、数据迁移等各方面的测试用例；所属的范围，属于哪一个组件或模块关联性，和软件产品特性相联系阶段性，属于单元测试、集成测试、系统测试、验收测试中的某一个阶段时效性，不同的版本所适用的测试用例可能不相同14.2.2测试套件及其构成方法建立合适的、可扩展的测试用例框架，从而借助这个框架能有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等实例测试用例套件测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来1)按程序功能模块组织2)按测试用例的类型组织3)按测试用例的优先级组织测试类型与测试用例设计根据测试类型设计根据程序功能模块设计功能测试易用性测试配置测试压力测试回归测试界面测试文档测试国际化测试•测试用例1•测试用例2•测试用例3•测试用例1•测试用例2•测试用例3安装/卸载测试联机帮助测试软件更新测试联机注册测试文件操作测试•测试用例1•测试用例2•测试用例3•测试用例1•测试用例2•测试用例3数据备份测试测试用例的组织和测试过程的关系测试用例的组织和测试过程的关系测试套件应用场合只是部分功能模块发生了变化，就可以创建由这些改动模块的测试用例构成的测试套件在修改的模块中，也不需要选择所有的测试用例，针对不同的优先级创建不同的测试套件测试执行的第一阶段可以创建一个特定平台上的测试套件有必要为自动化测试、手工测试分别建立测试套件。还可以建立和测试人员相对应的、不同平台或不同模块的测试套件回归测试中，可以先运行曾经发现缺陷的测试用例，然后再运行从来没有发现的缺陷的测试用例14.2.3跟踪测试用例用例执行的跟踪:跟上进度？测试人员每天能执行多少个测试用例？“通过、未通过以及未测试的”各占多少？不能被执行的原因是什么？测试用例覆盖率的跟踪14.2.3维护测试用例测试用例的维护是持续改进的过程测试用例维护流程示例14.2.5测试用例的覆盖率测试用例本身：发现缺陷后补充的测试用例数/总的测试用例数需求、功能点覆盖率代码覆盖率Q&A