【讨论】“可自动化性”是否与“产品自身的可维护性”存在强耦合关系。

dumpling_1998

产品自身在可维护性架构上过于单薄，架构师和开发人员在产品设计之初完全没有基于可测性的架构和开发，以至于偌大的产品发展到现在连个软件平台的承载层面都没有。在这个现状下，感觉自动化的架构实现过于困难，甚至都难以找到一个稳定的接口用于确定自动化的测试边界。即便勉强做出来，可复用性和可移植性也太差，后期维护成本可以预见的会非常高，投入产出比将相当不划算。

大家怎么看这个问题呢？

yunzhong134679

同意你的看法，自动化的架构需要考虑产品的匹配程度以及可继承性。自动化成本和卖车一样，用的“卖的”越多，成本越低

yunzhong134679

赞同，自动化设计需要结合产品本身特点来开发，并且要考虑可重复性，自动化运行和卖车一样，利用率（车卖的多）越高，成本越低

sdyl1317

如果当前架构过于单薄，可能需要考虑进行架构重构。虽然这需要一定的时间和资源，但长远来看会减少维护成本并提高系统的灵活性。

sdyl1317

如果当前架构过于单薄，可能需要考虑进行架构重构。虽然这需要一定的时间和资源，但长远来看会减少维护成本并提高系统的灵活性。

karlzala

这个问题是产品开发团队或产品运作团队的决策问题导致的。
因为前期开发成本过高，或架构老旧。既不能抛弃当前架构，又难以在当前架构上开发新的自动化平台。
个人建议，早死早超生，切平台才是正道理。

lsekfe

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

复制代码