大道至简

欲买桂花同载酒...

Go 基础语法不能只按 var、if、for、func 分开背,而要放进一个能运行、能校验、能测试的小工具里学。这篇文章围绕一个任务结果汇总 CLI,把变量、分支、循环、函数、错误返回和最小测试串起来。

阅读全文 »

测试方案经常会写成两个极端: 过于模板化,什么都写一点,但没有重点 过于简略,只剩测试范围几个大标题,起不到指导执行的作用 更关键的是测试方案最重要的不是“全”,而是“能指导决策和执行”。如果看完方案之后,团队仍然不知道: 这次最该测什么 哪些内容需要优先保障 哪些风险可以降级处理 自动化、巡检、监控要不要提前介入 上线后要不要继续观察 那方案再长也只是资料,不是方案。 一、测试方案首先要回答什么问题一份有价值的测试方案,至少要回答下面...

阅读全文 »

很多项目里的测试介入时间太晚,往往是需求评审结束、开发排期确定、接口基本写完之后,测试才开始认真看需求。这种节奏很容易导致两个问题: 很多风险已经来不及调整 后面的测试工作天然被动 更适合把测试介入前移到需求分析阶段,因为很多真正关键的问题,只有这个时候最容易发现、也最容易被修正。 一、需求阶段真正要做的,不是提前写用例把“测试前移”理解成提前写测试用例很常见,但需求阶段真正高价值的工作不是写步骤,而是做下面这些判断: 这次需求风险有多...

阅读全文 »

从功能测试走到测试开发,通常不是先有清晰的岗位定义,而是在不断解决重复问题和复杂问题的过程中,逐步走到这条路上。 这条路径如果只看技术,会显得很碎:Python、Jenkins、接口自动化、UI 自动化、K8s、平台建设。但如果从问题演进的角度看,它其实很清楚:先解决交付问题,再解决重复问题,再解决系统问题,最后进入平台和体系问题。 一、第一阶段:先学会“怎么把版本测对”刚进入测试岗位时,关注点很直接: 需求要测完 问题要找全 版本要能...

阅读全文 »

对测试开发的理解还停留在“会写自动化脚本的人”。这个定义太窄,也会直接限制一个测试开发工程师的成长上限。 这里讨论的测试开发,本质上是用工程化方法解决质量问题。关注点不只是执行测试,而是让测试能力可以复用、可以沉淀、可以持续运行,并最终进入平台和体系层。 因此,这里的测试开发不适合被看成一个“偏测试的开发岗位”,更准确的理解是:站在质量目标之上,用工程方法组织验证、系统和运行能力的人。 一、为什么“会写脚本”远远不够如果把测试开发只理解...

阅读全文 »
0%