27、Windows Store 应用开发：错误处理与测试策略-优快云博客

Windows Store 应用开发：错误处理与测试策略

1. 错误处理设计

在开发处理敏感用户信息（如社保号码、家庭银行账户信息等）的 Windows Store 应用时，谨慎的错误处理策略至关重要，因为不当的错误处理可能会导致敏感信息泄露，例如在屏幕上显示异常的内部消息或堆栈跟踪信息。

为确保应用不泄露敏感信息，在实施错误处理策略时可采取以下预防措施：
- 使用 try/catch 块 ：在尝试访问可能不可用或缺失的资源，或者依赖无法控制的类型和函数时，设置 try/catch 块。同时，使用 finally 块尽快释放任何非托管资源并进行必要的清理工作。
- 处理未处理异常 ：UnhandledException 事件可处理应用代码未处理的异常。将 UnhandledExceptionEventArgs 的 Handled 属性设置为 true，告知框架不再进一步处理该异常，此时应用不会终止。
- 处理敏感设备访问错误 ：Windows Store 应用首次访问敏感设备功能前，用户必须授予权限。由于应用可能无法访问敏感设备，因此需要处理尝试访问禁用或缺失的设备功能时可能发生的错误。
- 异步调用的错误处理 ：使用 async/await 模式时，可在代码中的任何异步调用周围放置 try/catch 块，捕获该方法异步执行期间引发的任何异常。当预计异步调用期间会引发多个异常时，可使用 AggregateException 类进行处理。
- 处理未观察到的异常 ：实现 UnobservedTaskException 事件处理程序作为安全网，处理未观察到的异常。

以下是一个简单的错误处理示例：

try
{
    // 尝试访问可能不可用的资源
    var resource = GetResource();
    // 使用资源
}
catch (Exception ex)
{
    // 处理异常
    LogError(ex.Message);
}
finally
{
    // 释放资源
    ReleaseResource();
}

2. 错误处理知识测试

以下是一些关于错误处理的测试问题，帮助你检验对相关知识的掌握程度：
| 问题 | 选项 | 答案 |
| — | — | — |
| 当 XAML 框架何时引发 UnhandledExceptionEvent 事件？ | A. 每次在 try/catch 块中捕获异常并在 finally 块中由应用代码处理时
B. 每次在返回 void 的异步方法中抛出异常时
C. 调用异常的 Handled 方法时
D. 应用代码不再有任何可能捕获未处理的异常时 | D |
| 当应用在未获得用户使用设备权限的情况下尝试调用 Windows.Media.Capture.MediaCapture.InitializeAsync 方法时，通常会引发哪种类型的异常？ | A. UnauthorizedAccessException
B. InvalidOperationException
C. 通用的 System.Exception
D. 无 | A |
| 当你忘记等待返回任务的异步方法，并且在异步操作期间引发异常时会发生什么？ | A. 异步操作执行后，异常立即传播给调用者
B. 异常存储在匿名 Task 实例中，然后被忽略（未观察到的异常）
C. 异常未处理，最终向上冒泡，导致进程终止
D. 异常添加到返回给调用者的 AggregateException.InnerExceptions 集合中 | B |

3. 测试策略设计与实现

测试是软件开发过程的重要组成部分，对于 Windows Store 应用也不例外。测试不仅是为了发现代码中的错误，还包括验证应用是否满足所有功能和非功能需求，以及是否按预期运行。常见的测试方法可分为功能测试和单元测试。

3.1 功能测试

应用的功能需求是软件应执行的任务。功能测试是一个通用类别，包括所有从用户角度验证软件功能需求是否正常工作的测试。功能测试需要事先确定软件应执行的功能（或任务）以及基于这些功能规范的预期结果。

例如，在酒店预订应用中，用户请求预订特定夜晚的房间。功能测试可能会验证应用是否实际将请求发送到远程服务，服务是否处理请求并将响应返回给应用，以及是否告知用户预订操作是否成功。应用应能够成功处理该场景以及可能影响执行流程的任何问题，例如网络连接不可用、房间已被他人预订等。

功能测试有三种方法：
- 自下而上方法 ：先集成和测试较低级别的组件。所有低级模块测试并验证结果后，再测试较高级别的组件，重复此过程直至测试完层次结构顶部的组件。
- 自上而下方法 ：与自下而上方法相反，先集成和测试较高级别的组件，然后系统地测试每个流程分支，直至测试完用例中涉及的所有低级组件。
- 组合方法 ：结合自上而下和自下而上的测试方法，充分利用两种方法的优势。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([开始]):::startend --> B{选择测试方法}:::decision
    B -->|自下而上| C(测试低级组件):::process
    B -->|自上而下| D(测试高级组件):::process
    B -->|组合| E(结合两种方法):::process
    C --> F(测试高级组件):::process
    D --> G(测试低级组件):::process
    E --> H(交替测试):::process
    F --> I([结束]):::startend
    G --> I
    H --> I

3.2 集成测试

集成测试是功能测试的一种特殊类型，其目的是验证应用的各个组件和资源是否按预期协同工作。在这种测试中，软件模块组合成复合聚合体，测试不同部分如何作为一个整体集成。与单元测试不同，集成测试测试被测方法与应用所依赖的低级组件之间的所有代码。不过，尽管两者存在差异，但通常可以使用相同的测试框架创建单元和集成测试，例如在 Visual Studio 2012 中，可以使用相同的 Windows Store 应用单元测试库模板进行单元和集成测试。

3.3 编码 UI 测试

UI 测试是另一种功能测试，可通过用户界面驱动应用进行测试。从概念上讲，这与手动按 F5 运行整个应用并与用户界面元素交互并无不同。Visual Studio 2012 允许通过记录在用户界面上执行的操作序列，然后生成代码自动重复相同步骤并验证结果（即“编码 UI 测试”，简称 CUIT）来自动化此类测试。但截至目前，Windows Store 应用不支持此功能，只能通过手动与用户界面交互来测试应用。为跟踪手动测试，可以使用 Microsoft Test Manager 描述测试，并将测试结果与 Visual Studio Team Foundation Server 中的构建关联起来。

在手动测试 Windows Store 应用的用户界面时，Visual Studio 远程调试器可让你从运行 Visual Studio 的第二台计算机远程运行、调试和测试应用。当 Visual Studio 计算机不支持 Windows Store 应用特定的功能（如触摸、地理位置和物理方向）时，在远程设备上运行尤其有效。

4. 单元测试

单元测试不应与功能测试（尤其是集成测试）混淆。在单元测试中，你要将应用中可测试的最小软件单元从代码的其余部分隔离出来，通过将其作为单个单元进行测试，确定其是否按预期运行。隔离被测类或方法需要移除任何外部依赖，即被测代码单元与之交互但无法控制的任何对象或组件（如文件系统、数据库和远程服务）。为此，可以用存根和模拟对象替换外部依赖。

单元测试具有以下特点：
- 鼓励分离关注点 ：隔离软件进行单元测试需要采用一种鼓励分离关注点的设计，并针对接口而非具体实现进行编码。
- 测试独立性 ：单元测试的成功或失败不应相互依赖，也不需要按特定顺序执行。
- 回归测试 ：单元测试还可用于回归测试。每次修改代码时，可针对修改后的代码运行现有的单元测试，以验证更改是否影响了代码的其他部分。这样，在为软件添加新功能时，回归测试可大大降低引入新错误的风险。

5. Windows Store 应用测试项目的实现

Windows Store 应用不使用在 Microsoft.VisualStudio.TestTools.UnitTesting 命名空间中定义的经典 Visual Studio .NET 应用单元测试框架，而是使用专门为 Windows Store 应用设计的框架，该框架位于 Microsoft.VisualStudio.TestPlatform.UnitTestFramework 命名空间中。

这个新命名空间包含为测试 Windows Store 应用提供特定支持的类型和方法，并依赖于 Windows Store 应用的同一 WinRT 引擎。实际上，测试代码在 Windows Store 应用的同一沙盒环境中执行。因此，不仅可以从测试代码调用 WinRT API，而且 Windows Store 应用的单元测试项目还包含一个 Package.appxmanifest 文件，这与 Windows Store 应用项目中的应用清单相同。要测试应用如何与某些资源或设备（如用户库、网络摄像头或麦克风）交互，必须像在任何 Windows Store 项目中一样，在单元测试项目的应用清单中声明相应的功能。

与传统的 .NET 应用测试框架相比，Windows Store 应用测试框架有以下不同：
- 不支持 ExpectedException 属性 ：取而代之的是，框架在 Assert 类中引入了一个新的泛型方法 ThrowsException ，该方法明确指出抛出异常是你期望被测方法表现出的行为。
- 支持在 UI 线程上运行测试 ：Visual Studio 2012 Update 2 引入了新的 UITestMethodAttribute 属性，可在不使用 Dispatcher 进行封送处理的情况下，在主 UI 线程上运行单元测试。
- 支持轻量级数据驱动测试 ：单元测试框架为轻量级数据驱动测试提供了基本支持，这是一种特殊的测试策略，允许使用不同的输入值执行相同的测试方法。

以下是一个简单的单元测试示例：

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.VisualStudio.TestPlatform.UnitTestFramework;

namespace SimpleApplication.Unit.Test
{
    [TestClass]
    public class UtilityTest
    {
        [TestMethod]
        public void Divide_TwoDoubles_ReturnsDouble()
        {
            // Arrange
            var expected = 2.4; // 预期结果
            var utility = new Utility(); // 设置测试对象

            // Act
            var actual = utility.Divide(4.8, 2.0); // 实际结果

            // Assert
            Assert.AreEqual(expected, actual); // 验证条件
        }
    }
}

6. 单元测试的命名约定

在单元测试中，遵循一致的命名约定有助于提高代码的可读性和可维护性。常见的命名约定如下：
- 类名：类名遵循 Test 模式。例如，如果测试的类名为 Utility，则所有与该类相关的测试都分组到一个名为 UtilityTest 的单元测试文件中。
- 测试方法名 ：单个测试的命名基于模式。StateUnderTest 表示测试方法时的条件（例如，是否传递了正确的参数或无效值）。ExpectedBehavior 用于说明在提供的条件下期望方法表现出的行为（例如，返回某个值或抛出某种异常）。

无论为测试项目选择何种命名约定，都要确保所有测试遵循相同的标准，并明确每个测试的状态和期望的行为。

7. 单元测试的执行规则

与经典的 .NET 应用测试框架一样，TestClass 属性用于标识要运行的单元测试组，TestMethod 属性表示需要运行的每个单元测试。在示例中，测试验证了提供两个双精度数作为参数时，被测方法返回正确的结果。方法体还说明了所谓的“三个 A 规则”：设置要测试的对象（Arrange）、执行被测方法（Act），然后对对象进行断言（Assert）。

Assert 类包含用于使用布尔命题验证单元测试条件的方法。例如，在上述示例中使用的 AreEqual 方法通过调用 Object.Equals 方法验证两个值是否相等。示例断言在提供的参数下，方法应返回一个特定值，该值由 expected 变量表示。如果是，则断言为真，测试通过。要验证两个对象是否指向同一引用，必须使用 AreSame 重载方法之一。

8. 不同参数下的单元测试

除了验证方法在提供正确参数时的行为是否正确，还需要测试提供错误参数或被测对象的状态不符合预期时的情况。例如，假设期望某个方法在提供空值作为参数时抛出 ArgumentNullException 类型的异常。为测试这种行为，可以使用 ThrowsException 方法，其中 TException 表示预期的异常类型。

以下是一个测试除以零情况的示例：

[TestMethod]
public void Divide_ZeroAsSecondParameter_ReturnsInfinite()
{
    // Arrange
    var utility = new Utility();

    // Act
    var actual = utility.Divide(4.8, 0.0);

    // Assert
    Assert.IsTrue(Double.IsInfinity(actual));
}

以下是一个测试抛出异常情况的示例：

[TestMethod]
public void GetCustomerName_EmptyId_ThrowsArgumentNullException()
{
    // Arrange
    var biz = new Biz();

    // Act & Assert
    Assert.ThrowsException<ArgumentNullException>(() => biz.GetCustomerName(""));
}

9. 异步调用的单元测试

也可以使用经典的 async/await 模式测试异步调用。以下是一个异步调用单元测试的示例：

[TestMethod]
public async Task GetCustomerNameAsync_ValidId_ReturnsCustomerName()
{
    // Arrange
    var biz = new Biz();
    var expectedName = "Expected Name";

    // Act
    var actualName = await biz.GetCustomerNameAsync("123");

    // Assert
    Assert.AreEqual(expectedName, actualName);
}

10. 在 UI 线程上运行单元测试

Visual Studio 2012 Update 2 引入了一个新属性，用于在 UI 线程上运行代码。创建 Windows Store 应用的单元测试项目时，标记为 TestMethod 属性的测试不会在 UI 线程上运行。在引入这个新属性之前，如果要在 UI 线程上执行操作，必须使用 Dispatcher。现在，只需用新的 UITestMethod 属性标记测试即可。

[UITestMethod]
public void Some_UI_Test()
{
    // 要在 UI 线程上执行的代码
}

11. 测试夹具的管理

遵循单元测试的原则，每个测试都需要在已知条件下开始，并在结束时清理相关资源。这样，测试不会受到其他测试或外部条件的影响。

可以使用 ClassInitialize 和 TestInitialize 属性集中设置运行测试前必须具备的所有条件（也称为“测试夹具”），例如创建要提供给被测方法的模拟对象或打开与数据库的连接。使用完夹具后，可以分别使用 ClassCleanup 和 TestCleanup 属性将其拆除。

这两种属性的区别在于，标记为 ClassInitialize 和 ClassCleanup 属性的方法分别在一组测试运行前后调用，而标记为 TestInitialize 和 TestCleanup 属性的方法分别在每个单元测试运行前后调用。因此，如果需要在不同的单元测试之间共享夹具，可以在标记为 ClassInitialize 属性的方法中设置夹具，在不同测试之间共享，然后在 ClassCleanup 方法中拆除夹具。相反，如果要为每个单独的测试重新创建一个全新的夹具，可以用 TestInitialize 属性标记方法，而负责在每个测试后拆除资源的方法则用 TestCleanup 属性标记。为每个单独的测试重新创建一个全新的夹具是最佳实践，因为这样可以避免测试之间的耦合。

以下是一个 TestInitialize/TestCleanup 模式的示例：

[TestInitialize]
public void TestSetup()
{
    // 设置每个单元测试将使用的全新夹具
}

[TestMethod]
public void Test_Using_Fresh_Fixture()
{
    // 使用夹具
}

[TestCleanup]
public void TestTearDown()
{
    // 在进入下一个单元测试之前拆除夹具
}

12. 轻量级数据驱动测试

单元测试框架为 Windows Store 应用引入了对轻量级数据驱动测试的基本支持，这是一种允许使用不同输入值执行相同测试方法的特殊测试策略。

以下是一个数据驱动测试的示例：

[DataTestMethod]
[DataRow("25892e17-80f6-715f-9c65-7395632f0223", "Customer #1")]
[DataRow("a53e98e4-0197-3513-be6d-49836e406aaa", "Customer #2")]
[DataRow("f2s34824-3153-2524-523d-29386e4s6as1", "Customer #3")]
public void GetCustomerName_RightID_ReturnExpected(String id, String customerName)
{
    var biz = new Biz();

    var actualCustomer = biz.GetCustomerName(id);

    Assert.AreEqual(customerName, actualCustomer);
}

这种测试策略基于两个新属性：DataTestMethod（取代了标准的 TestMethod 属性）和 DataRow。此外，测试方法的签名也不同，现在接受两个字符串作为参数。DataRow 属性定义了将作为参数传递给测试方法的数据集。然后，测试方法以及相关的设置和拆除方法将多次执行，每次使用不同属性提供的值。在示例中，第一个值（表示客户 ID 的字符串）对应于测试方法接受的第一个参数，代表将提供给被测方法（GetCustomerName）的值。传递给测试方法的第二个值表示期望被测方法返回的值。

13. 测试问题思考

假设有以下需要测试的方法：

public async Task<String> LoadDocumentSample(String fileName) 
{ 
    try 
    { 
        var folder = KnownFolders.DocumentsLibrary; 
        var file = await folder.GetFileAsync(fileName); 
        var text = await Windows.Storage.FileIO.ReadTextAsync(file, Windows.Storage.Streams.UnicodeEncoding.Utf8); 
        return text; 
    } 
    catch (UnauthorizedAccessException ex) 
    { 
        // 处理异常 
    } 
    catch (Exception ex) 
    { 
        // 处理异常 
    } 
}

作为第一个测试，你希望确保提供用户文档库中现有文本文件的名称时，该方法返回文件的实际内容（在本例中为“some content”）。以下是第一个集成测试的实现：

[TestMethod] 
public void SaveDocumentSample_ExistingFileName_ReturnsExpectedText() 
{ 
    var utility = new Utility(); 
    var t = utility.LoadDocumentSample("document.txt"); 
    Assert.IsTrue(t.Result == "some content"); 
}

运行测试时，由于异步操作执行期间引发的 AggregateException 而失败。为解决此问题，首先应检查测试项目的应用清单中是否声明了访问文档库的功能。因为如果没有声明相应的功能，应用将无法访问文档库，从而导致异常。

Windows Store 应用开发：错误处理与测试策略

14. 总结与实践建议

在 Windows Store 应用开发中，错误处理和测试策略是保障应用质量和安全性的关键环节。通过合理的错误处理，可以避免敏感信息泄露，确保应用在各种异常情况下的稳定性；而有效的测试策略能够帮助开发者及时发现并修复代码中的问题，提高应用的可靠性和性能。

以下是一些实践建议：
- 错误处理
- 全面覆盖 ：在可能出现异常的代码段都要设置 try/catch 块，确保对各种异常情况进行捕获和处理。
- 信息安全 ：在处理异常时，避免直接将敏感信息显示在错误信息中，防止信息泄露。
- 资源管理 ：使用 finally 块及时释放非托管资源，避免资源泄漏。
- 测试策略
- 多样化测试 ：综合运用功能测试、集成测试、单元测试等多种测试方法，全面验证应用的功能和性能。
- 自动化测试 ：尽可能使用自动化测试工具，提高测试效率和准确性。例如，在支持的场景下使用自动化脚本进行功能测试。
- 持续测试 ：在开发过程中持续进行测试，及时发现和解决问题，避免问题积累。

15. 未来趋势与挑战

随着技术的不断发展，Windows Store 应用开发面临着新的趋势和挑战。在错误处理和测试策略方面，也需要不断适应和创新。

15.1 新的错误类型

随着应用功能的不断增加和复杂性的提高，可能会出现新的异常类型。开发者需要及时了解并处理这些新的错误，确保应用的稳定性。

15.2 跨平台兼容性测试

随着 Windows 系统在不同设备上的广泛应用，应用需要在多种平台和设备上进行测试，以确保兼容性。这增加了测试的难度和工作量。

15.3 性能测试的重要性

随着用户对应用性能的要求越来越高，性能测试变得尤为重要。开发者需要进行性能测试，优化应用的响应时间和资源占用。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px

    A([未来趋势与挑战]):::startend --> B{新的错误类型}:::decision
    A --> C{跨平台兼容性测试}:::decision
    A --> D{性能测试的重要性}:::decision
    B --> E(及时处理新错误):::process
    C --> F(增加测试难度):::process
    D --> G(优化应用性能):::process
    E --> H([应对挑战]):::startend
    F --> H
    G --> H

16. 常见问题解答

以下是一些关于 Windows Store 应用错误处理和测试的常见问题及解答：

问题	解答
如何确保错误处理不会影响应用的性能？	尽量避免在错误处理代码中进行复杂的操作，确保错误处理代码简洁高效。可以使用日志记录等方式，将错误信息记录下来，而不是在错误发生时进行复杂的处理。
测试时发现问题，如何快速定位问题所在？	可以结合日志记录、调试工具等方式，逐步缩小问题范围。例如，在代码中添加日志输出，记录关键步骤的执行情况；使用调试器单步执行代码，观察变量的值和程序的执行流程。
对于异步操作的测试，有什么特殊注意事项？	要确保异步操作的结果正确返回，可以使用 async/await 模式等待异步操作完成。同时，要处理可能出现的异步异常，例如使用 AggregateException 类处理多个异常。

17. 案例分析

以下通过一个实际案例，进一步说明错误处理和测试策略在 Windows Store 应用开发中的重要性。

17.1 案例背景

某公司开发了一款 Windows Store 应用，用于管理用户的个人财务信息。应用需要与远程服务器进行数据交互，同时涉及到用户敏感信息的存储和处理。

17.2 错误处理问题及解决

在开发过程中，发现应用在网络连接不稳定时会出现异常，导致数据传输失败。为了解决这个问题，开发者在与服务器交互的代码段添加了 try/catch 块，捕获网络异常，并在异常处理代码中提示用户检查网络连接。同时，使用 finally 块确保在异常发生时，及时关闭网络连接，释放相关资源。

以下是相关代码示例：

try
{
    // 与服务器进行数据交互
    var response = await HttpClient.GetAsync("https://example.com/api/data");
    if (response.IsSuccessStatusCode)
    {
        var data = await response.Content.ReadAsStringAsync();
        // 处理数据
    }
}
catch (HttpRequestException ex)
{
    // 处理网络异常
    MessageBox.Show("网络连接不稳定，请检查网络设置。");
}
finally
{
    // 关闭网络连接
    HttpClient.Dispose();
}