大家好，我是rainbowzhou。
今天下午，我有幸参加了由Testops举办的测试运维MeetUp的沙龙活动，收获颇丰。沙龙邀请了三位业内资深的专家，分别从不同的角度和层面，分享了他们在测试领域的实践经验和心得体会。
首先，老张以《测试环境的稳定性治理》为题，深入浅出地讲解了测试环境治理的重要性和方法。测试环境是软件质量保障的基础，如果测试环境不稳定，不仅会影响测试效率和效果，还会导致测试结果不可信，甚至引发生产环境的故障。因此，测试环境需要进行有效的治理，以保证其可用性、一致性、可控性和可复用性。老张结合自己所在项目的实际案例，介绍了测试环境稳定性治理面临的挑战和应对方法，包括：
- 环境太多：服务容器化，降低硬件成本和部署时间
- 流程不严谨：变更权限权限收口，减少无效变更和回滚；
- 时间紧任务重：变更发布需要流程规范严格执行，避免人为失误和冲突；
- 多数据源的悖论：数据治理打通底层数据，请求标记和逻辑区分，影子库或影子表。
老张还分享了一些测试环境稳定性治理的小技巧，如服务不可用订阅、上线通知、接入日志平台、定期召开复盘会、定义相关指标等。他还强调了测试环境稳定性治理对质量保障工作的价值，如提高测试质量和效率、降低测试成本和风险、增强测试信心和满意度等。给我留下了深刻的印象，并让我感悟到：作为测试人员，要突出自己的价值，要能推动项目和公司向前发展。
接着，单东东老师分享了《持续交付下的分层自动化实践》，从理论到实践，全面阐述了分层自动化在持续交付中的作用和实现方式。他认为，持续交付是敏捷开发的核心目标之一，要实现持续交付，就需要快速反馈软件质量和功能状态，而分层自动化是快速反馈的有效手段。单东东老师根据自己多年的自动化经验，总结了分层自动化的最佳实践原则和方法论，并结合Devops平台的功能模块，演示了如何构建一个高效、可靠、易维护的分层自动化框架。
他还从精益思想的角度，重新解读了测试金字塔模型，并建议测试与开发保持相同的技术栈，以便更好地理解代码实现逻辑和覆盖测试场景。他让我对分层自动化有了新的认识和启发，并让我感悟到：作为测试人员，要不断学习新知识、新技术、新方法，要敢于尝试新角色、新领域、新项目，要善于解决问题、创造价值、提升影响力。
最后，云层老师以《从测试到架构师到敏捷教练》为题，回顾了自己几十年的职业生涯，分享了自己在不同阶段遇到的挑战和机遇，以及自己在知识、技能、思维等方面的认知变化和成长。有兴趣的同学，可以了解一下邓肯-克鲁格效应。他告诉我们，在职业发展中，要明白自己是谁、自己要做什么、自己想得到什么，要逻辑自洽，构建解决问题的整体视角，构建自己的护城河，从平台、项目、业务着手。他还抛出了一个有趣的问题：如何做好自动化测试的ROI？我的回答是：做好自动化测试的ROI，需要在以下几个方面做出合理的规划和优化：
- 选择合适的自动化工具，要考虑工具的功能、性能、兼容性、易用性、可扩展性、可维护性等方面，以及工具的价格和支持服务。（采购软件还是自研，购买测试平台未尝不可，该花的钱别省）
- 选择合适的自动化范围，要考虑测试用例的重要性、稳定性、复杂度、频率等方面，以及应用程序的变更频率和风险程度。一般来说，应该优先自动化那些高风险、高频率、低复杂度、稳定不变的核心功能测试用例。
- 选择合适的自动化时机，要考虑项目的周期、进度、资源等方面，以及应用程序的开发模式和交付方式。一般来说，应该在应用程序相对稳定后再开始自动化，以避免频繁修改脚本。同时，应该尽早介入自动化测试，并将其集成到持续集成和部署流程中，以提高效率和质量。
- 选择合适的自动化方法，要考虑测试用例的设计原则、编码规范、数据管理、异常处理、日志记录、报告生成等方面，以提高脚本的可读性、可复用性、可维护性和可扩展性。
- 选择合适的自动化指标，要考虑测试用例的覆盖率、执行率、通过率等方面，以及缺陷发现率、缺陷修复率等方面，以评估自动化测试的效果和价值。
让我对职业发展有了新的思考和规划，并让我感悟到：作为测试人员，要找到适合自己和团队的平衡点，在规范与创新之间，在计划与变化之间，在协作与竞争之间，在效率与质量之间，在满足与超越之间做出合理的取舍和调整。
沙龙活动在轻松愉快的氛围中结束，但对我来说，这只是一个开始。除了三位老师的精彩分享外，我还参与了一个有趣的收尾项目：乐高城市沙盘。我们进行了两个主题的沙盘演练，一个是搭建一条跨度为50cm、可承重的桥，另一个是规划一个50X50的城市商圈。在这个过程中，我体验了软件交付与城市建设之间的相似性和差异性，感受了敏捷与规范之间的平衡。我也发现了自己和团队的一些问题和不足，如没有对需求进行二次确认，没有预留测试时间，没有合理设计和规划每个Sprint的期望和效果等。这让我意识到了，在追求敏捷开发的过程中，也要有相应的规范标准，这样才能使两者平衡，发挥工程化思想的优势。
