测试知识体系一

wubba_lubba
192 阅读15分钟

转载：测试开发知识图谱 - 掘金 (juejin.cn)

1 测试方法与理论

名称相关知识点
1.1 软件开发生命周期SCRUM/XP、持续集成/持续交付/DevOps
1.2 测试流程体系传统测试流程、测试左移、测试右移
1.3 测试技术体系分层测试体系、单元测试、UI 测试、接口测试、白盒测试
1.4 测试经典书籍全程软件测试、探索式测试、持续交付、Google 测试之道、不测的秘密

1.1软件开发生命周期

敏捷开发方法——XP及SCRUM

什么是敏捷开发？

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法，就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。

什么是迭代？

迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

   敏捷的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver Development），水晶开发（Crystal Clear）等等。

Scrum

Scrum 是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程，是敏捷开发的一种实现机制。Scrum以经验性过程控制理论（经验主义）为理论基础，主张知识源于经验, 以及基于已知的东西做决定。Scrum 采用迭代、增量的方法来优化可预见性并控制风险。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个冲刺（Sprint）。

当前Sprint需要完成的任务会展现在特别设计的面板上，清晰地展示每个任务的负责人、当前状态、实现过程中的问题和变更等等信息。项目团队和各利益攸关方能清晰地把握每个任务的开发进度和遇到的问题，并以此分析、控制项目的进度、成本和风险。

    Scrum以站立会作为项目规划、过程控制和资源分配的内部交流协商机制。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。

【Scrum开发流程中的三大角色】

  • 产品负责人（Product Owner）

    主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

  • 流程管理员（Scrum Master）

    主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

  • 开发团队（Scrum Team）

    主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。


如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出多个Story作为本次迭代中的多个build要完成的某个功能点，这个目标的时间周期通常是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务。

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）即kanban；

6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

Scrum重要特征：

1)迭代开发。在Scrum的开发模式下，我们将开发周期分成多个1-4周的迭代，每个迭代都交付一些增量的可工作的功能。迭代的长度是固定的，如果我们选择了1周的迭代，那么保持它的长度不要发生变化，在整个产品开发周期内每个迭代都是1周的长度。这里需要强调的是在每个迭代必须产出可工作的增量功能，而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。

2)增量交付。增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品待办事项列表条目的总和。在 Sprint 的结尾，新的增量必须“完成”，这意味着它必须可用并且达到了 Scrum 团队 “完成”的定义的标准。无论产品负责人是否决定真正发布它，增量必须可用。增量是从用户的角度来描述的，它意味着从用户的角度可工作。

3)自组织团队。Scrum团队是一个自组织的团队，传统的命令与控制式的团队只有执行任务的权利，而自组织团队有权进行设计、计划和执行任务，自组织团队还需要自己监督和管理他们的工程过程和进度，自组织团队自己决定团队内如何开展工作，决定谁来做什么，即分工协作的方式。

4)高优先级的需求驱动。在Scrum中，我们使用Product Backlog来管理需求，Product Backlog是一个需求的清单，其中的需求是渐进明细的、经过优先级排序的。Scrum团队从Backlog最上层的高优先级的需求开始开发。在Scrum中，只要有足够1-2个Sprint开发的细化了的高优先级需求就可以启动Sprint了，而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

XP

XP是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。

  • 在更短的周期内，更早地提供具体、持续的反馈信息。
  • 在迭代的进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断的发展它。
  • 依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
  • 依赖于口头交流、测试和源程序进行沟通。
  • 倡导持续的演化式设计。
  • 依赖于开发团队内部的紧密协作。
  • 尽可能达到程序员短期利益和项目长期利益的平衡。

5个原则

  1. 快速反馈
    及时地、快速地获取反馈，并将所学到的知识尽快地投入到系统中去。也就是指开发人员应该通过较短的反馈循环迅速地了解现在的产品是否满足了客户的需求。这也是对反馈这一价值观的进一步补充。
  2. 简单性假设
    类似地，简单性假设原则是对简单这一价值观的进一步补充。这一原则要求开发人员将每个问题都看得十分容易解决，也就是说只为本次迭代考虑，不去想未来可能需要什么，相信具有将来必要时增加系统复杂性的能力，也就是号召大家出色地完成今天的任务。
  3. 逐步修改
    就像开车打方向盘一样，不要一次做出很大的改变，那样将会使得可控性变差，更适合的方法是进行微调。而在软件开发中，这样的道理同样适用，任何问题都应该通过一系列能够带来差异的微小改动来解决。
  4. 提倡更改
    在软件开发过程中，最好的办法是在解决最重要问题时，保留最多选项的那个。也就是说，尽量为下一次修改做好准备。
  5. 优质工作
    在实践中，经常看到许多开发人员喜欢将一些细小的问题留待后面解决。例如，界面的按钮有一些不平整，由于不影响使用就先不管；某一两个成员函数暂时没用就不先写等。这就是一种工作拖泥带水的现象，这样的坏习惯一旦养成，必然使得代码质量大打折扣。
敏捷开发中XP与SCRUM的区别

区别之一： 迭代长度的不同

XP的一个Sprint的迭代长度大致为12周, 而Scrum的迭代长度一般为 2 4周.

区别之二: 在迭代中, 是否允许修改需求

XP在一个迭代中，如果一个User Story(用户素材, 也就是一个需求)还没有实现， 则可以考虑用另外的需求将其替换，替换的原则是需求实现的时间量是相等的。 而Scrum是不允许这样做的，一旦迭代开工会完毕, 任何需求都不允许添加进来，并有Scrum Master严格把关，不允许开发团队受到干扰

区别之三: 在迭代中，User Story是否严格按照优先级别来实现

XP是务必要遵守优先级别的。 但Scrum在这点做得很灵活， 可以不按照优先级别来做，Scrum这样处理的理由是：如果优先问题的解决者，由于其它事情耽搁，不能认领任务，那么整个进度就耽误了。 另外一个原因是，如果按优先级排序的User Story #6和#10，虽然#6优先级高，但是如果#6的实现要依赖于#10，则不得不优先做#10.

区别之四:软件的实施过程中，是否采用严格的工程方法，保证进度或者质量

Scrum没有对软件的整个实施过程开出工程实践的处方。要求开发者自觉保证，但XP对整个流程方法定义非常严格，规定需要采用TDD, 自动测试， 结对编程，简单设计，重构等约束团队的行为。

不难发现，这四个区别显见的是： Scrum非常突出Self-Orgnization, XP注重强有力的工程实践约束，即Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。所以建议在管理模式上启用Scrum， 而在实践中，创造一个适合自己项目组的XP。

持续集成/持续交付/DevOps

假如把开发工作流程分为以下几个阶段：

编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署

「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期。

持续集成

持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。“持续集成”源自于极限编程(XP)，是 XP 最初的 12 种实践之一。

CI 需要具备这些：

  • 全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要;
  • 灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折;
  • 版本控制工具。如 Git，CVS，SVN 等;
  • 自动化的构建和软件发布流程的工具，如 Jenkins，flow.ci;
  • 反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。

持续集成的优点

  • “快速失败”，在对产品没有风险的情况下进行测试，并快速响应;
  • 限度地减少风险，降低修复错误代码的成本;
  • 将重复性的手工流程自动化，让工程师更加专注于代码;
  • 保持频繁部署，快速生成可部署的软件;
  • 提高项目的能见度，方便团队成员了解项目的进度和成熟度;
  • 增强开发人员对软件产品的信心，帮助建立更好的工程师文化。
持续交付

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。

  比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。当然，持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。

持续交付的好处

持续交付和持续集成的优点非常相似：

  • 快速发布。能够应对业务需求，并更快地实现软件价值。
  • 编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈;
  • 高质量的软件发布标准。整个交付过程标准化、可重复、可靠，
  • 整个交付过程进度可视化，方便团队人员了解项目成熟度;
  • 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
持续部署

持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。

持续部署的优点

持续部署主要好处是，可以相对独立地部署新的功能，并能快速地收集真实用户的反馈。

Devops

Development + Operation，促进开发，技术运营，质量保障部门的沟通与整合

1.2 测试流程体系

传统测试流程

单元测试->集成测试->冒烟测试->系统测试->验收测试

测试左移

支持团队在软件开发周期早期与所有干系人合作，清晰理解需求以及设计测试用例去帮助软件“快速失败”，尽快修改bug

测试右移

产品上线了也可以做一些测试活动，保证线上数据的一致性或尽可能少的影响线上用户，以及及时获得用户反馈

1.3测试技术体系

分层测试体系

image.png 实施方法

单元测试由开发人员在代码实现完成后进行，QA主要进行接口和UI层的测试。

接口层测试：\

  • 交付节奏快、代码量很小的项目，可以直接从UI层验证，不需要QA人员进行接口测试；其他项目根据需要进行接口测试。
  • 根据开发计划，确定执行接口测试的时间。
  • 参与到接口评审，根据接口文档，确定被测接口。
  • 设计case、准备数据、执行测试。
  • 跟踪Bug。

UI层测试：
前后端联调完毕后，进入接口层测试。UI层测试除了关注UI交互的问题，更重要的是站在用户的角度，从UI层完成端到端业务流程验证，易用性、稳定性等因素也是这个层面测试需要考虑的事情。

分层测试自动化：

  • 从接口层、UI层选择回归频率高的业务流程做自动化回归，降低回归测试成本。
  • 不是所有业务流程都适合做自动化测试，自动化用例维护也有成本，选择自动化目标时，应考虑选择不频繁变动的流程。
  • UI层的变动大，维护成本高，从自动化用例的比例来看，也应该遵循金字塔的结构，UI层应该是占比最少的，把更多的自动化回归放到接口层、单元测试层。
avatar
文章
阅读
粉丝