【讲座笔记】腾讯T4专家讲测试开发
总体感受
- 不愧是专家，非常自信，是对自己专业的自信，同时想问题非常透彻，直指要害。“真佛只讲家常话”，面对外行会从思维的层面讲，听着很轻松。
- 听众听讲座喜欢回答问题做互动，喜欢听故事，不喜欢照本宣科，这也是演讲者需要注意的。
- 老板喜欢聪明人，喜欢聪明人在独立思考问题，有自己的见解。
- 要做出能让老板夸耀自己的成绩，更厉害的是能成为老板对外宣扬的故事和业绩。
关于开发理念
- 买了一辆赛车并不意味着能成为一个赛车手，工具不是重点，关键是要能熟练使用工具，对工具的底层原理能了解。
- 前端不需要知道后端的接口实现，后端也不需要知道前端调用接口的写法，前后端分离，联调只做功能的验证。
- 开发不仅要做测试，测试除了测试，还要做研发效能的提升。
- 团队人少就用现成的工具，业务为王，团队人多再考虑自研。
- git的分支策略分为gitflow分支策略和trunk-based development，即主干开发的分支策略。策略取决于业务形态，属于维护期还是快速的功能迭代阶段。
- gitflow分支策略是小批量多批次，容错率高。版本很多，工程师层次不齐就选择gitflow，这样容错率很高，错误隔离很高，缺点是集成度上不去，强管理诉求。
- 主干开发的分支策略有谷歌等公司在执行，适合强代码审查，保密代码少的公司
- 程序员要写单元测试，底层的模块一定要有单元测试。
- 项目要有ROI的视角，这是一个平衡的问题。要看成本花的值不值，早花比晚花好。
- 能不能卡住招聘关，因为要高级的人帮你看。
- 人不行，本质是管理层有问题，业务都来不及做，排期有没有把CR和测试的时间排进去？重视测试就要拿出成本来，但也不要搞一刀切，同时要把有限的资源花在刀刃上。
- 可测试性和可观测性，要有视图，要能看到，这本质是架构师的责任，实现功能的同时，要保证功能被测试，能测试对性能的影响。不能测试推着开发和架构师做，本来是未雨绸缪的事情。
- 长期来看，质量越高，效率越高。效率高了，才能做质量保障工作。质量问题没有搞清楚之前不要搞业务。
- 压测怎么做？
- 压测是阿里做双十一用来保命的，是当时没有办法的办法，结果被其他公司以为是最佳实践。
- 在每一个环节都注重性能，当算法迭代后就做算法的压测，写完模块后就做模块的压测，每个节点都做容量的压测。
- 把性能的实践和工程，融入开发过程中。
- 同时也要留出保证代码安全的时间
- 总结来说，全链路压测是用来验证没有问题的，不是首要的工具。
- 测试和开发是分开的，测试是基于需求的功能进行测试。基于黑盒的角度去做。
- 关于代码评审：
- 写代码的类一定要加注释
- 要做好代码评审, 代码评审是讲解式的，给熟悉的人小批量多批次，但是太频繁的代码评审就是结对编程了。
- 10行代码，10个问题。代码太多反而没有问题。
- 老板喜欢什么样的人？这个问题的回答可以讲个故事，两个人，一个是SAP12年的工作经验，拿红包被裁员。另一个是从小学医，半路出家在日资做了1年测试。
- 群面面完之后老板们都倾向于医生，HR来找我问是不是私下有关系。
- 因为当我们问SAP的人，问原理的时候，答不上来工作原理，他大量的积累都来自工作时间的积累，同时知识结构有点老化，适应变化的能力是不足的。
- 我们问另一个年轻人，问内部细节的时候非常清楚，知道是哪个文件的哪几行，看了源代码，真正的吃透了，来龙去脉非常清楚，工作年限不是问题。他入职之后个人批下来两个美国专利
- 学会刨根问底，知道表面不够，要知道底层逻辑，知道问题和问题背后的底层原理
- 我很反对刷题，以前能靠算法识别人才，结果中等难度以上的题一上来就是最优解，那就不能算分。
- 要讲态度，但不能只找态度好的，也要找能干活的。
- 一万小时定律适合按部就班的，但架构师要不能循规蹈矩，要敢于创新。
- 领导要招两类人：聪明的人、比团队平均水平更高。这样才能让团队整体越来越好。
- 测试和测试开发不是一件事，代码写的好人太多了，技术栈全的人，我们人多的是。
- 测试需要的是思维能力，需要发散思维的能力，要把自己想成小学生，把自己放空去看问题，这对于测试能力很重要。跳出传统的思维的圈子去想问题，举几个脑力小体操：
- 俗话讲“坐“电梯，其实是”站“电梯
- 俗话讲”肉夹馍“，是”馍夹肉“
- 冰箱是个柜子，冰柜是个箱子
- 推荐《软件研发效能提升之美》。
- 可以看看linux的源码，面试造火箭，工作拧螺丝，是常态。
- 工作的基本要求是对业务知识要有沉淀，对场景有理解。
- 对于刚毕业学生的建议？
- 可以去选你喜欢的方向，刚毕业不要钉死，不知道哪个适合，那就多试试
- 多尝试，10年之后再沉淀，1个领域里很前，然后成为交叉的人才
- 前端的工程化太快了，3年换一批东西。
- 推荐在极客时间听课程，可以只听音频。
