测试笔记

　　用了一个多月的时间看完了陈能技的《软件测试技术大全》，可谓是受益不浅，如今总结一下笔记，分享也好，复习也好

　　全书四篇二十章，我也按照篇章来总结，方便之后查看，可是总结完第一篇就总结第四篇，为了弥补我以为本书不够好的地方。不少人都以为测试很简单，没前途，因此不重视，学测试的人也有部分这样认为。第四篇讲的是软件测试的学习环境和研究方向及我的发展，无疑是给学习测试者打上一剂强心剂，才能让他们更加自信的学下去。

 

第一篇 软件测试的基础

第1章  软件测试概述

测试人员的能力不足的缘由：

• 基础知识不过扎实：仅浮浅地了解一些基本的测试设计方法，并无深刻理解
• 专业技术不够精通：没有真真正正地应用 某些工具或技术
• 没有创建相对完整的测试体系概念，忽视理论知识：理论知识缺少，认为理论知识没用而没有深刻理解测试的基本道理

Harry Robinson提出的迎接测试将来挑战的建议：

• 积极地不满于现状：不要被动接受或知足测试的现状
• 抛开人与人之间的隔阂：总结、分享、学习
• 学习更多关于测试的知识：参加交流会、论坛、阅读优秀资料
• 学习更多关于开发的东西：阅读相关文档、和开发人员交流

第2章 软件测试的组织

一我的的测试是不可能成功的，测试是一项须要合做进行的工做。

微软的结论：不能依赖开发人员测试，也不能依赖外部公司的测试，必须本身创建一个独立的测试部门。

测试组织分类：项目型和职能型

• 项目型的测试组织：指测试人员做为项目组成员之一，紧密地结合到项目中，与项目组其余组员紧密协做，从头至尾跟着项目走。
  • 项目经理是负责测试资源调配和测试计划的主要人员
  • 测试人员参与的力度强，能深刻了解项目方方面面的信息，有利于稳定持续有效地测试出更多细节问题
  • 测试人员对bug的处理意见上受到项目负责人约束
  • 测试经验不利于普遍传播
  • 测试人员可能会感受在团队中被孤立
• 职能型的测试组织：指测试人员参与到项目中，以独立的测试部门委派的方式进入。
  • 测试人员可能同时测试多个项目
  • 测试人员向所在部门的经历报告工做
  • 能节省部分测试资源，充分利用各阶段之间的时间差来合理利用资源
  • 测试深度不够，对业务知识和领域知识涉及不深，致使测试的问题相对表面化

快速融入项目团队的技巧

• 尽可能了解每位开发人员的性格特色
• 对开发人员正在开发的产品功能产生兴趣
• 将缺陷跟踪库中全部之前的bug都查看一遍
• 保持虚心学习的态度

尽快投入测试工做的技巧

• 阅读需求文档、设计文档及用户手册是关键的第一步
• 若是项目处于前期阶段，则应该多参与项目的各类会议，尽可能多了解项目的各方面知识
• 阅读已有的测试用例或根据需求和设计文档编写测试用例
• 阅读缺陷库中的bug，并尝试复现

测试规范：包括内部规范和全局规范

• 内部规范：指测试人员在测试工做过程当中须要遵循的规范
  • 软件测试方法指南：是对测试人员在进行各类类型的测试时进行规范化的要求
  • 测试用例设计规范：通常包含测试用例的模板以及测试用例设计的要求
  • 缺陷录入规范：用于规范化测试人员的bug录入过程
  • 测试计划规范：通常包含测试计划的模板以及对测试计划的要求
  • 测试报告规范：通常包含测试报告的模板以及对测试报告的要求
  • 测试工具使用规范：指测试人员在何时使用那些工具，工具的参数设置须要注意哪些方面的问题
• 全局规范：指测试人员与其余项目成员之间须要共同遵循的规范
  • 缺陷分类规范：指如何把bug进行归类
  • 缺陷等级划分规范：是bug的严重程度标识和优先级标识的依据
  • 测试提交流程规范：是开发人员提交某项完成的功能模块给测试人员测试时应该遵循的流程
  • 缺陷状态变动规范：要求项目组不一样角色的人对bug状态的修改和更改权限应该遵循的流程

第3章 软件测试人员应具有的条件

测试人员应具有的基本素质：

1. 对软件测试感兴趣:兴趣是最好的老师
2. 拥有适合作软件测试的性格特性：怀疑思惟
3. 好奇心：好奇心越强，越容易成为优秀的测试人员
4. 成就感：测试人员的成就感源于破坏和挑剔
5. 全面的思惟能力：思惟能力强，看问题全面
6. 责任感：对待软件测试的态度是对软件质量负责任的态度，对用户负责任的态度

测试人员的技能要求：

1. 业务知识：对业务知识了解的越多，测试就越贴近用户的实际需求
2. 产品设计知识：测试人员对与软件产品设计、软件架构方面的信息了解得越多，越有利于对测试深刻研究
3. 了解UML：UML对测试人员也是很是有指导意义的
4. 掌握测试工具：了解工具间的差别，及使用技巧
5. 了解开发工具：使用开发工具的一些基本操做
6. 用户心理学：始终站在用户的角度思考问题
7. 界面设计3种模型
   1. 设计者模型：关注的是对象、表现、交互过程
   2. 用户模型：关注目标、信心、情绪
   3. 实现者模型：关注数据结构、算法、库等界面实现实现是要考虑的问题
8. 人机交互认知心理学：
   1. 一致性原则：从任务完成、信息传递、界面控制和操做等方面应该与用户理解和熟悉的模式尽可能保持一致
   2. 兼容性：在用户指望和界面设计实现之间的兼容，要基于用户之前的经验
   3. 适应性：用户应该处于控制地位，所以界面应该在多方面适应用户
   4. 指导性：界面设计应该经过任务提示和及时的反馈信息来指导用户，须要作到“以用户为中心”
   5. 结构性：界面设计应该是结构化的，以减小复杂度
   6. 经济性：界面设计要用最少的步骤来实现一个用于支持用户业务的操做
9. 脚本语言：理想的自动化语言
10. 编写文档的能力：缺陷报告、测试报告
    1. 合理组织语言，体现清晰的思惟
    2. 多用短语和精炼的语言，忌长篇大论
    3. 适当空行和换行
    4. 每写一段话，先本身阅读一遍
    5. 尽可能规范写做格式

第四篇 软件测试的学习和研究

第19章 软件测试的学习环境

良好的学习环境主要依靠3个方面支撑：

• 书：可供学习的资料
• 制度：一个促使测试人员不断学习的机制
• 人：可让测试人员学习的楷模

软件测试的交流

• 与管理层交流
• 与开发人员交流
• 与测试人员交流
• 与业界同行交流

与开发人员交流注意事项：

• 定义本身角色，让开发人员感受到须要测试人员的帮助
• 测试人员应对那些感到疑惑的开发人员解释本身的工做
• 尽可能减小会产生误会和曲解的bug报告

第20章 软件测试的研究方向及我的发展

转型：

• 转向售前角色
  • 提升业务知识
  • 学习用户思惟
  • 提升表达能力
  • 增强沟通能力
  • 培养说服能力
• 转向售后角色
  • 提升软件操做的熟练度
  • 提到定位问题的能力
  • 强化环境知识
• 转向开发角色
  • 深化程序架构思想和构成的理解
  • 提升编码能力
• 转向QA
  • 增强对质量的理解
  • 加大对质量的宣传
  • 学会发现问题的本质

发展：关键是选择本身认为适合的持续发展路线，不要轻易动摇。

 

• 管理路线
  • 初级测试工程师：要求具有基本的测试执行能力和测试理论知识，主要集中在手工测试和基本的功能验证性测试方面
  • 中级测试工程师：要求具有测试设计能力，对测试理论知识的进一步理解，主要集中在黑盒测试的执行及其测试用例的设计，及具有必定的制定测试计划和测试报告的能力
  • 高级测试工程师：要求具有较强的测试用例设计能力，能把测试理论和知识融入到测试工做实践中，具有较好的制做测试计划和测试报告的能力；与中级测试工程师的明显界限是：测试经验。
  • 测试组长：具有相对较强的制做测试计划和测试报告的能力，测试的组织能力以及沟通能力。具有必定的测试风险意识，以及与开发人员交涉的能力，须要具有Bug评审的组织和缺陷分析能力。
  • 测试主管：须要管理多个测试项目的资源调度、人员招聘以及培训、能力评估和效绩考核。
  • 质量主管：主要关注测试的总体组织架构设置是否合理，测试工具的选型是否合理，测试人员与其余人员的沟通和交流是否存在问题；还会重点关注流程的质量，负责质量管理体系的创建和维护。
• 技术路线
  • 各测试工程师须要对相应的领域深刻而持续的研究。
  • 测试设计架构师：具有多方面或多个领域的丰富经验和知识；负责测试方面的总体设计。

第二篇 软件测试基本理论

第4章 软件工程与软件测试

软件的生命周期：计划->需求分析->设计->编码->测试->运行维护

软件工程研究领域：人员管理、项目管理、配置管理、质量管理、可行性分析->需求分析->系统设计->编码->测试。

软件开发模型：

• 线性模型：瀑布模型...
• 渐进式模型：螺旋模型...
• 变换模型
• 敏捷开发模式

不一样开发模式下的软件测试：

CMM（承制方软件工程能力的评估方法）分级

1. 初始级：软件过程缺少定义，项目的成功严重依赖我的，软件质量由我的的开发经验来保证；
2. 可重复级：实施了基本的项目管理和过程控制，依赖以往项目的成功经验来确保新的相似项目的成功。
3. 已定义级：全部项目遵循必定的标准进行管理，具有可量化的、文档化的过程管理；进一步减小了项目成功对于人的依赖性。
4. 已管理级：加入了评估和度量机制，利用评估和度量来对软件过程以及产品的作出合理的判断和控制。
5. 优化级：关注改进的持续性，融入了技术改革、缺陷预防等理念；软件组织可从本身的过程控制和管理中获得反馈信息，用于进一步指导过程的改进。

ISO 9000-3主要内容

• 合同评审
• 需求规格说明
• 开发计划
• 质量计划
• 设计和实现
• 测试和确认
• 验收
• 复制、交付和安装
• 维护

敏捷开发中的软件测试

• 敏捷测试做为团队的“车头灯”，帮助开发人员找到目标
• 敏捷测试注意内容：
  • 更多地采用探索性测试方法
  • 更多地采用上下文驱动的测试方法论
  • 更多地采用敏捷自动化测试原则

配置管理（CM）：用于控制复杂系统发展的一门学科，确保开发活动和测试活动顺利进行的工具

软件配置管理定义（SCM）：管理计算机程序产品进展的一门学科，包括在开发的初始阶段和产品的全部维护阶段

SCM的基本任务：计划、识别、控制、状态记录和状态审计。

第5章 软件测试的目的与原则

软件测试的目的：为了发现错误而执行软件程序的过程。一个成功的测试是发现迄今为止还没有发现的错误

软件测试的两面性：

• 为了验证程序能正常工做的测试
• 为了验证程序不能正常工做的测试

软件测试的验证和确认

• 验证是指在软件生命周期的各个阶段，用下一个阶段的产品来检查是否知足上一个阶段的规格定义
• 确认是指在软件生命周期的各个阶段，检查每一个阶段结束时的工做成果是否知足软件生命周期的初期在需求文档中定义的各项规格和要求。

软件测试的原则：

• Good enough原则
• Pareto原则（8020原则）
• 尽量早地开展测试
• 在发现较多错误的地方投入更多的测试（Bug具备集群性）
• 避免同化效应（交叉测试）

第6章 软件测试的方法论

软件测试的学派及对软件测试的定义

• 分析学派：认为测试是严格的技术性的；认为软件测试是计算机科学和数学的分支
• 标准学派：认为测试是用于衡量进度的一种方式，强调成本度量和可重复的标准；认为软件测试是一个管理的过程
• 质量学派：强调过程，测试人员负责审批开发人员，同时保证质量；认为软件测试是软件质量保证的分支
• 上下文驱动学派：强调人的做用，寻找利益相关的Bug；认为软件测试是开发的一个分支
• 敏捷学派：使用测试来验证开发是否完成，强调自动化测试；认为软件测试是顾客角色的一部分

IBM软件测试方法：基于RUP进行的

RUP：Rational统一过程模型，是一种强调迭代开发、持续集成的软件开发过程模型

• 回归测试：每添加新模块，旧模块都须要回归测试，最好可以自动化
• 测试度量：
  • 测试需求的覆盖
  • 测试用例的覆盖
  • 测试执行代码的覆盖
• 用例驱动：用一个个测试用例将系统分红多个模块进行测试，化简为繁

RUP对软件测试的分类：

• 可靠性：完整性测试、结构性测试
• 功能：配置测试、功能测试、安装测试、安全测试、容量测试
• 性能：基准测试、竞争测试、负载测试、性能曲线测试、强度测试

RUP对测试阶段的划分

1. 单元测试在迭代的早期实施，侧重于核实软件的最小可测试元素
2. 执行集成测试是为了确保当把实施模型中的构件集成起来执行用例时，这些构件可以正常运行
3. 当将软件做为总体运行或实施明肯定义的软件行为子集时，便可进行系统测试
4. 验收测试是部署软件以前的最后一项测试操做

第7章 软件测试的过程管理

PDCA循环：P(Plan)，D(Do)，C(Check)，A(Action)

• 测试需求的分析和肯定
• 测试计划
• 测试设计
• 测试执行
• 测试记录和缺陷跟踪
• 回归测试
• 测试总结和报告

需求说明书的检查要点：

• 正确性：对照原始需求检查需求规格说明书
• 必要性：不能回溯到出处的需求项多是多余的
• 优先级：恰当地划分并标识
• 明确性：不适用含糊的词汇
• 可测性：每项需求都必须是可验证的
• 完整性：不能遗漏必要和必需的信息
• 一致性：与原始需求一致、内容先后一致
• 可修改性：良好的组织结构使需求易于修改

测试计划要点：

1. 肯定测试范围：明确须要测试的对象
2. 制定测试策略
   • 测试战略：就是测试的前后次序、测试的优先级、测试的覆盖方式、回归测试的原则等
   • 测试战术：也就是采用的测试方法、技巧和工具等
3. 有效地利用测试资源
4. 合理地安排进度：每项测试最好预留缓冲时间
5. 评估风险：制定出相应的应对策略

测试用例设计方法

• 等价类划分法
• 边界值分析法
• 基本路径分析法
• 因果图法
• 场景设计法
• 错误猜想法
• 正交表法
• 均匀试验法
• 组合覆盖法：PICT工具

测试用例的选择策略：先执行基本的测试用例，再执行复杂的测试用例；先执行优先级高的测试用例，再执行优先级低的测试用例。

BVT测试：编译检查测试，主要检查源代码是否能正确编译成一个新的、完整可用的版本

冒烟测试：先检查软件的基本功能，在进行下一步测试

BVT测试和冒烟测试是全部正式测试执行以前的第一步

测试执行的结果只有两个：测试经过和测试不经过；测试不经过，测试人员应把缺陷记录下来，反馈给开发人员

撰写测试报告的基本原则：客观地陈述全部相关事实

Bug的生命周期：New->Open->Fixed->Rejected->Delay->Closed->Reopen

若是时间比较紧迫，修改后剩余的时间不足以作一次有效的回归测试的话，不进行修改多是种明智的选择

易脆（不可维护）是旧的软件系统被替换的主要缘由之一

时间紧迫是回归测试的难度所在，但更难的是要克服测试人员的疲劳思惟。

测试报告纲要：

第8章软件测试的度量

测试的度量原则

• 要制定明确的度量目标
• 度量标准的定义应该具备一致性、客观性
• 度量方法应该尽量简单、可计算
• 度量数据的收集应该尽量自动化

测试不能提升软件质量，软件的质量是固有属性，其提升有赖于开发人员的努力

测试人员的工做成果不能从软件的产品质量或软件的最终结果获得科学的评估

 软件测试的度量：

• 加权法度量缺陷

1. 1. 给缺陷加权
   2. 度量筛选后的Bug

• 定性评估：对测试人员发现的Bug的质量进行相对主观的衡量。

1. 1. Bug的类型分布
   2. Bug的重现率
   3. Bug录入的清晰程度、简明程度等
   4. Bug的新颖程度

• 测试覆盖率统计

1. 1. 代码行覆盖 = （已执行测试的代码行 / 总的代码行）*100%
   2. 功能模块覆盖率 = （已执行测试的功能模块数 / 总的功能模块数）*100%
   3. 数据库覆盖率 = （功能模块访问的数据库表面积 / 总的数据库面积）*100%
   4. 需求覆盖率 = （已执行的测试用例数 / 总共设计的测试用例个数）*100%

考核测试人员的硬指标

• 缺陷逃逸率 = （用户发现的缺陷个数 / 总共出现的缺陷个数）*100%
• 测试效率 = 执行的测试用例个数 / 测试执行的工做日

考核测试人员的软指标：Bug报告和测试报告

第三篇 实用软件测试技术与工具

第9章 实用软件测试技术

黑盒测试：把软件产品当成一个黑箱进行测试，测试只须要了解软件的输入结果和输出结果

白盒测试：是一种以理解软件内部结构和程序运行方式世纪城的软件测试技术

自动化测试：利工具进行重复性的工做，从而提升测试效率

手工测试不可替代点：

• 测试用例的设计：测试人员的经验和对错误的判断能力是工具不可替代的
• 界面和用户体验测试：人类的审美观和心理体验是工具不可模拟的
• 正确性的检查：人们对是非的判断、逻辑推理能力是工具不可替代的

探索性测试：同时设计测试和执行测试

探索性测试过程：

• 识别软件系统的目的
• 识别软件系统提供的功能
• 识别软件系统潜在的不稳定的区域
• 在探索软件系统的过程当中记录关于软件的信息和问题
• 建立一个测试纲要，使用它来执行测试

单元测试

狭义的单元测试：指编写测试代码来验证被测试代码的正确性

广义的单元测试：指小到一行代码的验证，达到一个功能模块的功能验证，从代码规范性的检查到代码性能和安全性的验证都包括在内

单元测试进行：开发人员编写测试代码，测试人员执行测试代码并收集和分析结果

单元级别的性能测试：性能的考虑应该在架构设计时就开始，对于架构原型要进行充分的评审和验证。

单元级别的性能测试角度：

• 代码效率评估
• 应用单元性能测试工具
• 数据库优化

AQTime：可计算出每行代码执行时间的工具

NTime：用于测试函数、方法的性能是否知足要求的工具

数据库性能检查

引发数据库问题的主要缘由：数据库的设计和SQL语句

数据库的设计：数据库的参数配置和逻辑结构设计

可找出有性能问题的语句的工具：SQL Best Practices Analyzer、SQLServer数据库自带的事件探查器和查询分析器、LECCO SQLExpert等

压力测试

负载测试与压力测试区别

• 负载测试须要进行屡次的测试和记录
• 压力测试的目的很明确，就是要找到系统的极限点

软件的容量测试：指软件系统在处理大数据量的时候，或者是加载大批量数据时的性能表现

容量测试的关键：模拟大批量的用户业务数据，首先要估算好用户若干年后可能出现的最大数据量

数据生成工具：DataFactor等

安全测试

• 网页安全漏洞检测工具：Paessler Site Inspector、Web Developer、AppScan等
• SQL注入检测工具：AppScan等
• 缓冲区溢出检测工具：AppVerifier

跟踪法测试：一种介于黑盒测试和白盒测试之间的测试技术

跟踪法技术测试关心中间的一些环节是否也是正确的

跟踪法测试应用：

• 跟踪SQL语句：SQL Server的事件探查器
• 跟踪网络Socket包：SockMon
• 跟踪日志

C/S结构软件系统的测试

• 易用性测试
• 服务器端的测试
• 性能测试
• 安全性测试
• 安装部署测试

B/S结构软件系统测试

• 连接测试
• Cookies测试
• 兼容性测试
• 并发访问测试

界面测试

界面模型：设计者模型、实现者模型和用户模型

界面测试要点：

• 制定界面设计规范
• 理解用户的目标
• 对界面原型进行测试
• 防止界面的“审美疲劳”

数据库测试

• 数据库设计的测试
• SQL代码规范性测试
• SQl语句效率测试
• SQL数据库兼容性测试

Web Services的测试

Web Services：是一种新的使用基于XML标准和协议来交换信息的Web应用程序

测试工具：

• 性能：LoadRunner、TestComplete
• 功能：WebInject、soapUI、SOAPtest和TestComplete

内存泄露测试

内存泄露缘由：

• 分配完内存以后忘了回收
• 程序写法有问题，形成资源没法回收
• 某些API函数的使用不正确，形成内存泄露
• 没有及时释放内存

检测工具：MemProof、AQTime、Purify、BundsChecker、Perfmon的Handle Count、Virtual Bytes和Working Set计数器

可访问性测试

工具：Rampweb_ToolBar、Watchfire WebXACT、Parasoft WebKing和QTP等

第10章 实用软件测试工具

• 测试管理工具：TestDirector
• 自动化测试工具：TestComplete、QTP
• 性能测试工具：LoadRunner
• 内存检查工具：BoundsChecker
• 测试用例设计工具：CTE XL

第11章 开源测试工具

• 使用开源工具的成本：
  • 学习和培训成本
  • 安装部署成本
  • 改形成本
• 测试管理类：Bugzilla、Mantis、BugFree
• 单元测试类：
  • 针对.NET
    • 单元测试框架：NUnit
    • 单元测试方法：NMock
    • 界面层代码测试：NunitForms
• 性能测试类：
  • Web性能测试工具：OpenSTA
  • 性能测试工具：TestMaker
  • 大数据生成工具：DBMonster
• 自动化功能测试类：
  • 自动化测试框架：Abbot Java GUI Test Framework
  • 功能测试工具和录制工具：SharpRobo
  • IE自动化测试工具：Samie

第12章 测试工具的原理及制做

使用Windows脚本辅助测试

• 大部分Windows操做系统都内置了脚本宿主（WSH），用于执行Windows脚本
• Windows脚本分两类：VBScript和JScript
• 使用JScript可进行的测试
  • GUI自动化测试
  • 检查注册表
  • 处理文件
  • 操做Excel
  • 运行应用程序
  • 使用WMI（Windows Management Instrumentation，即Windows管理规范）
  • 访问网络
  • 使用正则表达式
  • 发送邮件

猴子测试：利用测试工具随机产生键盘敲击和鼠标点击时间。

代码覆盖率测试工具：DevParner、AQTime

第13章 实用小工具的应用技巧

任务管理器：可用于了解被测程序各类信息的小工具

运行程序，查看“内存使用”和“虚拟内存大小”，当程序请求所须要的内存后，若是虚拟内存仍是持续地增加，就说明这个程序存在内存泄露。

判断网络链接速度是否存在瓶颈，能够用字节数/间隔与目前网络的带宽进行比较

若是处理器时间持续超过95%，则代表CPU处理存在瓶颈

Perfmon：Windows自带的性能监控工具

• 启动：在“运行”中输入perfmon，便可启用
• 可实时或计划监控计算机某些性能参数

NetStat:Windows自带的一个网络信息查询器

• 启动：在命令行中输入netstat以及一些参数，便可启动
• 可显示当前系统的全部TCP/IP链接状况，以及协议的统计信息
• 使用方法可在命令行中输入“netstat -?”查询

Visual SourceSafe的文件比较器：可用于比较两个文件之间的差别。

第14章 单元测试管理

自动化静态检查：主要根据代码的语法和词法特征来识别潜在的错误

自动化动态单元测试：经过执行那些实现了测试用例的测试代码的方式来进行测试，测试工具动态生成某些测试用例，而后自动转换成测试代码并执行

• 变量与值比较时，先写值，在写变量。
• 代码尽可能作到“高内聚，低耦合”
• 单元测试须要“广专结合”、“动静相宜”，“广专结合”是指广义的单元测试与狭义的单元测试相结合
• 重要的、经常使用的单元模块应投入更多的测试
• 单元测试可以让开发人员交叉测试
• 只有投入必定量的单元测试、覆盖足够多的代码区域，才能起到单元测试应有的做用

第15章 自动化功能测试管理

• 自动化测试的实现成本和维护成本

• 过早进行自动化测试会带来维护成本的增长
• 过多进行自动化测试不能换来持续加强的效果

适合自动化测试的用例：

• 容易实现自动化且重要的功能模块
• 能被有效的识别出控件的界面
• 能比较好地插入验证点进行结果验证的功能

自动化功能测试脚本

1. 线性脚本：使用简单的录制回放
2. 结构化脚本：在脚本中使用结构控制，如循环结构、分支结构等
3. 共享脚本：把表明应用程序行为的脚本在其余脚本之间共享
4. 数据驱动脚本：把数据从脚本分离出来，存储在外部的文件中，这样脚本就只包含编程代码，使得脚本在测试数据改变是不须要修改代码
5. 关键字驱动脚本：把检查点和执行操做的控制都维系在外部数据文件中，所以测试数据和测试操做序列控制都是在外部文件中设计好，除了常规的脚本外，还须要额外的库来翻译数据

• 衡量一个自动化的测试项目是否成功，缺陷率是主要指标之一

提升自动化测试效率的建议：

• 弄清开发软件所采用的编程语言
• 确保自动化测试工具能识别重要的GUI控件
• 用于展现内容的组件是否有公开的API，数据是否能输出到一个可读的文件格式
• 要求开发人员不要把混淆应用到GUI层面的代码中
• 要求开发人员给出一个或多个包含全部被测程序使用的GUI对象的窗口，测试人员尽早肯定自动化测试工具是否支持这些控件
• 清楚测试应用程序是否提供API，容许在GUI层如下进行测试

敏捷自动化测试原则

• 测试自动化意味着使用工具支持测试项目的各个方面，不仅是测试执行方面
• 当测试自动化获得指定的程序员支持是，会更加顺利进行
• 测试工具开发人员由测试人员领导
• 测试工具开发人员收集并应用各类工具来支持测试
• 测试工具开发人员帮助实现软件产品的可测性，并开发工具或小程序以便利用这些可测性
• 组织实现测试自动化是为了完成某个短时间任务
• 避免盲目地进行长期的自动化测试任务，而不是基于业务场景的分析

第16章 性能测试管理

性能测试的成本：测试成本和软件修改为本

性能测试步骤：

1. 测试脚本的开发
2. 测试执行
3. 测试结果的收集和统计

• 通常在功能测试完成后再开展性能测试，而且每次性能调优后，应先进行基本的功能冒烟测试和回归测试，确保功能测试正常后，在进行性能的回归测试
• 规划性测试：采用各类级别的低配置的及其运行测试，而后对测试结果进行拟合，从而推算出高配置的状况
• 最佳并发用户数应当大于系统的平均负载，是用来对用户公布的性能数据
• 最大并发用户数应当大于系统的峰值负载，是安全使用软件系统的最大极限

瓶颈分析：识别性能问题->分析性能问题->定位性能瓶颈

• 定位性能瓶颈应遵循“先外后内，先硬件后软件”的原则，先观察程序的外围影响因素，排除因为测试环境不当带来的性能问题

在有限的时间和资源的状况下，完成尽量全面的性能测试，则是一个成功的性能测试

性能测试的全面性：功能模块全面性和测试类型全面性

第17章 探索性测试管理

探索性测试：在对测试对象进行测试的同时学习测试对象，在测试过程当中运用得到的关于测试对象的信息设计新的更好的测试的方法

剧本化测试：严格按照先设计测试用例，再执行测试并记录结果的顺序的一种测试方式

探索性测试原理：在测试以前提出不少关于软件产品的疑问，而后设计测试并执行测试以获取答案。一般，测试不能很好地回答这些问题，全部须要调整测试比不断尝试

探索性测试过程：计划、学习和调查、测试执行、结果分析。

第18章 用户界面测试管理

操做界面要求：好用的、易用的、美观的。

用户界面应尽早进行，后期修改的风险及压力：开发人员修改的风险和测试人员漏测的风险

用户界面设计原则：

• “射箭”原理：使用户用最少的鼠标光标点击和键盘操做步骤来完成须要的功能，展现须要的界面，并在醒目的位置显示功能按钮
• 减小用户工做量：
  • 逻辑工做量
  • 知觉工做量
  • 记忆工做量
  • 物理工做量
• 少就是多：好的界面设计不是不能再添加一些界面元素，而是不能在减小一个界面元素。

尽可能避免使用模式对话框，由于它会使正在交互的界面动做无效或引发非预期的结果

应避免把不一样的操做绑在一块儿