软件测试基础定义
- 软件测试是获取信息的技术调查
- 软件测试的目标是发现软件错误，并予以修正
- 测试是一个迭代过程
缺陷报告
缺陷报告的目的
- 缺陷报告为了让缺陷得到修复
- 尽早提交
- 报告所有缺陷, 提供多的信息, 又要有业务信息又要有技术信息
- 清楚说明对用户价值的危害
遇到缺陷
当遇到缺陷后，可以采用时间盒的方式处理测试时间分配的问题，处理下面两个问题
- 是继续调查当前缺陷以提供更简化的重现步骤，还是开的新的测试
- 是继续测试该功能，还是测试其他功能
当遇到缺陷后，应该通过技术调查发现更多的信息
- 一是发现一些额外的信息，使得之前的缺陷报告更加完整
- 二是可能会发现更多相关的缺陷
后续测试的一个切入点是评估当前缺陷的风险。也就是风险暴露的可能性，用户可能遇到此缺陷的可能性，暴露此缺陷的用户场景的情况。 还有就是风险暴露所带来的损失，评估这个缺陷所带来的最大用户损失
7大产品元素从而多角度的思考测试覆盖
- 结构
- 功能
- 数据
- 接口
- 平台
- 操作
- 时间
测试覆盖并非唯一的测试切入点，测试人员还可以利用漫游测试，基于缺陷的快速测试等方法来测试产品。其目的是通过多样化的测试来获取更多的信息，从而更好的评估缺陷的风险
编写高质量的缺陷报告
- 为每一个缺陷单独提交一份缺陷报告，小缺陷也是如此
- 仔细编写缺陷报告的标题。 “条件-失败”，阐述在何种情况下软件会发生什么样的失败
- 像编写详细测试用例那样编写重现步骤
- 使用缺陷模板来提交缺陷
- 在编写缺陷报告时，要考虑缺陷查询
- 链接相关的缺陷
- 注意缺陷报告的可读性
- 客观中立的书写缺陷报告。对于软件设计，解决方案，不要涉及，只写错误报告。
测试缺陷修复
- 普通影响力的缺陷修复: 普通缺陷
- 小规模的回归测试
- 高影响力的缺陷修复: 测试架构级别的改动，发布前的缺陷修复，测试已发布产品的补丁
- 需要周密的测试
测试缺陷修复的策略
- 基本检查- 重新执行重复步骤
- 查看改动代码集，了解当前测试
- 考虑产品的七个分类，不要完全复用旧的test case，应该新增加测试用例来扩展测试的深度和广度
- 对修改的代码做影响分析。通过考虑被修改代码的输入，输出，副作用，他可以更好的设计测试
- 考虑哪些功能与被修改的功能共享数据
- 根据缺陷类型，做针对性的测试
坚持阅读缺陷报告
- 了解当前有哪些活跃的缺陷
- 学习测试技巧，完善测试设计
- 获得测试灵感
- 追踪软件设计
- 总结缺陷模式
测试文档
测试文档两类：
- 产品: 供他人阅读和使用的文档
- 工具: 测试小组的内部文档或测试人员的个人文档。团队或是个人实施测试的工具，其根本价值在于帮助测试人员更有效的测试
对于大部分软件项目，项目团队的目标是交付有竞争力的产品，测试小组的任务和通过技术调查提供产品的质量信息
测试文档是持续演化的工具
提供测试信息
- 测试计划： 一组指导测试过程的想法
- 测试设计规约： 测试策略(一组指导测试设计的想法和详细的测试设计)
- 测试总结报告
- 缺陷报告
- 操作笔记
- 测试笔记
- 测试资料
- 移交文档
- 测试知识库
在测试中演化测试文档
测试迭代： 测试学习—>测试设计—>测试执行—>测试评估—>测试学习
通过测试迭代对测试文档进行持续演进，将文档维护融入测试过程，使测试文档成为活文档
注重实效的测试文档
维护测试文档会不会占用很多测试时间？ 测试文档应该内容精炼，格式灵活，相互参考
对于测试人员，测试文档的内容不外乎为：
- 需要测试的功能和属性（测试对象和测试覆盖）
- 如何实施测试（测试设计和测试执行）
- 如何判断软件是否出错（测试先知）
- 测试过程中发现了哪些信息（测试发现）
- 测试进度和测试资源
在测试实战中，测试人员可以用测试覆盖大纲或测试想法列表为核心文档，用它来驱动测试设计和执行，并记录测试所发现的信息
一种很简单的测试覆盖大纲就是功能列表
- 建立了被测对象的整体模型
- 提供了可扩展的测试设计框架
- 提供了测试覆盖的目标
- 简洁的形式提供丰富的信息
- 格式灵活，允许用多种方式记录信息
形形色色的测试文档
测试文档的主要功能
- 为完成技术任务提供便利： 测试文档提供技术信息，以支持更好的测试设计和执行
- 改善测试任务和测试过程之间的联系： 测试文档解释测试策略背后的思想，测试的覆盖范围，测试工作的规模，测试的深度和广度，测试分工等，从而帮助测试小组与整个项目的交流和协作
- 为组织，规划和管理测试项目提供结构
测试计划： 一组指导测试过程的想法
启发式测试计划的语境模型 Heuristic Test Planning Context model. HTPCM的特征是测试计划者通盘考虑产品需求，项目环境，测试小组，测试资源，明确测试任务，并制定相应的测试过程。
好的测试计划是基于语境的，只有符合项目情况的测试方案才能有效地工作。 测试方法各有巧妙，无所谓好坏。讨论优秀，不应该只考虑测试方法本身，而是要考虑测试，实现和环境是否紧密联系，即优秀是对测试，实现和环境之间关系的描述
example
针对所有构建的基线测试
- 每个构建都要执行的测试：冒烟测试和性能测试
针对最新可测构建的每日测试
- 每天对于最新的可测构建进行持续的测试
- 手工的验收测试
- 自动化功能性回归测试
- 运行最热门的测试用例
- 压力测试，持续测试，稳定性测试
- 持续的手工探索式测试和漫游测试
- 针对自动更新的测试
针对发布候选构建的测试
- 网站兼容性测试
- 演示情景验证
- P0缺陷验证
- 全面压力和稳定性测试
- 手工测试
平衡手工测试和自动化测试
- 解释手工测试和自动化测试的适用范围，为测试资源运用提供指导
Google ACC (Attrribute, Component, Compatibility)google团队使用的一种建模方法，来快速的建立产品的模型，以指导下一步的测试设计。
风险分析。Google的ACC工具则通过分析项目元素(测试用例，代码变更，产品缺陷等)来识别分享。 可以利用电子表格自行计算各个条目的风险。在评估风险的时候，他可以考虑以下因素：
- 自动化测试用例
- 手动测试
- 代码变更
- 代码复杂度
- 产品缺陷
测试设计规约
- 测试设计规约是一个容器，可以容纳各种测试模型和资料
- 测试人员需要建立测试设计的框架
- 测试想法优于测试用例
- 合理的利用测试模板
功能测试建模方式：功能列表
通过将产品的功能分解为层次结构，为功能覆盖提供指导。与漫游测试相互支持。
大纲与思维导图
表格
测试指南
测试想法列表。测试启发式方法备忘单
质量特性列表
操作文档
检查列表
缺陷目录
测程表
基于测程的测试管理： session based test management .一个测程包括四个要点： 主题，时间表，可评审的结果和简报
