存档测试分享-优快云博客

本文链接：https://blog.youkuaiyun.com/software_test010/article/details/146315672

📝 面试求职： 「面试试题小程序」，内容涵盖测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

存档，也经常听到有人称之为存盘，单机游戏的进度存在电脑磁盘上，因此，存盘的说法非常形象，也很好理解。

在后来发展的网游服务器架构下，游戏数据不再放客户端本地，而是把数据放到服务器上，这就需要将数据从内存写到数据库，实现数据落地，这就是本文打算主要讨论的服务器数据存档的内容。

01 数据和存档原理

在展开存档相关测试工作介绍前，我们需要先了解一下游戏数据处理相关的原理，包括游戏数据在客户端和服务器之间如何流转，以及怎样的数据需要存档。下面先举一个简单的例子来说明一下。

以玩家所在的位置坐标数据为例：玩家在场景里移动，玩家的位置由客户端进行计算，然后发给服务器进行校验，校验不通过则拉回服务器计算出的坐标点，始终以服务器的计算结果为准。

玩家停止移动后，服务器对玩家位置坐标的记录仍在内存里，不会存入数据库。那么接下来当玩家下线时候，我们来看位置坐标是否需要存档，分 2 种情况：

1.如果玩家再上线仍需在同一坐标，则服务器会在玩家下线时，把玩家位置坐标从内存写入数据库，进行该数据的存档。

2.如果玩家在主城下线再上线就会回到主城的起始坐标，那么玩家在主城下线时，是无需对当前坐标进行存档的。

看了上面的例子，我们可以发现：如果在客户端下次上线时候，数据仍需使用，那么这个数据就需要存档；或者，如果服务器重启后，这个数据仍需要保留，那也要进行存档。那么，对应到测试工作中，我们在编写用例时，需要先理清楚这个功能涉及了哪些游戏数据，然后再逐个分析这些数据是否需要测试存档。

接下来，我们分别来看一下，游戏内有哪些数据分类，以及存档机制怎样。

1.1 游戏数据的分类

游戏内有哪些数据分类，针对不同的游戏类型可能会不太一样，大家需要了解自家游戏的数据类型，这能够帮助我们更好的考虑到一个功能有哪些数据，然后分析出这些数据是如何在客户端与服务器之间流转的，进而覆盖到这些数据的存档测试，同时基于数据流转逻辑挖掘出更深入的功能测试点。

这里整理了一些通用的游戏数据分类，可以先了解一下。

1.玩家数据

这部分数据，随着玩家登录而加载，随玩家下线而保存，下线后不可能修改。比如个人活动数据、个人属性数据、个人战绩数据等。

2.离线数据

如社交类数据，玩家离线时仍需要为玩家进行处理，因为在他离线期间可能会发生改变。离线数据与玩家数据的区别是，玩家数据在玩家下线后不会再改变。

举个简单好理解的例子：A离线时，B同意了A的好友申请，则A的好友数据增加了B，A上线时会收到服务器发来的好友列表，客户端上显示B已是A的好友。同样，A的公会申请在离线时被通过，则A的个人公会数据也是类似的逻辑。

3.共享数据

与玩家关联，但用于多个玩家共享的数据，如公会数据。稍微详细一点说：某公会的升级、公会资源等数据，与公会内所有成员共享，所有公会成员上线时将收到服务器发来的所属公会数据，在公会成员打开公会面板时进行客户端显示。

上面讲离线数据时也提到了公会数据，区别在哪里呢？解释如下：个人公会信息是属于玩家的离线数据，而某个公会的数据，属于公会成员共享的，这属于共享数据，需要理解清楚哦。

4.设置类数据

如各种设置类数据、动态加新活动等服务器数据，与玩家无关。以动态加新活动为例，原本活动是配在配表里的，当线上动态加一个新活动时，这个新活动不可能再加到配表里，那就只能存入数据库，可以认为是活动配表新增了一行，但其实这一行是存在数据库里的。

1.2 游戏存档的机制

了解了游戏内的数据类型以后，我们再来看一下，数据存档有哪些机制，即数据怎样进行存档。同样，不同游戏采用的存档机制可能不太一样，也是需要去了解自家游戏采用了哪些机制。当跟进新功能时，能够首先去考虑该功能采用的存档机制是否合理，而后对各数据的存档正确性进行验证。

这里举例说明常用的 3 种存档机制，基本能覆盖大多数游戏。

1.立即存档

当数据发生改变时，直接调用存档操作立即进行数据库存档。主要用于关键数据变化时调用，以及一些设置类数据。比如扣除元宝等较为关键的场合；比如激活码信息、玩家白名单、QA 白名单等设置类数据。

另外如果数据是临时修改性质，数据变化不频繁，也可以采用立即存档的方式，操作较少，对 DB 几乎无影响。

2.延迟存档

延迟存档是根据存档变化在一定时间后开始存档操作，防止短时间内大量的变化导致存档操作过于频繁，如好友数据的变化存档、社团数据变化存档、聊天内容存档等。如果要保存的数据是频繁变化的，会导致单位时间有很多保存操作的，则需要采用延迟保存的方式进行数据存档，主要是为了避免单位时间内的 DB 存档压力波动。

另外可以了解一下的是，延迟存档，在关服时会需要有批量存档操作，否则上一次存档后的新数据就还在内存里未落地。这一般来说是通用逻辑，不需要每个选择延迟存档的数据都测试关服时存档。

3.定时存档

定时存档是根据当次存档时间设置下次存档的时间，不考虑存档是否发生变化。一般测试定时存档的数据能够存档即可，不需要再测试每个数据是否能定时存档，只要每个赛季回归该功能生效即可。与延时存档类同，定时存档也需要在关服时有批量存档的操作。

1.3 存档的游戏实现

大部分游戏服务器架构下都有DB Server。不管是立即存档还是延迟存档的数据，在逻辑服发生数据变化后，都是需要发给DB Server，由DB Server 进行数据库存档操作，实现数据落地。因此，我们再来简单进一步了解下DB Server 的存档操作。

1.DB Server缓存部分数据

DB Server 缓存玩家的数据，避免频繁读取数据库。DB一般会将数据存取分成两类，一类是直接进行存取的数据，一类是带缓存的数据。上文提到的几类数据，不同数据类型可以选择不同缓存策略，例如玩家的在线数据，部分缓存在DBServer；而设置类数据，有部分缓存，其他则是直接存取。在DB Server做了缓存的数据，当玩家数据发生改变时，玩家数据会从逻辑服发到DB Server，这时会修改缓存里的数据，然后再从缓存延迟写到数据库。

2.DB Server延迟保存

大部分游戏的DB Server 会有一个延迟保存间隔，目的是为了防止密集的大量数据保存产生性能波动。

可以了解一下自家游戏的存档机制，是否有其他特殊的机制和逻辑，测试时可以针对性进行考虑。