这是一个创建于 900 天前的主题，其中的信息可能已经有所发展或是发生改变。
在项目上正式之后测试进行回归，然后会留下一些测试数据，但是由于产品是面向 C 端的，有可能这些测试数据会被用户看到，所以需要把测试数据给清理掉，这种情况有没有什么好的解决方案？
目前我们的方案就是测试完了手动把测试账号相关的数据进行删除，很明显这不是个好的办法，所以来问问各位 v2er 们有你们项目是怎么处理类似问题的？
目前我们的方案就是测试完了手动把测试账号相关的数据进行删除，很明显这不是个好的办法，所以来问问各位 v2er 们有你们项目是怎么处理类似问题的？
第 1 条附言 · 2022-05-31 09:00:52 +08:00
更新下，我们是有预发环境的，预发和正式数据库也是隔离的，预发验收之后还是要在正式验收下，看了下各位的回答，好像用影子库会比较好点，但是改动会比较大，可以调研下，另外就是让测试造数据的时候尽量保持真实。
 |
1
puzzle9 2022-05-30 15:28:05 +08:00  2
我能想到的 建议发点正常的数据
|
 |
2
wobuhuicode 2022-05-30 15:29:15 +08:00
表里面加多一个参数标记为测试就好了
|
 |
3
eote 2022-05-30 15:29:18 +08:00
为啥没有测试库、预投产库、生产库隔离
|
 |
4
teslayun 2022-05-30 15:31:22 +08:00 4
定义请求头参数，测试的所有请求都带上这个请求头参数，然后后端分流存影子库，压测的大数据量也不怕了，数据多了直接清影子库就行
|
 |
5
zhazi 2022-05-30 15:32:32 +08:00
上线之后进行回归表示上线之前的流程并不完善。
在 pm 验收产品之后开发测试工作就完成了。 |
 |
6
XiLingHost 2022-05-30 15:45:53 +08:00
环境分离啊，开发测试生产三个环境同构但数据不同步就行了
|
 |
7
lujiaosama 2022-05-30 15:50:48 +08:00
难道你们的生产库和测试库开发库用的同一个? 那也太离谱了吧.
|
 |
8
hhjswf 2022-05-30 16:04:23 +08:00
@lujiaosama 产品验收一般都会在生产环境做测试吧
|
|
9
lujiaosama 2022-05-30 16:15:28 +08:00
@hhjswf 所以其实还会有个预生产库的, 除了库名不一样, 其他东西都一样.
|
 |
10
xiangyuecn 2022-05-30 16:16:14 +08:00 5
楼上有些人的意思：线上环境就不要测试了，能不能跑全凭感觉🐶🐶
|
 |
11
lscho 2022-05-30 16:18:23 +08:00
@xiangyuecn 测试环境不出问题，线上环境还会出什么问题呢？
|
 |
12
rushssss 2022-05-30 16:25:42 +08:00
通过某种手段标记请求并将这些请求走特殊分支的方法实际上是有隐患的：因为有可能这条分支没有 bug ，但真实用户走的分支有问题，导致问题测不出来
这个问题个人看法，暂时没什么特别好的办法，如果会影响到普通用户，只能手动清理一下 |
 |
13
nine 2022-05-30 16:31:19 +08:00
（目前我们的方案就是测试完了手动把测试账号相关的数据进行删除，很明显这不是个好的办法，所以来问问各位 v2er 们有你们项目是怎么处理类似问题的？）
很明显这是一个好办法 |
 |
14
dudubaba 2022-05-30 17:15:03 +08:00
增加预发环境，开发、测试、预发、正式。预发和正式除了用户不一样其他完全一样，产品一律在预发验证没问题同步上线。
|
 |
15
Blank10030 2022-05-30 17:18:20 +08:00 2
正式环境还测试那还要测试环境干啥。
|
 |
16
Jooooooooo 2022-05-30 17:40:11 +08:00
打标和过滤.
|
 |
17
qf19910623 2022-05-30 17:40:54 +08:00
@lscho 你怎么就能觉得测试环境不出问题，线上环境就不会出问题呢？这种生产环境故障我可是遇到过很多次
|
 |
19
clove 2022-05-30 17:46:33 +08:00 1
完全不能理解 "正式环境还测试那还要测试环境干啥。" 这个说法。
前司，测试环境 ok 、预发布环境 ok 、然后上正式环境还出现过问题。由于网络环境不同，多个机房某几个正常、某几个机房有问题的情况出现也不是一次两次了。 所以上正式环境还得每个机房验证一遍，产生测试数据是难免的。 我们的做法其实也没啥高明之处，主要基于账号测试，尽量不面向所有客户发布测试数据，只针对某一批测试的账号进行功能验证。 |
 |
20
sadfQED2 2022-05-30 17:54:08 +08:00 via Android
我们 pm 都是线上环境验收测试，但是要求线上环境不能随便乱写文字，不能带测试字样。
总的一句话，pm 发布的时候带点脑子，别让人发现不就行了 |
|
21
lscho 2022-05-30 18:07:11 +08:00
@qf19910623
预生产环境除了数据库不同，别的都相同，还会有什么什么问题呢？如果你生产环境出问题，只能证明你测试环境与生产环境还有差距。 @gaodq 所以有生产环境数据脱敏同步入预生产环境的测试方法啊。 |
 |
22
libook 2022-05-30 18:26:01 +08:00 3
灰度上线，进行小范围测试，测试完逐渐放大灰度比例，同时监测用户反馈，最终全量。
|
 |
23
singerll 2022-05-30 18:34:46 +08:00
@lscho 生产环境和测试环境有差距，可能会有很多原因，即便是同样的设备、同样的网络，也可能会有差异，生产环境还是需要测试的。
1 、硬件环境会有差异。比如服务器型号不同，服务型号相通某个部件型号不同，甚至是型号都相同但批次不同，这些都可能造成设备之间的差异。 2 、基础环境差异。尤其是你有几千台机器，防火墙，安全设备、waf 等设备一大堆的情况下，不可能模拟一模一样的环境。比如生产环境因为跟某个外部系统对接了，你开通了相应的安全策略，但你在测试环境因为不需要跟这个系统调试，并没有开通这个策略，这个想象很普遍。 3 、外部环境差异。我曾遇到过，因为出口用了不同的 ip 或者端口，碰巧网络运营商抽风的情况下，恰好某个地区或者某个运营商访问异常。 |
 |
24
ychost 2022-05-30 18:59:11 +08:00
测试一般有统一的测试灰度，比如这个灰度里面只能测试人员能看到，其它用户看到的是 master 上面的数据，后面再逐步扩大灰度即可
|
 |
25
potatowish 2022-05-30 19:25:01 +08:00 via iPhone
创建测试用户，登录测试用户来添加数据，创建定时任务，根据创建人为条件定时清理测试数据
|
 |
26
jin5354 2022-05-30 20:06:28 +08:00 4
楼上好多人回复太离谱了，有没有听过线上回归 4 个字啊，测试环境和生产环境差距可大了去了，上线不做回归测试可真是太牛了
像 lz 说的场景也没啥好办法，要不就测试的时候正经发内容别写 1234 ，要不就利用权限管理只在某旮旯位置测试，不要被大众看到，用完即删，比如测试外卖开店就放到西藏某旮旯村庄，要不就单独写点逻辑准备一个不公开的测试空间 |
 |
27
bootvue 2022-05-30 21:22:11 +08:00
影子库 sharding-proxy hint 强制路由
比如 某个字段 xxx_test 有个特殊标识 自动路由到单独数据库 /表中 不影响生产主库 自己捣鼓捣鼓 我也没用过 |
 |
28
janus77 2022-05-30 21:34:59 +08:00
专用测试账号可破。。。。
|
 |
29
joesonw 2022-05-30 22:00:41 +08:00 via iPhone
一般不是把线上数据倒入到 staging 做回归吗？
|
 |
30
Rocketer 2022-05-30 22:06:05 +08:00 via iPhone
生产环境测试就是得用与普通用户一样的环境，包括账号等都不能用特权账号，否则就是另一个测试环境，还是可能有问题。
所以归根结底还是得在内容上控制，别太离谱就行 |
 |
31
frandy 2022-05-30 22:13:29 +08:00
看到定义请求头参数给到的灵感,和逻辑删除差不多的逻辑,每张表中定义一个字段,用于区分是否正式环境。
这又让我联想到了 saas 系统,分为细粒度的从字段区分和粗粒度的从数据库区分,saas 系统区分更为复杂,这种测试数据区分要么是,要么否。 另外一种就是灰度上线,正式环境集群部署,负载均衡分流的时候检测到有特定请求头的数据,分流到指定的服务上,这个服务上连的数据库不同,其他都和正式一样。 以上都是猜想,未真正实施,抛砖引玉。 |
|
32
frandy 2022-05-30 22:16:42 +08:00
补充:第二种灰度上线不一定要请求头的数据,指定的源 ip,比如你在公司测试,正式环境,公司有公网 ip,通过这个 ip 访问的数据也是一种分流方式
|
 |
33
zlhsvc 2022-05-30 22:37:41 +08:00
测试时候发点正常内容，尽量选人少时候测。其他的就看具体上线的功能。
|
 |
34
LeegoYih 2022-05-30 23:02:43 +08:00
预发环境， 小项目可以在数据库加 is_test 字段区分
|
 |
35
xy90321 2022-05-30 23:57:29 +08:00 via iPhone
|
 |
36
wenzichel 2022-05-31 00:01:52 +08:00
1. 多环境隔离：我们这里是测试环境、预发布环境和正式环境，测试环境是测试程序和测试数据；预发布是测试程序和正式数据；正式环境则是正式程序和正式数据。不同的环境之间的数据是隔离的。若您要需要测试数据，那就在测试环境里测试，数据随意删减、若需要正式环境验证您的测试程序，那就在预发布。预发布没问题，就可以上线。
2. 白名单机制：使用登录 uid 或者设备 id 来设置白名单，只有白名单中的用户或设备，才能访问测试数据。但依然不建议，我还是建议使用上面环境隔离的方式。 |
 |
37
chawuchiren 2022-05-31 00:05:45 +08:00
面向 c 端的产品，就算是淘宝京东，都有测试数据能被你看到，为什么不可以？
|
 |
38
hallDrawnel 2022-05-31 00:11:16 +08:00
看你的业务，做特定的屏蔽。正式环境肯定是需要有测试数据的。但比如你是直播业务，那可以对普通用户屏蔽特定的直播间，然后在屏蔽的直播间测试，全站类的广播只发布后端，做接口验证等。没有统一的方法，根据业务因地制宜调整。复制流量之类的做法也覆盖不了一些特殊的情况。
|
|
39
jin5354 2022-05-31 07:22:05 +08:00
@xy90321 st 做啊，全部都要做，开发时在测试环境做，上线前在 staging 做，上线后在线上回归，一个都不能少，谁能保证 staging 和线上完全一致？只要是维护超过几年的有一些复杂度的项目，staging 和线上分叉就越严重，你不回归就会出现只在线上才暴露的奇葩错误
|
 |
40
nothingistrue 2022-05-31 09:23:26 +08:00
既然是正式环境，那肯定有“删除”操作，不管是硬删除还是软删除，把这个用例放到最后做，那测试完数据自己也就删除了。测试完，还能留下能被用户看到的测试数据的，就先别管测试数据怎么清理了，先去检查一下测试用例吧，要么漏测，要么用例顺序不良。
有些东西倒是一旦经过就会留下不可消除的痕迹，比如日志、统计信息，还有大多只给后台看的东西，这些东西没法通过正常操作删除。简单点的话，测试完手工清理。高级点的话，正式环境的测试过程也当成常规过程看，这些数据就永久保留，做好标记即可，但这需要良好的系统功能设计和测试用例设计。 |
 |
41
unco020511 2022-05-31 09:46:48 +08:00
在测试用例中加入"测试数据删除"这一项,并且在过测试用例评审是格外注意
|
|
42
unco020511 2022-05-31 09:48:43 +08:00
@lscho #11 测试和生产网络环境 /数据 /机器配置都不一样,你在测试测完,在生产也是有可能出现问题的,所以在生产环境回归这是一个必不可少的步骤
|
 |
43
cheneydog 2022-05-31 10:12:19 +08:00
数据库版本管理工具
nodejs 项目我用 knex ，其中 的 seed 就是测试数据的管理。 其他项目和管理工具应该也有类似的东东吧。 |
 |
44
Akiya 2022-05-31 11:28:33 +08:00
测完删除不就行了
|
 |
45
guaguaguaxia1 2022-05-31 11:47:23 +08:00
@teslayun 这种做法容易留下史诗级 bug ，因为很容易会对有这个请求头参数的请求做一些特殊逻辑
|
 |
46
Believer 2022-05-31 13:59:14 +08:00
设置 test env 根据 env 切换 database
|
 |
47
chrosing 2022-05-31 14:47:50 +08:00
我们有 4 套 本地开发库 测试环境库 预发布生产环境库和生产库
其中预发布生产环境的话 会进行两次测试 第一次就是往预生产产生的数据 第二次是正式环境中测试,不过我们的数据和生产的一样了 都视为有效数据 |
|
48
qf19910623 2022-06-02 16:07:51 +08:00
@lscho
大多数情况下不会有这么完美的测试环境的，很多诡异的问题不到生产环境还真暴露不出来，甚至因为换了个域名就可能出问题，不要以为这么低级的错误就不会出现 |
Select Language