接手一个没文档的老系统,从哪里开始测?

接手一个没文档的老系统，从哪里开始测？

没有需求文档，没有设计文档，没有接口文档——前任测试离职了，只留下一句“你看着测吧”。别慌，按这个思路来，一周之内你就能把这个系统摸透。

为什么老系统让人头大

新系统有PRD、有接口文档、有原型图，你知道什么是对什么是错。老系统什么都没有——你不知道这个按钮点了应该弹什么，不知道这个字段填错了应该报什么提示，不知道哪个功能是核心流程哪个是边角料。

老系统的测试难点不在技术，而在信息缺失。你不知道“正确行为”是什么，所以无法判断“是不是Bug”。

这篇文章给一套系统化的探索思路。核心原则是：先搞清楚系统做了什么，再搞清楚怎么测，最后才动手测。

别急着看代码、看数据库。先把系统跑起来，用一遍。

注册一个全新账号，从头到尾走一遍核心流程：作为一个新用户，你能做哪些操作？注册、登录、设置个人信息、使用核心功能、退出。这一步是为了建立对系统的整体印象——这是一个做什么的系统。

用已有数据的账号再走一遍：找一个有历史数据的账号（订单记录、操作日志、历史消息），看老用户看到的页面和新用户有什么不同。

把所有菜单都点一遍：左侧导航、顶部Tab、右下角悬浮按钮——能点的都点。这一步会发现很多隐藏功能，也可能发现一些已经失效的入口。

产出：一张系统功能脑图。不用画得很好看，能帮你自己理清系统有哪些模块、每个模块有哪些功能就行。

点完所有页面后，你应该能判断这个系统的核心业务是什么了。

如何判断：用户最频繁操作的功能、出问题后影响最大的功能、收入直接依赖的功能——这些都是核心。电商是下单支付，OA是审批流转，CRM是客户管理。如果还是不确定，去问产品经理或者看用户反馈，他们最清楚什么功能最重要。

画出核心流程图：从用户进入系统到完成一个完整的业务操作，中间经过哪些步骤、涉及哪些角色。比如电商下单流程——用户浏览商品→加入购物车→提交订单→支付→商家发货→用户收货。每一步涉及哪些页面、哪些接口。

非核心功能先放一边：用户头像修改、个人签名编辑——这些是边缘功能。优先级排序是核心流程P0、主要功能P1、边缘功能P2。没有文档的情况下，先把精力放在P0和P1上。

老系统没有接口文档，但接口就在那里。

打开浏览器F12，切换到Network面板，操作一遍核心流程：每做一步操作，看发了哪些请求。请求方式是什么、URL是什么、传了什么参数、返回了什么数据。这些就是你现成的接口文档。

找后端代码中的接口定义：如果你有代码权限，搜Controller、Router、Handler这些关键词，能找到所有接口的定义。有些代码框架（如Spring Boot的@RequestMapping、Express的app.get）会明确标注接口路径和参数。

摸清数据库结构：连上数据库，看有哪些表。SHOW TABLES列出所有表，DESC <表名>看字段结构。核心表通常命名比较规范：users、orders、products。如果表名和字段名有注释那就更好了，没有就通过字段名和已有数据来推测含义。

产出：一份接口列表（至少包括核心流程涉及的接口），以及核心表的结构说明。

用Postman或curl逐个调核心接口。先调GET接口看返回数据，确认数据结构是否符合你的理解。再调POST/PUT接口看能否成功创建或修改数据。

这一步最容易发现“假设错误”：你从页面流程中推断接口A返回的数据中status=1代表“已支付”。实际上查了更多数据后才发现status=2才是“已支付”，status=1是“待支付”。你的假设被数据纠正了。

对接口做边界值测试：不传参数、传空值、传超长值、传特殊字符。看接口返回什么。这些测试会暴露系统的容错能力和异常处理情况。如果接口因为空值崩溃了，说明这里没有做校验——这就是Bug。

整理测试用例：根据前四步对系统的理解，为每个核心功能编写用例。重点覆盖正常流程和关键异常场景。不需要一上来就覆盖所有边界情况。先保证核心流程跑通，再慢慢补全。

建一套独立的测试数据：不要用生产数据。自己造一套测试数据，包括测试账号、测试订单、测试商品。这套数据不会受其他人影响，你的测试结果可反复验证。

做一次完整回归：用你的测试用例和测试数据，把核心流程完整跑一遍。记录所有通过和未通过的用例。这次回归的结果就是你和系统的“信任基线”——以后每次发版都以此为参照。

前面五步让你能开始工作。但真正把一个老系统吃透，需要持续积累。

记录你遇到的坑：哪些功能看起来正常但其实有问题？哪些接口的行为和页面展示不一致？哪些代码模块Bug特别多？记录下来，这是后续测试的重要参考。

补充缺失的文档：根据你实际测试中积累的经验，逐步补齐接口文档、数据字典、测试用例。这些文档不要求完美，但要让下一个接手的测试少走弯路。

建立自动化回归：核心流程的用例逐步转为自动化脚本。老系统缺乏文档，自动化脚本本身就是一种“可执行的文档”——它比任何文字描述都更准确。

接手老系统最忌讳两种心态：一是抱怨没文档，一直等别人给资料；二是觉得没法测，随便点点就算了。

老系统本身就是一个测试对象。你花在了解它上的每一分钟，都是在建立你独一无二的经验。当你把这个系统彻底摸透后，你就是这个系统的专家——比开发更了解用户会怎么用、比产品更了解哪里有坑。