引言¶
- 早期定义(
1973, Bill Hetz)：软件测试是对程序能够按预期运行建立起的一种信心。 - 经典定义(
1979, Myers)：测试是为发现错误而执行程序的过程。 - IEEE定义：使用人工或自动手段来运行或测量软件系统的的过程，以检验软件系统是否满足规定的要求，并找出与预期结果之间的差异。
说白了就是找Bug，但请不要称之为捉虫...
宗旨：在有限的时间和资源内，尽可能的发现问题，发现至今未发现的问题，尽早的暴露出来，并且协助开发尽快解决。
发现问题，分析问题（分析出问题也就解决了一大半），解决问题
测试原则¶
- 测试依赖于测试场景
- 测试对象不止是程序，还有各种文档等
- 测试显示缺陷的存在，但经过软件测试不能证明系统不存在缺陷
- 穷尽测试是不可能的，应设定及时终止的条件
- 统计表明，大多数的Bug来自于对需求的错误理解，所以测试要尽早介入，尽可能降低修复成本
- Bug的分布遵循二八法则，即Bug往往会集中在某一模块
- 测试的杀虫剂悖论，同一功能不能总是用同一条Case反复验证
测试规范¶
包含但不限于以下内容
- 编写测试用例
- 测试用例评审
- Bug管理
- 测试结果/报告
测试策略¶
- 传统软件：慢，通常采用金字塔模型，重点在GUI测试
- 互联网软件：快，通常采用菱形模型，重点在API测试
保证测试质量和测试覆盖率的前提下，有效缩短测试执行时间
测试计划¶
通常由测试管理者制定
任务分配、时间安排
测试方案¶
通常由测试负责人制定
测试方案一般是对测试计划的进一步细化和明确，是技术层面的文档。
它描述需要测试的特性、测试的方法、测试环境的规划、测试工具的设计及选择、测试用例的设计方法、测试代码的设计方案等。
- 测试目标
- 测试原则
- 被测试项：功能、非功能
- 测试方法/策略：UI测试、接口测试、兼容性测试、安全测试、性能测试
- 测试环境：工具、框架
测试分类¶
静态测试¶
动态测试¶
- 白盒测试，又称结构测试，或逻辑驱动测试，常用于单元测试
- 黑盒测试，又称功能测试，或数据驱动测试
- 灰盒测试，常用于集成测试
按阶段划分
- 单元测试 Unit Test
- 集成测试 Integration Tests
- 冒烟测试 最初是从电路板测试得来的。因为当电路板做好以后，首先会加电测试，如果板子没有冒烟再进行其它测试，否则就必须重新来过。
- 系统测试
- 回归测试
- 验收测试
- 探索性测试
- 随机测试
其中系统测试可以包括
- API测试
- GUI测试
- 兼容性测试
- 本地化测试
- 性能测试 Performance Test
- 安全测试
验收测试通常可以分为
- α版本测试，通常供开发方测试
- β版本测试，通常供测试方测试
- Release版本测试，通常供第三方测试
兼容性测试¶
- 不同系统：Mac、Windows、Android（热门品牌）、iOS
- 不同机型：不同分辨率、不同系统版本
- 不同浏览器：Chrome、Safari、Edge
- 不同版本：向上/向下兼容
- 不同网络环境
- 不同语言
- 不同主题：夜间/日间、背景等
- 分享功能：分享到主流APP
- 其它：标准规范等
关于向上向下兼容
- 向上兼容，渐进增强：业务优先，新版本老功能不会受影响
- 向下兼容，优雅降级：新特性优先，新版本老功能可能失效
比如做网站，向上兼容，则会更关注内容本身。向下兼容，则会优先考虑那些最高级、最完善的浏览器来设计网站。
兼容性测试比较枯燥，最好采用自动化方式来做，比如移动端
- Appium + Selenium Grid + OpenSTF
- 云测平台：Testin、SauceLab
软件测试模型¶
- V模型
- W模型
- X模型
- H模型
测试左移¶
- 单元测试
- 研发自测
- 代码评审（Code Review）
- 代码审计
- 自动化冒烟测试
测试右移¶
线上监控
- 线上问题闭环：验证问题-反馈结果-状态更新等
- 更便捷丰富的日志查看，方便定位问题
- 关键指标每日监控
- 生产数据监控
- 业务监控：比如短信邮件等收发
精准化测试¶
- 根绝代码变更自动分析影响范围
- 代码调用链与黑盒测试用例关联
- 代码流程分析与覆盖率统计
- 黑盒测试过程中借助代码流程覆盖数据指导探索式测试
- 利用线上数据推导有效测试用例
测试开发¶
测试开发并不是开发，本质上依然是测试，需要深入理解被测业务，根据场景和目的开发对应的工具或者框架，以提高测试效率和质量。
最不想要懂一点技术又懂一点业务的人，这种人要的薪资很高，但其实啥都不会。
要么技术特别厉害，懂底层的技术。要么业务特别熟练，但这种人往往换一个业务就不行了。
不是说只有开发了什么什么工具和平台才是技术，技术是你解决问题的能力。
- 测试架构师
开发是所有问题都能解决，遇到问题就去解决，just do it
架构是所有问题都可以分解，遇到问题先分解，所有的问题并不是只有0和1两个状态或者结果，从0到1是一个过程，可以被分解成若干份。
那些高大上的技术工具框架对我们的业务其实没有什么帮助，我们应该思考底层的能力，逻辑，思考清楚业务，能力。能做什么？能解决什么问题，重复使用？浪费时间？
从业务层面想：分享，qq微信微博等有何不同？分享即成功，做过很多业务经验，但是换个业务完全是零，所以要思考底层的差异
从技术层面想：比如兼容性：不用挨个测，不同浏览器内核，不同系统等，比如安卓新系统兼容性测什么？就是安卓8和安卓7有何不同
职业发展¶
开发领域已经有那么多优秀的前辈，我觉得不少我一个，而测试领域非常专业的人才还很少，我觉得我能有机会，而且测试发展空间其实也挺大的，自动化测试，性能测试，安全测试等。而且从产品角度思考问题，加上增长黑客的意识，职业道路还是挺宽泛的，相信努力以后会做到话语权更高的职位。
个人价值，公司价值，用户价值，个人和企业价值同步，通过量化而进化。
测试经理应该是被消灭的，大家应该都做到，扁平化，赋能的作用。比如一个家庭老公和老婆，过日子需要一个人来管么？自治。比如大学，虽然有老师，但不能指望老师教了，要有自己的价值。 90后不好管理？最好管理，要么给钱要么他喜欢。而80后还要画饼。
测试工程师的自我修养？¶
测试必须先了解业务架构
我们常常会说一个测试的研发能力怎样怎样，但往往忽略了一个开发的测试能力，是的，很多测试的研发能力不足，但同时，很多研发的测试能力也非常差。
对于高阶测试开发，有些bug不是测出来的，而是分析出来的
会那么多工具，为什么用，好在哪里，要学会思考，掌握底层原理，而不是所有经验都单纯的来自工作
单元测试、埋点测试、code review 等其实都不应该归属于测试职责范围
测试左移最主要就是持续集成
基础能力¶
- 良好的沟通和表达能力
这是一切的基石与前提。
- 快速学习与理解能力
作为测试要深入理解业务需求，明确测试重点，但业务知识不等同于测试能力，面对业务的变化以及其它的业务，要能快速学习，理解本质，融会贯通才是关键。
- 自我管理能力
互联网公司目前都越来越扁平化，管理也会越来越扁平化，每个人都应该学会自我管理。比如了解被测目标，及其涉及的人员和资源，合理制定测试计划，安排测试进度，评估测试风险。
- 探索创新能力
专业能力¶
- 用例设计能力
- 缺陷分析与定位能力
- 测试开发能力
自动化测试¶
自动化本身并不难，难的是产生价值。
- 自动化测试只是一种测试手段，仅能替代重复的手工操作，并不能替代手工测试。
- 自动化的本质是发现变化的东西对不变的东西的影响，即主要用于回归测试，验证新功能是否影响了旧功能。
- 自动化一定是基于业务的，必须要考虑可重用性和维护成本，不要为了自动化而自动化，从而违背测试的宗旨。
自动化不是银弹，而且有很多成本：开发成本，维护成本，与手工测试重复测试造成的无用功损耗。
开发告诉你改了哪里，只测相关的改动，但是线上却出现了问题，出在那些没有改动的地方，所以经验性的减少测试case是没有依据的，但是又有时间的限制，我们不能cover所有，所以需要自动化。
自动化依据的是测试用例，测试用例遗漏或者出了问题，自动话也一定是有问题的，所以自动化不能解决所有问题。也不能与手工无缝衔接
自动化主要搞定环境和数据（为满足不同场景需要参照数据，即动态数据）
自己做的云测其实根本用不起来，不现实，除非testin这种云基础，公有云不行，私有云，随插随跑（想到百度之前的架子）
自动化有没有用？有必要做，但为啥做着做着就失败了呢，有成本，有特定环境，试用范围。
更多的只是团队能力的积累和提升。很多测试人员偷偷学自动化然后跳槽，团队可以一起公开搞，提高团队能力。
自动化维护成本很高，而前端是最容易变得东西
质量保证是上层的东西，质量控制是底层的
关于线下测试大会¶
几乎所有的主题其实本质上都是在讲：如何保证质量的同时提高测试效率，毫无疑问，就是自动化，自动化不是使用各种工具替代手工测试那么简单，它更多的是一种思想。
了解了行业内在做什么，水平是什么，我们和他们差距有多少。
讲师把这些东西讲出来更多的只是对他们自己有价值，而听众只是一时兴奋，过几天就忘光了。确实如此，不过大咖们分享的思考问题和解决问题的方式还是挺有价值的，值得学习一下。
测试平台¶
真正以技术为主的团队，通常不会用那些奇淫巧计，测试平台在测试开发中优先级可以放低，底层框架搭建好利用闲余时间可以搭建平台，提升下易用性
大可不必为了搭建平台而搭建，利用Django等框架快速搭建，没必要深入Vue等前端的技术栈，更不要做为发展方向，那并不是作为测试的重心