软件生命周期与常用测试模型

软件生命周期

指的是软件从产生到报废的整个过程，是一种时间概念。别称：软件生存周期或软件开发生命周期。

*通常软件生命周期包含哪些阶段

1.客户问题引入或定义（需求）-->产品经理

2.可行性分析（涉及经济、商业论证、政治法律、技术等） -->产品经理、项目经理、开发经理、测试经理、架构师、技术大佬

2.1成本（人天）

2.2商业/法律问题

2.3政治风险

2.4技术难关，根据现有技术能力是否能解决实现项目功能

3.项目招投标 -->看谁要的钱少，相关资质，交付时间周期

4.项目立项

4.1成立项目组

4.2人力安排、时间安排

5.需求分析-->产品经理收集客户需求，输出需求文档进行需求分析

5.1参与人员：所有参与项目的人员

5.2需求分析由谁主导：产品经理

6.开发阶段（设计、编码、测试）

6.1UI设计师：输出效果图

6.2开发工程师：进行编写代码

6.3测试：对项目软件进行测试

6.4交付客户验收

7.维护

典型的软件生命周期模型有哪些?

1.瀑布开发模型（已经很少使用）

2.*V模型

2.1.需求分析：产品经理整理需求并召开需求澄清会议（需求评审），经过多轮沟通形成一个基线化文档，叫需求规格说明书，简称SRS

基线化文档代表各方对该文档达成一致，可进入下一个状态。

2.2.概要设计：简称HLD，项目分为模块A、模块B、模块C ；-->开发人员输出

2.3详细设计：简称LLD，针对每个模块中的具体功能点怎么实现； -->开发人员输出

2.4.编码和实现：开发人员编写代码（代码打包成压缩文件 .war/.jar）

2.5单元测试：简称UT，又称白盒测试（直接看代码逻辑与代码内部结构-->对代码进行测试）--由开发人员完成自测，输出单元测试报告

2.6集成测试：简称IT，模块A、模块B、模块C单独测试没有问题，放在一起测试。又称灰盒测试，也叫接口测试（api）

2.7系统测试：简称ST，又称黑盒测试，也叫功能测试，除了保证当前软件功能的正常使用，还要保证与第三方系统对接不会出现问题。

ST和IT合并称为SIT，即系统集成测试。

2.8验收测试：简称UAT

α（阿尔法测试）：公司内部开发和测试人员模拟用户行为操作，对此时发现的bug进行修复。

β（贝塔测试）：产品已经交付客户手中，此时出现bug，客户进行收集，发送邮件到项目组验证进行修复。

2.9上线/发布

项目经历了哪些阶段？每个阶段的输入与输出是什么？

	输入	输出
需求分析	用户需求	需求规格说明书
概要设计	需求规格说明书	概要设计文档
详细设计	概要设计文档	详细设计文档
编码阶段	详细设计文档	代码包（.war/.jar）
单元测试	开发部署环境	单元测试报告
系统集成测试	单元测试报告	系统集成测试报告
验收测试	系统集成测试报告	验收测试报告

3.W模型（双V模型）file:///C:\Users\ADMINI~1\AppData\Local\Temp\ksohtml8800\wps1.png

4.*H模型

SSR澄清：需求评审，得到需求规格说明书

review：评审，测试人员要参与

TPM：测试经理编写测试计划（规定的测试范围，人力的安排、软件与硬件的资源、测试进度、风险评估）

风险评估：

1.新人参与测试

2.项目需求延期提测（开发原因）

项目组常用的评审方式有哪些？-->（用例评审、谁写的谁讲）

交叉评审：测试组同事之间进行评审

组内评审：项目组开发、测试、ui设计师、产品经理进行评审

会议评审：项目组开发、测试、ui设计师、产品经理进行评审、有客户参与；

testlink：是一款用例管理工具

TPM、测试骨干或运维搭建测试环境

公司有哪些环境？

开发环境：开发人员编写代码

测试环境：测试人员测试当前项目软件使用

预发布环境：模拟用户的使用场景，产品经理验收使用

生产环境：线上环境、正式环境

环境搭建好之后，开发人员将开发的功能代码打包，交由TPM或运维人员进行部署到测试环境；

部署完成之后重启服务器，就可以通过浏览器访问网页，项目部署都是liunx服务器上；

冒烟测试-->在sit1系统集成测试前进行，在测试用例中选取而三十条作为冒烟用例

定义：对主体功能进行测试

例如：

qq登录功能的主体功能是什么？登录成功

qq注册功能的主体功能是什么？成功注册账号

冒烟测试不通过-->版本打回，开发人员重新编码修复，修改完成之后再次打包部署，部署完之后再次进行冒烟测试，直到冒烟测试通过为止。

系统集成测试：

sit1：又称全量测试，需要测试所有编写的测试用例，全部执行完。

sit2：称为回归测试

sit3：称为回归测试

回归测试测试哪些内容?

1.测上一轮发现bug的用例

2.测试与上一轮发现bug的相关模块的用例

3.执行冒烟用例

4.测试新增的用例

上线硬性标准

0bug；

H模型中允许带有一两个易用性bug上线，易用性bug不会影响功能使用；

当前版本发现易用性bug，如果需要留到下一个版本中解决，需要做好相关的记录并且发送邮件告知项目组成员。

例：微信

项目与产品：先有项目然后才有产品

项目与版本：一个项目有多个版本

项目上线：产品经理会提前邮件通知相关人员具体上线时间点

测试人员配合上线前、上线中及上线后的工作：

上线前：测试人员应做随机测试或交叉测试

上线中：整理当前版本的相关文档记录进行归档

上线后：要在正式环境中进行测试（所有的测试都是按用户的操作进行验证）

敏捷开发模型

周期短：1-2周左右一个版本

轻量级：每个版本的任务量不会太多

晨会：15分钟左右

1.对前一天工作的总结

2.对当天工作任务进度安排

3.是否存在延期风险

增量开发模型：一个项目被划分为多个增量，按照优先级增量交付部分功能

迭代开发模型：将一个复杂且周期长的项目划分为多个独立的功能模块，且分为多个版本开发上线。

例：微信项目：聊天列表、通讯录、收藏、零钱、扫码支付、小程序

第一个版本：聊天、通讯录

第二个版本：收藏

第三个版本：零钱、扫码支付

第四个版本：小程序

测试的基本准则：

1.测试不仅仅是单纯的软件本身的测试

1.1了解功能背景目的

1.2软件是否受其他外界因素影响：弱网、断网

2.测试应尽早介入

2.1需求分析评审，对需求理解更透彻，为后面输出测试用例和测试工作打下基础；

2.2确保开发、测试、产品对需求的理解是一致的，规避后面功能开发出现错误；

2.3尽最大可能降低项目的延期风险

3.二八原则/二八定律：80%的错误出现在20%的模块

测试活动生命周期？

1.测试计划

2.测试用例编写输出

3.测试实现与执行（冒烟测试、sit）

4.输出测试报告，达到准出标准，进行验收测试

5.版本文档归档