测试已保存设置的升级路径

发布于 2024-10-09 19:52:29 字数 451 浏览 0 评论 0原文

我正在使用 C# 工作,我的软件中有一个自定义的“设置”对象,该对象保存在磁盘上,当我升级软件版本时,我需要能够对其进行测试。

例如,如果我有“版本 A”的软件并具有该版本的设置,当我升级到软件的“版本 B”时,我想确保“设置 A”可以完全升级。

当后来我升级到软件的“版本 C”时,我必须测试从 A->C 以及 B->C 的升级路径(版本 n+1 需要比版本 n 多 n+1 的测试用例) )。

我非常担心的是,测试路径的指数增长将很快变得难以维护。

有处理这个问题的标准方法吗?


我遇到的一些重要问题是:

设置不一定存储在本地计算机上,因此我继承的软件需要能够将这些设置从一台计算机传输到另一台计算机。

MSDN 表示,像 ClickOnce 设置这样的构造不直接支持这一点,我必须“开发[我的]自己的自定义设置类,用于在远程计算机上存储设置”。

I'm working in C# and I have a custom "settings" object in my software that's saved on disk that I need to be able to test when I upgrade versions of my software.

For example, if I have software with "version A" and have settings from that version, when I upgrade to "version B" of my software, I want to make sure that "settings A" can be upgraded cleanly.

When later I upgrade to "version C" of my software, I have to test the upgrade paths from A->C as well as B->C (version n+1 requires n+1 more test cases than version n did).

A large concern I have is that this exponential growth of testing paths will quickly get hard to maintain.

Is there a standard way of dealing with this?


Some important issues I have are:

The settings aren't necessarily stored on a local computer, so the software I inherited needs to be able to transfer these settings from computer to computer.

MSDN says they constructs like ClickOnce settings don't support this directly, and I must "develop [my] own custom settings classes for storing settings on a remote computer."

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

守望孤独 2024-10-16 19:52:29

我添加了一条关于在升级后首次运行应用程序时可能执行此操作的评论。

我不清楚您是否关心的是必须开发所有这些升级路径还是将其集成到您的安装/升级过程中。

如果问题是如何构建和测试越来越多的设置升级,那么一个简单、相对容易的方法就是:

public interface ISettingsUpgrader
{
    void UpgradeSettings();
}

public abstract class SettingsUpgrader : SettingsUpgrader
{
    protected int version;

    public virtual void UpgradeSettings()
    {
        // load settings and read version info
        version = settingsVersion;
    }
}

public class SettingsUpgraderV2 : SettingsUpgrader
{
    public override void UpgradeSettings()
    {
        base.UpgradeSettings();
        if(version > 1) return;

        // do the v1 -> v2 upgrade
    }
}

public class SettingsUpgraderV3 : SettingsUpgraderV2
{
    public override void UpgradeSettings()
    {
        base.UpgradeSettings();
        if(version > 2) return;

        // do the v2 -> v3 upgrade
    }
}

因此,对于每个新版本,您只需遵循此约定并实现从先前版本的升级。所有基本设置文件处理都在基类、抽象类中进行,并且将根据需要执行后续升级。

在测试方面,每个新版本只需要验证(1)是否调用了基本方法——现有测试已涵盖其功能,以及(2)最新的 v(n-1) -> v(n-1) 是否已被调用。 v(n) 被正确执行。

作为补充说明,在每个级别实现设置回滚过程可能是一种很好的形式,除非您不允许回滚到以前版本的选项。

I added a comment about possibly doing this when the application first runs after an upgrade.

It isn't clear to me if your concern is with having to develop all these upgrade paths or with getting this integrated into your installation/upgrade procedure.

If the issue is with how to build and test increasingly numerous settings upgrades, then a simple, relatively easy way to do it is this:

public interface ISettingsUpgrader
{
    void UpgradeSettings();
}

public abstract class SettingsUpgrader : SettingsUpgrader
{
    protected int version;

    public virtual void UpgradeSettings()
    {
        // load settings and read version info
        version = settingsVersion;
    }
}

public class SettingsUpgraderV2 : SettingsUpgrader
{
    public override void UpgradeSettings()
    {
        base.UpgradeSettings();
        if(version > 1) return;

        // do the v1 -> v2 upgrade
    }
}

public class SettingsUpgraderV3 : SettingsUpgraderV2
{
    public override void UpgradeSettings()
    {
        base.UpgradeSettings();
        if(version > 2) return;

        // do the v2 -> v3 upgrade
    }
}

So, for each new version, you only have to follow this convention and implement the upgrade from the previous version. All of the basic settings file handling goes in the base, abstract class, and successive upgrades will be performed as necessary.

Testing-wise, each new version requires only verifying (1) that the base method is called -- the functionality of which is already covered by existing tests, and (2) that the latest v(n-1) -> v(n) is properly executed.

As an additional note, it is probably good form to also implement a settings rollback procedure at each level, unless you're disallowing the option to roll back to a previous version.

明媚如初 2024-10-16 19:52:29

安装程序通常必须使用管理员权限运行,因此通常可以访问网络。您需要做的就是访问当前版本的应用程序配置(或者注册表项,如果您这样做的话)并获取文件位置,然后使用 FileStream 来拉取它,无论是来自本地计算机还是本地服务器或企业服务器,只要您可以通过 LAN/WAN 进行操作即可。从互联网地址获取数据将需要不同的机制。

我要做的就是对转换进行分层。要将设置文件从 A 转换为 D,请首先将其转换为 B,然后转换为 C,最后转换为 D。这听起来可能性能不佳,但只有在用户拥有极其过时的版本的情况下才会如此。软件;之前版本的定期更新只需要经过一层。它还具有使每一层都拒绝更改的极端优势;一旦您拥有正确将版本 A 转换为版本 B 的代码,您就不必返回并可能破坏它以添加版本 C 更新逻辑。

Installers must generally be run using Administrator permissions, and therefore usually have access to the network. All you should need to do is access the current version's app config (or a registry key if you did it that way) and get the file location, then use a FileStream to pull it across, whether that's from the local comp, the local server, or a corporate server, as long as you can do it over the LAN/WAN. Pulls from an Internet address will require a different mechanism.

What I would do is layer the conversions. To convert a settings file from A to D, first convert it to B, then to C, and THEN to D. This may sound non-performant, but it will only be so in cases where the user has an extremely outdated version of the software; regular updates from the previous version will only need to go through one layer. It also has the extreme advantage of making each layer closed to change; once you have code to correctly turn version A into version B, you NEVER have to go back in and possibly break it to add the version C update logic.

薄凉少年不暖心 2024-10-16 19:52:29

处理升级的最佳方法是一次一步地进行。

以你的例子为例:
构建从 A 到 B 的升级路径,然后从 B 到 C 的升级路径。

在测试从 A 到 C 的升级时,必须先运行 A 到 B,然后再运行 B 到 C。

这将在很大程度上限制测试场景。我见过的很多软件都是通过这种方式升级的。这可能会导致类似将某个字段添加到表中(升级到 B)但又立即将其删除(升级到 C)之类的情况;但这只是为了限制这种情况而付出的很小的代价。

最后,您只需构建一个升级脚本即可从上一版本升级到当前版本。

The best way to deal with upgrades is to do it one step at a time.

Taking your example:
Build an upgrade path from A to B, then one from B to C.

When testing an upgrade from A to C you have to run A to B first, then B to C.

This will limit testing scenarios quite a bit. A lot of software I've seen does the upgrade this way. It might result in things like having a field added to a table (upgrade to B) only to have it removed immediately (upgrade to C); but that's a small price to pay in order to limit the scenarios down.

At the end of this you only have to build an upgrade script to take you from the immediate previous version to the current one.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文