第三章 测试工程师

目录

3.1 一种面向用户的测试角色

3.2 测试工程师的工作

测试计划

风险

3.1 一种面向用户的测试角色

TE以某种 特定的产品最合适的方式发现软件中风险最大的地方并尝试减少或消除它， 综合开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力

3.2 测试工程师的工作

TE进入产品时，需要考虑以下一些问题：

• 当前软件的薄弱点？
• 安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？
• 主要用户场景是否功能正常？对于不同国家的用户是否一样？
• 该产品与其他产品（软件和硬件）互操作吗？
• 当发生问题时，是否容易诊断问题所在？

TE在测试计划及测试完整性上必须更加系统和周密，重点在真实用户的使用方式和系统级别的体验上，善于发现需求中的模糊之处，分析沟通不明确的问题

TE拥有技术能力、领导力、深刻理解产品的能力、洞察力

TE职责：

• 测试计划和风险分析
• 评审需求、设计、代码和测试
• 探索式测试
• 用户场景
• 编写测试用例
• 执行测试用例
• 众包（以自由自愿的形式外包给非特定的大众网络的做法）
• 使用统计
• 用户反馈

测试计划

测试计划代表了对软件功能的预期，随着代码的更新而更新，时刻代表最新的产品功能

 测试计划具有的特性：

• 及时更新
• 描述软件的目标和卖点
• 描述软件的结构、各种组件和功能特性的名称
• 描述软件的功能和操作简介

ACC(Attribute Component Capability, 特质、组件、能力）的指导原则：

• 避免散漫的文字，推荐使用简明的列表
• 不必推销
• 简洁
• 渐进式的描述
• 指导计划者的思路， 帮助计划者思考产品功能及测试需求
• 最终结果应该是测试用例， 可以清楚地指导测试用例的编写

最终达成的目标：

• 描述产品目标的形容词和副词
• 确定产品各部分、各特性的名词
• 描述产品实际做的什么的动词

最终通过测试完成验证这些能力能正常运行、产品各组件能满足应用的目标。

下面详细介绍ACC具体内容：

1. 特质
   1. 先确定该产品对用户、对业务的意义：为什么开发？核心价值？靠什么吸引用户？
   2. 测试人员通过阅读产品需求文档、团队愿景和使命使命，来确定系统特质的列表
   3. 将测试用例关联到产品的特质
2. 组件
   1. 组件是构成待建系统的模块；对于大型系统，他们是架构图众大框架；对于小型项目， 他们是代码里的类和对象
3. 能力
   1. 能力代表系统在用户指令下完成的动作， 他们是对输入的响应、对查询的应答、以及代表用户完成的活动
   2. 能力最重要的特点是可测试性

风险

1. 风险分析

风险分析众可供参考的因素：

• 哪些事情需要担心？
• 事件发生的可能性有多大？
• 对公司、对客户产生多大影响？
• 产品具备什么缓解措施？
• 缓解措施有多大可能失败？处理失败的成本有哪些？
• 恢复过程有多困难？
• 事件是一次性，还是会再次发生？

确定风险的两个要素：

• 失败频率，分为4个预定义值：
  • 罕见：可能性很小，恢复也很容易
  • 少见：少数情况下发生故障
  • 偶尔：故障容易想象、场景有些复杂，而该能力是比较常见的
  • 常见：此能力所属的特性使用量打、复杂度高、问题频发
• 影响：
  • 最小：用户不会注意到的问题
  • 一些：可能打扰用户问题， 即使发生，重试或恢复机制即可解决
  • 较大：故障导致使用受阻
  • 最大：故障会永久性的损害产品的声誉，并导致用户不再使用它

不同的人员对产品关注点不同：

• 开发人员：自己负责的特性选择最大的风险，因为他们希望代码得到充分的测试
• 项目经理：喜欢那些是的软件从竞争产品众脱颖而出引人注目的特性
• 销售人员：吸引用户， 有卖点、演示拉风的特性
• 总监或者VIP:区别于主要竞争对手产品的特性

      2. 风险缓解

极端环境办法是去掉风险最大的组件：交付的软件越少，风险越小， 但是有很多措施缓解风险：

• 围绕风险大的能力点编写用户故事，从中确定低风险的使用场景， 然后反馈到开发团队， 请他们有针对性的增加约束
• 编写回归测试用例， 确保问题在重现时可以被捕捉到
• 编写和运行引发故障的测试用例，来推动开发实现恢复和回滚的特性
• 插入监听代码， 更早的检测到故障
• 插入代码监听软件，发现新旧版本间的行为变化以发现回归问题

具体的缓解措施很大程度上取决于应用本身以及用户对于安全性的期望， 测试人员可以参与到实际风险缓解的过程中， 但最主要的工作是暴露风险。优先测试风险最大的能力点

      3. 其他

TE有责任理解所有的风险点， 并利用手段予以缓解， 下面是一些指南：

• 根据高风险的能力点和特质， 编写用户故事、用例或者有针对性的测试指导
• 分析高风险特质-能力对相关的bug， 保证回归测试用例存在
• 思索高风险的区域，咨询可能的回滚和恢复机制
• 引入尽可能多的相关各方
• 某个高风险组件仍处于测试不足的状态， 需要把风险分析给项目成员