1、单元测试的测试对象一般是某个组件或者某个函数，目标是保障这个组件/函数满足要求没问题。由于单测一般会把输入都通过类似 mock 的手段进行控制，所以是可以模拟出几乎全部你能想得到的输入（当然前提是你能想到）。不过如果说只是要用到 mock 手段方便你模拟线上数据的多样性，那你只需要一个接口 mock 服务就可以了，不需要特意去弄单元测试。

2、不知道你在测这个重构项目时，对重构的技术方案、改动范围有多少了解？有没有对现有缺陷做缺陷分析，看主要出现的原因是什么？每项测试都有自己擅长的点和不足的点，建议先找到你现在问题的原因，再考虑用什么解决方案。你说的线上数据多样线下难以覆盖，只是一个直接原因。为啥重构前线上同样多样的数据不会出问题，重构后会出问题呢？是不是重构的时候有些地方本身就没考虑完善导致逻辑遗漏，或者重构的人对以前代码逻辑不够熟悉，想当然去写写出了不正确的逻辑？这些才是根本原因。

个人经验，要控制好重构类项目的风险，必须从技术方案开始入手，把重构拆碎成多次，控制每次重构的边界（可以理解为改动范围），每重构完成一部分就测试并上线一部分，就算出问题也可以在这次有限的改动范围内快速找到原因并修复。否则一次大重构非常容易变成重写，影响范围大到几乎整个系统重测，开发测试都得加班加点，且风险难以控制。

如果后端没变，仅仅是前端展示有变化，做个前端 diff 测试就行了吧。

本来该长一样的数据，结果变了，一下子就出来了。

刚刚在百度和论坛都搜索了一遍，好像没有关联性特别强的文章，有没有关于这个介绍的文章呢？如果是 dom diff 的话，因为报表是一个画布，没有 dom，感觉不好去比对

感谢大佬抽空回答，
1.自己在这次重构中了解确实不太深入，测前和开发简单的讨论过影响范围还有大概的实现方式，测还是停留在功能层面去测。漏掉了很多场景。前端开发也是比较新的同事，里面很多堆叠的逻辑也不太清楚；
2.现在需要的确实是 mock 数据去测试图表的渲染效果，以前这块是缺失的，现在就要开始补回来了；
3.看完大佬分析的过程，发现自己看问题的思路也是停留在比较表层，不能揪出问题的所在；

前端开发也是比较新的同事，里面很多堆叠的逻辑也不太清楚；

这种情况下做重构，要非常小心。不清楚逻辑就做重构，是重构容易出问题的原因之一。现在你们处于测试没法把场景列得足够全，开发也没有对原有逻辑梳理得十分清晰的就动手重构的状态，重构的两个大坑都踩到了。。。

建议：
1、看这次重构是不是非常必要，如果不是，那就先 hold 一下，或者重新梳理逻辑后再重构吧。
2、如果代码已经上线甚至基于它已经做了一部分功能，不好回滚，那就找熟悉这块逻辑的同事（不限于测试，包括产品等都可以拉过来）一起过来补充更多的场景，以及做好线上用户反馈问题后及时响应的机制。

只是数值上的对比的话想办法获取就行。不过一些前端渲染啊样式这些，还是得靠看。
另外如果重构方案你参与过评审的话，测起来可能更有头绪一点。