第二讲 软件生命周期

一、为什么要测试？
1.软件的非正常运行或其自身的缺陷（BUG）会引发很多问题。
比如12306 我们春节买票的时候，软件很卡，登录不了，为什么会这样
很多人在同一时间作同一件事情，导致服务器处理不过来，性能问题

2.软件是由代码和文档组成的，而这些都是由 “人” 来设计和编写的，
人都有可能犯错。
需求文档市由产品经理输出的，需求文档可能存在错别字  逻辑不清楚 所以
要测试，
代码==》开发编写==》存在代码问题

3.环境也会影响软件，以致出现软件“失效”现 象。
可移植性测试 ==>在不同的区域是否正常

4. 软件测试活动只是关键的质量保证活动之一
测试只是团队中的一份子，需要大家共同维护，产品经理需求要清楚，开发需要自测
代码需要审核

二、什么市测试
1、制造业的定义： “以检验产品是否满足需求为目标”
客户需要做一个白色的盒子，需要检验盒子的颜色 大小==》测试

2、软件测定义
a:验证软件的正确性；
b:发现软件中的缺陷==》专业==》找出软件中的bug

3、“发现软件中的缺陷”的3种观点：
1.测试是为了证明程序有错 【对】
测试人员存在的价值就是证明软件有问题

2.一个好的测试用例：在于它能发现以前未发现的错误 【对】
测试用例是根据需求文档==》测试点==》测试用例
刚开始没经验写不好是正常的==》慢慢的去积累经验

3.一个成功的测试：能发现前所未有的错误的测【对】
在领导眼里只要上线没有问题，那就是成功的测试


三、软件生命周期
1、概念：指的是软件从产生到报废的整个过程，是一种 时间的概念

四、通常软件生命周期包括哪些阶段？
1)客户问题引入或定义
客户提出一个需求，客户提出的需求比较粗糙，需要产品经理沟通清楚
本身客户提出的需求很多时候会存在问题

2)可行性分析（涉及经济（商业论证），政治， 法律，技术等）
需要做电商平台 ==》违法 挣不挣钱  是否技术支持

3)项目招投标
要确定交付周期（6个月）和交定金30%

4)项目立项
成立项目组xxx项目组 讨论前三个月需要完成什么，后三个月完成什么，资源（人力 配置）

5)需求分析（测试从这里开始介入项目）
产品经理对接客户，拿到客户的需求进行分析，提炼出来==》转化为项目需求==》
产品经理主讲（需求评审）==》需求规格说明书

6)开发测试阶段（设计，编码，测试）
开发：编写文档和编写代码
测试：了解需求，编写测试点，编写测试用例，有问题提问题（提给开发）

7)维护
运维系统，交30%的定金，完成交付后交60%，10%帮忙维护一年


五、软件生命周期模型
1、瀑布模型：软件周期长，可能错过商机

2、V 模型：项目的阶段【重要】

用户需求：客户提出的要求，客户提出的需求比较笼统，不清晰

需求分析：产品经理根据客户的需求提炼出项目需求，组织it团队开一个评审会议
由产品经理主讲，测试  开发会提出自己的观点，经过多次讨论==》需求规格说明书（SRS）

概要设计：简称HLD  比如我们搭建房子，首先搭建一个框架，框架里面是什么还不知道
软件定义：好比我们的微信，微信 通讯录 发现 我 ==》模块1  模块2 模块3 模块4

详细设计：简称LLD 就是根据每个模块具体有哪些功能，怎么去实现，模块1需要实现
聊天 发红包  转账 语音 视频等等

编写和实现 coding ：开发人员根据上面的文档编写代码

单元测试：（unit test）白盒测试：可以把它当作一个白色的盒子，通过盒子可以看到
里面的内部逻辑和内部结构==》可以看到代码逻辑==》代码测试==》一般开发完成（自测）
把每一个模块测试好了
【面试题：白盒测试中那个方法最弱，那个方法最强？语句覆盖最弱，路径覆盖最强】

集成测试：简称 IT（integration test）把模块1 模块2 模块3 模块4测试没问题，需要串联
起来进行测试==》集成测试==》灰盒测试==》接口测试【测试负责】

系统测试: 简称 ST（system test）保证整个系统没有问题以及第三个对接也没有问题
第三方测试：比如 淘宝支持支付宝登录 ==》黑盒测试或者功能测试【测试负责】

集成测试和系统测试合并sit测试==》系统集成测试

UAT 测试：验收测试（测试环境 验收环境）

1）α 阿尔法 ==》内部测试：内部人员开发测试 产品坐在一起 模拟用户场景去验收
看下有没有问题，如果发现问题了，及时通知开发修复，测试人员需要跟进bug解决情况

2）β 贝塔==》外部测试：软件已经交付给客户了，这是客户发现问题，我们会让客户统一
收集bug，以邮件方式发给相关的人，测试人员针对这些问题复测一遍，看下是否存在问题
，如果存在大问题，推迟上线，需要和客户沟通清楚，承若上线时间


你上一家公司的项目有哪些阶段？
每个阶段由哪些输入输出？
阶段                      输入                          输出
需求分析阶段           项目组成员参与需求评审          需求规格说明书SRS
概要设计阶段           需求规格说明书SRS               概要设计说明书HLD
详细设计阶段           概要设计说明书HLD               详细设计说明书LLD
编码阶段               开发编写代码                    整个代码包（.war .jar .zip）
单元测试阶段           对代码进行单元测试              单元测试报告
系统集成测试阶段       测试人员编写测试用例 执行测试   系统集成测试报告
验收测试阶段           公司内部成员和用户参与验收      验收测试报告



六 H 模型 ==>项目的流程【非常重要】

项目和版本的区别：微信项目11年，期间更新很多版本==》一个项目包含很多各版本

项目和产品的区别：先有项目后有产品  ==>软件生命周期的阶段
客户问题的引入=》可行性分析=》招投标=》成立项目组=》需求分析=》开发测试=》维护

假设6个月一个版本 ==》交付周期
工作日：周一到周五

自然日：周一到周天


1、梳理大致流程
①需求评审             开发 测试 产品 运维等
②概要设计HLD          测试继续了解需求
③详细设计LLD          测试深入了解需求，基于项目周期编写测试计划
④编码coding           测试人员根据需求编写测试用例和评审用例
⑤开发把编写好的代码打包   运维搭建测试环境，开发把代码包交给运维部署到测试环境中
⑥测试人员进行冒烟测试，进行sit系统集成测试发现bug提bug
⑦测试人员进行回归测试，将所有的bug全部复测一遍，直至bug数为0
⑧输出一个测试报告，发送给领导准备上线

2、针对以上8点细化

①-①SRS：客户提出需求，产品经理和客户进行沟通，产品经理根据客户需求，输出项目需求
，发给 测试 开发 运维 ui等等，开发测试进行阅读 和分析需求，把不确定的点记录下来
在个时候产品经理通知大家开一个需求评审会议，由产品经理主讲，测试开发听，看
提出自己的意见，产品经理觉得提出意见还可以，就进行调整需求，经过多次讨论，输出
一个基线化文档==》需求规格说明书

通知方式：邮件   项目组群 领导转达
通知的内容：会议的内容  时间   地点
基线化：表示没有问题，非常稳定 随时可以进入下一个环节

②-②
开发同事基于需求，编写概要设计说明书==》HLD
测试人员了解需求，测试人员可以参加开发文档评审（review）

③-③
开发基于概要设计说明书，编写详细设计说明书LLD
测试人员深入了解需求，需要挖掘需求当中的需求点，便于编写测试用例
基于项目的周期编写测试计划（测试范围 人力 任务进度 资源等等）

测试计划谁写？==》测试经理  测试骨干  你写

④-④ 开发基于文档编写代码（coding）
测试人员基于需求编写测试用例，编写完后，进行用例评审

用例评审有哪些？
交叉评审：我写的用例，你来评审，你写的用例，我来评审（测试组内）
组内评审：项目组内部成员 产品 项目经理 运维   ==》在公司中一般是这种形式
会议评审：客户可能也想参加（一般很少）

用例评审完后进行增删改，有可能会进行二次评审，评审完没有问题后，进行保存
（1、自己保存2、发给领导 3、上传用例管理工具testlink）
TE:test engineer 测试工程师
TC：test case 测试用例
TPM：test project manager 测试经理


⑤-⑤ 打包部署
运维搭建测试坏境，开发编写好的代码达成一个代码包，交给运维，运维将代码包部署
到测试环境中（包war jar zip）根据服务器而定，一般基于linux ，运维通知测试人员
可以进行到测试环节，会给到测试人员 ip地址  账号 密码

公司中有哪些环境？
测试环境：测试人员使用  （内网）
开发环境：开发人员使用  （内网）
生产环境：线上环境  真实环境
测试环境下一个单不会真实发货，如果在生产环境下单会真实发货


⑥-⑥
测试人员开始测试  （总共1000条）
首要要进行冒烟测试（选取用例50条以内）
冒烟测试：对主体功能的测试 ==》cms登录主体功能是登录成功
微信支付功能的主体功能是 支付成功
qq注册功能的主体功能是 qq注册成功可以登录

如果冒烟测试不通过，把版本打回给开发进行修复，让开发修复好后 通知我们测试
继续进行测试

如果冒烟测试哦通过，进行sit1胸痛集成测试
SIT1:系统集成测试，全量测试，把所有的用例全部执行一次（1000条用例）
发现bug 提交到bug管理工具，测试完 后输出一个测试小结（记录这次测试发现多少bug
执行多少用例 通过多少失败多少）==》假如发现用例没有覆盖全==》新增用例


⑦-⑦
SIT2：称为回归测试，也叫增量测试  （有可能抽取500）
回归测试测哪些内容？
1）复测上一轮发现bug
2）新增用例需要测试
3）冒烟测试
4）上一轮发现bug相关联模块
==》测试完后后需要输出测试小结（记录这次测试发现多少bug
执行多少用例 通过多少失败多少）假如发现用例没有覆盖全==》新增用例


SIT3：称为回归测试，也叫增量测试  （有可能抽取300）
回归测试测哪些内容？
1）复测上一轮发现bug
2）新增用例需要测试
3）冒烟测试
4）上一轮发现bug相关联模块
==》测试完后后需要输出测试小结（记录这次测试发现多少bug
执行多少用例 通过多少失败多少）假如发现用例没有覆盖全==》新增用例

SIT4：称为回归测试，也叫增量测试  （有可能抽取100）
回归测试测哪些内容？
1）复测上一轮发现bug
2）新增用例需要测试
3）冒烟测试
4）上一轮发现bug相关联模块
==》测试完后后需要输出测试小结（记录这次测试发现多少bug
执行多少用例 通过多少失败多少）假如发现用例没有覆盖全==》新增用例
当最后一轮测试没有问题了，所有的bug全部修复，都已ok，回归测试已结束
这时需要输出一个测试总结报告（记录所有测试的情况，用例执行情况 bug修复情况，
遗留）发给领导，领导会根据这个报告来作上线准备


问题1：一般测试一个版本有多少bug？比如1000条用例 5%-15%==》50-150个bug

问题2：H模型有一个0/1表示什么意思？可以理解为是一个建议性bug，建议性bug可以留到
下一个版本修复，需要把这个情况告知测试经理，让领导来决定是否可以遗留，需要确定
哪一个版本修复，修复时间

问题3：上线的标准（测试准出的标准）是什么？
1）本次更新的功能均已实现，符合需求规定的功能
2）所有的用例全部100%执行
3）所有提交的bug（致命 严重 一般 ）全部都要解决，且已验证通过和关闭
4）相关小结的文档，冒烟测试报告 bug统计报告 用例执行报告已输出
5）输出测试总结报告且通过相关领导确认

问题4：测试准入标准（什么时候可以介入测试）
1）所有相关文档都已输出（需求文档 开发文档 用例文档 测试计划）
2）开发编写的代码已完成且通过了单元测试，研发的功能符合需求文档
3）测试用例已通过评审
4）环境搭建好了，代码也已部署到测试环境
5）冒烟测试通过

问题5：假如上线后出现了问题怎么（客户那边反馈了线上有问题）？
1）让客户收集问题，统一发给我们研发部门
2）对这些问题在测试环境（线上环境）中操作一遍，是是否是客户这边误操作
3）如果测试环境没有问题，线上存在问题，可能漏传代码，立马上传代码，看下
是否正常
4）如果测试环境存在，对这些bug进行划分等级（致命 严重 一般 建议），通知上级领导
5）一时半会修复不了，这些问题有点严重，看是否需要回滚代码，回滚代码时需要
备份数据
6）跟进这些问题，直到修复为止


七、敏捷开发模型：项目周期端，项目进行比较快，互联网较多

八、迭代开发模型：在原有的系统上面增添新的功能

九、测试基本原则

十、测试活动生命周期

测试计划（测试准入）==》前提是需求基线化，已经了解了需求

测试分析和设计 ==》前提是测试计划输出，开始设计用例

测试实现和执行 ==》前提是用例已经编写好了，用例也评审过了

测试报告（测试准出）==》前提是用例执行完了，bug也已经修复了且为0

测试资产归档 ==》前提是测试报告输出==》手机测试