umlandsm chapter10.ppt

软件测试基础 基于状态图的测试 基于活动图的测试 基于协作图的测试 基于用案图的测试 验证指为了弄清楚某一事物是否和相关的规约保持一致而对其进行检查或测试的活动。软件测试是一种验证活动，其中常常用到复审、分析、审查和走查等技术 确认是为了弄清楚某一事物是否是用户实际想要的事物而对其进行检查的过程 软件调试指在软件没有以预期方式执行的情况下对它进行分析并找出其中错误的过程 软件测试是一种系统地识别软件中错误的方法 静态分析不需要执行软件，它通过对软件源代码的静态分析得到某些有意义的度量，从而发现程序中所存在的问题 动态分析通过对程序执行时动态行为的分析来得到执行路径、测试覆盖率等有用信息 需求规约：指明用户要求软件应该实现什么功能，通常也说明了实现这些功能时所存在的约束 体系结构设计规约：描述实现需求规约的软件系统的体系结构。软件中的各构件及这些构件之间的关系将由该文档描述 详细设计规约：描述如何具体实现软件中的各个构件（直至单个的单元） 单元测试：对软件的每个单元（基本构件）进行测试，以验证该单元是否正确地实现了相应的详细设计规约 集成测试：将多个构件（与体系结构设计元素相对应）集成在一起作为子系统进行测试，然后通过添加构件来逐渐增大该子系统并进行测试，直到其成为整个系统为止 系统测试：测试软件系统是否符合相应的需求规约 验收测试：通常使用系统测试用例的子集进行测试，以判断所实现的软件是否就是客户所想要的软件 回归测试: 当软件的运行环境或用户需求发生改变时，需对软件进行修改以适应新的运行环境或增添新的功能，此时涉及到回归测试 目的：(1) 通过测试来确信对软件功能上的增强等修改并没有影响系统原有的功能；(2) 验证新增的功能 测试用例构成：(1) 系统测试的测试用例，用来测试系统的原有功能；(2) 新设计的测试用例，用来测试新增的功能 从测试是否针对系统的内部结构和具体实现算法的角度来看，软件测试又可分为： 黑盒测试：也称功能测试或数据驱动测试，它是在已知产品所应具有功能的前提下，通过测试来检测每个功能是否都能正常使用 白盒测试：也称结构测试或逻辑驱动测试，它是在知道产品内部工作过程的前提下，通过测试来检测产品内部动作是否和规约说明书中所描述的一致 测试目标的建立、测试策略的选取、测试用例的设计与构建是在软件编码之前完成的 测试用例的执行、测试的实际输出与期望输出的比较和分析、软件的修改以及回归测试是在软件编码之后完成的 一个完整的测试用例至少有三个必要的成分： 测试用例描述：用于描述如何对一个特定需求或设计决策的实现进行测试 测试输入：包括待测试对象（单元、子系统或系统）读取的任何外部数据 测试用例的期望输出 单元可以是单个方法，也可以是单个类，甚至可以是以层次形式组织起来的多个类 测试人员往往对单个类的测试更感兴趣。类的测试同时具有单元测试和集成测试的某些特点 单元测试要用到类图和状态图 集成测试要用到协作图、活动图、状态图和构件图 系统测试则要使用用案图来验证系统的行为 测试形式(1) 基于规约的测试: 将类视为一个黑盒，其意图是为了检查类的功能是否与规约中所描述的一致 测试对象: 类的规约以及方法的规约 类的规约除包括类中所有方法的规约之外，还包括一个用于说明该类语义的语句 基于程序的测试: 涉及到类的实现，其意图是为了检查代码的正确性 测试对象：类的所有方法和整个类 在独立地测试一个方法时，应忽略该方法发送给其它对象的消息，编写合适的桩替代它并返回合适的值 测试形式(2) 回归测试:一种基于缺陷的测试方法 重用那些检查出先前版本软件中缺陷的测试用例，其目的是为了检查当前版本的软件中是否还存在相同的错误 健壮的回归测试除了检查老错误之外，还应能检测出相关的新错误，其原因在于诸软件缺陷本身可能是结构相关或功能相关的 状态图一般用来描述类的动态行为，它提供的某些特殊机制使其有别于普通的有限状态机。这些特殊机制主要包括：状态的层次性、状态的并发结构、通过事件广播的通信技术、与状态和时间相关联的动作等等 类测试的一个重要组成部分是如何由给定的规约自动生成测试用例，这些测试用例通常以消息序列的形式出现。由于可能的消息序列数目是无限的，因而进行穷尽测试通常是不实际的，这就要求我们使用某些覆盖标准来选择合理数目的消息序列 基于有限状态机的测试技术也在软件测试中尤其是协议一致性测试中得到了广泛的应用 将有限状态机应用到类的测试中还是一个比较新的概念。基于状态的类测试方法主要考虑类的属性和成员函数之间的交互关系，而有限状态机恰恰可有效地用来表示和测试这些交互关系（将属性值作为有限状态机的状态，将成员函数作为有限状态机的变迁） 基本符号： States：状态图中状态的集合。