验收测试

什么是 开发环境、测试环境、生产环境、UAT环境、仿真环境 开发环境 ：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。 测试环境 ：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。 生产环境 ：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。 三个环境也可以说是系统开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。 UAT 环境 ：UAT，(User Acceptance Test),用户接受度测试 即验收测试，所以UAT环境主要是用来作为客户体验的环境。 仿真环境 ：顾名思义是和真正使用的环境一样的环境（即已经出售给客户的系统所在环境，也成为商用环境），所有的配置，页面展示等都应该和商家正在使用的一样，差别只在环境的性能方面。 系统内部 集成测试 (System Integration Testing) SIT 用户 验收测试 (User Acceptance Testing) UAT SIT在前，UAT在后，UAT测完才可以上线。 SIT是 集成测试 UAT是 验收测试 从时间上看，UAT要在SIT后面， UAT测试 要在 系统测试

在DevOps中，你可能经常会听到类似这样的一些话： 功能还没集成进来。 功能还没部署上去。 功能还没交付。 功能还没上线。 功能还没发布。 请问，以上“集成”、“部署”、 “交付”、“上线”、“发布”这几个概念，表达的是同一个意思吗？如果不是，它们有什么区别呢？ 我相信大多数人都会为此而迷茫，本人也常常被这几个术语搞晕。 也许你会说，上面的例子太简单，难于判断。好吧，下面再给你一些更多的例子（均来自DOM【DevOps Master，简称DOM】认证课程的权威教材）： 还要再花几天才能把这个新版本发布到UAT环境中。 上次发布新版本到生产环境时，你花掉了整个周末的时间。 一行代码的改动需要花多长时间才能部署上线。 每次提交代码都可能产生一个可发布的版本。 很多公司都会在一天内发布很多次。 遵循极限编程的座右铭：如果它令你很受伤，那么就做更多的练习（If it hurts, do it more often）。合乎逻辑的极限就是每当有版本通过自动化测试之后，就将其部署到生产环境中。这种技术叫做“持续部署”，Timothy Fitz发明的一个术语。 持续交付指的是应用程序的构建、部署、测试和发布的自动化流程。 由良好的金丝雀发布系统提供的这层安全网让持续部署的风险甚至更小。 有些人反对持续部署，在直觉上，这么做的风险太高。但如前所述，越频繁的发布会让发布风险越低。 根据我们的经验

一、测试阶段也称测试级别 单元测试 集成测试 系统测试 验收测试 1.组件测试 也称单元测试 （1）单元是软件里最小的、可以单独执行编码的单位，通常由一人完成编程。 （2）对于采用流程语言（如C、VisualBasic等）的设计的软件，单元可以由一个或若干个最接近的函数或过程所组成。 （3）对于采用面向对象语言设计的软件，单元可以是一个类或类的实例，或者由方法来实现的功能。 （4）对于网页或用户窗口界面，单元可以是一个文字输入窗口或一个按钮等。 （1） 驱动器 是通过接口与测试对象通讯的辅助工具。用于调用被测试的组件或系统替代性程序。 （2）桩模块 桩用于替代或模拟那些还没有完成的组件（模块），用于模拟输入和输出（针对不完整的功能）。 （3）模拟器 用一个系统来描述另一个要测试的抽象系统的行为特征。 2.集成测试 1.集成 把组件/系统合并为更大部件的过程 2.集成测试 一种旨在暴露接口以及集成组件/系统间交互时存在的缺陷的测试。 3.有多种集成类型，如： （1） 组件集成测试 测试的目的在于发现接口和集成后组件间协同工作的缺陷。 （2） 系统集成测试 测试系统和其他软件包的集成： 例如，与商务标准软件的集成； 测试与外部系统的接口和交互： 例如，电子数据的交换、网络。 单元测试通常是单人执行，而集成测试通常是多人执行或第三方执行 4.集成测试的策略 （1）自顶向下集成 （2

测试过程 类型：新建产品、运维产品 测试过程：测试计划、测试用例、单元测试、集成测试、系统测试、验收测试、线上验证 系统测试 人员：测试工程师、需求分析师、运维工程师 工具：ITMP 验收测试 人员：用户（需要测试和需求人员准备验收测试用例） 线上测试 性能测试 性能测试修复和优化 来源： https://blog.csdn.net/ZZQHELLO2018/article/details/100972131

软件产品开发流程： 下图所示的是一个软件产品开发大体上所需要经历的全部流程： 1、启动 在项目启动阶段，主要确定项目的目标及其可行性。我们需要对项目的背景、干系人、解决的问题等等进行了解。并编制项目章程和组建项目团队，包括：产品经理、架构工程师、UI工程师、开发工程师、测试工程师等。 完成以上准备工作之后，召开项目启动会，启动会结束则进入下一步的工作。 2、规划 在项目的规划阶段，项目经理需要和项目需求方，以及项目的相关干系人确定项目的范围，创建WBS，确定项目的里程碑和项目计划。同时制定项目的管理计划，包括成本、质量、风险等方面的预测和控制方案。 3）需求 在需求阶段，需要对采集的需求进行需求分析，编写PRD文档、UI设计、高保真设计。 最后进入需求评审，评审通过则进入下一步的工作 4）设计 在设计阶段，设计人员根据需求文档，对软件系统进行设计，包括数据结构、系统架构、业务模型及规则、流程控制、模块接口等。 输出概要设计，详细设计文档，以及数据库设计说明书等。 5）开发 在明确需求后，开发工程师正式进入编码阶段，根据产品原型图、UI效果图、设计文档，选择合适的开发环境、开发工具、开发语言等等进行实现，这个阶段也是个很长很难的阶段，也是软件实现的核心。 6）功能测试 对软件进行测试是保证软件质量的重要手段。开发工程师开发完成后，可以交由测试工程师测试

单元测试 ： 单元测试：完成最小的软件设计单元（模块）的验证工作，目标是确保模块被正确的编码，使用过程设计描述作为指南，对重要的控制路径进行测试以发现模块内的错误，通常情况下是白盒的，对代码风格和规则、程序设计和结构、业务逻辑等进行静态测试，及早的发现和解决不易显现的错误。 集成测试 ：集成测试：通过测试发现与模块接口有关的问题。目标是把通过了单元测试的模块拿来，构造一个在设计中所描述的程序结构，应当避免一次性的集成（除非软件规模很小），而采用增量集成。 自顶向下集成 ：模块集成的顺序是首先集成主模块，然后按照控制层次结构向下进行集成，隶属于主模块的模块按照深度优先或广度优先的方式集成到整个结构中去。 自底向上集成 ：从原子模块开始来进行构造和测试，因为模块是自底向上集成的，进行时要求所有隶属于某个给顶层次的模块总是存在的，也不再有使用稳定测试桩的必要。自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块） 系统测试 ：系统测试

下面继续本书第四部分的读书笔记部分 第四部分 开发中的调试和测试思想 　　第8章 调试；第9章 敏捷开发模式下的测试 第9章 敏捷开发模式下的测试 　　随着市场竞争的日趋激烈，今天的商业项目需要不断缩短发布时间，同时还要不断地为客户提供高质量的产品。而老一套的开发模式很难适应当今的竞争环境，所以有一些开发人员就开始讨论轻量化和快速的开发方法。这就是著名的《敏捷软件开发宣言》，这份宣言没有僵化的开发方法和复杂的技术结构，而更像是一份针对客户和开发个体的箴言警局。 1、敏捷开发的特征 　　从敏捷软件开发宣言可以发现敏捷开发的一些特征： 　　（1）客户参与 　　　　围绕以客户需求为导向的开发过程，需要让客户尽早参与到开发周期中，并一直到其结束；如果没有客户参与，敏捷开发等同失败，这时可以选择传统的开发流程。 　　（2）迭代开发 　　　　敏捷开发提倡迭代式和增量式的开发模式。 　　（3）测试驱动 　　　　测试在其中发挥重要作用，依赖单元测试和验收测试（极限编程）。 2、敏捷测试的特征 　　敏捷测试要求每个人参与到测试计划的设计、实现及执行中去。客户通过定义用例集以及程序属性参与到定义验收测试的设计中来。开发者和测试者打造可以进行功能自动化的测试组件。敏捷测试要求每个人参与，需要有大量的沟通与协作工作。 　　（1）客户参与 　　　　在客户参与阶段，客户需要参与到开发周期来定义验收测试的设计。

什么是 开发环境、测试环境、生产环境、UAT环境、仿真环境 开发环境 ：开发环境是程序猿们专门用于开发的服务器，配置可以比较随意， 为了开发调试方便，一般打开全部错误报告。 测试环境 ：一般是克隆一份生产环境的配置，一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。 生产环境 ：是指正式提供对外服务的，一般会关掉错误报告，打开错误日志。可以理解为包含所有的功能的环境，任何项目所使用的环境都以这个为基础，然后根据客户的个性化需求来做调整或者修改。 三个环境也可以说是系统开发的三个阶段：开发->测试->上线，其中生产环境也就是通常说的真实环境。 UAT 环境 ：UAT，(User Acceptance Test),用户接受度测试 即验收测试，所以UAT环境主要是用来作为客户体验的环境。 仿真环境 ：顾名思义是和真正使用的环境一样的环境（即已经出售给客户的系统所在环境，也成为商用环境），所有的配置，页面展示等都应该和商家正在使用的一样，差别只在环境的性能方面。 系统内部 集成测试 (System Integration Testing) SIT 用户 验收测试 (User Acceptance Testing) UAT SIT在前，UAT在后，UAT测完才可以上线。 SIT是 集成测试 UAT是 验收测试 从时间上看，UAT要在SIT后面， UAT测试 要在 系统测试

一、什么是软件 软件是计算机程序、程序所用的数据以及相关文档资料的集合。 二、软件的定义 使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。 本书以及百度的定义：为了发现程序中的错误而执行程序的过程。 三、软件测试的目的 1）软件测试为了发现程序存在的代码或业务逻辑错误； 2）软件测试为了检验产品是否符合用户需求； 3）软件测试为了提高用户的体验。 四、软件测试的原则 1）测试应该尽早介入； 2）所有的测试都应追溯到用户需求； 3）程序员应该避免检查自己的程序。除了单元测试。因为程序员对于自己的作品，思维具有局限性。无法保证测试质量。交给第三方或者专业测试，运用各种测试技术，利用丰富的测试经验和对bug的敏感，去提高软件的质量； 4）设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下还要制造极端状态和意外状态。 5）二八原则，测试发现的错误中80%很可能起源于20%的模块中； 6）对错误结果要进行一个确认过程； 7）制定严格的测试计划； 8）完全测试是不可能的，测试需要终止； 9）妥善保存测试过程中的所有文档。 五、软件测试的对象 1）程序； 2）数据； 3）文档。 六、软件测试的分类 1）按测试执行阶段划分： 单元测试（开发人员）； 集成测试（开发或者测试人员）； 系统测试（测试人员）；

软件研发流程和质量 最常见软件开发模型：瀑布模型（v、w模型） 　　　　　　　　　　快速原型模型 　　　　　　　　　　敏捷开发模型 V模型 　　 需求分析、概要设计、详细设计、编码、单元测试（独立的模块测试）、集成测试（模块联调）、系统测试（整体流程）、验收测试（验证是否满足需求） 。 v模型的优点： v模型清楚地标识出了软件开发的各个阶段； 清楚地描述了测试阶段与开发过程各阶段的对应关系与开发同步（引入检测机制，需求分析做的好不好，看验收测试）；它采用自顶向下逐步求精的方式把整个开发过程分为不同的阶段，每个阶段的工作都很明确，因此便于控制开发过程：阶段划分清晰，方便工作的整体把控。 v模型的测试既包括了底层测试（检验源代码质量的测试：单元测试），又包括了高层测试（需求级的测试：系统测试）。 v模型的缺点： 它仅仅把测试过程作为需求分析，概要设计，详细设计，编码之后的一个阶段，容易让人理解为测试是软件开发的最后一个阶段； 和瀑布模型一样，流程也是单向的。到了测试阶段，程序已完成，错误已经产生，很多前期的错误一直到测试阶段才发现，甚至无法发现，往往无从修改了。 没有明确说明早期的测试，不符合越早测试和不断地进行测试的原则（用户需求对不对要到验收测试才能发现）。 W模型-双V模型 开发一个v，测试一个v，开发和测试并行。 开发V：需求分析、概要设计、详细设计、编码、集成、实施、交付。