想一两句话把什么是架构师讲清楚，是非常困难的一件事。因为架构师这个角色是致力于解决高度复杂抽象的问题，所以架构师的定义也是复杂抽象的。但并不代表架构师的定义无法被解释清楚，我们需要多花点时间，从各个角度来解读架构师。通俗地解释下什么是架构师大白话的解释就是，软件产品的设计师。架构一词最早源于建筑学，软件工程的架构师与建筑工程的架构师有非常多的相通之处，都是负责“产品”的宏观层次设计。他人眼中的架构师在老板眼中，架构师是一名技术领导者，带领团队攻关疑难问题。在业务方眼中，架构师是一座业务与技术的桥梁，填平业务与技术的鸿沟。在研发团队眼中，架构师是一位导师与布道者，是大家学习的榜样。在项目组眼中，

TK教主16年在腾讯内部的一个分享，讲述安全研究者的个人成长。虽然分享的内容是关于安全研究领域，但我相信对各个领域的学习成长是相同的。这里记录如下：个人成长确立个人方向，结合工作内容，找出对应短板该领域主要专家们的工作是否都了解？相关网络协议、文件格式是否熟悉？相关的技术和主要工具是否看过，用过？阅读知识学习过程的起点，不能止于阅读工具的每个参数每个菜单都要看、要试学习网络协议要实际抓包分析，学习文件格式要读代码实现学习老漏洞一定要调试，搞懂别人代码每一个字节的意义，之后要完全重写一个Exploit细节、细节、细节、刨根问底建立学习参考目标短期参考什么？比自己优秀的同龄人阅读他们的文章和其他工

TK教主16年在腾讯内部的一个分享，讲述安全研究者的个人成长。虽然分享的内容是关于安全研究领域，但我相信对各个领域的学习成长是相同的。这里记录如下：个人成长确立个人方向，结合工作内容，找出对应短板该领域主要专家们的工作是否都了解？相关网络协议、文件格式是否熟悉？相关的技术和主要工具是否看过，用过？阅读知识学习过程的起点，不能止于阅读工具的每个参数每个菜单都要看、要试学习网络协议要实际抓包分析，学习文件格式要读代码实现学习老漏洞一定要调试，搞懂别人代码每一个字节的意义，之后要完全重写一个Exploit细节、细节、细节、刨根问底建立学习参考目标短期参考什么？比自己优秀的同龄人阅读他们的文章和其他工

​《漫谈测试成长之探索——测试文档》一文阐述了我们可以从项目维度去整理测试相关的文档来提升自己，本文将从测试排期方面探索成长方向。我们知道，对于做一件事，我们要有计划，要知道目标，要记得看时间。这里的时间对应到软件测试中就是与测试相关的时间节点。如图1-1所示，在以往工作中，作为一线测试执行者，我们一般会关注开发计划提测时间、测试计划开始时间、测试计划完成时间和需求计划发布时间。但是，经验告诉我们，只关注这些时间节点似乎是不够的。在实际工作中，需求实际可测试的时间经常延期，测试时间被压缩的情况时有发生。图1-1传统测试排期时间节点那我们能做些什么去规避或者说减少测试工期被压缩的情况呢？本文的答

​《漫谈测试成长之探索——测试文档》一文阐述了我们可以从项目维度去整理测试相关的文档来提升自己，本文将从测试排期方面探索成长方向。我们知道，对于做一件事，我们要有计划，要知道目标，要记得看时间。这里的时间对应到软件测试中就是与测试相关的时间节点。如图1-1所示，在以往工作中，作为一线测试执行者，我们一般会关注开发计划提测时间、测试计划开始时间、测试计划完成时间和需求计划发布时间。但是，经验告诉我们，只关注这些时间节点似乎是不够的。在实际工作中，需求实际可测试的时间经常延期，测试时间被压缩的情况时有发生。图1-1传统测试排期时间节点那我们能做些什么去规避或者说减少测试工期被压缩的情况呢？本文的答

​随着敏捷开发模式的流行，版本交付周期缩短，测试工期压缩，一线测试工程师不仅工作节奏加快，而且工作量也在加大。但是，我们的成长速度似乎越来越慢。这是为什么呢？大环境下，我们都陷入了一个非成长型的恶性循环，随着项目迭代频率加快，循环的回归测试和发布执行等工作不断地消耗着我们的精力和成长动力，我们都想跳出这个循环，却并没有那么顺利。图1-1敏捷下的测试循环那么，我们就这样躺平么？当然不行，我们必须继续探索跳出这个恶性死循环的方法。本文想从测试文档的整理说起，分享测试成长的探索之路。一、传统测试文档传统的测试文档一般包括：测试计划、测试用例、测试缺陷和测试报告。测试计划文档整理了测试的排期，测试用例

​随着敏捷开发模式的流行，版本交付周期缩短，测试工期压缩，一线测试工程师不仅工作节奏加快，而且工作量也在加大。但是，我们的成长速度似乎越来越慢。这是为什么呢？大环境下，我们都陷入了一个非成长型的恶性循环，随着项目迭代频率加快，循环的回归测试和发布执行等工作不断地消耗着我们的精力和成长动力，我们都想跳出这个循环，却并没有那么顺利。图1-1敏捷下的测试循环那么，我们就这样躺平么？当然不行，我们必须继续探索跳出这个恶性死循环的方法。本文想从测试文档的整理说起，分享测试成长的探索之路。一、传统测试文档传统的测试文档一般包括：测试计划、测试用例、测试缺陷和测试报告。测试计划文档整理了测试的排期，测试用例

​回顾校园生活中，我们参加每一场考试后都会对错题进行分析总结并补缺补漏，以便能更好地去应对更重要的考试。回到软件系统开发中，我们记录和跟踪缺陷的目的是什么，仅仅是为了在软件系统开发过程中跟踪Bug直至修复么？应该不止于此。我们也可以对项目缺陷进行分析，分析其共性进而分类，从而建立项目的“错题集”，为下一次“考试”提供宝贵的经验。如图1-1所示，通常一条缺陷记录会包含缺陷编号、缺陷标题、状态、缺陷描述、严重程度、优先级、开发负责人、测试负责人、缺陷类型、功能模块、对应版本和对应环境等信息。那么，我们可以从哪些方面来分析和总结项目的缺陷呢？图1-1软件缺陷记录示例 一、缺陷分析维度如图1-2所示，

​回顾校园生活中，我们参加每一场考试后都会对错题进行分析总结并补缺补漏，以便能更好地去应对更重要的考试。回到软件系统开发中，我们记录和跟踪缺陷的目的是什么，仅仅是为了在软件系统开发过程中跟踪Bug直至修复么？应该不止于此。我们也可以对项目缺陷进行分析，分析其共性进而分类，从而建立项目的“错题集”，为下一次“考试”提供宝贵的经验。如图1-1所示，通常一条缺陷记录会包含缺陷编号、缺陷标题、状态、缺陷描述、严重程度、优先级、开发负责人、测试负责人、缺陷类型、功能模块、对应版本和对应环境等信息。那么，我们可以从哪些方面来分析和总结项目的缺陷呢？图1-1软件缺陷记录示例 一、缺陷分析维度如图1-2所示，

在分享测试用例评审的内容之前，我们可以先思考下为什么要组织测试用例评审会议呢？一、评审目的一般来说，参加测试用例评审的人员包括对应项目的产品人员、设计人员、开发人员和测试人员。图1-1测试用例评审相关人员测试用例评审会议的发起者一般是测试人员，既然我们是发起者，那我们发起这个会议的目的是什么呢？首先，在测试用例设计过程中，我们可能会对某些需求点存在疑问或者不同意见，那我们就要找产品人员讨论和明确需求点。其次，我们可能对产品的界面交互设计存在疑问或者优化建议，那我们就需要找设计人员和产品人员共同讨论和明确设计点。再次，我们也可能对开发设计方案的理解上存在偏差，那我们就需要让各端开发人员协助把控测