2017-04-07 14:03:10 lilin520530 阅读数 685
  • 初级学软件之ASP.NET第二季 内置对象

    初级学软件之ASP.NET第二季 内置对象 视频课程 主讲内容: 第一讲 Response对象 第二讲 Request对象 第三讲 Application对象 第四讲 Session对象 第五讲 Cookie对象 第六讲 Server对象 第七讲 ViewState对象

    2375 人正在学习 去看看 胡延亮
   软件测试(英语:software testing),描述一种用来促进鉴定软件的正确性、完整性、

安全性和质量的过程。软件测试的经典定义是:在规定的条件下对程序进行操作,以发现程序

错误,衡量软件质量,并对其是否能满足设计要求进行评估的过程。
  
    一个好的公司应该有专门的测试团队。因为,测试直接影响的软件是否能交付,是交付的

基石。测试的需求:
 
    测试需求包括功能测试需求和非功能性测试需求,而非功能性测试需求包括性能、安全

性、可靠性、兼容性、易维护性和可移植性等测试需求。对于非功能性测试需求,既要独立考

虑它们各自的特点和各自的测试需求,也要考虑它们之间的关系和相互影响,例如安全性和可

靠性密切相关,越安全越可靠,越可靠越安全。而安全性会增加许多保护措施,往往会降低性

能。在整个系统测试需求分析时,不仅要考虑来自整体系统的测试需求,还要考虑系统数据、

外部接口等测试需求

    软件测试的误区?

    1.软件开发完成后进行软件测试。

    2.软件发布后如果发现质量问题,那是软件测试人员的错。

    3.软件测试要求不高,随便找个人做都行。

    4.软件测试是测试人员的事情,与程序员无关。

    5.项目进度吃紧时少做些测试,时间富裕时多做测试。

    软件测试的流程?

    1、制定测试计划[7]
   
    2、编辑测试用例
 
    3、执行测试用例

    4、发现并提交BUG

    5、开发组修正BUG

    6、对已修正BUG进行返测

    7、修正完成的BUG将状态置为已关闭,未正确修正的BUG重新激活
   
2018-11-18 04:30:08 gdhjgfr 阅读数 713
  • 初级学软件之ASP.NET第二季 内置对象

    初级学软件之ASP.NET第二季 内置对象 视频课程 主讲内容: 第一讲 Response对象 第二讲 Request对象 第三讲 Application对象 第四讲 Session对象 第五讲 Cookie对象 第六讲 Server对象 第七讲 ViewState对象

    2375 人正在学习 去看看 胡延亮

分享一下我老师大神的人工智能教程!零基础,通俗易懂!http://blog.csdn.net/jiangjunshow

也欢迎大家转载本篇文章。分享知识,造福人民,实现我们中华民族伟大复兴!

               
第一篇 软件测试的基础 
第1章 软件测试行业 1 
1.1 软件测试的起源 2 
1.1.1 第一个bug的故事 2 
1.1.2 几个导致严重错误的bug 3 
1.1.3 软件测试的起源 3 
1.2 软件测试的发展 3 
1.2.1 软件调试 4 
1.2.2 独立的软件测试 4 
1.2.3 软件测试的第一次定义 4 
1.2.4 软件测试成为专门的学科 5 
1.2.5 开发与测试的融合趋势 5 
1.2.6 为什么软件测试发展比较缓慢 5 
1.3 软件测试行业的现状和前景 6 
1.3.1 国内测试行业现状 6 
1.3.2 测试人员的现状 7 
1.3.3 软件测试的前景 8 
1.4 小结 9 
1.5 新手入门须知 9 
.1.6 模拟面试问答 10 
第2章 软件测试的组织 11 
2.1 测试的组织形式 12 
2.1.1 微软的经验教训 12 
2.1.2 最简单的软件测试组织 12 
2.1.3 组织形式的分类方式 12 
2.1.4 综合型的测试组织 14 
2.2 融入测试组织 15 
2.2.1 根据开发的模式判断自己的测试角色定位 15 
2.2.2 “支援编程人员”的测试与“批判性”的测试 16 
2.2.3 “面向业务”的测试与“面向技术”的测试 16 
2.2.4 测试的划分对敏捷项目开发的重要性 17 
2.2.5 如何融入一个项目团队 18 
2.2.6 快速融入项目团队的技巧 18 
2.2.7 尽快投入测试工作的技巧 19 
2.3 软件测试的团队建设 19 
2.3.1 学习型团队的组建 19 
2.3.2 让每一位测试人员找到适合自己的位置 20 
2.3.3 “无规矩则不成方圆” 21 
2.3.4 测试规范 21 
2.3.5 部门制度 22 
2.4 小结 23 
2.5 新手入门须知 23 
2.6 模拟面试问答 23 
第3章 软件测试的人员要求 25 
3.1 测试人员的素质要求 26 
3.1.1 你对测试感兴趣吗 26 
3.1.2 你有适合做软件测试的性格特征吗 27 
3.1.3 好奇心 27 
3.1.4 成就感 28 
3.1.5 消极思维 29 
3.1.6 全面的思维能力 29 
3.1.7 测试的正确态度 29 
3.1.8 责任感是测试人员的自我要求 29 
3.1.9 责任感与压力 30 
3.2 测试人员的技能要求 31 
3.2.1 业务知识 31 
3.2.2 产品设计知识 32 
3.2.3 测试人员需要了解软件架构知识 32 
3.2.4 测试人员需要了解统一建模语言(uml) 32 
3.2.5 测试人员的“武器” 32 
3.2.6 测试人员需要掌握的测试工具 33 
3.2.7 测试人员需要掌握开发工具吗 34 
3.2.8 用户心理学 34 
3.2.9 界面设计中的3种模型 34 
3.2.10 人机交互认知心理学 35 
3.2.11 测试人员是否需要编程技能 35 
3.2.12 掌握编程技能的好处 35 
3.2.13 脚本语言 35 
3.2.14 文档能力 38 
3.3 小结 40 
3.4 新手入门须知 40 
3.5 模拟面试问答 41 
第二篇 软件测试必备知识 
第4章 软件工程与软件测试 42 
4.1 软件工程简介 43 
4.1.1 什么是软件工程 43 
4.1.2 软件的生命周期 43 
4.1.3 软件工程的研究领域 44 
4.1.4 软件工程的发展历史 44 
4.1.5 软件工程化概念的提出 44 
4.1.6 “软件工厂” 45 
4.1.7 软件过程管理 45 
4.1.8 软件过程相关方法和工具 45 
4.1.9 软件工程发展的新趋势 46 
4.1.10 软件工程的目的 46 
4.2 软件开发模式 47 
4.2.1 常见的软件开发模式 47 
4.2.2 线性模型 47 
4.2.3 渐进式模型 48 
4.2.4 变换模型 49 
4.2.5 软件开发模式的发展 49 
4.2.6 rup的历史 49 
4.2.7 rup过程模型下的软件测试 50 
4.2.8 rup工具 51 
4.2.9 “重型”过程vs.“轻量”过程 51 
4.2.10 敏捷运动 52 
4.2.11 极限编程(xp) 52 
4.2.12 xp中的软件测试 54 
4.2.13 xp工具 54 
4.3 不同软件开发模式下的软件测试 54 
4.3.1 cmm和iso中的软件测试 54 
4.3.2 cmm与软件测试 54 
4.3.3 iso与软件测试 55 
4.3.4 敏捷开发中的软件测试 56 
4.4 小结 57 
4.5 新手入门须知 57 
4.6 模拟面试问答 58 
第5章 软件配置管理与软件测试 61 
5.1 软件配置管理的应用 62 
5.1.1 什么是配置管理 62 
5.1.2 实施软件配置管理的好处 63 
5.1.3 配置管理计划 63 
5.1.4 配置标识 64 
5.1.5 变更控制 65 
5.1.6 配置状态记录和报告 66 
5.1.7 配置审计 66 
5.1.8 配置管理的自动化 66 
5.1.9 进度控制与软件测试 67 
5.1.10 变更控制与软件测试 67 
5.1.11 配置管理与软件测试 68 
5.2 vss的安装和使用 68 
5.2.1 vss简介 68 
5.2.2 vss的安装 69 
5.2.3 创建vss数据库 69 
5.2.4 创建vss项目project 69 
5.2.5 vss备份 69 
5.3 svn的安装和使用 70 
5.3.1 svn的基本原理 70 
5.3.2 svn的下载与安装 71 
5.3.3 创建资源库 71 
5.3.4 运行svn服务 72 
5.3.5 用户授权 72 
5.3.6 导入项目文件 73 
5.3.7 检出项目 73 
5.3.8 用add命令添加文件 74 
5.3.9 commit命令 74 
5.3.10 update命令 74 
5.3.11 将svn服务注册为系统服务 74 
5.3.12 远程客户端访问 75 
5.3.13 目录访问权限控制 75 
5.4 小结 76 
5.5 模拟面试问答 77 
第6章 软件质量与软件测试 78 
6.1 软件质量属性 79 
6.1.1 质量的3个层次 79 
6.1.2 软件质量模型 80 
6.2 软件质量保证与软件测试 80 
6.2.1 sqa与软件测试 81 
6.2.2 sqa与项目组各成员之间的关系 81 
6.2.3 sqa组织 81 
6.2.4 sqa的工作内容 82 
6.2.5 qa与qc的区别 82 
6.3 质量保证体系建设 83 
6.3.1 iso 9000质量管理体系与八项质量管理原则 83 
6.3.2 iso 9000质量管理体系的建立过程 84 
6.3.3 cmm质量管理体系与过程改进 84 
6.3.4 结合psp、tsp建立cmm过程改进体系 84 
6.3.5 应用pdca质量控制法持续改进软件质量 85 
6.4 小结 85 
6.5 新手入门须知 86 
6.6 模拟面试问答 86 
第7章 软件测试的目的与原则 87 
7.1 软件测试的目的 88 
7.1.1 测试是为了建立软件的信心 88 
7.1.2 软件测试与软件信心的关系 88 
7.1.3 软件测试的两面性 88 
7.1.4 软件测试的验证与确认 89 
7.1.5 测试是一种服务 90 
7.2 软件测试应该遵循的几个原则 90 
7.2.1 good enough原则 90 
7.2.2 pareto原则 91 
7.2.3 尽可能早开展测试 91 
7.2.4 在发现比较多错误的地方需要投入更多的测试 92 
7.2.5 同化效应 92 
7.3 小结 92 
7.4 新手入门须知 93 
7.5 模拟面试问答 93 
第8章 软件测试的方法论 95 
8.1 软件测试的5大流派 96 
8.1.1 分析学派 96 
8.1.2 标准学派 96 
8.1.3 质量学派 97 
8.1.4 上下文驱动学派 97 
8.1.5 敏捷学派 98 
8.1.6 不同流派的测试定义 98 
8.2 软件测试的方法应用 98 
8.2.1 微软公司的第一类测试 99 
8.2.2 微软公司的第二类测试 99 
8.2.3 微软的缺陷管理 100 
8.3 ibm公司的软件测试方法 100 
8.3.1 回归测试 100 
8.3.2 测试的度量 101 
8.3.3 用例驱动 101 
8.3.4 rup对软件测试的分类 101 
8.3.5 rup对测试阶段的划分 103 
8.4 自动错误预防(aep)方法 103 
8.4.1 aep的基本概念 103 
8.4.2 实现软件自动错误预防的5大法则 104 
8.5 小结 106 
8.6 新手入门须知 106 
8.7 模拟面试问答 108 
第9章 软件测试的过程管理 109 
9.1 软件测试的各个阶段 110 
9.2 测试需求 110 
9.2.1 需求规格说明书的检查要点 111 
9.2.2 需求文档的检查步骤 111 
9.2.3 通过编写测试用例来检查需求 114 
9.3 测试的计划 115 
9.3.1 为什么要制定测试计划 115 
9.3.2 测试计划是对测试过程的整体设计 115 
9.3.3 确定测试范围 116 
9.3.4 制定测试策略 116 
9.3.5 安排好测试资源 117 
9.3.6 安排好进度 117 
9.3.7 计划风险 118 
9.4 测试的设计及测试用例 118 
9.4.1 基于需求的测试用例设计 118 
9.4.2 等价类划分法 119 
9.4.3 边界值分析法 120 
9.4.4 等价类+边界值 122 
9.4.5 基本路径分析法 122 
9.4.6 因果图法 123 
9.4.7 场景设计法 124 
9.4.8 错误猜测法 125 
9.4.9 正交表与tcg的使用 125 
9.4.10 利用均匀试验法设计测试用例 127 
9.4.11 组合覆盖与pict的使用 128 
9.4.12 分类树与cte xl的使用 130 
9.4.13 测试用例设计的自动化 132 
9.4.14 敏捷测试用例设计 133 
9.4.15 测试用例的粒度 133 
9.4.16 基于需求的测试用例设计 134 
9.4.17 测试用例的评价 134 
9.4.18 测试用例数据生成的自动化 135 
9.5 测试的执行 135 
9.5.1 测试用例的合理选择 135 
9.5.2 测试的分工与资源利用 136 
9.5.3 测试环境的搭建 136 
9.5.4 bvt测试与冒烟测试 137 
9.5.5 每日构建的基本流程 138 
9.5.6 通过每日构建来规范源代码管理 138 
9.5.7 通过每日构建来控制版本风险 139 
9.6 测试的记录和跟踪 139 
9.6.1 bug的质量衡量 139 
9.6.2 如何录入一个合格的bug 140 
9.6.3 报告发现问题的版本 140 
9.6.4 报告问题出现的环境 141 
9.6.5 报告问题重现的操作步骤 141 
9.6.6 描述预期的行为 141 
9.6.7 描述观察到的错误行为 141 
9.6.8 bug报告应该注意的几个问题 142 
9.6.9 如何跟踪一个bug的生命周期 142 
9.6.10 如何与开发人员沟通一个bug 143 
9.6.11 bug评审要注意的问题 143 
9.6.12 基于qc的缺陷管理 144 
9.7 回归测试 144 
9.7.1 为什么会回归 145 
9.7.2 回归测试的难度 145 
9.7.3 基于风险的回归测试 145 
9.8 测试总结和报告 147 
9.8.1 缺陷分类报告 147 
9.8.2 缺陷类型分布报告 148 
9.8.3 缺陷区域分布报告 148 
9.8.4 缺陷状态分布报告 148 
9.8.5 缺陷趋势报告 149 
9.8.6 典型缺陷与bug模式 150 
9.8.7 测试中的pdca循环 151 
9.8.8 客观全面的测试报告 152 
9.8.9 实用测试经验的总结 152 
9.9 小结 153 
9.10 新手入门须知 153 
9.11 模拟面试问答 153 
第10章 软件测试的度量 156 
10.1 软件测试度量的目的 157 
10.1.1 测试度量的难度 157 
10.1.2 测试人员工作质量的鉴定 158 
10.1.3 度量的目的 159 
10.2 软件测试的度量方法及其应用 159 
10.2.1 bug的数量能说明什么 160 
10.2.2 度量bug的数量 160 
10.2.3 加权法度量缺陷 160 
10.2.4 bug的定性评估 162 
10.2.5 bug综合评价模型 162 
10.2.6 测试覆盖率统计 163 
10.2.7 代码覆盖率 163 
10.2.8 功能模块覆盖率 164 
10.2.9 需求覆盖率 165 
10.2.10 测试用例文档产出率与测试用例产出率 166 
10.2.11 考核测试人员的硬指标和软指标 166 
10.2.12 硬指标 166 
10.2.13 软指标 167 
10.2.14 考核表 168 
10.3 小结 169 
10.4 新手入门须知 169 
10.5 模拟面试问答 170 
第三篇 实用软件测试技术与工具应用 
第11章 实用软件测试技术 171 
11.1 软件测试技术的发展 172 
11.2 软件测试技术 173 
11.2.1 不管黑盒、白盒,找到bug就行 173 
11.2.2 黑盒测试 173 
11.2.3 白盒测试 174 
11.2.4 手工测试、自动化测试,一个都不能少 175 
11.2.5 自动化测试的目的 175 
11.2.6 手工测试的不可替代性 175 
11.2.7 探索性测试的“技术” 176 
11.2.8 探索性测试的基本过程 177 
11.2.9 探索性测试的管理 177 
11.2.10 单元测试的定义 178 
11.2.11 单元测试由谁做 178 
11.2.12 结对单元测试 179 
11.2.13 单元级别的性能测试 180 
11.2.14 性能测试“从小做起” 180 
11.2.15 数据库性能检查 182 
11.2.16 软件的“极限考验”——压力测试 183 
11.2.17 软件的容量如何 183 
11.2.18 安全性测试 187 
11.2.19 网页安全漏洞检测 188 
11.2.20 sql注入 188 
11.2.21 缓冲区溢出 189 
11.2.22 安装测试 189 
11.2.23 环境测试 192 
11.3 实用软件测试技术的综合应用 193 
11.3.1 跟踪法测试 193 
11.3.2 跟踪法的典型应用 193 
11.3.3 跟踪法测试的好处 195 
11.3.4 跟踪法测试的必要性 196 
11.3.5 c/s结构软件系统的测试 196 
11.3.6 b/s结构软件系统的测试 197 
11.3.7 链接测试 197 
11.3.8 cookies测试 198 
11.3.9 兼容性测试 198 
11.3.10 并发访问测试 198 
11.3.11 手机应用测试的要点 198 
11.3.12 手机应用软件的特点 199 
11.3.13 手机应用软件的测试要点 199 
11.3.14 游戏软件系统的测试重点是“玩” 199 
11.3.15 游戏可玩性的测试 200 
11.3.16 游戏的环境测试 201 
11.3.17 网络游戏的安全性测试 201 
11.3.18 游戏的性能测试 201 
11.3.19 界面交互及用户体验测试 201 
11.3.20 使用用户模型对界面交互进行测试 201 
11.3.21 界面和用户体验测试的要点 202 
11.3.22 数据库测试 203 
11.3.23 数据库设计的测试 203 
11.3.24 sql代码规范性测试 203 
11.3.25 sql语句效率测试 204 
11.3.26 sql数据库兼容性测试 205 
11.3.27 web services的测试 206 
11.3.28 内存泄露测试 208 
11.3.29 造成软件内存泄露的原因 208 
11.3.30 如何检测内存泄露 209 
11.3.31 对内存问题测试的分工与合作 209 
11.3.32 检查程序员的编码规范 210 
11.3.33 报表测试 211 
11.3.34 报表测试的业务基础 211 
11.3.35 报表测试中的细节问题检查 212 
11.3.36 报表测试中的性能测试、安全性测试 212 
11.3.37 报表的保存和打印测试 212 
11.3.38 报表的格式测试 212 
11.3.39 联机帮助和用户手册的测试 212 
11.3.40 联机帮助的测试要点 213 
11.3.41 用户手册的测试要点 214 
11.3.42 缺乏工具支持的性能测试 214 
11.3.43 借助其他小工具和自己开发的小程序来解决问题 215 
11.3.44 手工的性能测试 217 
11.3.45 本地化测试与国际化测试 218 
11.3.46 本地化软件测试和国际化测试的要点 218 
11.3.47 本地化软件测试和国际化测试对测试人员的要求 219 
11.3.48 本地化软件测试和国际化测试工具的使用 219 
11.3.49 可访问性测试(accessibility testing) 220 
11.3.50 section 508 web指南 220 
11.3.51 可访问性测试工具 221 
11.4 小结 221 
11.5 新手入门须知 221 
11.6 模拟面试问答 222 
第12章 测试管理工具qc的应用 225 
12.1 测试管理平台 226 
12.1.1 测试过程管理规范化 226 
12.1.2 测试管理平台——qc简介 227 
12.1.3 qc安装 227 
12.1.4 qc安装常见问题 230 
12.2 测试需求管理 234 
12.2.1 定义测试需求 234 
12.2.2 从office文档导入需求到qc 234 
12.2.3 把需求项转换成测试计划 235 
12.3 测试计划管理 236 
12.3.1 测试用例的管理 236 
12.3.2 设计测试步骤 237 
12.3.3 测试用例的重用 238 
12.3.4 测试用例对需求项的覆盖 239 
12.4 测试执行 241 
12.4.1 定义测试集 241 
12.4.2 为测试集添加测试用例 242 
12.4.3 执行测试 243 
12.5 缺陷登记与跟踪 244 
12.5.1 添加新缺陷 244 
12.5.2 如何避免录入冗余的缺陷 244 
12.5.3 bug的生命周期 245 
12.5.4 把缺陷链接到测试 246 
12.6 在qc中生成测试报告的图表 247 
12.7 基于qc的测试项目管理 248 
12.7.1 qc的库结构 248 
12.7.2 创建qc项目库 248 
12.7.3 定制项目 248 
12.7.4 添加项目组成员 249 
12.7.5 自定义qc的数据字段 250 
12.7.6 配置跟踪提醒规则 252 
12.7.7 设置可追溯性通知规则 254 
12.7.8 设置工作流 256 
12.7.9 “缺陷模块”列表自定义 256 
12.7.10 添加缺陷字段自定义 257 
12.7.11 脚本编辑器 258 
12.7.12 qc项目的导入导出 259 
12.7.13 qc项目的备份还原 261 
12.8 其他资源 262 
12.9 练习和实践 262 
第13章 功能自动化测试工具qtp的应用 264 
13.1 如何开展功能自动化测试 265 
13.1.1 选取合适的测试项目来开展自动化测试 265 
13.1.2 自动化测试工程师的知识体系 265 
13.1.3 自动化测试工具选型 266 
13.1.4 自动化测试项目计划 267 
13.2 使用qtp开展功能自动化测试 268 
13.2.1 qtp的安装 268 
13.2.2 使用qtp录制脚本 269 
13.2.3 使用关键字视图和专家视图编辑脚本 272 
13.2.4 回放脚本 273 
13.2.5 插入检查点 273 
13.3 构建功能自动化测试框架 276 
13.3.1 模块化框架 276 
13.3.2 函数库结构框架 278 
13.3.3 数据驱动框架 279 
13.4 其他资源 282 
13.5 练习和实践 282 
第14章 性能测试工具loadrunner的应用 284 
14.1 如何开展性能测试 285 
14.1.1 性能测试工程师的素质要求 285 
14.1.2 认识性能测试 286 
14.1.3 性能测试的类型 287 
14.1.4 性能测试成熟度模型 288 
14.1.5 分析和定义性能需求 289 
14.1.6 “不成文的”性能需求定义 290 
14.1.7 计划性能测试 291 
14.2 使用loadrunner开展性能测试 291 
14.2.1 loadrunner简介 291 
14.2.2 loadrunner基本使用方法和步骤 293 
14.2.3 选择协议 295 
14.2.4 录制脚本 296 
14.2.5 常见脚本回放问题解决 298 
14.2.6 修改和完善脚本 299 
14.2.7 脚本参数化 300 
14.2.8 添加事务 300 
14.2.9 添加内容检查点 301 
14.2.10 性能参数的选择和监视 302 
14.2.11 运行场景 304 
14.2.12 选择需要监控的性能参数 304 
14.2.13 性能测试报告与性能瓶颈分析 304 
14.3 其他资源 306 
14.4 练习和实践 306 
第15章 安全测试 308 
15.1 常见安全漏洞分析 309 
15.1.1 缓冲区溢出 309 
15.1.2 整数溢出 311 
15.1.3 命令注入 312 
15.1.4 sql注入 312 
15.1.5 xss——跨站脚本攻击 314 
15.2 使用appscan进行安全测试 316 
15.2.1 appscan简介 316 
15.2.2 利用appscan进行web安全测试 316 
15.2.3 使用appscan测试altoroj项目 317 
15.3 其他资源 320 
15.4 练习和实践 321 
第16章 单元测试工具mstest的应用 323 
16.1 单元测试范围管理 324 
16.1.1 单元测试的分类 324 
16.1.2 静态单元测试 325 
16.1.3 动态单元测试 325 
16.1.4 “广专结合”、“动静相宜” 326 
16.1.5 单元测试的效果 326 
16.1.6 单元测试的范围 326 
16.2 单元测试的过程管理 327 
16.2.1 单元测试的过程策划 327 
16.2.2 管理层对单元测试的重视 327 
16.2.3 单元测试意识的改变 327 
16.2.4 单元测试的组织 328 
16.2.5 单元测试模式的选择 328 
16.2.6 单元测试的管理规范 328 
16.2.7 单元测试的人员分工 329 
16.2.8 单元测试的策略 329 
16.2.9 单元测试用例的设计 329 
16.2.10 代码标准和规范 329 
16.2.11 代码审查制度 330 
16.2.12 单元测试的流程 330 
16.2.13 单元测试与每日构建的结合 331 
16.2.14 单元测试的自动化方面 331 
16.2.15 自动化单元测试与每日构建的结合 332 
16.3 单元测试的质量度量 333 
16.3.1 单元测试覆盖率 333 
16.3.2 单元测试评审 334 
16.4 单元测试工具mstest的应用 334 
16.4.1 建立单元测试项目 335 
16.4.2 巧用nmock对象 337 
16.4.3 对缺乏接口实现的类的方法进行测试 337 
16.4.4 使用nmock对象 337 
16.4.5 使用nmock的场合 338 
16.4.6 单元测试的执行 338 
16.4.7 测试管理 338 
16.4.8 运行测试代码 339 
16.4.9 查看测试结果 339 
16.5 数据驱动的单元测试 339 
16.5.1 为什么要使用数据驱动的方式 339 
16.5.2 创建数据驱动单元测试 339 
16.5.3 使用数据源 341 
16.5.4 使用配置文件定义数据源 342 
16.5.5 编写单元测试代码使用配置文件定义的数据源 343 
16.6 小结 343 
16.7 新手入门须知 344 
16.8 模拟面试问答 344 
第17章 开源测试工具 346 
17.1 开源测试工具简介 347 
17.1.1 开源的背景 347 
17.1.2 开源测试工具的发展现状 347 
17.1.3 开源测试工具的分布 347 
17.1.4 开源测试工具的来源 348 
17.1.5 开源测试工具的优势 348 
17.1.6 开源测试工具的不足 348 
17.2 常用开源测试工具介绍——测试管理类 348 
17.2.1 bugzilla 349 
17.2.2 mantis 350 
17.2.3 bugfree 351 
17.2.4 综合比较 352 
17.3 常用开源测试工具介绍——单元测试类 352 
17.3.1 nunit 352 
17.3.2 nmock 353 
17.3.3 nunitforms 354 
17.4 常用开源测试工具介绍——性能测试类 355 
17.4.1 jmeter 356 
17.4.2 testmaker 357 
17.4.3 dbmonster 358 
17.5 常用开源测试工具介绍——自动化功能测试类 360 
17.5.1 abbot java gui test framework 360 
17.5.2 white 361 
17.5.3 watir 362 
17.6 如何在测试组中引入开源测试工具 363 
17.6.1 开源测试工具的成本考虑 364 
17.6.2 引入开源测试工具的步骤 364 
17.6.3 引入开源测试工具可能碰到的问题 365 
17.7 小结 366 
17.8 新手入门须知 366 
17.9 模拟面试问答 367 
第18章 测试工具的原理及制作 369 
18.1 自制测试工具的优势 370 
18.2 辅助工具的制作 371 
18.2.1 测试工具的开发策划 371 
18.2.2 测试语言的选择 371 
18.2.3 测试工具开发的各种实现技术 372 
18.2.4 接口驱动 372 
18.2.5 测试执行器及远程代理 373 
18.2.6 测试解释器和测试生成器 374 
18.3 利用windows脚本辅助测试 374 
18.3.1 利用jscript进行简单的gui自动化测试 375 
18.3.2 利用jscript检查注册表 375 
18.3.3 利用jscript的filesystemobject对象处理文件 376 
18.3.4 读取文件 376 
18.3.5 创建文件 377 
18.3.6 利用jscript操作excel 377 
18.3.7 在jscript中运行应用程序 378 
18.3.8 在jscript中使用wmi 379 
18.3.9 在jscript中访问网络 380 
18.3.10 在jscipt中使用正则表达式 381 
18.3.11 使用jscript发送邮件 382 
18.3.12 jscript脚本的调试方法 383 
18.4 简易自动化测试 383 
18.4.1 使用vbscript进行web自动化测试 384 
18.4.2 利用uiautomation实现gui自动化测试 384 
18.5 设计一个性能测试框架 387 
18.5.1 性能测试的基本原理 387 
18.5.2 controller的简单设计 388 
18.5.3 agent的简单设计 389 
18.5.4 虚拟用户的产生 392 
18.6 正交表测试用例自动生成工具的设计 393 
18.6.1 正交表类的设计 394 
18.6.2 加载正交表文件 396 
18.6.3 解释输入 398 
18.6.4 查找正交表 398 
18.6.5 改进方向 406 
18.7 数据库比较工具的制作 407 
18.7.1 “三库”的问题 407 
18.7.2 sqlserver表结构原理 407 
18.7.3 数据库比较工具的设计 408 
18.8 oracle的sql语句跟踪工具的制作 411 
18.8.1 设置oracle的sql跟踪参数 412 
18.8.2 打开sql跟踪 412 
18.8.3 关闭sql跟踪 413 
18.8.4 改进方向 414 
18.9 一个简单的猴子测试工具的制作 414 
18.9.1 猴子测试工具应该具备的功能 414 
18.9.2 windows api的调用 415 
18.9.3 截屏功能的实现 418 
18.9.4 让猴子动起来 420 
18.9.5 记录猴子的足迹 421 
18.9.6 给猴子一些知识 421 
18.9.7 记录被测试应用程序的资源使用情况 423 
18.9.8 完整的猴子测试工具 425 
18.9.9 扩展 432 
18.10 测试覆盖率辅助管理工具的制作 432 
18.10.1 测试覆盖率管理 432 
18.10.2 需求覆盖率管理 432 
18.10.3 测试用例覆盖率管理 433 
18.10.4 功能模块覆盖率管理 434 
18.10.5 代码覆盖率管理 435 
18.10.6 数据覆盖率管理 436 
18.10.7 测试覆盖率统计的自动化 437 
18.10.8 测试覆盖率对测试管理的意义 438 
18.10.9 测试覆盖率辅助管理工具的设计 438 
18.10.10 调用devpatner的代码覆盖率统计工具 439 
18.10.11 用c#来调用dpanalysis执行被测试应用程序 439 
18.10.12 测试覆盖率辅助管理工具的使用 443 
18.11 小结 444 
18.12 新手入门须知 445 
18.13 模拟面试问答 445 
第19章 小工具的使用 447 
19.1 巧用windows自带的小工具 448 
19.1.1 windows的任务管理器 448 
19.1.2 利用windows任务管理器检查进程驻留 448 
19.1.3 利用windows任务管理器检查内存问题 448 
19.1.4 利用windows任务管理器检查网络使用情况 449 
19.1.5 利用windows任务管理器检查cpu使用情况 450 
19.1.6 perfmon的性能监控 450 
19.1.7 netstat的网络监视 453 
19.2 免费小工具的妙用 454 
19.2.1 sql server数据库的sql事件探查器 454 
19.2.2 visual studio开发工具的spy++ 456 
19.2.3 visual sourcesafe的文件比较器 457 
19.2.4 http协议包查看器——http watch 458 
19.2.5 html do m查看器——ie developer toolbar 459 
19.3 小结 460 
19.4 新手入门须知 460 
19.5 模拟面试问答 461 
第20章 持续集成 462 
20.1 持续集成简介 463 
20.1.1 持续集成的价值 463 
20.1.2 持续集成包含的过程 463 
20.2 利用windows脚本搭建一个每日构建框架 463 
20.2.1 每日构建框架的基本要素 463 
20.2.2 获取源代码 464 
20.2.3 编译源代码 466 
20.2.4 分析编译结果 466 
20.2.5 处理编译结果 468 
20.2.6 发送编译报告 469 
20.2.7 利用windows任务计划来定时启动脚本 470 
20.2.8 每日构建框架的扩展1——单元测试 471 
20.2.9 每日构建框架的扩展2——自动化功能测试 476 
20.2.10 每日构建框架的扩展3——每日缺陷简报 477 
20.2.11 缺陷库表结构分析 477 
20.2.12 缺陷统计程序的设计 479 
20.2.13 每日构建框架的扩展4——每日配置管理简报 483 
20.2.14 配置管理的现状 484 
20.2.15 缺陷简报程序的设计 484 
20.2.16 每日构建框架的扩展5——每日里程碑预报 486 
20.2.17 每日构建框架的其他扩展思路 488 
20.2.18 每日缺陷统计 488 
20.2.19 每日缺陷简报 490 
20.3 利用windows脚本整合一个自动错误预防系统 491 
20.3.1 轻量级的aep框架 491 
20.3.2 把aep系统整合到每日构建框架中 491 
20.3.3 整合fxcop 491 
20.3.4 整合sql bpa 493 
20.3.5 测试结果检查和发送 493 
20.4 其他资源 494 
第21章 代码审查 495 
21.1 代码审查实践 496 
21.1.1 为什么需要代码审查 496 
21.1.2 代码静态分析的工作内容 497 
21.1.3 类型检查 497 
21.1.4 风格检查 497 
21.1.5 程序理解 498 
21.1.6 bug查找 499 
21.2 自动代码审查 500 
21.2.1 代码分析工具pclint的应用 501 
21.2.2 pclint与vc6的整合 501 
21.2.3 代码风格审查工具stylecop的应用 502 
21.2.4 stylecop的设置 503 
21.3 其他资源 504 
第22章 探索性测试管理 505 
22.1 探索性测试的必要性 506 
22.1.1 探索性测试的原理 506 
22.1.2 探索性测试与即兴测试的区别 506 
22.1.3 探索性测试的意义 507 
22.2 如何进行探索性测试 507 
22.2.1 优秀探索性测试人员的基本素质 507 
22.2.2 测试就是向程序提问 508 
22.3 探索性测试的过程管理和度量 509 
22.3.1 测试组长是“教练” 509 
22.3.2 基于探索任务的测试计划 509 
22.3.3 探索性测试的“碰头会议” 510 
22.4 小结 513 
22.5 新手入门须知 513 
22.6 模拟面试问答 513 
第23章 用户界面测试管理 515 
23.1 用户界面测试的必要性 516 
23.2 如何进行用户界面测试 516 
23.2.1 用户界面测试的时机 516 
23.2.2 后期修改界面的风险 517 
23.2.3 界面测试遗漏 517 
23.2.4 用户界面测试的要点 517 
23.2.5 “射箭”原理 518 
23.2.6 减少用户的工作量 518 
23.2.7 “少就是多” 518 
23.3 用户界面测试原则 518 
23.3.1 亲和力 519 
23.3.2 协助 520 
23.3.3 有效 521 
23.3.4 鼓励 522 
23.3.5 熟悉 522 
23.3.6 明显 523 
23.3.7 个性化 523 
23.3.8 安全 524 
23.3.9 满意 524 
23.3.10 简单 525 
23.3.11 支持 525 
23.3.12 多样性 526 
23.4 小结 526 
23.5 新手入门须知 527 
23.6 模拟面试问答 527 
第四篇 软件测试的学习和研究 
第24章 软件测试的学习环境 529 
24.1 学习氛围的建立 530 
24.1.1 培训导师制度 530 
24.1.2 把测试人员的学习内容作为工作考核的一部分 531 
24.1.3 把测试人员的学习计划纳入到项目计划 531 
24.1.4 把测试人员的学习和技术研究任务化、专门化 531 
24.1.5 建立一帮一的导师制度 532 
24.1.6 建立一个持续的培训体系 533 
24.1.7 读书会 534 
24.1.8 找个师傅学习软件测试 534 
24.2 软件测试经验的总结 535 
24.2.1 测试知识库的建立 535 
24.2.2 知识库的“进” 536 
24.2.3 知识库的“出” 536 
24.2.4 办一份内部期刊 537 
24.2.5 测试管理经验的总结 538 
24.2.6 过程管理经验总结 538 
24.2.7 个人管理经验总结 540 
24.3 软件测试的交流 541 
24.3.1 日常的交流 541 
24.3.2 专门的交流 542 
24.3.3 与开发人员的交流 542 
24.3.4 定义好自己的角色 543 
24.3.5 解释自己的工作 544 
24.3.6 尽量减少会产生误会和曲解的bug报告 544 
24.3.7 与管理层的交流 545 
24.3.8 宣传测试 545 
24.3.9 主动报告测试 545 
24.3.10 外部交流 545 
24.4 小结 546 
24.5 新手入门须知 546 
24.6 模拟面试问答 547 
第25章 软件测试的研究方向与个人发展 549 
25.1 软件测试角色与其他项目角色的可转换性 550 
25.1.1 转向售前 550 
25.1.2 转向售后 551 
25.1.3 转向开发 553 
25.1.4 转向qa 554 
25.2 测试人员的发展路线 555 
25.2.1 管理路线 555 
25.2.2 技术路线 557 
25.3 软件测试的研究方向 558 
25.3.1 软件测试中的数学 558 
25.3.2 软件测试工具设计 559 
25.3.3 其他研究方向 559 
25.4 小结 560 
25.5 新手入门须知 560 
25.6 模拟面试问答 560 
附录 各章习题答案 561            

给我老师的人工智能教程打call!http://blog.csdn.net/jiangjunshow

这里写图片描述
2019-07-30 22:07:49 sylan15 阅读数 233
  • 初级学软件之ASP.NET第二季 内置对象

    初级学软件之ASP.NET第二季 内置对象 视频课程 主讲内容: 第一讲 Response对象 第二讲 Request对象 第三讲 Application对象 第四讲 Session对象 第五讲 Cookie对象 第六讲 Server对象 第七讲 ViewState对象

    2375 人正在学习 去看看 胡延亮

之前给新人推荐入门的软件测试书籍,我一般会推荐京东上排名靠前的《软件测试(第二版)》,但是之前我也只是简单的翻了一下,所以没有给更详细的建议。

这次抽时间把全书看了一遍,总体感觉在基础知识普及上,国内写的书会更接地气一些,特别是一些实用方法和基础概念,国内会根据当前的市场需求,同时综合各家取长补短来进行知识普及,而国外的这些书更多的偏纯理论汇总,当然,也和这本书出版的比较早有关系吧。

下面我简要说下读完这本经典的入门书籍后的建议。

全书分为六部分共 22 章节。

第一部分是软件测试行业基础信息的普及,比如软件测试的背景、软件开发过程、软件测试的定义以及原则。

第二部分是测试理论基础,比如需求说明、白盒测试、黑盒测试、动态测试和静态测试。

第三部分是具体的测试技术了,比如配置测试、兼容性测试、多语言测试、易用性测试、安全性测试、Web 测试以及测试文档的说明。

第四部分是一些测试的补充,比如测试工具、测试自动化、不同的测试里程碑阶段。

第五部分是测试文档的介绍,比如测试计划、测试用例、Bug 以及项目质量度量。

第六部分是作者对未来的展望,比如软件测试标准化的思考、软件测试工程师的职业说明。

总得来说,全书大部分内容都是最基本的基础知识,对于软件测试行业的基本概念也都做了普及,但是整体的框架划分以及侧重点和我理解的不太一样。

比如按照测试基础、测试流程、软件质量模型、测试方法、测试用例设计方法等等这么去分类的话,和目前实际情况会更接近一些。

针对本书的阅读人群,我的建议是:
1.有 1-3 年测试经验的测试工程师:3 年以内工作经验的工程师,可能刚刚开始上手实际的项目,也可能刚刚对测试工作有了自己的理解,但是缺少体系化,缺少方法论的指导,那么结合书中的内容,可以在一定程度上有互补的效果。
2.有 3-5 年测试经验的测试工程师:为啥把 1-3 年和 3-5 年的人群分开说呢?因为这两个人群看这本书的侧重点是不同的,比如 1-3 年的人去看应该着重的是具体知识点的吸收、学习和应用,3-5 年的去看,应该是把看完后的内容进行重新组织,结合自己项目实际情况和已有的经验积累,把本书的内容糅合进去,让自己的知识体系更完善、更系统化。
3.刚入门的测试工程师:我是犹豫了半天才把这部分人群的推荐给加进来的,我理想中要推荐的入门书籍目前还没找到,补上推荐是因为里面的一些基础知识可以作为科普使用,至少在一定程度上可以增加对软件测试的认识吧。

目前我看过的几本书,在整体组织上,都不是完美适合零基础的初学者,一个是内容的分类上我有更好的建议,另一个是概念性的东西太多,初学者不能很好的同实际进行结合,我很清楚的记得很久前自己看这种书的感受。

不建议测试管理者细看,也是可以略读。

书中的内容都是基础性的知识普及,大部分管理者肯定都已经了解,可以快速的过一遍查漏补缺,细看的话应该不会有啥新收获。

另外,针对各章节的阅读方法,我的建议是:
1.精读:无,因为全书全部都是基础信息的普及,都没有进行深入的讲解,所以没有需要精读的章节。

2.粗读:第 3、5、6、7、10、11、18、19 章。

粗读的这几个章节的内容,我认为都是实际项目中可能经常碰到的知识点,所以建议看的时候可以细一点,把概念和逻辑搞清楚,能记住就行,用的时候可以再细查,本次不需要精读去完全搞的特别清楚。

3.略读:第 1、2、4、8、9、12、13、14、15、16、17、20、21、22 章。

剩下的大部分内容,都只是略读即可,了解下概念,熟悉下知识点,如果是 3-5 年的测试人员,可以把部分知识点进行下重新组合和提炼,但是也不用花费太多的时间在这部分上面。

本文首发于公众号「sylan215」,十年测试老司机的原创干货,关注我,一起涨姿势!

sylan215

2019-07-15 21:00:46 qq_37378487 阅读数 91
  • 初级学软件之ASP.NET第二季 内置对象

    初级学软件之ASP.NET第二季 内置对象 视频课程 主讲内容: 第一讲 Response对象 第二讲 Request对象 第三讲 Application对象 第四讲 Session对象 第五讲 Cookie对象 第六讲 Server对象 第七讲 ViewState对象

    2375 人正在学习 去看看 胡延亮

第一部分 软件测试综述

2019.05.17 - 2019.05.18

1.软件测试定义
使用人工或自动手段来运行或测试某个系统的过程,检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

第1章 软件测试的背景

1.软件错误用例

  • 美国航天局火星基地登陆者号探测器,1999
    当单元测试成功后,必须结合进行完整的系统测试,才能检测出各部分之间可能产生的的错误传递。
  • 爱国者导弹防御系统,1991
    不能放过任何小的、当下看似不重要的缺陷,因为这些缺陷很有可能在日积月累下导致系统的重大错误。

2.软件失败的术语

  • 缺点(defect)故障(fault)失败(failure):指的是严重情况,甚至危险情况。
  • 异常(anomaly)事件(incident)偏差(variance):主要是未按预料的运行,而不是全部失败。
  • 问题(problem)错误(error)缺陷(bug):最常用的术语。

但总体来说,只要与开发小组达成共识即可,不需要过多计较用词。

3.软件缺陷的官方定义

  • 产品说明书(product specification)
    对开发的产品进行定义,给出产品细节、如何做、做什么、不能做什么。
  • 判断软件缺陷的五个规则(满足1个即可):
  1. 软件未实现产品说明书要求的功能。
  2. 软件出现了产品说明书指明不应该出现的错误。
  3. 软件实现了产品说明书未提到的功能。
    ——预料不到的操作,虽然有了可能更好,但会增加测试的工作,甚至带来更多缺陷。
  4. 软件未实现产品说明书虽未明确提及但应该实现的目标。
    ——例如:极端条件下,软件对可能产生的错误的正确反馈。
  5. 软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好。

4.软件测试员的目标
尽可能早地找出软件缺陷,并确保其得以修复。
——“修复”缺陷并非指一定要改正软件,可以是指在用户手册中增加一段注释或为用户提供特殊的培训。

第2章 软件开发过程

1.测试文档
是完整的软件产品的一部分。

比较重要的测试提交清单:

  • 测试计划(test plan):描述用于验证软件是否符合产品说明书和客户需求的整体方案。包括质量目标、资源需求、进度表、任务分配、方法等。
  • 测试用例(test cases):列举测试的项目,描述验证软件的详细步骤。
  • 缺陷报告(bug reports):描述执行测试用例找出的问题。通常记录在数据库中。
  • 测试工具和自动测试(test tools and automation):如果测试小组使用自动化工具测试软件,必须有文档记录。
  • 度量、统计和总结(metrics,statistic,summaries):测试过程的汇总。采用图形、表格和报告等形式。

2.软件产品的组成部分
产品不仅仅包括代码,也包括许多支持(非软件部分),这些也都需要测试。

  • 非软件部分:
    帮助文档、用户手册、样本和示例、产品支持信息、错误信息、安装等。

3.软件开发生命周期模式
作为测试人员,可能会遇到不同模式,需要根据当前项目采取的模式来定制测试和方法(应用不同的测试技术)。

  • 大爆炸模式
    • 背景:产品需求无需很好理解,最终发布日期可以随意修改。
    • 优点(对于开发):简单,没有计划、进度安排和正规开发过程。
    • 缺点(对于测试):从项目管理的角度,产品已经完工。准备交付,此时测试人员实际上妨碍了产品的交付。测试工作越深入,软件缺陷发现得越多,争吵就越多。
    • 实际情况:避免在此模式下进行测试。
  • 边写边改模式
    • 背景:最初的粗略想法(没有计划和文档的编制)一些简单的设计漫长的来回编写、测试和修改缺陷的过程发布产品
    • 优点(对于开发):极其适合意在快速制作而且用完就扔的小项目。
    • 缺点(对于测试):测试人员会和程序员一样陷入无休止的循环往复,不断拿到新的软件版本,此时可能旧版本的功能还未测试完成。
    • 实际情况:这种模式是最可能碰到的,它是软件开发的入门。
  • 瀑布模式
    • 思想:从最初的构思到最终产品要经过一系列步骤(无法回溯)。每一个步骤结束时,项目小组审查并决定是否进入下一步。如果项目为准备好进入下一步,就停滞下来,直到准备好。
    • 优点(对于开发):对于拥有明确清晰的目标的产品定义和训练有素的开发人员的项目而言,效果很好。
    • 缺点(对于测试):测试在最后进行,一些根本性的问题如果出现在早期,会导致软件缺陷修复成本剧增。
    • 实际情况:需要改进成一个能够在早期就进行测试的模式。
  • 螺旋模式
    • 思想:一开始不必详细定义所有细节。从小开始,定义重要的功能,努力实现这些功能,接受客户反馈,然后进入下一阶段。
    • 优点(对于开发):包含了瀑布模式(分析、设计、开发和测试的步骤)、边写边改模式(每一次的螺旋)、大爆炸模式(从外界观察)。
    • 优点(对于测试):发现问题早,成本低。
    • 实际情况:测试人员最喜欢的模式,可以尽早影响到产品,弄清楚产品的来龙去脉。

第3章 软件测试的实质

1.承上:
现实生活中,几乎看不到任何纯粹采用某种模式进行的项目,看不到完全符合客户要求的详细产品说明书,也没有足够的时间去做所有需要做的测试。
启下:
但这个理想的过程正是追求的目标。

2.测试的原则

  1. 完全测试程序是不可能的
    剔除重复的、无必要的测试条件。
  2. 软件测试是有风险的行为
    把数量巨大的数量的可能测试减少到可控制的范围,以及针对风险做出明智的选择(哪些测试重要,那些测试不重要)。
  3. 测试无法显示潜伏的软件缺陷
    可以报告缺陷的存在,但不能在任何情况下保证软件缺陷没有了。只有通过继续的测试,不断找到缺陷。
  4. 找到的软件缺陷越多,就说明软件缺陷越多
    同样的错误可能出现多次;某个缺陷附近常会有很多其他缺陷;多个软件缺陷可能是由同一个严重错误引起的。
  5. 杀虫剂怪事
    测试人员必须不断编写不同的、新的测试程序,对程序的不同部分进行测试。
  6. 并非所有软件缺陷都要修复
    项目小组要对缺陷进行取舍,根据风险决定哪些缺陷要修复,哪些不需要修复。
  7. 何时一个问题才叫缺陷
    参照第1章 判断软件缺陷的五个规则。
  8. 产品说明书从没有最终版本
    产品更新换代速度快,测试人员必须要想到未曾计划测试的功能可能会增加,经过测试并报告软件缺陷的功能可能发生变化甚至删除。
  9. 软件测试人员在产品小组中最不受欢迎
    早点找出缺陷;控制情绪;不要总是报告坏消息。
  10. 软件测试是一项讲究条理的技术专业

3.软件测试的术语和定义

  • 精准(precision)&准确(accuracy)
    • 精准:稳定性
    • 准确:正确性
  • 确认(verification)&验证(validation)
    • 确认:保证软件符合产品说明书。
    • 验证:保证软件满足用户要求(有时产品说明书并不能完全满足用户要求)。
  • 质量(quality)&可靠性(reliability)
    • 质量:软件产品能够满足用户需求,并且用户会感到该产品的性能优越,优于其他产品。
    • 可靠性:表示程序的稳定程度,仅仅是质量的一个方面。
  • 测试(testing)&质量保证(quality assurance,QA)
    • 测试:尽早找到软件缺陷,并确保其修复。
    • 质量保证:创建和执行一些标准和方法,改进软件开发过程,防止软件缺陷发生。

第二部分 测试基础

2019.05.20 - 2019.05.22
第4章:静态黑盒——检查产品说明书,并在软件编写之前找出问题;
第5章:动态黑盒——在不了解软件如何工作的前提下进行测试;
第6章:静态白盒——通过正式审查和检验检查代码的细节;
第7章:动态白盒——在看到软件的工作方式时,根据获得的信息对软件进行测试。

第四章 检查产品说明书

1.为何要测试产品说明书?
除了大爆炸模式,其余三种开发模式(边写边改、瀑布、螺旋模式)都要求开发小组根据需求文档编写产品说明书,用意定义软件是什么样的。

  1. 在产品说明书中完善描述产品,可以确保最终产品符合客户要求以及正确计划测试投入。
  2. 测试人员可以将产品说明书作为测试项目的书面材料,据此可以在编写代码之前找出软件缺陷。

2.测试产品说明书的方法

  • 黑盒测试(black-box testing)&白盒测试(white-box testing)
    黑盒测试:又称功能性测试(functional testing)或行为测试(behavioral testing)。无法看到软件究竟如何运行,只知道程序进行一些输入,就能得到某种输出结果。
    白盒测试:又称透明盒测试(clear-box testing)。测试人员可以访问具体代码,可以根据代码检查结果判断可能产生的缺陷,并据此定制测试。
    ——因为要适应代码操作而进行定制测试,所以很容易形成偏见而无法进行客观测试。
  • 静态测试(static testing)&动态测试(dynamic testing)
    静态测试:不运行软件,只是检查和审核。
    动态测试:通常意义上的测试,使用和运行软件。
    测试人员可以利用书面文档进行静态黑盒测试,认真查找其中的缺陷,可以在软件代码编写前就尽早的找出缺陷。

3.产品说明书测试流程

  1. 高级审查
    ——更好的了解产品以及影响其设计的外部因素,找出根本性问题或遗漏之处。
  • 站在客户的角度思考需求
    当审查到某部分的专业知识不理解时,不要放掉,因为正式设计测试时一定会再次遇到这个问题。
  • 研究现有的标准和规范
    比如:公司惯用语和约定、行业要求、政府标准、GUI、安全标准等。
  • 审查和测试类似软件
    有助于设计测试条件和测试方法,还可能暴露意想不到的潜在问题。
  1. 低层次测试
    ——确保所有细节都被定义。
  • 产品说明书属性检查清单:
    a. 完整(是否有遗漏和丢失?)
    b. 准确(既定方案正确吗?)
    c. 精确(描述是否清楚?)
    d. 一致(功能描述是否自相矛盾?)
    e. 贴切(陈述是否简洁?)
    f. 合理(以现有的资源能否实现目标?)
    g. 代码无关(是否专注于定义产品,而非软件架构、代码?)
    h. 可测试性(功能能否测试?)
  • 产品说明书用词检查清单:
    a. 总是、每一种、所有、从不——绝对肯定的描述
    需要考虑违反这些情况的用例。
    b. 当然、因此、明显、必然——意图说服你接受假定情况
    考虑违反前提条件的用例。
    c. 某些、有时、常常、大多、几乎——描述过于模糊
    “有时”发生的功能无法测试。
    d. 等等、诸如此类、以此类推、例如——没有明确定义功能
    无法测试,需要对功能进行明确解释。
    e. 良好、迅速、高效、稳定——无法量化
    必须进一步准确定义其含义。
    f. 处理、进行、拒绝、跳过、排除——隐藏大量需要说明的功能
    细化功能操作步骤。
    g. 如果……那么……(没有否则)——缺少否则句
    需要明确定义当条件没有发生时,会产生什么结果。

第5章 带上眼罩测试软件

1.动态黑盒测试
有效的动态测试需要关于软件行为的一些定义(需求文档或产品说明书)。
根据产品说明书了解被测试软件的输入和输出,定义合适的测试用例。
——选择测试用例是测试人员最重要的一项任务,不正确的选择可能导致测试量过大或过小,甚至测试目标不正确。

2.通过性测试(test-to-pass)&失效性测试(test-to-fail)

  • 通过性测试:确认软件至少能做什么,而不考验其能力。
    ——仅仅运用最简单、最直观的测试用例,不需要想尽办法让程序崩溃。
  • 失效性测试:在确定软件在普通情况下能够正常运行后,有意共计软件的薄弱环节。
    ——设法迫使指定的错误信息出现,或迫使未考虑到的错误暴露出来。

3.等价类划分(equivalence partitioning)
把软件具有相似输入、相似输出、相似操作的分在同一个等价组,不对同组的用例进行过多重复的测试,有效的把无限测试用例集缩小。
由于这是不完全测试,所以是有风险的,如果为了减少测试用例的数量过度划分等价类,就有可能漏掉那些可能暴露软件缺陷的测试用例。

4.数据测试
对数据(如:键盘输入、鼠标单击、打印输出等)进行软件测试,就是在检查用户的输入信息、返回结果以及中间计算结果是否正确。
根据原则对大量的数据进行等价划分,以合理的减少测试用例。

  • 边界条件(boundary condition)
    数据等价划分为有效数据和无效数据
    ——测试最后一两个合法的数据点,和第一两个非法的数据点。

  • 次边界条件(sub-boundary conditions):有一些边界在软件内部,最终用户看不到(如:2的幂、ASCⅡ码表)。

    • 默认、空白、空值、零值和无:不是输入不正确,而是根本没有输入。
      ——设置默认值或提示错误信息。
    • 非法、错误、不正确和垃圾数据:失效性测试对象,输入不合法的数据。
  • 状态测试
    软件状态(software state)是指软件当前所处的条件或者模式。
    ——软件通过代码执行了某个分支,触发一些数据位,设置某些变量,读取某些数据,转入一个新的状态。

    • 状态转换图三要素
      a. 软件可能进入的每一种独立状态
      b. 从一种状态转入另一种状态所需的输入和条件
      c. 进入或退出某种状态时的设置条件即输出结果

    • 描述状态
      定义完备的状态变量(state variable)——与进入和退出状态相关的静态条件、信息、值、功能等。

    • 失败状态测试
      竞争条件&时序错乱:大多数操作系统都具备多任务执行的能力,所以软件执行过程中随时有可能被中断。
      ——首先仔细查看状态转换图中的每一个状态,找出那些外部影响会中断该状态。如果此时数据未准备好,或使用时发生了变化,状态会怎么改变。(如:共享同一台打印机,同时启动软件的多个实例等)
      重复、压迫和重负:测试极端恶劣的条件下可能发生问题的状态。

  • 重复测试(repetition testing):重复执行相同的操作。
    ——主要检查内存泄漏(memory leaks)问题。(如:反复读写数据,重复启动关闭程序)

  • 压迫测试(stress testing):使软件在内存小、磁盘空间少、CPU速度慢、调制解调速率低等不够理想的条件下运行。
    ——观察软件对外部资源的要求和依赖程度。
    - 重负测试(load testing):让软件处理尽可能大的数据文件。
    ——最大限度发掘软件的能力。(如:高并发,长时间运行)

第6章 检查代码

1.静态白盒测试
在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码,从而找出软件缺陷的过程,有时成为结构化分析。
在开发过程初期,让测试小组集中精力进行软件设计的审查非常有价值,可以尽早发现软件缺陷,也可以为黑盒测试员提供设计和应用测试用例的思路。

2.编码标准问题
注意:在对软件进行正式审查时,测试和注解的对象仅限于错误和缺漏,不同的编写风格不是缺陷!

3.通用代码审查清单

  1. 数据引用错误
    使用未经正确声明和初始化的变量、常量、数组、字符串或记录。
  2. 数据声明错误
    不正确的声明或使用变量和常量。
  3. 计算错误
    糟糕的数学问题,使计算无法得到预期结果。
  4. 比较错误
    边界条件问题,小于、大于、等于、不等于、真、假。
  5. 控制流程错误
    计算或比较错误直接或间接导致,循环等控制结构未按预期方式工作。
  6. 子程序参数错误
    子程序不正确地传递数据。
  7. 输入/输出错误
    文件读取、接收键盘或者鼠标输入以及向打印机或者屏幕等输出设备写入错误。
  8. 其他检查
    是否统一编码、是否需要移植、是否兼容、是否有错误提示。

在测试代码时应该考虑这些标准,但应该在研读其他公开的标准之后采用符合自己小组的自定义标准。

第7章 带上X光眼镜测试软件

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

2.分段测试

  • 为什么?
    不分段类似于大爆炸的开发模式,难以找出出现问题的原因和导致问题的部分,并且某些软件缺陷掩盖了其他软件缺陷,核心问题很难弄清。

  • 单元测试(unit testing)和集成测试(module testing)
    递增测试的两条途径:

    1. 自底向上:编写测试驱动模块调用正在测试的模块
      ——向处于测试的模块发送测试用例数据,接受返回结果。
    2. 自顶向下:编写桩(stub)代码充当接口模块
      ——将上层模块需要的数据直接由文件输入,只需要配置桩就能快速实验测试用例。

注意:在进行白盒测试之前,一定要根据说明书建立黑盒测试用例,这样才能真正测试到用户在实际使用情况中可能会进行的操作。

3.数据覆盖

  • 数据流覆盖
    ——在软件中完全跟踪一批数据,在程序运行期间检查变量的中间值。
    可以根据观察结果决定更改某些测试用例,保证变量取得感兴趣的、甚至具有风险的中间值。
  • 次边界覆盖
    询问编写代码的程序员是否知道这些次边界条件,并对内部数据表给予特别的注意,因为这里聚集了大量次边界条件。
  • 公式和等式
    ——公式中会出现某些变量取值不合法而导致崩溃,这在黑盒测试中是不能看出来的。
    技巧:不关心公式和等式是如何实现的,仅查看它们使用的变量,在程序正常输入输出之外,为其建立测试用例和等价划分。
  • 错误强制(error forcing)
    ——如果在调试器中调试,可以强制改变变量的值,以达到测试错误提示的目的。

注意:不要设置现实世界中不可能出现的情况,可以和程序员一起反复检查错误强制情况是否合法。

4.代码覆盖(code coverage)
为了全面覆盖,必须测试程序的状态以及程序流程,设法进入和退出每一个模块,执行每一行代码,进入软件每一条逻辑和决策分支

  • 程序语句和代码行覆盖
    语句覆盖实际上是一种误导,即使全部语句都被执行了,但也不能说走遍了软件所有路径(如:不进入循环)。
    • 分支覆盖
    • 条件覆盖
      复杂判断(如:两条件的IF),用例保证覆盖IF语句中每一种可能(如:A对B对、A错B对、A对B错、A错B错)。
      如果测试了条件覆盖,那么就也达到了分支覆盖和语句覆盖。
2007-03-04 01:34:50 congdou5265 阅读数 1
  • 初级学软件之ASP.NET第二季 内置对象

    初级学软件之ASP.NET第二季 内置对象 视频课程 主讲内容: 第一讲 Response对象 第二讲 Request对象 第三讲 Application对象 第四讲 Session对象 第五讲 Cookie对象 第六讲 Server对象 第七讲 ViewState对象

    2375 人正在学习 去看看 胡延亮
软件测试(第二版)81adf017-07b8-49c6-8903-056653ae21e1.jpg
:
Detail:软件测试(第二版)[@more@]

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23243/viewspace-902389/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/23243/viewspace-902389/

没有更多推荐了,返回首页