软件测试52讲
茹炳晟
eBay中国研发中心,测试基础架构技术主管
立即订阅
13425 人已学习
课程目录
已完结 63 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 从“小工”到“专家”,我的软件测试修炼之道
免费
测试基础知识篇 (11讲)
01 | 你真的懂测试吗?从“用户登录”测试谈起
02 | 如何设计一个“好的”测试用例?
03 | 什么是单元测试?如何做好单元测试?
04 | 为什么要做自动化测试?什么样的项目适合做自动化测试?
05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?
06 | 你真的懂测试覆盖率吗?
07 | 如何高效填写软件缺陷报告?
08 | 以终为始,如何才能做好测试计划?
09 | 软件测试工程师的核心竞争力是什么?
10 | 软件测试工程师需要掌握的非测试知识有哪些?
11 | 互联网产品的测试策略应该如何设计?
GUI自动化测试篇 (10讲)
12 | 从0到1:你的第一个GUI自动化测试
13 | 效率为王:脚本与数据的解耦 + Page Object模型
14 | 更接近业务的抽象:让自动化测试脚本更好地描述业务
15 | 过不了的坎:聊聊GUI自动化过程中的测试数据
16 | 脑洞大开:GUI测试还能这么玩(Page Code Gen + Data Gen + Headless)?
17 | 精益求精:聊聊提高GUI测试稳定性的关键技术
18 | 眼前一亮:带你玩转GUI自动化的测试报告
19 | 真实的战场:如何在大型项目中设计GUI自动化测试策略
20 | 与时俱进:浅谈移动应用测试方法与思路
21 | 移动测试神器:带你玩转Appium
API自动化测试篇 (3讲)
22 | 从0到1:API测试怎么做?常用API测试工具简介
23 | 知其然知其所以然:聊聊API自动化测试框架的前世今生
24 | 紧跟时代步伐:微服务模式下API测试要怎么做?
代码测试篇 (3讲)
25 | 不破不立:掌握代码级测试的基本理念与方法
26 | 深入浅出之静态测试方法
27 | 深入浅出之动态测试方法
性能测试篇 (7讲)
28 | 带你一起解读不同视角的软件性能与性能指标
29 | 聊聊性能测试的基本方法与应用领域
30 | 工欲善其事必先利其器:后端性能测试工具原理与行业常用工具简介
31 | 工欲善其事必先利其器:前端性能测试工具原理与行业常用工具简介
32 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(上)
33 | 无实例无真相:基于LoadRunner实现企业级服务器端性能测试的实践(下)
34 | 站在巨人的肩膀:企业级实际性能测试案例与经验分享
测试数据准备篇 (4讲)
35 | 如何准备测试数据?
36 | 浅谈测试数据的痛点
37 | 测试数据的“银弹”- 统一测试数据平台(上)
38 | 测试数据的“银弹”- 统一测试数据平台(下)
测试基础架构篇 (4讲)
39 | 从小作坊到工厂:什么是Selenium Grid?如何搭建Selenium Grid?
40 | 从小工到专家:聊聊测试执行环境的架构设计(上)
41 | 从小工到专家:聊聊测试执行环境的架构设计(下)
42 | 实战:大型全球化电商的测试基础架构设计
测试新技术篇 (5讲)
43 | 发挥人的潜能:探索式测试
44 | 测试先行:测试驱动开发(TDD)
45 | 打蛇打七寸:精准测试
46 | 安全第一:渗透测试
47 | 用机器设计测试用例:基于模型的测试
测试人员的互联网架构核心知识篇 (5讲)
48 | 优秀的测试工程师为什么要懂大型网站的架构设计?
49 | 深入浅出网站高性能架构设计
50 | 深入浅出网站高可用架构设计
51 | 深入浅出网站伸缩性架构设计
52 | 深入浅出网站可扩展性架构设计
特别放送篇 (8讲)
测试专栏特别放送 | 答疑解惑第一期
测试专栏特别放送 | 答疑解惑第二期
测试专栏特别放送 | 答疑解惑第三期
测试专栏特别放送 | 答疑解惑第四期
测试专栏特别放送 | 答疑解惑第五期
测试专栏特别放送 | 答疑解惑第六期
测试专栏特别放送 | 答疑解惑第七期
测试专栏特别放送 | 浅谈全链路压测
测一测 (1讲)
测一测 | 这些软件测试题目,你都掌握了吗?
结束语 (1讲)
结束语 | 不是结束,而是开始
软件测试52讲
登录|注册

11 | 互联网产品的测试策略应该如何设计?

茹炳晟 2018-07-23
在上一篇文章中,我跟你分享了做好互联网产品测试你要具备的非测试知识,那么现在我就来跟你聊聊应该如何设计互联网产品的测试策略。
在我开始今天的话题之前,请你先思考一下为什么我会把互联网产品的测试策略单独拿出来讨论,互联网产品的测试策略和传统软件产品的测试策略到底有哪些不同?

研发流程的不同决定了测试策略的不同

如果直接回答互联网产品和传统软件产品的测试策略有何不同,你会有些摸不着头脑,那么按照我一直在强调的知其然知其所以然的原则,你可以先去总结这两类产品的研发本身最大的不同是什么?
那就是,互联网产品的“快”。
我在专栏前面的文章中,已经提到了互联网产品的上线周期通常是以“天”甚至是以“小时”为单位,而传统软件产品的周期多以“月”,甚至以“年”为单位。
发布周期的巨大差异决定了,传统软件产品的测试策略必然不适用于互联网产品的测试,二者的测试策略必然在测试执行时间和测试执行环境上有巨大差异。
比如,对于功能自动化测试用例,执行一轮全回归测试需要 12 小时,对传统软件来说这根本不是问题,因为发布周期很长,留给测试的时间也会很充裕。
不要说全回归测试执行时间需要 12 小时,哪怕是需要几天几夜也没有任何问题,就像我以前在思科(Cisco)做传统软件测试时,一轮完整的全回归测试的 GUI 测试用例数接近 3000 个,API 测试用例数更是接近 25000 个,跑完全部用例需要将近 60 小时。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件测试52讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(40)

  • Cynthia🌸 置顶
    关于api测试,希望后续仔细讲讲如何开展。因为具体到业务的api,数据之间流转,各种关联性还是比较强的。有些还牵扯到加密,解密等等。
    但是对于单独一个api的开发而言,他可能根本不关心数据的流转,只知道按照需求实现代码,这样就给测试带来很多问题,和开发沟通时很难一下子找到自己想要的内容。
    希望能聊聊您的经验。

    另外就是对于互联网测试的策略总结的很好,现在看到不少书还是沿用传统的思路去说测试策略,感觉又笨重又无法迅速拿来进行实践。
    这部分以后会深入聊么,还是点到为止了?

    作者回复: 你说的很多,单个api测试容易,但是很多api之间交互和依赖,再加上现在的微服务化,都对api测试提出了很高的挑战,后续文章会专门来讲这块,尤其会去谈基于消费者契约的api测试。关于互联网测试策略,后续我们会讲的测试数据服务和测试基础架构设计都是为了适应互联网产品测试的实践,希望可以对你有帮助。非常感谢高质量的留言👍

    2018-07-23
    19
  • 置顶
    非常赞同作者对于互联网产品较于传统产品测试策略比重变化的观点。我们项目属于互联网产品,采用微服务的架构而且前后端完全分离。当时在项目初期自动化框架选型的时候,鉴于项目迭代速度快、人员短缺且大部分缺少比较好的代码能力的情况,我决定采用了postman+newman+jenkins的方式,在api层面实现了从数据初始化到覆盖系统7大流程的集成、系统回归测试。中间有尝试使用python进行脚本化的转变,但是效率却没有得到提升。原因可能是我们脚本可能不够灵活吧,但还有一个原因是我们通常使用postman进行接口的调试,调试完成后可以进行简单的参数化就把这些调整过的接口或者新增的接口纳入到回归测试脚本中,不用再进行额外的开发。而且postman流程化的脚本,可以在任意步骤打“断点”,对于我们人工进行流程调试验证以及造数据都有很大的方便性,至少这个这个项目一年多了,在主流程上通过api流程化脚本的覆盖下,还没有发生过大的问题。但是之前跟一个测试经理沟通时,他说我们的方式根本不属于自动化的范畴。但我个人还是比较坚持,毕竟自动化是为了提高效率并且需要注重投入和产出的,只要效果是好的,形式不是很重要不是吗?不知道作者能不能谈下您的观点?

    作者回复: 我是完全支持你的观点的,这个一定是属于自动化测试的范畴,postman+newman是很好的轻量级api测试实践,在结合jenkins可以说能够满足绝大多数的CI/CD的要求。👍

    2018-07-30
    7
  • siru
    老师有没有一些比较正规的测试文档模板分享呢?
    2018-07-23
    8
  • Geek_84a77e
    1、测试执行集群,不理解这个概念,是把我们写好的自动化代码放到服务器上执行,多个服务器组成的集群?希望老师能具体说明,包括如何实现主从
    2、本篇主要想讲互联网产品适合api test 那可否针对一个接口教我们如何设计全面的测试用例?就像之前一篇文章针对登陆设计用例一样。如果后期会有专题讨论,那在这篇文章提及一下也无妨
    2018-07-23
    4
  • Brandon
    api中的如果业务代码使用异步处理,那么测试用例会很尴尬 同步返回的数据基本没用 除了轮询还有其他方法吗?
    2018-07-23
    3
  • sylan215
    嗯嗯,其实之前,我一直把金字塔模型作为目标,但是回头看看实际情况,我们确实是一直还在 GUI 自动化上挣扎。

    看到茹老师的菱形测试策略,感觉如获至宝。

    一方面,GUI 自动化可以下沉,往接口测试靠拢,UI 操作的底层实际也是接口的调用关系,所以是可行的;

    另一方面,单元测试可以加大颗粒度,这样也变成了接口测试,单元测试的颗粒度要求真的太细,对于快速迭代的互联网产品来说,需要有一套完备的机制来保证,而这个在目前的国内环境是办不到的,如果加大颗粒度到接口测试,应该也是可行的;

    但是,目前很多公司的现状是,开发代码的分层并不明显,导致接口测试需要大量的 mock 测试代码,同时也增加了实现的难度,这是我们目前面临的比较大的问题。

    以上,欢迎关注公众号「sylan215」一起沟通交流。
    2019-02-13
    2
  • 辰九
    感觉老师偏向于api测试、但是面向用户最终还是gui层、后端api没问题不代表gui层没有问题,gui层的测试除了覆盖功能逻辑以外、交互逻辑也很容易出问题、这块也需要重点注意
    2019-06-09
    1
  • Laura张远园
    工业机器人、敏捷团队,属于敏捷下的传统测试。
    我们测试人员的KPI指标是测试自动化率,所以gui测试也基本全部自动化,一旦用户界面变动测试人员就要加班改测试代码。
    我们测试人员写单元测试的目的是用单元测试覆盖测试需求,减轻gui覆盖测试需求的代码量和维护成本,而在前面的文章中已经说明单元测试应当覆盖代码保证代码质量、而不是覆盖测试需求。
    在之前公司做通信应用层测试时,在信令交互中,会为了测试某一个模块功能,模拟其它模块向该模块发布消息,以便检测该模块的回复消息,是不是属于api测试?
    52讲12篇拜读下来,感叹于老师测试知识的广博。想请教老师:一个测试人员应当如何进行积累以达到测试知识的体系化与深度?似乎找不到测试体系化的教科书,我们可以有哪些途径进行积累。
    向老师请教,谢谢老师

    作者回复: 感谢你的大力支持,其实很多知识都是来自于项目的实践,并没有大而全的教科书可以告诉我们所有的东西,其实这也体现出了测试工程师必须要具有的我快熟学习能力。另外你说的信令测试,这个严格来讲不属于api测试,而是属于集成测试的范畴。

    2018-09-01
    1
  • 小小光芒
    自动化测试用例最重要的作用就是回归测试。开发人员开发新功能导致break旧功能,如果没有自动化回归,很难发现问题。实际上手动回归成本大,全回归很少做。这个问题有什么成功的实践方案解决呢
    2018-08-04
    1
  • 乐少
    目前公司的api业务都是异步处理的,想听听老师又那些方案分享一下的

    作者回复: 异步的api测试是比较麻烦的,我会在后面讲api的时候详细来谈。

    2018-07-25
    1
  • Gz
    实话 我觉得 最有效率的 测试办法 就是让开发保证 解耦性 这样 互相干扰的东西就少了 每次 回归测试的内容就会十分固定 不论是 客户端还是 后端都能很好的保证质量🤦‍♀️
    2019-10-18
  • shuwei
    我是一个开发人员,看了老师的这11讲,每篇都有得到东西,也在思考自己公司测试人员的定位,谢谢分享~
    2019-09-11
  • 你吱道的太多了biu~
    老师,手游测试中手工测试真的也要轻量吗,感觉游戏是非常复杂和重交互的,目前还是无法逃脱手工逻辑验证,游戏测试虽然是软件测试的一种,但是实际测试工作还是有不少区别的,关于游戏测试的资料也不怎么多,看到一些软件测试的经验和观点难免有些迷茫,我们公司前端和接口自动化用于回归保证稳定,新的版本或系统出来还是要人工分析需求和执行用例(就是点点点)多一些
    2019-08-30
  • LOVE园
    感觉还是难度很高,在现阶段互联网发展公司都是怼业务线,压根不管测试策略如何是好
    2019-07-24
  • shane
    我上一家公司相对做的比较好,新功能,新产品都是微服务架构,也是重点在api自动化,接口百分百覆盖,单元测试也都有做,gui自动化只有冒烟程度
    2019-07-05
  • Ana
    我们公司一个月一版本 应该属于传统软件产品。公司对软件产品质量要求不高,基本没有接口测试的要求,可能是开发自测。测试就做系统手工功能测试,对系统架构和接口定义等都不了解。后来学会用charles抓包,有了解一些接口,觉得很有趣。觉得纯粹黑盒测试好傻,觉得要了解系统设计才能发现更多问题
    2019-06-23
  • 泡芙小妞
    我们公司是典型的互联网行业,但是我们目前只做了GUI测试,并且GUI测试都是偏手工的,自动化很少或者几乎没有,测试组只有3个人,要面对4个端,每次都是GUI测试完成,版本就上线了,API测试根本没有做,单元测试是由开发来做的
    2019-05-24
  • Geek__c1668bdf82c6
    我们项目就是属于开发周期短,版本迭代快的那种,目前我们一周一发版,以前对各功能做了全面的ui自动化测试,后来产品对页面做了重构,ui就全部更换,自动化就停止了,现在主要放在了api自动化测试上,相对稳定,不需要经常改

    作者回复: 这是目前很多企业的思路,但是还是建议做清凉级的gui测试

    2019-04-15
  • 口水窝
    现在处于手工测试比较多,API测试只有几个版本去做了,但是我现在想的是如何把API测试和集成思维集合在一起,这样才有意义。
    GUI测试,后面又空余时间做比较稳定的模块,每一种技术,深入,连点带面,这样称为一个体系,才会有价值!
    2019-03-21
  • yudi5158
    除了自动化测试金字塔模型,我这边还参考了质量模型以及结合开发流程。 之前也有写过一篇分享文章: https://www.jianshu.com/p/40ecad5f942e 敏捷团队中的测试策略
    2019-03-11
收起评论
40
返回
顶部