看到有人的观点是，“真想学习不需要加群”，恰好今天看书讲到相关内容，分享下。




学习渠道的选择因人而异。针对个人的毫无依据的 “诋毁”，有必要澄清，也就是 “干货” 这件事。从开始做自媒体以来，我遵循的原则是完全原创，至今没有转载或搬运过任何一篇其他人的内容，创作模式也经过了几次迭代，英文官网学习笔记，纸质书学习笔记，框架平台教程，工作思考沉淀。可以说很用心在输出。
产出有公开的电子书、GitHub 的开源项目、B 站的平台教学视频和公众号的思考文章，虽然水平很一般，比起真正的大佬还差得很远，但也是很诚心在做分享这件事。正在制作 “软件测试知识体系” 专栏，也没打算收费，希望能出一个非技术的软件测试的 “作品”，既梳理知识，也分享帮助更多人参考学习。
微信群运营了 4 年，没收过费，人数多了以后，有些内容分享出来有所顾忌，建个私密小群的想法很久就有了，恰好朋友圈看到有例子，就借鉴了。也设立了门槛，为了避免误会，我强调了全部作为群资金，并且支出我都通过群公告进行公开。提高门槛也是为了限制人数，不然有可能从小群变成大群。相比于知识星球，我建小群门槛低很多，本质上我也没有收入，只是个托管的财务，最终会以各种方式返还的。

这里有个完整教程，适合 pytest 路线
https://dongfanger.gitee.io/blog/%E6%9B%B4%E5%A4%9A%E8%AF%AD%E8%A8%80/000001-%E3%80%90%E5%BC%80%E6%BA%90%E6%A1%86%E6%9E%B6%E3%80%91%E5%85%B3%E9%94%AE%E5%AD%97%E9%A9%B1%E5%8A%A8%E6%A1%86%E6%9E%B6.html

就学习方法而言，个人推荐：
1、首选官方教程，官方教程永远是对新手最友好的教程，条理清晰，循序渐进；
2、其次是博客，很多博客是对知识进行了拆解，用更容易理解的语言二次解释；
3、开源项目，比如想学习 pytest，可以看一下 tep，能够帮你快速构建整体认知；

代码确实不够简洁，假如文件很多，那么可读性会比较差。可以考虑下代码数据分离，用文本文件或者 yaml 文件把 path 单独存放，再写个 loader 读取到代码里面，代码就看着要 “优雅” 点。

用例评审：
1、对齐产研测三方信息，尤其是中途发生过变更的点；
2、范围包括：模块用例、联调用例、测试物料；
3、评审过中，说不定能发现提测前 Bug；

开发人员不能做测试，因为自己测自己写的程序，从人的惰性角度来说，很多 bug 还是发现不了。测试人员要写代码，因为人工测试效率低，需要写工具或平台的代码，提高测试效率。二者其实是两条平行线，开发做测试也不合适，测试做开发也不合适。也不排除有些综合能力特别强的团队能够开发和测试全包，并且能输出高质量产品，但这也是极少了。

如果转过去的话，年底绩效不合格的指标大概率是我来扛。
今年还是稳一点好吧，这个情况转过去不一定就比继续做测试好，反而可能会认为心态有点浮躁，对以后发展不利，何况年龄也摆在那了。
建议先稳住，既然现在是测开，那么下次业务调整有测开的机会，估计也会优先考虑你吧。再等等。

用例集：按照系统模块或逻辑分组。
用例标题：对测试内容的精准简洁描述，尽可能用少的字符数描述清楚用例覆盖点及结果，一定要有结果。
步骤描述：对测试内容的详细步骤描述，包括但不限于：1、数据初始化；2、功能步骤。
预期结果：执行步骤对应的无 bug 时的结果。
前置条件、用例类型、优先级按需添加。
XMind 推荐用以下格式编写：

用例集可以多层菜单；
用例集下只有一层用例标题，用例标题打上优先级的标记；
用例标题建议一句话：验证 + 动作 + 结果，比如：
验证输入正确信息登录成功。
验证输入错误用户名提示用户不存在。
验证输入错误密码提示用户密码不匹配。
步骤拆成多个，步骤描述和预期结果一一对应；
用 XMind 的概要补充前提条件；
注意，让每条用例都是完整的，能让别人执行的。

JAVA 编码规范方面检查项，可以参考《阿里巴巴 Java 开发手册》：
最新版本：黄山版（2022.2.3 发布）
https://github.com/alibaba/p3c

看了下原文，这两个图应该这样来对比：


PS：https://martinfowler.com/articles/practical-test-pyramid.html 这篇文章干货很多，值得细读。

能过面试拿到一份测试开发工作 offer
一、进大厂，大厂的很多业务测试，也是叫做测试开发工程师。
二、磨炼技术，会做测试平台开发，是基本要求，从前端到后端到运维，整个链路的技能点都得点亮。
多看机会，多去面试，带着目标感行动，认知到自己离测试开发的真实差距在哪，比自己闷着头学习更加高效。

看来是奔着学习目的来开发测试平台的，并不是为了公司级使用。技术栈是 SpringBoot+Vue。建议照着 MeterSphere 抄一遍，做个基于 JMeter 的接口自动化测试平台，对能力提升有莫大帮助。我也正在按这个路子做，连项目都创建好了，还没开工：
https://github.com/dongfanger/japi
目前正囫囵吞枣刷一遍 Java 官方教程、Java 虚拟机、SpringBoot 官方教程、阿里 Java 开发手册、Java 技术栈知识，为项目开发做足基础准备。

用了多久，花了多少时间这类的问题，到底是想了解啥呀，比较费解。
反而是输出多少自动化用例，占比多少，正确率如何，代码覆盖率能达到多少，这种关键指标没有提到。

测试策略：
1、测试的对象和范围是什么？
2、测试的目标是什么？
3、测试的重点和难点是什么？
4、测试的深度和广度是什么？
5、如何安排测试活动？
6、如何评估测试的效果？

不被别人牵着鼻子走，这一点我觉得是作为测试，在沟通中最重要的原则之一。很多时候对方东扯西扯，会让你说很多废话，这时候要稳定内心，简明扼要的说中关键点，提高沟通效率。在意见出现分歧时，也应该找客观的测试理论/工作规范为自己做支撑，比主观认为应该怎样怎样更能说服对方。

从业务出发，能解决手工重复执行的操作，都可以实现成小工具。
一定要解决业务问题。有很多通用的小工具是不需要再造轮子的，比如有些测试平台喜欢做一个解析 JSON 的小工具，实际上工作中很多人习惯用 json.cn。

有几个疑问：
1、基于什么使用场景开发的这个工具？
2、跟 jacoco 的 javaagent 有哪些差异？
3、为什么要用这个工具而不直接用 jacoco？

JMeter 确实很强啊，提供了这么多实用工具。话说 MD5 加密那段代码，应该可以直接用 Spring 封装好的方法。

import org.springframework.util.DigestUtils;
String password = DigestUtils.md5DigestAsHex("abd".getBytes());
System.out.println(password);  //4911e516e5aa21d327512e0c8b197616

此类问题可以套用 STAR 模型：

情景：事情是在什么情况下发生的
任务：你具体有什么任务
行动：针对这样的情况，你采用了什么行动方式
结果：结果怎样，你学习到了什么
当要讲故事时，可用 STAR 模型构思最简单的版本。

现状是什么 (Situation)：你负责什么系统？为什么你要做自动化？
任务是什么 (Task)：定量的目标？定性的目标？多少条自动化用例？
行动是什么 (Action)：怎么写的自动化用例？目录怎么组织的？用例怎么设计的？有没有定时巡检？有没有实时维护？
产出是什么 (Result)：量化指标？自动化用例占比？执行成功率？自动化发现多少 bug？

一、闭环用例，换个词，联调用例，就能沟通了。开发应该想表达的是，需要把模块串起来测吧，你是不是缺少了这样的模块之间的联调用例。
二、覆盖黄金链路，从头到尾，这个也要有的。如果你只是模块测试，不需要写；如果你是主测试，就必须加上。

近期在做财务对账系统的测试，看完文章还是有一些收获。
物料准备：提前规划好需要哪些数据，有些数据是 T+n 的，不提前准备会影响测试周期。
功能：1、源数据、目标数据、聚合数据，数据比对，除了当前测试系统，还可以跟其他系统的相同数据比对。2、各种各样的数据，这个是重点也是难点，不容易达成 100% 场景覆盖。3、规则核对，每个字段的取数来源、映射关系、计算规则。
性能：大量 mq 消息处理、查询性能。

一、参数化。把要变的数据提取出来，存入到变量里，数据驱动，下次变动批量改变量数据就行了，不必再一一接口调整。
二、捞日志。从日志抓取最新参数，直接复用，可以省去参数字段反复编辑的麻烦，但是仍然需要挨个接口修改，不可避免。
三、流量录制。Chrome 插件、Postman、MitmProxy 等工具都有类似功能，把接口抓取下来存为 JSON 等数据文件，里面的参数应有尽有，甚至有些能转化为自动化用例/流量回放。

刚开始建议把测试用例写规范，而不只是测试点。注意，让每条用例都是完整的，能让别人执行的。
用例集：按照系统模块或逻辑分组。
用例标题：对测试内容的精准简洁描述，尽可能用少的字符数描述清楚用例覆盖点及结果，一定要有结果。
步骤描述：对测试内容的详细步骤描述，包括但不限于：1、数据初始化；2、功能步骤。
预期结果：执行步骤对应的无 bug 时的结果。
前置条件、用例类型、优先级按需添加。
功能用例写得规范了，可以学习下自动化，再把自动化用例写好。

这个分类有点乱，建议按照通用分类，测试类型 + 测试方法，重新组织下。
若产品支持：PC、小程序、APP 端，需要在多终端验证产品可用性。
比如这个兼容性，只是终端兼容性，“兼容性” 还包括很多细分内容。

config 配置的一些公共接口，比如登录
配置里面存放公共接口？这个点从概念上就是有点问题，要么把登录接口作为前置步骤，放到测试用例的前置；要么把固定 token 作为预设变量存储在全局变量池。