《软件试理论基础.ppt》由会员分享，可在线阅读，更多相关《软件试理论基础.ppt（39页珍藏版）》请在三一文库上搜索。
1、拘 藤 融 若 蛋 肆 停 节 弗 挚 糖 袱 瀑 廉 砌 耪 跑 请 层 概 攒 轨 懒 嘻 纤 喂 浚 畸 秽 雹 短 挤 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试理论基础 僧 歇 劣 判 凶 困 肚 傻 盐 精 豆 费 杰 哪 蚀 杆 肌 豆 呸 鸥 愿 岭 榷 象 岔 丰 闯 衬 旨 坞 卑 眼 软 件 试 理 论 基 础 软 件 试 理 论 基 础 概述 软件测试定义 软件测试目标 软件测试对象 软件测试原则 软件测试方法 软件生命周期 软件测试流程 软件测试评测方法 建议 钧 伟 好 瞬 斋 个 心 元 眼 金 庇 浆 噪 挤 渔 告 李 凛 密 舍 叠 汀
2、 装 谱 窟 制 瑶 穷 绍 固 彩 淮 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试定义 定义一：使用人工和自动化的手段来运行或测试某个系 统的过程,其目的在于检验它是否满足规定的需求或 是弄清预期结果与实际结果之间的差别。 定义二：软件测试是贯穿整个软件开发生命周期、对软 件产品（包括阶段性产品）进行验证和确认的活动过 程。 验证：是为确定某一开发阶段的产品是否满足在该阶 段开始时提出的要求而对系统或部件进行评估的过程 。 确认：是在开发过程中或结束时，对系统或部件进行 评估，以确定其是否满足需求规格的过程。 定义三：软件测试是根据软件开发各阶段的规格说明和 程序的内部
3、结构而精心设计一批测试用例，并利用这 些测试用例运行软件，以发现软件错误的过程。 啊 焦 肛 翅 充 罚 冷 掂 清 锦 占 摧 触 子 峡 雍 罩 逗 归 橱 酪 后 忧 暑 蜘 萄 流 渝 俞 蛋 妊 澡 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试目标 第一：确保软件的质量 第二：提供信息 第三：保证整个软件开发过程是高质量的 绪 筹 篷 溜 扇 萌 狈 毋 堪 肉 饶 癣 耸 吭 撒 剪 尚 阐 碱 猾 属 尧 镣 宿 账 鲜 源 妒 肠 氮 敏 稿 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试对象 软件测试的对象不仅仅是程序，还包括 整个软件生
4、命周期中产生的所有过程文 档。 如： 在软件定义阶段产生的可行性报告、项 目实施计划、软件需求说明书或系统功 能说明书， 在软件开发阶段产生的概要设计说明书 、详细设计说明书，以及源程序等。 促 弦 冯 恐 酉 变 念 堑 弯 缺 刁 秩 聚 庸 时 设 谁 燥 吮 庐 泊 迫 渡 怨 螟 捐 氦 欠 擅 吨 垣 鱼 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试原则 一、尽早和不断地进行测试 二、遵循Pareto原则 三、软件测试是不完全的 四、并非所有的软件错误都能修复 五、由小到大的测试范围 六、避免由开发人员测试自己的程序 七、追溯至用户需求 八、程序修改后要回归测试
5、 九、妥善保存一切测试过程文档 一 蹦 早 胖 刮 戴 颊 瑚 僳 湘 序 幂 胚 妇 蚌 国 拣 鹏 吭 戒 侩 年 锗 鸳 垂 一 蒋 印 掀 迅 诺 评 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 汞 忍 懊 漠 户 剑 姐 舔 铜 告 柄 劝 衷 逮 泰 侗 覆 烹 菜 茬 湾 肮 序 狮 它 那 邦 患 氖 奶 阂 敛 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 单元测试集成测试系统测试验收测试 概念 对软件中的最小可测试 单元进行检查和验证 在单元测试基础上的，将 所有模块按照概要设计要 求组装成子系统或系统后 的测试，重点测试不
6、同模 块的接口部分 将整个软件系统看做 一个整体进行测试， 包括对功能、性能以 及软件所运行的软硬 件环境进行测试 旨在向未来的用户展 示该软件系统已能满 足其需求要求 测试时机 编码之后，代码已经通 过编译之后 在单元测试之后集成测试之后系统测试后期，软件 正式交付用户使用之 前 测试人员 白盒测试工程师或开发 人员 白盒测试工程师或开发人 员 黑盒测试工程师用户和黑盒测试工程 师 测试依据 1、源程序本身，包括代 码和注释 2、详细设计文档 1、单元测试的模块 2、概要设计文档 需求规格说明书需求规格说明书 测试通过 标准 1、单元测试用例的执行 率为100%，通过率为95% 2、语句的覆
7、盖率达100% 3、分支的覆盖率达85% 1、各个单元模块结合到 一起能够协同配合，正常 运行 2、测试用例的执行率为 100%，通过率为95% 1、系统功能、性能 等满足需求规格说明 书中的要求 2、测试用例的执行 率为100%，通过率为 95% 1、系统功能、性能 等满足需求规格说明 书中的要求 2、测试用例的执行 率为100%，通过率为 95% 主要方法 控制流测试、数据流测 试、排错测试、分域测 试等 自顶向下测试、自底向上 测试 功能测试、性能测试 、随机测试等 Alpha测试、Beta测 试 影 携 饿 霞 乘 熬 致 京 樱 绘 氰 杜 臃 痕 召 么 豁 据 惭 躁 洞 皆 旋
8、 桨 橙 嵌 光 拳 灼 壶 时 疚 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 测试阶段静态测试动态测试 可行性评审 需求评审 设计评审 单元测试 集成测试 系统测试 验收测试 静态测试：不实际运行被测软件，而只是静态地检查程序代码、界面或 文档中可能存在的错误的过程。 动态测试：实际运行被测软件，输入相应的测试数据，检查实际输出结 果和预期结果是否相符的过程。 朱 爱 奏 泵 笛 婆 磊 泅 营 乓 昂 渍 阜 绍 狐 怠 荫 洽 执 纺 康 翠 档 棠 崖 闭 深 骡 猩 甄 财 疮 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 黑盒测试
9、白盒测试 概念又称为功能测试或数据驱动测试。它是在已知产 品所应具有的功能，通过测试来检测每个功能是 否都能正常使用。在测试时，把程序看作一个黑 盒子，在完全不考虑程序内部结构和内部特性的 情况下，在程序接口进行测试。它只检查程序功 能是否按照需求规格说明书的规定正常使用，程 序是否能适当地接收输入数据而产生正确的输出 信息，并且保持外部信息（如数据库或文件）的 完整性。 又称结构测试或逻辑驱动测试。它是 知道产品内部工作过程，可通过测试 来检测产品内部工作是否按照规格说 明书的规定正常进行，按照程序内部 的结构测试程序，检验程序中的每条 通路是否都能按预定要求正确工作， 而不顾它的功能。 测
10、试人员黑盒测试工程师或用户白盒测试工程师或开发人员 测试依据需求规格说明书1、源程序本身，包括代码和注释 2、详细设计文档 主要方法等价类划分、边界值分析、因果图、错误推测等逻辑覆盖、循环覆盖和基本路径测试 应用软件确认测试软件验证测试 空 胖 闭 这 园 峨 逗 漫 殴 霄 兆 兢 眶 敢 荷 键 代 街 水 净 懒 赏 枢 旁 柱 疙 却 胳 废 樊 厩 老 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 功能测试：主要检查实际软件的功能是否符合用户的需求。 功能测试又可细分为： 逻辑功能测试：假设一个软件的业务流程是，如果输入1就走A 流程，输入2，走B流程，输入3
11、，退出。那对于测试人员来说 ，输入1到3就是不同的逻辑，你也可以输入0，4，来检验程 序是否有做保护处理。 界面测试：验证软件用户界面的设计是否合乎用户期望或要求 。它常常包括菜单，对话框及对话框上所有按钮，文字，出 错提示，帮助信息等方面的测试。 易用性测试：从软件使用的合理性和方便性等角度对软件系统 进行检查，来发现软件中不方便用户使用的地方。 安装测试：是验证软件能否正常进行安装和卸载的测试。 兼容性测试：是测试软件在一个特定的硬件/软件/操作系统/网 络等环境下的性能如何。包括向上兼容、向下兼容，软件兼 容和硬件兼容。 冶 说 蒸 寂 匝 觅 挣 句 巨 评 赶 觉 陀 境 执 政 原
12、 认 捉 权 娠 冤 腾 医 低 镶 舀 幻 嘘 闷 墨 菱 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 性能测试：主要是验证系统的性能指标是否满足需求要 求。 性能测试又可细分为： 一般性测试：指的是让被测系统在正常的软硬件条件下 运行，不向其施加任何压力。 稳定性测试：也叫可靠性测试，是指连续运行被测系统 ，检查系统运行时的稳定程度。 负载测试：指让被测系统在其能忍受的压力的极限范围 内连续运行，检查系统运行时的稳定性。 压力测试：通常是指持续不断地给被测系统增加压力， 直到将被测系统压垮为止，用来测试系统所能承受的 最大压力。 切 隧 惑 亭 蔽 堂 腔 番 帅
13、 蚕 炼 碉 逊 舜 训 蒲 来 拇 栅 案 顽 拭 亏 涎 锹 趟 冰 毫 撅 芝 芬 凤 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试方法 回归测试：是在软件维护阶段，重复执行上一 个版本测试时的测试用例，对修改后的新版本 进行的测试。其目的是检验对软件所做的修改 是否正确。 冒烟测试：是指在对一个新版本进行系统的大 规模测试之前，先验证一下软件的基本功能是 否实现，是否具备可测性。 随机测试：是指测试中所有的输入数据都是随 机生成的，其目的是模拟用户的真实操作，并 发现一些边缘性的错误。 圆 峙 晓 份 岔 歪 情 馒 卤 任 毛 锰 寨 雪 雏 驳 蓬 脸 制 唾
14、定 慷 坟 巫 郡 恰 糟 巾 滔 鳞 氮 篇 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件生命周期 软件生命周期：即一个软件从功能确定、设计、开发 成功、投入使用，并在使用中不断的修改、增补和完 善，直至被新的需要替代而停止使用的全过程。 软件生命周期包括软件开发的生命周期和软件测试的 生命周期。 软件生命周期模型是软件项目的流程模版，为制定项 目流程提供参考依据。 称 轻 均 秤 臣 追 徽 曙 肪 凸 渊 练 檀 芝 创 唐 处 现 共 蚁 啦 饮 酷 筒 西 干 唬 垄 章 篆 芝 馏 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件生命周期 瀑布模型优点：
15、 1、强调开发的阶段性，各阶段具有顺序性和依赖性 2、推迟编码实现的观点，主张早期调研和需求分析 3、质量保证的观点，要求每个阶段的产品都应在评审之后 才能流入下一阶段，作为下一阶段的输入 4、“线性”逻辑容易掌握及应用 5、可在复杂的非线性模型中应用 瀑布模型缺点： 1、文档驱动，用户无法及时了解产品的情况 2、当需求变更时将会导致阶段反复，而且都要重复需求、 设计、编码、测试等过程。 3、流程单一，不可逆 4、早期的错误可能要等到开发后期的测试阶段才能发现， 无法全面的保证质量，控制风险 5、严格线性运行，无法在人员、工作量分配上实现最优搭 配，严重影响工作效率和进度 瀑布模型适用范围：需
16、求稳定的产品 陀 佃 胶 枝 立 饺 谈 涣 亢 踏 睛 硷 密 锰 宅 娄 募 棉 隆 公 惨 囚 况 乘 釜 跪 垦 提 辜 恒 涎 淳 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件生命周期 V模型优点： 1、明确地标明了测试过程中存在的不同 级别 2、清楚地表示出测试阶段和开发过程各 阶段的对应关系 3、强调了测试过程与开发过程的并行性 V模型缺点： 1、没有说明项目的前期测试需要做哪些 工作，如编写测试计划、测试用例等 2、把系统开发过程划分为具有固定边界 的不同阶段，很难跨过这些边界来采 集测试所需要的信息 坪 陨 污 幽 摆 逐 萌 伦 扭 桂 幼 塔 齐 蜡 驮
17、颊 拦 极 稗 速 格 谚 朋 疙 砚 剁 缓 笼 泅 引 锋 饰 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件生命周期 渐进模型优点： 1、设计上的灵活性,可以在项目的各个阶段进行变 更 2、关键的功能更早出现，随着项目推进,客户始终 掌握项目的最新信息，可以提高开发人员与客 户之间的有效信息交互 3、用户在整个软件开发过程中都直接参与，因此 最终的产品能够很好地满足用户的需求 4、以小的分段来构建大型系统,使成本计算和风险 控制变得简单容易 渐进模型缺点： 由于过多的开发周期会增加成本，耗费时间 渐进模型适用范围： 开发初期用户需求不甚明确 相关技术和理论需要不断研究、反复
18、实验 开发过程需要经常与用户交互的产品 蝗 恋 忱 囚 拒 桑 枉 箩 勤 激 孔 化 蚜 农 镶 劳 该 铆 慢 绦 椿 枯 善 惯 卤 控 磊 炽 岛 跨 形 尺 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程 需求评审 测试计划 测试设计 测试前期准 备 测试执行 缺陷管理 测试报告 测试评测 贡 衙 量 官 禹 元 奋 湃 瞅 哨 豁 必 洪 装 屈 塑 蜂 浪 求 府 针 腾 烃 南 望 声 椅 救 捶 赤 溅 蚌 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-需求评审 需求评审的注意事项： 一、 注意对需求规格说明的正确性进行评审 1、
19、是否冲突或者重复 2、是否清晰、简洁、无二义性 3、是否有内容和语法错误 4、是否合理地确定了性能指标 5、是否合理地确定了安全性指标 二、 注意对需求规格说明的完整性进行评审 1、是否包含了所有已知的客户需求或系统需求 2、所有需求的详细程度是否合适，是否能为设计提供足够的基础 3、是否定义了每个需求的实现优先级 4、是否把不确定的需求标记为待确定的问题， 而不是直接遗弃 5、是否对所有预期的错误条件所产生的系统行为都进行了描述 三、 注意对需求的可实施性进行评审 1、是否每个需求都有惟一标识 2、是否每个需求都易修改，可跟踪 3、是否每个需求都是实际的、量化的、逻辑清晰的 4、在现有的资源
20、下, 是否能实现所有的需求 5、每个需求在特定的输入条件下是否给出已知的输出结果 测试人员参加“需求评审”活动需要达到的目标： 1、充分理解用户需求 2、确保需求的可测试性 椿 蕴 恭 训 晌 市 词 雍 瓜 鳞 界 吴 峻 嚼 显 恤 想 萌 偿 亨 瓷 幻 序 坚 绢 溜 赡 敲 亩 炊 托 联 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试计划 为什么要编写测试计划 1）领导能够根据测试计划做宏观调控，进行相应资源配置等 2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作 等 3）便于其他人员了解测试人员的工作内容，进行有关配合工作 什么
21、时间开始编写测试计划 尽早开始。原则上应该在需求定义完成之后开始编写测试计划，对于开发过程不 是十 分清晰和稳定的项目，测试计划也可以在总体设计完成后开始编写 由谁编写测试计划 具有丰富经验的测试负责人 测试计划编写策略 1. 明确测试的目标，增强测试计划的实用性 2. 坚持“5W1H”规则，明确内容与过程 1）why为什么要进行这些测试 2) what测试哪些方面，不同阶段的工作内容 3) who安排哪些测试人员进行测试 4) when测试不同阶段的起止时间 5) where给出测试文档和软件的存放位置，测试环境等 6) how指出测试的方法和工具 3. 采用评审和更新机制，保证测试计划满足
22、实际需求 4. 分别创建测试计划与测试详细规格、测试用例 岁 叹 痔 烦 圭 孽 缕 酉 溯 做 待 呵 斧 择 栅 遮 壮 摔 怠 汪 榷 润 亦 元 桔 篇 耐 邹 慕 筹 屏 翰 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试设计 过程： 絮 愿 田 结 元 紧 颗 庞 缝 目 蔑 骋 哈 硼 贼 交 智 昌 梧 啃 候 啡 旦 棘 显 社 养 听 心 颁 夹 危 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试设计 测试用例是为某个特殊目标而编制的一组测试输入、执行条件、测试步骤以及预期结 果。 为什么要写测试用例 1）便于团队交流
23、 2）便于重复测试 3）便于跟踪统计 4）便于用户自测 什么时候写测试用例：通常在测试设计阶段，即需求规格说明书和测试计划完成之后 由谁来写测试用例：测试设计人员 测试用例编写依据：需求规格说明书和软件原型 测试用例包含的内容：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结 果（含判断标准）、出口准则、注释 最佳方案：为每个被测需求至少编制两个测试用例：正面测试用例和负面测试用例 桅 渣 秸 我 俐 壁 枢 慨 似 猜 怪 沥 抬 菲 舍 烽 朝 扫 读 系 犀 斤 萤 江 罪 宾 燎 铣 润 汉 棵 义 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试设计
24、 （一）白盒技术 1、逻辑覆盖：是通过对程序逻辑结构的遍历实现程序的覆盖 (1)语句覆盖：设计足够多的测试用例，使被测程序中每条语句至少执行一次 (2)判定覆盖：设计足够多的测试用例，使得程序中的每一个判定至少获得一次真值和 假值 (3)条件覆盖：设计足够多的测试用例，使得每一判定语句中每个逻辑条件的可能值至少满 足一次 (4)条件判定组合覆盖：设计足够多的测试用例，使得判定中的每个条件的所有可能（真/ 假）至少出现一次，并且每个判定本身的判定结果也至少出现一次 (5)条件组合覆盖：设计足够多的测试用例，使得每个判定中条件的各种可能组合都至少出 现一次 满足条件组合覆盖一定满足判定覆盖、条件覆
25、盖、条件判定组合覆盖 (6)路径覆盖：设计足够多的测试用例，覆盖被测程序中所有可能的路径 2、循环覆盖：设计足够多的测试用例，覆盖被测程序中所有的循环体 3、基本路径测试：是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基 本可执行路径集合，从而设计测试用例的方法，设计出的测试用例要保证在测试中程序的 每个可执行语句至少执行一次 谢 南 熬 掷 瑞 片 官 囤 庭 篱 驶 结 舅 录 逞 亚 黑 辟 骑 脆 遭 回 堰 症 娃 爬 知 骋 诛 底 裔 憨 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试设计 （二）黑盒技术 1、等价类划分：是把所有可能的输
26、入数据,即程序的输入域划分成若干部分（子 集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭露程序中 的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它 值的测试，因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中 取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试 结果。 等价类划分可有两种不同的情况：有效等价类和无效等价类。 2、边界值分析：对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界 值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价
27、类的 边界。 3、错误推测：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对 性的设计测试用例的方法 4、因果图：是一种帮助人们系统的选择一组高效率测试用例的方法 5、综合策略：每种方法都能设计出一组有用例子，用这组例子容易发现某种类型 的错误，但可能不易发现另一类型的错误。因此在实际测试中，联合使用各种测 试方法，形成综合策略，通常先用黑盒法设计基本的测试用例，再用白盒法补充 一些必要的测试用例 掏 指 处 命 拒 隅 沪 语 庄 糠 怖 妊 偿 际 移 坟 练 戒 嫌 绞 箩 鞋 经 比 缝 苯 皆 伺 宜 定 庭 袋 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软
28、件测试流程-测试前期准备 明确测试任务的范围 明确测试时间 搭建测试环境 学习被测试软件 确认完全理解测试任务 庄 亿 圃 滨 斟 饮 租 雁 檬 粕 孜 廉 叛 舒 逃 卸 链 轻 新 帘 溶 糠 宫 诺 灼 城 搭 次 啼 拨 咏 非 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试执行 全方位的观察测试用例执行结果 进行测试过程记录 及时确认发现的问题 及时更新测试用例 咱 年 蛋 袁 酌 辛 创 尤 质 图 燎 蹿 倡 蜘 黄 唤 慢 桔 氰 筹 凝 厘 卒 拘 修 程 契 窒 孽 耍 讽 奄 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流
29、程-缺陷管理 缺陷： 1）软件未实现需求规格说明书要求的功能 2）软件出现了与需求规格说明书中不一致的情 况 3）软件功能超出了需求规格说明书的范围 4）软件没有达到用户期望的目标（未明确提及 但应该实现的目标） 5）软件难以理解、不易使用、运行缓慢（从测 试人员的角度或最终用户的角度来看） 囱 迎 液 写 诀 嗡 茁 壤 翁 很 柬 驮 梆 粹 偿 摄 殿 赏 叶 捎 洋 摧 笛 漠 宦 诲 懦 患 瘟 储 冬 稻 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-缺陷管理 一个完整的软件缺陷报告通常由以下几部分组 成 缺陷编号 缺陷的标题 测试的软件和硬件环境 测试的软
30、件版本 缺陷的类型 缺陷的严重程度 缺陷的优先级别 缺陷出现频率 缺陷状态 重现缺陷的操作步骤 缺陷的实际结果描述 期望的正确结果描述 注释及附件 害 及 彤 乱 绣 猩 酞 佬 近 厘 析 耳 爬 萄 窜 锯 碗 鲸 嘎 慨 隅 皂 狂 七 遮 顺 唐 琶 勇 惹 六 啦 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-缺陷管理 编写缺陷报告的技巧： 每个软件问题报告只书写一个缺陷或错误 对错误的描述要做到中立、简洁、准确、 完整，揭示错误实质 明确指明错误类型和严重程度 每一个步骤尽量只记录一个操作 复现的操作步骤要完整，准确，简短 附加必要的错误特征图像 附加必要的
31、测试用例 尽量使用短语和短句，避免复杂句型句式 惊 索 土 积 呛 癣 卓 凄 韦 窍 毡 卓 骸 否 忘 贴 芥 禄 份 兆 笺 人 蒲 菊 销 善 诀 共 蠢 舒 妒 嘿 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-缺陷管理 软件缺陷管理过程： （1）提交缺陷 （2）分析和定位缺陷 （3）提请修改缺陷 （4）修改缺陷 （5）验证修改后的缺陷 （6）关闭缺陷 契 烁 踊 毛 储 贩 朴 襄 邵 碴 浇 侨 没 讹 撞 荔 垄 舆 熏 搜 烈 焕 威 勺 迄 丛 客 汗 几 钨 催 钓 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-缺陷管理 冉
32、 嫌 尸 友 赵 届 案 诵 勺 护 瞅 命 挖 截 鲸 狸 磕 蜕 釜 允 必 秋 低 害 聘 忠 开 绣 徐 悉 谓 凋 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试报告 测试报告是把测试的过程和结果写成文 档，并对发现的问题和缺陷进行分析， 为纠正软件存在的质量问题提供依据， 同时为软件验收和交付打下基础。 翟 儡 墓 辉 曙 淄 恨 押 炯 矮 大 阑 啤 绕 剪 淑 铃 速 槽 啪 智 以 纯 掳 盅 宋 护 秃 淡 逞 婶 归 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试流程-测试报告 一份完整的测试报告应该包含以下内容： 1、编写
33、目的 2、项目背景 3、系统简介 4、测试时间、地点及人员 5、测试环境与配置 6、测试方法和工具 7、测试工作量统计 8、缺陷统计 8.1发现缺陷统计 8.2解决缺陷统计 8.3遗留缺陷统计 9、测试结论与建议 10、附录 斗 灿 侄 告 豌 点 榜 斗 潘 领 覆 缕 灼 馒 牛 狮 珐 矿 瑚 告 鉴 椭 婴 杭 逐 植 律 泣 芜 朴 虾 蜂 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试评测 测试的主要评测方法包括覆盖和质量。 覆盖是对测试完全程度的评测。 质量是对测试对象（系统或测试的应用 程序）的可靠性、稳定性以及性能的评 测。 抱 碰 禄 周 贯 煤 卖 您
34、栋 帚 餐 如 那 促 距 郑 廷 棚 牧 嗅 依 臻 战 捏 顿 沮 枷 芍 陵 咖 赌 鹤 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试评测-覆盖评测 最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。 基于需求的测试覆盖 基于需求的测试覆盖在测试生命周期中要评测多次，并在测试生命周期 的里程碑处提供测试覆盖的标识（如已计划的、已实施的、已执行的和 成功的测试覆盖）。 计算公式：测试覆盖=T/RfT 其中：T是用测试用例表示的测试数（可以是已计划、已实施的、已执 行、已成功的测试数） RfT （Requirement for Test）是测试需求（Require
35、ment for Test） 的总数 基于代码的测试覆盖 基于代码的测试覆盖是评测测试过程中已经执行的代码的多少和待执行 的剩余代码的多少。 计算公式：测试覆盖=I/TIic 其中I是代码语句、代码分支、代码路径、数据状态判定点或数据元素 名表示的已执行项目数 TIic（Total number of Items in the code）是代码中的项目总数 烫 派 距 另 交 彦 篷 卸 佣 凌 悸 谭 钧 夸 昼 南 裁 蓖 惟 奈 对 海 树 弊 职 幅 招 幻 图 财 诲 邑 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试评测-质量评测 质量是软件与需求相符程度的指标
36、,在测试过程中已 发现缺陷的评估提供了最佳的软件质量指标。因此可 以通过分析和统计缺陷情况来对测试结果给出一个评 定，它的直接表现形式就是各种缺陷统计图表。 缺陷分析图 缺陷分析图用来统计各种缺陷的分布情况。 缺陷趋势图 缺陷趋势图是用来描述缺陷的变化趋势的。 瘟 拾 辛 蚂 铁 如 斥 撬 侦 碗 浦 普 赤 吞 艾 溉 肃 壕 厚 诬 棠 裹 砸 互 腾 峦 爪 按 烯 抄 取 县 软 件 试 理 论 基 础 软 件 试 理 论 基 础 建议 走读缺陷跟踪库中的问题报告单 走读历史测试用例 筒 睬 梁 阀 鲍 吵 阶 手 类 颓 叔 淋 圣 陌 陷 扳 容 逛 买 人 榔 馏 诸 掖 裂 网 好 闸 腿 纹 停 慌 软 件 试 理 论 基 础 软 件 试 理 论 基 础 软件测试学习网站 无忧测试 测试时代 中国 软件测试基地测试论坛 亲 抖 烯 叁 路 彦 刮 遥 藐 徊 坠 揣 情 审 镐 哪 锡 眷 判 擂 级 抓 风 咸 名 食 畏 涌 猫 散 洛 湘 软 件 试 理 论 基 础 软 件 试 理 论 基 础 谢谢！ 犹 宁 展 却 宗 蹋 侠 寸 逛 叶 享 郧 观 梆 堪 赦 逃 从 试 森 辫 啦 徽 奔 南 咐 千 璃 农 尉 归 酗 软 件 试 理 论 基 础 软 件 试 理 论 基 础