150 lines
5.5 KiB
Markdown
150 lines
5.5 KiB
Markdown
---
|
||
title: 研发流程与规范
|
||
date: 2020-06-28 16:37:55
|
||
tags: [研发流程与规范]
|
||
categories: [质量体系]
|
||
author: Anges黎梦
|
||
sticky: 1
|
||
---
|
||
|
||
### 开始之前
|
||
|
||
在开始之前，我们首要知道的是现在的研发模式是什么？
|
||
|
||
研发模式，在以前都是瀑布式的研发模式。
|
||
|
||
而在现如今，很多公司引入敏捷模式、迭代模式等模式。
|
||
|
||
而我们作为测试工程师，为什么要去了解研发模式呢？
|
||
|
||
那是因为不同的研发模式，不同的研发架构，都会引入相对不同的测试手段、测试方法等。
|
||
|
||
若不去了解研发的架构，那么在测试中很容易出现忽略的测试内容，而这些内容往往是很致命的。
|
||
|
||
所以我们本篇文章，从研发模式、研发架构来入手，简单为大家介绍一下研发流程与规范。
|
||
|
||
### 研发模式与流程
|
||
|
||
#### 瀑布模式
|
||
|
||
|
||
|
||
瀑布模型式是最典型的预见性的方法，
|
||
|
||
严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。
|
||
|
||
要求每一各研发阶段都要做到最好后，才会去研发下各阶段。
|
||
|
||
这样它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂，
|
||
|
||
用这种模式研发软件所需的时间也是比较长的。
|
||
|
||
瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
|
||
|
||
瀑布式开发是一种老旧的计算机软件开发方法。
|
||
|
||
#### 迭代模式
|
||
|
||
|
||
|
||
迭代式研发是每次只设计和实现这个产品的一部分,逐步逐步完成的方法叫迭代开发。
|
||
|
||
每次设计和实现一个阶段叫做一个迭代。
|
||
|
||
在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度的小项目，被称为一系列的迭代。
|
||
|
||
每一次迭代都包括了需求分析、设计、实现与测试。
|
||
|
||
采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。
|
||
|
||
再通过客户的反馈来细化需求，并开始新一轮的迭代。
|
||
|
||
迭代开发是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。
|
||
|
||
迭代是开发有很多的有点，比如能降低风险，得到早起的用户反馈，能够持续的测试和集成等。
|
||
|
||
#### 敏捷模式
|
||
|
||
敏捷软件研发发又称敏捷研发，
|
||
|
||
作为一个整体工作，按短迭代周期工作，每次迭代交付一些成果，
|
||
|
||
相比迭代模式两者都强调较短的周期提交软件，但是敏捷模式周期更短，并且强调队伍的高度协作。
|
||
|
||
关于敏捷测试，大家可以看下图来辅助理解。
|
||
|
||
|
||
|
||
#### 简单区别
|
||
|
||
从技术特点上说：
|
||
|
||
- 瀑布模式简单，
|
||
|
||
分阶段，而且阶段间存在因果关系，但是不支持用户参与，要求预先确定需求；
|
||
|
||
- 迭代模式不要求一次性开发出完整的软件系统，能得到早期的用户反馈；
|
||
|
||
- 敏捷模式支持用户参与，能够适应用户需求的变化。
|
||
|
||
从使用范围上比较：
|
||
|
||
- 瀑布模式需求易于完善定义且不易变更的软件系统；
|
||
|
||
- 迭代模式适用于需求难以确定不断变更的软件系统；
|
||
|
||
- 敏捷模式适用于需求复杂难以确定，动态变化的软件系统。
|
||
|
||
### 技术架构
|
||
|
||
这里的技术架构，我们仅用来指代公司项目的项目结构。
|
||
|
||
在传统模式的公司中，或者一些公司的内部项目。
|
||
|
||
其实只有一个工程来实现后端所有的接口。
|
||
|
||
这样的项目，在我们测试的时候会比较好测试，毕竟只有一个项目，接口都在这个项目内。
|
||
|
||
我们只需要考虑测试用例的覆盖率，是否覆盖了所有接口即可。
|
||
|
||
而现如今很多公司，根据项目、模块、服务等维度，拆分了很多工程项目。
|
||
|
||
由这些工程项目共同组成公司的业务产业链。
|
||
|
||
这里大家听过最多的应该是微服务了。
|
||
|
||
这里我们为大家介绍两种架构。
|
||
|
||
#### **SOA（Service-Oriented Architecture）**
|
||
|
||
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，
|
||
|
||
并通过这些服务之间定义良好的接口和协议联系起来。
|
||
|
||
接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。
|
||
|
||
这使得构件在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
|
||
|
||
#### **微服务**
|
||
|
||
单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，
|
||
|
||
一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
|
||
|
||
面向服务的。将自己的业务能力封装并对外提供服务，
|
||
|
||
这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。
|
||
|
||
|
||
### 我们要做什么？
|
||
|
||
每一种架构，都有自己独特的测试风格、测试方法。
|
||
|
||
我们在测试的工作中，不仅仅需要掌握好我们测试的相关技能。
|
||
|
||
研发掌握的这些内容，我们也要多少了解一下，更好的完成我们的测试工作。
|
||
|
||
|
||
|
||
|