25、软件开发中的错误恢复与测试协作

软件开发中的错误恢复与测试协作

1. 代码严重错误的恢复

在软件开发过程中，我们难免会在代码里犯下严重错误。但作为开发者，我们有能力从这些错误中恢复过来，并且避免软件发布后出现问题，这能让用户对我们的软件更加满意。

1.1 测试的局限性与必要性

严格的测试无法覆盖所有可能的用户场景，尤其是当应用程序具有高度可配置性时。考虑代码中的决策点，再结合支持的平台和外部依赖，可能产生的代码路径数量会超出我们在应用程序过时之前所能测试的范围。然而，这并不意味着我们要放弃测试。即使我们暂时没发现代码里有错误，也还是需要对其进行测试。

1.2 从严重错误中恢复应用程序的步骤

1.2.1 理解错误控制流并进行拦截

一般来说，错误处理程序（系统或环境的默认处理程序）会回溯函数调用栈，寻找应用程序定义的错误拦截点。要是没找到，操作系统或环境通常会终止应用程序。

1.2.2 定义错误拦截点

不同的编程语言有不同的实现方式：
- C++ 和 Java ：使用 try/catch 结构。Java 有一些优雅的扩展，而 C++ 能让我们更接近底层，捕获处理器生成的异常。在编写 Windows 应用程序时，我们可以编译代码来处理异步异常，从而捕获空指针引用或非法指令。虽然这会使代码体积略有增大，但如今的编译器能很好地控制额外代码的大小，这个代价是值得的。
- 结构化异常处理 ：对于技术能力较强的开发者来说，这是一种替代方案。它的开销较小，也能在纯 C 代码中实现，但更为复杂。有一些第三方库可以简化其实现。
- Visual Basic ：使用 On Error 特性。还有像 NuMega 的 FailSafe 这样的产品，能让我们捕获与 C++ 或 C 中相同的处理器级错误。

1.3 设计方面的考虑

1.3.1 数据与视觉的分离

我们要将数据和视觉部分分开，这样数据就能免受视觉部分潜在不稳定因素的影响。在严重错误发生时，建议将数据保存到不同的位置，而不是覆盖原数据。

1.3.2 视觉的稳定初始状态

这主要针对不太严重、可恢复的错误。例如，浏览器回到上一页，或者像刚打开文档一样显示文档。我们可以将光标移到文件开头，清除标记，清空剪贴板，重置特殊模式，清除缓存，然后重新开始访问和显示数据。如果应用程序有主窗口和详细信息窗口，遇到意外错误时，可以关闭详细信息窗口，返回主窗口。

1.3.3 简单而稳固的数据设计

理想的数据子系统应具备四个功能区域：从存储中加载数据、将数据保存到存储、向其他子系统提供数据以及接受其他子系统对数据的更改。但在实际中，可能需要添加一些额外的功能。为了让数据设计更加稳固，我们可以考虑在视觉部分处理复杂的数据处理。如果觉得这个方法不可行，也可以在数据和视图之间引入一些中间类。因为视觉部分比数据更容易恢复，当数据子系统出现严重错误时，往往就难以挽救了。如果数据不是同质的，我们可以尝试创建一个基类来处理通用操作，并使用数据库事务或结构化存储，尽可能多地对数据进行序列化。

1.4 错误信息的收集与报告

即使从意外错误中恢复过来，我们仍需向用户发出警报，并收集尽可能多的错误信息。使用结构化异常处理时，我们可以获取到和系统应用程序错误对话框一样多的信息。不过，这些信息只有在我们为发布版本创建映射或调试信息时才有用。我们可以在大多数环境中生成这些信息，而不会影响应用程序的大小和效率。在向用户报告错误时，要把握好分寸，既让用户明白错误的严重性，又不能让他们对软件的安全性失去信心。通常，我们可以使用类似“内部错误 — 请联系技术支持”这样的表述。

下面是一个简单的 mermaid 流程图，展示从严重错误中恢复应用程序的流程：

graph TD;
    A[发生严重错误] --> B[理解错误控制流并拦截];
    B --> C[定义错误拦截点];
    C --> D[进行设计考虑];
    D --> E[收集并报告错误信息];

2. 测试的使命与任务

测试是一项艰巨的任务，它既无限又不确定。无论测试人员怎么做，都无法确保能找出所有问题，甚至是所有重要问题。不过，我们可以将测试人员从对手转变为合作伙伴，充分发挥他们的优势。

2.1 测试的使命

在运行良好的项目中，测试团队的使命不仅仅是执行测试，更重要的是帮助降低产品失败的风险。测试人员要寻找产品中的明显问题、潜在问题以及不存在的问题，对产品质量进行探索、评估、跟踪和报告，以便我们在产品开发过程中做出明智的决策。

2.2 测试人员的主要任务

测试人员如果认真对待自己的使命，就必须完成以下五项主要任务：
1. 监控产品质量 ：这是测试的核心服务，包括质量规划、评估、跟踪和报告等子任务。质量报告不仅包括 bug 报告，还需要了解哪些部分运行正常、产品是如何被观察的以及识别问题所使用的标准。
2. 执行适当的测试过程 ：合适的测试过程能为质量评估提供可接受的置信水平。我们需要帮助测试人员了解产品中风险更高、更复杂的区域，让他们在这些地方投入更多精力。
3. 协调测试进度 ：测试人员要与项目中的其他活动保持进度协调，与开发人员并行工作。我们要让他们了解开发过程中的情况，邀请他们参加规划和状态会议。在接近发布里程碑时，要谨慎控制变更，减少引入新 bug 的风险，降低回归测试的工作量。
4. 与项目团队和利益相关者协作 ：测试人员是信息的传递者，他们的成功很大程度上取决于与产品开发其他职能部门以及项目团队外利益相关者之间的信息传递质量。与他们保持良好的沟通能带来诸多好处。
5. 学习与研究 ：学习是测试的基本组成部分。测试人员应该了解用户、产品技术以及各种测试技术，不断学习并总结经验，分析现场发现的问题，找出测试和开发过程中的漏洞并加以改进。

2.3 测试人员与开发人员的相互需求

角色	需要的信息	需要的服务
测试人员	产品是什么以及如何工作；产品的预期使用方式；产品中哪些部分更易出现故障；剩余开发工作的进度；产品任何更改或添加的状态和细节；已报告问题的状态	及时向测试人员提供信息；尝试理解测试过程；快速响应已报告的问题；与项目进度保持同步；合作设定合适的质量标准；让测试人员参与所有可能影响他们的决策
开发人员	发现的问题；产品中哪些部分似乎运行正常；用户对产品的看法；要测试的内容；测试进度；当前测试周期的状态；测试人员有效工作所需的信息	及时向开发人员提供信息；帮助开发人员了解用户；熟悉软件开发的一般过程；理解产品及其底层技术；快速响应新的构建版本；与进度保持同步，不拖延项目；合作设定合适的质量标准

下面是一个 mermaid 流程图，展示测试人员的主要任务流程：

graph TD;
    A[开始测试] --> B[监控产品质量];
    B --> C[执行适当测试过程];
    C --> D[协调测试进度];
    D --> E[与团队和利益相关者协作];
    E --> F[学习与研究];
    F --> G[持续改进测试工作];

3. 测试人员的特点与问题

3.1 测试人员的现状

许多测试人员并非真正对测试工作感兴趣，测试只是他们的工作而非职业追求。其中一部分是刚毕业的学生，他们把测试工作当作过渡，等待进入开发的“核心圈子”；还有一些是心怀不满的前开发人员，被“降职”到测试岗位。而且，很少有测试人员接受过专业的测试技能培训，也鲜有人阅读测试相关书籍或参加测试会议。即便有参加的，也常常感到困惑，因为现有的很多书籍和课程要么将测试视为需要正式规范和设计文档的严格数学分析，要么当作需要大量无人阅读和维护的测试文档的官僚式综合，这两种观点都不太适用于工业软件开发的实际情况。

3.2 优秀测试人员的特质

优秀的测试人员首先要是出色的批判性思考者，他们有着强烈的学习欲望，是充满活力的团队成员，并且具备良好的写作和表达能力。然而，如果公司只注重招聘技术背景强的人员，就很难找到这样的优秀测试人员。因为虽然技术知识很重要，但无畏质疑的习惯更难培养。

3.3 测试人员与开发人员之间的矛盾

3.3.1 角色定位差异

开发人员致力于创造成功的可能性，处于项目的前沿；而测试人员则专注于降低失败的风险，守护项目的侧翼。这两种角色之间存在天然的紧张关系，因为一种角色的成功可能会对另一种角色的目标产生潜在的负面影响。任何成功的可能性都伴随着一定的失败风险，关键在于双方在履行各自职责时，要充分考虑对方的使命。

3.3.2 关注点不同

开发人员通常更关注技术细节，而对过程或质量动态等抽象问题关注较少。这是因为开发软件需要熟练掌握技术和工具，而维持这种技能需要大量的时间和精力。虽然要生产高质量的软件还需要其他多种技能，但大多数开发人员认为技术知识是生存和成功的关键，这一点是正确的。而且，开发人员通常在项目后期才会关注测试人员的工作，而测试人员则始终关注开发人员的工作，这种关注点的差异也是矛盾的来源之一。

3.3.3 相互认知偏差

由于角色的不同，双方可能会觉得对方的工作不够专业。开发人员担心测试人员技术能力不足，而测试人员则担心开发人员过于关注技术细节，而忽视了产品的实用性。此外，双方往往对对方的工作需求缺乏了解，这也会导致合作中的问题。

3.4 与开发人员行为相关的测试问题

以下是一些与开发人员行为密切相关的测试问题：
1. 测试团队人员不足 ：开发人员对测试团队的人员配备有很大的影响力，他们可以支持或阻碍测试团队获取足够的人员。
2. 测试时间不足 ：开发人员在项目后期添加功能会给测试过程带来很大压力。虽然有时后期变更不可避免，但应该让测试人员参与决策过程，并提前提供尽可能多的信息。
3. 测试自动化持续失效 ：产品设计的变更，特别是用户界面元素的变更，可能会使自动化回归测试失效。开发人员应与测试人员合作，协调设计变更与测试自动化开发。
4. 测试结果因产品变更而无效 ：即使产品只有一位发生变化，也可能使所有测试结果失效。在项目接近尾声时，要严格控制变更，避免测试人员通宵处理风险。
5. 测试覆盖不全面 ：如果开发人员不提供基本的架构信息，测试人员可能会在整个项目中进行无效的测试。虽然规格和需求文档往往不准确且难以维护，但开发人员至少应该定期接受测试人员的访谈，介绍产品的工作原理。
6. 产品难以测试 ：如果开发人员不在代码中构建特殊的测试功能，有些产品将很难进行测试。例如，游戏开发人员会实现作弊代码和隐藏测试菜单来方便测试。
7. 产品质量不佳 ：产品质量始于开发人员。大多数质量问题是由开发人员的错误造成的。在将产品交给测试团队之前，开发人员应该先进行一些测试，以发现明显的问题。如果开发人员不坚持高标准，测试人员最终也会降低标准。

下面是一个表格总结这些问题：
|问题|描述|解决建议|
|----|----|----|
|测试团队人员不足|开发人员影响测试团队人员配备|支持测试团队获取足够人员|
|测试时间不足|项目后期添加功能压缩测试时间|让测试人员参与决策，提前提供信息|
|测试自动化持续失效|产品设计变更使自动化测试失效|与测试人员协调设计变更与测试自动化开发|
|测试结果因产品变更而无效|产品微小变更可能使测试结果无效|严格控制项目后期变更|
|测试覆盖不全面|开发人员不提供架构信息导致测试无效|定期接受测试人员访谈，介绍产品原理|
|产品难以测试|代码中未构建测试功能|在代码中添加特殊测试功能|
|产品质量不佳|开发人员错误导致质量问题|开发人员先进行测试，坚持高标准|

4. 开发人员促进测试人员融入工作的方法

4.1 明确共同使命

开发人员和测试人员的共同使命是推出优秀的产品。开发人员应秉持这样的态度：测试人员能帮助他们专注于可能性，同时避免风险。也要让测试人员接受这种观点。双方可能会在风险问题上存在分歧，但可以共同关注产品发布后的情况，并从中吸取经验教训。

4.2 加强沟通交流

开发人员应经常与测试人员会面，如有可能，坐在他们附近。询问他们的工作内容和方式，这种不经意的关注能极大地激励测试人员。

4.3 遵守协议承诺

开发人员要遵守与测试人员就产品功能添加、bug 修复协议等方面达成的协议。测试工作很容易受到意外变更的干扰，如果必须偏离协议，要尽快通知测试人员。

4.4 提升自身能力

开发人员要承担起改进自身流程、预防 bug 的责任。这样做能提高产品的可测试性，尤其是在项目早期。开发人员的行为会对测试人员产生很大影响，积极的行为能让测试人员成为充满活力、警惕的“护卫队”，帮助产品脱颖而出。

下面是一个 mermaid 流程图，展示开发人员促进测试人员融入工作的流程：

graph TD;
    A[明确共同使命] --> B[加强沟通交流];
    B --> C[遵守协议承诺];
    C --> D[提升自身能力];
    D --> E[实现良好协作，推出优秀产品];

总之，软件开发中的错误恢复和测试协作是一个复杂但重要的过程。开发人员和测试人员需要相互理解、密切合作，才能开发出高质量的软件产品，满足用户的需求。