不测的秘密：精准测试之路----读书笔记（第一章）

一、举步维艰

1、敏捷转型：测试眼中的研发

传统：

• 需求是清晰的
• 流程是固化的
• 开发是有序的
• 系统是可测的
• 测试时间是充足的
• 用户是讲道理的

敏捷：

• 需求频繁更改
• 交付问题多
• 测试时间紧
• 用户抱怨多
• 开发延迟，压缩测试时间，已成常态

那么问题来了：

• 还能随心所欲设计大量用例吗？
• 还有大段的系统测试时间和集成测试时间吗？
• 还能要求充足的回归测试吗？
• 还能期望研发提供各种测试建议吗？
• 还能不能愉快的进行了。。。

2、回归的痛苦

两个场景：

场景一：

开发：刚修复了一个紧急用户反馈，安排下测试吧。
测试：改了哪些？影响了哪些功能？
开发：改了好些地方，为了保险，把所有功能都测一遍吧。

场景二：

开发：昨天的修改测试完成了吗？
测试：测试中，要跑500个用例呢？
开发：我只修改了一行代码，怎么要测这么多呢？

 两种意见：

1）缩减回归测试的范围--没有好的方案

2）依靠自动化测试

3、自动化测试的价值

传统：

传统ROI（成本与收益）公式：自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本
很大的前提：测试做的越多越好
这个理解对全新的项目是正确的，对后续的迭代和增量版本合理吗？回归测试中，因为“不放心”进行测试，冗余比例很高，因此公式中的收益很大一部分来自于这里。

自动化测试定义：

传统：

通常指测试过程被自动化，即把手工测试的用例让机器去做

广义包括：

• 测试环境的搭建和管理
• 测试环境的检查、监控和报警
• 测试代码的静态检查、编译和构建
• 测试场景的构造，测试数据的自动化准备
• 测试用例的分发和执行
• 测试结果的保存和管理
• 测试报告的生成
• 测试优先级的建议

自动化测试类型：

• 单元测试
• 代码静态检查，文件检查，签名校验，证书检查
• 接口自动化测试（本地native接口测试和服务service接口测试）
• UI自动化测试
• 性能测试（本地和服务）

可能的价值：

• 帮助回归，节省人力
• 构建人工测试无法构建的场景、数据准备，或执行一些人工测试做不到的测试用例，有效提升测试覆盖率
• 前置测试，让测试和开发可能并行，提升项目敏捷度，降低测试独占周期（提测到待发布的时长）

测试员路在何方：重要的不是我做了多少年，而是我的工作是否可被轻易取代

核心竞争在哪里？

• 精通业务：最精通的不是产品，市场研究员吗？
• 比其他岗位更懂业务技术：不应该建立在其他岗位的不足上
• 思想上：很多开发技术强的测试都转开发了

不测的秘密：精准测试之路----读书笔记（第一章）

原文：https://www.cnblogs.com/testing2019/p/10244745.html