搜索
软工教研室张晓燕软件测试方法和技术第2版第14章测试用例的设计本章要解决的问题为什么我们要使用测试用例?测试用例有哪些基本元素组成?测试用例编写和设计时需要遵循哪些基本的原则?白盒测试用例和黑盒测试用例设计的基本方法测试用例设计，组织和测试过程组织之间的关系和实践过程跟踪和维护测试用例第14章软件测试用例的设计14.1测试用例构成及其设计14.2测试用例的组织和跟踪14.1测试用例构成及其设计14.1.1测试用例的重要性14.1.2测试用例设计书写标准14.1.3测试用例设计考虑因素14.1.4测试用例设计的基本原则测试用例的概念测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。什么是测试用例测试用例可以独立进行测试执行的最小单元测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例测试用例就是将软件测试的行为活动转化为规范化的文档测试用例的元素14.1.1测试用例的重要性如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障测试用例的作用有效性可复用性易组织性客观性可评估性和可管理性知识传递重要参考依据，提高测试质量14.1.2测试用例设计书写标准标志符（Identification）测试项（TestItems）测试环境要求输入标准（InputCriteria）输出标准（OutputCriteria）测试用例之间的关联示例良好测试用例的特征可以最大程度地找出软件隐藏的缺陷可以最高效率的找出软件缺陷可以最大程度地满足测试覆盖要求既不过分复杂、也不能过分简单使软件缺陷的表现可以清楚的判定测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了不包含重复的测试用例测试用例内容清晰、格式一致、分类组织良好测试用例的特征(续)测试需要保证以下两点：程序做了它应该做的事情程序没有做它不该做的事情因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。良好测试用例的特征例如:软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。良好测试用例的特征对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢?良好测试用例的特征由简而繁和参数化是一个从简单的测试描述（测试功能点、测试需求等）逐步细化到能够去依照执行的测试用例的过程17样例－登录需求：用户名长度为6至10位（含6位和10位）用户名由字符（a-z、A-Z）和数字（0-9）组成不能为空、空格和特殊字符密码规则同用户名规则样例－登录简能够正确处理用户登录一般输入正确的用户名和口令可以进入系统输入用户名或口令错误无法进入系统详细19详细操作步骤预期结果输入正确的用户名和口令（均为6位），点击[OK]按钮进入系统输入正确的用户名和口令（均为10位），点击[OK]按钮进入系统输入正确的用户名和口令（均为6至8位之间），……进入系统用户名为空，……提示输入用户名不能进入系统用户名为空格，……提示无效用户名不能进入系统用户名小于6位，……提示用户名太短不能进入系统……………………………………定义－参数化是一个将测试数据与测试逻辑（步骤）分开，简化测试用例的过程；方式是将用例中的一些输入、输出等作为参数，数据则单独列出，在执行时选择相应的数据执行。为什么要参数化？没有将测试数据和测试逻辑分开的测试用例可能显得非常庞大，不利于测试员理解，导致难以控制和执行；通过将用例参数化，可以简化用例，使测试用例逻辑清晰，数据与逻辑的关系明了，易于理解；有利于提高测试用例的复用性；哪些内容需要参数化？测试用例中需要通过使用不同数据来重复执行测试的部分；包括：输入（数据或操作等）输出（结果数据或预期结果等）样例－登录步骤：1、输入用户名2、输入口令3、点击[OK]按钮结果：预期结果24测试数据“用户名”“口令”“预期结果”说明“user10”“pass10”进入系统正确的用户名和口令(6位)“user789”“pass789”进入系统正确的用户名和口令(7-9位)“user000010”“pass000010”进入系统正确的用户名和口令(10位)“”“pass”提示输入用户名不能进入系统用户名为空“空格”“pass”提示无效用户名不能进入系统用户名为空格“user”“userpass”提示用户名太短不能进入系统用户名小于6位“user0000011”“userpass”提示用户名太长不能进入系统用户名大于10位………………………………………………14.1.3测试用例设计考虑因素具有代表性、典型性寻求系统设计、功能设计的弱点测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生考虑用户实际的诸多使用场景14.1.4测试用例设计的基本原则尽量避免含糊的测试用例尽量将具有相类似功能的测试用例抽象并归类尽量避免冗长和复杂的测试用例单个测试用例的质量要求具有可操作性具备所需的各项信息各项信息描述准确、清楚测试目标针对性强验证点完备，而且没有太多的验证点没有太多的操作步骤，例如不超过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