? ? ? 测试，是一件偏执又克制的事。绝大多数测试项目需要在追求质量与提高速度之间撕扯，如果把时间轴拉长，自信的说，所有测试项目的历程都是努力追求测试三角形平衡的历程。
? ? 以web services的测试策略为例，技术应用在近十年里不断发展和演变。如今，业界普遍认为，API层或者基于web services的测试自动化程度最高。但实际上真的如此吗？
? ? 现实场景中，WS测试是分层测试的一种，其核心目标是为交付功能服务的。那么，测试团队始终需要思考的，是对测试开发的投入边界问题，即整体投入要符合deliver feature的预期，包括时间预期、质量预期和成本预期。
? ? 2017年前后，我所在的技术团队启动了WS应用，产品架构从传统的BS结构升级为数据-服务-展示的分层结构。测试团队随着开始建立针对web services的测试解决方案。在第一期版本上线时，整个研发团队需要在比较短的时间里，完成基础架构的升级。也就意味着，这是一个时间成本权重很大的测试项目。
? ? 同时，可以评估资源投入。那时的测试团队第一次接触web services测试，自动化技术经验不足，也没有积累足够的测试场景。如果要追求高质量的测试服务，会带来学习曲线陡增的风险。
? ? 因此，在初期的技术选型时，团队选择了一款商业工具SoapUI进行自动化的搭建。保证在合理的时间内快速完成release上线，彼时的AT投入非常节制。
? ? SoapUI当然不是一个完美的测试方案。团队服务的产品特性决定了API测试的难点。比如，如果WS返回值经过计算，SoapUI中的配置功能无法解决预期结果的动态查询；测试环境包含多个数据库，测试脚本与测试数据结偶困难；schema不标准化导致测试用例不能通过，等等。
? ? 但购买商业软件，给团队赢得了至少一个license周期的时间完善和加强web service测试。在此期间，测试团队关注了像smartbear, Tricentis等测试方案提供商；也通过技术交流去了解其他团队怎样做API测试；同时开始动手改造。
? ? 这个改造过程颇有些曲折，印象比较深刻的尝试有两个。一个是为了重点突破预期结果需要动态查询的难点，用Python写了一个测试框架。因为是纯脚本，每个脚本都可以自定义计算逻辑，或者指定数据库、表单的查询。方案听起来简单明了，对吧？并且这种检查性脚本编写、debug都不困难，很快自动化测试的覆盖率能追赶上SoapUI AT的水平。但随着版本迭代、测试场景的复杂性加强，这套方案的执行问题日益凸显。测试数据的更新颗粒度太细，维护回归测试脚本叠加新增功能的自动化，导致测试开发的投入有增无减等等。
? ? 另一个被放弃的尝试，核心思想是这样：虽然数据源是动态的，我们可以把测试所需的源数据快照下来，建立一个为测试存在的静态数据库。这个方案的失败之处在于对“测试”这个命题的解答过于执念，完全没有考虑到成本爆炸。单个测试用例所需的数据源快照集合到一起，测试环境中的相互引用，数据依赖等问题几乎无解。
? ? 时间走到2020年，整个web service测试方案才走向2.0的时代，能比较从容地应对各种测试场景和复杂案例。这套方案是一种混合方式，不需要复杂检查点的测试用例在postman上完成；通过开源工程，实现了schema validation，测试执行前可以预警schema的变化；同时开发了一个工具用于full-text compare，当检查点过于庞大或复杂时，用全文比较的方式来稳定保障测试点覆盖。
? ? 测试团队也放弃了把三套工具整合到一个测试平台的想法，因为虽然它们没有用一整套商用工具来得好看，但足够实用。最终web service的自动化测试覆盖率达到100%，并且自动化工具研究和开发的全职投入也全部退出。
? ? 回到今天有感而发的事情，测试不单纯追求高质量，有时要权衡利弊，有时要坦然放弃。永恒不变的，是要确保强大的交付能力，并强化事半功倍的团队能力。作为测试团队的领导者，更要关注其业务的关键决策条件，确保工作质量并及时完成。尽管遭受挫折，依然勇于直面挑战，从不气馁。