软件测试流程及生命周期模型

软件测试流程

一、测试计划阶段（需求评审）
内容包含（测试目的，项目背景，参考文档，提交文档，术语定义，测试需求，测试策略，系统资源，测试工具，测试进度，里程碑，任务安排，风险评估，测试通过标准，附录。）
一份测试计划大概25页到40页

二、测试设计和开发阶段
1、分析测试需求、设计测试用例（需要评审）
2、准备数据、开发测试工具、脚本

三、测试实施阶段（包含性能测试）
按照设计好的用例、准备好的数据和指定的测试策略，实施具体的测试流程

四、测试评估阶段
测试总结、缺陷分析、过程评估

拿到需求文档——需求评审——编写测试计划——计划评审——编写测试用例——用例评审——拿到接口文档——接口功能测试——接口测性能压测——持续集成——冒烟测试——进行系统迭代轮次——提交缺陷、跟进缺陷、反测——提交阶段性测试 告——测试达到上线标准后，提交总结性测试 告——编写性能测试用例——进行性能负载和稳定性测试——提交性能测试 告——进行安全性测试——提交安全性测试 告——进入alpha验收测试阶段——进入beta验收测试阶段——迭代维护

整个流程就是先拿到需求文档进行需求评审（开会讲产品，每个模块…）这时测试人员应看需求是否合理，需求里边有没有二义性的词，有没有多余的功能模块，多余的操作步骤等等，需求评审时如果能发现bug那才是把bug扼杀在摇篮里，需求评审之后开始编写测试计划，写好的计划要开会进行评审，告诉大家，由大家来决定合不合理，如果不合理也来得及改，计划评审后开始写测试用例，写完测试用例后也要评审，保证没有遗漏，拿到接口文档后进行接口功能测试，接口测试完了还能做接口的性能测试和压力测试，性能压测完了后开始持续集成，这时才有了可视化界面，有了可视化界面后要对 站进行一次冒烟测试，冒烟测试环节存在的目的是为了这个软件基本功能正常，流程能够跑通，所有的跳转页面都能跳转正确，能够符合系统测试阶段的标准，就是一个系统测试的把关者。冒烟测试完了之后开始进入系统测试阶段，第一轮，第二轮，第三轮…每一轮结束之后都要有阶段性的测试 告，项目达到上线标准后提交一个总结性的测试 告，把每一个阶段的 告数据汇总产出一份总结性的 告，有图有表扇形图折线图…最好是PPT。之后编写性能测试用例，进行性能负载和稳定性测试……

生命周期模型

在软件开发行业发展的实践过程中人们总结了很多的开发模型，比如瀑布模型，原型模型，螺旋模型，增量模型，渐进模型和RUP模型等。与软件开发工作紧密相连的软件测试行业也随之产生了一些具有指导意义的测试模型。

模型不分好坏，好坏分团队，事在人为。

什么是软件生命周期/strong>
软件生命周期是软件工程中非常重要的概念。
软件生命周期：是指软件开发和测试全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、发布后的维护的过程。

就是一个工作思路，工作方式。

一个软件项目的生命周期和人类的生命周期的类比：

人类：出生—>儿童 少年——>青年 中年 老年——>死亡

软件：可行性研究 需求分析——>设计 编码 测试——>软件发布维护——>淘汰

生命周期模型图

• 瀑布模型
  瀑布：顾名思义，水从上往下流，水回不去了，就是一个无法回滚的模型
  1、瀑布模型的特点
  （1）为项目提供了按阶段划分的检查点。
  （2）当前一阶段完成后，只需要去关注后续阶段。
  （3）可在迭代模型中应用瀑布模型。
  增量迭代应用于瀑布模型。迭代先解决最大的问题。每次迭代产生一个可运行的版本，同时增加更多的功能。每次迭代必须经过质量和集成测试。
  2、瀑布模型的缺点
  （1）在项目各个阶段之间极少有反馈。
  （2）只有在项目在生命周期的后期才能看到结果。
  （3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

不允许回滚的项目，外包公司多用瀑布模型，需求分析阶段可以改计划，进入设计阶段后就只能改需求分析，改不了计划，进入编码阶段只能飞设计，无法改需求分析，测试阶段只能改编码无法改设计。就是一次性的项目，不允许改需求，如果进入到后边的版本后想要回滚，回滚不了，如果发布上线后再想加东西那就下个版本再说。

• W模型
  1、W模型的特点
  （1）W模型由两个V字形模型组成，分别代表测试与开发过程，也就是说测试与开发是同步进行的。
  （2）测试的对象不仅仅是程序，还包括需求和设计。
  （3）尽早发现软件缺陷可降低软件开发的成本。
  2、W模型的缺点
  （1）W模型存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，并且测试和开发保持着一种线性的前后关系，上阶段完全结束，才能正式开始下阶段工作。也就是说需求分析和需求测试都结束之后才能进行概要设计和概要设计测试，必须并排进行。
  （2）无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临的困惑。（一次测明白，没法迭代）
  不在乎时间长短，追求质量不追求速度，保证每一个模块都没问题再进行下一项测试，例如国家级的，政府级的，金融，银行，医疗项目等。慢，但是质量高。

• 螺旋模型
  1、螺旋模型的特点
  （1）引入了其他模型不具备的风险分析，当存在重大风险时有机会停止，进行变更减小损失，特别适合于大型复杂的系统。
  （2）以小的分段来构建大型系统，使成本计算变得简单容易。
  （3）客户始终参与每个阶段的开发，保证项目不偏离正确方向。
  （4）随着项目推进，客户始终掌握项目的最新信息。
  （5）对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更！
  2、螺旋模式的缺点
  建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

必须是公司的核心产品才能用螺旋模型，核心产品的特点是公司的顶梁柱，版本要不断的更新和维护，而且这个项目是支撑着整个公司的，就像阿里的淘宝一样。
就像滚雪球一样，先从里圈开始，一圈一圈往外延伸，第一个版本就做几个功能，确定没问题了再往外扩第二圈，2.0版本，增加几个功能，确定2.0版本没问题再扩3.0版本……

螺旋模型的好处就是它可以保证项目不偏离正确的方向，当出现问题时可以回滚到上一个版本，进行变更，减小损失。比如说4.0出问题了可以回滚到3.0，重新设计4.0。

这种大项目没法计算成本，就算估计要花多少钱也估不准。但是如果第一次只计算1.0版本的费用，1.0做完没问题之后再估2.0的费用，这样就相对容易些。

一开始就定模块定的多并不是好事，因为只是现在的认知能够意识到需要这些功能，而将来很有可能有新的产品新的技术新的东西引进时思路就变了，所以一开始定模块是越少越好而不是越多越好，是随着 会的需要用户的需求来添加新的模块，而不是在一开始就定好很多模块。