集成测试与系统测试

1、1,小组软件开发过程TSPi,TSPi Phases Today,测试阶段,POST MAINTAINANCE,惨痛教训,2002年11月11日，欧洲航天局改进型阿丽亚娜5ECA型火箭发射，火箭起飞96秒后，主级发动机Vulcain-2的冷却循环系统出现故障，飞行186秒后，火箭飞行控制受到严重干扰，火箭偏离预定轨道，456秒后，火箭自毁爆炸。 火箭运载的总价值为6.34亿美元的两颗卫星落入大西洋。 事故调查委员会的报告指出，Vulcain-2主级发动机冷却循环系统的故障导致了这次事故。,TSP 集成与系统测试,Integration 3.较复杂、较易发生错误； 4.有明显定义的性能要求。,持

2、续集成,通常系统集成都会采用持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的集成，有助于尽快发现缺陷，避免大量缺陷集中涌现。 Daily Build 日常构建,系统测试,系统测试是将经过集成测试后的软件，作为计算机系统的一个部分，与计算机硬件、某些支持软件、数据和人员等系统元素结合起来，在实际运行环境下对计算机系统进行一系列的严格有效的测试来发现软件的潜在问题，保证系统的运行。,系统测试问题关键,系统是否已经安装了？ 是否适当地启动了？ 是否能执行在需求时所要求的功能？ 是否能在硬件缺陷或启动失败中恢复？ 它的功能是不是足够？ 性能能否满足要求？相应时间、吞吐量、

3、容量。 系统是不是可用？ 用户是否将发现它很方便？ 用户是否在回答正常操作问题时有麻烦？,系统测试的内容,压力测试（stress test） 容量测试（capacity test） 性能测试（performance test） 安全测试（security test） 容错测试（recovery test）,压力测试,1、压力测试估算 是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。对每个单独的组件进行压力测试后，应对带有其所有组件和支持服务的整个应用程序进行压力测试。 2、测试环境准备 包括硬件环境、网络环境、测试程序、数据准备等方面。,容量测试,容量可以看作系统性能指标中一

4、个特定环境下的一个特定性能指标，即设定的界限或极限值。 容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。 如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如果不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。,性能测试,测试软件能否在真实环境中满足性能要求。 性能测试系统的性能指标，一般应在产品需求文档中有明确定义，有三种形式描述软件系统的性能指标： （1）如在100000记录中查询一个特定数据的时间为0.5秒。 （2

5、）以某个已发布的版本为基线，如比上一个版本的性能提高30-50%。 （3）和竞争对手的同类产品比较。,安全性测试,安全性测试 用户认证安全 系统网络安全 数据库安全 缓冲区溢出-数据的安全 数据的安全。,安全性测试,1、两种级别的安全性 应用程序级别和系统级别； 一个完整的WEB安全性测试可以从部署与基础结构、输入验证、身份验证、授权、配置管理、敏感数据、会话管理、加密。参数操作、异常管理、审核和日志记录等几个方面入手。 网页安全漏洞检测 SQL注入-登陆安全 缓冲区溢出-数据的安全,可靠性测试,可靠性（reliability）是产品在规定的条件下和规定的时间内软件不引起系统失效的能力(完成规

6、定功能的能力)，其概率度量称为软件可靠度。 可靠性测试方法 选取测试用例：软件可靠性测试采用的是按照运行剖面对软件进行可靠性测试的方法。因此，可靠性测试所用的测试用例是根据运行剖面随机选取得到的。 可靠性测试结果的评估 根据测试结果进行评估系统的可靠性。,容错性测试,容错性测试是检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段，包括： 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快

7、恢复。 故障转移（Failover）是确保测试对象在出现故障时，能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行，即备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务，不影响用户的使用。,回归测试,回归测试的目的：在程序有修改的情况下保证原有功能正常的一种测试策略和方法； 测试的重点: bug修改、关联功能、新增加、修改功能、上一轮测试bug多的功能。 例子 阿里亚娜5型火箭发射失败的软件缺陷是修改的代码没有经过充分的回归测试,测试计划及测试开发,你计划进行什么测试?测试类型 测试的次序是什么?测试的顺序 每一个测试需要什么测试材料?测试材料,测试计划主要内容

8、： 1、测试策略-顺序 2、测试技术-方法 3、测试范围 4、测试组织（人员与功能的划分、时间进度安排）,测试大纲的开发测试用例 测试用例（用例编号、环境、需要测试数据、输入、操作步骤、预期输出）,跟踪和度量测试,测试日志 测试运行日期，测试人姓名 测试用例的编号或名称 每个测试开始时间 每个测试结束时间 发现缺陷的数量，使用LOGD引用和编号 测试结果,跟踪和度量测试,有缺陷倾向的模块,跟踪和度量测试,模块缺陷数据,如果一些模块看来特别差 ，应暂停测试，返工检查和 修正这些有缺陷倾向的模块！,嘿嘿，我们可以通过SUMDR表 SUMQ表来分析和迅速找出 有缺陷倾向的模块！,追踪缺陷数据,为追踪

9、和分析每个缺陷的详细数据。 讨论、分析、预防 缺陷逃过了那个过程的步骤？ 你能怎样修改这些步骤以避免缺陷不再发生 你能怎样修改开发过程来预防将来发生这些缺陷 在系统的哪里能存在未发现的类似缺陷？ 现在你怎样发现这些缺陷并修改它们？,我们要吸取教训， 举一反三！,集成测试、单元测试与系统测试的差别,文档,软件=代码+文档 对于客户而言，文档比代码更重要！ 没有文档的系统是无用的系统 文档化的最佳时期是设计完成 有时实现阶段会修改设计。 在大型产品中，应该尽早开发用户文档. 安装、维护、培训和市场需求的文档用户文档,用户文档,非常具有挑战性，描述你的美妙创造。Horrible 文档写的不好，问题何

10、在？ 你只写了你做了些什么，而没有写读者想看的。 描述系统如何工作. 关注读者的需求 Not 系统是如何构建的. 产品的结构,用户文档的组成,列出大纲 软件介绍 界面介绍 安装与卸载 使用说明（依模块与功能逐次描述其使用和操作步骤） 常见问题列表 服务与支持 附录,用户文档的风格,用短句 简单易懂的词或词语 大量的表格和清单 大量的界面截图 朗读 是否理解？是否顺畅？ 读者读起来很轻松。 能够迅速找到重点。,文档评审,文档是否假设用户可能没有某些知识?（术语） 文档是否包含所有需求?（文档内容） 功能是否按照所描写的工作?（准确性） 文档是否易读?（可读性） 能不能让读者明白你写的是什么?（易懂性）,集成与系统测试草案,0 开始条件 策略、计划、SRS、SDS、检查和单元测试过的部件 1 测试开发 测试材料的准备、测试用例的开发 2 建立 建立产品检查完整性，LOGD 3 集成 按照集成测试大纲和材料，对产品进行集成测试 LOGTES