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