• 大体上 只要是 符合 或者你能分为三层架构的系统 前端 服务 数据 都可以分层写。
    针对不同测试层 比如 前端 我图上也列了 你的前端的测试对象 如果是重点测试业务流转组合 那实体物理对象 就是 页面 各个功能性页面 或弹窗 都可以 比如 注册页 登录页 支付页 或 登录弹窗 他们会形成业务流组合 你就把 这些物理页面对象 设计个流程组合即可。比如 今天还没有登录弹窗 后天加两个登录弹窗 只需要在 业务流测试层 加个登录弹窗的组合流程 覆盖到相关业务流组合。

    具体的操作交互层,就写到单独一层,这一层主要是放,或模拟客户前端操作行为对页面控件带来的组合,主要是测前端Js 实现的问题。 比如 注册页面 那么多输入项 和 输出项的组合操作逻辑 就用因果判断 进行组合就可以了,具体的物理对象 是各个页面控件 但不涉及具体控件的输入内容,具体的输入内容 是放在 数据层的。 这一层主要是放 操作模拟组合。 比如操作序列,什么都不填,直接提交表单,看页面js和服务接口是如何控制的。

    最后 就是 等价边界 注册页面的具体输入内容。 这一层就是放 我们测试最熟悉的 等价边界值 那些个东西。

    这样就拆开和低耦合了啊,每一层的 测试内容不同 测试对象属性不同 就决定了这一层是可以单独设计和维护的了呗。

  • 1 点 线 面 的理解还算可以吧。 就是让你分的清 当前的测试对象 当前的测试层次 当前自己在测什么 可以测出什么问题。
    测试对象的属性 决定了测试的类型 决定了可以测出的缺陷类型。 好比我举例的 由上往下 业务场景层(对象是页面)

    操作交互层(对象是页面控件 各种元素) 数据出入层(对象是 具备输入性质的各种数据 可以是页面的 可以是接口的 也可以是数据库的)

    场景层 有场景层的 业务组合问题 页面控制流转问题

    操作交互层 有控件 和元素 之间的各种前端JS脚本控制业务逻辑 交互逻辑 业务规则的限制问题
    数据出入层 有具体的问题 但要看数据是哪一层的数据 产生了什么交互 比如前端的 JS 校验 规则控制问题 这些都是纯前端的js问题。 到接口了 提交前端表单了 有接口的输入限制问题 和服务校验返回控制问题 到数据库了 有数据落地的正确啊 位数啊等等问题。

    就是让你建立起 分类 分层 有层次 有系统性理解 测试。 当前我是测业务组合 还是测前端交互 还是测接口 还是测落地数据。
    要分的清,拎得清。 不要混为一谈,要对这个数据的整个处理流转的细节梳理清楚,前端干啥了 服务接口干啥了 落地数据干啥了,分层次 分流程 分门别类的 去检查各自的 ”输出” 输出就是检查上一个节点输入正确的 “预期结果” 分层的测完一整套 每一层的输入 输出 很明确。 用例写的也会有层次感 ,好摘的开,以后也好维护。 比如 你判断准确了 就是前端Js没做输入规则业务规则控制,那么在用例的 前端输入 这一块 你只需要改这一块就行了,如果发现是,构造绕过接口了,接口的输出 落地数据产生了非法数据,那么就是接口层没对前端提交的数据做出一些校验,这个问题在用例维护里只需要改 接口输入 这一块 就够了。

    这种 业务思维 加 技术实现分层思维 不断的找类 找层次 找输入输出的思维 你要不断加强 强化 然后就会越做越顺,看问题就越会有努力的方向,问题类型缺陷类型就会越定位越准确,直接找到解决的开发角色。提高缺陷解决效率。 这个前提就是用例设计的好坏来决定的。

    2 减少组合 具体思维 你可以参考 判定表因果图法 相关的理论讲解里的 如何去掉重复的 列 的方法,有具体业务规则 可以去掉,
    具体的逻辑规则限制,可以去掉,和其他许多 技术限制 比如数据类型 大小限制 导致一些数据根本不可能产生。 就这样去掉。
    或者 你看 图例 用例设计参考文件里的 业务需求 和技术实现 里有什么 可以去重的条件拿来去掉重复。

    3 好的用例 就是 我图里 列的 “满足特性” 你写的用例 具备了这些特性 就基本上 合格了、

  • 感觉这里堕落了 at April 01, 2020

    老用户之一,当初我也挺活跃,现在主要是照顾家庭和在准备转行的事情……
    Me too了 。哈哈,一起一起。 我还鼓捣过你的github项目。

  • @Fhaohaizi 你搬家呢?
    还是 下来了 有时间创作了 😆

  • @codeskyblue 我怀疑你在“直播带货”,可是我没有证据 😆

  • https://testerhome.com/articles/16966
    @frzyq

    可看看 这个 缺陷类型 的分类 要清楚 有什么样的缺陷。 这样做缺陷统计分析 缺陷分布柱状图 就可以兑当前系统 软件 或 服务 质量做出评估。

    角度 维度不同 分类也不同 我文中有分析。

    主要是 技术实现类缺陷 业务需求类缺陷。 这是一个维度
    可以再上边两个维度上 往里塞。

    技术实现类的 可以按 三层结构 前端 服务 数据库 来分别界定各自层级结构下的缺陷。 如上 缺陷分类好了 柱状分布图 更能真实反映 软件质量。

    比如 前端 下的 子缺陷问题类型 问题多了 说明当前 前端开发人员 实现质量不高。
    服务 接口 类的问题多说明 服务接口开发人员 逻辑问题多 接口问题多 实现质量不高。
    数据类的 多了 说明 服务 问题多 质量不高。
    你可以 在三层下 细分问题类型 这样越做越细 你对 缺陷定义的越准确 说明你对 缺陷的理解越深 对当前系统技术实现的细节 理解的越深 脑子里有层次感 有系统感
    就像一个 机械表 它内部的运行机理 组成构成 都 透明的 如庖丁解牛, 十分清晰.

    哦 另一个 层面 就是 你要对 缺陷问题 赋予 重要程度 是什么程度的缺陷 阻碍 致命 重要 次要 轻微。
    比如 致命 的 数据 尤其是 落地数据类的 错误 比如 订单 钱包 里的某个字段 错了 那肯定是致命的。

    你说的那个 应该是 次要 有解决处理办法 属于 运营人员配置错误 导致的前端 用户问题。 这个应该加强 对运营后台的培训 或 逻辑限制 防止他们用错。

  • 用好jmter 的这几个概念 就可以做到 分层 分类 各层之间耦合度低

    我们内部 约定了个 用Jmter 的目录规范 主要就是 步骤 用例 和 场景

    按照此约定 该去哪层写的去哪层写 核心和基线是 step 和 case层 场景只是做调度和组装 。

    步骤step是最原子性的
    步骤层举例

    Tips:1、步骤层里面互不依赖,如果模块很多可根据模块名创建文件夹来分类保存。

    2、步骤层的测试计划命名为步骤,通过Test Fragment这样的测试片段来进行包含。(建议Test Fragment名称和整个步骤的jmx文件名称保持一致,方便查询)。

    3、步骤层根据具体业务需求来切分,可以是单独一个sampler或者多个sampler组合,而且一般会使用事物控制器包含。(如果sampler里面的变量需要传递使用vars.get方法获取,里面有变量需要提取也是同步进行)。

    4、为了接口测试严谨性,一般步骤层,会跟随sampler绑定这个接口的必填参数测试的简单控制器,方便阅读。(必填参数测试:缺失必填参数后,接口返回值是否正确)。

    用例层举例

    Tips:1、用例层里面只调用步骤层来进行组装,不添加任何sampler。

    2、用例层一般会使用Parameterized Controller插件来对步骤层进行参数传递,一般需要和步骤层绑定。如果需要再获取上级参数传递可写为变量

    3、用例是独立存在的,用事物控制器进行包含,由于JMeter本身的特性,需要在场景层中组合的话,也只能存放为Test Fragment给与调用。

    4、用例名称中,事物控制器,测试片段,jmx文件名称尽量保持一致,方便查找。

    场景层举例

    Tips:1、场景层是由线程组通过Include Controller调用Test Fragment的测试用例来直接运行的jmx文件,也是最后输出的报告展示结果。

    2、所有用例都需要使用的变量可以在场景层存放,比如用户账户数据,数据账户密码,APPID,AppSecret等,如果不需要在场景层使用可以在用例层进行传值覆盖。

    3、场景层中的用例没有依赖关系,可以顺序或者乱序组合,互不干扰。

  • 总体来说 是要对数据进行验证的。

    绝对而言 如果 软件工程质量好的话 我意思是 比如 你们的业务测试质量很高, 那么 我们所做的UI自动化 就是个 分层测试的概念
    尽量把问题 集中到UI界面上 而不去关注接口 或 数据库数据的 验证。 或者 前提面向UI自动化 初始化或构建好了 UI页面场景依赖的数据, 重度把问题集中到对UI界面的 验证上来。 这种情景 就不太需要 对接口或数据库数据验证。

    另一种 情况 就是相对的, 比如 你们的业务测试质量不高 一些接口 或 数据落地验证 不准确。 那么你可能 就需要 对 页面接口返回的数据 或 响应 做一些面向业务规则的断言 或者需要访问数据库 对如表单提交类的 做落地数据断言。 这就有点违背 UI是一种分层测试的概念 战线扯的有点长了, 但没办法 国内或大多数全球企业 都是这样。
    所以 业务测试是基石 , UI自动化 是辅助 不要为了UI自动化而自动化 前提是你业务测试质量标准到了

    你要明确 你UI自动化要解决的是 哪个端的问题 要重度面向UI适配 系统碎片化兼容 和前端问题 来精准。 否则就 会有点扯的长 做了业务测试验证的活。

  • 性能测试 面很大啊 你这个问法不具体 指代不明 个人理解有以下性能维度
    一 服务性能测试
    啥是黑盒性能,就是指 以业务处理性能为指标的 性能测试 比如 lr 或jmeter 通过接口 对整个业务服务系统 试行压力 等各类型的测试,关注的是 业务处理指标 如 每秒事务数。 可以不关注被压测服务系统的中间件 服务组件的性能,如tomcat nginx啊 等,此类测试主要是 业务性能测试人员做 市面上大多数搞性能测试的 此类居多 。
    那么 这类可以归为 面向业务处理性能的 性能测试。 关注指标 有
    1.1 业务处理性能 或者说 把这类 归为 服务性能测试工程师 或者 我把他定义为 黑盒性能测试 重度面向业务处理性能 (捎带着监控了服务中间件)
    1.2 服务组件 中间件性能 这种 如果 上一步1.1 面向黑盒的指标通过的话 就可以重度分析 组件和中间件性能指标了 用专业的运维分析工具 分析定位

    比如 目前流行的grafana 或zabbix这类 都算
    1.3 数据库DBA类的 性能调优 SQL优化 本来是可以归到 1.2的 但实际 目前处理这类优化的角色 一般都是DBA 在做

    二 前端性能测试
    2.1 传统的 前端web h5 性能调优 比如 devtools 谷歌yslow 或pagespeed 前端性能调优标准来 也可以把APP里的H5啊 这类的归此
    2.2 APP 类的 native类的APP的 性能调优 ios android前端类的

    三 一般是运维工程师做的 硬件性能测试 和 服务组件性能测试
    2.1 服务器硬件上架前的 硬件上架标准测试 主要对硬件cpu mem IO 等做硬件压测 有各类专业工具
    2.2 部署服务组件 中间件 的上架标准测试 主要对 nginx tomcat 等 做 性能压测 也有各类压测工具命令行 或 其他工具平台
    这类 基本 不关注业务处理性能指标 关注 比如 cpu mem IO 的一些硬件资源处理性能 或者 是 中间件 类的 处理性能 和业务无关的 处理性能

    四 最后 可能就是 纯白盒性能了 直接阿里多隆 级别的 直接看代码 调优性能

只知道围绕前端弄的 那是初级测试员;知道围绕前端和数据的 那是中级测试员 ;知道围绕前端 服务 数据的 那是高级测试员;
“别跟我说你测试理论有多深,开发技术有多厉害,用的工具有多深奥,系统测试,三个字,一前一后一数据。合不起来的,躺下喽,合的起来的才有资格讲话。你说这话对吗?”