随笔分类 -  回顾功能测试

基于敏捷的角度重新考虑测试的位置
题外话: 从数据驱动测试的工具聊GUI背后
摘要：FitNesse就是典型的数据驱动测试工具 通过建立一个决策表描述业务对应的处理场景. 然后讲决策表的数据传入功能模块, 得到执行结果并与期望结果比对. 完成测试 所以这里的数据驱动测试就是一种API级别的功能测试 DDT测试显然需要工具支持表格形式的数据写入. 也即: 除了现成的框架外, 还可以自 阅读全文
posted @ 2018-06-28 15:33 然语 阅读(125) 评论(0) 推荐(0)
敏捷: 第二象限 ---- 为什么总有测试数据存放的讨论
摘要：功能测试, 属于第二象限的测试. 对于UI自动化 本质上也只是替代了部分功能测试. 执行的仍是功能场景 因此总能看到关于数据存放在表格还是文档, 如何读取等问题. 我不想比较每种方式的优劣性. 只就根源讨论. 测试强调的是和其他岗位人员的交流. 交流的背景就是基于一种共同语言 如AT一书所说, 图片 阅读全文
posted @ 2018-06-28 11:32 然语 阅读(180) 评论(0) 推荐(1)
题外话: 如何让开发接受有自动化测试参与的研发过程
摘要：对于遗留系统做UI自动化常常是困难的. 那么对于新业务进行UI自动化可行吗? 可行的. 如何说服开发人员接受编写可测试的代码呢? 那么想想为什么他们接受了编译器吧 如果测试编写完成了测试代码, 且在开发实现业务逻辑时, 能用已有的测试代码来验证自己的业务逻辑, 那么对于开发, 也没有更好的理由拒绝这 阅读全文
posted @ 2018-06-27 17:58 然语 阅读(102) 评论(0) 推荐(0)
敏捷: 谈谈UI自动化对于研发过程的应用
摘要：对于测试而言,常见的UI自动化场景是为了减少手工回归测试的范围和缩减成本开支. 对于敏捷过程, UI自动化是为了补全单元测试的不足而产生的. 简单而言: 在开发初期, 需要进行冒烟测试. 因此需要图形化的,用户界面的测试. 且对于单元测试而言, 覆盖更多的业务方面的测试是心有余力不足的. 尤其是对于 阅读全文
posted @ 2018-06-27 17:35 然语 阅读(177) 评论(0) 推荐(0)
思考: 第一象限 ---- 数据驱动测试
摘要：数据, 对于开发而言, 是关注的同时又经常忽略的资料. 就经历而言, 多数的数据需要自己执行后产生, 容易增加开发人员的惰性. 导致数据覆盖的边界不合理. 同时, 数据还是开发在设计API时必须的资料. 在新系统的开发中, 由于没有参考的数据, 因此在设计接口时, 从实现功能的角度出发, 不会更多关 阅读全文
posted @ 2018-06-26 14:44 然语 阅读(111) 评论(0) 推荐(0)
题外话: 再聊第一象限----用bug数量进行考核
摘要：总能听说有些公司用BUG数量作为测试的考核指标 如果你也身在这样的公司 那么恭喜: 你们的项目就是一个忽略第一象限的项目 为了减少工作量: 你们需要通过BUG数量, 对开发进行KPI考核 为了升职加薪: 你们需要招更多的开发和产品来扩大项目规模, 并缩短迭代周期 一个完成开发的系统,是不应该存在过多 阅读全文
posted @ 2018-06-26 14:16 然语 阅读(387) 评论(0) 推荐(0)
敏捷: 第一象限的认知
摘要：何为第一象限: Agile Testing中描述大致意为: 面向团队的自动化测试 为何要作为第一象限: 是程序员必须要完成的工作, 属于开发内容.优于业务实现代码.原因如下: 1. 编码之前需要先进行设计, 之后才是业务代码 2. 设计完成后需要进行验收, 之后才能说完成了设计 好处有这些: 1. 阅读全文
posted @ 2018-06-26 14:03 然语 阅读(175) 评论(0) 推荐(0)
敏捷:技术债务和用户故事的互斥和统一
摘要：敏捷开发过程中 技术债务的产生: 1.时间因素: 加快甚至跳过开发阶段 2.技术因素: 绕过解决不了的技术问题 3.业务因素: 缺少业务的核心解释 4.个人因素: 没有良好的开发习惯 用户故事的产生: 1.少量的需求: 针对特定用户出发,为了解决系统之外问题而对系统产生影响 2.合理的需求: 技术债 阅读全文
posted @ 2018-06-26 13:49 然语 阅读(203) 评论(0) 推荐(0)
序
摘要：时隔两年,重新梳理一下测试相关的知识.希望从新的角度,能发现一些不一样的细节. 阅读全文
posted @ 2018-06-26 13:23 然语