码迷,mamicode.com
首页 > 其他好文 > 详细

《敏捷软件测试》的读书笔记(五)

时间:2015-07-26 12:33:09      阅读:92      评论:0      收藏:0      [点我收藏+]

标签:

第五部分 测试人员经历的一个迭代

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

制定计划:短期计划更好。(优先级变化 、环境的不稳定,长期计划很难实现。)

项目卡处:需要做、开发中、待验证、已完成。

评估story:工作量(小中大)。集体评估,再调整。

story测试评估

 

 享受敏捷,让会议有趣。(站会发言定时打断。)

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

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

 测试计划:

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

2. 使用测试矩阵:

条件1 条件2

功能1

功能2

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

3. 测试表格、白板

4. 自动化的测试列表。

 

传达测试结果:

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

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

缺陷度量:

 

16. 迭代前的准备

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

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

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

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

 

17. 迭代开始

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

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

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

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

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

2. 可测试story:

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

2. 如系统时间:通过增加运行时服务器属性。(job:修改运行时间。)

3. 高层次测试和示例

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

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

4. 测试用例审查

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

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

 

18. 编码和测试

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. 发布标准:性能指标、测试覆盖率、没有重大缺陷、让客户明确新功能,比如现场演示。

《敏捷软件测试》的读书笔记(五)

标签:

原文地址:http://www.cnblogs.com/echolxq/p/4677297.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!