《监理工作-软件监理测试工作-参考》由会员分享，可在线阅读，更多相关《监理工作-软件监理测试工作-参考（99页珍藏版）》请在金锄头文库上搜索。
1、北京市质易达工程监理有限责任公司 2009年09月*工程系统 工程监理-软件测试工作1. 软件测试的原则和标准n 测试的定义 软件测试是为了发现错误而执行程序的过程，广义上的 测试包括代码和文档。 软件测试是根据程序开发阶段的规格说明及程序内部结 构而精心设计的一批测试用例（输入数据及其预期结果 的集合），并利用这些测试用例去运行程序，以发现错 误的过程。 n 测试的目的：验证对象之间的交互； 验证软件的所有 构件是否正确集成；确认所有需求是否已经正确实施； 确定缺陷并确保在部署软件之前将缺陷解决；尽早尽可 能多发现缺陷；提高软件产品的质量。测试的生命周期n 在软件开发生命周期中，软件是通过迭
2、代来不断加以 完善的。在这种环境中，对于每个作为测试目标的工作 版本，测试的生命周期还都必须具有一种迭代方法。n 计划：标志测试条件（确定测试什么）和测试的优先级 n 设计：设计测试用例（确定怎么测试） n 开发：测试开发（设计脚本、数据等） n 执行：执行测试用例 n 评估：将测试结果与期望结果进行比较软件测试的原则和标准n 软件测试的原则 原则一：穷尽测试是不可能的，不充分的测试 是愚蠢的，过度的测试也是一种罪孽 原则二：测试工作具有创造性，但很困难 原则三：测试旨在防止错误的发生 原则四：测试是有风险的 原则五：测试要有计划性 原则六：测试要有独立性（测试部门、小组）测试的局限性n 程序
3、测试可以表明缺陷的存在，但决不能证明 没有缺陷。 n 测试必须用需求作为参考点。如果需求是错误 的或不完全的，就会产生假的测试。 n 基于实现的测试并不能发现遗漏，正如缺少的 代码不能被测试一样。 n 从来都不能确信一个正在测试的系统是正确的 ，测试设计中的错误，可能产生假的测试结果 。 n 得到一个预测是困难的，有的甚至是不可能的常用词汇n 错误(Error)：Bug n 缺陷(Fault)：是错误的表现 n 失效(failure)：当缺陷执行时会发生失效 n 事故(incident)：系统在制定范围内执行所需功能时表现 的无能 n 测试脚本：一个用过程脚本语言编写的程序，该程序用 来执行一
4、个测试包 n 测试包：测试实例的集合 n 测试装置：由测试驱动器和其他支持测试执行的工具组 成的系统。 n 测试用例(Test Case)：由输入数据和预期结果组成。输 入数据：数据、文件或操作序列，预期结果：后果和实 际输出黑盒测试n 黑盒测试（Blackbox Testing）又称功能测试 、数据驱动测试或基于规格说明的测试，是一 种从用户观点出发的测试。 n 被测程序被当作一个黑盒，不考虑程序内部结 构和内部特性，测试者只知道该程序输入和输 出之间的关系或程序的功能，依靠能够反映这 一关系和程序功能的需求规格说明书考虑确定 测试用例和推断测试结果的正确性。 n 软件的黑盒测试被用来证实软
5、件功能的正确性 和可操作性。白盒测试n 白盒测试（Whitebox Testing）又称结构测试 、逻辑驱动测试或基于程序的测试。它依赖于 对程序细节的严密检验，针对特定条件设计测 试用例，对软件的逻辑路经进行测试。 n 在程序的不同点检验“程序的状态”以判定其实 际情况是否和预期的状态相一致。 n 软件的白盒测试用来分析程序的内部结构。n 白盒测试要求对某些程序的结构特性做到一定程度的覆 盖，或者说是“基于覆盖的测试” 。最为常见的程序结构 覆盖有： n 语句覆盖：它要求被测程序的每一可执行语句在测试中 尽可能都检验过，这是最弱的逻辑覆盖准则； n 分支覆盖或判定覆盖：要求程序中所有判定的分
6、支尽可 能得到检验； n 条件覆盖：当判定式中含有多个条件时，要求每个条件 的取值均得到检验； n 判定条件覆盖：同时考虑条件的组合值及判定结果的 检验； n 路径覆盖：只考虑对程序路径的全面检验。回归测试n 目标： 修改的或增加的部分是正确的 没有引起其他部分产生错误n 应用： 增量开发 版本控制 软件维护n 测试和测试 n 测试是由一个用户在开发环境下进行的测试， 也可以是公司内部的用户在模拟实际操作环境 下进行的测试。 n 测试是由软件的多个用户在实际使用环境下进 行的测试。这些用户返回有关错误信息给开发 者。测试的分类n 静态分析 n 功能测试 n 用户界面测试 n 性能测试 负载测试
7、 强度测试 容量测试 n 配置测试 n 安装测试 n 安全性测试 n 兼容性测试测试的标准n GB/T16260-1996信息技术 软件产品评价 质量特性及其使用指南 n GB/T17544-1998信息技术 软件包 质量要求和测试 n GB/T8567-1988计算机软件产品开发文件编制指南 n GB/T9385-1988计算机软件需求说明编制指南 n GB/T9386-1988计算机软件测试文件编制规范 n GB/T11457-1995软件工程术语 n GB/T13502-1992信息处理 程序构造及其表示的约定 n GB/T14085-1993信息处理系统 计算机系统配置图符号及约定 n
8、 GB/T14394-1993计算机软件可靠性和可维护性管理 n GB/T15189-1994DOS中文信息处理系统接口规范 n GB/T15532-1995计算机软件单元测试 n B/T15535-1995信息处理 单命中判定表规范 n GB/T1526-1989信息处理 数据流程图、系统流程图、程序网络 图和系统资源图的文件编制符号及约定 n GB/T16680-1996软件文档管理指南 n GB/T8566-2001信息技术 软件生存期过程n 测试相关模型需求分析系统设计详细设计编码单元测试集成测试系统测试验收测试时间程序员的理解 =用户的理解 详细程度V 模型（改良）评价n 优点l文档
9、驱动的开发模型。l改良后的模型很注重反馈和测试，其中V模型提出了测 试驱动开发的概念。l在需求非常明确的前提下可以使用，也适用于有长期 专职开发人员的小型项目开发。n 不足：l严格限定了开发的各阶段，缺乏迭代性。l缺乏对变化的支持。原型法 Brooks 1975设计实现测试维护需求设计实现测试原型设计实现 初始原型初始 概念修改原型 直至被接受完成 发布原型最终 产品目的是和用户一起开发并完善一个原型，从最清楚的需求部分开始。进化原型法评价n 优点：l需求驱动的开发模型。l帮助理解需求。l增强和用户的交流，增加用户好感。n 不足：l缺乏结构化的系统和严谨的开发流程，很难作 为一个项目进行管理。
10、迭代 1迭代2迭代3分析设计编码测试发布1分析设计编码测试发布2分析设计编码测试发布3迭代n分析设计编码测试最终 发布增量型（例RUP）评价n 优点： l开发过程分解为多个迭代过程，每个过程可以有自己的开发 模型。 l可以快速提交可用的系统，然后根据反馈实施下一个迭代。n 不足： l是一个开发框架，对每个迭代的具体过程缺乏支持：n1）如果迭代太少，很容易会蜕变为Code-Fix模式，迭代太多 则往往因文档驱动而导致测试和集成的复杂度和费用太大。n2）因而无法克服以往开发模型的不足。经常蜕变成Waterfall 模型。简单 设计迭代 计划测试驱动 Pair开发持续 集成重构1N个 Iterati
11、on发布 计划1N个 Release小发布发布1N个 TaskXP的增量过程失败通过时间单元测试 100% 通过设计先写 单元测试重构运行 单元测试编程发现BUG集成先写 功能测试User Story运行 功能测试测试驱动开发n软件开发的测试过程n 招投标及合同签订阶段在合同中应该明确功能测试的基础需求规 格说明书，并明确性能测试的方法、其它需 测试的类型以及第三方测试等。在现在的投标书中，有在投标文件中提出验 证方法的现象，应引起注意。（P153 8.2）在监理规划中，应该对软件测试的监理过程 方式（旁站、抽查等）进行明确。开发生命周期中的验证活动开发阶段验证活动需求.确定验证步骤 .对需求
12、进行评审 .产生功能测试用例 .确定需求一致性需求阶段监理任务n 对测试计划以及测试用例的审核n 审核主体：测试计划（参阅测试计划审查表） n 审核注意事项：时间 人员安排测试环境：软、硬件、具体地点测试的依据和标准测试方法及软件，测试的可行性执行和维护需求的可行性与可测性集成、验收测试的进入、结束条件验收需求对测试设计、用例、规程、经过的跟踪测试计划的编制需符合GB/T 9386标准n 测试用例审核功能用例是否完全覆盖n 注意软件性能、安装、配置测试的约定开发阶段验证活动设计.确定设计信息是否足够 .准备结构和功能的测试用例 .确定设计的一致性设计阶段n 继续对功能性测试用例进行细化 n 提
13、交接口等测试方法 n 对单元测试的过程、方法进行确认，核实是否已覆 盖控制流和数据流 n 提交各模块单元、集成测试方案 算法和逻辑 模块接口 数据结构（全局和局部） 边界条件 独立的路径 错误处理 人员，环境，工具开发阶段验证活动编码 单元 测试.为单元测试产生了完整的结构和功能测试的测试 用例.进行了足够的单元测试.主要进行白盒测试，辅助以黑盒测试.对合理、不合理输入进行鉴别和响应.在测试的过程中，需对所有的局部和全局数据 结构、外部接口、程序代码的关键部分实施严格 的代码审查。.多个模块可以平行的独立进行单元测试测试阶段和测试方法单元测试n 目的：分别完成每个单元的测试任务，以确保 每个模
14、块能正常工作。 n 单元测试单元测试在迭代的早期实施，侧重于核实软件 的最小可测试元素。单元测试通常应用于实施 模型中的构件，核实是否已覆盖控制流和数据 流，以及构件是否可以按照预期工作。单元测试n 检验程序最小单位有无错误。 n 一般在编码之后，由开发人员完成。 n 实施效果非常好，但是实施阻力比较大l“不可能出问题”l“小子，我的代码肯定没错”l“天，我这是怎么了，如此简单的错误”l“以后绝对不可能了”单元测试的进入条件n 完成单元模块编码 n 代码编译无错误 n 开发单元纳入承建单位配置受控库单元测试的内容n 单元功能测试 n 模块接口测试 n 局部数据结构测试 n 路径测试 n 错误处
15、理测试 n 边界测试 n 重要模块的性能测试单元测试的成果n 单元测试报告 n 测试记录，测试结果分析 n 软件问题报告单，软件修改报告单 n 经修改的代码 n 回归测试记录和结果单元测试过程n 驱动程序：用于模拟主程序的运行 n 桩模块：用于模拟子程序的运行n 静态分析 对源代码的静态分析：主要分析代码中的类型、 引用、参数传递，以及表达式等不用运行就能 够发现的错误；另外还有一些容易出错的地方 ，如空指针赋值、下标越界等。还可以检查诸 如命名规则等编程规范。 此项测试在监理的过程中，一般可以通过代码巡 查的过程来保证。集成测试n 又称为组装测试或者联合测试 n 在单元测试的基础上进行 n
16、将所有模块按概要设计、详细设计的要求进行 组装。 n 在进行集成测试时，必须确定关键模块(重要需 求，高层控制模块，复杂易错模块，明确性能 要求模块)，对关键模块及早进行测试。 n 在做回归测试时，也应集中测试关键模块。 n 集成测试的目的：在模块组装后查找模块间接 口的错误为什么进行集成测试？ 一个模块可能对另一个模块产生不利的影响 将子功能合成时不一定产生所期望的主功能 独立可接受的误差，在组装后可能会超过可接 受的误差限度 可能会发现单元测试中未发现的接口方面的错 误 在单元测试中无法发现时序问题（实时系统） 在单元测试中无法发现资源竞争问题集成测试的方法：n 非增式测试：采用一步到位的方法来构造测试 ：对所有模块进行个别的单元测试后，按程序 结构图将各模块联接起来，把联接后的程序当 作一个
