十年时间说长不长说短不短。当年刚入行的时候面试官问我为什么想做测试我特别实诚地回答“因为我细心喜欢找bug。”现在回想起来这个答案幼稚得能抠出三室一厅但它确实是我和测试这行缘分的起点。这十年里我从功能测试做到自动化测试再从自动化测试做到性能测试、安全测试中间还涉足过车载、芯片、AI这些听起来很“硬核”的领域。身边很多同行问我做了这么多年测试到底积累了些什么是技术栈越来越深还是薪资越跳越高我觉得都不是真正沉淀下来的是一套怎么面对未知问题、怎么评估质量风险、怎么在有限资源里做出靠谱发布决策的方法论。如果你正打算入行测试、已经在职两三年觉得遇到了瓶颈、或者想从某个专项测试往更宽的领域走这篇总结应该能给你一些参考。我不会讲那些放到任何行业都适用的空话只讲这十年我在真实项目里踩过的坑、验证过有效的方法以及回头看才明白的道理。1. 十年测试路从手工点点点到质量守护者的认知升级1.1 刚入行时我对测试的理解点、点、点我的第一份测试工作是在一家做企业级Web系统的公司职位是“软件测试工程师”。入职前我以为自己每天的工作就是拿着产品需求文档打开系统按照用例一条条执行发现问题就提单没问题就通过。前三个月我确实也是这么干的而且干得自我感觉良好——一个月能提四五十个bug觉得自己的价值就是“找茬”bug数量就是KPI。但很快我就被打脸了。有一次我提了一个“严重”级别的bug开发同事看了一眼就驳回了“需求文档里写的就是这个逻辑是你理解错了”。我翻开需求文档仔细读发现他的解释在字面上确实说得通但用户真实使用场景里根本不会那样操作。我才意识到测试如果只对着文档点点点那只是“需求的复读机”而不是“质量的守护者”。这个阶段给我最大的教训是测试的基础不是操作熟练度而是对业务的理解深度。机械执行用例谁都会但能把业务逻辑吃透、能站在用户视角反向推导异常的才叫测试工程师。后来我每接手一个新模块第一件事不是打开系统而是先找产品经理聊需求背景、找开发聊技术方案、找运维聊部署架构把整个链路在脑子里跑通了再开始测。1.2 十年后我对测试工作的重新定义做了十年测试如果现在有人让我用一句话定义测试我会说测试的本质是“风险识别与信息兜底”——在有限的资源、时间和预算内尽可能把可能导致线上故障、用户投诉、业务损失的问题提前暴露出来并且给出可量化的质量结论。这个定义意味着三件事。第一测试不可能穷尽所有情况我们能做的是基于风险优先级来分配精力把80%的资源投在20%的高风险模块上。第二测试的输出不只是bug列表更是一个“能不能发布”的建议这个建议背后要有数据支撑用例覆盖率、缺陷密度、遗留缺陷等级、性能指标是否达标。第三测试和开发不是对立关系我们的共同对手是“线上的未知故障”而不是彼此。所以这些年我写测试用例的风格也变了。年轻时喜欢把用例写得又全又细一个功能能写两百条用例结果一半是无效用例维护成本极高。现在我会先问自己三个问题这个功能挂了影响面多大出问题的概率多高有没有更简单的验证路径想清楚这三点再动手设计用例。反而用例子少了但每条用例的命中率大大提升。1.3 角色演进从执行者到设计者再到管理者测试工程师的职业路径回头看我大致经历了三个阶段。前两年是“执行者”核心技能是用例执行、bug提交、回归测试这个阶段拼的是细致和执行力。中间三到五年是“设计者”开始负责测试计划、用例设计、自动化框架搭建、性能测试方案拼的是系统思考能力和技术深度。最近几年算是在“管理者/顾问”的角色要负责质量策略制定、测试团队规划、风险决策和建议拼的是沟通影响力和全局观。这三个阶段不是割裂的而是层层递进的。执行者如果只盯着自己那一亩三分地永远不会理解为什么用例要这么设计设计者如果不懂业务痛点和用户场景设计出来的测试方案再漂亮也是纸上谈兵。所以我对新人的建议一直是不管你现在处于哪个阶段都试着往上一层思考。做执行的时候想想如果我是测试负责人这个模块我会怎么安排测试重点做设计的时候想想如果我是项目经理这个质量风险我会怎么跟老板汇报。2. 技术栈演进一个测试工程师十年攒下的工具箱2.1 接口自动化性价比最高的投入如果让我给测试团队挑一个最值得优先投入的技术方向我一定会选接口自动化。为什么因为接口层处在UI层和单元层之间既比单元测试更接近用户真实场景又比UI自动化稳定得多、快得多。一个产品的核心业务流程只要接口测通了UI只要做关键路径的冒烟测试就够了。我最早搭建接口自动化用的是JavaTestNGHttpClient后来切到了PythonRequestspytest。为什么要换因为Python写起来快生态好维护成本低。框架核心就四件事请求封装、断言封装、参数化、结果报告。请求封装解决的是登录态、公共参数、签名逻辑的统一处理断言封装解决的是状态码之外对返回字段、数据库落库情况的校验参数化解决的是不同测试数据跑同一套用例结果报告解决的是跑完怎么直观看到通过失败、失败在哪个环节。这里有一个特别容易被忽视的坑接口自动化最怕的不是代码写得烂而是测试数据不稳定。同一套用例今天跑通过明天跑失败查了半天发现是上游的测试数据被别人改了。所以做接口自动化一定要把造数和清数做成脚本的一部分每次执行前造一批独立的测试数据执行后清掉做到用例之间互不干扰。我见过太多团队自动化用例几百条但因为数据问题天天红最后沦为摆设。2.2 Appium移动端自动化纸上谈兵容易真机跑起来全是坎移动端自动化我接触最多的框架是Appium。如果说接口自动化是“按部就班”那Appium自动化就是“步步惊心”。最常见的坑有三个元素定位不稳定、等待策略不对、真机和模拟器行为不一致。元素定位方面很多App的页面元素id是动态生成的今天叫btn_login_01明天就变成btn_login_02你用绝对id定位必挂。我的做法是优先用resource-id结合文本内容、类名、层级关系做相对定位实在不稳定就让开发在代码里加testID这对后期自动化收益巨大值得push。等待策略方面sleep(3)这种写满脚本的我看得太多正确做法是显式等待轮询条件元素可见、可点击、存在分别封装成自定义方法。真机与模拟器差异方面iOS的权限弹窗、Android的厂商ROM差异都可能导致脚本在模拟器上跑得好好的一上真机就崩所以UI自动化必须设定真实设备兼容范围至少覆盖主流机型。还有一点UI自动化的维护成本远高于接口自动化。UI稍微改个文案、挪个按钮位置用例可能就挂了。所以我的经验是UI自动化只覆盖核心用户路径的冒烟用例比如登录、注册、下单、支付这些不可或缺的流程不要指望UI自动化替代完整的回归测试。2.3 弱网测试与并发测试Fiddler和JMeter的实战用法弱网测试我有段时间做得特别多因为App在弱网环境下最容易出问题。工具上我用Fiddler比较多它可以模拟延迟、丢包、带宽限制。具体做法是在CustomRules.js里写脚本或者在菜单栏的Simulate Modem Speeds里选一个预设速率。但预设速率太粗糙了我一般会自定义比如模拟2G/3G网络的延迟300ms、丢包1%做法是在脚本里给onBeforeRequest加一行oSession[request-trickle-delay] 300给响应加一行oSession[response-trickle-delay] 300。弱网测试要重点观察的不是“页面有没有加载出来”而是三件事超时机制是否生效、请求重试是否会导致重复提交、弱网切换到强网后数据是否一致。我测过一个支付模块弱网下用户点支付请求超时了界面提示“支付失败”但实际后台已经扣款成功。这就是典型的分布式事务一致性问题不做弱网测试根本暴露不了。并发测试我用JMeter比较多。很多新手一上来就设置5000个线程结果把服务器压崩了然后跑过来告诉我“性能不过关”。这是典型的错误姿势。正确的做法是先小规模压测做摸底比如从100并发开始观察响应时间和错误率再逐步增加找到性能拐点。JMeter里线程数、Ramp-Up时间、循环次数这三个参数要配合着调Ramp-Up一般设置成线程数/每秒增加数比如100线程希望每秒增加10个Ramp-Up就是10秒。聚合报告里重点看三列Average响应时间、Error%、Throughput吞吐量以每秒事务数为主响应时间只做参考关键是看拐点在哪。2.4 测试数据管理决定自动化成败的隐形因素前面提到过测试数据问题这里单独展开说因为它的重要性被严重低估了。打个比方自动化测试就像是在一条跑道上跑步代码是跑鞋测试数据是跑道本身。跑鞋再高级跑道坑坑洼洼一样跑不出好成绩。常见的测试数据问题包括环境之间数据不同步测试环境一套数据、预发环境又一套数据、数据被其他团队用例污染、造数脚本和生产数据脱敏不完全导致合规风险。我的解决思路是建立“测试数据管理规范”核心就三条环境隔离、独立造数、定时清理。每个环境必须有独立的数据库实例不能用生产数据直接灌测试环境每个测试用例必须能通过造数接口或SQL脚本创建自己的前置数据每次测试结束后必须有清理机制避免脏数据堆积影响后续用例。我曾经负责的一个项目自动化脚本稳定跑了三个月突然开始大量失败查了整整两天最后发现是另一个团队往公共测试库里灌了一批“看起来相似但逻辑不同”的数据导致我的用例断言全部失效。从那以后我再也不信“公共数据”这种东西能隔离一定隔离能独立一定独立。3. 专项测试领域从通用测试到行业深耕3.1 安全测试授权范围内越挖越有意思的方向安全测试是我转型最大的一个方向因为它完全改变了我的思维方式。以前测功能我关注的是“这个功能对不对”做安全测试我关注的是“这个功能怎么被滥用、被绕过、被攻击”。新手学安全测试我建议从OWASP Top 10入手先理解SQL注入、XSS跨站脚本、越权访问、文件上传漏洞这四类最常见的漏洞原理。工具方面Burp Suite是必学的抓包改包工具SQLMap是SQL注入检测利器Nmap是端口扫描的基础工具。练习平台强烈推荐Pikachu漏洞靶场这是一个本地化的Web漏洞练习环境覆盖了大部分OWASP Top 10漏洞类型而且是开源免费的在自己电脑上装一个随便练完全合法合规比去真实网站乱试安全得多。这里必须强调一点安全测试一定要在授权范围内进行。可以对自己的系统、公司内部系统、或者像Pikachu这种专门的靶场环境做渗透测试但绝对不能对未经授权的网站或系统做任何攻击行为这不仅违反职业道德更触犯法律。我见过有同行因为好奇对某个网站跑了扫描器结果惹上了麻烦真的要引以为戒。3.2 车载测试与汽车电子完全不同的测试哲学从互联网测试转到车载测试我最大的感受是这两个领域的“质量观”完全不一样。互联网产品的bug最坏情况是用户不满、业务损失、舆情危机车载软件的bug最坏情况是车毁人亡、生命安全事件。所以车载测试的第一个特点就是安全标准极其严苛ISO 26262功能安全标准贯穿整个开发流程。车载测试涉及的范围很广CAN/LIN总线通信测试、车载以太网测试、自动驾驶感知算法测试、座舱交互测试、导航娱乐系统测试。其中CAN总线测试是汽车电子测试的基础。每辆车上都有一条或几条CAN总线像人的神经网络一样连接着各个ECU电子控制单元测试时要通过CANoe或PCAN这类工具往总线上发报文验证各ECU对报文的响应是否符合规范。这里涉及很多汽车特有的概念比如DBC文件描述CAN报文格式的文件、信号矩阵、报文周期、错误帧等每一块都能写好几篇长文。还有一个和互联网测试很大的区别车载测试的硬件耦合度极高。同一个软件装在不同的域控制器上表现可能完全不同同一辆车冬天和夏天跑出来的数据也不同。所以车载测试必须做大量的实车测试和台架测试而台架测试要在硬件在环HIL环境中进行通过模拟传感器信号、执行器负载在实验室环境里验证控制器的逻辑。3.3 芯片测试与EMC测试实验室里的硬核测试芯片测试和EMC测试是我这几年接触得比较多的两个“硬核”方向。芯片测试通常指芯片流片后的功能验证和量产测试分为晶圆测试CP和成品测试FT核心是用ATE自动测试设备对芯片的电性能参数、逻辑功能进行检测。这里面涉及的知识包括模拟信号采样与量化、数字逻辑向量生成、测试覆盖率计算、良率分析。芯片测试的难点在于每一颗芯片都要测而且测试时间直接影响芯片的成本所以测试工程师要想尽办法在保证覆盖率的前提下压缩测试时间。EMC电磁兼容测试很多人听到这三个字母就觉得高深其实一句话就能讲明白因为电子产品工作时会产生电磁辐射同时又容易被外部电磁干扰所以要通过专门的测试来确保设备既不会干扰别人又不会被人干扰。EMC测试分两大类EMI电磁干扰测试和EMS电磁抗扰度测试。热词里提到的“EMC测试的RE的读点是什么意思”我猜这里的“读点”应该是“RE的点”或者“Reading Point”之类RE全称是Radiated Emission辐射发射测试它的“读点”指的是在某个频点上的辐射发射值比如某产品在200MHz频点上辐射值读数是35dBμV/m标准限值是40dBμV/m那这个读点就在限值以内符合要求。测试这些项目一般要去专业实验室里面有电波暗室、频谱分析仪、天线、信号发生器整套系统的搭建和维护费用非常高所以多数企业是送样到第三方实验室测。3.4 游戏测试与AI测试两朵不一样的另类云游戏测试和AI测试跟传统软件测试也截然不同。游戏测试除了常规的功能测试还要关注数值平衡性角色的攻击力、血量、爆率是否合理、用户体验操作手感、画面流畅度、音效反馈、兼容性不同手机配置、不同系统版本。游戏性能测试特别重要尤其是帧率FPS和功耗发热玩家不会容忍一款开着高画质就掉帧到30FPS以下的游戏。AI测试是我目前关注最多的新方向。传统测试的输入是确定的输出是可预期AI系统的输入是海量数据输出是概率性的。比如一个图像识别模型同一个模型在不同光线、不同角度下识别同一只猫置信度可能不一样。测试AI系统核心是两件事一是数据质量测试训练数据是否覆盖足够的边界场景、是否分布均衡、有没有标注错误二是模型评测用预先标注的测试集去评估准确率、召回率、F1值这些指标还要做鲁棒性测试比如输入一个带噪声的图片看模型会不会出错。“AI变异测试”是近几年比较新的概念它的思路是借鉴传统变异测试——通过对模型或代码做微小变异比如修改某个权重、改变某个激活函数然后验证测试集能不能检测出这个变异。如果大量变异都逃过了现有测试集的检测说明测试集不充分。这个概念用大白话说就是用“故意下毒”的方式测试你的测试用例到底灵不灵。4. 踩坑实录那些年我交过的“学费”4.1 缺陷定位不准被开发反怼之后我才学会的沟通方式不知道有没有同行和我一样刚入行时提bug喜欢写“页面报错”“系统崩溃”这种模糊描述截图一贴就提交了。结果开发看了半天找不到规律跑过来问我“你到底在哪一步操作的用的什么账号什么浏览器有没有看控制台日志”我当时很委屈觉得开发是在故意刁难后来才发现问题在我我给的缺陷信息不足以支撑开发快速定位。从那以后我养成了一个习惯提交任何缺陷之前必须自己先做一次“最小重现”。也就是把操作步骤精简到不能再精简确认是这个步骤必然导致这个结果而不是偶发。缺陷单必须包含五要素前置条件、复现步骤、预期结果、实际结果、影响范围再加上日志抓取和抓包数据。这样做之后开发同事对我的信任度大大提升缺陷解决速度也明显变快了。这背后的道理很简单测试的价值不只是“发现问题”更是“减少沟通成本帮团队快速解决问题”。4.2 自动化脚本“天天红”问题居然不在脚本本身有一段时间我们团队的接口自动化用例天天能挂十几条但去看接口本身逻辑都对数据也没问题就是断言失败了。我排查了很久最后发现是执行环境的时间和服务器的系统时间不一致导致的——用例里校验了时间戳本地时间比服务器快了30秒导致接口返回的timestamp字段和预期永远对不上。这个坑让我深刻理解了一件事自动化测试的稳不只是脚本代码的稳还包括测试环境的稳。环境变量、系统时间、IP归属、数据库同步延迟任何一个环节有微小偏差都可能导致一大堆用例同时失败。后来我给团队定了一条规矩自动化执行的基线环境必须做“环境巡检”每次执行前自动检查关键环境指标比如时间同步、服务版本号、数据库连接数有异常先告警而不是等用例执行完才从满屏的红色里找原因。4.3 版本发布前夜我发现测试环境配置少了三项那是春节前最后一个版本我负责的模块已经测了两轮一切正常准备第二天发布。当晚十点产品经理临时加了一个小需求说是“配置项调整”我顺手在测试环境改配置验证没想到一改就出事了。对照生产配置一看测试环境少了三个关键的配置项意味着之前两轮测试根本没覆盖到这三个配置开启后的逻辑分支。也就是说我们一直以为自己测的是完整版本实际上测的是一个“缺失版”。事后复盘根因是测试环境的配置管理太随意没有一个基线化的配置清单。后来我推动团队做了配置管理规范所有非生产环境必须保存一份“配置基线”每次环境更新必须比对基线任何新增配置项必须先更新基线文档再改环境。这个改动看起来很基础但真的避免了大量“环境可用但配置不全”的假阳性结论。做测试的最怕的不是系统有问题而是系统没问题但我们的环境有问题得出一个错误的“通过”结论这是比bug更可怕的事故。4.4 误报与漏报两个都要管但不能一刀切测试工作里最纠结的事就是用例报了一堆错结果一看全是误报或者为了避免误报把断言放得很松结果漏掉了真正的问题。误报会降低团队对自动化的信任度漏报会让潜在问题流到线上这两头都不能偏废。我的平衡策略是分等级处理。线上直接可见、影响用户核心流程的问题用最严格的断言宁可误报不能漏报非核心流程、影响面小的问题用比较宽松的断言只做“提醒”不做“失败”处理还有一些已知的历史问题在修复之前用例标记为skip而不是fail避免每天都看到红色而麻木。另外误报的根因追踪同样重要那种“偶尔飘红、重跑又过”的用例一定要揪出原因因为不确定性问题往往比稳定复现的问题藏着更大的隐患。5. 测试思维与职业进阶不只会执行用例的人走不远5.1 测试用例设计的底层逻辑其实就四招很多新人在设计用例时毫无章法想到哪写到哪漏测了也不知道漏在哪。我在团队内部培训时最常讲的测试用例设计底层逻辑就四招等价类划分、边界值分析、场景法、错误推测法。等价类划分就是把输入数据按性质分成若干类每一个类里取一个代表性数据就够了。比如一个年龄输入框限制18到60岁那至少要有有效等价类如30岁、无效等价类之小于18如10岁、无效等价类之大于60如70岁、还有非数字类型如“abc”。边界值分析是等价类的一个补充80%的bug都出在边界上所以18岁、60岁、17岁、61岁这些边界值必须测。场景法是从用户操作的角度把功能串成一条完整链路比如从加入购物车到支付成功、从支付超时到订单取消重点测业务流而不是单个点。错误推测法是依赖经验和直觉去猜测哪里容易出问题比如用户连续快速点击提交按钮会不会导致重复下单、网络断开再恢复后页面状态是否正确。这四招配合使用才能在有限的用例数量下尽量提升覆盖率。我最怕看到的就是为了凑用例数量写一堆“输入1点击按钮预期出现结果1”的无效用例这种东西测了等于没测。5.2 沟通协作测试最容易被忽视的“软技能”测试工程师在很多人眼里是“技术岗”但我做了十年越来越觉得这行本质是“沟通岗”。你要跟产品经理确认业务规则要跟开发人员讨论缺陷归属要跟运维人员协调环境问题要跟项目经理汇报测试进度哪一样都离不开沟通。怎么把技术做到位又沟通通畅我的体会有三一是讲事实而不是讲情绪。提缺陷时不要用“你这代码写错了”“这功能做得有问题”这种带指责意味的话而是客观陈述“在这个前置条件下、执行这些步骤实际结果与预期不符”描述流畅的缺陷单本身就是最好的沟通。二是学会区分哪些东西不可妥协、哪些可以协商。安全性、数据一致性、核心链路不可妥协UI美观度、文案风格可以谈判。三是测试的结论必须要有数据支撑。说“这版本质量不行”没有说服力说“这个版本遗留2个P0级缺陷、5个P1级缺陷其中1个会导致数据错乱建议修复后发布”才有分量。5.3 测试左移与质量内建越早发现问题的成本越低这是我后来带团队最强调的一件事。传统测试是“开发完成-测试介入-上线”这条流水线看起来没毛病但问题在于需求阶段埋下的坑要等测试阶段才被发现返工成本已经翻了好几倍。测试左移就是让测试活动从需求阶段就开始介入。具体落地我做了三件事。第一需求评审阶段测试必须参与重点从测试视角提出质疑这个需求的可测性怎么样验收标准够不够明确有没有遗漏的异常场景第二要求开发提测前必须自测通过并且提供自测报告测试不接“半成品”。第三推行“契约测试”服务之间接口联调前先通过契约文件约定请求和响应格式避免两团队开发到一半才发现字段对不上。这三件事让我们的缺陷逃逸率明显下降最直观的变化是线上紧急修复的频次从一个月两次降到了两三个月一次。5.4 面试与团队管理视角我筛人时真正看重什么带团队这几年我至少面试过几百个测试候选人说说我真实的筛选标准。简历上写“熟练掌握Appium、JMeter、LoadRunner”的人很多但只要追问一句“你在实际项目里用Appium解决过什么特别难的问题”很多人就答不上来这说明所谓“熟练掌握”只是用过demo。我真正看重的能力有三个一是复盘反思能力同样的一个项目让他讲成功经验或者失败教训看他能不能讲出深度方法论而不是罗列流水账二是业务敏感度给他一个不熟悉的功能看他会不会主动追问业务背景、用户场景、数据流转而不是直接开始说“我会用什么工具测”三是解决问题的能力给出一个线上故障场景让他讲排查思路看他是无头苍蝇式乱试还是有条理地分层次验证。工具、框架这些都可以在入职后快速学会但思维方式和解决问题的底层能力才是区分优秀测试和普通测试的分水岭。6. 给新人和同行的一些实在话6.1 如果有时光机我会给刚入行的自己写三条建议第一条建议不要只做一个“执行者”。刚入行可能确实要从执行用例做起但千万不要沉溺在“我今天又提了几个bug”的成就感里。要多想一步为什么用例要这么设计这个bug背后暴露了什么问题换一种设计方式能不能提前发现只有不停地往上思考才能跳出重复劳动的陷阱。第二条建议技术能力是护城河但绝不是全部。会写自动化脚本、会压测、会抓包这些都很重要但真正让你在职场上走远的是你对业务的理解深度和沟通协作的能力。给业务方讲清楚“这个bug为什么会产生什么影响”比你默默提交十个bug更有价值。第三条建议定期复盘把经验变成方法论。我很多工作习惯和测试框架都是在一次次复盘里总结出来的。不要等跳槽写简历时才想起来总结每做完一个项目、每踩完一个坑都花半小时把它记录成文档时间久了这就是你区别于别人的核心竞争力。6.2 十个提升效率的习惯强烈建议养成每天上班先花10分钟看昨日的自动化测试报告处理失败用例别让它堆积。提交缺陷前先自测一遍“最小重现”确保不是自己操作的问题。所有环境账号、配置、部署方式都记录下来不要把信息放在自己脑子里。写自动化用例时同步写数据清理逻辑不给自己留“脏数据债”。接口自动化优先于UI自动化能把逻辑放在接口层验证就绝不放到UI层。被测系统的新版本上线前先跑一遍冒烟用例再开始深度测试。常用命令和SQL脚本做好个人代码片段管理随手粘贴省时省力。每周抽半小时学习一个测试相关的新工具或新概念哪怕只是了解它的应用场景。开测试评审会时先列风险清单再讨论用例细节避免被开发带偏节奏。定期做“模拟线上故障”演练在测试环境主动制造异常验证监控和告警是否灵敏。6.3 一句说给自己和同行的话十年过去测试这个职位的社会认知从“点鼠标找bug的”变成了“质量保障工程师”工具和概念换了一茬又一茬从自动化测试到AI测试从敏捷到DevOps但有一点始终没变我们是一群对质量有执念的人愿意在别人觉得“差不多就行”的地方较真到底。这个岗位不需要你成为天才但需要你保持好奇、保持批判、保持对细节的敏感。如果你觉得自己每天都在重复劳动、没有成长试试往上一层想想“为什么”和“怎么办”也许就是打破瓶颈的开始。希望这篇总结对你有用也欢迎同行后台聊聊你们踩过的坑一起把这行做得更专业。