PART5 测试人员经历的一个迭代

一、测试人员在发布或主题计划阶段的工作

 1. 制定计划：短期计划更好。（优先级变化 、环境的不稳定，长期计划很难实现。）

 2. story卡处：需要做、开发中、待验证、已完成。

 3. 评估story：工作量（小中大）。集体评估，再调整。

 4. story测试评估：

解决什么问题？客户怎么用这个功能？最坏的结果是什么？有关联系统吗？安全吗？性能有要求吗？

从未接触过的业务，会不会影响测试？第三方产品需要额外时间。

用法、使用场景、实用价值。

了解测试报告中需要的内容。（测试结果持久化工具，测试证明截图。）

 享受敏捷，让会议有趣。（站会发言定时打断。）

开发：先实现最基本的功能。Story分开。线下任务可以不做。尽早完成影响系统其它功能的story。

测试数据：去掉敏感信息，如银行卡、身份证等。

 测试计划：

1. 轻量级：测试设备需求、测试人员，投入时间。假设、风险、性能、UAT。

2. 使用测试矩阵：

条件1 条件2

功能1

功能2

可以被当作测试覆盖率。颜色区分状态。

3. 测试表格、白板

4. 自动化的测试列表。

传达测试结果：

1. 已通过测试数：如功能25个测试，共100个用例通过。

2. 测试覆盖率：包、类、方法、可运行代码行。测试覆盖数/总数。95%

缺陷度量：

二、迭代前的准备

如果迭代前的活动不能为迭代中省时间，果断放弃。

1. 迭代需求讨论会：sprint开始前。（事先明确，客户意见一致。了解story对不同角色的人员意味着什么。基于现实的用例讨论story。）

2. 迭代开始时编写用户验收测试-高层次。（对于复杂story，至少编写一个常用路径，一个非常用路径。）

3. 测试策略：考虑何时开始测试它们。

三、迭代开始

1. 迭代计划：分解story，评估工作量。（参考UAT测试用例、通过条件。）--------通过原型实例理解story。

可以不做功能去掉。站在不同角度考虑：用户、程序员、产品，文档编写人员。考虑关联到的系统功能影响，尽早暴露不确定因素。

当别人不同意时：建议先加一部分功能，试一个迭代。

 测试策略选择：大部分的子功能用"刚好够用"的数据，而数据全集用于验证全部的功能。

确定工作量：计算总的时间估值，或卡片数量。备选story。学习新工作时：新增风险时间。

2. 可测试story：

1. 整个团队参与可测试性问题

2. 如系统时间：通过增加运行时服务器属性。（job：修改运行时间。）

3. 高层次测试和示例

1. 一图胜千言。修改功能时：打印现有功能，笔标注。

2. 需求=story+交流+用户场景+导向图

4. 测试用例审查

你觉得  有什么遗漏吗？哪块最可能有风险？重点关注哪里？

测试用例作为文档保存起来：用例易于维护。测试代码导出API，类结构图。

四、编码和测试

1. 驱动开发：

从简单入手：先写基本流---->异常场景构建。再增加复杂度：探索性测试。

评估风险：条目  影响  * 发生概率  = 风险。复杂功能，列出潜在风险。

编码和测试同时进行，让所有团队成员都参与其中，放弃那些可能基本不会发生的极端情况。

分歧时，寻找第三方力量，确定不要重复讨论这一问题。

一次只完成一个story。

自我展示：大声说出自己的想法：放一只小小鸭子提醒自己：提问前多思考。

展示给客户：

2. 完成测试任务

在访问真实服务的数据完成之前，可以使用Mock或硬编码数据测试。

迭代无法完成时：放弃一个story。立即通知开发人员。协助测试。

缺陷0容忍。

3. 哪些问题需要记缺陷

a.开发确认是问题 b.开发不能立即修复 。尝试为每个story预留2小时或半天修复缺陷。（立即修补，以后修补，不修补。）

团队原则：必须在迭代内修复缺陷，让整个团队看到缺陷。

缺陷数量不能超过10。

多个缺陷考虑组合缺陷。

4. 确保快速构建

a. 不需要在回归测试中包括所有边界情况和类似情况。

5. 迭代度量

进度度量、缺陷度量。

记录测试时间：

单表的CRUD。

复杂业务逻辑。

缺陷重现时间，缺陷验证时间。记录缺陷类型。

静态分析工具：findbugs，找到sprint优先级最高问题的增长。

度量：

story测试执行数量。

自动化状态。

测试通过/失败折线图。

每个story的总结、状态。

缺陷度量。

迭代结束时的收尾工作

1. 迭代回顾会：30分钟内。演示新功能。

哪些做得好，不好，下个迭代的尝试。

”开始、停止、继续“清单。设置一个检验点，验证是否有改进。

运行单测代码覆盖率工具。迭代开始的第4天前，完成所有story的高层次的测试用例。开发在迭代第4天前交付一个story给测试。维护一份待办列表。

花时间庆祝，让团队暂停脚步，刷新视角。

2. 成功的交付

培训、文档。

定期做一个重构迭代，减少技术债务，提高测试覆盖率。总有些测试不值得自动化。

自动化回归测试，至少每天运行。

可靠性测试、容错、复原测试、安全性。

尽早使用外部第三方测试，降低风险。

用DB脚本处理数据转换，向后兼容的问题。数据库修改后，在数据库上运行diff。

设置任务提醒功能。

3. 考虑文档是给谁的，他们用它做什么，如果没有答案，则考虑是否放弃写文档。

4. 发布标准：性能指标、测试覆盖率、没有重大缺陷、让客户明确新功能，比如现场演示。