软件测试到底是个啥？
入行前，你一定问过这个问题。
入行后，你也一定因为这个问题而迷惑。
因为你对软件测试的定义决定了你对自己应该做什么的定位。
也正因为随着你在工作中的经验增长，你的认知也在不断增长，每一次修正你的认知，你都会上升一个台阶。
那么，软件测试到底是个啥？
与其直接写我的答案，还不如我们一起来看看这个寻找的过程，我认为，在这个过程中，你获得的收获可能会更多。我的答案当然不是唯一正确的答案，它甚至都很难称得上正确，只有你自己给自己寻找到的那个答案，才是属于你的正确答案。
那么，让我们开始探索之旅。
当我们想知道一个人到底怎么样的时候，我们会怎么做？我们会找到这个人，认识这个人，和这个人相处一段时间。但是这样我们还是会看走眼，因为他可能是装的，也可能偶然走错了路。为了更深入的了解他，我们一般会去了解这个人的历史，从时间维度扩展我们的认识；我们也会多找一些和他接触过的人，看看别人眼中的他是什么样；再后来，我们也会安排一些极端情况，看看在这些情况下，这个人到底会如何表现。
软件测试就是这么一个人，让我们一起认识认识他。
2000年左右，软件测试开始在中国大陆流行。而在此之前，它已经有了几十年的历史。最初的软件测试很土，就是开发人员自己看看自己的代码行不行。后来分化出来一群专职的软件测试人员。2005年软件测试外包火了起来；2010年大家仿佛一夜之间都开始关注自动化测试，同时，敏捷开发的流行也让测试管理变得复杂；2015年以后，自动化测试也好，敏捷测试也好，已经有了大量成熟的框架和实践让大家参考和使用，那一年我记得几家大公司相继辞退了自己的功能测试团队。
这个简史实在是够简洁。从测试的编年史上我们能够看出来什么呢？测试的发展趋势正在逐步的从技术视角转向业务视角。
2005年的软件测试什么样？测试人员是专业的、技术的。你给我需求，我按照需求测试软件，发现缺陷记录缺陷，然后和开发人员沟通。测试用例的编写使用正交法最多，那时候对一个好的测试人员的评价就是，“发现bug特别多”。安全测试领域到现在评价一个专家还用发现bug的快慢和多少来衡量，你可以从这个新兴的领域窥见当年的影子。
2010年的软件测试又是什么样？测试人员被塞进敏捷团队，一般都是SCRUM。敏捷团队的特点是小步快跑，高速迭代带来的就是需求描述极度简洁，测试人员被迫接受很烂的需求文档，与需求工程师和开发工程师更频繁、更剧烈的冲突。甚至部分团队出现了开发主导测试范围和测试进度的情况，测试丧失了主动权。
2015年以后的软件测试又是什么样？敏捷的概念被弱化了，是否敏捷已经不是政治正确，而是变成了依据项目特点做出的选择。前后场逐步分离，在前场，产品驱动的理念给开发和测试都带来了崭新的挑战，测试管理转变为矩阵化管理，决定了测试人员工作范围和节奏的是一个个业务单元。与其说测试拥有了更高的灵活性，不如说测试人员逐步融入了业务团队，随着业务的指挥棒翩翩起舞。在后场，专业的测试团队将注意力更多的集中在提供灵活的工具和平台上，他们的角色从管理者变成了支持者。由前场拉动后场，由业务主导而非技术主导，是这个时期的特点。
在今天这个时代，掌握话语权的不再是测试技术专家，而是懂业务的测试人员。PMO（项目管理办公室，在某些组织内是质量保证团队）面对测试人员振振有词的“时间不等人”也只能做出让步，允许脏上线，以抢占市场。
测试总监们虽然名义上拥有测试团队的管理权和部分考核权，但是面对前方多变的业务形势，也只能放任测试人员自行判断何种测试策略是最适合的。
自动化测试平台的设计者们更加尴尬，他们面对的是搞出一个高大全的平台结果没人用的窘境。
请问这个平台适合做什么？
你想用它做什么都行！
类似的对话偶尔发生在前端测试负责人和后端平台设计者之间。设计者不懂业务，不了解前端想要什么，因此做出来的平台顾此失彼，空有通用性和理论正确，却无法支持一个业务单元的回归测试。
- “开发总是看不起我们”
- “到底这是不是个bug？”
- “我提了好多bug，没修就上线了”
- “明明你们都参加了评审，出了事故为啥都怪我？”
- “需求太烂了，啥也没说清楚”
- “就给一天时间？够干啥的？又要加班！”
作为一个测试工程师，你是否也有这些困惑？
- “开发经理太难沟通，就知道甩锅”
- “破系统太不靠谱了，总出事故”
- “又要马儿跑，又要马儿不吃草”
- “这活儿没完没了，想整理点儿文档都没时间”
- “给我30%的绩效考核权有个屁用，谁都不听我的”
作为测试经理/总监，你是否也有这些困惑？