《敏捷中的软件测试》读书笔记（一）

本书主要从敏捷团队，组织挑战，敏捷测试象限，自动化，测试人员的一个迭代五个部分进行讲解。本篇主要总结了前三个部分的干货，剩余部分请见本篇《敏捷中的软件测试》读书笔记（二）

一.简介

1. 敏捷团队角色

不同团队之间的区别是为了产品发布贡献的不同技能。

• 客户团队：项目中所有属于“业务”一方的人(包括业务分析师，产品经理，问题专家等)。编写story和需要发布的功能集。
• 开发团队：参加发布代码的任何一个人都是开发人员，任何团队成员都可以承担任何类型的任务(包括测试人员，程序员，架构师等)

客户团队需要设定开发的用例的优先级，开发团队确定他们所需的工作量。

2. 敏捷测试人员和传统测试人员有何不同

• 传统测试中的测试人员往往被期望成为质量守护者
• 传统的开发周期通常很长，测试人员通过研究需求报告来制定测试计划
• 敏捷测试人员在工作中密切接触业务，详细了解需求
• 敏捷测试人员帮助客户编写定义下一步故事需求的测试用例，与开发人员一起寻找测试中的遗漏
• 快速从测试中得到反馈，驱动项目前进

3. 敏捷测试和传统测试有何区别

• 敏捷是迭代和增量的。团队构建测试少量代码，确保可以正常工作，然后转移到下一个需要构建的部分。程序员从不超前与测试人员，因为一个功能在被测试之前都是未完成状态
• 敏捷测试关注于业务价值和交付满足客户需求的软件
• 传统测试只专注于与需求一致

4. 敏捷团队的运作方式

意味着参与交付软件的每一个人都有责任交付高质量的软件

• 质量保证不单单是测试人员来负责，整个团队经常共同思考如何设计具有可测试性的代码
• 不同团队成员之间的持续合作，不仅就测试任务合作，例如构建基础设备和为可测试性进行设计
• 团队中的每个人都可以寻求和获得帮助

5. 敏捷测试人员的十条法则

• 敏捷测试思想：以客户为中心，注重结果，勤于耕作，协作，富有创造力，乐于学习和适时地创造业务价值
• 敏捷测试人员：专业的测试人员，适应变化，与技术人员和业务人员展开良好合作，并理解利用测试记录需求和驱动开发的思想。
• 十条法则：帮助团队识别和满足客户提出的每一个故事的需求。敏捷测试人员通过自己独特的观点和面向客户的方法为团队和组织创造价值：
• 提供持续反馈
• 为客户创造价值
• 进行面对面的沟通
• 勇气
• 简单化
• 持续改进
• 响应变化
• 自我组织
• 关注人
• 享受乐趣

二. 组织挑战

1. 文化因素影响团队转变到敏捷开发

• 技能和适应能力：团队成员不能适应敏捷实践，包括不能改变测试方式的测试人员与开发团队的其他人密切工作的时候会很艰难。
• 辅助因素：
  敏捷项目通常会使用回顾总结等工具来鼓励不断改进和适应，要求适应性强，并且能在敏捷项目中改进和发展
  敏捷实践需要时间和培训来让团队成员适应
• 合适的节奏：敏捷价值的中心思想是让大家时刻以最好的状态工作。可以偶尔高强度工作或加班，但也是整个团队一起加班
• 客户关系：将买卖关系转换为合作关系
• 组织规模：组织规模越大，结构中的层次可能会越多，组织越大，当形成自顶向下的交流渠道时，报告结构变得指令化，不适合技术和业务的沟通。
• 沟通挑战：每日站会，客户代理等
• 授权团队：让团队的每个成员都有做决定的权利

2. 质量保证团队适应敏捷的障碍

1. 丧失身份：害怕团队分散丧失质量保证人员的身份，无人支持等
2. 缺乏培训：不理解新角色导致不适应
3. 不理解敏捷概念：仍存在‘小型瀑布’现象，测试编码不同时进行，压缩测试时间
4. 过去的经验和观点：不同成员没有自组织相互协作沟通，互相抱怨
5. 角色间的文化差异

3.构建敏捷团队的方式

1. 引入变化：讨论恐惧，赋予团队权利，庆祝成功
2. 把测试人员整合到敏捷项目
3. 人员分布：不管是同一位置还是分布式团队都应利用工具或空间实时协作
4. 人力资源：招聘测试人员应多考虑的是技能之外的东西，是否能适应敏捷团队，因为质量是整个团队的责任
5. 团队建设： 自组织团队，业绩和奖励，自我能力贡献

3. 敏捷测试及开发的结构

1. 敏捷项目团队是跨职能的
2. 根据项目规模不同，一些专家或者测试人员可能同时服务于几个团队
3. 测试人员的工作和其他项目人员的工作一起被管理。测试人员可接触更大的测试人员社区学习和实验新的想法。

4. 传统面向质量的过程如何将其应用到敏捷环境中

1. 正确使用度量标准
   提醒团队偏离轨道或者在正确的道路上提供反馈。明确目标并且是可衡量的，例如单元测试量，测试覆盖率，缺陷率等
2. 缺陷跟踪
   优点: 便捷，用作知识库，跟踪
   缺点：成为沟通工具，减少了成员彼此的直接讨论；浪费时间和精力
3. 测试计划

测试策略是一种静态文档，很少改变，而测试计划对每一个新的项目都要创建新的。

测试计划最大一部分是为了可跟踪性，是否执行了期望行为的所有测试。敏捷中通过细小、定义良好的步骤构建功能，例如单元测试，以及对每张故事卡的验收测试。

三. 敏捷测试四象限

1. 测试四象限

敏捷测试象限.jpg

2. 支持团队的测试

• 象限一：单元测试，组件测试
  是面向技术的测试，是面向开发人员的测试。常用测试自动化工具xUnit进行自动化。是自动化测试。
  目的：测试驱动开发TDD，帮助程序员准确理解代码需要什么及提供正确设计的指导而保证内部质量。
  优势：效率更高，测试人员工作更容易，设计时谨记测试，及时反馈
  工具：为了支持团队的面向技术测试，敏捷团队需要源代码控制，测试自动化，IDE和构建管理等工具。

• 象限二：功能测试，用户故事测试，实例，原型，仿真
  是面向业务的测试，也是面向客户的测试。这个象限可能与单元级别完成的某些测试重复，但第二象限是在一个更高层次的面向实例的确认期望的系统行为。包括自动化和手动测试
  目的：快速提供信息并确保快速的解决问题。帮助了解应用何时完成并验证外部质量。
  需求困境：
  1.共同语言：使用图片，流程图，电子图表和原型等可以被不同背景和观点的人接受的工具
  2.激发需求： 提问，使用示例
  3.多重观点：考虑不同角色用户的角度和观点
  4.与客户增进交流：面对面或者交流工具的交流
  5.增进清晰度：同一用户故事，不同角色会有不同的定义，所以需要明确需求
  6.满足条件：这些条件通常来自与客户有关高层次验收标准的讨论，有助于识别风险假设和提高团队编码的信心
  7.涟漪效应：细小，简单的故事可能存在广泛的影响，并且该故事触及的应用每一部分都可能复杂度很高
  测试工具包：
  1.激发示例和需求的工具：核对表，思维导图，电子表格，模型，流程图等
  2.基于示例自动化测试的工具：单元测试工具，API级别功能测试工具，测试GUI的工具，录制回放工具，自制的测试自动化工具
  编写测试策略：增量构建测试，确保测试通过，使用合适的测试设计模式，构建/操作/检查，基于时间的，活动和事件模式，关键字和数据驱动测试

3. 评价产品的测试

• 象限三： 探索测试，场景，可用性测试，用户验收测试
  是面向业务的测试，尽量模仿真正用户使用应用的手动测试。探索测试是这一象限的重点。这类测试依赖于人们的智力，经验和直觉。
  目的： 评价产品是否没有达到期望或者对抗竞争
  测试方式：
  1.实例演示：通过向团队进行用户故事演示，做一些探索测试
  2.场景测试：创建场景，模拟最终用户行为和工作流
  3.探索测试：基于会话的测试，自动化和探索测试
  4.可用性测试：用户需求和角色测试，导航，研究竞争对手
  5.图形用户界面背后：API测试(不同参数，API调用顺序)，Web服务(消息格式和处理，排队时间以及消息响应时间等)
  6.测试文档和文件：用户文档(检查文字，链接等)，报告(简单易读)
  探索测试辅助工具： 测试设置，生成测试数据，监控工具，模拟器，仿真器

• 象限四：性能和压力测试，安全性测试，“非功能性”测试
  是面向技术的测试。通过工具来测试产品的安全和速度等因素，要考虑在恰当的时间进行这些测试，不能留到最后。
  目的：评价产品的技能，健壮性和安全性等非功能性特性。
  ility测试：安全性，可维护性，交互性，兼容性，可靠性，可安装性。
  项目应该一开始就进行性能，压力，负载及可伸缩性测试。

4. 管理技术债务

敏捷测试矩阵的每个象限担任保持技术债务在一个可管理的水平的角色。运行单元测试自动化的构建和集成过程是最小化技术债务的必需品。

5. 测试管理

测试应该包含在源代码控制机制中，以便于跟踪哪个版本的测试运行于哪个版本的源代码之上。

6. 文档

• 在开发过程中可以用文档记录测试代码，可以方便的看出我们的测试对象和测试代码的功能
• 汇报测试结果，通过日志或者报告系统向组外人提供测试结果