45、软件开发中的测试与协作

软件开发中的测试与协作

1. 增加测试复杂度

当基本测试用例通过后，就应开始添加更多测试用例，包括边界条件和极端情况。这些测试可能会揭示程序员或测试人员对需求的误解，或者表明需求本身的含义未被大家完全理解。重要的是，团队成员要就此进行讨论并达成共识。

在测试人员构思可执行测试的新场景时，也应考虑手动探索性测试的潜在场景，并记录下来以备后续研究。要牢记这些测试的目的，它们应为程序员提供编写代码的示例。随着代码的演进，测试可以更具挑战性，但不要急于陷入极端情况，应先确保基本功能正常工作。如果通过风险分析想到更多测试用例，随时可以添加额外的测试。

2. 风险评估

长期以来，测试人员一直使用风险分析来确定测试的优先级，敏捷开发也将风险考虑在内。高风险的故事可能会有更高的规模估计，团队在发布和迭代规划时会考虑风险来确定故事的优先级。

快速的风险分析有助于确定首先要进行的测试以及重点关注的方向。由于时间有限，我们无法对所有内容进行测试，因此可以利用风险分析来确定测试的合理范围。

对于复杂的故事，可以按以下步骤进行风险评估：
1. 列出与该故事相关的所有潜在风险，不仅限于功能方面，还应考虑安全、性能、可用性等因素。
2. 对每个风险项，使用1 - 5的等级（或适合的其他等级）评估其发生时对业务的影响，1表示影响较小，5表示严重的负面影响。
3. 同样使用1 - 5的等级评估每个风险项发生的可能性，1表示极不可能发生，5表示很可能发生。
4. 将影响等级和可能性等级相乘，得到每个风险项的总风险评级。

这样就能轻松确定团队应首先关注的测试领域。低风险项可以最后处理，或者由于其影响较小或发生可能性极低，甚至可以不进行测试。

不同的领域对风险的处理方式不同。例如，测试心脏起搏器软件时，无论风险多低或多不可能发生，都需要进行全面测试；而测试公司内部供少数专业人员使用的Web应用时，可以跳过不太可能发生或有明显解决方案的场景。

以下是一个运费故事的风险评估示例：
| # | 项 | 影响 | 可能性 | 风险 |
| — | — | — | — | — |
| 1 | 显示的费用不正确 | 4 | 2 | 8 |
| 2 | 用户无法选择不同的运输选项 | 5 | 1 | 5 |
| 3 | 商品不符合所选运输选项，但仍允许选择 | 3 | 2 | 6 |
| 4 | 结账时估计费用与实际费用不符 | 3 | 4 | 12 |
| 5 | 输入无效邮政编码未被验证捕获 | 4 | 1 | 4 |
| 6 | 用户无法理解运输选项规则 | 2 | 3 | 6 |
| 7 | 用户无法更改送货地址 | 5 | 2 | 10 |
| 8 | 用户更改送货地址，但费用未相应更改 | 5 | 4 | 20 |

从这个示例可以看出，第8项风险最高，因此应确保测试更改送货地址并验证更新后的费用，甚至可以自动化此场景的端到端测试。而对于第5项，可能之前已经对邮政编码验证进行了测试且效果良好，就无需再次测试。

同时，要注意过往的问题，避免再次发生。

3. 编码与测试协同推进

在迭代过程中，编码和测试应齐头并进。测试人员、程序员、数据库专家和其他团队成员应根据示例和测试提供的指导，协作开发故事。不同成员发挥各自的专业知识，但都要对完成每个故事负责，并且在工作过程中相互学习。

以运费故事为例，程序员Patty领取了编写运费估算代码的任务。她通过前期讨论已对故事有了较好的理解，还可能查看了测试人员在维基页面或故事卡背面记录的故事目的、工作示例和高级测试，以明确工作方向。测试人员Tammy看到编码工作开始后，开始编写成本计算的GUI后测试用例。

团队计划先根据送货地址和商品重量计算5天的运费，且商品只能在北美大陆内运输，此验证将在表示层进行，因此成本计算测试可假设输入的是有效目的地。他们使用运输合作伙伴提供的成本计算API，Tammy向Patty询问算法位置，以便自行计算成本并编写测试。Tammy在GUI后测试工具中编写了最简单的测试用例：
| 重量 | 目的地邮政编码 | 费用 |
| — | — | — |
| 5 lbs | 80104 | 7.25 |

由于Patty尚未完成使该测试通过的代码，Tammy开始着手该故事的另一个测试任务，即设置与运输合作伙伴测试系统配合的测试环境。

4. 识别变化

由于这个故事和测试较为简单，Patty和Tammy没有像处理复杂故事那样讨论和调整测试设计，也无需向产品负责人询问更多问题。当Patty完成简单测试后，Tammy编写了更多测试用例，尝试了美国境内不同的重量和目的地，一切正常。但当她尝试加拿大邮政编码时，测试出现异常。她将此情况告知Patty，Patty发现API默认使用美国邮政编码，加拿大和墨西哥的代码需要国家代码，且她尚未为其他国家编写单元测试。

他们修改了测试输入，Patty与Paul合作修改调用API的代码。修改后的测试用例如下：
| 重量 | 目的地邮政编码 | 国家代码 | 费用 |
| — | — | — | — |
| 5 lbs | 80104 | US | 7.25 |
| 5 lbs | T2J 2M7 | CA | 9.40 |

这个简单的例子展示了编码和测试之间的迭代过程。不同团队有不同的工作方式，例如Patty和Tammy可以在编码和测试上进行配对；Tammy可以与Paul合作编写自动化测试的夹具；Tammy可以在远程办公室使用在线协作工具与Patty合作；Patty也可以自己编写可执行的故事测试，然后编写代码使测试通过。关键是，测试和编码是一个所有团队成员都参与的开发过程。

Tammy可以继续识别新的测试用例，包括极端情况和边界条件，直到她认为所有风险领域都已被最少数量和种类的测试用例覆盖。有些极端情况发生的可能性极低，可以不进行测试，或者测试通过后不将其纳入回归测试套件。有些测试在UI可用后手动进行可能更好。

5. 三人原则

Patty编写了以夏威夷为送货目的地的单元测试，但Tammy认为只有北美大陆的目的地才被接受，两人都不确定军事邮政信箱目的地是否可行。于是他们去找产品负责人Polly询问意见，这就是“三人原则”的应用。当出现分歧或问题时，听取三个不同的观点有助于找到更好的解决方案，避免后续再次讨论。如果参与讨论的人对主题不熟悉，其他人需要清晰地组织思路进行解释，这也很有帮助。让不同角色的人参与可以确保需求的变化不会被忽视，避免后续给团队成员带来意外。

当出现意外问题时，“三人原则”是一个很好的起点。根据问题的严重程度和复杂程度，可能需要召集更多人甚至整个团队。例如，如果运输合作伙伴的API速度过慢，导致网站响应时间不可接受，开发团队和客户团队需要迅速探索替代解决方案。

6. 专注于一个故事

程序员Paul在寻找编程任务时，尽管运费故事的UI任务还在任务板的“待办”列，但他对删除购物车中商品的故事更感兴趣，于是领取了相关任务卡。由于还没有人开始为该故事编写可执行测试，他便独自开始工作。

此时团队同时进行两个故事的开发，但不确定完成每个故事所需的时间。更好的做法是Paul先处理第一个故事的UI任务，以便尽快完成该故事。当一个故事完成（即所有代码编写并测试通过）时，就清楚知道该故事没有剩余工作了。即使在本次迭代中其他故事未能完成，至少有一个完成的故事可以发布。

完成整个故事并非只是测试概念，测试人员应积极推动和遵循。如果程序员开始编写某个故事的代码，应确保有人同时开始该故事的测试任务。这需要进行平衡，如果删除商品故事甚至还没有高级测试，那么它可能是最高的测试优先级。通常，在团队开始下一个故事之前，应先完成当前故事。

除非团队非常小，否则通常会同时进行多个故事的开发。尽管这可能更具挑战性，但应尽量一次专注于完成一个故事。例如，Patty即将完成运费故事，Paul转向删除商品故事，而Patty遇到问题时，Paul帮助她完成代码，使Tammy能够完成探索性测试并将该故事标记为“完成”。这样团队就能更清楚本次迭代还剩下多少工作。

有时候，如果程序员和测试人员配对完成每个故事，并且故事较小且相互独立，多个故事可以同时完成。但要避免程序员在没有完成测试任务的情况下开始编码。

7. 产品批判性测试

当可测试的代码块可用且指导编码的自动化测试通过后，应深入探索功能，尝试不同的场景，了解代码的行为。应准备业务和技术方面的产品批判性测试任务卡，只有完成所有这些测试，故事才算真正完成。

当一个故事除测试外的所有任务都完成时，这种测试尤为重要。此时应能够对故事的整个流程进行测试，包括各种变化情况。不要推迟这种测试，因为可能会发现开发过程中被测试遗漏的需求，从而及时编写缺失的测试和代码。在团队仍专注于该故事时填补这些空白可以增加更多价值，而后续再处理则成本更高。

在测试最终故事时，可能会发现一些“锦上添花”的功能，例如使功能更易用或更快，但这些并非原始故事的一部分。此时应与客户协商，如果迭代中有时间且业务能从中受益，可以添加这些功能，因为现在添加的成本较低。但不要因添加回报率不高的“装饰性”功能而影响其他故事的进度。

如果探索性测试使团队和客户意识到故事未涵盖重要功能，应为后续迭代编写新的故事。要严格控制“范围蔓延”，否则团队将无法按时交付原计划的价值。

8. 与程序员协作

测试人员和程序员在编码和测试过程中密切协作。这种协作不仅增强了团队交付正确产品的能力，还提供了技能转移的机会。程序员可以学习新的测试方法，提高编写代码时的自我测试能力；测试人员可以更了解编码过程，明白合适的测试如何使编码更轻松。

8.1 配对测试

程序员Paul完成了运费选项故事的用户界面，但尚未提交代码。他邀请测试人员Tammy一起查看，演示了用户在结账过程中输入送货地址的操作，运费立即显示。Tammy更改送货地址后看到新的费用更新，输入与地址不匹配的邮政编码时看到了相应的错误消息。两人都认为UI没问题，于是，Paul提交了代码，Tammy继续进行手动探索性测试。

测试人员Janet喜欢在配对测试时让程序员操作，自己观察，她认为这样比自己操作而让程序员观看更有效。

8.2 “给我展示”

Tammy特别关注更改送货地址后运费重新计算的问题，因为这是一个高风险领域。她发现，先显示运费，然后进入账单地址页面，再返回更改送货地址时，运费没有正确更新。她让Paul来观察这个问题，Paul意识到是会话缓存存在问题并回去修复。

向他人展示问题并一起解决比在缺陷跟踪系统中提交缺陷报告并等待他人处理更有效。如果团队成员不在同一地点工作，尤其是处于不同时区时，这种方式会更困难。应尽量采用最直接的沟通方式。例如，Lisa的一位队友所在时区比她早12.5小时，该队友会工作到深夜，必要时会打电话给Lisa，两人一起处理测试结果和示例。

向他人展示GUI可能会帮助Paul意识到自己实现的错误行为。同样，如果Tammy的GUI测试脚本无法正常工作，解释问题的过程可能会让她自己找到原因。如果没有人可以查看代码或帮助调试问题，有时向自己大声解释问题也会有帮助，“橡皮鸭调试法”和“大声思考”是解决问题的有效方法。Janet会在桌上放一只小橡皮鸭，提醒自己在提问前先思考。

9. 与客户沟通

开发团队成员很容易埋头编写故事而忘记与客户保持沟通。除了在有问题时咨询业务专家外，还需要向客户展示已交付的内容。

如果在编码开始前能与客户或代表客户的人一起审查测试用例最好，如果没有，也为时不晚。对于需要客户更深入参与可执行测试细节的情况，要确保找到适合客户和技术团队成员的测试工具。

在迭代计划中，如果有制作报告或界面原型的任务，应保持过程简单。例如，能用白板绘制就不要编写HTML原型，因为简单性是核心价值。

一旦编码完成的用户界面或报告可用，即使还很简陋、缺少某些功能或显示硬编码数据，也应展示给相关客户。因为客户只有通过实际查看、感受和使用应用程序，才能确定其是否符合需求。

以下是整个开发过程的流程图：

graph LR
    A[增加测试复杂度] --> B[风险评估]
    B --> C[编码与测试协同推进]
    C --> D[识别变化]
    D --> E[三人原则]
    E --> F[专注于一个故事]
    F --> G[产品批判性测试]
    G --> H[与程序员协作]
    H --> I[与客户沟通]

通过以上各个环节的有效执行和协作，可以提高软件开发的质量和效率，确保最终产品满足客户需求。

软件开发中的测试与协作

10. 风险评估的实际应用

风险评估在软件开发过程中起着关键作用。通过对潜在风险进行系统的分析和评估，团队能够更有针对性地分配测试资源，确保高风险领域得到充分测试。以下是风险评估的详细步骤和应用示例：

• 列出潜在风险 ：对于一个复杂的软件项目，需要全面考虑各种可能的风险，不仅包括功能方面，还应涵盖安全、性能、可用性等多个维度。例如，在一个电子商务网站的开发中，可能的风险包括用户登录失败、支付处理错误、页面加载速度过慢等。
• 评估影响等级 ：使用1 - 5的等级对每个风险项发生时对业务的影响进行评估。影响等级越高，说明该风险对业务的损害越大。例如，支付处理错误可能会导致用户资金损失，对业务的影响较大，可评为5级；而页面上的一个小错别字对业务的影响较小，可评为1级。
• 评估可能性等级 ：同样使用1 - 5的等级评估每个风险项发生的可能性。可能性等级越高，说明该风险发生的概率越大。例如，在一个新开发的系统中，由于技术不成熟，某些功能出现故障的可能性较高，可评为4级；而一些经过多次测试和验证的功能，出现问题的可能性较低，可评为1级。
• 计算总风险评级 ：将影响等级和可能性等级相乘，得到每个风险项的总风险评级。总风险评级越高，说明该风险的优先级越高，需要优先进行测试。例如，一个风险项的影响等级为4，可能性等级为3，则总风险评级为12，应重点关注。

以下是一个风险评估的示例表格：
| 风险项 | 影响等级 | 可能性等级 | 总风险评级 |
| — | — | — | — |
| 用户登录失败 | 4 | 3 | 12 |
| 支付处理错误 | 5 | 2 | 10 |
| 页面加载速度过慢 | 3 | 4 | 12 |
| 页面错别字 | 1 | 2 | 2 |

根据这个表格，团队可以优先测试“用户登录失败”和“页面加载速度过慢”这两个高风险项，而对于“页面错别字”这个低风险项，可以放在最后进行测试，或者根据实际情况决定是否进行测试。

11. 编码与测试的协同工作模式

在软件开发过程中，编码和测试是紧密相连的两个环节。有效的协同工作模式能够提高开发效率，确保软件质量。以下是几种常见的编码与测试协同工作模式：

• 测试驱动开发（TDD） ：程序员先编写测试用例，然后编写代码使测试通过。这种模式能够确保代码的可测试性和正确性，同时也能帮助程序员更好地理解需求。例如，在编写一个函数时，先编写该函数的测试用例，定义函数的输入和输出，然后编写函数代码，直到测试用例通过为止。
• 行为驱动开发（BDD） ：测试人员和程序员一起编写可执行的测试用例，使用自然语言描述系统的行为。这种模式能够促进测试人员和程序员之间的沟通和协作，确保双方对需求的理解一致。例如，使用Gherkin语法编写测试用例，描述用户的操作和系统的响应。
• 并行开发与测试 ：程序员和测试人员同时进行工作，程序员编写代码，测试人员编写测试用例。这种模式能够加快开发进度，但需要确保双方的工作能够及时同步，避免出现测试用例与代码不匹配的情况。例如，在一个敏捷开发团队中，程序员和测试人员在同一个迭代中同时进行编码和测试工作。

以下是一个编码与测试协同工作的流程图：

graph LR
    A[需求分析] --> B[测试用例编写]
    A --> C[代码编写]
    B --> D[测试执行]
    C --> D[测试执行]
    D --> E{测试是否通过}
    E -- 是 --> F[代码部署]
    E -- 否 --> G[代码修复]
    G --> C[代码编写]

12. 团队协作的重要性

在软件开发项目中，团队协作是成功的关键因素之一。不同角色的成员，如程序员、测试人员、数据库专家等，需要密切合作，共同完成项目目标。以下是团队协作的几个重要方面：

• 知识共享 ：团队成员之间应积极分享自己的知识和经验，促进彼此的学习和成长。例如，程序员可以向测试人员介绍代码的实现细节，测试人员可以向程序员反馈测试过程中发现的问题和建议。
• 沟通协调 ：良好的沟通是团队协作的基础。团队成员应及时、准确地沟通项目进展、问题和解决方案。例如，通过每日站会、定期的项目会议等方式，确保团队成员之间的信息畅通。
• 责任共担 ：每个团队成员都应对项目的成功负责，共同努力解决遇到的问题。例如，当一个故事出现问题时，整个团队应一起分析原因，寻找解决方案，而不是互相推诿责任。
• 互相支持 ：在项目开发过程中，团队成员可能会遇到各种困难和挑战，此时需要互相支持和帮助。例如，当一个程序员遇到技术难题时，其他程序员可以提供技术支持和建议。

13. 应对意外问题的策略

在软件开发过程中，意外问题是不可避免的。以下是一些应对意外问题的策略：

• 快速响应 ：当出现问题时，团队应立即采取行动，快速响应问题。例如，当发现一个严重的缺陷时，应立即停止当前工作，集中精力解决问题。
• 问题分析 ：对问题进行深入分析，找出问题的根源。例如，通过调试代码、查看日志文件等方式，确定问题发生的原因。
• 制定解决方案 ：根据问题的分析结果，制定相应的解决方案。例如，如果问题是由于代码逻辑错误导致的，应修改代码；如果问题是由于环境配置问题导致的，应调整环境配置。
• 验证解决方案 ：在实施解决方案后，应进行验证，确保问题得到解决。例如，重新运行测试用例，检查问题是否仍然存在。

以下是一个应对意外问题的流程图：

graph LR
    A[发现问题] --> B[问题分析]
    B --> C[制定解决方案]
    C --> D[实施解决方案]
    D --> E{问题是否解决}
    E -- 是 --> F[结束]
    E -- 否 --> B[问题分析]

14. 总结

软件开发是一个复杂的过程，需要测试、编码、协作等多个环节的紧密配合。通过增加测试复杂度、进行风险评估、编码与测试协同推进、识别变化、应用三人原则、专注于一个故事、进行产品批判性测试、与程序员和客户有效协作等方法，可以提高软件开发的质量和效率，确保最终产品满足客户需求。

在实际项目中，团队应根据项目的特点和需求，灵活运用这些方法和策略，不断优化开发流程，提高团队的协作能力和问题解决能力。同时，要注重团队成员之间的沟通和知识共享，营造良好的团队氛围，使团队能够更好地应对各种挑战，实现项目的成功。

总之，软件开发不仅仅是技术的实现，更是团队协作和沟通的过程。只有通过有效的协作和沟通，才能打造出高质量、满足用户需求的软件产品。