任务6集成测试1.pptVIP

主讲人：杨晔 任务1集成测试 测试层次 1 Goal 1： 确定单元测试、集成测试、系统测试的含义 开发，自顶向下； 测试，自底向上。 单元测试是被理解得最好的。 功能性测试、结构性测试所讨论的测试理论和技术都可直接用于单元测试。 系统测试是功能性测试，常常与客户验收测试结合在一起进行。 V型瀑布模型 Goal 1： 确定单元测试、集成测试、系统测试的含义 传统的开发模型中，概要设计的最终结果，是将整个系统的功能分解为功能组件的树型结构。 自顶向下的集成测试，桩； 自底向上的集成测试，驱动器； 大爆炸 不管采用哪种方法，传统集成测试的目标是根据功能分解树集成以前测试过的单元。 不同生命周期模型， 会对各个层次的测试产生什么影响? Goal 2： 传统瀑布式开发的主要弱点 功能分解：只有在系统被彻底理解之后才能很好地进行； 需求规格说明与所完成系统的很长时间的分离。开发期过长，没有机会得到客户的反馈。 新模型的共同点 从功能分解转向强调合成（迭代）。 合成更接近人们的工作方式：从已知和理解的东西开始，然后逐渐增加，可能还会删除不需要的部分。 了解其他生命周期模型 Goal 2： 一、瀑布模型的新模型 瀑布模型的派生模型是：增量开发、进化开发和螺旋模型。 回归测试的目标是保证在前一个构建中工作正常的功能，新增加了代码之后仍然工作正常。 由于构建是一组可交付最终用户功能，因此这三种新模型的一个共同优点，是都产生比较早期的综合，能产生较早的客户反馈，缓解瀑布式开发对的两个不足 对测试的影响：集成测试带来消极影响。 了解其他生命周期模型 Goal 2： 二、基于规格说明的生命周期模型 1. 快速原型法 快速原型法生命周期通过急剧缩短规格说明到客户的反馈周期，以产生非常早的综合来解决这个问题。不是构建最终系统，而是构建一种快速、不完善的原型，并用来启发客户提出反馈意见。 了解其他生命周期模型 Goal 2： 对测试的影响 问题：需求在哪里？最后的原型是规格说明吗？系统测试用例如何反向跟踪到原型？ 解决： （1）把原型法周期用做信息收集活动，然后以传统的方式产生需求规格说明。 （2）获取客户怎么使用原型，将他们的使用情况定义为对客户很重要的场景，然后使用这些场景作为系统测试用例。 快速原型法的重要贡献是为需求规格说明阶段引入操作（或行为）的观点。通常需求规格说明技术强调的是系统的结构，而不是系统的行为。这很不幸，因为大多数客户都不大关心结构，而的确关心行为。 了解其他生命周期模型 Goal 2： 了解其他生命周期模型 2. 可执行规格说明 是快速原型法的一种扩展，通过这种方法，需求以某种可执行格式（如有限状态机、状态图或Petri网）描述。然后客户执行这种规格说明，以观察想实现的系统行为，并像快速原型法模型一样地提供反馈。 上层SATM的有限状态机 已知需求为右图的有限状态机，请问如何设计系统测试用例？ 可执行路径。 Goal 2： 了解其他生命周期模型 对测试的影响 降低系统测试难度 与原型相比，需求规格说明文档是明确的。从可执行规格说明中导出系统测试用例常常是一种机械过程。 开发可执行规格说明需要更多的工作，但是通过减少生成系统测试用例的工作量可以得到部分补偿。 如果系统测试根据可执行规格说明进行，则在系统层上可得到一种结构性测试的有意义的形式。 1. 结构认识 集成测试要考虑的是单元之间的接口。 集成测试考虑的是概要设计信息，而系统测试是在需求规格说明的层次上。 2. 行为认识 以系统的系统级输入、输出位置上的端口边界来考虑系统。 线索支持测试的高度解析的视图。 单元级线索是执行（可行路径的）源语句的序列， 集成级线索可以被看做是单元级线索序列，但不考虑单元线索的“内部问题”，只考虑单元线索的交互。 系统级线索可以解释为集成级线索序列。 Goal 3： 区分单元测试、集成测试、系统测试 集成测试 2 1999年9月，火星气象轨道人造卫星，在飞行41周4.16亿英里后，进入火星轨道时消失了。 卫星的缺陷：洛克希德.马丁太空科学家使用的是英制（磅）加速度数据，而喷气推进实验室采用公制（牛顿）加速度数据进行计算。 NASA（美国国家航空航天局）花费了5万美元调查这个原因。 组装测试或联合测试 在单元测试的基础上，将所有模块按照设计要求，逐步装配成高层的功能模块，并进行测试，直到整个软件成为一个整体。 目的是检验软件单元之间的接口关系，并把经过测试的单元组成符合设计要求的软件。 集成测试验证程序和概要设计说明的一致性，是发现和改正模块接口错误的重要阶段。 集成测试的含义 为什么已经有了单元测试，还需要集成测试？ 这是因为在将单元组装成一个整体时需要考虑以下问题： 在把各个单元模块连接起来