版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
测试定位篇·你不是研发的附属品
神明也会犯错
曾几何时，我还是一个测试小白的时候，眼里的研发个个熠熠发光，有如神明一般。
对于研发大神的安排和指挥，我无不如圣旨般极力奉行。
然而，大神所指的“明路”，也不尽然正确，尤如上帝也会犯错，每每引发线上的事故。
当如此的剧本，不断上演…
疑惑、担心、内心的不安…无时无刻不在困扰着我，尤其到上（shao）线(xiang)的日子，更是越发的强烈。
我开始怀疑自己、怀疑我信奉的大神…到底如何，才能把工作做到最好，才能放心的上线?
测试的处境
- 是否你在团队内一直没有话语权，说的话没有人表示赞同，你越来越不想表达什么？
- 是否你的测试工作都由研发来给圈定范围，测试的内容是否都由研发来指导？
- 是否你提交的BUG，每每被开发给否定后，你都默默的关掉？
- 是否你觉得自己能力得不到认可，觉得你在团队里可有可无？
- 是否你越来越怀疑自己，怀疑测试职位本身？
- …
如果，你现在确实如此。 那么，请不要再怀疑了，你应该试着去改变这一切。让自己处于主导地位，与其被动的接锅，不如主动来承担，用自己的提升，来改变目前的现状。
那么，如何做才能改变目前的现状呢？我这里给大家一些意见和建议，或许会帮到你。
试着去改变
在产品的各个阶段，作为测试的你应该做什么呢？
- 产品规划阶段：
也可以理解为产品概念期，由于目前互联网行业的现状，所谓互联网一大抄。测试人员，在此过程中，可以结合自己使用各种产品的体验，自己作为测试人员对于产品的缺陷的敏锐嗅觉，从一个更高的角度对产品的规划提出自己的想法，更好的帮助产品取得成功。 - 需求阶段：
需求评审：测试人员开始做需求阶段的缺陷预防，保证需求是能够满足用户的原始需求，并且整个需求都是非常清晰和合理的，版本后期没有需求不合理或者需求不清晰的问题。 - 设计阶段：
测试人员开始做设计阶段的缺陷预防，能够对于研发的整个设计方案非常清楚，能够根据研发设计文档里面的业务逻辑图，自己能够站在测试的角度来画出一份让测试人员更加容易理解的业务逻辑图，并且能够发现研发在设计方案上存在的一些问题，并且指导研发进行修改。
此处有两点要说明一下：
1）业务设计的缺陷，这个可以结合自己对于产品和业务的理解，来发现相应的设计缺陷。
2）架构和代码设计缺陷，这个就需要自己在工作和学习中，不断的提升自己架构和代码的能力才能达到。 - 编码阶段：
单元测试
接口测试用例
自动化测试用例
测试工具的开发
架构设计评审
代码评审
推动代码可测性
并且开始思考后面如何去更好的测试（更高的效率，更好的保证质量），并且帮助研发提前做好编码阶段的缺陷预防，甚至做到测试驱动开发。 - 测试阶段：
制定测试策略
测试环境准备
测试计划
确定专项测试内容
执行测试用例发现和定位bug、跟踪和回归bug，质量分析，有效的探索性测试等等，目的是花更短的时间来更好的保证质量。 - 上线阶段：
确定发布策略
确定回滚策略
确定监控方案
能灰度尽量灰度、能分批发布尽量分批发布，减少上线影响。上线后的回归，上线后的业务监控、数据分析，保证上线的稳定性。
如果你的测试工作，只做了测试阶段的内容。那么，我推荐你可以试着去参与到更多的阶段中去，提升自己的能力来达到让自己参与到其中并能有所帮助。在此过程中，我相信：你会不断的肯定自己，不断的被他人肯定。
那么，我确信：你将成长为团队的核心成员，你们的团队将会彼此成就，共同成长~ 加油！！！
本系列文章将从：成长、经验、技能、思虑等各方面，讲述个人的一些见解，希望能给大家些许的帮助。谢谢