代码审查和敏捷开发

敏捷软件开发是一种非常流行的软件开发模型，并在业界逐渐普及.

与传统的软件开发模型不同，敏捷开发模型具有自己独特的价值和方法.

其中，敏捷测试部分也不同于先前的软件测试过程. 这对测试人员提出了新的要求，并带来了新的挑战.

敏捷软件开发始于90年代中期. 最早是与传统的瀑布软件开发模型（瀑布模型）进行比较的，因此当时的方法称为轻量方法. 二十世纪初，这种方法的17位倡导者建立了敏捷联盟（Agile Alliance），并将软件开发方法称为敏捷软件开发过程.

敏捷联盟成立之初就总结了四个基本价值原则:

通过过程和工具软件产品进行个人和交互比通过全面文档进行工作的软件更为重要. 客户协作比合同协商（合同协商之上的客户协作）更重要. 一个计划）

基于这四个原则，敏捷软​​件开发有其独特的过程

图. 敏捷软件开发过程

整个过程与敏捷开发之前出现的许多软件开发方法混合在一起，包括极限编程（Extreme Programming，1996），Scrum（1986），功能驱动开发和测试驱动开发（Test Driven Development）等. 这些方法已在敏捷软件开发过程的所有阶段得到充分体现和应用.

例如，Scrum主要关注项目管理. 团队中的项目经理（Scrum管理员）需要在每个客户需求到达时制定Sprint周期，定义每个Sprint的目标，分配任务，进行监督，最后总结收益和损失并开始计划新的Sprint.

相比之下，功能驱动开发和测试驱动开发主要用于Sprint周期. 如果在新功能开发期间执行该项目，则此阶段将主要促进功能驱动的开发. 所有测试人员和开发人员都将重点放在新功能上，从开发和测试方面完成任务. 如果项目正在测试新功能，则此阶段需要将工作重点转移到测试上. 所有测试人员和开发人员都密切注意当前版本的缺陷状态. 测试人员需要在“每日站立会议”上报告在前一个工作日发现的新缺陷. 项目经理根据项目进度和缺陷的严重性来决定是否解决这些问题. 需要及时修复的缺陷是Sprint的一项新任务. 它会由项目经理添加到Sprint待办事项列表中，并通知开发人员修复漏洞.

对于敏捷开发和测试中的评审过程，极限编程中的同行评审思想已得到充分应用. 代码和文档审查既简单又高效. 团队成员组成一对并互相审查；有时，开发人员和测试人员也可以结成对并相互协作. 这可以帮助首先清除缺陷和问题.

敏捷开发还具有以下关键概念（关键问题）:

迭代过程，用户案例，任务，站立会议，持续集成，最简单的解决方案，重构

这些概念通常用于敏捷开发中. 下面我们将详细讨论测试人员在敏捷软件开发中的作用和功能.

本节将简要介绍测试人员在敏捷开发中的素质和职责.

我们的敏捷开发团队由四个开发人员，两个测试人员，一个产品设计，一个项目经理和一个产品经理组成（见图2）. 每天早上10点，在固定时间在会议室，团队将举行一次常设会议. 这时，团队成员向项目经理报告了前一天完成的任务，遇到的困难以及当天要完成的任务. 同时，项目经理会更新Sprint Backlog（一个精巧的Excel表），并迅速解决每个人提出的问题.

图2.敏捷开发团队的成员

由于敏捷开发要求参与者能够快速有效地响应变化，因此对测试人员提出了很高的要求.

测试是软件开发的组成部分. 在敏捷软件开发中也是如此. 不同的组织给测试人员以不同的头衔: 测试开发人员，质量分析师，软件质量工程师等.

每个标题暗示一个不同的功能. 以上标题符合以下能力要求:

具有质量检查和编写代码的能力->测试开发具有预防缺陷的能力（质量保证）和质量控制（质量控制）->质量分析员具有开发和执行测试程序的能力->软件质量工程师<

总的来说，有三个基本质量要求: 代码编写（编码），测试（测试）和分析（分析）.

在许多其他开发过程中敏捷软件开发 源码，测试人员的能力在每个测试阶段都是不同的；有时它侧重于分析（例如系统配置测试），有时侧重于代码编写（例如功能测试）. 但是，在敏捷开发过程中，测试人员需要结合这三个方面来进行工作. 只有这样，它们才能真正体现敏捷测试的本质: 简单高效地应对变化.

在敏捷软件开发中，测试人员的职责主要包括三个方面:

定义质量: 这应该是软件测试人员的基本职责. 敏捷方法鼓励测试人员在Sprint计划期间直接与客户沟通，并根据他们自己的经验共同制定产品功能的质量要求. 沟通不足（沟通）: 敏捷过程强调团队中的沟通. 开发人员通常将重点放在重要且新颖的功能上. 测试人员应掌握细节，并在设计中寻找“门遗漏”. 此外，开发人员使用单元测试来确保产品的基本质量. 测试人员可以使用验收测试（Acceptance Test）来识别客户需求和实际结果之间的不一致. 反馈: 敏捷过程强调简单性和效率. 测试人员需要及时提供有关当前产品质量问题的反馈. 这样，团队可以立即开始解决问题. 如果传统流程是每周汇总一次状态，则敏捷流程需要汇总每日质量问题. 在我们的项目中，内部测试报告将以网页的形式显示在内部站点上. 每个团队成员都可以随时获得它. 此外，我们的测试框架还提供了自助测试: 通过在测试用例列表中单击特定的用例，开发人员可以重现缺陷而不会中断测试人员的工作.

以上总结了测试人员在敏捷开发中需要演示的功能和任务. 下面，请遵循一个项目示例，以详细了解敏捷测试的最佳实践.

此部分结合了一个软件项目，以详细说明项目过程中的主要测试活动，每个活动的前提条件和目标任务.

项目简介: 根据B2B公司的要求，我们将开发类似于Google的搜索服务. 作为Web服务，该服务可以嵌入到网页中. 当用户输入关键字并选择商人的类型和位置时，系统将返回到特定商人的列表（请参见图3）.

图3.项目示例图

典型的敏捷开发和测试活动如下表所示. 它主要由三个部分组成，从最初的用户故事设计和发布计划，到对Sprint周期的多次迭发和测试，以及最终的产品发布阶段. 每个时间段都有相应的测试活动. 通常，Sprint周期分为两类: 功能周期（Feature Sprint）和发布周期（Release Sprint）. 功能周期主要涉及新功能的开发和各种测试. 发布周期将与计划结合以确定新版本功能，然后测试最新功能.

敏捷开发测试活动的主要活动

用户故事设计

找到隐藏的假设

发布计划

设计摘要的验收测试用例

迭代冲刺

预计验收测试时间

编码和单元测试

评估测试框架的构建

重构

详细的设计验收测试用例

集成

编写验收测试用例

进行验收测试

重构验收测试

冲刺结束

进行验收测试

下一个Sprint的开始

执行回归测试

发布

发布

在迭代Sprint周期中，根据传统步骤，开发部分可分为编码和单元测试，重构和集成. 应该注意的是，重构和集成是敏捷开发的Sprint迭代中不可忽略的任务. 如果要优化和改进新的Sprint周期中的最后一个功能，它将不可避免地与重构和集成密不可分.

在每个Sprint周期结束之前敏捷软件开发 源码，测试团队将针对Sprint周期或上一个Sprint周期中已完成的功能提交验收测试（在实际项目中，测试团队的进度通常晚于开发团队） . 这样，开发团队可以运行验收测试，以验证开发的功能当前是否符合预期. 当然，这种期望在迭代中不断变化和提高.

当产品的所有功能都可以实现并且测试工作基本完成时，它将进入发布周期. 目前，测试团队的任务相对较多.

在上面，我们概述了敏捷开发的主要活动. 下面我们将详细介绍和分析每个阶段相应的测试活动. 首先是用户故事的设计和发布阶段.

在用户故事和发布计划阶段，项目经理和产品经理将根据客户需求制定汇总的产品发布时间表. 此时，测试人员可以与开发人员一起学习新功能，以了解客户需求. 其中有两个主要活动: 找到隐藏的假设和接受设计大纲的测试案例.

3.2.1查找隐藏的假设

如上所述，开发人员通常会注意一些重要的系统功能，而忽略细节. 此外，敏捷开发提倡一个简单的实施计划. 在每个开发Sprint周期中都不可能实现完美的功能；相反，每个Sprint将逐步开发一些功能. 因此，测试人员需要从各个角度查找系统需求，并从一开始就探索隐藏的假设.

项目示例:

从B2B公司的角度考虑问题: 该搜索框对公司的业务有何价值？

A: 搜索框可以方便用户获取提供者的目录信息. 如果越来越多的用户使用此搜索框，则可以增加访问我们网站的次数. 从用户角度思考问题: 当网站用户查找信息并寻找业务合作伙伴时，搜索框对我有什么好处？

A: 劣势: 查找商人的地址，只是发现它过去已经关闭或关闭. 好处: 只需单击鼠标，即可轻松找到商户

令人不愉快: 有时会寻找一类商人，但不​​记得具体的名称. 从程序员的角度思考问题: 实现搜索框的最简单方法是什么？

A: 由文本输入和搜索按钮组成的表单；后台将通过服务器程序从中取出匹配类型和地址的企业名称，并将其返回给用户；每个退回的商品均包括商家名称，地址和评估意见. 在这些问题中寻找问题问: 当用户忘记其特定姓名时，搜索框如何提醒用户？

A: 在第一个版本中很难实现. 用户可以输入至少一种类型以提高模糊搜索的效果. 终于找到了隐藏的假设

以上想法使测试人员对系统的隐含假设更加清晰:

首先，该系统应该能够在高峰时间处理200个搜索请求和1000个鼠标单击事件.

第二，用户可以继续在找到的内容中搜索

最后，系统提供商家类别的列表；如果用户选择了商家类别却忘记了特定名称，则系统会提供模糊查询.

在敏捷开发中，这些假设可以记录为用户案例，以指导未来系统的开发和测试.

3.2.2设计摘要的验收测试用例

在定义了一系列用户故事之后，测试人员可以继续设计汇总验收测试用例. 正如我们前面讨论的，与单元测试不同，验收测试将检查系统是否满足客户期望，即是否可以实现用户故事. 因此，测试人员可以根据每个用户故事进行扩展，在其中寻找“动作”，然后为每个“动作”制定正面和负面的例子.

项目示例:

动作数据的预期结果

搜索

可以成功搜索的一组（类别，位置）数据

类别和位置条件下的一组业务信息

搜索

一组无法成功搜索的（类别，位置）数据

空列表

当Sprint周期正式开始时，项目经理将为周期制定具体的开发和测试任务. 在例行的Sprint计划会议上，每个团队成员必须为未来的Sprint周期提供自己的假期和培训计划. 另外，每个团队可以根据各自团队成员的能力和工作经验来适当地设置一个负载因子（Load Factor）. 例如，我们团队的工作量值为75％，这意味着每个人平均每天工作6个小时（按8个小时计算）. 然后，每个人都可以开始分配任务.

当开发团队开始编码和单元测试时，测试人员的工作重点包括: 估计验收测试的时间，估计测试框架的结构，详细设计验收测试以及编写验收测试代码. 第二项主要活动通常在项目的初始Sprint周期内完成. 其他三个主要活动将在以下多个Sprint周期中适当地迭代执行. 下面我们将详细介绍每个主要活动.

3.3.1预计验收测试时间

在软件开发的早期阶段，需要估计时间以制定计划. 这在敏捷开发中被更广泛地使用. 如果以前的开发模型要求测试人员估算软件版本的发布计划（这种计划通常持续数月），那么现在有必要在每次Sprint机会会议上估算从两周到一个月的任务. 此外，在日常例行会议中，测试人员需要不断更新其估计时间，以响应不断变化的需求. 因此，每个测试人员都应该具有估计任务的能力. 下面，我们将介绍两种估计测试计划的通用方法:

快速粗略方法

就经验而言，测试通常占项目开发时间的三分之一. 如果一个项目开发估计每天需要30个人，那么测试时间为每人10天.

项目示例:

搜索框的开发估计每天需要78人. 但是，考虑到系统具有模糊搜索的功能，测试任务可能会占31％的40％，大约1个人. 下面列出了具体任务:

任务估计时间

设计测试用例并准备测试数据（搜索数据集）

8

加载数据集

2

编写自动测试代码

18

执行测试并报告结果

3

摘要

31

详细而全面的方法

此方法从测试任务的基本步骤开始，并执行详细的分类. 这些包括:

测试准备（设计测试用例，准备测试数据，编写自动化测试代码并改进代码）有关测试操作（建立环境，执行测试，分析和报告结果）的特殊注意事项

项目示例:

估计单个测试任务的示例如下表所示:

测试准备和特殊考虑评估

1

设计测试用例

0.5

创建环境

0.1

准备测试数据

0.5

运行测试

0.1

编写自动测试代码

0.5

分析结果

0.1

改进自动测试代码

2.5

报告结果

0.1

总计

4

0.4

4.4

有关估计的多个测试任务的摘要，请参见下表:

测试任务编号准备运行特殊考虑评估

1

4

0.4

4.4

2

4

0.4

4.4

3

12

4.5

8.5

25

4

4

0.4

4.4

5

4

0.4

4.4

6

4

0.4

4.4

7

4

0.4

4.4

总计

51.4

3.3.2评估测试框架的构建

测试框架是自动化测试的重要组成部分. 由于敏捷开发过程主张快速高效地完成任务，因此这需要一定的自动测试率. 完善的测试框架可以大大提高测试效率并及时反馈产品质量.

在敏捷开发过程中，在第一个Sprint周期中，需要添加建立测试框架的任务. 在随后的迭代中，仅当需要对测试框架进行重大调整时，测试团队才需要将其单独视为一项任务，否则它可能不会被列为主要任务.

项目示例:

考虑到该项目刚刚进入测试阶段，需要为此建立一个测试框架. 结果，更多的任务被添加到原始估计中.

任务估计（小时）

选择测试工具

3

建立测试系统

3

编写脚本以下载，存储和还原测试数据

2

查找或创建测试结果报告工具

8

设计特定的搜索测试用例

4

准备搜索测试数据

4

编写并测试“搜索”模块

3

编写并测试“验证退货清单”模块

1

了解“搜索结果”的模块设计

4

编写并测试“搜索结果”模块

4

第一次运行测试

4

分析第一轮测试的结果

4

第二次运行测试

4

分析第二轮测试结果

4

总计

52

3.3.3详细的设计验收测试用例

完成测试任务的评估，然后可以继续详细设计验收测试用例. 我们可以在摘要设计中优化测试用例，并根据不同的测试环境，测试数据和测试结果编写更详细的测试用例. 此外，您可以结合多个用例来完成复杂的测试操作.

由于敏捷开发的过程是一个反复的过程，因此在未来的Sprint周期中可能会优化许多复杂的功能. 对于测试人员来说，一种有效的方法是尝试使用一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case），以实现首次自动化. 对于某些复杂的功能测试用例，您可以先采用手动方法测试，然后考虑自动化，直到功能在下一个Sprint周期稳定为止. 此外，您可以针对测试中出现的缺陷设计回归测试用例（Regression Test Case），并为它们编写自动测试代码，以便可以在发行周期（Release Sprint）中平稳有效地验证此类问题.

项目示例:

基本验证测试用例:

动作数据的预期结果

登录

用户名: （空）

密码: （空）

“无效的用户名和密码”

功能测试用例:

动作数据的预期结果

登录

正确的用户名和密码

输入系统: 请输入搜索条件，然后单击“搜索”按钮

搜索

错误类型

提示正确的类型

搜索

使用正确的类型

商家信息

3.3.4编写验收测试用例

敏捷开发并不主张编写太多文档，而是主张直接编写测试用例. 此外，测试人员和客户应获得良好的沟通，总结这些要求，并将其转变为验收测试用例. 如果资源充足，则最好为验收测试用例建立版本控制机制.

考虑到需求将在每个Sprint周期内不断变化，因此测试团队应控制测试的自动化速度并正确估算未来功能的增加或减少. 高自动化率将导致大量测试代码在以后重构，但会增加工作量.

在Sprint周期结束时，团队将举行回顾会议. 团队成员可以在会议上畅所欲言，并指出在过去的Sprint周期中可行，不可行以及需要改进的地方. 需要改进的领域将在项目经理的监督下在未来的Sprint周期中实施.

由于敏捷开发主张增量开发，因此当新的Sprint开始时，测试团队需要根据新的Sprint周期的开发进度及时重建验收测试. 如果在新的Sprint周期中没有特定的新功能开发，则测试团队可以专注于执行验收测试和发现缺陷.

如果下一个Sprint周期是发布周期，则测试人员需要准备执行回归测试. 让我们仔细看看每个测试活动.

3.4.1重建验收测试

如上所述，敏捷开发是以迭代方式进行的，每次迭代中都引入了新功能. 因此，通常需要修改或添加验收测试用例，并且还需要删除相应的验收测试代码. 如果这部分工作需要很多时间，则最好将其放在一起进行估算.

项目示例:

在下一个Sprint周期中，我们需要实现以前未实现的“模糊搜索”功能. 测试人员应在新的Sprint周期中更新原始的验收测试用例，并在测试“搜索”模块中添加模糊搜索测试. 重新估计的测试任务将包含在下表中:

任务估计时间

设计测试用例并准备测试数据（模糊搜索数据集）

2

加载数据集

1

编写自动测试代码

3

执行测试并报告结果

2

摘要

8

3.4.2执行验收测试

验收测试可以分为两类，基本验证测试和功能测试. 如果这是基本的验证测试，建议开发人员在运行单元测试和提交代码之前直接运行自动测试脚本. 如果是功能测试，则可以在每个Sprint的后期提交新的功能代码后，由测试人员分别执行.

敏捷开发和测试是相辅相成的. 一旦基本验证测试出现问题，则意味着开发人员的实现违反了原始的客户定义要求，因此无法提交. 如果功能测试存在问题，则测试人员应及时与开发人员联系. 如果是缺陷，则需要及时报告给项目经理，并在日常常务会议上提出. 如果不是，则继续下一个任务. 这个过程充分体现了敏捷开发提倡的团队沟通机制.

3.4.3执行回归测试

在发布周期中，测试人员的任务非常重要，因为这是产品发布之前的最终质量检查.

首先，我们必须建立一个框架，用于自动生成构建，运行自动测试代码，手动执行测试用例以及总结测试结果. 估算方法已包含在上面.

第二，定期执行各种测试，包括功能测试和系统测试.

最后，我们必须整理每个功能测试周期之前发生的问题. 如果已将其归类为回归测试用例，则只需定期执行；否则，需要一一添加. 如果用例已经自动化，则可以直接运行；如果是手动测试，则测试人员需要根据测试用例进行操作，并最终汇总测试结果. 测试的这一部分称为回归测试.

以上我们回顾了整个项目开发中敏捷测试的基本过程. 详细介绍了每个阶段的主要测试活动，并结合实际项目，并描述了每个测试活动的最佳实践.

最后，让我们讨论测试中的两个问题: 手动测试和测试报告.

手动测试和自动测试是两种主要的测试类型. 考虑到敏捷开发的效率，自动化测试将比手动测试更好. 手动测试有两个主要缺点: 不可靠且容易被遗忘. 例如，在文本的搜索示例中，一旦我们重新编制索引，就无法再现搜索文本中先前的文本错误. 此外，当测试人员必须手动逐个完成测试用例时，他们很容易忘记一些特殊的测试用例，并且掩盖了许多缺陷. 敏捷测试提倡一些基本的验收测试可以自动化. 对于涉及系统的测试，手动测试更为合适.

测试报告是反映测试团队工作的最佳结果. 为了适应敏捷开发的节奏，可以将测试报告以网页的形式发布在内部Web服务器上，并且将一些问题区域标记为鲜艳的颜色，以警告团队中的每个人.

总而言之，本文详细讨论了敏捷开发中的测试任务. 我希望本文能帮助正在使用敏捷或打算使用敏捷的团队更好地了解敏捷测试.

很久以前就有这样的想法: 开发一套有效的管理软件，用于软件开发行业中的项目管理. 这个想法的原因与我自己的经验有关. 在最初的几年中，当我在**系统上工作时，部门主管要求我根据Visual Basic和adodb进行此类操作. 那时，确实确实缺乏经验，远见和想法. 我这样做是出于尝试和研究的考虑. 好吧，仅限于上述限制. 我应该说些什么？看起来很琐碎，因为没有特殊的界面设计，UI设计不是大气的，部门内部只能实现基于LAN的任务分配，每周报表编写和文档上传.

1. Leangoo，我通过搜索学习了此工具. 通过该网站，我注册了一个帐户，创建了新产品积压订单，并检查了该网站的一些现有示例. 总体而言，敏捷开发已集成在一起. 管理理念，观点清晰，感觉很好.

2. Teambtion，这是我以前学过的软件. 它具有版本和应用程序版本. 任务管理和FAQ管理也不错，但是任务卡，看板和敏捷管理燃尽图的概念并未出现在软件中. 最让我印象深刻的是常见问题解答. 也许这与我的工作性质有关. 我个人认为此模块更实用. 这些是先前的条件. 我不知道是否有任何修订. 我很久没读它们了. 也许有更新.

3. 可行的. 在Worktile中，我们输入的默认页面是IM“消息”. 这种即时消息传递功能是通信的体现. 在企业协作场景中，任务是沟通的最初结果，是后续工作的核心，而Worktile的核心是任务.

·

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/ruanjian/article-251903-1.html