第 1 章 测试团队的发展之路
1.1 测试团队面临的困局
随着互联网的大规模发展、持续集成，以及 DevOps 等软件工程方法的提出和普及， 软件测试技术发生了很大的变化。自动化测试越来越普遍， 不再被认为是少数大公司才能 负担得起的“奢侈品”。敏捷测试（Agile Test）和左移（Shift-Left）等方法论被提出并广泛 应用于实践， 很多大学的计算机系都开设了软件测试的课程， 软件测试的价值、难度和发 展空间被人们充分了解， 测试团队和从业人员也得到越来越多的认可， 开发人员对测试技 术和测试团队有了更高的期待。与此同时， 测试团队面临着不少困难， 其中具有普遍性的有：
测试自动化难。自动化测试程序编写成本高、执行时间长、维护成本高。测试的 “技术债”在业务高速发展的过程中越积越多：一边修复老的用例， 另一边出现 新的失败用例；一边补充自动化， 另一边又因为项目的时间压力遗留了未自动化 的用例；一些可以自动化完成的功能、回归测试还得依赖手动测试， 效率低、问 题遗漏多。
测试结果的噪声大。回归测试的通过率比较低，每次回归测试都需要排查大量的 失败用例， 大部分的失败都是由于测试环境及相互干扰，而不是中间代码导致的， 测试人员难以获得成就感。另外， 测试结果的噪声多次导致回归测试已经发现的 问题在排查中被漏过，变成线上问题。
测试不充分。测试分析和用例枚举非常依赖测试人员的经验和业务领域知识， 新 入行的测试人员很容易出现测试遗漏。同时， 缺少有效的技术手段度量和提升测试的充分性。
测试人员对自身成长的焦虑。上述各种困局使得测试人员把大量时间花在各种琐 事上，没有时间和精力提升自身能力、追求技术创新，也缺少沉淀积累。
这些问题及其背后的原因往往互为因果，形成一个个“死结”，阻碍了测试团队以更少的时间、更少的人力、更少的资源，得到更好的结果，测试团队面临的困局可用图 1-1 表示。
图 1-1 测试团队面临的困局
我们针对上述问题做了很多技术创新，取得了不少成果， 并在实践中总结了一些经验和方法。
