软件的概念

错误观点：“软件就是程序，软件开发就是编程序”

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合；

程序是按事先设计的功能和性能要求执行的指令序列；

数据是使程序能正常操纵信息的数据结构；

文档是与程序开发，维护和使用有关的图文材料；

软件十大特性

形态特性：软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分对它确实毫无意义的。

智能特性：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决策问题；

开发特性：尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知识型工作充满了个人行为和个人因素；

质量特性：软件是个人编写的，由于其开发特性存在，所以不存在完全没有缺陷的软件；

生产特性：与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为有限；

管理特性：由于上面的特性存在，所以软件过程中的管理显得更为重要，相比传统行业，也更为独特；

环境特性：软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性；

维护特性：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大差别，维护体现在升级、优化、功能更新等方面，甚至可以全盘重构；

废弃特性：与硬件不同，软件并不是由于被“用坏”而被废弃的；

应用特性：软件的应用极为广泛，如今它已经渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位；

软件的分类

系统软件

系统软件是负责管理计算机系统中各种独立的硬件，使得它们可以协调工作；

服务性程序：如诊断程序、排错程序、练习程序等

语言程序：如汇编程序、编译程序、解释程序；

操作系统

数据库管理系统

应用软件

应用软件是为了某种特定的用途而被开发的软件，它可以是一个特定的程序，比如一个图像浏览器，也可以是一组功能联系紧密，可以互相协作的程序的集合；

软件生命周期

软件的生命周期，又称为软件的生存周期。它是按照按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段；

每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件；

余额宝的诞生

软件开发模型：

由于项目、需求的模式不同，所以在软件生命周期过程中选择的软件开发模型也会有所不同，在历史上，软件开发模型经历了“边做边改”、瀑布、原型、螺旋、敏捷等模式的变更；

瀑布模型：

计划===>需求分析 ===>设计 ===>编码 ===>测试 ===>运行维护

特点：

1. 软件开发的各项活动严格按照线性方式进行；

2. 当前活动接受上一项活动的工作结果。

缺点：

1. 由于开发模型是线性的，增加了开发的风险；

2. 早期的错误可能要等到开发后期的阶段才能发现。

原型模型：

客户与开发公司紧密联系，开发周期长，开发会受到需求变更的影响；

特点：

1. 实现客户与系统的交互；

2. 进一步细化待开发软件需求；

3. 开发人员可以确定客户的真正需求是什么。

螺旋模型：

制定计划 ===>风险分析 ===>实施工程（需求确认、软件需求、软件产品设计、设计确认与认证、详细设计、开发、测试） ===>客户评估

特点：

1. 螺旋模型是将瀑布模型与快速模型结合起来；

2. 强调了其他模型所忽视的风险分析；

3. 每一次螺旋包括4个步骤：制定计划、风险分析、实施工程、客户评估。

缺点：

1. 强调风险分析，但要求许多客户接受并相信这种分析，是不容易的；

敏捷模型：

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法；

特点：

1. 短周期开发；

2. 增量开发；

3. 由程序员和测试人员编写的自动化测试来监控开发进度；

4. 通过口头沟通、测试和源代码来交流系统的结构和意图；

5. 编写代码之前先写测试代码，也叫作测试先行。

重沟通 少文档

缺点：

1. 团队的组建较难，人员素质要求较高；

2. 对测试员要求掌握各种脚本语言编程，能执行单元测试、自动化测试。

PART3 软件开发文档

下面是必须的一些文档

3.7 阿里系开发模型的变迁

开发模型的变迁

最早期：边做边改=》稳定期：瀑布式=》发展期：敏捷=》创新期：DEVOPS

3.8 项目的一生

项目进程：

（1）编程阶段：单元测试(白盒测试)-测试参与其中

（2）编程完成：开发联调(集成测试)-开发为主

（3）提测-冒烟测试 (自动化为主，手工为辅) 测试执行

（4）测试阶段-系统测试(黑盒功能测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试)

（5）验收阶段-验收测试-测试配合用户或需求

3.9 软件的测试方法

软件测试概念：

经典定义：软件测试，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

标准定义：软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

软件测试的目的：

软件测试的目的在于发现问题，检查系统是否满足需求

生命周期各测试方法对比

3-11 软件测试常用术语

C/S：C指的是客户端(Client)，S指的是服务器端(Server)，这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。比如我们经常用的QQ、和各种网络游戏就属于C/S结构的软件。

B/S：B指的是浏览器(Browser)，S指的是服务器(Server)，这种软件同样是基于局域网或互联网的，它与C/S结构软件的区别就在于，不需要安装客户端(client)，只需要有浏览器，就可以直接使用。比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件，B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点。

缺陷【Bug/Defect】：软件的Bug指的是软件中(包括程序和文档)不符合用户需求的问题。

测试环境：软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。用一个等式来表示：测试环境=软件+硬件+网络

测试用例【Test Case】：在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。

用一个等式来表示：测试用例=输入+输出+测试环境

其中，"输入"包括测试数据和操作步骤，"输出"指的是期望结果，"测试环境"指的是系统环境设置

冒烟测试【Smoke Testing】：在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性

α测试：验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试

β测试：验收测试的一种，指的是内测后的公测，即完全交给最终用户测试

3-12 软件测试常见模型

V模型：V模型时我们熟知的瀑布模型的一种改进，瀑布模型将软件生命周期划分为计划、分析、设计、编码、测试和维护六个阶段，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以可能带来严重的后果。

V模型就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时开始，这两个并行的动态的过程就会极大地减少bug和error出现的几率。

W模型：一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

W模型是从V模型演化过来，实际上开发是V，测试是并行的V；相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动，W明确表示出了测试和开发的并行关系，测试与开发是同步进行的，有利于尽早地全面的发现问题。

其他模型-H模型：真正的测试级别之间不存在严格的次序关系，各阶段间可以反复触发、迭代、增量。

为了解决V模型和W模型存在的问题，有专家提出了H模型，它将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

其他模型-X模型：

3-13 软件测试覆盖率

测试覆盖率：覆盖率是用来度量测试完整性的一个手段，同时也是测试技术有效性的一个度量；

覆盖率=(至少被执行一次的item数)/item的总数

特点：

1. 通过覆盖率数据，可以检测我们的测试是否充分；

2. 分析出测试的弱点在哪方面；

3. 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加。

测试覆盖率对于黑盒测试来说，主要指两个方面：需求覆盖和用例覆盖

需求覆盖：

1. 定义：它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。

2. 计算公式：需求覆盖=(被验证到的需求数量)/(总的需求总数)。

用例覆盖：

1. 定义：主要体现在我们每轮测试验证通过的用例数在总用例中的比重；

2. 计算公式：用例覆盖=(验证通过的用例数量)/(总的用例总数)。

3-15 测试覆盖率的运用

简单的测试覆盖率：本次测试执行的用例数/所有用例数

上述覆盖率统计建立在认为总用例数编写全面，一般对于大型系统测试要求覆盖率100%

覆盖率的审核：抽样验收

基于产品的测试覆盖率： 已测试需求点/设计所有需求数

以产品、需求维度统计，无论大型项目或是小需求迭代都要求覆盖率达到100%

基于白盒的测试覆盖率： 大多工具判断语句覆盖，即单元测试代码覆盖代码行/总代码行

更多考察研发人员；更多时候要求覆盖率达到80%+

缺陷： 覆盖率数据只能代表测试过那些代码，不能代表是否测试好这些代码；容易遗漏逻辑、判断等场景；

基于自动化的测试覆盖率： 自动化覆盖的测试场景(测试用例)/所有测试场景(用例)

80/20原则，比如用户80%的时间在使用20%的功能，20%的功能就可以撑起用户最关键的业务场景，自动化测试的用例选择更着重与这20%的核心功能

用途： 自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计。

测试覆盖率的最终意义：

=》应用最多的地方在测试停止标准

=》单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试

=》在短迭代、DevOps中，更强调用单元测试覆盖率来评估不断增加的代码数量

3-15 测试团队的组织架构

3-16 软件测试人员必备

软件的测试的原则：

原则1：所有的测试都应追溯到用户需求

原则2：尽早的启动测试工作

原则3：Pareto法则应用于软件测试

原则4：穷尽测试是不可能的

原则5：杀虫剂怪事

原则6：前进两步，后退一步

原则7：三心二意

细心、信心、耐心

团队合作的沟通意识、时刻保持怀疑的态度且有缺陷预防意识

3-17 软件工程标准

国内通用的标准主要有ISO9000及CMM

ISO9000：

CMM：

软件测试规范：

测试系统主要有下面6个相互关联、相互作用的过程组成

4-1 软件测试环境搭建原则

搭建测试环境前：

（1）确定测试目的

（2）功能测试，稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点也不同

功能测试：不需要大量的数据，需要覆盖率高，测试数据要求尽量真实

性能测试：可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置

测试的软件环境尽可能的模拟真实环境

尽可能的模拟用户使用环境，选用合适的操作系统和软件平台

了解符合测试软件运行的最低要求及用户使用的硬件配置

了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间

产品化的测试则需要考虑兼容性的方案

营造独立的测试环境

不同的项目、不同的公司会对测试环境的独立性有不同的要求

测试过程中尽量保证测试环境独立，不会受到其他测试人员以及项目研发人员的影响

构建可复用的测试环境

通过备份或数据隔离的方式

重复运用一套测试环境进行多版本多时间段的测试

搭建测试环境过程分析

线下搭建

独立测试服务器或虚拟机

测试环境配置

测试项目导入

测试环境配置

配置java环境(下载jdk并配置环境变量)

下载并安装中间件(tomcat、jetty或其他)

安装数据库并导入初始化脚本

Docker模式

构建属于自己的image

依赖第三方平台（如蚂蚁金融云）

4-2 测试环境的建设落地

环境建设思路：

考虑点：用途、使用成本、维护成本

基本架构：

研发环境：用于研发自测、集成测试

测试环境：用于日常单系统或两两微服务之间测试，可同时集成自动化测试回归

联测环境：完备环境，用于大型联测

外联环境(如果有需求)：稳定版本环境，用于外部商户等联调

灰度/沙箱环境：用于生产数据测试，仿真测试

4-3 测试过程

4-4 测试策划概述

4-5 需求测试

需求测试实战

审查需求文档==》我们一起简单看下需求文档

余额理财产品需求文档

1 货币基金消费

投资人购买货币基金后，可直接通过货币基金金额进行支付购买商品或服务，货币基金可以视同余额、集分宝一样作为支付工具进行消费。

流程说明：

1. 用户在消费场景选择商品或服务并下单，进入收银台支付，此外包括标准收银台、快付收银台、暂不包括航旅收银台；

2. 如果用户的货币基金可用金额大于0，则在账户余额下方显示可用金额，单位为元，如果金额为0，则不显示；

3. 用户选择货币基金支付，点击使用，弹出浮层；

4. 浮层显示用户所有可用金额，和本次支付最多可用金额，默认支付最多可用金额，用户可进行修改，最大不能超过该金额，支持两位小数使用；

5. 货币基金金额可以跟其他支付工具(除了线下、现金方式)进行组合使用；

6. 用户输入支付密码后，实时扣除指定份数的货币基金，如果扣除失败，则显示失败的具体原因；如果扣除成功，将用户消费金额变成数据实时同步到用户资产，当前可用金额=交易前可用金额-消费金额，同时更新资产更新时间为当前时间；

7. 用户支付成功后，异步通知基金公司扣除该金额。

作者：憨憨老婆伍

原文链接：https://blog.csdn.net/hwinte/article/details/105974948