软件测试的生命周期&测试流程

一、软件的生命周期
二、开发模型
三、测试模型
四、测试流程
五、缺陷管理流程
六、软件和质量

---

一、软件的生命周期(基于瀑布模型的生命周期)

软件的生命周期：是指从产生到淘汰的过程
包括：计划（开发方与需求方讨论）、需求分析、设计、编码、测试（单元测试、集成测试、系统测试、验收测试）、运行维护、淘汰升级等

1、可行性研究及计划

开发方和需求方共同讨论，确定软件的开发目的及可行性，并制定实施计划

通过确定软件开发目的，给出软件的功能、性能、可靠性、接口等方面的设想
研究完成这个项目的可行性，问题的解决方案，对资源、成本的估计，制定实施计划

2、需求分析

由需求分析人员和用户共同讨论
在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析
弄清用户对软件系统的全部需求，明确哪些需求可以满足，哪些不可以，并给出确切描述
产出《需求规格说明书》

注：唯一不变的是变化本身，同样需求在整个软件开发过程中会不断变化，所以，要制定需求变更计划来应对这种变化
来保证项目的顺利进行

3、软件设计

此阶段是核心，由架构师完成
根据需求分析的结果，对整个软件系统进行设计，如：系统框架设计、数据库设计等
软件设计：分为概要设计(HLD)和详细设计(LLD)
产出《设计说明书》

• 概要设计(HLD)-----集成测试(接口)
• 详细设计(LLD)-----单元测试(代码)

4、编码

按照软件设计的结果，程序员开始编写代码

5、软件测试

软件编写完成后，要经过严密的测试，以发现问题并加以纠正
整个测试过程分为：单元测试、集成测试、系统测试、验收测试
测试方法主要有：黑盒测试、白盒测试

在测试过程中，要建立详细的测试计划并严格按照测试计划进行，减少测试的随意性

• 单元测试：对代码的测试，一般由开发完成
• 集成测试：对接口的测试，在单元测试之后进行，由开发完成
• 系统测试：比对需求规格说明书，根据测试用例进行完整的测试，如各功能是否满足需求，系统运行是否存在漏洞
• 验收测试：用户对软件进行验收，客户拿到软件后，会根据用户需求来进行判定软件是否达到需求

单元测试、集成测试、系统测试之间，好比：砖、墙、楼

6、运行维护

是软件生命周期中，持续时间最长的阶段
软件投入使用后，由于多方面原因，软件不能继续适应用户的要求或要延续软件的使用寿命，就要对软件进行维护
软件的维护：包括纠错性维护、改进性维护

7、淘汰升级

生命周期示意图：

二、开发模型

软件开发模型：边做边改模型、瀑布模型、快速原型模型、螺旋模型、增量模型、迭代模型、演化模型
             喷泉模型、混合模型、敏捷开发模型

1、边做边改模型

这种模型，没有规格说明，也没有经过设计，开发人员拿到项目会立即根据需求编写程序
软件会伴随客户的要求不断被修改，直至客户满意
缺点：缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改
     忽略需求环节，给软件开发带来很大的风险
     没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难

2、瀑布模型

瀑布模型中，包括计划、需求分析、设计、编码、测试、运行维护等六个基本活动
规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落，是一种线性模型

瀑布模型强调文档的作用，要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化
已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
(1) 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
(2) 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险
(3) 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果

3、快速原型模型

本质是，开发人员对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终系统需求
快速原型模型中，第一步：通过一些快速原型语言先构建出软件产品的原型系统，可快速的和用户交互
用户通过该原型系统具体的了解该款软件，对原型进行评价，进一步细化待开发软件的需求。通过逐步
调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步：则在第一步的基础上
开发客户满意的软件产品
快速原型，可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果

4、螺旋模型

螺旋模型，将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，适合于大型复杂的系统
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
(1) 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件
(2) 风险分析：分析评估所选方案，考虑如何识别和消除风险
(3) 实施工程：实施软件开发和验证
(4) 客户评估：评价开发工作，提出修正建议，制定下一步计划
螺旋模型也有一定的限制条件，具体如下：
(1)在软件开发的每个阶段，都增加一个风险分析过程
(2)螺旋模型强调风险分析，但要求客户接受这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
(3)如果执行风险分析会影响项目的利润，那进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
(4)软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
在软件开发的每个阶段，都增加一个风险分析过程

5、增量模型

与建造大厦相同，软件也是一步一步建造起来的
增量模型，就是把待开发的软件系统进行模块化，把每个模块都看作一个增量组件，从而分批次的分析、设计
编码和测试这些增量组件。运用增量模型的软件开发过程，就是递增式的过程
相较于瀑布模型，开发人员不需要一次性地把整个软件产品交给用户，可以分批次进行提交
例如：要开发A、B、C、D四个业务功能，增量方法就可以将四个功能分为两次增量来完成
第一个增量完成A、B功能，第二次增量完成C、D功能

其实，增量就是：一块一块来进行测试
比如画一幅人物画，用增量，就是先画人的头部，再画身体，再画手脚

6、迭代模型

每次迭代都会产生一个可发布的产品，也就是把一个大项目拆成若干个小项目，分步实施，适合于分多期实施的项目
例如：要开发A、B、C、D四个业务功能
对于迭代开发，则是分两次迭代来开发，第一次迭代完成A、B、C、D四个基本业务功能，但不含复杂的业务逻辑
第二次迭代是逐渐细化、补充完整相关的业务逻辑，如果遇到风险，那么在前期就可发现并设法解决

其实，迭代就是：先整体再细化
比如画一幅人物画，先画整体轮廓，再勾勒基本雏形，再细化、着色

7、演化模型

演化模型，就是在原型基础上经过改进形成最终产品，属于迭代开发方法
该模型可以表示为：第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->...
即：根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型
再根据用户在使用原型的过程中，提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到用户满意的软件产品
采用演化模型的开发过程，实际上就是从初始的原型逐步演化成最终软件产品的过程。

演化模型：主要针对事先不能完整定义需求的软件开发.用户可以给出待开发系统的核心需求

8、喷泉模型

喷泉模型不像瀑布模型那样,需求分析结束后才开始设计,设计结束后才开始编码.该模型的各个阶段没有明显的界限
此模型：具有更多的增量和迭代性质，软件开发过程的各个阶段可以相互重叠和多次反复，相关对象在每次迭代中加入渐近的软件成分
就像水喷上去又可以落下来，可以落在中间，也可以落在最底部

优点：适合面向对象的软件开发，开发效率相对较高
缺点：由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理

9、混合模型

过程开发模型又叫混合模型、元模型
把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展
实际上，一些软件开发单位都是使用几种不同的开发方法，来组成他们自己的混合模型

小结：

综上所诉，我们可以看到各个开发模型都有其可取之处，也有其缺点,软件开发过程中应适当的选择合适的开发模型,且应随着当前
正在开发的软件产品的特性而变化，以减小所选模型的缺点，充分利用其优点
几大开发模型也有其共通点，例如:瀑布模型是按顺序进行，就如数学中的“线性”开发。而“线性”是人们最容易掌握并能熟练应用的思想方法
一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，当我们领会了线性的精神，就可以不再呆板地
套用线性模型的外表，而可以用活它，例如：增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，其他模型亦如此

以下列出了几种常见模型的优缺点：
瀑布模型：文档驱动，系统可能不满足客户的需求
快速原型模型：关注满足客户需求，可能导致系统设计差、效率低，难于维护
增量模型：开发早期反馈及时，易于维护，需要开放式体系结构，可能会导致效率低下
螺旋模型：风险驱动，风险分析人员需要有经验且经过充分训练

10、敏捷开发模型

敏捷开发，是一种以人为核心、迭代、循序渐进的开发方法
敏捷开发过程中，软件一直处于可使用状态，它将项目分成若干相互联系、可以独立运行的子项目，因此，每个阶段软件都是可见的，客户
可以直观的体验并提出意见

敏捷开发的开发方法有：极限编程(xp)、Scrum、精益开发、动态系统开发方法、特征驱动开发、水晶开发等

敏捷宣言：个体和交互胜于过程和工具 (强调：人与人的沟通)
         可用的软件胜于完备的文档 (强调:轻文档，对文档的依赖性不高)
         客户合作胜于合同谈判 (强调:客户参与)
         相应变化胜于遵循计划 (强调:拥抱变化)
三种角色：Product Owner(产品经理)、Scrum Master(项目经理)、Scrum Team(开发团队)
四种会议：Sprint Planning Meeting(Sprint的计划会议)、Daily Scrum Meeting(每日站会)
         Sprint Review Meeting(Sprint的评审会议)：每个sprint结束，团队会把成果向PO或其他人演示
         Sprint Retrospective Meeting(Sprint的回顾会议)：对刚结束的Sprint进行总结
两个工具：Backlog(待办列表)：Sprint Backlog(Sprint的需求列表)、Product Backlog(产品需求列表)
         Burn-down Chart(燃尽图)：Sprint Burn-down Chart(Sprint燃尽图)
                                  Release Burn-down Chart(发布燃尽图)

Scrum基本术语：

• Sprint：原意冲刺，指一个迭代周期，即：实现一个小目标的周期，一般需要1-周时间
• Backlog：待办列表，即待认领或开发的任务列表，分为：Sprint Backlog、Product Backlog
• Product Backlog：产品待办列表，即需求列表
• Sprint Backlog：这一轮要迭代的任务需求列表
• User Story：用户故事，指一条需求，也就是一个功能点
• Task：实现一条需求要做的具体开发任务
• Daily meeting：每天的站会，用于监控项目进度。有些公司直接称其为Scrum
• Sprint Review meeting：冲刺评审会议，让团队成员们演示成果
• Sprint burn down：冲刺燃尽图，说白了就是记录当前周期的需求完成情况
• Rlease：开发周期完成，项目发布新的可用版本

 以Scrum为例，其流程图：

Scrum的流程说明：

1、由Product Owner将整个产品设计成Product Backlog(产品待办列表)，就是一个个需求列表

2、Scrum Team召开产品迭代计划会议，根据Product Backlog列表，确定哪些Story(需求)要在第一次迭代中完成，评估迭代时间(2-4周)
   然后把这个Story进行细化，形成一个个Sprint Backlog，从而得到相应的迭代周期任务列表。ps:会议提倡所有团队人员参与

3、由Scrum Team的每个成员把Sprint Backlog(要迭代的功能需求)再细化成更小的任务(小到每个任务的工作量在2天内能完成)贴在任务墙上的任务看板
   让大家认领分配(任务看板：就是把未完成、正在做、已完成的工作状态贴到一个墙上，这样大家都可以看到任务的状态)

4、举行Daily Scrum Meeting(每日站立会议)，让大家在每日站会上总结昨天做的事、遇到的困难，今日开展什么任务
  (每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，每个人都要发言，时间控制在15分钟内)

5、每个人回答完后，走到看板前更新自己的Sprint burn down(Sprint燃尽图)，保证任务的状况可以清晰看到
  (燃尽图：把当前的任务总数和日期一起绘制，每天记录下，可以看到每天还剩多少个任务，直到任务数为0，这个迭代就完成了)
   ps：在开发人员开始开发一个任务时，需要找来相对应的测试人员，讲解该任务功能，以便测试人员有一致的理解，并且一开始就进行
   测试用例、自动化测试脚本的开发等(若需要自动化测试的话)

6、尽量做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS
   就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上
   再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件
   通知项目管理人员

7、当一个Story(需求)完成，也就是Sprint Backlog(要迭代的功能需求)被完成，也就表示一次Sprint(迭代)完成
   这时，我们要进行Sprint Review Meeting(评审会议)，也称为演示会议，要向客户演示自己完成的软件产品，并获得客户的反馈
   产品负责人和客户都要参加（这个会议非常重要，一定不能取消）
   ps：用户对软件开发没有概念，只知道要实现什么需求，所以，就要不断的让用户看到产品的模型，让用户逐渐对产品产生概念

8、最后就是Sprint Retrospective Meeting(回顾会议)，也称为总结会议，以轮流发言方式进行，每个人都要发言
   总结并讨论改进的地方，放入下一轮Sprint(迭代)的产品需求中

小结：

• Scrum项目先建立一个产品功能订单（Backlog），制定一个短期“冲刺”（Sprint）计划，执行这个计划，在计划周期内天开会讨论计划中的问题和进展，计划完成后演示工作成果，再对该阶段的工作做回顾、反思和改进，然后不断重复以上流程
• 从上述的Scrum项目管理流程中我们总结出Scrum规定的几个要点
    1、计划开始之前需要有一个产品功能订单 
    2、整体的开发流程由一个一个的Sprint周期组成
    3、计划周期内每天进行问题和进展的反馈
    4、Sprint周期完成时需要能够有具体输出且演示的工作成果
    5、Sprint周期完成后需要进行Sprint回顾
    6、整个过程周期性的推进
• 是的，Scrum就是这么简单

 三、测试模型

测试模型：V模型、W模型、X模型、H模型

1、V模型（瀑布模型的变种）

以“编码”为黄金分割线，将整个过程分为开发和测试，并且开发和测试之间是串行的关系
同时，测试过程中存在的若干不同的测试级别，并与每一个开发级别对应

优点：是软件开发瀑布模型的变种，改进了瀑布模型
      反映了测试活动与分析和设计的关系

缺点：测试过程作为需求分析、概要设计、详细设计及编码之后的一个阶段
      该模型使人容易理解为：主要是针对程序进行测试，寻找错误，忽略了对需求、设计的测试
      需求分析阶段的错误，直到后期才被发现，没有体现“尽早、不断地进行软件测试” 的原则
      先规范流后开发测试流，对应于开发模型的瀑布模型的开发，这种开发周期长，修复错误的周期长，所以修复成本也高

• 单元测试：是模块测试，验证软件的基本组成单位的正确性，是白盒测试
• 集成测试：是模块间的测试，测试接口（软件各模块之间的接口和软件与硬件之间的接口）是否正确，是灰盒测试（白盒和                    黑盒结合）
• 系统测试：系统测试包括：冒烟测试 系统测试 回归测试
   (1) 冒烟测试：主干流程测试，确认软件的基本功能正常，可以进行后续的测试工作
   (2) 系统测试：是检测系统的功能、质量、性能能否满足系统的要求，包括功能、性能、界面、可靠性、兼容性等等，是黑                          盒测试
   (3) 回归测试：修改了旧代码之后重新进行测试，确认修改后的代码没有引入新的错误或导致其他代码产生新的错误
• 验收测试：是确保软件能否满足用户的需求或合同的要求

2、W模型（V模型的改进）

W模型：是由两个V模型组成，一个是开发阶段，一个测试阶段 
可以看出：在W模型中，开发和测试是并行的关系

优点：基于“尽早、不断地进行软件测试”的原则下，在V模型中增加软件各开发阶段应同步进行的测试，演化为W模型
     强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试
           测试与开发是同步进行的，从而有利于尽早地发现问题

缺点：虽说开发和测试是并行的，但该模型的整体还是串行的 (以需求为起点，到测试结的过程)
     只有上一阶段完成后，才可以开始下一阶段的活动，无法支持敏捷开发模式

对应关系如下：

3、X模型（也是对V模型的改进）

X模型：分为两个流，是开发流和测试流交替进行

X模型：左边描述的是，针对单独的程序片段进行的相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序
      然后再对这些可执行程序进行测试，己通过集成测试的成品，可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分
      多根并行的曲线表示变更可以在各个部分发生
      由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试
      这一方式能帮助有经验的测试人员在测试计划之外发现更多的软件错误，但这样可能对测试造成人力、物力和财力的浪费
      对测试员的熟练程度要求比较高

ps：感觉像开发一点就测一点，然后聚成一部分，再测试这一部分...

4、H模型

H模型：开发流和测试流属于两个平行流，与其他流并发运行，即只要测试成熟，测试就可以进行
H模型：软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时
      就可以从测试准备阶段进行到测试执行阶段

     (1) 软件测试可以进行尽早的进行
     (2) 软件测试可以根据被测物的不同而分层次进行
     (3) 强调测试是独立的，只要测试准备完成，就可以执行测试

小结：

• X、W都是在V上建立的，目前现在多数公司是W
• 测试模型的使用，在实际工作中应灵活地运用各种模型的优点

四、测试流程

（一）测试流程包含的阶段

测试流程包含：需求分析、计划、设计、实施、评审等阶段

1、需求分析阶段：

阅读需求，理解需求，主要就是对业务的学习，分析需求点，参与需求评审会议
输出：需求规格说明书（SRS）

2、计划阶段：

参考需求规格说明书（SRS），编写测试计划
进行项目总体规划
内容包括：产品概述、测试目标、测试范围(来自需求文档)、测试策略(方法)、资源配置(人力物力的分配)、进度安排、测试周期
         风险评估及规避措施等
由测试主管编写，当然我们也会参与相关的评审工作
输入：SRS
输出：测试计划

• 测试周期：参考历史数据、同行专家、需求点
  中值估算法：历史数据大小排，取中值
  三点估算法：（乐观+悲观+最可能*4）/6
  扑克牌估算法：取自敏捷开发中的估算方法
• 风险分析：(1)测试活动不能如期举行：开发不能如期发布版本，测试的环境、数据、脚本、人手不到位，软件冒烟测试没通过打回，少数bug迟迟不能修复，开发在攻关等 (2)团队业务不熟 (3)软件质量低，bug太多
• 制定测试计划，参照以往文档（5W1H）：what(对象)、why(原因)、who(参与人)、when(时间)、where(场所)、how(方式)

3、设计阶段：

对测试计划进行细化，生成测试方案，测试方案编写完成后也需要进行评审

主要是编写测试用例，会参考需求文档（原型图）、概要设计、详细设计等文档,用例编写完成后会进行评审
内容包括：测试需求的细化、测试策略（方法）的选取、设计和编写测试用例、测试环境的规划、自动化测试框架的设计
         测试数据和测试脚本的设计、测试工具的设计和选择
由经验丰富的测试人员编写
输入：SRS、测试计划
输出：测试方案、测试用例文档

• 测试方案要求根据《SRS》上的每个需求点，设计出包括：需求点简介、测试思路、详细测试方法三部分的方案
• 测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖
• 测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏
  
   
• (1)测试用例的生命周期：确定要写测试用例→ 设计测试用例(用到的技术) →实现测试用例→ 执行测试用例 → 管理测试用例
  
      黑盒测试的设计技术：等价类、边界值、因果图、判定表、状态迁移。。
      白盒测试的设计技术：语句覆盖、分支覆盖、条件覆盖、路径覆盖。。
• (2)测试环境包括：硬件、软件环境，网络环境，测试数据，测试工具
     测试环境的原则：1、尽可能真实环境，或模拟真实环境，少用模拟器、虚拟机
                                2、达到软件运行的最低底线，达到最低测试配置，如：游戏，最低需要什么显卡、主频、内存CPU等
                                3、选择主流的操作系统和软件平台
                                4、测试环境要干净、独立、排除干扰，如：做性能测试，尽量不要有其他软件，同时不要中病毒
• (3)硬件相关知识：1、常见硬盘设备和技术指标，如：主频、缓存、cpu、硬盘、显卡等
                              2、会一些常用设备的连接、操作、配置
                              3、具备识别、排查硬件故障的能力
  
     软件相关知识：1、常用软件的安装、操作、配置，如：操作系统的安装，驱动程序安装，数据库的安装、使用、查询、
                                   导入导出，浏览器及其插件的安装
                             2、熟悉各种模拟器、虚拟机
                             3、熟悉各种系统镜像、备份还原工具，如：很多电脑要安装一样的配置，已有一台，怎么快速全部安好
• (4)测试工具、脚本：1、测试管理工具：HP的QC，JIRA，禅道
                                 2、功能测试工具：HP的UFT、QTP，selenium
                                 3、性能测试工具：HP loadrunner，Apache Jmeter
                                 4、代码测试工具：Junit，Cppunit，PHPunit
                                黑盒层面： 2、3       白盒层面：4

4、执行（实施）阶段：

首先，搭建测试环境，执行冒烟测试（预测试），冒烟（预测试）通过，然后进入正式测试，遇到问题，提交bug到缺陷管理平台
并对bug进行跟踪,直到被测软件达到测试需求的要求，没有重大bug，测试结束

简言之，就是：手工或自动化执行测试，发现、报告、跟踪bug

• 缺陷，详情见 五、缺陷管理流程

5、评审阶段：

出测试报告，对整个测试过程、版本质量做一个详细的评估
输出：测试报告

•  测试结束的标准：1、因项目需要提前结束(客户提前1个月需要软件)
                              2、因开发原因阻塞(开发攻关不下来，又不影响大局)
                              3、软件质量不达标(要么砍掉，要么回炉)
                              4、正常下，按规定全部提前完成(理想情况下)
                              5、达到规定的结束标准：覆盖率到。。，缺陷率少于。。
• 测试结束后要做什么：1、确保所有测试都已经结束
                                    2、收集测试工作产出物(各种文档，如：SRS，报告，日志，图表等)
                                    3、组织总结反思会：对较晚发现且不能解决的缺陷，以后可邀请更多同行专家解决
                                                                    发现的缺陷为什么发生，什么时候发生，找到可能的趋势
                                                                    表扬、批评什么人；对以后工作的期望
                                                                     
• 总结的内容：
  (1)测试工作的度量：
  黑盒测试：测试用例对需求的覆盖率，记为A
                   测试用例覆盖的需求数和需求总数的百分比（1200条用例覆盖100个需求，共有120需求，有A=100/120 *100%）
                   测试用例的执行情况：多少用例执行成功，多少失败了，失败的测试用例发现多少缺陷
  白盒测试：统计测试用例对代码的覆盖率
                   测试用例对模块、代码行、路径的覆盖率    
  (2)评估软件产品的质量：整理缺陷管理系统中的缺陷报告
                                        对缺陷报告进行分类统计（按阶段、模块、优先级和严重性、状态变化趋势），绘制表格图表分析

  

  
  (3)成本核算：硬件设备、软件系统、人力资源、项目管理运营的成本
  (4)资源利用率：包括人员、设备、软件工具等
              计算方法：一个资源，在规定时间内(如：一个月)，用于实际测试工作的时间所占百分比
                     意义：有助于后续项目的资源估算和优化
  (5)总结和反思（总结好的，反思不好的）

（二）测试流程

•  产品团队一般组成：项目经理、产品、开发（前端、后端、移动端）、测试、UI设计
• 大一点的企业还包括：DBA（数据库工程师）、架构师、运维、运营
• 测试的主要沟通对象：开发、产品经理、测试经理、研发经理

开发流程：
         了解用户需求 → 进行需求分析 → 得知功能组成及设计软件结构 → 开发设计计划 → 概要设计、详细设计 → 编写代码 
         → 单元测试→ 代码审查 → 集成测试 → 打包提交给测试部 → 等待测试部提交bug → 修复bug → 等待测试部回归bug
         → N轮之后，直到bug解决，符合需求 → 版本上线 → 面向用户使用

测试流程：
         了解用户需求 → 进行需求分析 → 需求评审 → 需求定稿(需求规格说明书)，测试人员理解需求
         → 测试主管编写测试计划（人力物力时间进度的安排），并进行同行评审 → 测试组长发布测试计划
         → 由资深测试人员设计测试方案及评审 → 测试人员根据测试方案定稿，进行测试用例编写 → 评审测试用例本
         → 搭建测试环境 → 等待开发提交测试包(提测) → 部署测试包 → 冒烟测试（主体功能预测） → 正式进入测试，执行测试用例 
         → bug跟踪处理（提交及回归bug）→ N轮之后符合需求 → 测试结束，出测试报告 → 测试验收
         → 写安装、使用手册 → 版本上线 → 面向用户使用 → 测试总结

如下：

根据需求 ————> 制定测试计划
　　　　　　　　　　↓
　　　　　　设计、编写测试用例
　　　　　　　　　　↓
　　　　　　　执行测试用例 ————>提交缺陷报告
　　　　　　　　　　↓
           提交测试总结报告

小结：

• 流程：需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM
• 需求分析：主要是产品人员制定的，包括文档以及原型的设计
• 需求评审：需求分析出来后，就要召集参加该项目的全体工作人员进行评审，以会议的形式对文档以及原型进行讨论，
                    此时，测试人员要对原型和文档进行理解和熟悉，对不理解的地方进行提问
• 测试计划：根据开发计划进行排期，做出测试的具体时间和此时
• 测试用例：测试方案写完之后，就进行测试用例的编写
• 用例评审：用例写之后，对用例进行评审，参加评审的人员可以是开发人员、产品人员、测试人员等
• 环境部署：由于之前所在的公司，都是由测试人员进行环境部署的，每次更新测试包，都是测试人员亲自更新
• 执行测试：环境部署之后，就可以开展测试了
• 测试通过：所有bug都关闭以后，可以看成测试通过了，然后就是产品的上线

五、缺陷管理流程

1、缺陷类型：

缺陷类型：错误、遗漏、冗余、不满足客户需求

2、引入缺陷的原因：

原因：
     开发过程中，缺乏有效沟通或没有沟通
     软件复杂度，越来越高
     编程中产生错误
     需求不断变更
     项目进度的压力
     不重视开发文档
     软件开发工具本身隐藏问题

3、缺陷管理流程：

测试发现缺陷 → 提交缺陷进入系统 → 审核 → 分配给相关开发人员 → 开发处理缺陷- → 测试检查验证确认 → 关闭、重新激活、挂起、推迟

状态：
     new--open--fix--close 
     new--open--fix--reopen--fix--close
     new--open--reject--close
     new--open--reject--reopen--fix--close
测试人员:关注 fix 和 reject 状态的缺陷

• 识别缺陷：通过技术文档(SRS)、参考同类型软件识别缺陷、与客户和相关人员(主管，经理，需求人员)来沟通识别
• 缺陷：分可再现、不可再现
• 统一缺陷报告的模板： 
  1、编号   2、所属模块 3、摘要/标题（用一句话描述BUG）
  4、测试环境 、操作步骤 、实际结果 、期望结果 、备注
  5、bug优先级、严重性 6、测试人  7、日期  8、bug状态  9、截图

六、软件和质量

测试：是保障软件质量的重要手段，但不是唯一
保证质量：需要软件生命周期中的所有参与者共同进行，也就是从软件的生产流程上，从需求、设计、开发编码、再到运维，掌控软件质量

1、软件质量铁三角：（技术、流程、组织）

2、软件质量管理体系（有：ISO、CMM、6西格玛）

CMMI特点：初始级（无序的，不可预测的）
          可重复级（过程有规律的，能重复以前的成功）
          已定义级（过程概括为：标准的，一致的）
          已管理级（过程是可预测的）
          优化级（过程不断改进）

CMM：阶段式      CMMI：阶段式，连续式
6西格玛：百万个样本中3,4个缺陷

3、软件质量模型：

4、质量管理的PDCA循环：

plan（计划） → do（执行） → check（检查） → act（改进）