第1章 软件测试概述&需求分析

第1章 软件测试概述&需求分析

课程内容

• stage1（阶段1）

  • testTheory

    • 测试概述，需求分析，用例，测试方法，缺陷，通用技术，计划，总结等
    • 通过上课提问，作业和笔记的把握来让学生们理解和记住面试相关问答，培养学生测试角度的思维

  • linux

    • linux命令精讲，目录和文件管理，安装和程序管理，账号和权限管理
    • 通过虚拟机演示，让学生了解linux的基本知识，能够掌握基本的shell命令。为后面搭建虚拟机环境做准备。

  • projectManagement

    • Mantis，TestLink，SVN，GIT，等

  • 将AgentSystem项目项目融入到项目管理相关工具里，包括Mantis，TestLink，禅道，SVN，GIT），让学生了解在windows和linux上怎么搭建环境，了解项目全流程中测试参与的相关内容。并掌握navicat，xshell，xftp配套工具的使用。

• stage2（阶段2）

  • 01 Web&HTML
    • 走进HTML，css美化，html5新增元素和属性，javascript基础，javascript BOM，javascript表单验证
    • 掌握前端基础页面知识，为UI自动化打基础。
  • 02 Python
    • 初识Python，流程控制语句，常用数据结构，函数与模块，项目实训-在线投票系统
    • 掌握python的基本代码编写，为后期学习自动化做铺垫
  • 03 InterfaceTesting
    • 第1章 接口测试基础，第2章 使用Postman进行接口测试，第3章 Fiddler基本使用，第4章 Fiddler高级使用，第5章 抓包工具Charles的使用，第6章 接口自动化测试实战
    • 理解接口测试，掌握接口相关工具（postman，fidder，charles，jmeter）等工具
  • 04 Database
    • 第1章 初识MySQL数据库，第2章 创建MySQL数据库和表，第3章 MySQL数据库数据管理，第4章 使用DQL查询数据，第5章 安装操作MongoDB
    • 掌握sql语句。了解mysql之外的其他常用数据库。

• stage3（阶段3）

  • 01 JavaBase
    • 第1章 初识Java，第2章 变量和数据类型，第3章 选择结构，第4章 循环结构，第5章 双重循环与跳转，第6章 数组，第7章 方法，第8章 封装&异常
    • 和python语言对比，学会java语言的基本编写。为自动化做铺垫。
  • 02 Docker
    • docker基本管理
    • 了解docker技术，理解docker项目部署分离技术
  • 03 PerformanceTesting
    • 第1章 软件性能测试基础，第2章 JMeter入门及脚本录制，第3章 JMeter常用测试元件，第4章 JMeter性能测试脚本开发，第5章 性能测试项目实战，第6章 LoadRunner入门，第7章 LoadRunner脚本增强，第8章 LoadRunner场景设计及监控，第9章 LoadRunner结果分析
    • 掌握jmeter和loadrunner，结合实战，可以进行基本的性能测试
  • 04 UIAutomatedTesting
    • 第1章 软件自动化测试基础，第2章 TestNG框架介绍，第3章 Selenium基础，第4章 Web自动化测试实战，第5章 Robot Framework基础，第6章 Robot Framework Web自动化测试，第7章 持续集成自动化测试
    • 理解何为自动化，自动化的selenium技术，TESTNG框架，uittest框架，Robot Framework框架等目前自动化领域流行的技术
  • 05 MobileTesting
    • 第1章 移动端测试入门，第2章 Appium自动化介绍和环境搭建，第3章 Appium常用操作，第4章 移动端自动化测试项目实战
    • 掌握appium的安装，结合appium+selenium+python编写自动化代码
  • 06 SecurityTesting
    • 第1章 安全性测试基础，第2章 安全性测试工具的使用
    • 了解安全测试的攻防技术，可以使用AppScan进行安全测试扫描

本课目标

1. 记忆测试理论中可能要面试的概念

​ 什么是软件测试？软件测试的原则有哪些？

2. 理解各角度的软件测试分类划分和具体使用场景

3. 了解项目内各职位所负责的工作，和测试工作的配合关系

4. 理解常见系统架构

5. 记忆软件测试的流程

6. 理解软件生命周期模型，了解敏捷测试，理解devOPS。

7. 可以使用《需求分析跟踪矩阵》来分析挖掘测试需求，可以使用xmind来理解挖掘测试需求

软件的概念

软件=程序+文档

• 程序：指能够实现某种功能的指令集合
• 文档：指软件在开发、使用和维护过程中产生的图文集合

软件测试=程序测试+文档测试

软件的特点

1.软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性。（代码+数据等逻辑组成的集合，实现各种功能，解决各种问题）
2.软件的生产与硬件不同，它没有明显的制造过程。要提高软件的质量，必须在开发方面下功夫。
3.在软件的运行和使用期间，不会出现硬件中所出现的硬件老化和磨损问题，因而它存在退化功能，必须要对其进行多次修改与维护，直至其“退役”。
4.计算机的开发与运行常常受到计算机系统的制约，它对计算机系统有着不同程度的依赖性。
5.软件的开发至今尚未完全摆脱人工的开发方式。
6.软件本身是复杂的。软件的复杂性可能来自它所反映的实际问题的复杂性，也可能来自程序逻辑结构的复杂性。
7.软件成本相当昂贵。软件的研制工作需要大量的、复杂的、高强度的脑力劳动，它的成本是比较高的。
8.相当多的软件工作涉及社会因素。许多软件的开发和运行涉及机构、体制及管理方式等问题，它们直接决定项目的成败。

软件的本质

如果把软件和硬件分开理解，软件就是一种“逻辑”，不同的软件就代表各种不同的逻辑，而各种不同逻辑的背后其实就是一种解决问题的方式。

软件的本质是信息处理，以及对信息处理的自动化。在软件系统中，数据是信息的载体，是对客观事物所蕴含信息的抽象描述。软件对数据的处理包括：Define（定义），Transfer（传递），Transform（转换），Store（存储），Retirval（检索），Show（展示）。

人-软件-硬件-驱动机器做人想做的事情。

软件的分类

• 系统软件
  • 如windows、Linux、UNIX等，还包括操作系统的补丁程序及硬件驱动程序，都是系统软件类
• 应用软件
  • 工具软件、游戏软件、管理软件

软件项目团队构成

项目经理

项目经理负责分配资源，确定优先级，协调与客户和用户之间的交往。总而言之，就是尽量使项目团队一直集中于正确的目标。项目经理还要建立一套工作方法，以确保项目工件的完整性和质量。
构架设计师
构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要为各构架视图确立整体结构：视图的详细组织结构、元素的分组以及这些主要元素组之间的接口。因此，与其它角色相比，构架设计师的见解重在广度，而不是深度。

需求分析员

业务分析员通过概括和界定作为建模对象的组织来领导和协调业务用例建模。例如，确定存在哪些业务主角和业务用例，他们之间如何交互。通过描述一个或几个用例的需求状况以及其他支持软件的需求来获取系统功能某一部分的规约。还要负责用例包并维护该用例包的完整性。
软件设计师
设计员定义一个或几个类的职责、操作、属性及关系，并确定应如何根据实施环境对它们加以调整。此外，设计师可能要负责一个或多个设计包或设计子系统，其中包括设计包或子系统所拥有的所有类。 编写部分模块设计文档和代码，检查软件工程师编写的模块代码。

UI设计师

界面设计人员通过以下方法来领导和协调 Web 界面的原型设计和正式设计：获取对 Web 界面的需求（包括可用性需求），构建 Web 页面原型，使 Web 界面的其他涉众（如最终用户）参与可用性复审和使用测试会议，复审并提供对 Web 界面最终实施方案（由其他开发人员员创建，如设计师和实施工程师）的适当反馈。

软件开发工程师

软件工程师负责完成设计师的设计意图， 根据设计文档编写代码； 根据设计文档编写单元测试代码，根据测试报告 BUG 记录修订 BUG ，完成包或子系统的开发。
测试工程师
测试工程师负责执行测试，其中包括设置和执行测试，评估测试执行过程并修改错误，以及评估测试结果并记录所发现的缺陷。

实施工程师

负责软件产品安装调试和部署，完成项目相关系统工程工作，负责客户技术支持，负责编写系统部署方案和使用手册、维护手册，负责系统实施计划和规划。

运维工程师

无论做什么运维，运维工程师最基本的职责都是负责服务的稳定性，确保服务可以7*24H不间断地为用户提供服务。在此之上运维工程师的主要工作职责如下：

1. 质量：保障并不断提升服务的可用性，确保用户数据安全，提升用户体验。
2. 效率：用自动化的工具/平台提升软件在研发生命周期中的工程效率。
3. 成本：通过技术手段优化服务架构、性能调优；通过资源优化组合降低成本、提升ROI。

从产品的生命周期来看：

1. 产品发布前：负责参与并审核架构设计的合理性和可运维性，以确保在产品发布之后能高效稳定的运行。

2. 产品发布阶段：负责用自动化的技术或者平台确保产品可以高效的发布上线，之后可以快速稳定迭代。

3. 产品运行维护阶段：负责保障产品7*24H稳定运行，在此期间对出现的各种问题可以快速定位并解决；在日常工作中不断优化系统架构和部署的合理性，以提升系统服务的稳定性。

什么是软件测试

使用人工操作或软件自动运行的方式来检验它是否满足规定的需求
弄清预期结果与实际结果之间差别的过程

• 预期结果
  • 指用户的预期结果
• 实际结果
  • 指的是软件的实际运行结果
• 软件缺陷
  • 预期结果与实际结果之间的差别

正确理解软件测试

测试是为了发现程序中的错误
成功的测试是发现了至今为止尚未发现的错误
测试并不仅仅是为了找出错误
没有发现错误的测试也是有价值的

错误理解软件测试

测试是为了证明程序没有错误

软件开发完成后进行软件测试

软件发布后如果发现质量问题，那是软件测试人员的错

软件测试要求不高，随便找个人多都行

软件测试是测试人员的事情，与程序员无关

项目进度吃紧时少做些测试，时间富裕时多做测试

软件测试是没有前途的工作，只有程序员才是软件高手

通过测试达到零缺陷率

软件测试的历史发展

60年代以前

• 软件测试跟“调试”（Debug）关联在一起，由开发人员执行。没有单纯意义上的软件测试，软件测试还没有形成概念

• 随着软件工程的发展，软件测试的概念出现在20世纪60年代

70年代初期

• Bill Hetzel提出软件测试是为了证明程序是正确的，建立一种信心。

70年代末期

• 1972年，在北卡罗来纳大学举行了首届软件测试正式会议。
• 1979年，Glenford Myers 在《软件测试艺术》中，对测试做了定义：测试是为发现错误而执行的一个程序或者系统的过程。

80年代

• 20世纪80年代早期，“质量”的号角开始吹响。软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评价的内容，制定了各类标准。
• 提出了一系列各种复杂而精密的软件开发设计流程和管理方法，例如CMM、CMMI软件测试也有了行业标准IEEE/ANSI，V模型和其他模型的逐渐形成
• 1983年，Bill Hetzel 在《软件测试完全指南》中指出：测试是以评价一个程序或者系统属性为目标的任何一种活动，测试是对软件质量的度量。

90年代

• 手工测试（Manual Test）到测试工具的发展。测试工具盛行起来

现在

• 软件测试管理工具的大量应用，测试是为了度量和提高被测软件的质量。

  ---

  我国的软件测试发展

  • 1978年-1988年，中国软件蹒跚起步，软件英雄厉兵秣马。1980年，在中关村建立了“北京等离子体学会先进技术发展服务部”

  • 1988年-1998年，软件市场内忧外患，最初繁荣后的低谷。随着盗版的日益猖獗以及国外软件巨头的入侵，国产软件失去了最初的辉煌。从1994年中国正式接入国际互联网，到作为网络时代标志的瀛海威时空的成立，再到中国计算机公用互联网CHINANET建成

  • 1998年-2008年，互联网蓬勃发展，中国软件迎来复兴。2001年，中国成功加入WTO，自此中国正式获得和国际市场对话的权利;2002年，全面建设小康社会成为改革的核心，同年博客进入中国，互联网春天来临;2000年左右以新浪、腾讯、网易等代表的互联网公司先后在国际市场上市，以中国概念股的姿态夺得了资本市场的认可;同样在2000年，金山创办了电子商务网站卓越网，电子商务成为互联网主流商业模式。

  • 随着快速占领市场，敏捷开发，快速迭代的需求，2012年自动化火了起来

    小结：软件定义世界，智能化的影响越来越影响中国的发展。

软件测试的重要性

事故1：阿丽亚娜 5 型运载火箭

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QmPDoGRK-1645522648127)(.image/image-20220220202813351.png)]

1996 年，阿丽亚娜 5 型运载火箭首次飞行，搭载发射星群航天器（欧洲航天局的四大航天器之一的星座）。然而由于运载火箭无法到达指定轨道，任务以失败告终。

损失：3.7 亿美元，故障原因：阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中，对一个水平速率的测量值使用了16位的变量及内存，因为在4型火箭系统中反复验证过，这一值不会超过16位的变量，而5型火箭的开发人员简单复制了这部分程序，而没有对新火箭进行数值的验证，结果发生了致命的数值溢出。因此，飞行器在发射后 37 秒便从原始路径偏移。最终不得不启动了火箭自毁程序。

事故2：奔腾的长除法

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-tq1cmwjS-1645522648130)(.image/image-20220220202947580.png)]

1994 年，英特尔的奔腾微处理器芯片的浮点计算单元出现了一个 Bug。对于精确计算，处理器将返回不正确的十进制值。当时有大概 500 万个缺陷芯片在流通，英特尔最终决定为所有投诉的人更换芯片。这之后，英特尔把他们的故障处理器做成了钥匙链。
　　损失：4.75 亿美元 + 品牌名誉受损，故障原因：在奔腾浮点单元的分频器中有一个有缺陷的除法表，在约一千个条目中丢失了五条纪录。然而，这个错误在 90 亿随机浮点小数的除法中仅可能出现一次。例如，将 4195835.0 除以 3145727.0 得出 1.333739068902037589，而不是 1.333820449136241002，有 0.006% 的误差。

事故3：1987 年的华尔街崩盘

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-J5ZIy9Hn-1645522648131)(.image/image-20220220203244445.png)]

1987 年 10 月 19 日（也被称为黑色星期一），道琼斯工业平均指数（DJIA）下跌了 508 个点，损失了总价值的 22.61%，且标准普尔 500 指数下跌了 20.4%。这是华尔街一天之内见过的最大损失。
　　损失：一天 5000 亿美元，故障原因：问题出在交易程序和估价程序。在交易程序中，计算机基于外部输入执行快速股票交易，如相关证券的价格。该交易程序理应实施投资组合保险策略，并试图从事套利。

1987 年初，美国证券交易委员会针对内幕交易开始了一系列的调查。直到 10 月，投资者决定搬出华尔街。随着人们开始大规模外流，计算机交易程序出现了大量的销售订单至 DOT（订单转送及成交回报系统），于是系统超出负载、市场崩溃以及所有的投资者懵逼了。

事故4：千禧危机

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aBxH19hC-1645522648132)(.image/image-20220220203419291.png)]

千年虫（千年问题）是计算机系统的编码问题，在从 1999年 12 月 31 号过渡到 2000 年 1 月 1 号时，这个错误将在计算机网络和软件中引发一场浩劫。
　　损失：5000 亿美元，故障原因：为了节省计算机存储空间，大多数传统软件使用两位数字来存储日期中的年份，例如，用“97”来代表 1997 年。这导致了 2000 年 1 月之后日期相关程序的错误操作。

此外，有些程序没有考虑到 2000 年是闰年。甚至在 2000 年到来之前，人们都在担心一些软件可能在 1999 年 9 月 9 号（表示为 9/9/99）无法工作，因为早期的开发人员常使用一系列的 9 来表示一段程序代码的结束。

事故5：癌症治疗与致死性放射治疗

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l2nNYBEI-1645522648133)(.image/image-20220220203547047.png)]

1985 年到 1987 年期间，Therac-25 医疗放射治疗装置让成百上千的患者暴露在大量过量的辐射之中，少数患者接受了高达预期 100 倍的放射剂量。2000 年，巴拿马城也发生了同样的辐射剂量误差。

损失：10 余人死亡，20 人重伤，故障原因：基于输入数据的顺序，治疗计划软件计算出并提供双倍剂量的辐射。

事故6：爱国者导弹

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-19ivQtU5-1645522648134)(.image/image-20220220203706950.png)]

1991 年 2 月第一次海湾战争期间，部署在沙特宰赫兰的美国爱国者导弹系统未能成功追踪和拦截来袭的伊拉克飞毛腿导弹。结果飞毛腿导弹击中美国军营。
　　损失：28 名士兵死亡，100 多人受伤，故障原因：时间计算不精确以及计算机算术错误导致了系统故障。从技术角度来讲，这是一个小的截断误差。当时，负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时，每工作一个小时，系统内的时钟会有一个微小的毫秒级延迟，这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位，因而时间的精度也只限于24位的精度。在长时间的工作后，这个微小的精度误差被渐渐放大。在工作了100小时后，系统时间的延迟是三分之一秒。

0.33 秒对常人来说微不足道。但是对一个需要跟踪并摧毁一枚空中飞弹的雷达系统来说，这是灾难性的。飞毛腿导弹空速达4.2马赫（每秒1.5公里），这个”微不足道的”0.33秒相当于大约 600 米的误差。在宰赫兰导弹事件中，雷达在空中发现了导弹，但由于时钟误差没能精确跟踪，反导导弹因而没有发射拦截。

事故7：洛杉矶国际机场的航班停飞

2007 年，美国边境和海关控制网络发送了大量错误数据。这导致洛杉矶整个机场关闭了 8 个小时，在问题解决之前，超过 17000 架飞机不能起飞。这件事的罪魁祸首是一段有 Bug 的嵌入式软件。

事故8：Bug 葬送了日本 18 亿元的最新卫星

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MVVq6CLn-1645522648142)(.image/image-20220220203934919.png)]

2016年2月17日，被日本寄予厚望的 X 射线天文卫星“瞳”成功发射升空，但仅仅一个月后，“瞳”与地面的通信出现严重故障，经地面光学望远镜测控发现其运行轨迹出现多块太空碎片。4月28日，日本宇宙航空研究开发机构（JAXA）正式宣布，无法恢复对X射线卫星“瞳”的操控，事故原因经初步调查源自底层软件错误。卫星的控制系统在发现飞行姿态失控时，采取了错误的调整，推进器点火时朝向了错误的反方向，导致自身旋转更加严重，最终彻底失控。

事故9：温州7.23 动车事故

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-f7MrX1vm-1645522648143)(.image/image-20220220204218407.png)]

2011年7月23日20时30分05秒，甬温线浙江省温州市境内，由北京南站开往福州站的D301次列车与杭州站开往福州南站的D3115次列车发生动车组列车追尾事故，造成40人死亡、172人受伤，中断行车32小时35分，直接经济损失19371.65万元。上海铁路局局长安路生28日说，根据初步掌握的情况分析，“7·23”动车事故是由于温州南站信号设备在设计上存在严重缺陷，遭雷击发生故障后，导致本应显示为红灯的区间信号机错误显示为绿灯。

事故10：12306连现故障：上午近乎瘫痪下午爆串号门

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2HAWrPHE-1645522648145)(.image/image-20220220204601035.png)]

2014年春运图定列车售票首日，上午12306网站的响应速度逐渐变慢，刷新网页经常需要超过20秒，也有网友表示网页根本刷不出来。下午3时左右，正当抢票大战激烈进行时，以自己的用户名登录后，出现的确是别人的名字。
抢票插件作者倪超分析称，上线不久的12306新版，反应速度和稳定性比起旧版都有所下降，面对大量用户就显得力不从心。

事故11：男子趁ATM机出错恶意提款171次被判无期

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mXugxII8-1645522648146)(.image/image-20220220213434968.png)]

2006年4月21日晚10时，被告人许霆来到广州天河区黄埔大道某银行的ATM取款机取款。结果取出1000元后，银行卡账户里只被扣1元，许霆先后取款171笔，合计17.5万元。许霆潜逃一年后被抓获，一审以盗窃罪被判无期徒刑。

3月31日下午，备受关注的许霆案一审重审结果宣布，广州中院以盗窃罪判处许霆有期徒刑五年，罚金两万，追讨其取出的17万3千8百26元。许霆当庭表示不上诉，而许霆父亲许彩亮对于这个判决不满意，表示还会上诉。

自许霆案浮出水面且一审判处无期徒刑间，网民的关注焦点仅集中于银行的强权霸道与法院的量刑标准，并口诛笔伐；而二审结果宣判后，网民则对于法律的信任产生了动摇。在很多人的心中，银行成了高危地带，法律也不再那么坚强。备受关注的许霆案落幕，留下了“一地鸡毛”。

软件测试的目的

• 把尽可能多的问题在产品交给用户之前发现并改正
• 确保最终交给用户的产品功能符合用户的需求
  • 确保产品完成了所承诺或公布的功能
  • 确保产品满足性能和效率的要求
  • 确保产品健壮和适应用户环境
• 建立软件质量的信心，度量和提高被测软件的质量。

---

立场不同，测试目的不同

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vtcbCtgn-1645522648147)(.image/image-20220221083339116.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fzcXwjxY-1645522648148)(.image/image-20220221083410773.png)]

软件测试的原则

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cQFXlJ3N-1645522648149)(.image/无标题.png)]

测试人员应具备的素质

必备技能

1. 软件测试知识：测试计划、测试方案、编写用例、提交bug、跟踪bug，编写测试报告
2. 测试工具的使用
3. 操作系统
4. 编写代码的能力
5. 数据库知识
6. 业务知识、网络知识

辅助素质

1. 主动沟通，清晰了解掌握需求逻辑，和专业的问题反馈。

2. 胆大心细；相信自己，自己是专业的

3. 不被别人绑架；要有职业标准，也要有自己的态度

4. 对一切都要有怀疑的态度

5. 责任心；站在公司和用户的角度考虑问题

当工匠精神遇到公司快速发展、激烈的竞争，测试该如何破局？

工匠精神

"工匠们喜欢不断雕琢自己的产品，不断改善自己的工艺，享受着产品在双手中升华的过程。

工匠们对细节有很高要求，追求完美和极致，对精品有着执着的坚持和追求，把品质从0提高到1，其利虽微，却长久造福于世。"

如何破局？

• 一般就是加人、加班；提高测试人员素质。

• 为了速度稍微对质量进行瘦身，当然瘦身的前提还是要保证产品的健康。

• 还需要保证产品的健壮性，不至于在压力大的时候就会被压垮；在遭受病毒攻击时，就被随意攻破；换个环境，就不能适应。

• 要有专业的业务测试团队，对所负责系统及业务非常精通；

• 要有专业的质量团队，通过流程控制，保证任何项目都能临危不乱；

• 通过组建自动化实施专家团、白盒测试专家团、性能测试、安全测试、用户体验测试等专家团队，保证项目的每一种质量指标都能够有特种部队的支持；这样就可以保证紧急的战略项目可以在短时间内得到专业的质量保障。

常见软件系统架构

B/S架构

（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。该模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用成本。

BS分布性强、维护方便、开发简单且共享性强、总体拥有成本低。但数据安全性比C/S低、对服务器要求过高、数据传输速度慢、软件的个性化特点明显降低，难以实现传统模式下的特殊功能要求。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xVwMFKU2-1645522648149)(.image/image-20220221090035201.png)]

优点

分布性强，客户端零维护。只要有网络、浏览器，可以随时随地进行查询、浏览等 业务处理。
业务扩展简单方便，通过增加网页即可增加服务器功能。

维护简单方便，只需要改变网页，即可实现所有用户的同步更新。
开发简单，共享性强。

缺点

个性化特点明显降低，无法实现具有个性化的功能要求。
在跨浏览器上，BS架构不尽如人意。
客户端服务器端的交互是请求-响应模式，通常动态刷新页面，响应速度明显降低（Ajax可以一定程度上解决这个问题）。无法实现分页显示，给数据库访问造成较大的压力。
在速度和安全性上需要花费巨大的设计成本。
功能弱化，难以实现传统模式下的特殊功能要求。

B/S架构的几种形式

第一种：客户端-服务器-数据库

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6cwttVB7-1645522648150)(.image/image-20220221101818525.png)]

这个应该是我们平时比较常用的一种模式：

1、客户端向服务器发起Http请求

2、服务器中的web服务层能够处理Http请求

3、服务器中的应用层部分调用业务逻辑，调用业务逻辑上的方法

4、如果有必要，服务器会和数据库进行数据交换. 然后将模版＋数据渲染成最终的Html, 返送给客户端

第二种：客户端－web服务器－应用服务器－数据库

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jpbeMSE0-1645522648150)(.image/image-20220221101914438.png)]

类似于第一种方法，只是将web服务和应用服务解耦

1 客户端向web服务器发起Http请求

2 web服务能够处理Http请求，并且调用应用服务器暴露在外的RESTFUL接口

3 应用服务器的RESTFUL接口被调用，会执行对应的暴露方法.如果有必要和数据库进行数据交互，应用服务器会和数据库进行交互后，将json数据返回给web服务器

4 web服务器将模版＋数据组合渲染成html返回给客户端

第三种方法：客户端－负载均衡器(Nginx)－中间服务器(Node)－应用服务器－数据库

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vyDLwRQh-1645522648151)(.image/image-20220221102002860.png)]

这种模式一般用在有大量的用户，高并发的应用中。

1、整正暴露在外的不是真正web服务器的地址，而是负载均衡器器的地址

2、客户向负载均衡器发起Http请求

3、负载均衡器能够将客户端的Http请求均匀的转发给Node服务器集群

4、Node服务器接收到Http请求之后，能够对其进行解析，并且能够调用应用服务器暴露在外的RESTFUL接口

5、应用服务器的RESTFUL接口被调用，会执行对应的暴露方法.如果有必要和数据库进行数据交互，应用服务器会和数据库进行交互后，将json数据返回给Node

6、Node层将模版＋数据组合渲染成html返回反向代理服务器

7、反向代理服务器将对应html返回给客户端

C/S架构

C/S架构全称为客户端/服务器体系结构，它是一种网络体系结构，其中客户端是用户运行应用程序的PC端或者工作站，客户端要依靠服务器来获取资源。C/S架构是通过提供查询响应而不是总文件传输来减少了网络流量。它允许多用户通过GUI前端更新到共享数据库，在客户端和服务器之间通信一般采用远程调用（RPC）或标准查询语言（SQL）语句。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pVRSNTRw-1645522648151)(.image/image-20220221093043581.png)]

特点

• 客户端进程包含特定于解决方案的逻辑，并提供用户与应用程序系统其余部分之间的接口。服务器进程充当管理共享资源（如数据库，打印机，调制解调器或高性能处理器）的软件引擎。
• C/S结构在技术上很成熟，它的主要特点是交互性强、具有安全的存取模式、网络通信量低、响应速度快、利于处理大量数据。因为客户端要负责绝大多数的业务逻辑和UI展示，又称为胖客户端。它充分利用两端硬件，将任务分配到Client 和Server两端，降低了系统的通讯开销
• C/S结构的软件需要针对不同的操作系统开发不同版本的软件，加之产品的更新换代十分快，更新的代价高，效率低，很难适应百台电脑以上局域网用户同时使用。
• 客户端和服务器进程通过一组明确定义的标准应用程序接口（API）和RPC进行通信。

优点

• 能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，所以CS客户端响应速度快。
• 操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。
• C/S结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。
• 安全性能可以很容易保证，C/S一般面向相对固定的用户群，程序更加注重流程，它可以对权限进行多层次校验，提供了更安全的
• 存取模式，对信息安全的控制能力很强。一般高度机密的信息系统采用C/S结构适宜。

缺点

• 需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。
• 兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。
• 开发、维护成本较高，需要具有一定专业水准的技术人员才能完成，发生一次升级，则所有客户端的程序都需要改变。
• 用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户，所以适用面窄，通常用于局域网中。

C/S架构的类型

一层架构

在此类型C/S架构设置中，用户界面，营销逻辑和数据逻辑存在于同一系统中。但是由于数据差异导致难以管理。例MP3播放器，MS Office都属于单层应用程序。

两层架构

在这种类型中，用户界面存储在客户端机上，数据库存储在服务器上。数据库逻辑和业务逻辑在客户端或服务器上归档，但需要进行维护。如果在客户端收集业务逻辑和数据逻辑，则将其命名为胖客户端瘦服务器体系结构。如果在服务器上处理业务逻辑和数据逻辑，则称为瘦客户端胖服务器体系结构。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xvHslNC8-1645522648151)(.image/image-20220221093926268.png)]

三层架构

在三层架构中，需要使用到额外的中间件，这意味着客户端请求需要通过该中间层进入服务器，服务器的响应首先由中间件接收，然后再接收到客户端。中间件存储所有业务逻辑和数据通道逻辑，中间件提高了灵活性并提供了最佳性能。

三层结构被分成三个部分，即表示层（客户层），应用层（业务层）和数据库层（数据层）。客户端系统管理表示层，应用程序服务器负责应用程序层，服务器系统负责监视数据库层。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lbzyRnOg-1645522648152)(.image/image-20220221094903824.png)]

B/S 与 C/S对比

1、客户端要求

• C/S客户端的计算机电脑配置要求较高。

• B/S客户端的计算机电脑配置要求较低。

2、软件安装

• C/S每一个客户端都必须安装和配置专用的软件。
• B/S最大的优点就是不用安装任何专门的软件，只要有一个浏览器就可以。

3、软件升级和维护

• C/S每一个客户端都要进行升级和维护。
• B/S客户端不必安装及维护。

4、安全性

• C/S一般面向相对固定的用户群，它可以对权限进行多层次校验，提供了更安全的存取模式，对信息安全的控制能力很强。一般高度机密的信息系统应采用C/S结构。

发展前景

1、 C/S和B/S各有优势，C/S在图形的表现能力上以及运行的速度上肯定是强于B/S模式的，不过缺点就是他需要运行专门的客户端，而且更重要的是它不能跨平台，用c++在windows下写的程序肯定是不能在linux下跑的。

2、B/S模式就，它不需要专门的客户端，只要浏览器，而浏览器是随操作系统就有的，方便就是他的优势了。
而且，B/S是基于网页语言的、与操作系统无关，所以跨平台也是它的优势，而且以后随着网页语言以及浏览器的进步，
B/S在表现能力上的处理以及运行的速度上会越来越快，它的缺点将会越来越少。尤其是HTML5的普及，在图形的渲染方面以及音频、文件的处理上已经非常强大了。
不过，C/S架构也有着不可替代的作用。

常见面试题

什么是软件测试？

软件测试的原则是什么？

软件测试的分类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-um3KVagZ-1645522648153)(.image/image-20220221152213564.png)]

作业：把上述每个测试的概念和分类搞懂，做好笔记，提交上来

按开发阶段划分

• 单元测试

• 集成测试

• 系统测试

• 验收测试

按是否查看代码划分

• 白盒测试
• 灰盒测试
• 黑盒测试
  • 功能测试
    • 界面测试
    • 业务逻辑测试
    • 兼容性测试
    • 易用性测试
    • 回归测试
  • 性能测试
    • 性能测试
    • 负载测试
    • 压力测试
    • 并发测试
    • 配置测试
    • 容量测试
    • 可靠性测试

按是否运行划分

• 动态测试
• 静态测试

按是否手工测试划分

• 手工测试

• 自动化测试

  ​

按其他划分

• 随机测试
• 冒烟测试
• 安全测试
  • 安全测试是在软件产品开发基本完成时，验证产品是否符合安全需求定义和产品质量标准的过程
  • 安全测试是检查系统对非法侵入渗透的防范能力
  • 理论上来讲，只要有足够的时间和资源，没有无法进入的系统。因此，系统安全设计的准则是使非法侵入的代价超过被保护信息的价值
• 探索测试
  • 探索性测试 (ET)是敏捷世界里的一种重要测试方法，作为一个研究性的工具，它是用户故事测试和自动化回归集的重要补充
  • 是一种经过深思熟虑的测试方式，没有测试脚本，可以使你的测试超出各种明显已经测试过的场景。相对于严格的“先设计，后执行”有较大区别， 主要依靠对于业务与技术的深入思考和测试人员的经验。
• α测试
  • Alpha测试是指把用户请到开发方的场所来测试，俗称（内侧），Alpha测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中 Alpha
  • 王者体验服是属于 Alpha测试，属于开发可控的测试。
• β测试
  • Beta测试是指在一个或多个用户的场所进行的测试。beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。
    • 下载版本时的beta版本

软件测试流程

软件测试流程图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GnELnIRw-1645522648153)(.image/image-20220221150157620.png)]

软件测试过程主要工作内容

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E6TU9KYY-1645522648154)(.image/image-20220221150255975.png)]

测试小组的运行

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QeQVnZxJ-1645522648154)(.image/image-20220221151541373.png)]

软件生命周期模型

一 什么是模型

序

​ 不知道为什么，很多软件开发的新人都是从C或C++的入门书籍开始的。
​ 这就好比，要去打仗的人先熟悉兵器一样。
​ 为什么不从战略战术层面开始学习呢?如果战略和战术出了问题，兵器再熟练又有什么用呢?还不是一样吃败仗?
打仗的目的是追求胜利，不是兵器耍得如何漂亮。而软件开发的目的是解决用户在处理其业务时遇到的问题。
所以，软件开发新人更应该先去培养自己了解用户需求，解决用户问题的能力。

​ 模型被用来描绘人们所关注的现实或想法的某个方面。模型是一种简化。它是对现实的解释——把与解决问题密切相关的方面抽象出来，而忽略无关的细节。
​ 我们讲行软件开发是为了解决用户在业务中遇到的问题，而这些用户的问题领域对于软件开发团队来说是一整套庞大的知识体系，软件开发人员要弄清楚这些问题领域所需知识的广度可能令人望而生畏，庞大而复杂的信息也可能超乎想象。而模型正是解决此类信息庞大问题的工具。使用模型可以对庞大的知识信息进行了选择性的简化和有意的结构化，帮助开发人员理解信息的意义，并专注于用户问题本身。
​ 模型是一种工具，它把庞大、复杂、零乱的信息通过抽象简化这样的整理，让人更容易理解。

二 软件开发模型

软件开发模型也叫软件生命周期模型。是软件开发全过程。能够覆盖软件生命周期的基本阶段。

典型的软件开发模型有：瀑布模型、快速原型模型、螺旋模型、演化模型

主要的开发方法分类从大方向上包括：

结构化开发
结构化开发方法又称生命周期法，是迄今为止最传统、应用最广泛的一种开发方法
结构化开发方法结构化、模块化、自顶向下地对软件系统进行分析与设计
该方法严格按照阶段性开展工作，每个阶段都产生一定的成果（文档、代码），通过评估后再进入下一阶段开发工作

迭代开发

在迭代开发中，人们从项目的计划阶段开始，通过这些阶段进入产品的开发和发布。当产品发布时，来自产品测试和用户的结果，这些结果被折叠到下一个版本中。“发布”可能是一个误导性的术语；迭代开发可能涉及到产品在早期阶段的内部发布，而不是产品的发布面向公众的产品。使用这种技术的开发人员假设、接受并实际上期望他们开发的产品不会一次完成。与其试图预见所有潜在的问题和用户需求，他们通过一系列的迭代来逐步完善和改进产品，使其变得有用。迭代开发的一个主要优点是，它允许人们对问题和不断变化的需求做出快速响应，因为重建、回滚和优化都是在开发过程中直接构建的开发通常涉及来自公司不同部门的团队成员之间的密切合作。通过让每个人都参与到底层，公司可以降低开发成本，鼓励创新，并从一开始就开发出综合多种观点的产品迭代开发还需要大量的研究和分析，因为人们对市场压力、来自消费者和客户的明确需求以及对正在开发的产品的内部反馈作出反应。这个过程是动态的，而且非常迅速。有些公司的周期最短可能只有一周。在每个周期开始时，开发人员开会确定他们希望实现的变更，并将重点放在这些变更上；随着其他问题的出现，它们可以被添加到以后的开发周期中。这有助于集中精力，帮助公司更容易地满足期望；随着迭代开发的产品开始向公众推出，正在测试产品的用户可以遵循计划的更改，可以报告问题，并确保有一个固定的时间框架来解决这些问题

Ⅰ 瀑布模型（waterfull）

A 定义

瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-i4i88l4w-1645522648155)(.image/image-20220221103654566.png)]

Ⅱ 快速原型模型

定义

一般在需求提出初期，用户迫切需要体验产品，开发人员根据核心功能需求快速实现的一款可以用来演示的产品，形成demo，可快速挖掘是否是用户真正想要的产品。但这种模型在整个软件项目周期内只可能存在于这期间，当用户了解了demo后决定是抛弃还是继续采用，抛弃相当于需求双方没有达成一致，可以再次采用原型模型输出给用户确认，若选择不抛弃继续采用，原型模型就会被抛弃，选择其他模型继续开发。

优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。

Ⅲ 螺旋开发模型

A 定义

螺旋开发，1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，并且加入了两种模型忽略的风险分析，弥补了两者的不足，特别适合于大型复杂的系统。

“螺旋模型”的每一周期都包括制定计划、风险分析、实施工程和评审4个阶段。刚开始规模很小，开发过程每迭代一次，螺旋线就增加一周，软件开发又前进一个层次，系统又生成一个新的版本。

“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

B 优点

1）设计上的灵活性,可以在项目的各个阶段进行变更。

2）以小的分段来构建大型系统,使成本计算变得简单容易。

3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

C 缺点

很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

风险分析师分析的风险不正确的情况下，可能造成大的损失。

Ⅳ 软件开发增量模型

A 定义

是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。

B 增量模型的优点

1.整个项目的资金不会被提前消耗，因为首先开发和交付了主要功能和高风险功能。

2.每个增量交付一个可操作的产品。

3.每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应。

4.采用连续增量的方式，可把用户经验融入到细化的产品，这比完全重新开发要便宜得多。

5.“分而治之”的策略，使问题分解成可管理的小部分，避免开发团队由于长时间的需求任务而感到泪丧。

6.通过同一个团队的工作来交付每个增量，保持所有团队处于工作状态，减少了员工的工作量

7.每次增量交付的结果，可以重新修订成本和进度的风险。

8.便于根据市场作出反应。

9.降低了失败和更改需求的风险。

10.更易于控制用户需求，因为每次增量开发的时间很短。

11.由于不是一步跳到未来，所以用户能逐步适应新技术。

12.切实的项目进展，有利于进度控制。

13.风险分布到几个更小的增量中，而不是集中于一个大型开发中。

14.由于用户能够从早期的增量中了解系统，所以更加理解后面增量中的需求。

C 增量模型的缺陷

1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
　2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
　3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

D 增量模型的要求

1.良好的可扩展性架构设计，是增量开发成功的基础。

2.由于一些模块必须在另一个模块之前完成，所以必须定义良好的接口。

3.与完整的系统相比，增量方式正式的回顾和评审更难于实现，所以必须定义可行的过程。

4.要避免把难题往后推，首先完成的应该是高风险和重要的部分。

5.客户必须认识到总体成本不会更低。

6.分析阶段采用总体目标而不是完整的需求定义，可能不适应管理。

7.需要更加良好的计划和设计，管理必须注意动态分配工作，技术人员必须注意相关因素的变化。

软件测试模型

Ⅰ V模型

V模型大体可以划分为以下几个不同的阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

一般来讲:单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来;集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用;而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。

适用范围

V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

Ⅱ W模型

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等开发输出的文档同样要测试(这里针对设计文档，一般可以划分为需求设计文档、概要设计文档、详细设计文档和代码文档)， 也就是说，测试与开发是同步进行的。

从这个角度来说，一个完整合格的测试人员对软件各方面把握程度应该比开发人员更高，一个测试人员要能胜任软件研究任何一个岗位。

W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

V模型和W模型的区别

一、指代不同

1、v模型：是软件开发过程中的一个重要模型，由于其模型构图形似字母V，所以又称软件测试的V模型。

2、w模型：由两个V字型模型组成，分别代表测试与开发过程。

二、特点不同

1、v模型：仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

2、w模型：测试的活动与软件开发同步进行，测试的对象不仅仅是程序，还包括需求和设计，尽早发现软件缺陷可降低软件开发的成本。

三、适用不同

1、v模型：是一种传统软件开发模型，适用于一些传统信息系统应用的开发。

2、w模型：有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求文档的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。

V模型和W模型的局限性

•串行活动，无法更好适应变更：把软件的开发视为需求、设计、编码等一系列的串行活动，无法解决需求变更等变更调整。

•线性的前后关系，无法有效支持迭代：开发和测试保持线性的前后关系，上一阶段完成才能开始下一阶段，无法有效，快速支持产品迭代。

•测试完整性不足：顺序模型中没有很好体现测试流程的完整性。

Ⅲ H模型

这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试"微循环"。图中标注的其他流程可以是任意的开发流程。例如，设计流程或编码流程。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以(或者说需要)进行了。

H模型揭示了一个原理:软件测试是一个独立的流程，以独立完整"微循环"流程，参与产品生命周期的各个阶段，与其他流程并发地进行。H模型指出软件测试要尽早准备，尽早执行，只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，但也可以是反复进行的。

敏捷开发模型（Agile software development)

敏捷开发(Agile Development)
以用户的需求进化为核心、迭代、循序渐进的开发方法

软件项目的构建被切分成多个子项目
各个子项目的成果都经过测试
具备集成和可运行的特征

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C2SaVAEo-1645522648158)(.image/image-20220221141157242.png)]

敏捷开发原则

通过尽早、持续交付有价值的软件来使客户满意
即使在开发的后期，需求变更也是允许的
经常交付可工作软件
项目开发期间，业务人员和开发人员在一起工作
强化激励机制，为受激励的个人单独构建项目
在团队内部，最富有效果和效率的信息传递方法是面对面交谈

可工作软件是进度的首要度量标准
敏捷过程提倡可持续的开发速度
不断关注优秀的技能和好的设计，增强敏捷能力
尽量简化所要做的工作
好的架构、需求和设计出自于组织团队自身
团队要定期反省如何更有效地工作，并相应地调整自己的行为

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k7Q1Zh4u-1645522648159)(.image/image-20220221111254616.png)]

A 定义

敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

1、详细的产品需求列表，排定优先级，这些便需要产品经理来完成的工作，同时一般会有研发、UI、运营等人的配合;

2、工作量的评估：这一项需要技术人员的支持，同时也需要产品经理，内容就是沟通各方面的资源、权衡技术难度，制定详细的规划;

3、计划会议：这里是迭代的目标以及时间，同时把每一个大的任务细化到每个小任务——2、3天完成;

4、站立会议：每日开站立会议，每个人说明自己昨天完成了什么任务，今天要做什么，把已经完成的任务从未完成区域放在燃尽图的已完成区域;

5、做到每日集成，每天都有一个成功编译、并且可以演示的版本;

6、当一次迭代完成的时候，组织演示会议，也叫评审会议，邀请部门经理等管理者参加;

7、总结：轮流发言、讨论需要改进的地方，放入下一轮产品的需求中。

B 专有名词解释

Product Owner

Product Owner ，以下简称“PO”，国内经常翻译为“产品负责人”或者“产品拥有者”

PO主要是Built the right thing,即做对的事情。通过开发团队，最大化地实现产品的价值。

Product Backlog

Product Backlog，简称“PB”，中文翻译是“产品待办事项”，就是要实现产品价值，需要做的事情。这里包括业务功能和非业物功能。产品待办事项中的功能由Product Owner（PO）决定其内容（即要做什么），PO决定优先级（即先做哪个功能），因为PO是对产品的价值负责的，而且他是和客户/用户沟通最多的。

Product Owner 职责

PO最重要的一个职责就是管理好Product Backlog(PB)：

1、首先能够向团队清楚地传达Product Backlog的内容。

2、确保团队能够理解Product Backlog中的内容。

3、为了达到产品的目标和任务，PO对Product Backlog中的内容进行最优排序。

4、确保Product Backlog中的内容是可视化的，透明的，对任何人都是清晰的。同时要告知团队接下来做什么。

5、优化团队工作的价值。

Scrum Master

敏捷开发中的SM即Scrum Master，字面意思是敏捷专家或者敏捷大师，即熟悉敏捷开发模式及敏捷实施流程的人员。一般可由敏捷团队当中的开发负责人担任，部分能力很强且懂技术的产品经理也可担任这个角色，因涉及到工作量评估和分派等工作，最好都是由技术能力较强的人员担任。

角色定义

Scrum Master是团队的导师和组织者，与Product Owner紧密合作，及时为团队成员提供帮助。促使team按照scrum方式运行，为Scrum过程负责的人。

Scrum Master并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队干扰的角色。 Scrum Master是规则的执行者，他是Scrum团队中的服务型领导。

工作职责

确保scrum被理解和正确使用并使得Scrum的收益最大化。主要职责如下：

1、保证团队资源合理利用；

2、保证各个角色及职责良好协作；

3、解决团队开发中的障碍；

4、作为团队和团队外部的接口，协调解决沟通中的问题；

5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计划会议）, Daily Stand-up Meeting（每日站会）, Sprint Review Meeting（Sprint评审会）和 Sprint Retrospective Meeting（Sprint回顾会）

总结SM角色就是：教整个团队怎么做，如何估时，跟进每天进度，风险控制，定期总结，计划排定。

Sprint

Sprint（冲刺）：Scrum guide中把固定时间盒周期称为sprint（冲刺）

Sprint 说的是类似橄榄球比赛中的冲刺：大家团结一致，为了完成该Sprint的目标疯狂向前冲。

sprint强调尽快（run as fast as you can）

迭代强调重复（again and again）

Sprint包含计划会议、每日例会、开发工作、评审会议、回顾会议。
在一个Sprint中，开发团队成员、Sprint目标不应该改变。
一个Sprint的时间应控制在两周左右。合适的时间可以确保Sprint目标不随便变化，把风险限制在一个月的成本上。
如果某个Sprint目标过时了，产品负责人可以提前取消Sprint。

1）Sprint计划会议
计划会议确定Sprint中要完成的工作，有整个Scrum团队一起完成。

会议输入：产品待办事项列表（Product Backlog）、团队对这个Sprint的接受程度以及以往的表现
注意事项：首先需要明确回答两个问题：1、这个Sprint最终完成后要交付的结果 2、为此需要做的具体工作

会议结果：根据产品待办事项，开发团队对每个待办事项预估工作量，并开发团队成员认领待办事项。
注意事项：产品负责人需要对待办事项做出说明，协助开发团队做出取舍；开发团队需要明确sprint最初几天的工作内容，分解为少于一天的量。

2）每日例会
目标：评估Sprint进度。同步成员的活动，并创建一天的计划。提前暴露问题，降低风险。
开发团队中的每个成员应说明：已完成的工作，准备完成的工作，遇到的障碍、可能的风险
注意事项：Scrum Master确保会议正常举行，控制时间应该确保每个成员都了解目前的进度以及每个成员各自的工作；应该强调交流沟通，提前暴露可能的问题，

3）Sprint评审会议
会议内容：

产品负责人确定哪些已完成，哪些未完成
开发团队讨论在Sprint中哪些进度顺利、遇到了什么问题，如何解决的
开发团队演示完成的工作
整个团队就下一步的工作进行探讨，根据完成的事项，最终输出一份修订的产品代办列表

4）Sprint回顾会议
Scrum团队检验自身，并列出要改进的点
对前一个Sprint周期中的人、过程、工具进行检验，列出 better 和 to be better，列出要改进的点

迭代过程（Iterative process）

用户故事（User stories）

任务（Tasks）

站立会议（Stand-up meeting）

持续集成（Continuous integration）

最简方案（Simplest solutions）

重构（Re-factoring）

敏捷开发任务看板：

团队会在开放式办公区域放置一块白板，上面粘贴着所有的Story Card，按当前的开发状态贴在4个区域中，分别是：未开发，开发中，预测试中，测试中。Story Card的开发人员和测试人员根据开发进度在Story Wall上移动Story Card，更新Story Card的状态。这种方式可以对项目开发进度有一个非常直观的了解。

燃尽图

C 优点

​ 1、迭代快，开发周期短;

2、不再耗费大量的时间来写文档，而是人与人面对面交流，只写一些必要的文档;

3、分工详细，每天都输出成果，客户能够看得到，会信任项目团队;

4、沟通多，容易发现问题，同时能够激起团队的协作、奋斗精神;

D 缺点

1、人与人之间的信任是非常重要的环节，但是这个比较难完成，技术团队的成员可能技术能力差别大，同时也有互相竞争，又或者是项目团队的成员有所保留，不愿意这样的沟通;

2、团队在开发期间的任务多、压力大，需要时刻保持“兴奋”，一般很难做到。

E 敏捷开发里的关键概念

敏捷开发中的测试

1、传统测试VS敏捷测试

按照规格说明书来进行测试 VS 根据客户实际的需求和业务价值来进行测试
正确地做事 VS 做正确的事情

测试人员是提出建议者而非守门员

不仅进行确认测试，也可以发现需求缺失发现风险并与团队及客户沟通
及时向团队提供关于产品质量的反馈，便于调整在产品和版本的发布计划中提出建议
知识分享:协助整个团队参与到测试活动中来
协助团队从内部提升质量，让质量融入到产品开发中来

2、敏捷人员需要做到

具有丰富的产品知识，和对用户业务目标的准确了解，对不同系统和数据库等所用到的技术知识的了解，和不同角色以及客户进行有效沟通
主动验证质量目标并及时说出自己的想法
编写测试计划，列出需要执行的活动并进行估算自动化测试的能力和对测试工具的掌握
知识分享
持续反馈

3、敏捷开发团队介绍

我们的敏捷开发团队由四位开发人员、两位测试人员、一位产品设计，一位项目经理和一位产品经理组成（参见图 每天早上十点，在固定的时间和会议室里面，团队会举行站立会议。这时候，团队成员按照既定的顺序向项目经理汇报各自前一天完成的任务，所遇到的困难和当天要完成的任务。同时，项目经理更新 Sprint Backlog（一张制作精良的 Excel 表格），并及时解决每个人所提出的问题。

敏捷开发团队成员

由于敏捷开发要求参与人能够快速而高效得应对变化，所以无形中对测试人员提出很高的要求。

4、测试人员需要具备的素质

测试是软件开发中不可或缺的一部分。在敏捷软件开发中亦是如此。不同的组织给测试人员以不同的称号：测试开发 (Test Developer)、质量分析员 (Quality Analyst)、软件质量工程师 (Software Quality Engineer) 等。

每个称号隐含有不同的职能。以上的称号分别对应以下的能力要求：

具有质量检测和编写代码的能力–> 测试开发
具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员
具有开发和执行测试程序的能力 -> 软件质量工程师
总结而言，有三方面的基本素质要求：代码编写（Coding）、测试 (Testing) 和分析 (Analysis)。

在很多其他的开发流程中，各个测试阶段对测试人员的能力有所不同；有时候侧重分析（比如系统配置测试），有时候侧重代码编写 ( 比如自动化测试 )。但是，在敏捷开发流程中，测试人员需要结合这三方面来开展工作，只有这样才能真正反映敏捷测试的本质：简单而高效得应对变化。

5、 测试人员的主要职责

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

定义质量 (Define Quality)：这应该是软件测试人员的基本职责。敏捷方法鼓励测试人员在 Sprint 计划的时候直接与客户交流，从自己的经验出发，共同为产品功能制定质量要求。
交流缺陷（Communication）：敏捷过程强调团队中的交流。开发人员经常会专注于重要而新奇的功能，测试人员应该抓住细节，寻找设计中的“missing door”；另外，开发人员使用单元测试来保证产品的基本质量，测试人员可以使用验收测试（Acceptance Test）来鉴定客户需求与实际成果之间的不一致性。
及时反馈 (Feedback): 敏捷过程强调简单而高效。测试人员需要及时反馈产品目前的质量问题。这样一来，团队才可以立刻着手解决。如果传统的流程是一周汇总一次状态的话，敏捷流程要求每天汇总质量问题。在我们的项目中，内部的测试报告会以网页的形式显示在内部站点上。每个团队成员能够随时获取。另外，我们的测试框架提供自助测试 (Self-assistant Test)：通过点击测试用例列表中的某个具体用例，开发人员不需要中断测试人员的工作就可以重现缺陷。

6、测试人员的主要工作

典型的敏捷开发和测试活动主要由三部分构成，从最初的用户故事设计和发布计划，到几次 Sprint 周期的迭代开发和测试，以及最后的产品发布阶段。每个时间段都有相应的测试活动。通常 Sprint 周期被分成两类：特征周期（Feature Sprint）和发布周期（Release Sprint）。特征周期主要涉及新功能的开发和各类测试。发布周期则会结合计划，确定新版本功能，然后对最新的功能进行测试。

对各阶段相应的测试活动作详细的介绍和分析

①用户故事设计和发布计划阶段

在用户故事和发布计划阶段，项目经理和产品经理会根据客户的需求，制定概要的产品发布日程计划。此时，测试人员可以和开发人员一起学习新的功能，了解客户的需求。其中，有两个主要活动：寻找隐藏的假设和设计概要的验收测试用例。

寻找隐藏的假设

正如前文所述，开发人员通常关注一些重要的系统功能而忽视细节。此外，敏捷开发倡导简单的实现方案，每个开发 Sprint 周期不可能将功能完美得实现；相反，每个 Sprint 都会增量得开发一些功能。所以，测试人员在最初就需要从各种角度来寻找系统需求，探索隐藏的假设。

设计概要的验收测试用例

定义完一系列用户故事后，测试人员就可以着手设计概要的验收测试用例。正如我们在前文论述，不同于单元测试，验收测试检查系统是否满足客户的预期，也就是用户故事是否能够实现。于是，测试人员可以根据每条用户故事来扩展，寻找其中的“动作”，然后为每条“动作”制定正例和反例。

②迭代 Sprint 阶段

当一个 Sprint 周期正式开始时，项目经理将制定该周期的具体开发和测试任务。在定期的 Sprint 计划会议（Planning Meeting）上，每位团队成员都要提供自己在未来一个 Sprint 周期中的休假和培训计划。另外，每个团队可以根据各自团队成员的能力和工作经验，适当设定一个工作负载值（Load Factor）。比如，我们团队的工作负载值为 75%，也就是说每个人平均每天工作 6 小时（以 8 小时计算）。接着，大家就可以开始分配任务。

当开发团队开始编码和单元测试时，测试人员的工作重点包括：估算验收测试的时间、估算测试框架的搭建、详细设计验收测试和编写验收测试代码。第两个主要活动一般在项目初期的 Sprint 周期中完成。其他的三个主要活动将在接下来的多个 Sprint 周期中视情况迭代进行。下面我们将具体介绍每个主要活动。

估算测试框架的搭建

测试框架是自动测试必不可少的一部分工作。由于敏捷开发流程倡导快速而高效得完成任务，这就要求一定的自动测试率。一个完善的测试框架可以大大提高测试效率，及时反馈产品的质量。

在敏捷开发流程中，在第一个 Sprint 周期里，需要增加一项建立测试框架的任务。在随后的迭代过程中，只有当测试框架需要大幅度调整时，测试团队才需要考虑将其单独作为任务，否则可以不用作为主要任务罗列出来。

详细设计验收测试用例

完成对测试任务的估算，接着就可以着手详细设计验收测试用例。我们可以对概要设计中的测试用例进行细化，根据不同的测试环境、测试数据以及测试结果，编写更详细的测试用例。另外，可以结合几个用例，完成一个复杂的测试操作。

由于敏捷开发的流程是不断迭代的过程，所以很多复杂的功能可能会在未来的 Sprint 周期中被优化。对测试人员而言，一个有效的方法是尽量将一些验证基本功能的测试用例作为基本验证测试用例（Basic Verification Test Case）在第一时间实现自动化；而对一些复杂的功能测试用例，可以先采用手工的方法测试，直到在未来 Sprint 周期中该功能达到稳定时候再考虑自动化。此外，对测试中出现的缺陷可以设计回归测试用例（Regression Test Case），为其编写自动测试代码，使得此类问题在发布周期（Release Sprint）时可以顺利而高效得进行验证。

编写验收测试用例

敏捷开发不提倡撰写太多的文档，提倡直接编写测试用例。此外，测试人员和客户应取得良好的沟通，将这些需求总结下来，转化成验收测试用例。如果资源充足，最好对验收测试用例建立版本控制机制。

考虑到需求在每一轮 Sprint 周期中会不断得变化，测试团队要控制测试的自动化率，正确估计未来功能的增减。自动化率过高会导致后期大量测试代码需要重构，反而增加很多工作量。

③ Sprint 结束和下一个 Sprint 开始

在一个 Sprint 周期结束时，团队要举行一个回顾会议（Retrospective Meeting）。团队成员可以在会议上畅所欲言，指出在过去一个 Sprint 周期中可行的，不可行的和有待改进的地方。待改进之处将在项目经理监督下于未来的 Sprint 周期中实现。

由于敏捷开发倡导增量开发，当新的 Sprint 开始时，测试团队需要根据新 Sprint 周期的开发进度及时重构验收测试。如果新 Sprint 周期没有具体的新功能开发，测试团队可以将精力集中在执行验收测试和寻找缺陷上。

如果下一个 Sprint 周期是发布周期，那么测试人员需要准备执行回归测试。下面我们来详细了解每个测试活动。

重构验收测试

敏捷开发是以迭代方式进行的，功能在每次迭代中推陈出新。于是，验收测试用例经常需要修改或者添加，相应的验收测试代码也需要删减。这部分工作如果时间花销很大，最好在估算的时候一并提出。

在下一个 Sprint 周期中，我们需要实现之前没有实现的“模糊查找”功能。测试人员要在新的 Sprint 周期中更新原来的验收测试用例，在测试“搜索”模块中添加模糊查找测试。重新估算的测试任务参加下表：

任务，估计时间
设计测试用例，准备测试数据（模糊搜索数据集）
加载数据集
编写自动测试代码
执行测试和汇报结果
总结
执行验收测试

验收测试可以分为两大类，基本验证测试和功能测试。如果是基本验证测试，推荐开发人员在运行完单元测试和提交代码前直接运行自动测试脚本。如果是功能测试，可以在每个 Sprint 后期，新功能代码提交后，由测试人员单独执行。

敏捷开发的开发和测试是相辅相成的。一旦基本验证测试出现问题，那就说明开发人员的实现违反了最初客户定义的需求，所以不能够提交。如果功能测试出现问题，那么测试人员要及时与开发人员沟通。如果是缺陷，需及时上报给项目经理，并在每天站立会议中提出；如果不是，那么继续下一项任务。这个过程充分体现了敏捷开发所提倡的团队交流机制。

执行回归测试

在发布周期中，测试人员所肩负的任务非常重要，因为这是产品发布前的最后质量检验。

首先，要建立一套自动生成 build、运行自动测试代码、手工执行测试用例并汇总测试结果的框架。

其次，定期执行各类测试，包括功能和系统测试。

最后，要整理之前在每个特征测试周期中出现的问题。如果已经整理并归类为回归测试用例，那么只要定时执行就可以了；否则，需一一添加。如果用例已经被自动化，可以直接运行；如果是手工测试，测试人员需要按照测试用例进行操作，最后汇总测试结果。这部分测试就是所谓的回归测试。

DevOPS

DevOps是什么

有人说它是一种方法，也有人说它是一种工具，还有人说它是一种思想。更有甚者，说它是一种哲学。

DevOps的起源

这个故事有点长，从头开始讲起吧。

上个世纪40年代，世界上第一台计算机诞生。从诞生之日起，它就离不开程序（Program）的驱动。而负责编写程序的人，就被称为“程序员”（Programmer）。

程序员是计算机的驾驭者，也是极其稀缺的人才。那个时候，只有高学历、名校出身的人，才有资格成为程序员，操控计算机。

随着人类科技的不断发展，PC和Internet陆续问世，我们进入了全民拥抱信息化的时代。越来越多的企业开始将计算机作为办公用的工具，用以提升生产力。而普通个人用户也开始将计算机作为娱乐工具，用以改善生活品质。

于是，计算机的程序，开始变成了一门生意。程序，逐步演进为“软件（software）”，变成了最赚钱的产品之一。

在软件产业里，程序员有了更专业的称谓，叫做“软件开发工程师（Software Development Engineer）”，也就是我们常说的“码农”。

我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。

最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。

随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升。一个人已经hold不住了，就开始出现了精细化分工。

码农的队伍扩大，工种增加。除了软件开发工程师之外，又有了软件测试工程师，软件运维工程师。

分工之后，传统的软件开发流程是这样的：

软件开发人员花费数周和数月编写代码，然后将代码交给QA（质量保障）团队进行测试，然后将最终的发布版交给运维团队去布署。所有的这三个阶段，即开发，测试，布署。

早期所采用的软件交付模型，称之为“瀑布（Waterfall）模型”。

瀑布模型，简而言之，就是等一个阶段所有工作完成之后，再进入下一个阶段。

这种模型适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，轮流执行自己的职责即可。

但是，项目不可能是单向运作的。客户也是有需求的。产品也是会有问题的，需要改进的。

随着时间推移，用户对系统的需求不断增加，与此同时，用户给的时间周期却越来越少。在这个情况下，大家发现，笨重迟缓的瀑布式开发已经不合时宜了。

于是，软件开发团队引入了一个新的概念，那就是大名鼎鼎的——“敏捷开发（Agile Development）”。

敏捷开发在2000年左右开始被世人所关注，是一种能应对快速变化需求的软件开发能力。其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点，然后这样：

有两个词经常会伴随着DevOps出现，那就是CI和CD。CI是Continuous Integration（持续集成），而CD对应多个英文，Continuous Delivery（持续交付）或Continuous Deployment（持续部署）。

美其名曰：“持续（Continuous）”，其实就是“加速——反复——加速——反复……”，这样子。

画个图大家可能更明白一点：

敏捷开发大幅提高了开发团队的工作效率，让版本的更新速度变得更快。

很多人可能会觉得，“更新版本的速度快了，风险不是更大了吗？”

其实，事实并非如此。

敏捷开发可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的版本变化是比较小的，风险会更小（如下图所示）。即使出现问题，修复起来也会相对容易一些。

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈。

![img]

运维工程师，和开发工程师有着完全不同的思维逻辑。运维团队的座右铭，很简单，就是“稳定压倒一切”。运维的核心诉求，就是不出问题。

什么情况下最容易出问题？发生改变的时候最容易出问题。所以说，运维非常排斥“改变”。

于是乎，矛盾就在两者之间集中爆发了。

这个时候，我们的DevOps，隆重登场了。

DevOps到底是什么

DevOps这个词，其实就是Development和Operations两个词的组合。它的英文发音是 /de’vɒps/，类似于“迪沃普斯”。

DevOps的维基百科定义是这样的：

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

这个定位稍微有点抽象，但是并不难理解。反正它不是某一个特定软件、工具或平台的名字。

从目标来看，DevOps就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠。

举例说明什么是devOPS

为什么要合并这两个领域？原因很多，但首要原因是：我们目前的工作流程是脱节的。绝对的脱节。很多公司的开发部门和运维部门之间存在的深刻矛盾，其实就是这个“脱节”造成的。

下面是一个大家都基本熟悉的例子：部署软件产品。

开发部门要开发一款新产品。这款产品要使用最新最炫的技术，来保证客户的所有花俏的需求，从而给公司带来百万美元的利润。这款产品被要求使用最新的技术和运行平台，还得马上交付。于是开发部门没日没夜的加班、赶代码（cuts code like crazy），终于如期完成了任务。然后他们把自己的“杰作”一股脑的甩给了运维部门，后者还没能完全接手，前者已经迫不及待的开始了庆功会。

接到产品后，运维部门每个人的心中都充满了恐惧。

下面就是运维部门的恐惧之源：（{A.B.C}表示A或B或C之一）

• 这款优秀的产品在目前的底层平台上无法运行，因为这个平台{太古老了，空间不足，不支持某某版本}
• 这款产品的体系结构跟我们的{存储，网络，部署，安全}模型不匹配。
• 这款产品的{ 报告，安全，监视，备份，服务提供} 我们搞不懂 ，所以没法把它做成实际可用的产品。

尽管伴随着不绝于耳的抱怨和咒骂，运维部门最终还是把这款产品安装好了。不幸的是，由于做了很多蹩脚的修改和不合理的强迫式运行，这款产品的性能最后被归结为：终极失败（Epic Fail）。

于是非常沮丧的运维部门开始记录各种问题，源源不断的给开发部门提Issue。而开发部门的回应基本上都是：

• 这不是我们的错 —— 我们的代码非常完美——而是（运维部门的）部署做的太差劲了。
• 运维部门比较笨，他们不懂新技术—— 为什么他们没法实现最新的技术呢？为什么他们这么落伍呢？
• 在我的机器上运行的没问题啊……

两个部门之间的交流很快变成了一场暴风骤雨。客户（以及股东、投资方和管理层）则成了蒙受损失的失败方。最终公司损失了无数的金钱，大家也都失业了。终极的失败。

DevOps 又有啥不同？它有什么好处？

DevOps 就是想方设法的避免这种“终极失败”，同时让大家用更聪明更有效的方式去工作。它是一种框架，包含了很多优秀想法和原则，它鼓励开发部门和运维部门通力合作。在DevOps环境中，开发人员和系统管理员会构建一些关系、流程和工具，从而更好的与客户互动，最终提供更好的服务。

DevOps 也不仅仅是一种软件的部署方法。它通过一种全新的方式，来思考如何让软件的作者（开发部门）和运营者（运营部门）进行合作与协同。使用了DevOps模型之后，会使两个部门更好的交互，使两者的关系得到改善，从而让很多领域从中受益，例如：自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提供（provisioning）等等。

部门之间关系

早参与，多参与。对于开发人员，要让运维人员常驻到开发部门，全程参与开发流程。邀请运维人员参与你的Scrum或者开发会议，与他们分享项目计划、分享新技术的点子和心得。搜集功能性需求（指开发人员用到的需求）的同时也要搜集运维方面的需求。把对于“发布、备份、监控、安全、配置管理和系统功能”的测试作为一项独立的项目流程。软件产品在开发时解决的问题越多，那么在使用时暴露给用户的问题就越少。给运维人员做培训，让他们弄清楚项目的体系结构和核心代码。如果运维人员在反馈bug时提供的信息越多，那么你花在排查问题（trouble-shooting) 的时间就越少，这个bug也就会更快的被解决掉。

对于运维人员，在遇到问题时需要把开发人员加进来，大家一起解决问题。邀请开发人员参与你们的会议，分享项目进度（roadmaps），并且共同修订工作计划。运维人员一定要了解开发部门下一步的工作方向，从而确保产品运行的底层平台能够良好的支持最新技术。开发人员也会带来相关的技术、知识和工作，帮助你们改善产品的运行环境，使其更加易于维护、简洁有效。

有一些开发领域的概念，例如：“要根据API而非封闭的interface来构建工具”，分布式版本控制，驱动测试开发，以及诸如敏捷开发、看板管理（Kanban）和Scrum等方法论。如果把这些概念应用在运维领域，同样会产生革命性的变革。

不要惧怕新点子和新技术。我们可以随时随地的向他人学习，哪怕是一句“我们再也不要那样做了！”也会让我们从中获益。尽管处于不同的部门，但是我们要共同学习、共同成长，这样才能协同工作的更好！

按照从高到低的顺序，有效的沟通方式应该是：面对面交流 、视频会议、电话、即时通讯软件、Email。

目前支持DevOps的软件实在是太多了。话说回来，现在DevOps之所以被吹得天花乱坠，也有这些软件和平台的功劳，可以趁机卖钱啊。

DevOps生态圈中令人眼花缭乱的工具

上述这些关键要素里面，技术（工具和平台）是最容易实现的，流程次之，思维转变反而最困难。

换言之，DevOps考验的不仅是一家企业的技术，更是管理水平和企业文化。

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期，而不仅限于开发阶段。

下面这张图，更明显地说明了DevOps所处的位置，还有它的价值：

DevOps的发展现状

DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，为了在Twitter上更方便的传播，由DevOpsDays缩写为DevOps。

目前，DevOps处于高速增长的阶段。尤其是在大企业中，DevOps受到了广泛的欢迎。

根据2018年的调查发现，74%的受访者已经接受了DevOps，而前一年这一比例为66%。

越大的企业，越喜欢DevOps。包括Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、linkedIn、Netflix、NASA、Starbucks、Walmart、Sony等公司，都在采用DevOps。

如今，DevOps几乎已经成为了软件工程的代名词。

DevOps迅猛发展，相关专业人才的薪资待遇也跟着水涨船高。

根据调研，DevOps工程师在美国的平均年薪为130000美金，在中国平均年薪也在40万-50万区间，能力强者年薪百万也是比比皆是。

薪资的猛涨，又带动了IT工程师们学习和认证的热潮。

DevOps的认证目前最受欢迎的就是EXIN DevOps Master和EXIN DevOps Professional。这些认证的培训费用不低，但是仍然吸引了很多人踊跃报名。

![img]

EXIN DevOps认证体系

DevOps与虚拟化、容器、微服务

这几年云计算技术突飞猛进，大家应该对虚拟化、容器、微服务这些概念并不陌生。当我们提到这些概念的时候，也会偶尔提及DevOps。

它们之间有什么联系呢？

其实很简单。

大家可以设想一下，如果要对一项工作进行精细化分工，我们是对一个大铁疙瘩进行加工方便？还是拆成一块一块进行加工更加方便？

显然是拆分之后会更加方便。

所谓“微服务”，就是将原来黑盒化的一个整体产品进行拆分（解耦），从一个提供多种服务的整体，拆成各自提供不同服务的多个个体。如下图所示：

体式架构（Monolithic）→ 微服务架构（Microservices）

微服务架构下，不同的工程师可以对各自负责的模块进行处理，例如开发、测试、部署、迭代。

而虚拟化，其实就是一种敏捷的云计算服务。它从硬件上，将一个系统“划分”为多个系统，系统之间相互隔离，为微服务提供便利。

容器就更彻底了，不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”（Container），占用资源更少，部署速度更快。

虚拟化和容器，其实为DevOps提供了很好的前提条件。开发环境和部署环境都可以更好地隔离了，减小了相互之间的影响。

这也是DevOps为什么2009年时不火，现在越来越火的一个主要原因之一。

天下武功，唯快不破。

时代发展到现在，客户的需求瞬息万变，市场的风向也难以预测。作为企业，想要生存下去，只有让自己变得更快。作为员工，必须让自己眼光更加长远，内心更加包容。

面试题

软件测试模型？

软件测试流程？

需求分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JP3lvzF4-1645522648167)(…/.image/image-20220221154002102.png)]

软件需求

软件需求的重要性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fzQ5Drzm-1645522648168)(…/.image/image-20220222145505995.png)]

客户项目统计数据

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AWKXBNnO-1645522648168)(…/.image/image-20220222145632425.png)]

Software Requirements Specification，简称SRS

在特定环境下要完成一定功能的软件产品、程序或一组程序的说明 描述需求规格

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-63YhJiS1-1645522648168)(…/.image/image-20220221154152086.png)]

演示示例： 行政服务中心政务平台需求文档

需求分类

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lc14f25O-1645522648169)(…/.image/image-20220221202651760.png)]

测试需求

• 测试需求概念

  • 可直接形成测试大纲

• 测试需求的重要性

  • 是开发测试用例的依据
  • 是衡量测试覆盖率的重要指标
  • 有助于保证测试的质量和进度

• 测试需求的特性要求

  • 可核实的
  • 满足需求的正常的前置条件，不满足需求时的出错条件

需求分析对于开发和测试的影响

• 开发

  • 如果需求不明确，系统功能研发不合理，导致软件包含大量bug
  • 大量bug修改，影响进度和团队情绪
  • 进度收到影响，可能造成公司产品失去市场先机

• 测试

  • 如果不能很好理解需求，会被开发牵着鼻子走，也会被人怀疑测试能力
  • 不能及时发现开发的bug，没法保证测试质量

测试需求分析

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OKBNqW9f-1645522648169)(…/.image/image-20220221203625668.png)]

需求挖掘

• 需求挖掘的过程

  • 是将软件需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求

• 需求挖掘的方法

  • 通过列表的形式对软件需求进行梳理，形成原始测试需求列表

• 功能需求==》》输入方面

  • 输入来源是什么？

  • 输入数据数量是几个？

  • 如果有错误输入，响应是什么？

  • 什么是非法输入？什么是无效输入？

    • 非法就是程序能做，但做了就非法，这种情况也需要报错
    • 无效输入是指输入了有效输入以外的值。

    如：国名的下拉框不能出现台湾，台湾就是非法输入，却并不一定是无效输入。程序需要返回异常提示。

• 功能需求==》》处理方面

  • 输入数据的有效性检测的流程是什么？
  • 操作的确切次序，包含各时间的时序是什么
    • 按照特定时间变化的不同情况的测试
  • 对异常情况的回应是什么？例如：溢出、通讯失败、错误处理

• 功能需求==》》结果输出方面

  • 输出到何处（如浏览器，打印机，文件）？
  • 输出的数量是多少？
  • 输出的时序是什么样的？
    • 按照特定时间变化的不同情况的测试结果
  • 对非法值得处理是什么样的？

• 功能需求==》》性能需求方面

  • 静态量化可能包含
    • 支持的终端数目
    • 支持的并发用户数
    • 处理的文件和记录的数目，表和文件的大小
  • 动态量化可能包含
    • 在正常或峰值工作情况下一个特定时间段处理事务或任务的数目及数据量
    • 正常或峰值工作量情况下处理某个事务或任务所占用系统资源的数量

• 功能需求==》》用户接口方面

  • 系统用户显示时要求的屏幕格式
  • 页面规划及报告或菜单的内容
  • 输入和输出的相关时序
  • 一些组合功能键的用法

软件开发文档评审

什么是评审？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MIHHrqnL-1645522648169)(.image/image-20220222150630050.png)]

测试文档评审

内部评审

• 部门评审（测试部门：部门有相关项目经验的测试优秀人员）

现场评审

• 项目组评审（开发人员，测试人员，架构设计人员，产品经理，项目经理和客户方的业务人员）

一般测试计划和方案，测试用例，测试报告都需要经过评审定版，然后执行。

项目组和客户比较关注测试计划的时间安排，测试策略和测试用例业务逻辑的覆盖

文档评审的形式（理解，不需要记忆）

• 正式评审：是指通过开评审会的形式，组织多个专家，将涉及到的人员聚集在一起，并定义好参与评审人员的角色和职责，审进行正规的评审。

• 非正式评审：通过非正式的，一般通过邮件、电话、网络聊天等对需求进行评审。两种评审各有利弊，在评审时视情况而定。

• 相互评审、交叉评审：甲乙在两个项目组，处在一个领域，但工作内容不同，甲的工作成果交给乙审查，乙的工作成果交给甲审查，相互评审是非正式评审，但是非常有效的方式，在工作中经常使用。

• 轮查：又称分配审查方法，是一种异步评审方式。作者将需要评审的内容发给各个评审员，并收集他们的评审意见，这是一种非正式评审。

• 走查：产品的作者将产品在现场向同事介绍，描述产品要有怎样的功能、结构，从头到尾走一遍，以收集大家的意见。希望参与评审的同事能发现其中的错误，进行现场讨论这种方式处于正式和非正式之间，其应用普通。

• 小组评审：通过正式的评审会议完成评审工作，是有计划和结构化的评审形式。评审定义了评审会议中的各种角色和相应的责任，一般所有参与者在评审会仪的前几天就能拿到评审材料，并对该材料进行了独立研究。

• 审查：审查和小组评审很相似，但更为严格，是最系统、最严密、最系统化的评审形式，包含了制定计划、准备和组织会议、跟着和分析审查结果等。

扩展（了解）

代码走查

代码走查**(code walkthrough)**是一个开发人员与架构师集中讨论代码的过程。代码走查的目的是交换有关代码是如何书写的思路，并建立一个对代码的标准集体阐述。 在代码走查的过程中，开发人员都应该有机会向其他人来阐述他们的代码。 通常地，即便是简单的代码阐述也会帮助开发人员识别出错误并预想出对以前麻烦问题的新的解决办法。

代码审查

代码审查（英语：Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。

练习

• 写协同办公系统项目测试用例（写测试用例）
• 写行政服务中心政务平台（进行需求分析）
• 一支圆珠笔: 能够在软硬纸上书写;可以在不同温度下正常使用；笔的材质在安全范围内；书写流畅，不易擦拭；笔套和笔杆合适;一只笔能用1年;摔在地上，还能使用；笔芯墨水不会倒流，能够使用不同型号的笔芯；正常用力写字不会坏；合适3岁以上小孩使用。
• 朋友圈发送动态编辑界面的测试
• 练习1：聊天工具测试需求
• 练习2：航班订票系统测试需求

代理商项目安装

代理商（AgentSysment）系统

LINUX上系统安装

在虚拟机界面中按CTRL+alt，让鼠标移出来

再按下win+D，即可切换回原主机的界面

--------------------------------------------------------------------------------

ubuntu

注意，由于xshell远程连接ubuntu是通过ssh协议的，所以，确保ubuntu安装ssh服务器：

输入以下命令进行安装远程ssh服务

# sudo apt-get install openssh-server

若没有ssh，需要执行

# sudo apt-get install ssh

Ubuntu首次安装设置管理员root密码

sudo passwd root

--------------------------------------------------------------------------------

Ubuntu在用root账户使用xftp连接时提示拒绝连接

一般来说Linux不允许使用root账户连接，修改配置

vi /etc/ssh/sshd_config

#Authentication:

LoginGraceTime 120

PermitRootLogin prohibit-password

StrictModes yes

PermitRootLogin参数修改为yes

#Authentication:

LoginGraceTime 120

PermitRootLogin yes

StrictModes yes

修改后重启ssh服务

sudo /etc/init.d/ssh restart

--------------------------------------------------------------------------------

防火墙

sudo ufw status

sudo ufw disable

sudo ufw enable

1:查看防火状态

systemctl status firewalld

service iptables status

2:暂时关闭防火墙

systemctl stop firewalld

service iptables stop

3:永久关闭防火墙

systemctl disable firewalld

chkconfig iptables off

4:重启防火墙

systemctl enable firewalld

service iptables restart

5:永久关闭后重启

//暂时还没有试过

chkconfig iptables on

--------------------------------------------------------------------------------

安装mysql

$ sudo apt-get update #更新软件源

$ sudo apt-get install mysql-server #安装mysql

启动和关闭mysql服务器：

$ service mysql start

$ service mysql stop

确认是否启动成功，mysql节点处于LISTEN状态表示启动成功：

sudo netstat -tap | grep mysql

mysql -u root -proot

select host, user, authentication_string,plugin from user;

update user set host = ‘%’ where user = ‘root’;

二、注释bind-address = 127.0.0.1

在Ubuntu系统中，MySQL默认只能本地访问，不能远程访问，因为访问地址被绑定死了为本地127.0.0.1，想要远程访问的话，需要去/etc/mysql/mysql.conf.d中找到bind-address = 127.0.0.1，然后注释掉这一句，也就是在这句前面加上#号。

然后重启MySQL就可以了。

重启命令为：service mysql restart

更新密码的类型

alter user ‘root’@’%’ identified with mysql_native_password by ‘123456’;

flush privileges;

配置jdk的环境变量

vi /etc/profile

大写的G调到最后

JAVA_HOME=/usr/local/jdk1.8.0_191

JAVA_BIN=$JAVA_HOME/bin

JRE_HOME=$JAVA_HOME/jre

JRE_BIN=$JRE_HOME/bin

PATH=$JAV{A}_{B}IN:$JRE_BIN:$PATH

export JAVA_HOME JRE_HOME PATH

访问地址：

http://192.168.146.128:8080/login.action

Windows上系统安装

1.在windows上安装mysql数据库

MySQL 官网 https://www.mysql.com/

点击 DOWNLOADS 进入下载地址，会看到几个不同的版本：

MySQL Enterprise Edition：企业版（收费）

MySQL Cluster CGE：高级集群版（收费）

MySQL Community Edition：社区版（开源免费，但官方不提供技术支持）

通常我们用的都是社区版。点击进入社区版，看到一大堆东西，有点愣住了，不用急，其实点第一个 MySQL Community Server 的下载就可以了。

所以真正的下载地址其实是：https://dev.mysql.com/downloads/mysql/

拉到下面，选择 Windows 系统。

这里提供安装版和解压版，安装版是 32 位的（当然 64 位系统下也能安装），解压版是 64 位的。

点击 Download 后会跳转到如下页面，这是叫你注册/登录的，不理它，点击左下角的 No thanks, just start my download. 开始下载。

安装版是 32 位的，而现在的机器多半是 64 位机，虽然 32 位的程序也可以安装，但是并不建议。安装版的安装也比较容易，所以这里只讲解压版的安装。

2.msi版本解安装后配置环境变量

将安装包解压到你要安装的目录，将 bin 目录添加至环境变量。

3.开启mysql服务,启动对应的端口号

mysq1 -u root - p

-P3308

select host, user , plugin, authentication_string from mysql.user;

注:密码为authentication_string

plugin若是caching_sha2_password改为mysql_native_password的类型

ALTER USER ’ root '@‘localhost’

IDENTIFIED WITH mysqL_native_password BY

"123456’;

赋权操作:

mysql初始密码:phZzMO6dBl,e

grant all privileges on . to ‘root’@’%’ identified by 'Root!!2018’with grant option;

开启关闭防火墙:

systemctl status firewalld.service

systemctl stop firewalld.service

4.连接navicat

导入sql

5.配置jdbc

6.开启tomcat

访问地址