【讨论】“可自动化性”是否与“产品自身的可维护性”存在强耦合关系。 - 51Testing软件测试论坛

这是一个在软件开发中相当棘手的问题，以下是一些看法：
从根源分析角度
- **前期规划缺失问题**：在产品设计之初，架构师和开发人员没有考虑可测性和可维护性，这反映出在项目启动阶段缺乏全面的规划。软件开发不仅仅是实现功能，可维护性和可测性应该是架构设计的核心要素之一。例如，在设计数据库架构时，如果没有考虑到未来数据量增长后的维护难度，如查询效率的优化、数据备份与恢复的便捷性等，就会导致后期的困境。对于这种情况，团队应该进行一次全面的架构复盘，梳理出当前架构中不利于维护和测试的关键节点。
- **对产品发展预期不足**：没有规划软件平台承载层面，说明对产品的发展规模和复杂性估计严重不足。当产品规模扩大时，没有合适的平台承载，就像没有地基的高楼，摇摇欲坠。开发团队可能需要重新审视产品的业务逻辑和发展方向，预测未来可能的功能扩展和规模增长，为构建合适的平台承载层提供依据。
### 关于自动化测试困境
- **自动化测试边界问题**：找不到稳定接口确定自动化测试边界，是由于前期架构设计未考虑测试便利性导致的直接后果。在这种情况下，可以尝试从业务逻辑入手，先确定核心业务流程，通过分析这些流程中相对稳定的交互点来初步界定测试边界。同时，可以利用一些动态分析工具，在产品运行过程中监测数据的流动和系统的调用关系，辅助确定可能的测试接口。
- **复用性和移植性差的问题**：这是架构不合理导致的深层次问题。解决这个问题可能需要对现有代码进行重构，但这是一个高风险、高成本的过程。可以考虑逐步引入设计模式，将一些功能模块进行解耦，提高其独立性，从而在一定程度上改善复用性。对于移植性，可以通过抽象层的设计，将与特定环境相关的代码封装起来，以便在不同环境下更容易调整。
### 成本效益考量
- **投入产出比分析**：目前来看，强行推进自动化测试可能确实导致成本过高。但如果完全放弃自动化，随着产品的持续发展，人工测试的成本也会急剧上升。可以考虑分阶段实施自动化测试，先针对最核心、最稳定的业务功能进行自动化改造，逐步建立起自动化测试体系，在降低风险的同时，逐步提高自动化程度，平衡投入产出比。同时，要与利益相关者充分沟通，让他们理解这种权衡的必要性和潜在的长期收益。

复制代码