第2版 软件测试_软件测试(第2版) - CSDN
  • 下载地址:网盘下载内容简介······软件测试(原书第2版),ISBN:9787111185260,作者:(美)佩腾(Patton,R.) 著,张小松 等译;张小松译作者简介······Ron Patton具有近20年软件测试和软件质量保证...

    下载地址:网盘下载

     

     

     

    内容简介  · · · · · ·

    作者简介  · · · · · ·

    Ron Patton具有近20年软件测试和软件质量保证的工作经验,从事过各种产品的软件测试,从关键任务到儿单绘图程序。普先后就职于德州仪器公司、西门子公司和微软公司,担任过质量保证工程师、软件测试经理等职务。他现在是一个独立的软件项目管理和软件质量保证咨询师。

    目录  · · · · · ·

    第一部分 软件测试综述
    第1章 软件测试的背景 3
    1.1 臭名昭著的软件错误用例研究 3
    1.1.1 迪斯尼的狮子王,1994—1995 3
    1.1.2 英特尔奔腾浮点除法缺陷,1994 4
    1.1.3 美国航天局火星极地登陆者号探测器,1999 4
    1.1.4 爱国者导弹防御系统,1991 5
    1.1.5 千年虫问题,大约1974 5
    1.1.6 危险的预见,2004 5
    1.2 软件缺陷是什么 6
    1.2.1 软件失败的术语 6
    1.2.2 软件缺陷的官方定义 7
    1.3 为什么会出现软件缺陷 8
    1.4 软件缺陷的修复费用 9
    1.5 软件测试员究竟做些什么 10
    1.6 优秀的软件测试员应具备的素质 10
    1.7 小结 11
    1.8 小测验 12
    第2章 软件开发的过程 13
    2.1 产品的组成部分 13
    2.1.1 软件产品需要多少投入 13
    2.1.2 软件产品由哪些部分组成 16
    2.2 软件项目成员 17
    2.3 软件开发生命周期模式 18
    2.3.1 大爆炸模式 18
    2.3.2 边写边改模式 19
    2.3.3 瀑布模式 20
    2.3.4 螺旋模式 21
    2.4 小结 22
    2.5 小测验 22
    第3章 软件测试的实质 23
    3.1 测试的原则 23
    3.1.1 完全测试程序是不可能的 23
    3.1.2 软件测试是有风险的行为 24
    3.1.3 测试无法显示潜伏的软件缺陷 24
    3.1.4 找到的软件缺陷越多,就说明软件缺陷越多 25
    3.1.5 杀虫剂怪事 25
    3.1.6 并非所有软件缺陷都要修复 26
    3.1.7 什么时候才叫缺陷难以说清 27
    3.1.8 产品说明书从没有最终版本 28
    3.1.9 软件测试员在产品小组中不受欢迎 28
    3.1.10 软件测试是一项讲究条理的技术专业 28
    3.2 软件测试的术语和定义 29
    3.2.1 精确和准确 29
    3.2.2 确认和验证 30
    3.2.3 质量和可靠性 30
    3.2.4 测试和质量保证(QA) 30
    3.3 小结 31
    3.4 小测验 31
    第二部分 测试基础
    第4章 检查产品说明书 35
    4.1 开始测试 35
    4.1.1 黑盒测试和白盒测试 36
    4.1.2 静态测试和动态测试 37
    4.1.3 静态黑盒测试、测试产品说明书 37
    4.2 对产品说明书进行高级审查 37
    4.2.1 假设自己是客户 38
    4.2.2 研究现有的标准和规范 38
    4.2.3 审查和测试类似软件 39
    4.3 产品说明书的低层次测试技术 39
    4.3.1 产品说明书属性检查清单 39
    4.3.2 产品说明书术语检查清单 40
    4.4 小结 40
    4.5 小测验 40
    第5 章 带上眼罩测试软件 42
    5.1 动态黑盒测试:带上眼罩测试软件 42
    5.2 通过性测试和失效性测试 43
    5.3 等价类划分 44
    5.4 数据测试 46
    5.4.1 边界条件 47
    5.4.2 次边界条件 49
    5.4.3 默认、空白、空值、零值和无 51
    5.4.4 非法、错误、不正确和垃圾数据 52
    5.5 状态测试 53
    5.5.1 测试软件的逻辑流程 54
    5.5.2 失败状态测试 57
    5.6 其他黑盒测试技术 58
    5.6.1 像笨拙的用户那样做 58
    5.6.2 在已经找到的软件缺陷的地方再找找 59
    5.6.3 像黑客一样考虑问题 59
    5.6.4 凭借经验、直觉和预感 59
    5.7 小结 59
    5.8 小测验 60
    第6章 检查代码 61
    6.1 静态白盒测试:检查设计和代码 61
    6.2 正式审查 62
    6.2.1 同事审查 63
    6.2.2 走查 63
    6.2.3 检验 63
    6.3 编码标准和规范 64
    6.3.1 编程标准和规范示例 64
    6.3.2 获取标准 66
    6.4 通用代码审查清单 66
    6.4.1 数据引用错误 66
    6.4.2 数据声明错误 67
    6.4.3 计算错误 67
    6.4.4 比较错误 67
    6.4.5 控制流程错误 68
    6.4.6 子程序参数错误 68
    6.4.7 输入/输出错误 68
    6.4.8 其他检查 68
    6.5 小结 69
    6.6 小测验 69
    第7章 带上X光眼镜测试软件 70
    7.1 动态白盒测试 70
    7.2 动态白盒测试和调试 71
    7.3 分段测试 72
    7.3.1 单元测试和集成测试 72
    7.3.2 单元测试示例 74
    7.4 数据覆盖 75
    7.4.1 数据流 76
    7.4.2 次边界 76
    7.4.3 公式和等式 77
    7.4.4 错误强制 77
    7.5 代码覆盖 78
    7.5.1 程序语句和代码行覆盖 79
    7.5.2 分支覆盖 79
    7.5.3 条件覆盖 80
    7.6 小结 81
    7.7 小测验 81
    第三部分 运用测试技术
    第8章 配置测试 85
    8.1 配置测试综述 85
    8.1.1 分离配置缺陷 88
    8.1.2 计算工作量 89
    8.2 执行任务 90
    8.2.1 确定所需的硬件类型 90
    8.2.2 确定有哪些厂商的硬件、型号和驱动程序可用 90
    8.2.3 确定可能的硬件特性、模式和选项 91
    8.2.4 将确定后的硬件配置缩减为可控制的范围 91
    8.2.5 明确与硬件配置有关的软件唯一特性 92
    8.2.6 设计在每一种配置中执行的测试用例 93
    8.2.7 在每种配置中执行测试 93
    8.2.8 反复测试直到小组对结果满意为止 93
    8.3 获得硬件 93
    8.4 明确硬件标准 94
    8.5 对其他硬件进行配置测试 95
    8.6 小结 95
    8.7 小测验 95
    第9章 兼容性测试 96
    9.1 兼容性测试综述 96
    9.2 平台和应用程序版本 97
    9.2.1 向后和向前兼容 97
    9.2.2 测试多个版本的影响 98
    9.3 标准和规范 99
    9.3.1 高级标准和规范 99
    9.3.2 低级标准和规范 100
    9.4 数据共享兼容性 100
    9.5 小结 102
    9.6 小测验 102
    第10章 外国语言测试 103
    10.1 使文字和图片有意义 103
    10.2 翻译问题 104
    10.2.1 文本扩展 104
    10.2.2 ASCll、DBCS和Unicode 105
    10.2.3 热键和快捷键 105
    10.2.4 扩展字符 106
    10.2.5 字符计算 106
    10.2.6 从左向右和从右向左读 107
    10.2.7 图形中的文字 107
    10.2.8 让文本与代码脱离 107
    10.3 本地化问题 108
    10.3.1 内容 108
    10.3.2 数据格式 109
    10.4 配置和兼容性问题 110
    10.4.1 国外平台配置 110
    10.4.2 数据兼容性 111
    10.5 测试量有多大 112
    10.6 小结 113
    10.7 小测验 113
    第11章 易用性测试 114
    11.1 用户界面测试 114
    11.2 优秀UI由什么构成 115
    11.2.1 符合标准和规范 115
    11.2.2 直观 116
    11.2.3 一致 117
    11.2.4 灵活 117
    11.2.5 舒适 118
    11.2.6 正确 118
    11.2.7 实用 119
    11.3 为有残疾障碍的人员测试:辅助选项测试 119
    11.3.1 法律要求 120
    11.3.2 软件中的辅助特性 120
    11.4 小结 122
    11.5 小测验 122
    第12章 测试文档 123
    12.1 软件文档的类型 123
    12.2 文档测试的重要性 125
    12.3 审查文档时要找什么 126
    12.4 文档测试的实质 127
    12.5 小结 127
    12.6 小测验 127
    第13章 软件安全性测试 129
    13.1 战争游戏—电影 129
    13.2 了解动机 130
    13.3 威胁模式分析 131
    13.4 软件安全是一项功能吗?软件漏洞是一个缺陷吗 134
    13.5 了解缓冲区溢出 134
    13.6 使用安全的字符串函数 135
    13.7 计算机取证 137
    13.8 小结 139
    13.9 小测验 139
    第14章 网站测试 141
    14.1 网页基础 141
    14.2 黑盒测试 142
    14.2.1 文本 143
    14.2.2 超级链接 144
    14.2.3 图片 145
    14.2.4 表单 145
    14.2.5 对象和其他各种简单的功能 145
    14.3 灰盒测试 146
    14.4 白盒测试 147
    14.5 配置和兼容性测试 148
    14.6 易用性测试 149
    14.7 自动化测试简介 151
    14.8 小结 151
    14.9 小测验 151
    第四部分 测试的补充
    第15章 自动测试和测试工具 155
    15.1 工具和自动化的好处 155
    15.2 测试工具 156
    15.2.1 查看器和监视器 156
    15.2.2 驱动程序 157
    15.2.3 桩 158
    15.2.4 压力和负载工具 159
    15.2.5 干扰注入器和噪声发生器 159
    15.2.6 分析工具 160
    15.3 软件测试自动化 160
    15.3.1 宏录制和回放 161
    15.3.2 可编程的宏 162
    15.3.3 完全可编程的自动测试工具 163
    15.4 随机测试:猴子和大猩猩 164
    15.4.1 笨拙的猴子 165
    15.4.2 半聪明的猴子 166
    15.4.3 聪明的猴子 166
    15.5 使用测试工具和自动化的实质 168
    15.6 小结 168
    15.7 小测验 169
    第16章 缺陷轰炸和beta测试 170
    16.1 让别人测试你的软件 170
    16.2 测试共享 171
    16.3 beta测试 172
    16.4 外包测试 173
    16.5 小结 173
    16.6 小测验 174
    第五部分 使用测试文档
    第17章 计划测试工作 177
    17.1 测试计划的目标 177
    17.2 测试计划主题 178
    17.2.1 高级期望 178
    17.2.2 人、地点和事 179
    17.2.3 定义 179
    17.2.4 团队之间的责任 180
    17.2.5 哪些要测试,哪些不要测试 182
    17.2.6 测试的阶段 182
    17.2.7 测试策略 182
    17.2.8 资源需求 183
    17.2.9 测试员的任务分配 183
    17.2.10 测试进度 183
    17.2.11 测试用例 185
    17.2.12 软件缺陷报告 185
    17.2.13 度量和统计 185
    17.2.14 风险和问题 185
    17.3 小结 185
    17.4 小测验 186
    第18章 编写和跟踪测试用例 187
    18.1 测试用例计划的目标 187
    18.2 测试用例计划综述 188
    18.2.1 测试设计 189
    18.2.2 测试用例 191
    18.2.3 测试程序 192
    18.3 测试用例组织和跟踪 194
    18.4 小结 195
    18.5 小测验 195
    第19章 报告发现的问题 197
    19.1 设法修复软件缺陷 198
    19.2 分离和再现软件缺陷 200
    19.3 并非所有软件缺陷生来就是平等的 202
    19.4 软件缺陷的生命周期 203
    19.5 软件缺陷跟踪系统 205
    19.5.1 标准:测试事件报告 205
    19.5.2 手工软件缺陷报告和跟踪 206
    19.5.3 自动化软件缺陷报告和跟踪 206
    19.6 小结 210
    19.7 小测验 211
    第20章 成效评价 212
    20.1 使用软件缺陷跟踪数据库中的信息 212
    20.2 在日常测试中使用的度量 213
    20.3 常用项目级度量 216
    20.4 小结 220
    20.5 小测验 221
    第六部分 软件测试的未来
    第21章 软件质量保证 225
    21.1 质量是免费的 225
    21.2 工作现场的测试和质量保证 226
    21.2.1 软件测试 226
    21.2.2 质量保证 227
    21.2.3 软件测试团队的其他名称 228
    21.3 测试的管理和组织结构 228
    21.4 能力成熟度模型(CMM) 230
    21.5 IS0 9000 232
    21.6 小结 233
    21.7 小测验 233
    第22章 软件测试员的职业 234
    22.1 软件测试员的工作 234
    22.2 寻求软件测试职位 235
    22.3 获得亲身体验 236
    22.4 正规培训机会 237
    22.5 网站 237
    22.6 专注于软件和软件质量的专业组织 238
    22.7 更进一步阅读 238
    22.8 小结 239
    22.9 小测验 240
    附录A 小测验问题解答 241

     

     

     

    下载地址:网盘下载

     

    转载于:https://www.cnblogs.com/long12365/p/9730677.html

    展开全文
  • 本书是佩腾的软件测试,是学习软件测试必备书籍
  • 该书全面系统地介绍了软件测试理论及应用技术,不仅讲述基本的测试技能,也讲述成为一个成功的软件测试员所必须掌握的高级技能。   一部分 软件测试综述 1章 软件测试的背景 软件错误实例:迪斯尼的狮子王...

        该书全面系统地介绍了软件测试理论及应用技术,不仅讲述基本的测试技能,也讲述成为一个成功的软件测试员所必须掌握的高级技能。

     

    第一部分 软件测试综述

    第1章 软件测试的背景

    软件错误实例:迪斯尼的狮子王游戏在大多数系统不能运行;爱国者导弹系统时钟累积错误;千年虫(年份用两位数表示)出现问题等。

    产品说明书对开发的产品进行定义,给出产品细节、如何做、做什么、不能做什么。

    至少满足如下5个规则之一才称软件缺陷:1.软件未实现产品说明书的要求;2.软件出现产品说明书指明不该出现的错误;3.软件出现产品说明书未提及功能;4.软件未实现产品说明书虽未明确提及但应实现的功能;5.软件难以理解,不易使用、运行缓慢。

    软件缺陷来源:产品说明书、设计、编码、其他。修复费用越往后越多,指数级增长。

    软件测试员目标是尽可能早地发现软件缺陷,并确保其得以修复。

    第2章 软件开发的过程

    软件产品需要多少投入:客户需求;产品说明书;进度表;软件设计文档;测试文档(测试计划、测试用例、缺陷报告、测试工具和自动化测试、度量和统计)。

    软件产品包括:帮助文件、用户手册、样本和示例、标签和不干胶、产品支持信息、图标和标志、错误信息、广告和宣传材料、安装、说明文件。

    软件项目成员:项目经理、系统架构师、程序开发人员、测试员、技术作者、配置管理员。

    软件开发生命周期模式:大爆炸模式、边写边改模式、瀑布模式(构思-分析-设计-开发-测试)、螺旋模式(测试员通过参与最初设计阶段,可以尽早影响到产品,可以把产品来龙去脉弄清楚)。

    敏捷软件开发:快速原型、极限编程或进化开发。

    第3章 软件测试的实质

    测试的原则:完全测试程序不可能;软件测试有风险;测试无法显示潜伏的软件缺陷;找到的软件缺陷越多,说明软件缺陷越多;杀虫剂抵抗力怪事;并非所有缺陷都修复;什么时候叫缺陷难以说清;产品说明书没有最终版本;软件测试员在产品小组不受欢迎;软件测试是一项讲究条理的技术专业。

    术语:精确和准确;确认(保证软件符合产品说明书的过程)和验证(保证软件满足用户要求的过程);质量(满足客户要求)和可靠性(稳定,是质量的一方面);测试和质量保证。

    第二部分 测试基础

    第4章 检查产品说明书

    描述测试方式的术语:黑盒测试(功能性测试/行为测试)和白盒测试(透明盒测试)。静态测试(检查和审核)和动态测试(使用和运行软件)。

    测试产品说明书属于静态黑盒测试。

    测试产品说明书第一步是高级审查:假设自己是客户;研究现有的标准和规范;审查和测试类似软件。

    产品说明书低层次测试技术:产品说明书属性检查清单:完整;准确;精确;一致;贴切;合理;代码无关;可测试性。

    第5章 带上眼罩测试软件

    测试用例(test case)是指进行测试时使用的特定输入,以及测试软件的过程步骤。

    通过性测试(至少能做什么)和失效性测试(搞垮它)。

    等价类划分是指分步骤地把海量测试用例缩减得很小,但过程同样有效。

    数据测试等价类划分原则:边界条件;次边界条件;默认、空白、空值和无;非法、错误、不正确和垃圾数据。

    状态转换图应该表示出:软件可能进入的每一种独立状态;从一种状态进入另一种状态的输入和条件。进入或者退出状态的设置条件及输出结果。

    通过性状态测试:检查软件、描绘状态、尝试各种合法可能性、确认状态及其转换正常。

    失效性状态测试:竞争条件和时序错乱、重复、压迫和重负。

    第6章 检查代码

    静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码,从而找出软件缺陷的过程,有时也称为结构化分析。

    正式审查是进行静态白盒测试的过程,包括4个基本要素:确定问题;遵守规则;准备;编写报告。

    编码标准和规范:可靠性;可读性/维护性;移植性。

    通用代码审查清单:数据引用错误(导致缓冲区溢出,安全缺陷);数据声明错误;计算错误;比较错误;控制流程错误;子程序参数错误;输入/输出错误;其他检查。

    第7章 带上X光眼镜测试

    动态白盒测试是指利用查看代码功能(做什么)和实现方式(怎么做)得到的信息来确定哪些需要测试、哪些不需要测试、如何开展测试,也称结构化测试。

    单元测试/模块测试、集成测试、系统测试

    递增测试两条途径:自底向上(测试驱动调用被测试模块)和自顶向下(测试桩)。

    数据覆盖:数据流、次边界、公式和等式、错误强制。

    代码覆盖:程序语句和代码行覆盖、分支覆盖、条件覆盖。

    第三部分 运用测试技术

    第8章 配置测试

    执行任务:1、确定所需硬件类型。2、确定有哪些厂商的硬件、型号和驱动程序可用。3.确定可能的硬件特性、模式和选项。4、将确定后的硬件配置缩减为可控制的范围。5、明确与硬件配置有关的软件唯一特性。6、设计在每一种配置中执行的测试用例。7、在每种配置中执行测试。8、反复测试直到小组对结果满意为止。

    第9章 兼容性测试

    软件兼容性测试是指检查软件之间是否能够正确地交互和共享信息。

    向后兼容(可以使用软件以前版本)和向前兼容(可以使用软件未来版本)。

    高级标准和规范是产品普遍遵守的原则,低级标准是本质细节。

    兼容性测试记住3点:对兼容软件的所有可能选择进行等价划分;研究适用于测试软件的高级/低级标准和规范;测试软件程序之间的不同数据流动方式。

    第10章 外国语言测试

    使软件适应地域特征,照顾到语言、方言、地区习俗和文化的过程称为本地化或国际化。

    翻译问题:文本扩展;ASCII;热键和快捷键;扩展字符;字符计算;从左向右和从右向左读;图形中的文字;让文本与代码脱离。

    本地化问题:内容,数据格式。

    配置和兼容性问题:国外平台配置,数据兼容性。

    第11章 易用性测试

    优秀UI具备的7个要素:符合标准和规范;直观;一致;灵活;舒适;正确;实用。

    为有残疾障碍的人员测试:辅助选项测试。

    第12章 测试文档

    文档包括:市场宣传材料、广告,授权登记表,标签和不干胶,安装和设置指导,用户手册,联机帮助,指南,样本和示例,错误提示信息等。

    好的软件文档可提高软件易用性、可靠性,降低支持费用。

    文档测试检测清单:通用部分:听众、术语、内容和主题;正确性:紧扣事实、逐步执行;检查的内容:图表和截图、样本和示例、拼写和语法。

    第13章 软件安全性测试

    黑客动机:挑战/成名,好奇,借用,恶意破坏(丑化、破坏、拒绝服务),偷窃。

    威胁模型分析,整个项目小组执行的正式过程,用于评估软件系统的安全问题。

    了解缓冲区溢出,使用安全的字符串函数,计算机取证。

    第14章 网站测试

    黑盒测试:文本(当作文档对待);超级链接;图片;表单(用于输入和选择信息的文本框、列表框和其他域);对象和其他各种简单功能。

    灰盒测试(介于白盒和黑盒之间)适合网页测试,HTML(超文本标记语言)

    白盒测试,网站系统结构和编程知识:动态内容;数据库驱动的网页;用编程方法创建的网页;服务器性能和加载;安全性。

    配置和兼容性测试,易用性测试。

    第四部分 测试的补充

    第15章 自动测试和测试工具

    重复执行测试的过程称为回归测试。

    工具和自动化的主要属性:速度;效率;准确度和精确度;节省资源;仿真和模拟;坚持不懈。

    测试工具:查看器/监视器;驱动程序;桩;压力和负载工具;干扰注入器和噪声发生器;分析工具。

    软件测试自动化可以执行测试用例,查找软件缺陷,分析看到的信息,记录结果。

    自动化:宏录制和回放;可编程的宏;完全可编程的自动测试工具。

    随机测试:模拟用户可能的操作,测试猴子。

    第16章 缺陷轰炸和beta测试

    让别人测试你的软件,测试共享:整个测试小组参加缺陷轰炸。

    Beta测试是用于描述外部测试过程的术语。在该过程中,软件分发给选定的潜在客户群,让他们在实际环境中使用软件。

    外包测试,配置和兼容性测试通常是外包测试的理想选择。

    第五部分 使用测试文档

    第17章 计划测试工作

    测试计划的目的:规定测试活动的范围、方法、资源和进度;明确正在测试的项目、要测试的特性、要执行的测试任务、每个任务的负责人,以及与计划相关的风险。

    测试计划主题:高级期望;人、地点和事;定义;团队之间的责任;哪些要测试、哪些不要测试;测试的阶段;测试策略;资源需求;测试员的任务分配;测试进度;测试用例;软件缺陷报告;度量和统计。风险和问题。

    第18章 编写和跟踪测试用例

    有条不紊地仔细计划测试用例的重要性:组织;重复性;跟踪;测试证实。

    测试用例计划综述:测试设计说明——测试用例说明——测试过程说明。

    测试用例组织和跟踪:凭脑子记;书面文档;电子表格;自定义数据库。

    第19章 报告发现的问题

    不修复软件缺陷的原因:没有足够时间;不算真正的软件缺陷;修复风险太大;不值得修复;无效的软件缺陷报告。

    报告软件缺陷的原则:尽快报告软件缺陷;有效描述软件缺陷(短小,单一,明显并通用,可再现);在报告软件缺陷时不评价;对软件缺陷报告跟踪到底。

    软件缺陷分等级:严重性和优先级。

    软件缺陷生命周期:打开、解决、(审查、推迟、)关闭。

    软件缺陷跟踪系统:标准,测试事件报告;手工软件缺陷和跟踪;自动化软件缺陷报告和跟踪。

    第20章 成效评价

    在日常测试中使用的度量;常用项目级度量。

    使用度量的目的是评估测试员和项目的成效,获知一切是否按预定计划进行,如果不是,应该修正。

    打开的缺陷   修复/解决的缺陷    关闭的缺陷

    第六部分 软件测试的未来

    第21章 软件质量保证

    一致性费用是指与一次性计划和执行测试相关的全部费用,用于保证软件按照预期方式运行。

    软件质量保证人员的主要职责是检查和评价当前软件开发的过程,找出改进过程的方法,已达到防止软件缺陷出现的目的。

    QA质量保证,QC质量控制,QM质量管理

    能力成熟度模型(CMM)1.初始的,随意和混乱的过程;2.可重复的,项目级的思想;3.定义的,组织级别的思想;4.可管理的,可控制的过程。5.不断优化的。

    ISO9000(国际标准化组织),ISO9000-3(负责开发、供应、安装和维护计算机软件方面的事务)。

    第22章 软件测试员的职业

    软件测试技术人员、软件测试员或者软件测试工程师、软件测试工具开发师或软件测试开发工程师、软件测试负责人、软件测试经理。

    开源代码测试

    计算机用户的权利议案:观点;安装;服从;指示;控制;反馈;依赖;范围;协助;易用性。(用户第一)

     



    展开全文
  • 软件测试过程中,最主要的就是要掌握好软件测试的方法,掌握好了软件测试方法,有利于测试技能的大幅度提高。 软件测试方法 软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样...

          软件测试过程中,最主要的就是要掌握好软件测试的方法,掌握好了软件测试方法,有利于测试技能的大幅度提高。

    软件测试方法

           软件测试方法是指测试软件的方法。随着软件测试技术的不断发展,测试方法也越来越多样化,针对性更强;选择合适的软件测试方法可以让我们事半功倍。

    一、根据是否要走查代码,分为白盒测试、灰盒测试、黑盒测试;

    二、分为手工测试、自动化测试和性能测试:

    手工测试:UI测试、冒烟测试、随机测试、本地化测试、安装测试、卸载测试;

    自动化测试:

    性能测试:健全测试、衰竭测试、负载测试、强迫测试、压力测试、恢复测试;

    三、根据是否要运行程序,分为静态测试和动态测试;

    四、按测试阶段可分为:单元测试、集成测试、系统测试、回归测试、验收测试、α测试_Alpha测试、β测试,英文是Beta testing。又称Beta测试,用户验收测试(UAT);

    五、其他测试方法:端到端测试、接受测试、安全测试、兼容性测试、可用性测试、比较测试、边界测试、强力测试、装配安装测试、隐藏数据测试、等价划分测试、判定表测试、深度测试、基于设计、文档测试、域测试、接口测试、逆向测试、非功能性测试、极限测试等。

    其中一些测试方法的定义

    端到端

           端到端测试,英文是End to End Testing。

           端到端测试类似于系统测试,测试级的“宏大”的端点,涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话,用网络通讯,或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试及性能测试。端到端架构测试实质上是一种"灰盒"测试,一种集合了白盒测试和黑盒测试的优点的测试方法。

    健全测试

           健全测试,英文是Sanity testing。

           健全测试是指一个初始化的测试工作,以决定一个新的软件版本测试是否足以执行下一步大的测试能力。例如,如果一个新版软件每5分钟与系统冲突,使系统陷于泥潭,说明该软件不够“健全”,不具备进一步测试的条件。

    衰竭测试

          衰竭测试,英文是Failure Testing。

          衰竭测试是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

    负载测试

           负载测试,英文是Load testing。

           负载测试是测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下,何时系统的响应会退化或失败,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。

    负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    强迫测试

           强迫测试,英文是Force Testing。

           强迫测试是在交替进行负荷和性能测试时常用的术语。也用于描述对象在异乎寻常的重载下的系统功能测试之类的测试,如某个动作或输入大量的重复,大量数据的输入,对一个数据库系统大量的复杂查询等。

    压力测试

           压力测试,英文是Stress Testing。和负载测试差不多。

           压力测试是一种基本的质量保证行为,它是每个重要软件测试工作的一部分。压力测试的基本思路很简单:不是在常规条件下运行手动或自动测试,而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。

    恢复测试

           恢复测试,英文是Recovery testing。

           恢复测试是测试一个系统从如下灾难中能否很好地恢复,如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件(或者硬件)出现故障来检测系统是否能正确的恢复,通常关注恢复所需的时间以及恢复的程度。

           恢复测试主要检查系统的容错能力。当系统出错时,能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败,然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化(reinitialization)、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性;对于人工干预的恢复系统,还需估测平均恢复时间,确定其是否在可接受的范围内。

     

    可用性

           可用性测试,英文是Practical Usability Testing。

           可用性测试是对“用户友好性”的测试。显然这是主观的,且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

    比较测试

           比较测试,英文是Compare Testing。

           比较测试是指与竞争伙伴的产品的比较测试,如软件的弱点、优点或实力。来取长补短,以增强产品的竞争力。

    强力测试

           强力测试,英文是Mightiness Testing。

           强力测试通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如,在最低的硬盘驱动器空间或系统记忆容量条件下,验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。

    装配安装

           装配/安装/配置测试是验证软件程序在不同厂家的硬件上,所支持的不同语言的新旧版本平台上,和不同方式安装的软件都能够如预期的那样正确运行。比如,把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上,再验证所有功能都正常运行。

    隐藏数据

           隐藏数据测试在软件验收和确认阶段是十分必要和重要的一部分。程序的质量不仅仅通过用户界面的可视化数据来验证,而且必须包括遍历系统的所有数据。

           假设一个应用程序要求用户两条信息-----用户名和密码来创建帐户。这个用户输入这两条数据后保存。最后,一个确认窗口将通过数据库中找到这条数据来显示用户名和密码给用户。为了验证所有的数据保存是否正确,一个QA测试人员会在这个确认窗口简单的查看下用户名和密码。如果他们成功了?假设数据库记录了第三条信息----创建日期,它可能不会出现在确认窗口,而只在存档中才出现。如果创建日期保留的不正确,而QA测试人员只验证屏幕上的数据,那么这个问题就不可能被发现。创建日期可能就是一个bug,由于一个用户帐户保存了一个错误的日期到数据库中,这个问题也不可能会被引起注意,因为它被用户界面所隐藏。这只是一个简单的例子,但是它却演化出了一点:隐藏数据测试的重要性。

    判定表

           判定表的英文是decision table,是指一个表格,用于显示条件和条件导致动作的集合。

           定义:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

           判定表的优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。

           在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题

    深度测试

           深度测试的英文Depth test ,是指执行一个产品的一个特性的所有细节,但不测试所有特性。

          当比较函数返回真的时候才显示出效果来。必须启用“#深度测试”,才能执行测试。不使用的时候需要关闭。

    基于设计

           基于设计的测试的英文是design-based testing,是根据软件的构架或详细设计引出测试用例的一种方法。

           一种基于设计模型的测试方法(Model Based TestIng System,MATIS).该方法利用用户界面自动生成方法,把设计模型中的类属性定义和实现中的控件属性组织在一起,构建描述界面的逻辑对照表,辅助测试脚本引擎执行自动测试脚本.借助设计模型中扩展的类定义,MATIS方法可以自动生成测试用例和测试数据。

    域测试

           域测试的英文是domain testing,定义参考等价划分测试(equivalence partition testing);

           一般分为单域测试和多域测试,其中单域测试包括设备测试和业务测试,设备测试包括测试某个系统的软交换设备、中继媒体网关设备、信令网关设备、接入媒体网关和IAD等设备。

           等价类划分有两种不同的情况:有效等价类和无效等价类。设计时要同时考虑这两种等价类,因为软件不仅要能接收合理的数据,也要能经受意外的考验。

           一有效等价类:是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

           二无效等价类:与有效等价类的定义恰巧相反。

    逆向测试

           逆向测试/反向测试/负面测试的英文是Negative Testing,测试瞄准于使系统不能工作。

           负面测试与正面测试的比较:

           负面测试(Negative testing)是相对于正面测试(Positive testing)而言的。它们也是测试设计时的两个非常重要的划分。简单点说,正面测试就是测试系统是否完成了它应该完成的工作;而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点,正面测试就象一个毕恭毕敬的小学生,老师叫我做什么,我就做什么;而负面测试就象一个调皮捣蛋的孩子,你叫我这样做,我偏不这样做,而且和你对着干。开发人员也是最讨厌修改此类bug的。

    非功能性

           非功能性需求测试的英文是non-functional requirements testing ,是与功能不相关的需求测试,如:性能测试、可用性测试等。

           为什么非功能性需求很重要?

           在您设计解决方案的过程中满足功能性需求当然是很重要的。但是,如果没有考虑非功能性需求,您的解决方案则很难取得实效。

           非功能性需求特点:1.不要脱离实际环境;2.可靠性;3.可用性;4.有效性;5.可维护性;6.可移植性。

    极限测试

    简介

    极限测试本质上是为了满足极限测试的思想和流程而设计的一套测试策略和流程,其本身并不局限于使用特定的测试技术和方法。

    过程

    1.单元测试

    2.验收测试

        要熟记各个测试方法的意义,并且,灵活的运用它,这样,测试技能,将能更上一层楼。 

     

     

     

     

     

     

     

     

     

     

     

    展开全文
  • 软件测试复习(部分) 概述 程序+文档+数据=软件 狭义的软件测试定义:为发现软件缺陷而执行程序或系统的过程 广义的软件测试定义:人工或自动地运行或测定某系统的过程,目的在于检验它是否满足规定的需求或...

    软件测试

    概述

    程序+文档+数据=软件

    狭义的软件测试定义:为发现软件缺陷而执行程序或系统的过程

    广义的软件测试定义:人工或自动地运行或测定某系统的过程,目的在于检验它是否满足规定的需求或弄清预期结果和实际结果间的差别

    为什么要做软件测试

    • 发现软件缺陷
      • 功能错
      • 功能遗漏
      • 超出需求部分(画蛇添足)
      • 性能不符合要求
    • 软件质量高低:是否符合用户习惯、符合用户需求

    测试的任务

    • 找出
    • 定位
    • 修改
    • 修改后要做回归测试,对已修改的部分进行再次的测试,避免引入新的错误

    测试用例的定义和组成部分

    • 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说,测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。
    • 包含
      • 用例ID
      • 用例名称
      • 测试目的
      • 测试环境
      • 前提条件
      • 测试步骤
      • 预期结果
      • 其他信息

    一个好的高质量的测试用例在于能发现至今未发现的错误,一个成功的测试是发现了至今未发现的错误的测试(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    两个方向

    • 找错误,反向思维。
    • 证明能正常工作,正向思维。
    • 目前的方法出发点一般是“找错误”,因为没法证明软件是正确的。

    用户需求

    要求(用户想要) 需求(用户目的) 需要(用户内在欲望)
    牙膏 清洁牙齿 个人魅力(个人外表整洁)

    什么时候停止测试

    • 继续测试没有产生新的失效
    • 继续测试没有发现新缺陷
    • 回报很小
    • 以达到要求的覆盖
    • 无法考虑新的测试用例(若已遵循测试规则和指导方针,则可以选择)

    测试过程模型

    缺陷具有放大的特点,随着阶段的推进发现bug的成本会指数型上升,所以并不是代码级的测试才叫测试,而是开发过程各个阶段越早开始测试越好。

    • 瀑布模型:需求分析->设计(概要、详细)->编程->测试(单元、集成、系统)->维护
    • V模型(瀑布-改):在软件开发的生存期,开发活动和测试活动几乎同时的开始,如概要设计阶段结束后集成测试的测试用例就出来了、详细设计阶段结束后单元测试的测试用例也就出来了等
    • W模型(V模型更加细化、每步都加测试,边造软件边进行测试):需求分析加了需求测试、概要设计加了功能测试、详细设计加了设计测试、编码加了单元测试、集成加了集成测试、确认加了确认测试、验收加了系统测试
    • H模型:无实际意义,仅说明可以独立测试

    软件测试的原则

    • 所有的测试都应追溯到用户的需求
    • 尽早地和不断地进行软件测试(缺陷具有放大的特点,测试成本随阶段深入而上升)
    • 8-2原则
      • 测试中发现的错误80%很可能起源于程序中的20%
      • 提前测试可发现80%,系统测试找出剩余bug的80%(总体的16%),最后的4%可能只有用户大范围长时间使用后才暴露出来
      • 80%的工程用在20%的需求上(即关键需求)
    • 软件缺陷的寄生虫性:找到的缺陷越多说明软件遗留的缺陷越多
    • 避免自己测试自己的程序
    • 回归测试:避免引入新的错误

    软件测试流程

    制定测试计划->测试设计->测试开发->测试执行->评估测试

    注意

    • 测试不是开发后期的一个阶段
    • 测试入门其实稍容易,但要求技术一样高
    • 测试多数情况下不能覆盖所有输入
    • 不要“有时间多测,没时间少测”
    • 软件测试不止是测试人员的事,也是开发人员的事
    • 调试和测试不一样
    • 测试绝非只运行一下软件看结果对不对

    L10N:本地化测试

    I18N:国际化测试

    黑盒测试

    等价类划分与边界值分析

    如何划分有效和无效等价类(一些常用原则)

    • 如果一个变量在某一个范围内,给它一个有效等价类两个无效等价类
    • 如果一个变量取值在某一个集合范围内,可在集合内取一个有效等价类在集合外取一个无效等价类
    • 如果一个变量的条件是“必须怎样”、“一定会是怎样”则去一个值满足“必须要”的条件再取多个不满足的从多个角度去违背这个条件
    • 如果一个变量是布尔类型,则取一个对的一个错的

    在找到有效等价类和无效等价类后如何找测试数据

    • 有效等价类:要尽可能多的覆盖有效等价类
    • 无效等价类:每找到一组数据要至少覆盖一组无效等价类

    如果功能模块的输入是多个,多个自变量放在一起如何找有效等价类、无效等价类、测试数据,4钟方法:

    以一个具有自变量X1、X2的函数F为例,X1取值范围为[a, b)、[b, c)、[c, d];X2取值范围为[e, f)、[f, g]。仅考虑有标记的方块内为一般等价类测试(不处理无效数据的测试)、所有方块都考虑为健壮等价类测试(进行无效数据处理的测试)

    g |_______|_______|_______|_______|_______|
    f |_______|///////|///////|///////|_______|
    e |_______|///////|///////|///////|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    • 弱一般等价类
      • 有假设前提:是单缺陷的,即假设系统出现的缺陷很少是由两个及以上的输入变量共同出现缺陷而引起的。
      • 选取的测试用例覆盖所有的有效等价类
        • 对于X1(横轴):[a, b)、[b, c)、[c, d]都需要覆盖到;对于X2(纵轴):[e, f)、[f, g]都需要覆盖到。保证了这两点的情况下,就可以任意取点了
    g |_______|_______|_______|_______|_______|
    f |_______|_______|____x__|_______|_______|
    e |_______|___x___|_______|___x___|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    • 强一般等价类
      • 基于多缺陷假设
      • 选取的测试用例覆盖所有的有效等价类的笛卡尔积(集合A{a1,a2,a3} 集合B{b1,b2} 他们的 笛卡尔积 是 A*B ={(a1,b1),(a1,b2),(a2,b1),(a2,b2),(a3,b1),(a3,b2)} )
        • 对于X1(横轴):[a, b)、[b, c)、[c, d];X2(纵轴):[e, f)、[f, g],笛卡尔积的结果就是所有的格子,所以必须所有格子都取点
    g |_______|_______|_______|_______|_______|
    f |_______|___x___|___x___|___x___|_______|
    e |_______|___x___|___x___|___x___|_______|
      |_______|_______|_______|_______|_______|
              a       b       c       d
    • 弱健壮等价类
      • 有假设前提:是单缺陷的,即假设系统出现的缺陷很少是由两个及以上的输入变量共同出现缺陷而引起的。
      • 考虑无效值,对有效输入,测试用例的设计等同于弱一般等价类;对无效输入,测试用例需要保证拥有一个无效值(比如某一变量的有效类的取值范围为x、y、z,则无效类为x-和z+,加起来取值范围一共:x-、x、y、z、z+),并保持其余的值都是有效的。

    所以如下图,在保证弱一般等价类的取点后,还需要分别保证X1、X2中有1个属于无效输入的两个额外的取值范围,另一个属于有效输入的原本取值范围(如X1取无效X2取有效或X1取有效X2取无效,并全部覆盖无效范围)

    g |_______|_______|_______|___O___|_______|
    f |_______|_______|___x___|_______|___O___|
    e |___O___|___x___|_______|___x___|_______|
      |_______|___O___|_______|_______|_______|
              a       b       c       d
    • 强健壮等价类
      • 基于多缺陷假设
      • 所有的取值范围取笛卡尔积(比如某一变量的有效类的取值范围为x、y、z,则无效类为x-和z+,加起来取值范围一共:x-、x、y、z、z+,再与另一变量的取值范围取笛卡尔积)
    g |___O___|___O___|___O___|___O___|___O___|
    f |___O___|___x___|___x___|___x___|___O___|
    e |___O___|___x___|___x___|___x___|___O___|
      |___O___|___O___|___O___|___O___|___O___|
              a       b       c       d

    在找测试数据时(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    • 对于单缺陷的,即只有一个输入变量是处于无效等价类,其他所有输入变量都处在有效等价类中。包含:
      • 单缺陷有效值
      • 单缺陷无效值
    • 对于多缺陷的,即多个输入变量同时出现错误引起的。包含:
      • 有效值
      • 无效值

    与等价类划分密切相关的就是边界值分析。先划分等价类,再结合边界值产生测试用例。边界值分析中也有假设前提:单缺陷。包含4种设计测试用例的方法:

    • 一般的边界值分析
      • 有效范围:最小的、比最小大一点的、正常值、比最大小一点、最大值
      • 无效范围:比最小更小、比最大更大
      • 共7个,再分单缺陷和多缺陷,这样设计测试用例的个数就会指数上升
    - 单变量假设 多变量假设
    有效值 **一般边界值**5n-(n-1)【n-1个变量取正常值】=4n+1【仅考虑有效区间单个变量边界值(一般边界值):用最小值、略高于最小值、正常值、略低于最大值和最大值。】 **一般最坏情况边界值**5^n【仅考虑有效区间多个变量边界值同时作用(一般最坏情况边界值):用各个变量最小值、略高于最小值、正常值、略低于最大值和最大值的笛卡尔积。】
    无效值 **健壮性边界值**7n-(n-1)=6n+1【 同时考虑有效区间和无效区间单个变量边界值(健壮边界值):除了最小值、略高于最小值、正常值、略低于最大值、最大值,还要有略超过最大值和略小于最小值的值。】 **健壮最坏情况边界值**7^n【同时考虑有效区间和无效区间多个变量边界值同时作用(健壮最坏情况边界值):用各个变量最小值、略高于最小值、正常值、略低于最大值、最大值、略超过最大值和略小于最小值的笛卡尔积。】

    常见的边界值

    • 16bit整数32767~-32768
    • 报表第一行和最后一行
    • 屏幕光标最左上和最右下
    • 数组的第一个和最后一个
    • 循环的第0、1、倒数第一、倒数第二次

    决策表

    适合于问题有多个条件,条件有多种组合执行不同操作(有很多if、else if、else),不能表达循环结构

    最严格、最具有逻辑性

    判定表
    | 条件桩 | 条件项 | ... | 动作项 |
    | 动作桩 | 动作项 | ... | 动作项 |

    规则:条件的任意组合,判定表中的一列(贯穿条件项和动作项)。判定表有多少列就代表有多少条规则。

    规则的化简:有的规则相互包含,可以化简

    因果图

    找出所有的原因,找出结果,可能还有中间结果的产生,在画因果图时注意。

    • 从输入考虑
      • I:连虚线出去,如连到ab,表示ab中至少有一个必须成立
      • E:连虚线出去,如连到ab,表示ab不能同时成立
      • R:如处于a指向b的虚线三角箭头上,表示a出现时b也必须出现,不可能一个出现一个不出现
    • 从输出考虑
      • M:如处于a指向b的虚线三角箭头上,表示a为1时b必须为0,a为0时b值不定
    • 连线:恒等
    • ~:非
    • ∨:或
    • ∧:且
    • ci:原因
    • ei:结果

    画出因果图后,根据图得到决策表从而得到相应的测试数据:原因节点+中间节点为条件桩,结果结点为动作桩

    白盒测试

    逻辑覆盖

    语句覆盖->判定覆盖->判定/条件覆盖->条件组合覆盖->路径覆盖
          \_条件覆盖/
    • 语句覆盖:每条语句执行一次
    • 判定覆盖:每个判定分支至少执行一次
    • 条件覆盖:每个判定条件应取到各种可能的值
    • 判定/条件覆盖:同时满足判定和条件
    • 条件组合覆盖:每个判定条件的每一种组合各出现一次
    • 路径覆盖:每一条可能的路径至少执行一次

    关系:

    • 条件组合覆盖>判定覆盖>语句覆盖(即如果达到条件组合覆盖,就达到判定覆盖和语句覆盖:如果达到判定覆盖,就达到语句覆盖,下面类似理解)。
    • 条件组合覆盖>条件覆盖。
    • 条件覆盖不一定包含判定覆盖、语句覆盖。
    • 判定覆盖不一定包含条件覆盖。
    • 路径覆盖,判定覆盖>语句覆盖。

    基本路径测试

    基于程序圈复杂度产生的测试方法,画出控制流程图,算圈复杂度,找到独立路径并压缩为基本路径集合,根据集合中每条路径设计用例。把复合逻辑表达式拆成单个表达式

    圈复杂度用于计算程序的基本的独立路径数目(每条新的独立路径都必须包含一条新的有向边,从入口到出口互不相同的路径数)

    • 圈复杂的V(G) = e - n + 2p【边-节点+2*连接区域数,连接区域p通常为1】=P+1【判定节点数+1】
    • 一般来说,一个单元模块的最大复杂度V(G)<10

    如果把覆盖的路径数压缩到一定限度内,例如程序中的循环体只执行0次和1次,就成为基本路径测试,通过导出基本路径集合,从而设计测试用例,保证这些路径至少通过一次

    基于数据流的测试

    基于真的数据定义到数据的使用来进行测试,需要找到定义的节点(包括赋值的和比较的)和使用的节点(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    • 定义节点DEF:输入语句、赋值语句、循环语句和过程调用;变量的值会发生变化的语句
    • 使用节点USE:数出语句、赋值语句、条件语句、循环控制语句、过程调用

    需要找到所有这段功能代码从哪里开始定义,到哪里开始执行,把路径找出来。什么是定义使用路径(某一变量在最初节点定义到最终节点被使用)、定义清除路径(某一个变量从它的定义节点到使用节点这个过程中没有对这个变量进行二次定义)

    循环测试

    前提是程序是结构化的。

    简单循环测试

    • 0次通过循环
    • 1次通过循环
    • 2次通过循环
    • m次通过循环(m<=循环最大次数)
    • m-1,m,m+1次通过循环

    测试的过程

    单元测试

    单元测试的内容:5点(简答题)

    • 模块接口的测试
    • 局部数据结构的测试
    • 独立路径测试
    • 错误处理测试
    • 边界测试

    单元测试的模块

    • 被测模块:被测试的程序的模块
    • 驱动模块:用来模拟测试模块的上一级模块,相当于被测模块的主程序
    • 桩模块:用来模拟被测模块工作过程中所调用的模块

    单元测试的工具:Junit相关的概念:以插入断言的方式进行测试(类似黑盒测试)

    • 针对被测代码或者被测的功能点先创建测试类,然后在类里面创建一个个测试方法。通过实例化对象调用被测方法,用断言进行实际值预期值比较。

    单元测试的方法

    • 以白盒测试法为主(覆盖),先静态检查代码是否符合规范,再动态运行代码,检查结果。除了需要验证结果是否正确,还需要检查程序的容错能力、边界值处理等问题。

    集成测试

    • 一次性的集成big-bang:把所有通过了单元测试的模块按设计要求一次全部组装起来,然后进行整体测试。时间随变短了但急于求成。
    • 渐进地集成
      • 自上而下:从主程序模块开始按深度或广度优先策略边组装边测试
      • 自下而上:从最底层模块开始组装和集成测试
      • 汉堡包:两者进行结合,树状图每层画线,顶层采用自顶向下,底层采用自底向上
        相邻的集成:上下三层进行集成
        成对集成:先成对再相邻
        基于MM路径的集成:MM路径不是可执行路径,描述单元之间的控制转移。

    最终得到调用图,然后就会到基本路径测试,找复杂度,找路径,得到测试用例的套路

    系统测试

    黑盒为主(Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)

    对哪些内容进行系统测试(9个):易用性、国际化本地化、性能、功能、界面、兼容性、安全性、文档、安装

    Web系统测试

    具体到如Web系统测试中的功能测试包含哪些内容、对cookies里面的内容进行测试属于Web系统测试里面的哪一项的测试(属于功能测试)

    • 功能测试
      • 页面内容测试
      • 页面链接测试
      • 表单测试
      • Cookies测试、Session测试
      • 设计语言测试
      • 数据库测试
    • 性能测试(负载/压力)
      • 连接速度测试
      • 测试工具 LoadRunner
        • 负载测试
        • 压力测试
      • 网页性能Firefox插件:Yslow,Findbug,PageSpeed
      • Dynatrace检查网页性能
    • 可靠性测试:不间断测试,看多久不出错
    • 用户界面测试/易用性测试
      • 导航测试
      • 图形测试
      • 内容测试
      • 整体界面测试
    • 安全性测试
    • 兼容性测试
    • 接口测试
      • 服务器接口
      • 外部接口
      • 错误处理

    主要讲了性能测试的含义和怎么做,如所涵盖的含义如压力测试怎么做、负载测试怎么做等

    • 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
      • 时间性能:软件的一个具体事务的响应时间
      • 空间性能:软件运行时所消耗的系统资源
      • 我让你背1袋米(轻松)
      • 我让你背1袋米,但让你去操场上跑圈,看多久累倒(吃力)
      • 我让你背3袋米去操场跑圈,看多久累倒(极限)
      • 我让你背1袋、2袋、3袋、4袋…发现最多背3袋
    • 负载测试让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的可靠性。
      • 系统能否处理某个时刻同时访问Web系统/某个页面的用户数量
      • 超过了这个数量,会出现什么现象?
      • 在线数据处理的数量
    • 负载/压力测试关注什么?
      • 验证系统能否同一时间响应大量的用户,用户传送大量数据时能否响应,系统能否长时间运行。
        • 瞬间访问高峰
        • 每个用户传送大量数据
        • 长时间使用
    • LoadRunner性能测试工具原理:录制+回放模拟用户实际操作场景,监控并分析运行结果。

    自动化测试

    录制+回放+脚本 是主要的方式

    常用的自动化测试的工具,哪些种类,每种有什么工具

    • 功能测试工具:QTP
    • 性能测试工具:LoadRunner
      • 写脚本或者录制脚本
      • 使用用户自定义参数
      • 场景设计
      • 产生虚拟用户的机制:使用控制器,来控制模拟多少用户。
      • 使用监听器,查看测试结果

    (Copyright © https://blog.csdn.net/s_gy_zetrov. All Rights Reserved)


    visitor tracker
    访客追踪插件


    展开全文
  • 1、软件测试的艺术(原书第3版) 从第1版付梓到现在已经30余年,是软件测试领域的经典著作:第一章以一个小测试作为引子,第二章阐述全书的核心思想...2、软件测试(原书第2版) 该书内容全面实用,讲述浅显易...
  • 1、软件测试(原书第2版) (美)佩腾(Patton,R.)著,张小松 等译 2、软件测试的艺术(原书第3版) (美)梅耶 等 3、计算机软件测试(原书第2版) (美)卡尼尔 4、全程软件测试 朱少民 5、PaulC.Jorgensen的软件...
  • 一部分:软件评测知识 1. 软件质量与软件...2. 软件测试与质量保证 软件测试只是质量保证工作中的一个环节,软件质量保证与软件测试是软件质量工程的两个不同层面的工作; 质量保证:通过预防、检查与改进来
  • 越来越多的人加入了测试大军中,很多人也想通过自学来学习软件测试技术加入这个行业,但是现在软件测试的书籍越来越多,也良莠不齐,而且软件测试涉及的技术也越来越多。本文主要说明的是从事软件测试行业需要必备的...
  •   软件测试工程师,和开发工程师相比起来,虽然前期可能不会太深,但是涉及的面还是比较广的。前期面试实习生或者一年左右的岗位,问的也主要是一些基础性的问题比较多。涉及的知识主要有MySQL数据库的使用、Linux...
  • 软件测试行业在国内才起步不久,很多人都是刚刚毕业就进入这个行业,或者从其他岗位转过来,对软件测试的知识和技能了解的有限,而软件测试又是一个非常重视实践经验的工作。如何在较短时间内熟悉软件测试的基础知识...
  • 一部分:软件评测知识 1. 软件质量与软件测试 ...2. 软件测试与质量保证 软件测试只是质量保证工作中的一个环节,软件质量保证与软件测试是软件质量工程的两个不同层面的工作; 质量保证
  • 软件测试的有效方法(第2版)》笔记(一)第一章 评估软件测试的能力和人员资格1、软件开发过程:计划P、执行D、检查C、行动A。--PDCA循环2、软件测试涉及的人员:软件客户、软件用户、开发人员、测试人员、信息...
  • 1、软件测试的流程 2、web测试和APP测试的区别 仅仅从功能测试的层面上来讲的话,在流程和功能测试上是没有区别的。那么区别在哪里呢? 由于载体不一样,所以系统测试和一些细节可能会不一样。 那么我们就要先...
  • 1.软件测试定义两面性 2.测试的生命周期 测试需求分析--&gt;测试设计--&gt;测试计划--&gt;测试执行--&gt;质量评估 3.软件测试过程: 需求评审和设计评审是验证软件产品的需求定义和设计...
  • 软件测试新手期又叫入门,软件测试就是刚刚接触这个东西,不太熟。无论进入哪个行业,我们都要经历一个新手期。...1、开始自学的时候找一本书来入门(软件测试原版很不错)-差不多要1个月左右的...
  • 1.《软件测试技术大全 测试基础 流行工具 项目实战(第3)》 真正来自软件测试专家的经验之作,热点技术、流行工具、求职面试等知识应有尽有,是解决测试中的困惑与问题,尽快上手软件测试岗位的...
  • 一章 1、软件测试的定义: IEEE给出的定义—— 软件测试是使用人工和自动手段来运行或测试某个系统的过程,其目的在于检验它是否满足规定的需求或弄清楚预期结果与实际结果...2软件测试的目的 软件质量: 1.发现...
  • 1. 软件的三个要素:程序...3. 软件测试的目的:1)验证软件是否满足 软件开发合同 或者项目开发计划,系统/子系统设计文档,软件需求规格说明,软件产品说明等规定的软件质量要求 2)通过测试,发现软件缺陷 3
1 2 3 4 5 ... 20
收藏数 398,841
精华内容 159,536
关键字:

第2版 软件测试