软件测试复习资料.doc

软件测试的正面性: Bill Hetzel博士（正向思维的代表）代表论著TheCompleteGuidetoSoftwareTesting ： 软件测试就是为程序能够按预期设想那样运行而建立足够的信心。 “软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果” 测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作 IEEE 的定义 ：p 在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价 p 分析某个软件项以发现现存的和要求的条件之差别（即错误）并评价此软件项的特性 软件测试的反面性: Glenford J. Myers （反向思维的代表）：p 测试是为了证明程序有错，而不是证明程序无错误p 一个好的测试用例是在于它能发现至今未发现的错误 p 一个成功的测试是发现了至今未发现的错误的测试 p软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。 评审分类: 技术评审：对产品的每个阶段的输出内容进行技术性评估，确保需求规格说明书、设计文档等没技术问题。文档评审：格式、内容等，示例p14 管理评审：属于质量保证与管理范畴。 流程评审：同上。可测试性的特征:可操作性、可观察性、可控制性、可分解性、简单性、稳定性、易理解性评审方法：临时评审、轮查、互为复审、 走查、会议审查比较认可的方法： 互为评审：代码阶段； 走查：从头到尾； 会议审查：集体评审，其过程一般包含制定计划、准备组织会议、跟踪和分析结果。重要部分采用。 各种方法可以交替使用软件的评审过程的一般步骤：制定评审计划：组织审查小组，安排日程，分发软件项目材料；项目概貌介绍：当项目复杂时，由作者介绍概貌；评审准备：评审人员阅读项目材料，了解有关项目的情况；项目评审：召开评审会，讨论项目情况，发现和记录错误，督促修改；项目修改返工：由作者修正已经发现的问题，提交修改结果；复查：判断修改是否真正解决了问题。管理复审：向开发组织或使用部门的管理人员，提供有关项目的总体状况、成本和进度等方面的情况，以便他们从管理角度对开发工作进行审查评审的技术：检查表、场景分析、头脑风暴和工具等需求质量标准：正确性；可行性；规范性：业界标准 ； 可验证性； 优先级； 合理性； 完备性：考虑周全； 无二义性； 兼容性：与系统其它硬件及软件兼容； 一致性：模型、算法相容 ；易追溯性：每项需求都有来源软件文档的质量标准：规范性：模板 ；易理解性 ；一致性：前后 ；准确性 ；易修改性：统一的标识、索引 ； 读者是谁如何对需求进行评审：方式：向自己提问题；从用户角度考虑 方法： 分层评审方法：高层（功能逻辑p24），低层（检查表）。 分类评审方法：业务需求；功能需求；非功能需求；用户可操作性等。 分阶段评审：需求形成过程中多次。 需求评审属于静态测试，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。 测试人员在需求评审中作用： 明确自己的角色和责任 熟悉评审内容，为评审做好准备 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题软件设计：一般可分为体系结构设计和详细设计。 体系结构结构设计：需求到数据结构及系统结构， 定义子系统及之间的通信接口。 详细设计进一步分为详细设计、组件设计、DB设计、UI设计 v 非功能：系统架构、整体功能结构、可靠性、安全性、性能、可测试性等。 v 功能：组件、操作逻辑、UI等。从非功能到功能进行审查，从以下方面验证： 软件运行的需求：性能、安全、可用性等； 软件部署和维护的需求：可修改性、可移植性等 与体系结构本质相关的需求：概念完整性、正确、完备性、可构造性。 在实际设计评审中，分为两类， 设计技术的评审标准和非功能质量特性的设计评审要求 设计技术的评审标准：设计结果稳定性：；设计清晰性：目标描述准确、模块关系清晰 ；设计合理性：模块划分、模块结构完整性 ；结构简单性：尽量做到单入口单出口、模块的深宽度均衡 ； 系统的耦合度和内聚力： ； 结构和数据的一致性； 可测试性和可追溯性 依赖性：各个子系统间、与环境的关系描述 ； 不完整、易变动或潜在的需求项 非功能性质量特性的设计评审要求：安全性：数据与系统的分离、权限的设置 ；性能； 稳定：指服务的稳定性及质量，例如用中间层减少数据库的连接数量。 扩展：如多层分布式体系架构，业务逻辑在之间服务器上。 可靠：如系统无单点失效，有故障转移机制系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。 系统架构设计评审就是保证这些特性在设计中得到充分考虑。 系统架构设计的分层评审方法：针对多层次架构，分层评审和整体评审相结合，经过整体评审到分层评审、再反之。 分层评审，从人机交互、业务逻辑和数据服务来评审系统架构。 人机交互：界面及输入输出 业务逻辑：例如负载均衡的考虑、故障转移 数据服务：存储服务，DB设计 系统架构设计评审需注意：整个系统不应该存在单一故障点 （即无备用）；系统是否建立了故障转移机制（健壮性） ；是否建立了良好的负载平衡机制 ；系统架构设计评审时，要确定关键任务并保证关键任务设计合理、性能良好且可靠。 系统部署设计的评审是基于软件服务的质量目标，用来审查软件部署的目标、策略是否合理，是否得到彻底的执行。 是否服从和遵守部署设计的技术规范 逻辑设计的审查； 物理设计的审查； 可用性设计的审查； 可伸缩型设计的验证； 安全性设计的验证组件设计的评审：组件的功能和接口定义正确，文档描述清晰。 为每个模块确定采用的算法。数据结构、数据流和控制流的定义正确。 功能、接口及数据设计具有可测试性、可预测性。界面设计的评审：(1) 易懂性、易用性(2) 一致性和规范性(3) 美观与协调性(4) 遵守惯例和通用法则(5) 独特性(6) 快捷方式的组合(7) 自助功能(8) 错误保护用户界面及其显示要求：用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。 良好的用户体验，简单、方便和明了，让用户舒畅、愉悦 。 通用框架、浮动窗口和文字等整体布局合理 文字显示正常，且内容格式正确、美观。 色彩协调，风格前后一致， 文字标记和超链接可以打开和跳转成功测试需求测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以确定。 在制定测试计划之前，必须清楚测试需求； 明确测试需求的优先级；测试需求分解得越细，对测试用例的设计质量越有帮助； 详细的测试需求还是衡量测试覆盖率的重要依据 ； 测试需求是规划具体项目资源和时间的基础。功能性测试需求：主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。 程序安装、启动正常，有相应的提示框、错误提示；各项功能符合设计要求，正常运行并输出正确结果；功能逻辑合理，并能处理各种异常操作 ；能接受正确的数据输入，输出结果准确，格式清晰；系统的各种状态按照业务流程而变化并保持稳定；支持各种应用环境，能配合硬件设备测试用例（test case）是可被独立执行的一个过程，是最小的测试实体，不能再被分解。是为某个测试点设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。单个测试用例的质量要求：具有可操作性；具备所需的各项信息；各项信息描述准确、清楚；测试目标针对性强；验证点完备，而且没有太多的验证点；没有太多的操作步骤，例如不超过7步；符合正常业务惯例。良好测试用例的特征：可以最大程度地找出软件隐藏的缺陷；可以最高效率的找出软件缺陷；可以最大程度地满足测试覆盖要求；既不过分复杂、也不能过分简单、无冗余；使软件缺陷的表现可以清楚的判定；（测试用例包含期望的正确结果；待查的输出结果或文件必须尽量简单明了；）测试用例内容清晰、格式一致、分类组织；单元测试: 是对已实现的软件最小单元进行测试，以保证构成软件系统的各个单元的质量 v 单元测试活动中，强调被测试对象的独立性v 单元测试应从各个层次来对单元内部算法、外部功能实现等进行检验，包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。 单元测试的方法: 主要采用白盒测试方法(应用于代码评审、单元程序检验之中)，辅以黑盒测试方法(则应用于模块、组件等大单元的功能测试之中)。 v 白盒测试方法（White-box Testing，也称结构测试或逻辑驱动测试）：是根据模块内部逻辑结构，针对程序语句、路径、变量状态等来进行测试，检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确的工作。 v 黑盒测