测试人画像
测试是贯穿项目全程的，所以测试不管实际有没有走到这些流程节点，测试都可能需要拥有那么些能力和认知的。
1.业务抽象能力
若对业务有个深刻的思考，对市场环境要有所广面的了解，才可以拥有较准确的抽象能力，将业务场景抽象为一个个具化场景或功能来满足业务，项目是否靠谱，是需要大量的佐证去证明，脑洞大开的点子感觉再好也得需要经受的住推敲。
2.产品细化能力
对业务产品细化能力，大脑中要不停的模拟构建用户的每一次输入、点击、删除、登录、跳转、返回、切换、关闭、滑动等等，形成操作流是否可以大概率引导用户走近我们大家的预期，需求的脑容量看起来挺大，所以需要测试的耐心、细致、严谨、纯粹（当然不是修仙），此时多费脑子，上线时候就少很多返工、废弃项目等让人头疼和无语的情况；
插播一个小故事：
传说有个科学家做了个实验，抽取了30个一点没有篮球基础的人，均分为3组。第一组：自由练习真实投篮；第二组：只在大脑中不停的模拟标准投篮，不做任何真实练习；第三组：进行真实的标准投篮练习。在练习相同时间后，统一进行投篮测试命中率，结果：第一组36%，第二组74%，第三组83%。
由此可见：大脑构建的回报率其实很高且值得的。
3.需求分析能力
分析出需求表达的需求诉求和业务逻辑，不断的推敲真实和隐藏的诉求是否全部get（需求覆盖率），业务逻辑是否全部行程闭环。
需求分析就是在构建测试方案和用例的铺垫。
4.测试方案以及测试用例
测试方案
可能很初入入行业（我当时也这样），对于这种战略性的工作一直觉得没什么大用，实则不然，方案的制定其实是在构建测试的框架，这个工作目的是什么，最合适的切入点是什么等等，从而能更准确的把控测试细度以及范围，减少测试频繁陷入无休止（变化-分析-修改）的局部死循环和避免需求蔓延风险。
测试用例
每个测试工作者的重中之重，没有写一个好用例的测试绝对车祸不断，测试用例的编辑其实是在将业务需求逻辑真正的和代码实现逻辑靠拢的节点。此时，开始在用代码实现系统，而测试呢，也是在用测试用例的每一个case把系统构建起来，这样测试用例评审通过，是拿着测试用例、需求文档、开发实现的系统，三方做一个比较验证，发现不同点则要定位是需求、测试用例还是代码实现方面的问题，确定一方再逐步的深入定位和修正。
5.测试执行以及测试报告
第4点其实已经将测试执行过程说清楚了，这里就不在累赘了（中心思想：有条不紊，严格执行，积极维护），测试报告，这个是项目是否成功的毕业证书，测试报告的含金量有多少，就要看测试对于整体项目过程、系统实现和需求目的的满足以及匹配程度等的分析能力
6.项目全程质量管，防，控
管理-预防-控制，三者一体，相互融合，相辅相成
永远不要认为，可以用足够严谨的手段和策略避免bug的存在，bug就像误差，只能减少，不可能消除。
管理-需求、开发实现、测试构建，在项目各个阶段，三方都是处于微调状态，要做好管理和协同，做好合理流程化和轨迹管理和分析，来满足项目的增、删、改、恢复、延期等状况（比如bug管理、用例管理、需求管理、代码管理等）。
预防-测试介入越早，对系统构建越早，就会越早发现问题，从而会以相对最小代价完善。
控制-测试要明确项目背景，需求目的，测试范围，全力避免需求蔓延、开发实现奔溃、测试范围边界和标准模糊等情况。
7.项目积累
项目成功后，要形成项目执行里程碑点的成果物，这些都是财富。1）便于新人学习和快速上手；2）便于问题历史追溯；3）便于复盘总结。
测试人心态
客观：测试需要始终处于独立的思维逻辑中，不能被产品或开发带入到他们的可能错误的逻辑闭环中，客观抛出风险和积极协调风控处理方案。
质疑：测试敢于抛出自己的想法，从而和产品或开发的想法进行一个融合和互补。
认同：测试要海纳百川，融会贯通，乐于接纳外界的不同想法，丰富和完善自己的想法，才能雕刻出更好的系统，才能更好的满足最终用户诉求的服务能力。
成熟的测试人