书籍目录
1- 软件测试发展历程
2- 软件测试还值得入行吗?
3- 软件生命周期
4- 什么是软件质量?
5- 什么是软件测试?
6- 软件测试六项原则
7- 软件测试分类(上)
8- 软件测试分类(中)
9- 软件测试分类(下)
10- 冒烟测试
11- 了解研发团队
12- 软件开发模型(上)
13- 软件开发模型(下)
14- B/S架构和C/S架构
15- web工作原理
16- 静态页面和动态页面
17- OSI模型
18- TCP/IP协议
19- HTTP协议
20- WEB核心技术
768
软件测试那些事儿
免费
共20小节
软件测试工程师在各个企业起着举足轻重的作用,把着我们质量的这道大关口。虽然是老生常谈,但作为某养老项目的成员,今天学姐分享一下我们心目中软件测试那些事儿
离线

焦小灰

私信

1- 软件测试发展历程

软件测试由 Glenford J Myers在1979 《Art of Software Testing(软件测试艺术)》一书中明确将调试和测试进行了区分,并给出了软件测试的经典定义:

测试是为发现错误而执行程序的过程。 

至今《软件测试艺术》已经更新到了第三版。

从软件测试活动的出现,到如今软件测试已经经过了60多年的发展,伴随互联网的快速发展和新的软件开发方法出现,近10年软件测
试发生了翻天覆地的变化

1. 以调试为主的软件测试

软件测试是伴随着软件的产生而产生的。早期的软件开发过程中,那时软件规模都很小,复杂程度低,软件开发的过程混乱无序、相当随意,测试的含义比较狭窄,开发人员将测试等同于“调试”,目的是纠正软件中已经知道的故障,常常由开发人员自己完成这部分的工作

也就是开发和使用者为同一个人,软件程序的成功与否主要取决于程序设计的当事人。软件好不好我一个人说了算,那会儿还没有软件测试这个概念

2. 以证明为主的软件测试

直到20世纪60年代,为证明程序设计的正确性而进行了相关的测试,这时候才有了软件测试概念。

  • 在1957年,CHarles Baker在《软件测试发展》一书中就提出测试的概念,并且对调试和测试进行了区分:
  调试(Debug):确保程序做了程序员想让它做的事情
  测试(Testing):确保程序解决了它该解决的问题
  • 1972年在北卡罗来纳大学举行了首届软件测试正式会议

  • 1975年John Good Enough和Susan Gerhart在IEEE上发表了《测试数据选择的原理》,提出软件测试被确定为一种研究方向

这时的软件数量、成本和业务复杂性都大幅度提升,测试的重要性也大大增强,测试的目不仅仅是验证,而且要确认软件是满足需求的,也就是我们常说的“做了正确的事情”

3. 以破坏为主的软件测试

1979年,《软件测试艺术》第一版问世,这本书是测试界的经典之作。书中给出了软件测试的经典定义:

The process of executing a program with the intent of finding errors. 

测试是为发现错误而执行程序的过程

这个观点较之前证明为主的思路,是一个很大的进步。我们不仅要证明软件做了该做的事情,也要保证它没做不该做的事情,这会使测试更加全面,更容易发现问题。这时候软件测试脱颖而出

4. 以评估为主的软件测试

1983年,美国国家标准局(National Bureau of Standards)发布“Guideline for Lifecycle Validation, Verification and Testing of Computer Software”,提出了测试界很有名的两个名词:

验证(Verification) 和 确认(Validation)
Verification: Are we building the product right? 我们构建的产品正确吗?主要为产品的功能可用性
Validation: Are we building the right product? 我们构建了正确的产品吗?主要为产品符合用户预期

也就是常说的 VV(验证和确认)理论,测试被应用在整个软件生命周期中。

同时IEEE提出的软件测试新的定义:

使用人工或自动化的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差异

1983年,Bill Hetzel在《软件测试完全指南》中指出:

测试是以评价一个程序或者系统属性为目标的任何一种活动,测试是对软件质量的度量,就是它不单纯是一个发现错误的过程,
还包含软件质量评价的内容

这时候就制定了各种各样的测试标准,成为软件复用的保证基础,软件测试以及测试工具在这个时期得到了快速的发展:

  • 出现测试经理(test manager),测试分析师(test analyst)等职称

  • 开展正式的国际性测试会议和活动

  • 发表大量测试刊物

  • 发布相关国际标准

以上种种都预示着:软件测试正作为一个独立的、专业的、具有影响力的工程学发展起来了

5. 以预防为主的软件测试

以预防为主是当下软件测试的主流思想之一

STEP(Systematic Test and Evaluation Process)是最早的一个以预防为主的生命周期模型,STEP认为测试与开发是并行的,整个测试的生命周期也是由计划,分析,设计,开发,运行和维护组成,也就是说,测试不是在编码完成后才开始介入,而是贯穿于整个软件生命周期。

随着敏捷开发被提出以来,测试驱动开发、自动化的持续集成等技术的应用,都体现出人们不再满足在编码后对程序的验证和确认,而是事先就通过测试来保证代码的正确性

总结

不管从事哪个行业,都需要了解该行业的发展历程,并制定属于自己的职业规划。软件测试行业也不例外,从事软件测试行业的第一步就是要了解其发展历程。

2- 软件测试还值得入行吗?

互联网不倒,软件测试就不会消亡

国外软件测试行业发展的比较快一些,趋近于饱和状态,国内的软件测试行业起步比较晚,从业人员少,在过去的项目组都没有专门的测试人员,而是由开发人员兼职测试工作,因此存在一些软件质量问题

最近这几年随着互联网和软件行业发展,各行各业的应用都离不开相应的软件作为其支撑和沟通的平台,其软件质量是不可忽视的,如果用户使用软件产品时出现了质量问题,那么很可能会造成一些不可预估的后果和经济损失。因此软件测试也越来越被企业所重视,市场对软件测试人员的需求也与日俱增

1. 市场需求

目前市场上其实并不“缺人”,人真的挺多的,每年毕业这么多学生,肯定有很多人来学习软件测试,投简历的求职者确实很多,但现在企业缺的是“优秀的测试人员

根据不完全统计,中国软件人才缺口超过100万人,其中很大一部分为软件测试人才,缺口达到30~40 万,然而符合企业急需的软件测试工程师在国内现有的人才数量中却寥寥无几,为何会有如此大的缺口呢?

1.1 学校没有软件测试专业

国内传统学历教育在这方面尚处于真空状态,学校没有软件测试专业,所以公司通过校聘招来的人员还得经过公司系统的专业培训才能上岗,这就花费了很大一部分成本,无法满足行业对这一特殊岗位的需求,通过社招的大部分测试人员都是来自培训机构,没有相关的测试经验,从培训机构出来的测试人员构成了测试行业的中坚力量,所占比例是最大的

1.2 国内测试兴起较晚

在2004之前大学毕业生出来找工作,可能几乎没有听说过软件测试这个职位,企业也不重视软件测试,近些年随着互联网信息技术和我国外包业务的发展,很多IT公司开始重视软件测试,并开始组建软件测试团队。

疫情前,人们的“吃、穿、住、用、行”方方面面都有对应APP软件。疫情后,复工最快,最迅速的企业也都是通过互联网技术实现。

过去互联网技术只是让某些企业活的好。未来,互联网技术是很多企业能够活下去的关键点。互联网技术成为新的基建,互联网“基建”化就决定了软件测试行业的缺口会一直扩大。

并且,软件测试岗位,已不仅局限于互联网企业,现已逐步深入到实体产业,金融,通信,医疗,视频VR,汽车,手机……

2. 入行门槛

测试的门槛相对于软件开发来说,还是比较低,它并不要求原来是学计算机的。这个是由软件测试工作本身的性质特点决定的:他要求测试不能仅仅从软件开发的角度去看问题,而是要从客户的角度去看问题

2.1 学历要求

就目前国内市场,软件测试工程师的最低学历要求一般是专科以上学历,有个好的基础,才可能有好的结局;

因此,很多公司对学历有一定的要求,但是软件测试行业对学历也没有强制要求,大专以上学历都可以,因为软件测试行业是要靠真刀真枪拼专业知识的,你行不行,能不能出活,只要实习几个月公司就能完全判断出来;如果有技术,能出活,能给公司解决问题,学历低点没有关系;如果没技术,不能出活,那就算你学历再高可能会被开除。

2.2 英语要求

国内大多数的软件测试招聘中,对英语并没有特别高的要求,也就是说测试人员的英语水平并不会影响工作,但是英语好的测试有很大的优势

  • 可以进入外企,也可以进入对英语有要求的项目组,薪资高、福利好

  • 容易提高自身的测试技术

现在大部分测试工具和文献都是英文版,英文阅读能力强的人自热就更容易掌握最前沿的测试技术,但是现在常用的测试工具都自带汉化,英文不好的也容易掌握

3. 薪资待遇

那么今天,我们不说宽泛性的行业分析,从生活角度观察通过真实的数据,一起来看看国内软件测试行业现状

我们来看下某平台真实的招聘行情:

3.1 初级测试

image

基本不缺人,缺的是物美价廉又有经验的人,工作也比较简单,培训班刚出来的可以做,发招聘出来半个月内必然招满,培训班刚毕业的排着队等招聘,刚毕业的应届生更多。

测试基础,测试文档,沟通能力,或者纯功能测试工作经验2年内,抓包和定位基础BUG

3.2 中级测试

image

到这个阶段除了最基本的初级技能外,还要熟练使用postman、JMeter、ant、Jenkins、fiddler等测试工具,熟悉某一编程语言、数据库、服务器等计算机专业知识

因为工作难度加大,经验要求也会起来,刚培训出来的不是很好挤进来,所以筛选掉大量培训竞争者,面试也就没那么卷了,但是难度依然是有的,加上招中级的公司一般会有学历要求,这里又会筛选掉一批学历不够的竞争者

3.3 高级测试

image
image

到这里了,那是真的缺人,因为高级不仅仅是技能的要求,会有学历和大项目的要求

总结

如果你想做测试的工作,做绝对可以做,并且我认为测试是一个非常好的职位,有特别大的发展潜力!

3- 软件生命周期

软件生命周期又称为软件生存周期或系统开发生命周期,是软件从生产到衰败的一个过程。

软件生命周期内有计划评估、需求分析、设计、编码、测试、运行维护等阶段,每一个阶段都有确定的任务,并产生一定规格的文档,提交给下一个阶段作为继续工作的依据。

image

1. 计划评估

这个阶段说明了做什么软件?所需的时间?投入的成本?将来可取得的效益?

  • 确定软件开发目的、可行性

  • 对项目资源、成本、可取的效益和开发进度做出预估

  • 给出软件的功能、性能、可靠性及接口方面的设想

  • 制定出完成开发任务的实施计划,连同可行性研究报告

计划评估是一个很重要的阶段,也是在整个软件开发过程中不断变化和深入的阶段,能够为整个软件开发项目的成功打下良好的基础,它是软件开发和维护的前提,直接决定了项目的成败。

这一阶段是软件开发方和需求方共同讨论,制定项目总体开发计划,其实就是完成一个初步需求。

2. 需求分析

在确定软件开发可行的前提下,对软件需要实现的各个功能进行详细分析,完成PRD文档《产品需求文档》并和项目组成员共同评审。

  • 对用户的要求或者软件需要实现的各个功能进行详细分析

  • 编写《软件需求规格说明书》或《系统功能说明书》及初步的《系统用户手册》等需求文档

这里,我们需要注意到一点就是,同样的需求在软件开发过程中会不断变化和深入,此时我们便需要制定需求变更计划来应对这种变化,以保证整个项目的正常进行。需求文档通过评审之后,技术部制定技术文档,并进行技术评审,评审通过进行软件开发。

3. 设计

主要把需求转换成相应的体系结构、划分出系统框架,数据库表等 ,输出了《概要设计说明书》、《详细设计说明书》等文档

《概要设计说明书》主要是对整个软件架构的实现,搭建架构,表述各个模块的功能,设计模块接口连接以及数据传递的实现等事务把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块,每个模块都和某些需求相对应。

《详细设计说明书》对概要设计中表述的各模块进行详细分析,包括了对数据库的设计,为源程序编写打下基础

4. 编码

这一阶段是将软件设计开发的结构转化为计算机可以运行的代码。也就是依据《概要设计说明书》和《详细设计说明书》写出以某种程序语言的表示的源码。

在编码中要制定统一、符合标准的编写规范,以保证代码的可读性、易维护性,提高代码的运行效率,完成模块的编码后提交测试。

5. 测试

软件编码完成之后,需要经过严密的测试,以发现整个软件设计过程中存在的问题并加以改正。

检验软件是否符合需求文档,满足客户需求、达到质量要求、一般由独立的小组执行

注意:测试需要制定详细的测试文档,并且严格按照测试文档进行测试,以减少测试的随意性

6. 运维

将软件交付给客户投入正式使用,是软件生命周期中持续时间最长的阶段

在软件开发完成并投入使用之后,由于多方面的原因,软件不能继续满足用户的需求,如果要延续软件的寿命,就必须对软件进行维护,包括纠错性维护和改进性维护两个方面,比如软件错误、系统升级、添加功能、提高系统性能等方面

总结

这种按时间分程的思想方法是软件工程中的一种思想原则,即按部就班、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟,软件生命周期设计方法的指导意义正在逐步减少

4- 什么是软件质量?

软件质量是一个抽象的存在 ,软件质量在线的时候我们是比较难察觉它的存在的,我们不知道它就存在于我们的每一次需求讨论中、每一次的设计斟酌里、每一回车的代码提交时。但是一旦有客户抱怨产品不好用,或者发现产品缺陷时,质量这个隐形的存在似乎就变得特别醒目。

通常情况下,人们习惯说好的软件质量就是实现了客户对软件的所有需求。但是什么是需求呢?

小区门禁系统通过人脸识别实现自动开门,这是个很明确的功能需求。满足了功能需求我们就能说这个软件的质量很好了吗?
某天某位业主画了个浓妆,或者剪了个刘海,该系统无法识别了,功能无法满足了。你会发现,通常显性需求和隐性需求是
交织在一起的,很多隐性需求是为了辅助显性需求的更好实现。软件质量一定是需要去界定质量特性,及满足这些特性应该
具备哪些质量属性

1. 定义

软件质量是指软件明确和隐含定义的需求相一致的程度。

一个产品的所有特性,甚于这些待性可以满足显性或隐性的需求,而软件质量就是实体基于这些特性满足需求的程度

显性需求:需求文档明确定义的需求

隐性需求:需求文档未明确定义,但实际需要的需求

从管理角度对软件质量进行度量,可将影响软件质量的主要因素划分为六个部分特性: 功能性,可靠性,易用性,效率,维护性与可移植性

2. 功能性

在规定条件下使用,软件产品满足明确和隐性需求功能的能力

  • 适合性:产品与指定用户目标提供一组合适的功能

  • 正确性:产品具有所需精确度的正确的结果

  • 互用性:产品与一个或多个规定系统进行交互

  • 依从性:产品依附相关的标准、约定或法规

  • 安全性:产品保护信息和数据的能力,以使未授权的人员或系统不能阅读或修改这些信息数据,但不拒绝授权人员或系统对其的访问

3. 可靠性

在规定条件下使用时,软件产品维持规定的性能级别的能力

  • 成熟性:产品避免因软件发生错误而导致失效

  • 容错性:软件发生故障或违反指定接口的情况下,软件产品维持规定的性能级别

  • 易恢复性:指在失效发生的情况下,软件产品重建规定的性能级别并恢复受直接影响的数据的能力

4. 易用性

在规定条件下使用时,软件产品被理解、学习、使用的能力

  • 易理解性:用户认识软件的结构、功能、导航、逻辑、概念、应用范围、接口等难易程度

  • 易学习性:用户使用软件或某一个产品的容易程度(运行控制、输入、输出)对于易学习性有两个方面的约束

  • 易使用性:用户操作和运行控制产品难易程度,要求人机界面友好、界面设计简单合理

5. 效率

在规定条件下,完成预定的功能,系统需要的计算资源的多少

  • 时间特性:产品执行其功能时,提供适当的响应时间和处理时间以及吞吐率的能力

  • 资源利用性:产品执行其功能时,提供合适的数量和类型的资源的能力

6. 维护性

是指软件产品可被修改的能力,修改可能包括修正,改进或软件适应环境、需求和功能规格说明中的变化

  • 易分析性:产品容易找到出现bug或失效的原因

  • 可修改性:产品修改难度大小

  • 稳定性:产品避免由于软件修改而造成意外结果的能力

  • 可测试性:软件容易测试的程度

7. 可移植性

软件产品从一种环境迁移到另一种环境的能力

  • 适应性:适应不同的硬件配置和软件系统的程度

  • 易安装性:在指定环境中易被安装

  • 易替换性:在环境相同、目的相同的情况下替代另一个指定软件产品的能力

8. 影响软件质量因素

由于软件自身的特点和目前的软件开发模式使得隐藏在软件内部的质量缺陷无法完全根除,因此每一款软件都会存在一些质量问题。

影响软件质量的因素有很多,下面介绍几种比较常见的影响因素:

  • 需求模糊、频繁变更

  • 开发人员技术水平

  • 研发流程不规范

  • 组织架构

总结

所谓高质量的软件,除了满足用户需求之外,对于研发人员来说,它应该也是易于维护与升级的。软件开发时,统一的符合标准的编码规范、清晰合理的代码注释、形成文档的需求分析、软件设计等资料对于软件后期的维护与升级都有很大的帮助,同时这些资料也是软件质量的一个重要体现

5- 什么是软件测试?

在规定的条件下,通过人工或者自动化的方式对系统进行运行检测的过程,是验证系统是否满足客户需求,期望结果与实际结果是否存在差异,通俗地说,就是寻找系统中的缺陷,提高软件质量的过程,也称之为找BUG

这句话可以通过三个维度解释:

软件测试是在规定的条件下进行的

  • 也就是说软件测试不能是什么情况下都可以测试,必须有一个要求,对应到测试中就是我们经常说的前置条件

软件测试是一个过程

  • 不仅仅是一个动作,测试是有一个步骤的,我们把这个测试步骤也叫做为测试流程,实际工作中我们的测试流程:前期需求文档的评审,到中期测试用例的编写及执行,再到后期缺陷单的提交和关闭及测试报告的编写等一系列测试过程,所以他不是一个操作,而是一个过程

验证系统是否满足客户需求

  • 在整个研发过程中,开发是以需求为基础开发的,那么我们要验证系统是否达到客户要求标准,就是验证开发好的系统是否和需求定义是一致的,因为客户的要求是通过系统功能来体现的,只能确定每条需求被正确的实现后才能说明系统达到客户的要求

为什么要做软件测试?

  • 发现被测对象与用户需求之间的差异

  • 发现并解决缺陷,提高用户对软件质量的信心

  • 了解软件的质量状况,对决策提供数据依据

  • 积累经验,预防缺陷出现,降低产品失败风险

6- 软件测试六项原则

软件测试经过几十年的发展,人们提出了很多测试的基本原则用于指导软件测试工作。

制定软件测试的基本原则有助于提高测试工作的效率和质量,能让测试人员以最少的人力物力、时间等尽早发现软件中存在的问题,测试人员应该在测试原则的指导下进行测试工作。下面介绍一下业界公认的六项原则。

1. 无错误廖伦

现在依旧有不少人认为:没有发现错误的测试说明软件产品没有缺陷。

我们要明白测试工作的本质是什么?

测试的本质是证明软件存在缺陷,而不是证明软件没有任何缺陷

测试只能找出应用程序或软件中存在的缺陷,测试是为了辅助开发,降低缺陷存在的可能性而开展的活动,即便对产品或者应用程序进行了多次的、比较彻底的测试都没有发现任何缺陷,也不能证明软件是100%完美的。

2. 穷尽测试是不可能的

由于时间和资源的限制,进行完全(各种输入和输出的全部组合)的测试是不可能的,因为它需要大量的时间。

测试人员可以根据风险和优先级先专注于一些重要的指标,例如:用例设计方法、设置用例的优先级,都是控制测试的工作量。在测试成本、风险和收益之间求得平衡。一般来说,软件开发周期内永远不可能允许测试团队在项目中进行大量有效的组合测试。

测试简单的银行卡6位密码,你可以尝试5位纯数字、6位纯数字、7位纯数字……,但是时间上是不允许把所有的数字组合都考虑进去做详尽
测试,从功能本身出发也算是多余操作;随着系统承载业务多,代码规模也越庞大,算法逻辑复杂度也越高。要让测试完全覆盖是不可能
的。

所以我们就得采取以下策略:

  • 精准测试:改什么测什么

  • 二八原则:优先主要功能模块,只测重点

  • 用例设计方法:设计用例时使用等价类、边界值、因果判断表、正交表等设计方法

3. 尽早介入测试

“早起的虫子被鸟吃”,“早”是我们解决问题的有效方法

我们知道,缺陷的修复成本与其发现时间成反比,也就是bug发现越晚其修复成本越大。

缺陷存在于软件生命周期的各个阶段,因此应该尽早开展测试工作,把软件测试贯穿到软件生命周期的各个阶段中,这样测试人员能够尽早地发现和预防错误,降低错误修复的成本。尽早地开展测试工作有利于帮助测试人员了解软件产品的需求和设计,从而预测测试的难度和风险,制订出完善的计划和方案,提高测试的效率。

4. BUG具有集群性

BUG集群性是指几个模块中发现了大部分的缺陷。也就是说如果一个软件产品发现了100个bug,那么其中80个bug很可能都集中在20%的模块里,缺陷并不是平均分布的。

在开发一个软件的时候,并不是所有模块都很复杂,那么复杂模块出现bug的概率会高一些,所有在测试的时候,需要关注这些高危多发模块。

这一原则要求测试人员把系统划分为不同的功能模块,并设置模块的优先级,确定重点关注的功能模块,次要测试辅助业务的功能模块。

5. 杀虫剂悖论

我们都知道虫子的抗药性原理,即当我们反复使用相同的杀虫剂的时候,会有少量害虫产生免疫而存活下来,使得杀虫剂失去药效。

而在软件测试中,缺陷也是会产生免疫性的。同样的测试用例被反复使用,发现缺陷的能力就会越来越差;测试人员对软件越熟悉越会忽略一些看起来比较小的问题,发现缺陷的能力也越差,这种现象被称为软件测试的“杀虫剂”现象。它主要是由于测试人员没有及时更新测试用例或者是对测试用例和测试对象过于熟悉,形成了思维定式。

这一原则要求测试人员不断对测试用例进行更新和评审

6. 不同测试活动依赖不同测试背景

不同的项目产品都不相同,包含它们的元素、特性、功能需求都不尽相同,所以对不同的项目不能用相同的测试方法,APP和Web的测试点就不尽相同,商城类的产品就要比娱乐类的产品做更多的测试。

总结

软件测试的原则是帮助测试团队有效地利用他们的时间和精力来发现测试项目的隐藏bug的指导方针;
“没有错误”不是我们的追求,在互联网时代,始终快速给用户创造最大的价值才是我们孜孜不倦的追求。

7- 软件测试分类(上)

软件测试按照开发阶段可分为单元测试、集成测试、系统测试、回归测试和验收测试

image

1. 单元测试

单元测试(Unit Testing)是对软件中的最小可测试单元进行检查和验证,主要是测试模块在语法、格式和逻辑上的错误,用来验证这段代码的行为是否与我们期望的一致。

对于单元测试中单元的含义,一般来说,要根据实际情况去判定其具体含义,如C语言中单元指一个函数,Java里单元指一个类,图形化的软件中可以指一个窗口或一个菜单等。总的来说,单元就是人为规定的最小的被测功能模块。

比如我们把汽车比作系统,零部件比作单元模块;汽车厂生产汽车,我们知道汽车都是由部件组装起来的(发动机、轮胎、底盘、车身、
电器设备),我们就可以把组成轮胎的这些小零部件(轮辋、幅盘、轮毂、轴承、螺帽螺丝、气门芯)当做单元,在这些零件生产出来
后,都会有厂家质检人员进行质量合格测试,我们的系统也是一样,对他的最小单元函数编写出来后也要对它进行测试验证

1.1 什么时候开始单元测试?

单元测试应该在编写代码前考虑,在代码编写之后立即进行,每当开发者完成一部分代码时,就应该对其进行测试。

1.2 目的

其目的在于检查每个程序单元能否满足《详细设计说明书》中的模块功能、性能、接口和设计约束等要求,发现各模块内部可能存在的各种错误。

2. 集成测试

集成测试又称组装测试,是组件间的接口与交互测试,在单元测试的基础上,将所有模块按照《概要设计说明书》要求组装成为子系统或系统,验证组装后功能以及模块间接口是否正确的测试工作。

所有的软件项目都不能摆脱系统集成这个阶段。不管采用哪种研发模式,具体的开发工作总得从一个一个的软件单元做起,软件单元只有经过集成才能形成一个整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成,总是会出现一些常见问题,那么我们就得通过集成测试发现并解决这些问题。

2.1 测试项

  • 功能测试:借助工具对被测模块的接口进行测试,依据接口文档查看接口的入参和响应是否正确

  • 非功能测试:对接口的性能或可靠性进行测试,查看接口的性能指标(响应时间、并发用户数、资源利用率、tps等)

2.2 目的

检验软件模块对《概要设计说明书》的符合程度

集成测试的必要性还在于单接口能够单独正常运行,但并不能保证多接口的交互也能正常运行。程序在某些局部反映不出来的问题,有可能在全局上会暴露出来,影响功能的实现。

3. 系统测试

系统测试是为验证和确认系统是否达到其原始需求,而对集成的硬件和软件系统进行的测试。

系统测试在真实或模拟系统运行的环境下,检查完整的程序系统能否与硬件、外设、网络和系统软件、支持平台等正确匹配、连接,并满足用户需求。

3.1 测试项

  • 图形界面:界面布局是否整齐合理;风格、样式、颜色是否协调统一

  • 功能测试:软件系统的功能是否正确,其依据是需求文档,如《需求规格说明书》

  • 性能测试:对系统的性能进行测试,查看系统的各项性能指标

  • 兼容性测试:软件在不同操作系统、浏览器、分辨率、屏幕大小及硬件设备下能否正常运行

  • 易用性测试:界面操作、标题描述是否恰当,操作是否符合人们的常规习惯,提示界面是否符合规范,有没有提供相关的热键

  • 弱网测试:测试软件在2G、4G、5G不同网络下的表现

  • 安全性测试:用来验证系统内部的保护机制,以防止非法侵入

    • 身份验证、授权、配置管理、敏感数据、会话加密、重复提交、篡改参数、SQL的注入、爬虫、Dos攻击。在安全测试中,测试人员扮演试图侵入系统的角色,采用各种办法试图突破防线。因此系统安全设计的准则是要想方设法使侵入系统所需的代价更加昂贵

3.2 目的

验证最终软件系统是否满足用户规定的需求,通过与需求文档做比较,,发现软件与需求定义存在差异的地方

4. 回归测试

回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

  • 确认bug是否正确修改

  • 确认没有引入新的bug

5. 验收测试

验收测试也称为交付测试,是软件产品发布之前所进行的软件测试活动,是测试的最后一个阶段。

验收测试是按照项目任务书或合同、供需双方约定的验收依据文档对整个系统进行的测试与评审,决定产品被接收或拒收。

5.1 正式验收

一般由客户派出代表和开发方的测试小组一起进行测试验收,也可能由用户单独验收,总之方式不限,最终的目的还是让用户满意并接收。

正式验收测试是一项管理严格的过程,它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的用例应该是系统测试中所执行的优先级高的测试用例。不要偏离所选择的测试用例方向,这一点很重要。在很多公司中,正式验收测试是完全自动执行的。

5.2 非正式验收

α测试

α测试是由一个用户在开发环境下进行的测试,也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用,开发者坐在用户旁边,随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试,α 测试的目的是测试软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持),尤其注重产品的界面和特色。

  • 环境可控

  • 参与人员:开发、测试、客户

β测试

β测试是在软件的一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签订了支持产品预发行合同的外部客户,他们要使用该产品,并返回相关错误信息给开发者。

  • 环境不可控

  • 参与人员:测试、客户

总结

在软件开发过程中,测试是一个非常重要的环节。通过测试可以有效地发现程序中的缺陷,并提前解决这些问题,从而保证软件的质量。软件测试经过几十年的发展,已经形成了相对完整的体系,不同领域的测试方法、技术也不尽相同,软件测试可以按照不同的标准进行分类

8- 软件测试分类(中)

软件测试按测试方法可分为白盒测试、灰盒测试、黑盒测试

image

1. 白盒测试

白盒测试是依据被测软件分析程序内部代码逻辑结构,并根据内部结构设计用例,来对内部代码逻辑结构进行测试,可完全不顾程序的整体功能实现情况。

它将被测软件看成一个透明盒子,即清楚了解程序结构和处理过程,以此检查软件内部动作是否按照设计说明的规定正常进行。

常见白盒测试方法

1.1 静态结构分析法

在静态结构分析法中,测试人员通常通过使用测试工具分析程序源代码的系统结构、数据结构、数据接口、内部控制逻辑等内部结构,生成函数调用关系图、模块控制流图、内部文件调用关系图等各种图形、图表,清晰地标识整个软件的组成结构。

1.2 代码检查法

代码检查是指对计算机源代码进行系统地审查,找出并修正在软件开发初期未发现的错误,提升软件质量及开发者的技术。它主要检查代码和流图设计的一致性、代码结构的合理性、代码编写的标准性、可读性、代码的逻辑表达的正确性等方面。包括变量检查、命名和类型审查、程序逻辑审查、程序语法检查和程序结构检查等内容。

1.3 基本路径测试法

白盒测试的测试方法中运用较为广泛的是基本路径测试法。基本路径测试法是在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出基本可执行路径的集合,从而设计测试用例的方法。设计出的测试用例要保证在测试中程序的每个可执行语句至少执行一次

1.4 逻辑覆盖法

逻辑覆盖是以程序内部的逻辑结构为基础来设计测试用例的测试技术,通过对程序内部的逻辑结构的遍历来实现程序的覆盖。它属于白盒测试中动态测试技术之一。从覆盖源程序语句的详尽程度分析,逻辑覆盖包括以下6种覆盖标准:语句覆盖(SC);判定覆盖(DC);条件覆盖(CC);判定-条件覆盖(CDC);条件组合覆盖(MCC);路径覆盖

1.5 符号测试法

符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据,而且包括符号值

2. 灰盒测试

灰盒测试是介于白盒测试与黑盒测试之间的一种测试方法,灰盒测试多用于集成测试阶段,不仅关注输出、输入的正确性,同时也关注程序内部的情况。

灰盒测试不像白盒那样详细、完整,但又比黑盒测试更关注程序的内部逻辑,常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。

灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识和与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率

3. 黑盒测试

黑盒测试是通过测试来检测每个功能是否都能正常使用。

在黑盒测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部结构和内部特性的情况下,对系统进行测试,它只检查程序功能是否按照《需求规格说明书》的描述正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。

黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的。很明显,如果外部特性本身设计有问题或《需求规格说明书》的描述有误,用黑盒测试方法是发现不了的。

一般不需要应用程序代码、内部结构和编程知识的特定知识。 测试人员知道软件应该做什么,但不知道它是如何做的。测试人员提供输入、输出被视为该软件测试方法的一部分。黑盒测试是一种强大的方法,因为它端到端地执行系统。

黑盒测试通常称为功能测试,多用于系统测试阶段,它可以应用于所有级别的软件测试,但主要用于更高的可接受性和系统相关级别。它有时被称为基于规范的测试。

3.1 常见的测试方法

  • 等价类划分法

  • 边界值分析法

  • 正交表分析法

  • 因果判断表

  • 错误推算法

  • 场景法

总结

软件测试作为一个技术岗位,也是有自己圈内的技术划分的,不同的测试方法应用于不同阶段的测试

  • 白盒测试方法应用于单元测试

  • 灰盒测试方法应用于集成测试

  • 黑盒测试方法应用于系统测试、回归测试、验收测试

9- 软件测试分类(下)

软件测试按是否自动分为手工测试和自动化测试

在软件测试行业中,经常争议最大的话题就是:“手动测试和自动化测试的比较”,很多公司或者个人认为自动化测试很厉害,其实不管是自动化测试还是手工测试,它们都是软件测试方法的一种,目的都是为了保障软件质量,不存在哪个厉害的说法。

手工测试和自动化测试两者更像是相辅相成缺一不可的关系,如何去根据这两种测试方法各自的优点和缺点,更高效的完成软件质量保障才是大家需要关注的重点!

1. 手工测试

手工测试是指软件测试的整个活动过程(如评审、用例设计、测试用例执行等)都是由软件测试工程师手工执行来完成,不使用任何测试工具,狭义上是指测试执行由人工完成,这是最基本的测试形式,也是比较原始但是必须的一个步骤。

并且一直以来,人们在执行软件测试相关工作时也主要是以手工测试为主。但是随着现代软件复杂程度的逐渐加深,人们发现使用手工方式来完成软件测试会感到越来越力不从心,同时因为在软件测试中存在着大量的重复性工作,而这种工作是更适合机器而不是人类来完成的。因此,自动化测试成为最佳的解决方案。

任何新应用程序都必须先进行手工测试,然后才能使其测试自动化。手工软件测试需要更多的精力,但对于检查自动化的可行性是必需的。手工测试概念不需要任何测试工具的知识。软件测试基础之一是“不可能实现100%自动化”。这使得手工测试势在必行

2. 自动化测试

自动化测试是使用软件来控制测试执行过程,比较实际结果和预期结果是否一致,设置测试的前置条件和其他测试控制条件并输出测试报告。通常,自动化测试就是将大量的重复性的测试工作交给计算机去完成

那是不是自动化测试就一定好呢?自动化测试就可以更多的去代替手工测试呢?
其实事实并不是如此,在实际的软件测试工作中,自动化测试并不能完全代替手工测试。虽然,自动化测试能解决很多问题,但同时也存在很多问题

3.区别

手工测试 自动化测试
手工执行 借助工具执行
可能会出现人为失误,相对不太可靠 可靠,每次执行相同的操作
初期投入资源少,长远来看,性价比低 初期投入资源多,长远来看,性价比高
可以发现用例设计之外的bug 只能发现用例设计内的bug
如果测试只执行1次、2次,选择手工测试更划算 回归测试或者冒烟测试,自动化测试更快捷
适合所有项目 适合大项目
对需求变化适应性强 要求需求变化少甚至不变
更改维护成本低 更改维护成本高
效率低 效率高
可以做成持续集成 无法持续集成
可以进行界面测试、易用性测试 无法进行界面测试、易用性测试
无法进行性能测试 可以进行性能测试
测试技术要求不高 需要编写代码

总结

手工测试和自动化测试各有利弊,自动化完成不了的,手工测试都能弥补,重复性的操作可以通过自动化测试完成,提高效率,两者有效的结合是测试质量的关键

10- 冒烟测试

第一次听到“冒烟”两个字时,很容易让人理解为“走,抽烟去”,这里当然不是抽烟的意思。

那么在软件测试中,“冒烟测试”是什么意思呢?

1. 冒烟测试

冒烟测试是在软件开发过程中的一种针对一个新编译需要正式测试的软件版本的主要业务功能进行确认验证的手段,进行详细测试之前的预测试

主要目的是快速验证软件主要业务功能是否有缺陷,如果冒烟测试没通过,则不必做进一步的测试

1. 来源

冒烟测试(smoke testing)这一术语来源于硬件行业,最初是从电路板测试得来的。当电路板做好以后,首先会直接做加电测试,如果没有冒烟,则电路板就通过了测试。

有人认为,冒烟测试耗时短,仅用“一袋烟功夫”足够了。

也有人认为,软件中的冒烟测试是形象的类比了电路板基本功能检查。任何电路板焊好后,先通电检查,如果存在严重缺陷,电路可能就会短路,发生“冒烟”现象。

无论何种说法,在软件中,冒烟测试只是这类测试活动的形象化叫法,直接叫版本验证测试(Build Verification Testing)也许更为贴切。

在软件研发中,冒烟测试据说是来源于微软(《微软项目求生法则》),它和微软一直提倡的每日构建(build)有很密切的联系。
冒烟测试是在每日构建(build)后,对系统的基本功能进行简单的测试,这种测试强调对程序的主要功能进行验证测试,而不会
对具体功能进行更深入的测试。

每日构建(build)后的冒烟测试,如果采用自动化的执行方式,时间就非常短,通常是几秒钟,最多是几分钟的时间

2. 用途

2.1 提测之前

验证系统主要业务流程可以正确实现,以保证测试版本能够顺利进行,如果冒烟测试不通过,则不必进行下一步测试

2.2 回归测试

验证新的代码或者更改过的代码不破坏版本业务流程完整性

2.3 验收测试

和客户进行验收测试时,通常会选用冒烟测试用例,对系统进行冒烟测试

3. 意义

3.1 快速检验软件是否达到提测标准

通过冒烟测试,能够快速确认软件是否具备测试准入条件,避免出现正式测试阶段全面开展后才发现阻塞型缺陷等严重影响测试进度浪费人力物力的情况

阻塞型缺陷:严重影响主要业务流程的bug,即出现此类bug时,测试工作无法进行

3.2 帮助测试人员熟悉测试流程

通过冒烟测试,测试人员可以迅速熟悉测试总体流程。

  • 一方面有助于测试人员准确制定测试时间计划,合理安排工作进度;
  • 另一方面也有助于测试人员提前做好相关设备、数据的准备,为正式测试的开展奠定基础

3.3 最经济有效的方法

在原代码改动之后,冒烟测试是确定和修复bug的最经济有效的方法

4. 注意事项

4.1 选择合适的冒烟测试用例

进行冒烟测试之前,需要确定冒烟测试的用例集,冒烟测试用例集要覆盖软件的主要业务功能。通过冒烟测试,可以确保后续的测试流程没有严重阻塞性的缺陷。

由于冒烟测试的时间一般都比较短,冒烟测试的用例不宜太多,一般建议在总用例数的8-15%之间

4.2 测试与开发协调

  • 一是该阶段软件可能存在较多缺陷,特别是阻塞型缺陷,测试工作随时可能陷入停滞状态;

  • 二是该阶段测试人员对软件的流程、功能等熟悉程度较低,难免会出现找不到合适的测试方法,甚至是找不到功能模块的情况,从而延迟测试进度;

  • 三是该阶段的时间在软件生命周期中所占的时间比例较低,冒烟测试具有注重通过性、轻细节的特点,这就需要开发人员实时响应,尽快解决各类问题。

因此,在冒烟测试阶段,测试人员与开发人员的协同工作十分重要

4.3 注重效率

冒烟测试应以效率为先,尽量缩短测试时间,提高测试效率。

冒烟测试要在关注主流程、重点功能的前提下,抓关键缺陷,对于诸如页面不美观、用户体验不佳等缺陷,可在冒烟阶段有选择的予以过滤。

例如:测试系统登录,关注点应针对用户名、密码、校验码的输入及提交完成,对于非法字符的校验、登录框是否美观、错误提示是否准确
等均属于次要关注点,不纳入冒烟测试范围。

4.4 优化测试用例

冒烟测试过程同时也是对测试用例进行评估的一个过程。测试人员要充分利用这一阶段,对前期形成的测试用例进行检验,及时对测试用例进行完善,使测试用例更贴合实际,更具有可执行。冒烟测试的用例应根据版本变化,持续的进行优化和更新

4.5 执行方式

冒烟测试可以手动执行,也可以自动化执行。
稳定的系统适合自动化冒烟测试,集成过程中的系统适合手工冒烟测试。

总结

冒烟测试与正式测试的区别在于二者侧重点不同,冒烟测试关注的是阻塞型缺陷,包括但不限于流程不通、主要功能未实现等,而正式测试则属于全面、细致的测试,需要尽可能的发现全部缺陷并按其严重性进行区分。

11- 了解研发团队

我们都知道,软件只有再被开发出来之后,软件测试人员才能对之进行相应的测试,而一个项目组的开发人员会无缘无故的开发一款软件产品来让测试人员测试吗?当然不会,一定是用户有这方面的需求,然后项目组开发人员才会依据用户需求去开发相应的软件产品,之后才会对产品进行测试工作。那么对一个软件产品或者一项软件工程来说,参与角色通常都有哪些?

一般公司的软件研发团队通常由项目经理领导并负责制定项目计划、分配任务。通常的研发团队分为四组:

  • 产品组

  • 开发组

  • 测试组

  • 运维组

产品组

通常负责产品策划、客户感知、需求提炼、界面设计

产品组通常有产品人员和UI设计人员,UI设计细分所属部门通常是设计部,有的公司将产品部门和设计部门整合在一起,叫产品设计部,或是将设计部下辖于产品部门,所以综合来看UI设计属于产品部门。

  • 产品人员
    核心任务是针对用户需求提出解决方案,做好产品设计。在项目,上线后,组织开发、测试、运营进行上线监控,并在项目稳定运营后移交产品运营。产品经理负责产品需求梳理,产品设计,文案等工作。根据产品需求,完成产品的策划和设计。

  • UI设计人员
    根据产品需求,对产品的整体美术风格、交互设计、界面结构、操作流程等做出设计。负责项目中各种交互界面、图标、LOGO、 按钮等相关元素的设计与制作;能积极与开发沟通,推进界面及交互设计的最终实现。

开发组

业务功能的开发

研发组通常有前端开发人员和后端开发人员

  • 前端开发人员
    负责与产品设计和后端开发人员高效沟通,完成软件产品页面开发;网站的“前端”是与用户直接交互的部分,包括你在浏览网页时接触的所有视觉内容-从字体到颜色,以及下拉菜单和侧边栏。这些视觉内容,都是由浏览器解析、处理、渲染相关HTML、CSS、Java文件后呈现而来。前端开发,就是要创造上面提到的网站面向用户的部分背后的代码,并通过建立框架,构建沉浸性的用户体验。为了实现这个目标,开发需要熟练运用下列语言、框架、工具库。

  • 后端开发
    为了让服务器、应用、数据库能够彼此交互,后端开发人员需要具有用于应用构建的服务器端语言,数据相关工具,版本控制工具,还要熟练使用Linux作为开发和部署环境。后端开发者使用这些工具编写干净、可移植、具有良好文档支持的代码来创建或更新Web应用。但在写代码之前,他们需要与客户沟通,了解其实际需求并转化为技术目标,制定最有效且精简的方案来进行实现。

在一个网站登陆页面,前端只要需要负责静态页面部分,鼠标移入输入框、移出输入框的颜色变化这部分的内容;
但是输入用户名、密码后登录系统的话要连接数据库,这个就需要后台开发做逻辑处理了

一拨人负责管理数据,一拨人负责展示数据。这也就是最简单的前台和后台的划分。那些整天守着服务器捣鼓数
据的,是后台开发。那些整天琢磨如何做出花里胡哨的展示界面的,是前端开发

测试组

软件质量的检验

测试人员通常负责制定测试产品的测试计划,设计并执行测试用例,跟踪产品bug,对产品进行功能,性能,安全等测试。实施高效的测试活动,并对测试结果进行分析,给出专业报告,与其他部门紧密协作。

运维组

系统生产运行的保障

对服务器进行日常维护,确保网络连续正常运行。配合数据分析、开发人员进行相关数据统计、参数配置、系统测试及系统监控;研究运维相关技术,根据系统需求制定运维技术方案。创业型公司运维也会出现被开发人员的情况。

一般情况下根据项目的大小,公司财力和项目的紧急程度,这些人员的数量配置会有些变化。一个小的项目组需要项目经理、UI、开发和测试工程师,在初期每个岗位一个人也可以满足。人员资金有限的情况下项目经理可以由服务端开发工程师或产品经理担任,产品经理负责产品需求梳理,产品设计,文案等工作,UI设计部分如果产品经理不能设计,外包解决,ios和Android开发各一个,服务端工程师负责开发和运维,测试团队成员一起测,这样一个最小的四人团队就组成了。在这里面对产品经理和开发工程师的能力要求都比较高,需要全栈型人才。

总结

不同的企业由于其业务的不同,会设置不同的研发团队,以保证软件产品的实现。在进行研发团队结构人员设计时,应根据企业研发业务的不同,设置相应的研发团队,确保研发的高效性与灵活性。团队的规模和项目的复杂程度会影响需要的角色和人员数量,有些人员可能会兼任多个角色,特别是在小型团队或创业公司中

12- 软件开发模型(上)

软件开发模型是软件生产过程中分析、设计、 研发活动所遵循的框架模式。不同项目团队在不同业务背景下,采用合适的研发模型将会提高软件研发效率,降低研发成本,提高产品质量;清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。

在软件生产过程中,经过多年实践总结,沉淀出目前几种流行的软件研发模型:瀑布模型、快速原型模型、螺旋模型、增量模型、迭代模型、敏捷开发模型

1. 瀑布模型

最早出现的软件开发模型是1970年温斯顿罗伊斯(Winston Royce)提出的瀑布模型。

该模型给出了固定的顺序,将软件生存周期划分为制定计划、需求分析、设计、编码、测试和运维等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,形如瀑布流水,最终得到软件产品。

image

特点

由于瀑布模型要求每个阶段都要自上而下、相互衔接的固定次序,也就造成了以下特点:

  • 当前阶段完成后,您只需要去关注后续阶段

  • 每个阶段完成后,产生大量的文档,极大地增加了工作量

  • 不适合需求经常变化的项目

  • 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,很可能导致最终开发的软件产品不能真正满足用户的需求

  • 早期的错误可能要等到开发后期的测试阶段才能发现,从而增加了开发的时间成本

"线性"是我们最容易掌握并能熟练应用的思想方法。当我们碰到一个复杂的"非线性"问题时,总是千方百计地将其分解或转化为一系列
简单的线性问题,然后逐个解决。一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活
就太累了。当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。例如增量模型实质就是分段的线性模型,
螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子。

2. 快速原型模型

快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。

该模型是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。他的第一步是建造一个快速原型,实现客户与系统的交互,客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

image

特点

  • 该模型适合需求不明确的项目,减少由于软件需求不明确带来的开发风险

  • 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下

  • 使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新

快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型、减少误解、弥补漏洞、适应变化,最终提高软件质量;这种模型适合预先不能确定需求的软件项目。

3. 螺旋模型

1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来;是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

image

螺旋模型沿着螺线进行若干次迭代分,分为四个象限:

  • 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;

  • 风险分析:分析评估所选方案,考虑如何识别和消除风险;

  • 实施工程:实施软件开发和测试;

  • 客户评估:评价开发工作,提出修正建议,制定下一步计划

“螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开。它的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。只需定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品

特点

  • 强调了其他模型所忽视的风险分析和客户评价

  • 保证了项目正确性和可控性

  • 项目建设周期长、时间成本大

  • 适用于需求不明确的项目或者大型复杂的系统,便于风险控制和需求变更

螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。更适合大型的昂贵的系统级的软件应用。

因为该模型强调了其他模型所忽视的风险分析和客户评价,客户始终参与每个阶段的开发,所以保证了项目正确性和可控性,也因此造成了项目建设周期长、时间成本大的缺点,适用于需求不明确的项目或者大型复杂的系统,便于风险控制和需求变更。

13- 软件开发模型(下)

1. 增量模型

增量模型又称为渐增模型,也称为有计划的产品改进模型。它是把待开发的软件系统模块化,将每个模块作为一个增量组件,从而分批次地分析、设计、编码和测试这些增量组件。

运用增量模型的软件开发过程是递增式的过程,相对于瀑布模型而言,采用增量模型进行开发,开发人员不需要一次性地把整个软件产品提交给用户,而是可以分批次进行提交。

image

它就是从一组给定的需求开始,通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求,下一个版本纳入更多的需求,依此类推,直到系统完成。每个中间版本都要执行必需的过程、活动和任务

例如要开发一个产品,产品可分为 A、B、C 三个业务功能,每个功能都需要开发两周的时间。则对于增量方法而言,
可以将三个功能分为三次增量来完成,第一个增量完成A、B功能,第二次增量完成C、D功能。

特点

  • 增量模型的最大特点就是将待开发的软件系统模块化

  • 将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展

  • 以组件为单位进行开发降低了软件开发的风险,一个开发周期内的错误不会影响到整个软件系统

  • 开发顺序灵活,开发人员可以对组件的实现顺序进行优先级排序,先完成需求稳定的核心组件。当组件的优先级发生变化时,还能及时地对实现顺序进行调整

  • 增量模型的缺点是要求待开发的软件系统可以被模块化,如果待开发的软件系统很难被模块化,那么将会给增量开发带来很多麻烦

增量模型是瀑布模型和快速原型模型的综合,它对软件过程的考虑是:

  • 在整体上按照瀑布模型的流程实施项目开发,以方便对项目的管理

  • 但在软件的实际创建中,则将软件系统按功能分解为许多增量构件,并以构件为单位逐个地创建与交付,直到全部增量构件创建完毕,并都被集成到系统之中交付用户使用

增量模型也能够很好的控制前期风险并解决这些风险。

2. 迭代模型

迭代模型(iterative model)是由 IBM 公司提出的一种软件开发方法,该方法包括一系列的增量的步骤或迭代,每个迭代都包括很多的开发活动(计划、需求分析、设计、编码、测试、运维)实现软件的每项功能反复求精的过程,是从模糊到清晰的开发过程,每次迭代是从功能的深度和细化程度来划分的。

image

不要求每一个阶段的任务做的都是最完美的,先将主要功能先搭建起来,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交,然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善,这正符合敏捷开发的递增变化

例如要开发一个产品,产品可分为 A、B、C 三个业务功能,每个功能都需要开发两周的时间,而对于迭代模型来讲我们可
以把产品分为 A1、B1、C1 和 A2、B2、C2 第一次迭代完成 A1、B1、C1 三个基本业务功能但不含复杂的业务逻辑,而
第二次迭代就可以完成 A2、B2、C2 这些边缘/辅助功能再逐渐细化补充完整相关的业务逻辑,最终完善系统

特点

  • 降低了在一个增量上的开支风险

    如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。

  • 降低了产品无法按照既定进度进入市场的风险

    通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。

  • 加快了整个开发工作的进度

    因为开发人员清楚问题的焦点所在,他们的工作会更有效率。

  • 迭代模型适应需求模糊多变的项目

    由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的

迭代模型最适合前期需求不稳定,需求多变的项目;适合大项目、高风险项目,比如是航天飞机的控制系统时,迭代的成本比项目失败的风险成本低得多,用这种方式明显有优势。

迭代模型也能够很好的控制前期风险并解决这些风险。

3. 敏捷开发模型

敏捷开发模型是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发模式

在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

image

相对于“非敏捷”,更强调开发与产品之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。

敏捷开发小组主要的工作思想:以用户需求为核心,以用户为导向,快速开发,快速验证,快速修正的迭代方式,每次迭代交付一些成果

特点

  • 人和交互重于过程和工具

    组织文化必须支持团队人员彼此信任,人少但是精干,开发人员所作决定得到认可,环境设施满足成员间快速沟通的需要

  • 可以工作的软件重于求全而完备的文档

    认为把时间用在编码过程中比书写文档资料更有效,所以一部分创业型公司会省略掉部分文档资料的编写

  • 客户协作重于合同谈判

    强调开发与产品/客户的紧密协作,去掉不必要且繁琐的沟通程序,
    eg:开发和产品/用户面对面的沟通,不必通过文档会议的形式说明业务需求,节省很多时间成本

  • 随时应对需求变化重于循规蹈矩

    因为敏捷模型是一种应对快速变化的需求的软件开发模式,所以要随时应对需求变化,不能按照瀑布模型的线性方式进行各项软件活动

  • 适用于较小的队伍

    最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,因此敏捷方法更适用于较小的研发队伍。

敏捷开发模型相比迭代式开发两者都强调在较短的开发周期提交软件,但是,敏捷开发的周期可能更短,并且更加强调队伍中的高度协作。在公司中,往往减少一些规则制度或者既定程序,就会节省很大一部分时间成本,所以敏捷开发模型有时候被误认为是无计划性和纪律性的方法,实际上更确切的说它是强调适应性而非预见性的方法

总结

  • 在前期需求明确且不变的情况下尽量采用瀑布模型

  • 在客户无信息系统使用经验,需求分析人员技能不足情况下可以要借助快速原型模型

  • 在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代

  • 在需求不稳定情况下尽量采用增量迭代模型

  • 在资金和成本无法一次到位情况下可以采用增量/迭代模型,软件产品分多个版本进行发布

  • 对于编码人员经验较少情况下建议不要采用敏捷开发模型

14- B/S架构和C/S架构

1. B/S架构

Browser/Server(浏览器/服务器)架构

这种架构统一了客户端,让核心的业务处理在服务端完成。你只需要在自己电脑或手机上安装一个浏览器,就可以通过web Server与数据库进行数据交互。

  • WEB浏览器是客户端最主要的应用软件

image

1.1 原理

  • 浏览器:主要是与用户交互的界面,用于接收用户输入的数据和显示处理后用户需要的数据

  • web服务器:表示层和数据库访问层之间的桥梁,实现业务逻辑,具体包含:验证、计算、业务规则等等

  • 数据库服务器:主要是接受客户端请求后独立进行各种运算,与数据库打交道,主要实现对数据的增、删、改、查

1.2 优点

  • 客户端无需安装,有Web浏览器即可

  • 交互性较强:可以直接放在广域网上,通过一定的权限控制实现多客户访问的目的

  • 使用方便:不用安装、升级,无需升级客户端,升级服务器即可。可以随时更新版本,而无需用户重新下载

  • 研发方便

1.3 缺点

  • 性能相对差:客户端处理能力弱;相关协议技术标准

  • 安全性差:明文传输、客户端无加解密功能

2. C/S架构

Client/Server(客户端/服务器)架构

C/S架构是一种软件系统体系架构,也是生活中很常见的。这种架构是将需要处理的业务合理地分配到客户端和服务器端,这样可以大大降低通信成本,但是升级维护相对困难。比如我们手机中安装的微信、qq、王者荣耀等应用程序就是C/S架构

image

2.1 原理

  • 客户端:在客户机系统上结合了界面显示与业务逻辑

  • 服务器:主要是接受客户端请求后独立进行各种运算,与数据库打交道,主要实现对数据的增、删、改、查

2.2 优点:

  • 安全性好:客户端可以提供安全保证和加解密功能

  • 性能高:客户端处理能力强,通信效率高

2.3 缺点:

  • 用户群固定:由于程序需要安装才可使用,因此不适合面向一些不可知的用户

  • 维护成本高:发生一次升级,则所有客户端的程序都需要改变

总结

B/S架构是从C/S架构改进而来,可以说是三层C/S架构,由此可见两者关系不一般。B/S从C/S中脱离而出,后来随着WEB技术的飞速发展以及人们对网络的依赖程度加深,B/S一举成为当今最流行的网络架构。两种架构都在各自岗位上虎虎生威,它们各有千秋,都是非常重要的网络架构。在响应速度,用户界面,数据安全等方面,C/S强于B/S,但是在业务扩展和适用www条件下,B/S明显胜过C/S。可以这么说,B/S的强项就是C/S的弱项,反之亦然。它们各有优缺点,相互无法取代

15- web工作原理

web工作原理

Web工作原理是指互联网上各种网站和应用程序的运作方式和基本原理。随着互联网的发展和普及,Web成为人们获取信息、进行交流和开展业务的重要平台。了解Web工作原理对于开发人员、网络管理员和普通用户都非常重要。

浏览器与服务器之间的交互,由请求(Request)和响应(Response)组成,使用标准的HTTP协议(Hyper Text Transfer Protocol – 超文本传输协议)来进行请求的发送和响应的接收

image

  • 用户在浏览器中输入要访问的web站点地址(URL)

  • 由dns进行域名解析,找到服务器的IP地址,向该地址指向的web服务器发出请求。

  • web服务器根据请求将URL地址转换为页面所在的服务器上的文件全名,查找相应的文件。

  • 若URL指向静态文件,则服务器将文件通过http协议传输给用户浏览器;

  • 若HTML文档中嵌入了ASP,PHP,JSP等程序,则由服务器直接运行后返回给用户;

  • 如果web服务器所运行程序包含对数据库的访问,服务器会将查询指令发送给数据库服务器,对数据库执行查询操作,查询结果由数据库返回给web服务器,再由web服务器将结果返给页面,并以html格式发送给浏览器。

  • 浏览器解释html文档,在客户端屏幕上展示结果

URL

Internet上每一信息资源都有统一的且在网上唯一的地址,该地址就叫URL(Uniform Resource Locator,统一资源定位符),它是统一资源定位符。

协议+IP+端口号+路径+参数

https://www.ydcode.cn/forum/article/queryForumArticleById/id/160
    
默认端口号:http 80   https 443

image
image

总结

Web工作原理是一个复杂而庞大的系统,涉及到多个技术和协议的协同工作。了解Web工作原理可以帮助我们更好地理解和使用互联网,同时也为开发人员提供了指导和参考,以便他们能够开发出更好的Web应用程序和网站

16- 静态页面和动态页面

网页可以分为静态网页、动态网页两种类型

静态页面

静态页面即静态网页,是实际存在的,无需经过服务器的编译,直接加载到客户浏览器上显示出来,使用超文本标记语言编写。

静态页面需要占一定的服务器空间,页面内容固定不变,以 .html 、.htm等文件形式保存的网页可以包含文本、图像、声音、FLASH动画、客户端脚本和ActiveX控件及JAVA小程序等

特点:

  • 静态网页每个网页都有一个固定的URL

  • 静态网页的内容相对稳定,因此容易被搜索引擎检索

  • 不需要编译,所以速度快,节省服务器资源

  • 静态网页的交互性较差,在功能方面有较大的限制

  • 可以跨平台,跨服务器

  • 代码一般不被服务器执行,无法从服务器中获取信息;

  • 若有变化,必须手工编辑,并重新上传到服务器,是一个存储于 Web 服务器的文件。

  • 静态文档的开发在编写的时候确定文档的内容。由于文档内容不会变化,所以对静态文档的每次访问都返回相同结果

动态页面

所谓的动态网页,是指跟静态网页相对的一种网页编程技术。静态网页,随着html代码的生成,页面的内容和显示效果就基本上不会发生变化了——除非你修改页面代码。而动态网页则不然,页面代码虽然没有变,但是显示的内容却是可以随着时间、环境或者数据库操作的结果而发生改变的,网页中的关键内容在服务器端生成的网页能够访问服务器端的数据库,具有交互性。

动态页面使用超文本标记语言+ASP或超文本标记语言+PHP或超文本标记语言+JSP等

注意:不要将动态网页和页面内容是否有动感混为一谈。这里说的动态网页,与网页上的各种动画、滚动字幕等视觉上的动态效果
没有直接关系,动态网页也可以是纯文字内容的,也可以是包含各种动画的内容,这些只是网页具体内容的表现形式

特点:

  • 动态网页一般以数据库技术为基础,可以大大降低网站维护的工作量

  • 采用动态网页技术的网站可以实现更多的功能

  • 动态网页实际上并不是独立存在于服务器上的网页文件,只有当用户请求时服务器才返回一个完整的网页

  • 动态网页中的“?”对搜索引擎检索存在一定的问题,搜索引擎一般不可能从一个网站的数据库中访问全部网页,或者出于技术方面的考虑,搜索之中不去抓取网址中“?”后面的内容,因此采用动态网页的网站在进行搜索引擎推广时需要做一定的技术处理才能适应搜索引擎的要求

总结

静态页面和动态页面最大的区别就是静态页面是不能随时改动的,静态是一次性写好放在服务器上进行浏览的,如果想改动,必须在页面上修改,然后再上传服务器覆盖原来的页面,这样才能更新信息,比较麻烦,使用者不能随时修改。动态页面是可以随时改变内容的,有前后台之分,管理员可以在后台随时更新网站的内容,前台页面的内容也会随之更新,比较简单易学

17- OSI模型

国际标准化组织为了规范协议层次的划分制定了开发系统互联(Open Systems Interconnection)模型,即OSI参考模型,该模型定义了不同计算机互联的标准,是设计和描述计算机网络通信的基本框架。

OSI模型用于定义并理解数据从一台计算机转移到另一台计算机,在最基本的形式中,两台计算机通过网线和连接器相互连接,在网卡的帮助下共享数据,形成一个网络,但是一台计算机基于微软的Windows系统而另一台计算机基于Mac OS系统,那么这两台计算机之间将如何相互通信?

为了完成不同计算机或网络之间的成功通信,国际标准化组织提出了OSI七层模型,该模型(从上到下)包括了应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。

image

1. 物理层

OSI模型的第一层,最终数据的传输通道。物理层顾名思义就是最靠近物理传输设备的一层。物理媒介包括光纤,网线等。改成的主要作用是实现相邻计算机间的比特流传输,尽可能屏蔽掉具体传输介质和物理设备的差异。尽量对上层也就是数据链路层屏蔽掉其不需要考虑的物理介质差异,对其提供统一的比特流传输调用方式。

主要功能:屏蔽物理媒介差异,为数据链路层提供统一的物理比特流传输能力

数据单位:比特

常用协议:Ethernet(以太网)、RS-232(串口)等

实例:光纤、网线、集线器、中继器、调制解调器等。

物理层协议对与基本物理信号传输有关的机械、电气等功能进行描述。若生产相互连接的两个设备的两个厂商都遵循相同物理层规范,则二者必定能被连接在一起,并能接收对方发来的电、光或其他的物理信号,而且能正确地将这些物理信号理解为二进制的0和1序列,将数据转换成可通过物理介质传送的电子信号。

举个例子,早前的电话机,你在北京,你女朋友在上海,你俩打个电话就能通话了。为什么?
因为中间有根电话线。物理层你就可以这么简单的理解和记忆

2. 数据链路层

该层主要负责建立和管理不同计算机节点间的数据链路,并提供差错检测、封装成帧、透明传输的能力。它依赖物理层提供的比特传输能力把数据组织成为有边界的传输单位,称为“帧”;链路层为网络层提供服务,在不可靠的物理介质上提供可靠的传输。

数据链路层又分为两个层:媒体访问控制子层(MAC)和逻辑链路控制子层(LLC)

媒体访问控制子层(MAC)

MAC地址你一定不会陌生。每台计算机都有自己的全网唯一的MAC地址。

如下图你也可以看看自己的MAC地址。MAC子层的主要任务是解决共享型网络中多用户对信道竞争的问题,完成网络介质的访问控制。实现这个功能的是集线器。用集线器组网,检查计算机与计算机之间有没有冲突,避免冲突的协议叫CSMA/CD协议

image

逻辑链路控制子层(LLC)

主要任务是建立和维护网络连接和链路控制。

主要功能:物理地址寻址、数据的成帧、流量控制等

数据单元:帧

常用协议:PPP(点对点协议)、HDLC(高级数据链路控制协议)、Ethernet(以太网)等

实例:网卡、MAC地址、以太网、交换机

3. 网络层

网络层解决如何标识通信各方和数据如何从源到达目的这个问题。

顾名思义就是实现网络互联的关键所在。该层通过IP将大大小小的局域网形成一个互联互通的互联网。在计算机网络中进行通信的两个计算机之间会经过很多个数据链路,也可能还要经过很多通信子网。网络层的任务就是为两台通信的计算机之间选择合适的路由和交换节点,确保数据及时传送。网络层将数据链路层提供的数据帧组成数据包,包中有网络层包头,也就是IP相关信息,以便路由。它的单位称为“包”,“包”需要被进一步封装成链路层的帧然后才能通过物理层发送出去,而在接收方,包在链路层的帧中被解封装出来。

最典型的的网络层协议就是在Internet中使用的IP协议,它使用IP地址唯一地标识Internet中的一台主机,路由设备根据IP包中的目的IP地址将IP包一步步转发至目的主机。

主要功能:通过IP地址,实现网络寻址,即IP寻址,通过路由算法进行最优的网络路由。

数据单元:数据包

常用协议:IP(网际协议)、ICMP(因特网控制消息协议)、IGMP(Internet组管理协议)等

网络路由听起来有些抽象,个人认为该层最重要的能力是IP寻址,也就是在互联网中,通信的两台机器要互相找到对方。
网络路由也就是路由算法,其作用就是在上面的寻址过程中,选择一条最优路线。

4. 传输层

终端到终端的可靠链接,单位为数据段

传输层依赖物理层、数据链路层和网络层,任意一个网络节点都能把任何信息传递到其他任意节点,而传输层在物理层、数据链路层和网络层提供的节点间的通信能力基础上进一步提供了面向应用的服务,它向上层提供屏蔽了传输细节的数据传输服务,将来自高层的数据进行分段并将来自低层的数据重组,对数据传输进行差错恢复和流量控制。通过对每个网络节点的多个进程进行标识,传输层可以实现对网络层的多路复用。

如果你是一个程序员相信你一定知道端口这个东西,上述三层实现了两台机器间的互联互通。但是一台计算机上往往有好多应用程序,端口就是用来区分不同应用程序的方式,每个应用程序都有各自的端口。

很简单的一个道理,QQ用户能给微信用户发送即时消息吗?
不能,为什么?这就是传输层的作用。
传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务。包括处理差错控制和流量控制等。该层向上层应用屏蔽了底层通信
细节。上层应用只需要按照传输层的规范,向传输层提交数据传输任务,其余的事情不需要上层应用关系。我们常见的TCP/IP协议中的
TCP就作用在这一层
主要功能:传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务,并提供差错控制和流量控制等功能。 

数据单元:数据段
但是,当你谈论TCP等具体的协议时又有特殊的叫法,TCP 的数据单元称为数据段(segments)而 UDP 协议的数据单元称为数据报

常用协议:TCP(传输控制协议)、UDP(用户数据报协议)等

5. 会话层

会话层就是负责建立、管理和终止表示层实体之间的通信会话。该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

假如你了解session+cookie机制,相信你就明白了,这种session+cookie的机制就是会话层的实现。

会话层用于建立和管理不同主机的两个进程之间的对话。会话层可以管理对话,可允许对话在两个方向上同时进行,也可以强制对话同时只在一个方向上进行。在后一种情况下,会话层可以提供会话令牌来控制某时刻哪一方可以发生数据。会话层还可以提供同步服务,它可以在数据流中插入同步点,每当因网络出现故障而造成大量数据传输中断时,通过同步点机制可以使两个进程之间的数据传输不需要从头开始,而是从最后一个同步点开始继续传输。

主要功能:管理主机之间的会话进程

常用协议:SSH(安全外壳协议)、RPC(远程过程调用)等

6. 表示层

表示层协议规定对来自应用层的数据如何进行表达,例如采用什么样的文字编码、是否及如何进行压缩、是否及如何加密等。

HTTP请求头/响应头 Content-Type:application/json; charset=utf-8 。
这就是规定双方协商的数据格式: application/json; 和编码格式: charset=utf-8; 

主要功能:数据格式的编码和转换、加密等

常用协议:ASCII码、JPEG(联合图像专家组)等

7. 应用层

应用层是OSI模型中最靠近用户的一层,应用层协议直接面对用户的需求,通过应用程序来完成网络用户的应用需求;

这一层就是将通信模型定制化成一个协议,比如适合于超文本传输的协议HTTP,具备安全性传输的HTTPS,还有一些比如FTP,POP3,SMTP等

例如与发送邮件相关的应用层协议可以规定诸如邮件地址的格式、邮件内容的段落表示、客户与服务器进行交互的命令串等

总结

image

18- TCP/IP协议

TCP/IP(Transmission Control Protocol/Internet Protocol,传输控制协议/网际协议)是指能够在多个不同网络间实现信息传输的协议簇,也叫作网络通讯协议。

TCP/IP协议不仅仅指的是TCP和IP两个协议,而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇,只是因为TCP/IP协议中TCP协议和IP协议最具代表性,所以被称为TCP/IP协议。它是在网络的使用中的最基本的通信协议,TCP/IP传输协议对互联网中各部分进行通信的标准和方法进行了规定。

什么是协议?

为了使数据在网络上从源头到达目的,网络通信的参与方必须遵循相同的规则,这套规则称为协议,它最终体现为在网络上传输的数据包
的格式

image

1. TCP协议

TCP协议(传输控制协议)是为了在不可靠的互联网络上提供了一种端到端的、基于连接的、可靠的通信服务;是一种可靠的协议,在使用TCP发送数据前,需要建立起连接。

工作原理:三次握手、四次挥手

image

建立链接(三次握手)

  • 客户端发送SYN(SEQ=x)报文给服务器端,进入SYN_SEND状态。

  • 服务器端收到 SYN 报文,回应一个SYN(SEQ=y)ACK(ACK=x+1)报文,进入SYN_RECV状态

  • 客户端收到服务器端的 SYN 报文,回应一个ACK(ACK=y+1)报文,进入Established状态

三次握手完成,TCP客户端和服务器端成功地建立连接,可以开始传输数据了

断开链接(四次挥手)

  • 某个应用进程首先调用close,称该端执行“主动关闭”(active close)。该端的TCP于是发送一个FIN分节,表示数据发送完毕

  • 接收到这个FIN的对端执行 “被动关闭”(passive close),这个FIN由TCP确认。

注意:FIN的接收也作为一个文件结束符(end-of-file)传递给接收端应用进程,放在已排队等候该应用进程接收的任何其他数据之后,
因为,FIN的接收意味着接收端应用进程在相应连接上再无额外数据可接收
  • 一段时间后,接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN

  • 接收这个最终FIN的原发送端TCP(即执行主动关闭的那一端)确认这个FIN

特点

  • 面向连接:传输数据前需建立连接,否则不可传输数据

  • 可靠性高:一对一,需三次握手四次挥手

  • 传输速度慢:由于需要建立连接和提供可靠性保证,TCP传输速度较慢

  • 顺序性强:TCP保证数据按照发送的顺序进行传输,接收端可以按照相同顺序重组数据

  • 流量控制:TCP使用滑动窗口机制来控制发送端的数据量,避免接收端缓冲区溢出

应用场景

  • 网页浏览:HTTP协议使用TCP来传输网页内容,保证数据的可靠性和顺序性

  • 文件传输:FTP协议使用TCP来传输文件,确保文件的完整性和正确性

  • 邮件传输:SMTP协议使用TCP来传输电子邮件,保证邮件的可靠传输和顺序接收

  • 远程登录:Telnet和SSH等远程登录协议使用TCP来提供安全的登录通道

  • 数据库访问:MySQL、Oracle等数据库使用TCP来进行数据传输和查询

2. UDP协议

UDP协议(用户数据报协议)是一个简单的面向数据报的传输层协议;提供的是非面向连接的、不可靠的数据流传输。

UDP不提供可靠性,也不提供报文到达确认、排序以及流量控制等功能。它只是把应用程序传给IP层的数据报发送出去,但是并不能保证它们能到达目的地,因此报文可能会丢失、重复以及乱序等。但由于UDP再传输数据报前不用在用户和服务器之间建立连接,且没有超时重发等机制,故而传输速度很快。

特点

  • 无连接:UDP不需要进行连接的建立和维护,数据报独立发送

  • 无可靠性保证:UDP不提供重传和确认机制,数据传输不可靠

  • 传输速度快:由于无需建立连接和提供可靠性保证,UDP传输速度较快

  • 顺序性差:UDP数据报独立发送,接收端无法保证数据按照发送顺序接收

应用场景

  • 实时通信:音频、视频会议以及实时游戏等应用利用UDP的快速传输特性,实现实时交互

  • 流媒体:流媒体传输(如音频和视频的实时播放)通常使用UDP,因为对于丢失少量数据并不敏感,但传输速度至关重要

  • DNS解析:域名系统(DNS)使用UDP进行域名解析请求和响应,以快速获取域名对应的IP地址

  • 广播和多播:UDP支持广播和多播传输,用于向多个主机发送数据,如局域网中的视频流广播

3. IP协议

IP协议是整个TCP/IP协议族的核心,也是构成互联网的基础;IP协议位于TCP/IP模型的网络层IP协议(网际协议)是TCP/IP体系中的网络层协议,设计IP的目的是提高网络的可扩展性。

特点

  • 无连接:IP通信的双方都不长久地维持对方的任何信息。这样的话,上层协议每次发送数据的时候,都必须明确地指定对方的IP地址。

  • 不可靠:IP协议不保证数据报能够准确无误的到达接收端,它只能尽最大努力去传送

  • 无状态:通信双方不同步传输数据的状态信息,也就是IP数据报的发送传输,接收都是相互独立的,没有上下文关系。那么接收端就可能收到重复的,乱序的报文段。这就是所谓的无状态

IP协议根据数据包的目的IP地址来决定如何传输,如果数据包不能直接发送到目标主机,那么IP协议就会为它寻找下一个合适的路由器,并将数据包交付给该路由器来转发。多次重复这一过程,数据包最终到达目标主机,或由于发送失败而被丢弃;所以,IP协议使用跳转的方式确定通信路径。

总结

TCP/IP协议是互联网通信的基础协议,定义了数据在网络中的传输方式和规则。它由TCP和IP等多个协议组成,每个协议层级负责不同的功能。TCP/IP协议通过分层的方式工作,提供可靠的、端到端的数据传输服务。

对于测试工程师来说,了解TCP/IP协议对于理解网络通信、调试网络问题以及优化网络传输等方面非常重要。通过深入了解TCP/IP协议,可以更好地理解前端与后端之间的数据传输过程,并在测试工作中可以更深层次的发现软件中存在的缺陷,提高软件性能和用户体验。

19- HTTP协议

现在的互联网应用前后端是分离的,客户端和服务器端通过接口服务进行通信,其本质就是“http协议+json数据”。学习HTTP协议有助于测试人员定位bug或者提高录制测试脚本的效率,所以本节对http协议进行讲解。

HTTP(Hyper Text Transfer Protocol): 全称 超文本传输协议,是一个简单的请求-响应协议,它详细规定了浏览器和万维网(WWW)服务器之间互相通信的规则,通过因特网传送万维网文档的数据传送协议,是基于应用层的协议。

image

HTTP协议是基于 TCP/IP 通信协议来传递数据的,其中 HTTP1.0、HTTP1.1、HTTP2.0 均为 TCP 实现,HTTP3.0 基于 UDP 实现。现主流使用 HTTP1.1 和 HTTP3.0

1. HTTP请求与响应

当浏览器向服务器发出请求时,它向服务器传递了一个数据块,就是http请求,服务器接受请求后,根据请求返回响应的内容,就是http响应。

image

  • 基于客户端访问的URL进行识别,与服务器进行连接建立;
  • 客户向服务器提出请求;
  • 服务器接受请求,并根据请求返回相应的文件作为应答;
  • 客户与服务器关闭连接

1.1 HTTP请求

image

  • 请求行:请求方式、URL、协议/版本,他们之间使用空格隔开
  • 请求头(header):描述客户端的基本信息,从而把客户端相关的信息告知服务器
  • 请求体(body):提交到服务器的数据

常用的请求方法

根据HTTP标准,HTTP请求可以使用多种请求方法。

HTTP1.0定义了三种请求方法:GET、POST、HEAD方法;HTTP1.1新增了五种请求方法:OPTIONS、PUT、DELETE、TRACE 和 CONNECT 方法。

方 法 描述
GET (查询)发送请求来获得服务器上的资源,请求体中不会包含请求数据,请求数据放在协议头中,明文显示,不安全
POST (新增)向服务器提交数据进行处理请求,数据被包含在请求体中。例如提交表单或者上传文件
PUT (修改)向服务器提交资源,并使用提交的新资源,替换掉服务器对应的旧资源
DELETE (删除)请求服务器删除指定的资源,通常用于删除文件、删除数据等场景
HEAD 类似于GET请求,只不过返回的响应中没有具体的内容,用于资源的头部信息;通常用于检查资源是否存在、获取资源的元数据等场景。HEAD请求的特点是只返回响应头部信息,不返回响应体,可以减少网络流量和服务器负载
CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
OPTIONS 用于向服务器请求获取某个资源所支持的HTTP请求方式,通常用于Web API的开发和调试。OPTIONS请求的特点是只返回支持的请求方式,不返回响应体,可以帮助开发者了解Web API的使用方法
TRACE 回显服务器收到的请求,主要用于测试或诊断

1.2 HTTP响应

image

  • 状态行:HTTP协议版本、状态码和状态码,他们之间使用空格隔开
  • 响应头:描述服务器的基本信息。响应头部由多行 键/值对 组成,每行的键和值之间用英文的冒号分隔
  • 响应体:响应体中存放的,是服务器响应给客户端的资源内容

响应的状态码

常见的响应状态码

  • 1**:信息错误,服务器收到请求,需要请求者继续执行操作(实际开发中很少遇到1**类型的状态码)
  • 2**:成功,请求被成功执行并处理
  • 3**:重定向,需要进一步操作以完成请求
  • 4**:客户端错误,请求包含语法错误,接口路径不对
  • 5**:服务器错误,服务器在处理请求的过程中发生了错误
状态码 说明
100 服务器仅接收到部分请求,但是一旦服务器并没有拒绝该请求,客户端应该继续发送其余的请求
200 请求成功
204 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档
304 当测试实体自上次检索以来是否被修改时,出现此结果
400 客户端请求的语法错误,服务器无法理解
401 请求要求用户的身份认证
403 服务器理解请求客户端的请求,但是拒绝执行此请求
404 服务器无法根据客户端的请求找到资源
500 服务器内部错误,无法完成请求
501 服务器不支持请求的功能,无法完成请求
503 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中

1.3 特点

  • 基于客户/服务器模式
    在WWW中,“客户”与“服务器”是一个相对的概念,只存在于一个特定的连接期间,即在某个连接中的客户在另一个连接中可能作为服务器

  • 无连接
    客户与服务器之间的HTTP连接是一种一次性连接,它限制每次连接只处理一个请求,当服务器返回本次请求的应答后便立即关闭连接,下次请求再重新建立连接。这种一次性连接主要考虑到WWW服务器面向的是Internet中成千上万个用户,且只能提供有限个连接,故服务器不会让一个连接处于等待状态,及时地释放连接可以大大提高服务器的执行效率

  • 无状态
    即服务器不保留与客户交易时的任何状态。这就大大减轻了服务器记忆负担,从而保持较快的响应速度,因此每个请求都是独立的(需要cookie和session、token等对客户端浏览器做标识)

  • 灵活
    HTTP允许传输任意类型的数据对象。正在传输的数据类型由Content-Type加以标记

20- WEB核心技术

1. 客户端技术

Web客户端的主要作用就是用来发送HTTP请求并接收服务器响应、展现信息内容

也就是说,只要能达成这一目的的任何工具或程序,都可作为Web的客户端来对待,而不能仅限于浏览器。比如我们可以使用jmeter模拟客户端来处理HTTP请求和响应。也正因为如此,对Web系统的测试变得不再简单,我们不能单纯只是考虑在标准的网页浏览器中进行测试,还需要考虑到用户完全有可能绕开浏览器界面,而直接使用其它工具或者自己编写程序来完成请求的发送和响应的接收。这对Web系统的安全性提出了挑战,需要我们在设计系统时考虑到这些因素,因为服务器在处理请求时是不管请求的来源是否合法的。

1.1 作用

  1. 发送请求
  2. 接受服务器响应
  3. 把服务器响应的数据渲染成可视化页面

1.2 常用的浏览器

image

  • IE浏览器(Internet explorer)已被Edge替换
  • Safari浏览器
  • Firefox浏览器
  • Opera浏览器
  • Chrome浏览器
  • 360浏览器

2. 服务端技术

2.1 web服务器

Web服务器是可以向发出请求的浏览器提供文档的程序。

一般指网站服务器,是驻留于因特网上某种类型计算机的程序,可以处理浏览器等Web客户端的请求并返回相应响应,也可以放置网站文件,让全世界浏览;可以放置数据文件,让全世界下载。

2.2 作用

  • 监听客户端请求
  • 处理客户端请求

2.3 常用的web服务器:

  • Apache服务器
Apache仍然是世界上用的最多的Web服务器,市场占有率达60%左右;它的优势在开源代码开放,可以运行在几乎所有的Unix、Linux、
Windows系统平台上;缺点在于消耗的内存也比其他的web服务器要高
  • IIS(Internet Information Server)
IIS是一种web服务组件,其中包括Web服务器、FTp服务器、NNTP服务器和SMTP服务器,分别用于网页浏览、文件传输、新闻服务和邮件
发送等方面,它使得在网络上发送信息成为一件很容易的事。但IIS只能运行在Windows平台、Linux/Unix平台上
  • Tomcat服务器
Tomcat是Apache软件基金会的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun
的参与和支持,最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现;

Tomcat服务器是一个免费的开放源代码的Web应用服务器,属于轻量级应用服务器,因为Tomcat 技术先进、性能稳定,而且免费,
因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为比较流行的Web应用服务器,在中小型系统和并发访问用户不是很多
的场合下被普遍使用,是开发和调试JSP程序的首选
  • Nginx服务器
Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,由俄罗斯的程序设计师Igor Sysoev所开发,
最初供俄国大型的入口网站及搜寻引擎Rambler使用;其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页
服务器中表现较好;目前国内使用nginx网站用户有:新浪、网易、 腾讯

2.4 应用服务器

应用服务器是处理复杂系统的业务和数据库的访问

指通过各种协议把商业逻辑曝露给客户端的程序。它提供了访问商业逻辑的途径以供客户端应用程序使用。应用服务器使用此商业逻辑就像调用对象的一个方法一样

常见的应用服务器:

  • IBM WebSphere
WebSphere Application Server 是 一 种功能完善、开放的Web应用程序服务器,是IBM电子商务计划的核心部分,它是基于Java
的应用环境,用于建立、部署和管理 Internet 和 Intranet Web 应用程序。 这一整套产品进行了扩展,以适应 Web 应用程序服
务器的需要,范围从简单到高级直到企业级。

WebSphere 针对以 Web 为中心的开发人员,他们都是在基本 HTTP服务器和 CGI 编程技术上成长起来的。IBM 将提供 WebSphere
产品系列,通过提供综合资源、可重复使用的组件、功能强大并易于使用的工具、以及支持 HTTP 和 IIOP 通信的可伸缩运行时环境,
来帮助这些用户从简单的 Web 应用程序转移到电子商务世界
  • BEA WebLogic
BEA WebLogic Server 是一种多功能、基于标准的web应用服务器,为企业构建自己的应用提供了坚实的基础。各种应用开发、部署
所有关键性的任务,无论是集成各种系统和数据库, 还是提交服务、跨 Internet 协作,起始点都是 BEA WebLogic Server。由于
它具有全面的功能、对开放标准的遵从性、多层架构、支持基于组件的开发,基于 Internet 的企业都选择它来开发、部署最佳的应用。

BEA WebLogic Server 在使应用服务器成为企业应用架构的基础方面继续处于领先地位。BEA WebLogic Server 为构建集成化的企业
级应用提供了稳固的基础,它们以 Internet 的容量和速度,在连网的企业之间共享信息、提交服务,实现协作自动化。
BEA WebLogic Server 的遵从 J2EE 、面向服务的架构,以及丰富的工具集支持,便于实现业务逻辑、数据和表达的分离,提供开发和
部署各种业务驱动应用所必需的底层核心功能

3. 集群环境

集群就是指一组(若干个)相互独立的计算机,利用高速通信网络组成的一个较大的计算机服务系统,每个集群节点(即集群中的每台计算机)都是运行各自服务的独立服务器。这些服务器之间可以彼此通信,协同向用户提供应用程序,系统资源和数据,并以单一系统的模式加以管理。当用户请求集群系统时,集群给用户的感觉就是一个单一独立的服务器,而实际上用户请求的是一组集群服务器。

3.1 作用:

  • 负载均衡
可以把很多客户集中的访问请求负载压力尽可能平均地分摊在计算机集群中处理。客户访问请求负载通常包括应用程序处理负载和网络流量
负载。这样的系统非常适合使用同一组应用程序为大量用户提供服务的模式,每个节点都可以承担一定的访问请求负载压力,并且可以实现
访问请求在各节点之间动态分配,以实现负载均衡

一般是通过一个或多个前端负载均衡器将客户访问请求分发到后端的一组服务器上,从而达到整个系统的高性能和高可用性
  • 故障转移
当一台机器宕机时,另外一台机器接管宕机的机器的IP资源和服务资源,提供服务;常用于不易实现负载均衡的应用,比如负载均衡器,
主数据库,主存储对之间

4. 数据库

数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合

4.1 关系型数据库

存储的格式可以直观地反映实体间的关系。关系型数据库和常见的表格比较相似,关系型数据库中表与表之间是有很多复杂的关联关系的

常见的关系型数据库有Mysql,SqlServer等。在轻量或者小型的应用中,使用不同的关系型数据库对系统的性能影响不大,但是在构建大型应用时,则需要根据应用的业务需求和性能需求,选择合适的关系型数据库

4.2 非关系型数据库(NoSQL)

指的是分布式的、非关系型的、不保证遵循ACID原则的数据存储系统。

简单来说就是一个分布式系统不可能满足可用性、一致性与分区容错性这三个要求,一次性满足两种要求是该系统的上限。

工作完成质量会随着节点的变化而产生波动,当节点过多时,相关工作结果就无法那么准确。这一问题使整个系统的工作效率受到影响,导致整个数据库系统的数据乱码与出错率大大提高,甚至会出现数据节点的内容迁移,产生错误的代码信息。但尽管如此,NoSQL数据库技术还是具有非常明显的应用优势,如数据库结构相对简单,在大数据量下的读写性能好;能满足随时存储自定义数据格式需求,非常适用于大数据处理工作。

NoSQL数据库适合追求速度和可扩展性、业务多变的应用场景。对于非结构化数据的处理更合适.

如文章、评论,这些数据如全文搜索、机器学习通常只用于模糊处理,并不需要像结构化数据一样,进行精确查询,而且这类数据的数据
规模往往是海量的,数据规模的增长往往也是不可能预期的,而NoSQL数据库的扩展能力几乎也是无限的,所以NoSQL数据库可以很好的
满足这一类数据的存储。NoSQL数据库利用key-value可以大量的获取大量的非结构化数据,并且数据的获取效率很高,但用它查询结构
化数据效果就比较差。

4.3 分类

  • 键值对存储(key-value)
    代表软件Redis,它的优点能够进行数据的快速查询,而缺点是需要存储数据之间的关系。

  • 列存储

代表软件Hbase,它的优点是对数据能快速查询,数据存储的扩展性强。而缺点是数据库的功能有局限性。
  • 文档数据库存储
代表软件MongoDB,它的优点是对数据结构要求不特别的严格。而缺点是查询性的性能不好,同时缺少一种统一查询语言。
  • 图形数据库存储
代表软件InfoGrid,它的优点可以方便的利用图结构相关算法进行计算。而缺点是要想得到结果必须进行整个图的计算,
而且遇到不适合的数据模型时,图形数据库很难使用