软件建模与文档写作第7章 节 测试 [恢复].pptx

软件测试是按照测试方案和流程对软件产品（程序、数据和文档）进行功能或非功能性测试，在测试中需要使用不同测试工具，使用不同方法设计测试用例，对测试方案可能出现的问题进行分析和评估。执行测试用例后，需要跟踪故障，以确保开发的软件产品适应用户需求。 ;7.1软件测试概述 7.2结构化测试 7.3 面向对象测试 7.4 软件测试文档 7.5 本章小结 ;7.1.1 测试目标和原则 7.1.2 测试过程模型 7.1.3 测试类型 7.1.4 测试方法 7.1.5测试用例设计 ; 软件测试是评估一个系统的活动，旨在确定系统与实际需求之间是否存在差距、错误或者遗漏。通常情况下，软件测试活动涉及到的人员包括软件开发人员、测试人员、项目管理人员及最终用户。 软件测试以不同形式贯穿在整个开发周期中的每个阶段。例如在需求分析阶段，需求的验证可被认为是测试；在设计阶段，为改进设计而不断复查也可认为是测试；开发者进行编码的代码也是测试（即单元测试）；编码后系统的集成和软件交付也需要测试。 软件测试目的是能在最小的成本和最短的时间内，通过设计良好的测试规程和测试用例，系统地发现不同类别的错误。通过软件测试，可以发现系统在开发过程中由开发者引入的缺陷；获知软件的可信度，确定软件质量等级；有效地预防其它缺陷的产生；能够确保系统与需求规格说明一致，确保最终结果能满足用户需求，提升用户对软件产品的信心。; 为更好地实现软件测试的目标，在进行测试时要掌握一定的基本原则： 设计好的测试用例。测试并不能证明程序没有错误，因此设计好的测试用例才能最大可能地查找出缺陷。 不可能进行穷举测试。程序逻辑结构的复杂性和输入的多样性大大增加了测试的难度。单从时间因素考虑完成穷举测试是不可能的，测试人员需要在风险评估基础上完成测试的最佳安排。 尽早开展测试。尽早进行软件测试有利于开发者在软件开发周期中对时间更合理的安排，更有利于软件产品的按时发布可以降低系统返工的成本与时间。越早发现的缺陷，其修正的难度和费用越小。 ;7.1.2 测试过程模型;7.1.2 测试过程模型;7.1.2 测试过程模型;7.1.2 测试过程模型;7.1.3 测试类??;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.3 测试类型;7.1.4 测试方法;7.1.4 测试方法;7.1.4 测试方法;7.1.4 测试方法;7.1.4 测试方法;7.1.4 测试方法;7.1.4 测试方法;7.1.4 测试方法;7.1.5测试用例设计;7.1.5测试用例设计;测试用例覆盖所有测试点、覆盖所有已知的用户使用场景（User scenario），也就是说每个测试点都有相应数量的测试用例来覆盖，而且将各种用户使用场景通过矩阵或因果图等方式列出来，找到相对应的测试用例。 测试手段的区别对待。在设计测试用例时，就要全面考量测试的手段，哪些方面可以通过工具测试，哪些方面不得不用手工测试，对不同手段的测试用例区别对待。 有充分的负面测试。作为测试用例，不仅要测试正确的输入和操作，还要测试各种各样的例外情况，如边界条件、不正确的操作、错误的数据输入等。 有重复、冗余的测试用例，满足相应的行业标准等。 ;对于每个具体的测试用例，设计时应满足以下条件： 测试用例的出发点是发现缺陷，即单个测试用例在“暴露缺陷”上具有较高的可能性。 测试用例的单一性。一个测试用例面向一个测试点，不要将许多测试点揉在一起。例如，通过一个测试用例发现1～2个缺陷，而不能发现5～10个缺陷甚至更多的缺陷。 符合测试用例设计规范或测试用例模板。 描述清楚。包括特定的场合、特定的对象和特定的术语，没有含糊的概念和一般性的描述。例如，测试用例名称为“登录功能使用正常”，就是一个描述不清楚的例子，而这样的描述“登录功能中用户名大小写不敏感性验证”、“登录功能中用户名唯一性验证”和“用户账号被锁定后再进行登录操作”等就比较好。 ;操作步骤的准确性。按照步骤的操作得到唯一的测试结果。 操作步骤的简单性。操作步骤不应该太复杂，过于复杂的操作步骤意味着测试用例需要被分解为多个测试用例或者分解为多个环节进行验证。 所期望的测试结果是可验证的，即能迅速、明确地判断测试的实际结果是否与所期望的结果相同或相匹配。例如，在测试用例中描述期望结果为“登录成功”，这实际是不可验证的。要使这个期望结果具有可验证性，我们就应该这样描述所期望的结果—“‘退出（log out）’按钮出现”。 测试环境的正确性、测试数据的充分性。 前提条件、依赖性被完全识别出来。 ; 对于不同类别的