通过朋友帮助自学了一个月便开始进入了软件测试行业，因第一家公司是传统互联网典型的业务测试，每天需要做的就是点点点，每周一次发版，全站回归测试也是靠十几个测试人员的纯手工造数、检查。一重复就是三年，失去当初的工作激情，却发现只是熟悉了该领域内很小的那块业务，除此之外，测试本身的技能并无长进。接下来就是自学，参加线下的培训机构，想学习点真正有技术含量的东西，于是报名了性能测试培训班，从事两年性能测试后，发现公司专职专岗，给自己设限了，在测试技术广度上非常欠缺，但已然工作五年了只能通过自己学习，自我提升去快速地拓宽技术广度。
于是开始了漫漫的软件测试学习探索之路一直到今天，从未止步。也是我今天要分享的主题--持续学习，积极实践。通过不断学习与实践我总结出了以下一些测试工作中非常实用的最佳学习实践：
- 时间盒内，请勿打扰
- 持续挑战自我
- 最简单的TDD
- 风暴会议中我又GET到了新的缩略语
- 保持与时俱进
- 不跳槽也需要更新你的简历
- 用你喜欢的方式
- 我创建了实践社区
- 可视化白板
- 一路升值的知识库
- 独当一面
- 掌控你的职业发展
时间盒内，请勿打扰
无比投入地在重现一个至关重要的问题；刚刚萌生了一组新的测试想法LIST；测试过程在执行一个存储过程；焦急等待中...总在这些时间点，要开会了，开发人员过来说看不懂这个前置条件的描述，产品经理催促用户手册修订完了没。测试人员的工作中经常出现这种情况 。很多测试过程都是一组需要测试连续性的活动，而非随时可以被打断。否则再次进入状态需要浪费更多时间去完成。把自己每天的工作用时间盒来控制试试吧，你会发现惊喜。
类似于高效时间管理方法-番茄工作法，周计划完成后，拆分到每日任务。则基本的工作便可以确定下来，比如：今天主要做测试设计、回归测试、重现一个用户问题等，上午10-11点期间设定一个时间盒，提前处理好其他事务，并且告知他人请勿打扰。10点到后，立刻开始进入状态，如专注地重现问题，11点到时，即使没有重现出来，也要停下，整理思路，去设定另外一个时间盒来继续，因此时再继续效率也会低很多。同时很多沟通也待处理。通常，一个时间盒设定最好在半小时到两小时之间最为适合。时间盒设定结束也是对一些事务的及时止损。
持续挑战自我
没有挑战，便不会进步。每月给自己一个小目标，每季度一个大目标； 比如，从纯手工测试到专项测试的转型中，需要学习非常多的其他领域的知识，如果分开实行，便会感觉轻松不少，而每个小阶段的挑战成功，会为自己的学习之路增添更多自信心。从而达成在良性循环，积极暗示。
最简单的TDD
TDD，即 测试驱动开发（全名为：Test-Driven Development），TDD是敏捷方法中的一项核心实践，其原理是在开发功能代码之前，先编写单元测试用例代码，对要编写的函数或类明确测试方法后，再进行设计与编码。通常中小型项目不会使用，目前也是少数的大公司会有专职的流程。
但其原理与方法论非常值得借鉴，也就是我们通常说的测试先行。很多测试人员在执行测试阶段时会发现与开发人员对产品设计的理解还有偏差，但此时开发人员已交付了测试版本。即使产品经理介入，无论是要重构代码还是修改用户体验设计，都会投入更大的成本。
建议方法：开发阶段中测试人员优先输出冒烟测试用例，评审通过后开发人员根据冒烟CASE来做代码详细设计。这样在早期会扼杀掉流程问题。
风暴会议中我又GET到了新的缩略语
经常参加公司组织的各种研讨会议，听到新的缩略语、专业术语或最新的工具赶快拿小本本记录下来，下班后搜索补充并查阅资料放在自己的测试知识小库中。时时刻刻不要忘记更新你的思维导图与知识库。
保持与时俱进
其实并不需要参加昂贵的技术会议，平时多留心，积极心态，便会发现处处是机会。如果在一线城市的话很多大公司会有开源工具的分享发布会、无定期的技术沙龙、新产品的灰度发布用户测试招募，以及可以参与到当地的测试社区，学习别人优秀思想的同时也别忘了贡献自己的力量，养成总结的习惯，你的各种技能都会与日俱增。当然，参加外部的活动都会在广度上增长，如果想深入还是要靠自己钻研。
不跳槽也需要更新你的简历
养成每三个月至少更新一次简历的习惯，这并不是让你去准备跳槽（当然能有时刻准备的心态更好）而是每三个月为一个阶段，是否又能为简历贡献点UP的新资源，是否在专业领域内又有了建设。包括你的技能树也要同时更新。如果发现近三个月来根本没有更新资源，看看是工作出了问题还是自己已经倒退了，不进则退，危机感会让我们前行。
用你喜欢的方式
不用羡慕别人的生活方式，所以学习方式也一样。找到自己最喜欢的即好。没有必要跟同学一泡一天图书馆，即使在那坐着心已飞向远方，可以喜欢咖啡厅、傍晚或早晨的公园、周末的山上，或听、或看书籍、或浏览视频，保证是在自己精力最充沛的时间，只要是自己喜欢的就去学习吧，相信用自己喜欢的方式会事半功倍 。
我创建了实践社区
工作五年时带了7人的团队，公司还有其他的业务部所以测试人员也比较集中，经常在午餐时间会有测试人员讨论问题，抱怨某些地方的流程不规范，或是经常有冲突，几乎每个中午都会听到这样的话题，当然也包括新技术的讨论，某些测试对新框架的分享等 。于是灵机一动，我创建了一个测试实践社区，当时还是一个比较简陋的WIKI,后来我们内部开发了一个。开始时只有测试人员注册，于是每日中午的话题统统搬到了内部实践社区上，而且还发现很多平时不喜欢发言的测试人员也能参与到其中了。慢慢地，测试人员的吐槽社区逐渐发扬光大，变成了测试问题的解决方案平台，当时还创建了一个版块，叫常见问题。把大概率的问题封装成了Q&A。同时吸引了项目组其他团队的成员，产品、开发 项目经理 业务人员，后来已发展成了公司内部的社区。
第一个测试实践社区的创立，激发了我对测试这个领域的更多思想创造力，它不仅仅解决了一些技术性的问题，同时也是一个学习力、创建力的集合，如何学习解决问题远比解决问题本身更有意义。
可视化白板
建议测试团队有自己的白板，起初我们团队是TAPD的看板最佳实践团队，但后来还是使用了真正的白板，你可以作任何运用，只要是能让团队成员一目了然的东西都放上去。同时还可以征集其他成员的意见，不断补充，不断迭代。如用便笺展示出你的测试计划，项目经理最关心的； 把缺陷严重排列出来，与业务人员和产品经理讨论最终的修复优先级等等。动态调整，你的可视化白板，会至少节约20%的沟通成本 。