一
作为
测试人员的基本要求，大家都知道，需要能接受频繁的重复劳动，也因此让很多人都理解为测试入门很容易，是呀，重复劳动嘛，只有我把第一遍搞会了，后面直接无脑操作就行了。
事实真的如此嘛？
对那些没有啥追求的测试人来说，这当然就够了，反正是混日子嘛，在哪不是混。
但是对于有追求的测试人员来说，当然是追求能力的提升，不满足于现状了。
那么要怎么提升呢？这就是我今天要说的重点，如何保持一直处在学习区。
二
大家都知道舒适区、学习区和恐慌区的概念。
舒适区，顾名思义，就是做这些事情自己手到擒来，没什么难度，比如传说中的点点点。
学习区，就是伸手或者垫脚才能够的着的，比如负责个小的新项目，比如写个批处理。
恐慌区，就是跳起来也够不着的，比如写一个自动化用例框架。
测试入门之所以被认为是简单，就是因为很容易就到达舒适区，点点点嘛，谁不会，谁点的多点的快，就谁厉害呗。
恐慌区对于不想跳出舒适区的人来说，一点都不恐慌，你牛你上呗，我搞不了我也不去想。
反而是那些比较上进的测试人员，经常对恐慌区望而兴叹，为嘛？跳起来都够不着，该咋办嘛。
解决办法就在学习区了。
学习区对成长型的人来说，保持的时间是最长的了，当然也最容易懈怠，因为达成学习目标后，就会掉回到舒适区了。
那么到底如何能保持一直处在学习区呢？
上次和朋友讨论这个问题时，我给了两个建议。
三
一个是保持好奇心。
保持好奇心也可以认为是一种归零心态，就是碰到什么问题，都要想着去把它搞明白，搞透彻，不接受模凌两可。
比如在一个项目中开发使用了 API RegisterClass 来实现一个具体的功能，按理说，已经知道了具体的 API 名称了，就已经到了分层理论中的第二层，逻辑层，很好了，但还是不够。
我们通过 MSDN 查看这个 API 的详细信息会发现这么一个提示「The RegisterClass function has been superseded by the RegisterClassEx function」，那么问题来了，既然是这样，为毛开发不用 RegisterClassEx 呢？
我们接着往下看文档说明，RegisterClass 应该是和 UnregisterClass 配套出现的，那么我们调用 UnregisterClass 的时机是在什么时候，是否会对功能造成潜在的影响？
文档后面没有其他有价值的信息了，但是上面两个问题搞明白的过程中，可能还会引申出更多的需要搞明白的问题，只有我们保持好奇心，才会去挖掘这些问题，而这些可以挖掘到，并且可以解决的问题，其实就是我们的学习区。
四
另一个是要不满足于现状。
这个不是鼓励大家跳槽的意思哈，是说做任何事都要追求把事情做得更好一点的精神。
比如有个项目只有一个人负责，所以需求、用例以及项目进度信息她都很清楚，即使没有文档
记录，也能保证这个项目的顺利进行，同时配合的开发也很好，提测说明都写的蛮清晰，按理说做这个项目就是一个舒适区的项目。
如果我们反过来想一想，给自己找点麻烦该如何呢？
1、文档部分。
尽快产品和开发都提供了简要的需求文档和提测说明，但都是他们自己角度的说明，肯定是包含关键部分的说明，我们是否需要从第三方的角度进行下复述，方便其他人查看这个项目信息时可以更好更快的理解呢？
尽管只有自己负责，其他人可能并不关心进度，但是时刻给自己高要求，保证项目记录的完备，特别是自己一个人负责的项目，如果自己有事不在，其他人需要回查信息时，完全就只能靠当初的项目记录来获取信息了。
2、用例部分。
尽管不需要用例，一个人也可以完成需求的测试覆盖，但是考虑长远点的话就会知道，好记性不如烂笔头，所以及时的完成用例，并汇总到用例集中还是很必要的。
同时，对于
测试用例深度和广度的覆盖，以及探索性测试用例的考虑，都可以进行完善和补充。
3、总结部分。
当一个项目真的简单到没有任何可以总结的地方时，就需要反思这种项目测试是否应该进行提效，比如利用
自动化测试，有人说，自动化成本太高，看，这又是一个新的问题了，继续想办法解决吧。
我们碰到的每一个问题，都是我们进步的机会。
看，只要使用高标准来要求自己，时刻提醒自己要做得「更好一点」，就会一直处于学习区，因为你关注的每一个地方，都有
Bug 等着被修复。
以上，你是否有对于学习区的困扰呢？你目前的解决办法是啥样的呢？欢迎留言把你的方法也分享给大家，如果觉得我提供的方法有用，也欢迎转发给更多人看到，或者点个「好看」让我知道你的态度。
