此文只给初入职场的测试小白一点点小小的建议，大佬们请绕行~
前言：
初入测试行业的小白们，可能当前都在从事业务测试，也就是点点点，大都对测试行业抱有一丝丝的幻想和憧憬，都想着有一天成为业务专家或者测开大牛，但是千里之行始于足下，只有一步一个脚印的实践，去学习才能到达目的地。
正题：
不论是何原因，踏上了测试之路，就注定要一直不断的充实自己，测试目前在企业中，尤其是大厂，受重视的程度也在增加，测试的资源也在不断的丰富，给有理想的小伙伴们充分发挥自己聪明才智的机会。
测试，做好了不比开发差！小白们，一定要给自己信心，不要在意当下工资是不是比开发少，但是当你成长为测试专家或者成长为你所在的业务领域的业务专家，薪资方面一定不会比开发差！
所以初入测试，一定要把基础打扎实了，才能更好的为以后的发展奠定良好的基础，学习没有捷径可严，只有不断的探索前进！
接下来，说一说测试的流程，不论你在什么公司，测试流程都大同小异，无非就是：需求评审—>根据需求编写测试用—>测试用例评审—>执行测试用例—>发现问题—>提出问题—>待开发修改后回归问题—>上线前回归—>上线后回归等几大部分。
说到需求分析，一般都是由产品经理画好原型图或者写好需求文档，会叫上相关的开发负责人和测试负责人组会。需求分析会，是整个测试周期的开始，清晰明确的需求会决定后面开发以及测试的进度和质量，所以小白们一定要认真听，好好分析需求。
这里有这么几点需要注意：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。
无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：每项需求的制定都是必要的且能够追溯的。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。
以上就是小白们在听需求评审的时候要注意的点（后面如果想到，会再补充），当然需求评审是枯燥的，见识了好多人需求评审的时候都是玩手机，事后呢再找产品经理去问，这时候效率会有所落后。听好需求，对自己测试有很大的帮助，如果你不能很好的理解需求，那你又怎么能测试好这个需求呢？
为什么重视需求评审，并且在需求阶段需要测试参与并指出需求中的漏洞，因为在需求阶段发现问题，需要修改的成本最低，举个例子，如图所示：各个阶段发现bug所需的成本。
所以说需求评审阶段至关重要！
一个好的测试，哪怕不会代码，做到了业务测试的专家，也是很牛*的存在，这个时候，就是几乎就是一个项目经理的角色了，比产品懂技术，比开发懂业务，hold全流程，可以给其他人提出你的经验和意见。怼的了开发，骂的了产品（骂人不对的）
后记：
一步一个脚印，扎扎实实的稳步前进，不要三天打鱼两天晒网 ，要给自己定个阶段性的目标，每天朝着目标进步一点点，加油未来的大牛！