软件测试工程师理论基础（二）

研发流程（研发项目组织架构与常用模型）

研发的组织架构

1. 开发部门：主要负责产品的设计与开发，有需求分析师、系统架构师、UI前端工程师、开发工程师；
2. 测试部门：主要负责产品的验证与确认，有测试工程师、测试开发工程师、QC（产品质量评测）
3. 质量部门：主要负责产品的研发进度与研发质量，有管理岗位（开发经理、测试经理）、QA（质量保证工师）、CMO（配置管理员）

大公司才会岗位职责明确，分工细致；小公司一般都是身兼多职。

研发流程常用模型

1. 瀑布模型(适用需求全面且变更极少的情形,对项目周期要求不高OA系统)：按照软件生命周期的顺序从前往后进行

   项目计划→需求分析→架构设计→编码→测试→维护
   优点：应用广泛，阶段分明流程清晰，易理解，便于分析问题，质量有保障
   缺点：需求响应速度慢，测试介入较晚,前期的问题到后期才能发现,文档较多,项目后期才能看到研发成果,研发风险较大
   适用于传统的项目，一般1-3个月更新一次版本

2. 螺旋模型：将需求分段实现，每段需求的实现都是一个瀑布模型，每段需求实现完成之后都会进行风险评估
   优点：需求分段实现能实时的发现项目风险，降低项目风险，用户参与度高,项目可控
   缺点：周期长
   适用于大型项目的研发过程，一般会经历半年以上的研发时间

3. V模型：瀑布模型的变种,将测试划分为多个阶段,并与相应开发阶段对应

   优点:左边是开发活动,右边是测试活动,强调了开发和测试同等重要的思想
   缺点:对测试介入时间指代不明确
   适用需求变更不频繁的情形

4. 双V模型：一个V代表开发活动,一个V代表测试活动,开发和测试并行,测试设计和测试执行分离,先设计,后执行,测试设计和测试执行顺序相反

   优点:测试介入较早,有利于发现和预防bug
   缺点:测试设计对开发活动的依赖性较强

5. 敏捷迭代：将各部门拆散，需求、设计、开发、测试组成小的团队来认领需求，将需求划分成小需求,每个小需求由相应的团队去完成,开发效率高,重沟通,轻文档,持续集成：利用一个工（jenkins），进行自动化的合并，编译代码，打包成安装包，搭建测试环境，执行测试，并生成测试结果，发送给对应的责任人，省去大部分的编写文档的工作，强调沟通与交流。
   优点:能够快速开发出软件版本
   缺点: 对员工的个人能力、沟通交流能力，对团队要求高,不适合不成熟的团队
   适合互联网项目,需求变更频繁的项目，适用于互联网类的软件研发，1-2周更新一次版本，能够快速的响应市场需求

研发模型非常多（增量模型、RUP模型、H模型）
其实都是依托于瀑布模型来进行特定的工作调整的，没有必要掌握所有的研发模型。

在软件生命周期的过程中，开发和测试的系统测试工作内容