Go:基础语法到底怎么学才不会只会写玩具代码
Go 基础语法不能只按 var、if、for、func 分开背,而要放进一个能运行、能校验、能测试的小工具里学。这篇文章围绕一个任务结果汇总 CLI,把变量、分支、循环、函数、错误返回和最小测试串起来。
Go 基础语法不能只按 var、if、for、func 分开背,而要放进一个能运行、能校验、能测试的小工具里学。这篇文章围绕一个任务结果汇总 CLI,把变量、分支、循环、函数、错误返回和最小测试串起来。
Python 基础语法不该按定义背诵,而应该围绕一个能运行的小功能来学。这篇文章用实际脚本把变量、分支、循环、函数、列表、字典、输入输出和错误处理串起来。
从 0 开始把一个 Python 小项目真正跑起来:解释器怎么确认,虚拟环境怎么建,依赖怎么装,入口怎么组织,换环境时怎么验证。
测试方案经常会写成两个极端: 过于模板化,什么都写一点,但没有重点 过于简略,只剩测试范围几个大标题,起不到指导执行的作用 更关键的是测试方案最重要的不是“全”,而是“能指导决策和执行”。如果看完方案之后,团队仍然不知道: 这次最该测什么 哪些内容需要优先保障 哪些风险可以降级处理 自动化、巡检、监控要不要提前介入 上线后要不要继续观察 那方案再长也只是资料,不是方案。 一、测试方案首先要回答什么问题一份有价值的测试方案,至少要回答下面...
先不要急着学并发和接口,先把一份 Go 小工程真正跑起来:开发环境怎么确认,go.mod 在解决什么问题,包和模块怎么配合,入口怎么组织,测试和排错怎么做。
很多项目里的测试介入时间太晚,往往是需求评审结束、开发排期确定、接口基本写完之后,测试才开始认真看需求。这种节奏很容易导致两个问题: 很多风险已经来不及调整 后面的测试工作天然被动 更适合把测试介入前移到需求分析阶段,因为很多真正关键的问题,只有这个时候最容易发现、也最容易被修正。 一、需求阶段真正要做的,不是提前写用例把“测试前移”理解成提前写测试用例很常见,但需求阶段真正高价值的工作不是写步骤,而是做下面这些判断: 这次需求风险有多...
从功能测试走到测试开发,通常不是先有清晰的岗位定义,而是在不断解决重复问题和复杂问题的过程中,逐步走到这条路上。 这条路径如果只看技术,会显得很碎:Python、Jenkins、接口自动化、UI 自动化、K8s、平台建设。但如果从问题演进的角度看,它其实很清楚:先解决交付问题,再解决重复问题,再解决系统问题,最后进入平台和体系问题。 一、第一阶段:先学会“怎么把版本测对”刚进入测试岗位时,关注点很直接: 需求要测完 问题要找全 版本要能...
对测试开发的理解还停留在“会写自动化脚本的人”。这个定义太窄,也会直接限制一个测试开发工程师的成长上限。 这里讨论的测试开发,本质上是用工程化方法解决质量问题。关注点不只是执行测试,而是让测试能力可以复用、可以沉淀、可以持续运行,并最终进入平台和体系层。 因此,这里的测试开发不适合被看成一个“偏测试的开发岗位”,更准确的理解是:站在质量目标之上,用工程方法组织验证、系统和运行能力的人。 一、为什么“会写脚本”远远不够如果把测试开发只理解...