2.1 软件生命周期概念:

软件生命周期概念(别称软件生存周期、软件开发生命周期):指软件从产生到报废的整个过程,是一种时间的概念。(如一部手机的寿命)

2.2 软件生命周期的阶段:

1、客户问题的引入与分析---从而产生开发产品的想法

---产品经理/客户

2、可行性分析(技术方法能否实现;做这个项目能不能挣钱;有没有涉及侵权、涉及政治,以及是否违法)

---产品经理/需求人员

3、项目招投标:指确定项目的交付周期

---项目经理

4、项目立项:确定交付时间以及交付的量、对周期、人力安排以及测试环境做一个确定,这些项目经理都回去做一些规划

----项目经理             

5、需求分析由产品经理召开一个需求澄清会议,然后由产品经理主讲                                            ---产品经理

6、开发测试阶段:开发编写代码、测试设计测试用例并且执行测试用例

7、部署维护

部署:指软件进行上线或者给客户进行安装部署

维护:软件开发完成后投入使用,由于各方面的原因,软件不能适应客户的需求,需要延续软件的使用寿命,就必须对软件进行维护。

8、升级淘汰阶段:

升级阶段:修复错误(bug)、添加需求等等,编码后测试通过,进行推送升级

淘汰阶段:客户不用了:他又去找开发做了一款满足他需求的软件,意味着一款新的软件诞生,软件的生命周期又开始轮回起来了

2.3 软件生命周期模型:(测试流程)

开发模型:瀑布模型(waterfall)、V模型(重点讲解)、W模型、H模型(重点讲解)、敏捷开发模型(重点讲解)、迭代开发模型、增量开发模型(了解)

---瀑布模型(waterfall)

明确了每一步需要完成的工作内容,但同时也导致每步工作之间关联性很强,上一步没有完成就无法开展下一步工作。

测试模型:V模型、W模型、H模型(重点,要求掌握)

---V模型    

V模型是瀑布模型的变种,把瀑布模型中的测试阶段与之前的分析设计阶段对应起来,得到V模型

需求(简称:srs)全称:软件需求规格说明书

1、用户需求:一个文档,对整个项目的设计、框架、功能、模块的描述

2、概要设计:简称HLD,一个文档,架构的初步设计文档,使用说明什么类型数据库,架构的描述,设计,模块的名称(可理解为:盖房子的大概设计,基本框架结构)

3、详细设计:简称(LLD),一个文档,针对功能具体的实现,模块的具体实现,具体设计,架构的具体描述,(可理解为:房子的具体的装饰设计)

v模型的四个阶段:

(1)单元测试

单元测试:指验证软件单元是否满足详细设计文档的规格,能正确的执行,主要是对代码的测试。单元测试也是最小的测试单位。
在工作中单元测试一般情况是开发自测,如果需要测试进行单元测试,对测试的技术要求非常高,必须要懂开发语言;

(2)集成测试

集成测试是指多个单元组合验证软件是否满足概要设计文档的规格,能正常执行,主要是模块与模块之间的数据交互。

(3)系统测试

系统测试是指把软件进行正常运行,对整个软件系统进行测试,验证这个系统能正常的运行,主要是测试一个整体业务的流程。

(4)验收测试

验收测试是指:站在用户角度去对软件进行测试,验证系统满足用户需求;

验收测试测试分为两种:alpha测试(α)   和 bete测试(β)

α测试是内部测试
β测试是客户方测试

α测试和β测试区别:

1、α测试测试地点:是在自己公司    ;β测试一般在客户方

2、α测试都是内部人员进行测试,开发在现场及时发现问题,及时解决;β测试是在客户方的员工测试,发现问题同意反馈非开发在解决

3、α测试测试时间段,技术人员比较集中;β测试测试时间较长,测试人员不集中

备注:

(1)集成测试(it)和系统测试(st)  合并成(sit测试)

(2)sit测试(系统集成测试), 技术测试 ;uat测试(验收测试)

(3)sit环境 (sit1环境,sit2环境,sit3环境);uat环境(专门用来验收环境)

(4)环境:

a.线上环境(也叫生成环境):客户在实现

b.测试环境:测试人员使用

c、开发环境:开发人员使用

V模型优点:

1、非常明确的标明了测试过程中存在的不同级别,并且每个级别与分析设计阶段对应,这个测试他不是用同一种方法进行测试,他是每个不同阶段都有一个不同的方法

2、每个测试阶段有明确的交付物

V模型局限性:不够灵活,测试阶段介入晚

如果用户的需求在提出时就有问题,或者是在设计阶段就有,是发现不了,直到开发编码完成把这个东西做出来后开始单元测试,才能发现,甚至更后面才能发现问题,越往后发现我们需要返工的东西就会越多,从而成本也会越大。问题发现的晚,修复的质量产品的质量也会降低.

---W模型  

---敏捷开发模型 (重点)

敏捷开发模型是一个新型模型适应快速需求变化,交付周期比较短,轻量级的开发模式。

时间:一周,两周,一个月

产品拿到一个需求,开发一周,测试编写用例,第二周测试区测试,开发修改,修改好就上线

---迭代开发模型

项目被分为一系列的增量,每一个增量都交付整个项目需求中的一部分功能,需求按优先级进行划分增量的交付。

如:买家版,卖家版, 商家版,  ,先左买家版,

---增量开发模型  

项目被分为一系列的增量,每一个增量都交付整个项目需求中的一部分功能,需求按优先级进行划分增量的交付。

如:买家版,卖家版,商家版,先左买家版,            

---H模型

(1)需求澄清会议(产品经理会组织需求会议)

(2)拿到需求,深入分析和了解需求文档

(3)测试经理编写测试计划 (重点)

测试计划:(内容:测试目的,背景,范围,测试准入,测试准出,环境和资源,测试任务和测试进度,风险及风险管理,测试交付文档)

准入:

开发:需求分析报告,需求规格说明书,概要设计说明书,详细设计说明书,版本说明书及开发自测报告;

测试:测试计划,测试用例通过,测试环境搭建好

准出:

a.用例100%执行

b.0bug

c.输出测试报告

(4)编写用例

(5)评审用例(测试人员:组内评审(开发,测试,产品都参加),交叉评审(测试人员之间评审))

(6)用例评审通过以后导入到用例管理工具中禅道.

(7)搭建测试环境(运维搭建,自己搭建)

(8)开发提交代码包,提测(也叫转测)

(9)测试将代码包部署到环境,

(10)进行冒烟测试,冒烟测试通过,进入sit测试,如果,冒烟测试不通过,就把版本打回非开发,开发修改,在提测。

冒烟测试(也叫版本验证测试)定义:指对新本本的主要功能,基本功能进行测试。

如果通过,那么冒烟测试通过,如果冒烟测试失败,那么就把版本打回给开发进行修改,直到冒烟测试通过

(11)sit系统集成测试(一般一个项目有3次系统集成测试,有些项目周期长也有4次,5次)

(12)第一次sit测试也叫全量测试(把前面写的所有用例都要进行测试),测试出来的bug,指派给开发(通过禅道),测试小结

  

(13)开发修改bug,在提交

(14)第二次sit测试,第二sit测试测试前要冒烟测试,冒烟测试通过以后才能进行第二次sit测试;

第二sit测试和第三sit测试都叫做回归测试

回归测试:是系统维护阶段进行的验证测试

区别:测试阶段不同

冒烟测试是版本提交时第一个测试,回归测试是在维护阶段测试

(14)第二次sit测试,在将bug提交给开发,开发修改,

(15)第三sit测试,先冒烟测试,在去测试,验证。。。。。。以此类推

 备注:测试用例的来源:

a、冒烟测试用例

b、验证上一个版本提交bug的用例

c、测试和bug有关联的模块用来

d、你认为可疑的测试场景和测试用例

e、测试补充的测试用例和测试场景

(16)直到用例100%执行,0bug,

(17)输出测试报告=========================说明sit测试测完

测试报告:

内容:测试目的,测试范围,测试背景,测试实施日期,测试人员,bug 清单,用例清单,测试结果,

(18)sit测完通知 uat 测试,uat验收通过,

(19)封板(封装版本)

(20)等待上线

(21)上线前准备线上数据

(22)上线后在线上测试,

(23)测试没有bug,如有bug就要分析bug,bug影响程度,影响大,就回退版本,如果影响小就备注下次版本修改

(24)上线成功

—————————————————————————————

H模型(重点,要求掌握)

目前软件行业市场,主要都是以H模型的流程,进行软件开发工作

 

H模型我们可以理解为项目流程

什么项目?什么是产品?什么是版本?什么是迭代?

比如说,现在市面上没有一款正儿八经的社交软件,那我们就来做一款设计软件,我们先要组建一个项目,立项的名称“设计软件项目”,接下来做一款“微信”的社交产品,微信版本定为微信1.0,开发出来让大家去使用,用户多了,去使用后肯定会有体验不佳,或者是功能有些地方不能满足他的一个使用需求,所以产品需要不断的去迎合市场,要不断的去满足用户需求,所以我们要进行迭代更新,新加一些功能,或者优化一些功能,然后进行一次一次的发版更新推送

 

项目和产品的区别?先有项目再有产品

项目和版本的区别?一个项目中 项目只有一个,版本可以有多个

 

H模型特点:

1、H模型开发、测试活完全独立,各自形成一个独立的流程,并且与其它流程并发进行

2、H模型贯穿与产品的周期

3、软件测试可以尽早的进行,也可以根据被测物的不同而分层次进行

测试准备阶段

 

需求下来了后,项目经理就会把需求文档分给开发经理、测试经理,然后把需求文档分给对应的开发、测试,分下来干嘛? 分下来去看 在看的过程 我们每个人的理解想法意见不一样,所以要开一个需求澄清会议(产品经理召开,产品经理主讲),大家把各自的意见、想法、建议都抛出来进行讨论,经过多次讨论后,大家都认可了,想法也一致了,然后最终就会输入一个基线化文档:

SRS:需求规格说明书

基线化文档:表示这个文档已经确认了,稳定了,没有特殊情况不会进行修改了,同时它也是进入下一个环节的基础

SRS澄清后

开发这边:

1、编写概要设计说明书(HLD):就是这个需求需要哪些功能或者是需求分为哪些模块列出一个大纲

2、编写 详细设计说明书(LLD):就是对概要设计说明书列出的功能或模块进行详细设计

3、coding(编码实现)

 

测试这边

1、评审概要设计说明书(review HLD)

2、继续了解SRS

 

1、评审详细设计说明书(review LLD)

2、深入了解SRS

 

为什么测试人员可以评审开发人员编写的HLD和LLD?

因为开发和测试看的是同一份需求文档,开发要实现的功能,测试人员也是清楚的,所以测试人员也可以评审(但是实际工作中一般没有这个步骤)

 

如果我们对需求不够了解,在设计测试用例的时候可能就会出现覆盖不全,可能导致漏测,漏测在测试工作中属于比较严重的问题,所以得特别注意

 

3、TPM(测试经理)

输出一个测试计划/测试方案(一般由测试经理编写)

 

1、TE输出TC初稿,并进行多次用例评审,最终形成用例基线文档

TE(软件测试工程师)

TC(测试用例)

多次用例评审,有哪几种用例评审方式?

1.交叉评审:测试团体成员之间进行评审

2、团队评审:产品经理、开发、测试、运维一起评审

3、会议评审:有客户参加

 

2、TPM(测试经理)将基线用例输入到testlink(用例管理工具)并将TC(测试用例)分配给TE(测试)谁写的谁测

 

3、TPM或测试骨干或者是环境运维人员搭建测试环境

公司里的环境有哪几种?

3.1 开发环境:开发人员使用的一个环境

3.2 测试环境:测试人员使用的一个环境

3.3 正式环境/生产环境:正式对外提供服务,客户正式使用的环境

 

测试就绪点

 

测试环境搭建好了,开发编码也完成了,开发负责人会讲开发的代码打成一个war包,交由测试经理或者是运维人员去部署到测试环境的linux服务器上,部署完成后启动服务器,就可以通过浏览器访问网页,测试工作就可以开始了

 

测试执行阶段

什么是冒烟测试?

确认软件的基本功能是否正常,需求的主流程是否正常,是否可以进行后续的测试工作,如果冒烟测试不通过,就暂时先不进行正式的测试工作,把这个冒烟不通过的这个需求打回给开发,让他去修复,什么时候冒烟能通过,什么时候进行正式测试工作(只针对当前需求)

 

确认基本功能是否正常,基本功能是什么?

比如支付宝基本功能-支付

微信基本功能-社交、聊天

淘宝基本功能-购物

 

开发完成需求后需要进行自测(冒烟测试),自测通过提测

 

冒烟测试通过后正式执行SIT

SIT(系统集成测试/全量测试)全量测试什么意思?

就是把所有的用例都进行执行一遍,比如我们写了1000用例,就要把这1000条用例全部执行完

 

第一轮SIT1,全量测试,执行所有用例

第二轮SIT2,我们称之为增量测试/回归测试

增量测试:我们在测试过程中,测试某个功能点,就发现按照原理的用例来测试覆盖的不是很全,所以要在原先的用例上再加上几条用例,把这个需求测试点给覆盖完全

回归测试:开发在修复bug可能会对其它代码造成影响,然而出现新的问题,如果不去进行回归测试,这些问题就发现不了

回归测试要测什么?

一般情况下测试这些内容就可以了

1、新增这些用例

2、执行上一轮发现bug的这些用例

3、执行与上一轮bug所属模块的用例以及有关联的模块的用例

4、再进行一轮冒烟测试

第三轮SIT3,回归测试

。。。。。。

SIT4 0/1:上线的硬性要求

0是bug清零 1的话指的是允许一个易用性或者是建议性的bug。易用性或者是建议性的bug,它不会影响功能使用,和产品开发沟通后,可以建个优化需求建议需求放到下一个迭代版本去优化,必须要发邮件通知测试经理和抄送给项目组的相关成员,让大家都知道这件事

 

用例执行100%,软件需求分析均已实现

测试准出报告

 

达到上线要求了后,测试就可以结束这个版本的测试,输入一个测试报告给项目经理、抄送给测试经理、产品经理和项目组所有相关的成员.

 

2.4 测试流程

1、首先是用户需求

2、用户提出需求后,接下来会对需求进行一个分析,这时产品经理会召开一个需求澄清会议,把需求人员(产品经理、开发、测试、运维)拉过来,由产品经理主讲,一起把需求讲清楚,经过多次的分析,多次的讨论,最终会输入一个基线化文档——需求规格说明书文档,英文简称:SRS(这个文档是确定了,稳定了,一般没有特殊情况不会再进行修改了)

3、概要设计

4、详细设计

5、编码实现:开发编写代码实现需求

测试的基本原则:

1、测试是从用户的角度去测试;(用户故事测试)

2、测试不仅测试是软件本身,测试环境,配置,网络等

3、软件外在可用,不代表软件没有问题

4、软件测试是没有完成正确,只有更加完美

5、测试是永远测不远

6、测试应尽早介入,

7、2/8原则, (80%的错误集中在20%的区域)

8、杀虫剂效应

9、测试尽量选择第三方测试

10、测试活动的依赖对象(功能测试,性能测试,安全测试等)

测试活动的周期

测试计划(安排任务)-------测试分析和设计(编写用例)-----测试实现执行(测试阶段)---输出测试报告----  资产归档(测试文档)

准入(也叫转测,也叫提测):

开发:详细设计,概要设计,开发自测报告,

测试:测试计划,测试用例,测试用例审核通过,搭建好环境

准出:0bug  ,用例100%执行,输出测试报告

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/ZHH-CY/p/16546699.html

你还没有登录,请先登录注册
  • 还没有人评论,欢迎说说您的想法!