软件测试复习资料.doc

《软件测试复习资料.doc》由会员分享，可在线阅读，更多相关《软件测试复习资料.doc（11页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、【精品文档】如有侵权，请联系网站删除，仅供学习与交流软件测试复习资料.精品文档.软件开发的5个步骤：1 沟通 2 策划3 建模（需求分析、设计）4 构建（编码、测试）5 部署软件开发模型：（1 大棒开发模型 2 边写边改开发模型 3 瀑布开发模型4 增量开发模型 5 快速原型开发模型 6 螺旋开发模型）1 大棒开发模型将开发软件所需要的人力和物力放在一起。思路简单，通常可能是开发者的“突发奇想”，开发过程是非工程化的，随意性大。2 编写边改模型通常只是有了比较粗略的想法就开始简单的设计，然后进行较长的反复编写、测试与修复这样一个循环过程。这样能够较为迅速的展现成果，适合需要快速制作而且完成就扔

2、的小项目。如示范程序、演示程序等。3 瀑布模型将软件开发过程中各项活动规定为按照固定顺序相连的若干阶段性工作，每个阶段还加入了评审，最后阶段得到产品。优点是易于理解、调研开发的阶段性、强调早期计划及需求调查、确定何时能够交付产品及何时进行评审与测试。缺点是需求调查分析只进行一次，不能适应需求变化、顺序的开发流程使得开发中的经验教训不能反馈到该项目的开发中去、开发中出现的问题直到后期才能够显露，因此失去及早纠正的机会。4 增量模型以迭代的方式运用瀑布模型，优点是每个功能都让客户审核后再往下进行，可以尽早发现需求上的不明确和变更。5 快速原型模型根据客户需求在较短时间内解决用户最迫切的问题，完成可

3、演示的产品。这个产品只实现最重要的功能，在得到更加明确的需求之后，将原型丢弃。优点是客户可以迅速的看到产品，进行反馈、可以使错误在较早的阶段出现。缺点是原型只以可看为唯一标准，客户看到软件的外表、开发者为了使第一个原型快速的转起来往往只采用自己熟悉的技术而不考虑实际情况。6 螺旋模型螺旋模型是结合瀑布模式的可控制性与原型的迭代性质，并加入风险评估所建立的软件开发模式。优点是严格的过程风险管理，强调各研发阶段的质量、提供机会评估项目是否有价值继续下去。缺点是依赖专业的风险评估专家。敏捷开发核心思想：能够迅速的适应变化、强调团队成员之间的合作，尽快交付一个可用的软件。极限编程策划：软件产品来源于用

4、户故事，由用户按照系统的功能与特征划分成一个个小故事，然后确定故事的权值。极限编程团队评估每一个小故事并给出开发周数，如果某个故事的时间超过三周，那么请客户讲故事重新细分并标明权值。设计：遵循KIS（keep it simple）原则。即使用简单而不是复杂的描述。只实现故事出现原则，不鼓励而外功能。使用CRC（类责任协作）卡作为有效机制。编码：团队编码前根据功能首先开发一系列用于本次开发的单元测试。编码是集中精神与如何编程才可以通过测试，而不是测试发现问题后修改。并采用结对编程，开发完成后集中实施集成。测试：使用开发好的单元测试计划进行单元测试；邀请客户共同参与验收测试，发现问题后及早预警。指

5、出解决问题的本质也就是软件工程实践的精髓：理解问题（交流和分析）、计划解决方案（建模和软件设计）、设计计划（代码生成）、检查结果的精确度（测试和质量保证）软件开发的核心原则：1 存在价值2 保持简洁3 维护视图4 生产者要让消费者理解5 面向未来6 计划复用7 认真思考沟通的重要性：在分析、建模之前，客户的需求必须通过沟通活动来收集，任何一个有问题的客户都可能会影响到将来的开发成果。沟通的原则：1 倾听2 有准备的沟通3 需要有人推动4 最好当面沟通5 记录所有决定6 保持通力协作7 聚焦并协调话题8 采用图形表示9 继续前进原则10 谈判双赢原则策划的重要性:沟通可以协助团队定义全局目标，而

6、策划使用一系列的管理和技术，为团队定义一个向着目标前进的路线图。策划的原则：1 理解项目的范围2 客户参与策划3 采用迭代计划4 基于已知的估计5 计划考虑风险6 保持脚踏实地7 调整计划颗粒度8 制定计划保证质量9 描述如何适应变化10 经常跟踪、矫正计划建模实践重要性：建模可以更好的描述软件所转换的信息、是转换发生的构架和功能、用户要求的特征以及转换发生时系统的行为。分类：分析建模、设计建模分析建模的关注点：信息域、功能域、行为域分析建模的原则：1 必须描述并理解问题的信息域2 必须确定软件要实现的功能3 必须描述软件的行为4 描述信息、功能和行为的模型必须以分解的形式描述5 分析任务应该

7、从本质信息转向实现细节设计建模关注点:构架、用户界面、构件原则：1 设计建模可追溯到分析建模2 关注待建的系统构架3 数据设计与功能设计同等重要4 必须设计接口5 用户界面必须符合最终用户要求6 功能独立的构件级设计（高内聚）7 构件之间及构件与外部环境之间松散耦合（低耦合）8 设计模型尽可能易于理解9 设计应该是迭代进行构造实践主要活动：构造活动包括编码和测试任务，为向最终用户交付可执行软件做好准备。1 准备原则理解所要解决的问题理解基本的设计原则和概念选择一种能够满足要求的编程语言选择一种开发工具和编程环境构件级编码完成后开始单元测试2 编码原则遵循编码约束选择能够满足要求的数据结构理解软

8、件构架并开发出与其相符的接口尽可能保持条件逻辑简单用易于测试的方法开发嵌套循环选择有意义的变量名并要符合编码标准编写注释，增强代码可读性3 确认原则适当进行代码走查进行单元测试并改正发现的错误重构代码测试原则：1 所有测试都应该可以追溯到用户需求2 测试计划应该远在测试开始之前就计划并着手3 将Pareto原则应用于软件测试Pareto原则认为在软件测试过程当中80%的错误出现在20%的构件当中，测试中要分离可以构件，进行彻底测试。4 测试从微观开始，逐步转向宏观5 穷尽测试是不可能的。部署概念：为用户安装调试软件产品。主要活动:交付、支持和反馈原则：1 客户对于软件的期望必须得到管理2 完整

9、的交付包应该经过安装测试3 技术支持必须在软件交付之前就确定4 必须为用户提供适当的说明材料5 有却选的软件应该改正再交付协同需求收集方法：1 与会者从各自角度列出构成系统的周围环境的对象，由系统产生的其他对象以及系统用来完成的功能。2 列出服务操作与对象交互的服务列表3 列出约束列表4 列出性能列表需求工程的任务概念：需求工程由以下7个活动组成:起始、导出、精化、协商、规格说明、确认和管理。目标：理解客户需要什么，分析要求，哦ing股可行性，协商合理的方案，无歧义的详细说明方案，确认规格说明，管理需求以致将这些需求转化为可运行的系统。软件功能部署：是一种将客户要求转化为软件技术需求的技术。简

10、单的讲就是将客户要求转换为系统的功能和行为。目的是最大限度的使客户从软件过程中感到满意。需求分析产生软件操作的规格说明，让软件工程师细化在前期需求工程工作中获得的基础需求，并建立场景模型描述用户场景、功能活动、系统行为及数据流。分析模型在系统描述和软件设计之间建立桥梁。分析的经验原则：1 模型应该关注在问题域内可见的需求，不要试图解释系统是如何工作的。2 关于基础结构和其他非功能的模型应推迟到设计阶段再进行考虑。3 最小化整个系统内的关联。4 确认分析模型可以为所有共利益者都带来价值。5 尽可能保持模型简介。域分析在特定的领域内有些功能会重复发生，如果对这些模型加以定义和分类，让软件工程师或分

11、析师识别并服用这些模式，将促进分析模型的建模。更重要的是将大大增加可复用的设计模式的使用，使软件的复用得到很好的体现。方法是查找和创建那些能够被广泛应用的、有共同功能和特征的分析类，以便使用。分析模型通常开始于数据建模。数据对象是被软件理解的复合信息。数据对象只封装数据，在数据对象内部没有对数据的操作，通常表现为一张表。数据对象和OO类的区别：数据对象合并了一组独立的属性并为这个聚合取名字，书库对象实际上定义类一个描述事物的类型，可以实例化具体事物参与某个问题。OO类封装了数据属性但也合并了对这些属性的操作。通常情况下OO类中都是对数据对象的操作。构成数据建模的基本元素-数据对象、属性和关系。

12、使用UML分析建模，为使软件工程师更好的了解最终用户希望如何与系统交互，以便软件团队更好的、更准确的刻画系统特征，完成有针对性的分析和设计模型。方法是开发用例图、活动图、泳道图等。主场景：没有考虑其他可能的场景。用例图：使用图形方式可以更直观的描述系统。活动图：通过提供特定场景内交互流的图形化表示来补充用例。泳道图：在表示用例所描述的活动的同时指示哪个参与者或分析类对活动负责。数据流图（DFD）：描述流入系统的数据，经由处理元素转换，最后以结果数据对象的形式流出软件的图形。识别分析类：使用语法分析，所有的名词被当做一个潜在的类。C/S构架系统：在部署的时候需要在客户端安装一个客户端系统用来和服务器端通信实现系统的操作。B/S构架系统：无需安装客户端，通过标准浏览器就可以访问系统实现操作。