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

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

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

时间: 2024-10-10 00:53:33

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

《探索式软件测试》读书笔记(上)

<探索式软件测试>读书笔记(上) 2015-05-12 一.局部探索式测试 1.如何测试用户输入  1)合法输入和非法输入    输入筛选器   输入检查   异常处理代码  2)常规输入还是非常规输入  3)默认输入或用户提供的输入  4)使用输出来指导输入选择 2.如何测试软件状态 3.代码路径 4.用户数据 5.运行环境二.全局探索性测试 分类 方法 商业区 指南测试法 卖点测试法  地标测试法  极限测试法  快递测试法  深夜测试法  遍历测试法  历史区 恶邻测试法  博物馆测试法

《精益和敏捷开发》读书笔记

对精益不了解, 敏捷开发则是一个到处都在谈论的话题, 我只是跳着看了一些在敏捷方面的做法和观点, 而且主要是scrum相关的, 当然本书的敏捷开发基本上可以等同于scrum. 算是增加了一层对scrum新的认识. 书不敢说是一本好书, 只能各取所需吧. ======================我是读书笔记的分割线================== 如果在同一个办公区域, 你记不清所有人的名字, 那么这就是一个大型团队了 产生非最佳决策的原因是错误的假设和不充分的理由 守破离法则 第一步,

《算法导论》读书笔记(五)

摘要: 本章介绍了二叉查找树的概念及操作.主要内容包括二叉查找树的性质,如何在二叉查找树中查找最大值.最小值和给定的值,如何找出某一个元素的前驱和后继,如何在二叉查找树中进行插入和删除操作.在二叉查找树上执行这些基本操作的时间与树的高度成正比,一棵随机构造的二叉查找树的期望高度为O(lgn),从而基本动态集合的操作平均时间为θ(lgn). 1.二叉查找树 二叉查找树是按照二叉树结构来组织的,因此可以用二叉链表结构表示.二叉查找树中的关键字的存储方式满足的特征是:设x为二叉查找树中的一个结点.如果

《敏捷软件开发读书笔记之一》

要想成为一名优秀的软件开发者,需要熟练应用编程语言和开发工具,更重要的是能够领悟代美代码背后的原则和前人总结的经验——这正是本书的主题.本书凝聚了世界级软件开发大师RobertCMartin数十年软件开发和培训经验,不仅是一部深入浅出.生动易懂的面向对象原则与模式著作,而且还是一部通俗的敏捷方法导引书和快速实用UML教程.分为敏捷开发,敏捷设计,薪水支付案例研究,打包薪水支付系统,气象站案例研究和ETS案例研究六个部分,包含30个章节.以下是我对前两个部分的认识及见解: 以下六章是对第一部分敏捷

《敏捷软件开发读书笔记之三》

以下是我从最后两个部分:气象站案例研究和ETS案例研究中得到的一些收获,以及个人的一些认知及见解: “OBSERVER模式”又称为回归为模式,其最大的推动力来自开放封闭原则.使用这个模式的动机就是为了在增加新的观察对象时可以无需更改被观察的对象.这样,被观察对象就可以保持封闭.Observer是一个抽象类,具体的DigitalClock依赖于它,Subject的具体方法也依赖于它.因此,依赖倒置原则也运用于其中,Subject 不具有抽象方法,故它与Clock间的依赖关系可能违反了DIP.但是,

悟道—位IT高管20年的职场心经(读书笔记五)

悟道--一位IT高管20年的职场心经 第五章 搞定老板 "老板就是老板" 这一点,你可能会忘了,他一定不会忘: "老板不会总是老板" 这一点,他可能会忘,你最好别忘. 1.1  谁是老板 老板手上有的权力,你应该尊重.权力,意味着资源. 1.2  三招搞定老板 尊重老板由于他毕竟是你的老板: 把老板当客户,善用老板的资源! 老板的资源:权力.能力.经验.信息. 1.3  请示的学问:该不该请示 和自己的老板沟通,理解老板的性格特点,然后做事. 1.4  请示的学问:

Android驱动开发读书笔记五

第五章 本章介绍了S3C6410开发板的功能,开发板的不同主要是在烧录嵌入式系统的方式不同,以及如何在此开发板上安装Android. 1.安装串口调试工具minicom 首先需要一根USB转串口线,由于安装的是Ubuntu Linux所以需要按照以下步骤.配置和测试minicom (1).检测当前系统是否支持USB转串口 命令lsmod  | grep usbserial (2)安装minnicom apt-get install minicom (3)配置minicom minicom -s,

《启示录》读书笔记五

1.敏捷开发 敏捷开发以用户的需求进化为核心,采用迭代.循序渐进的方法进行软件开发.在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视.可集成和可运行使用的特征.换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态. 2.瀑布式开发 瀑布模型式是最典型的预见性的方法,严格遵循预先计划的需求.分析.设计.编码.测试的步骤顺序进行.步骤成果作为衡量进度的方法,例如需求规格,设计文档,测试计划和代码审阅等等

敏捷软件开发读书笔记(三)

敏捷设计 如果敏捷性(Agility)是指以微小增量的方式构建软件,那么究竟如何去设计软件呢?又如何去确保软件具有灵活性.可维护性以及可重用性的良好结构呢? 在敏捷团队中,全局视图和软件一起演化.在每次迭代中,团队改进系统设计,使设计尽可能的适合当前系统.团队不会花费许多时间去预测未来的需求和需要,也不会试图在今天就构建一些基础结构去支撑那些他们认为明天才会需要的特性.他们更愿意关注当前的系统结构,并使它尽可能的好. 那么怎么才能保证全局视图和软件一起演化呢?在软件出现下面任何一种气味时,就表明

敏捷软件开发读书笔记(一)

第一部分 敏捷开发 2001年初,由于看到许多公司的软件团队陷入了不断增长的过程的泥潭,一批业界专家聚集在一起概括出了一些可以软件开发团队具有快速工作.响应变化能力的价值观(value)原则.他们称自己为敏捷(Agile)联盟.在随后的几个月中,他们创建出了一份价值观声明.也就是敏捷联盟宣言(The Manifesto of the Agile Alliance). 敏捷联盟宣言如下: 1.个体和交互胜过过程和工具. 人是获得成功的最为重要的因素.如果团队中没有优秀的成员,那么就是使用好的过程也