性能测试方案设计与测试过程
性能测试过程 性能测试计划 按照模板生成性能测试计划 指标设计（并发数、在线数、TPS、请求超时）挑选典型交易（20%交易，覆盖80%流量）环境、数据准备（与生产环境尽量一致）场景设计（基础场景、专项场景）测试进度安排 需求分析、调研 了解业务需求 环境、数据准备： 系统部署 真实含义的业务数据 数据量为生产数据量三年以后的数据量。 场景分析设计 挑选交易，典型交易：高频交易，逻辑复杂的交易，集中时间段的场景 单交易运行——>单交易负载场景 混合场景设计：混合容量设计，浪涌设计（20->100,100->20） 稳定性场景设计（48小时、72小时持续压力验证） 场景执行、应用监控 执行测试场景 问题定位、分析优化 分析问题 回归验证 性能测试报告 测试结果汇总形成报告 性能测试方案扩展引入多样化的性能监控工具（prometheus/JVM/pinpoint/skywalking）丰富性能场景设计（扩展性场景、可靠性场景、网络异常等情况）可持续性能压测(Jmeter进行自动化...
持续交付发布可靠软件的系统方法（交付生态圈）第十三章：组件和依赖管理
《持续交付发布可靠软件的系统方法》读书笔记 持续交付让应用程序处于随时可发布的状态。在大型重构或添加复杂功能时，要继续保持应用的可发布状态，需要对大型应用组件化。组件是指应用程序中的一个规模相当大的代码结构，它具有一套定义良好的API，而且可以被另一种实现方式代替。一个基于组件的软件系统，通常其代码库被分成多个相互分离的部分，每个部分通过有限的定义良好的接口提供一些服务与其他组件进行有限的交互。有人把组件称为模块。基于组件的设计是一种良好的架构，具有松耦合性。 保持应用程序可发布团队不断地增加新特性，可以给每次新特性创建新的分支，当新特性完成后，再将它合并到主分支。这将会导致合并周期变长，无法做到持续集成，这种方法不是最好的。提倡每个人都应该提交到主干。可是这样又该如何保证主干一直保持可发布状态呢？有如下四种策略： 将新功能隐藏起来，直到它完成为止。一种方法是把新功能直接放进主干，但对用户不可见，比如通过单独的URL来访问，通过Web服务器配置不允许访问其入口；另一种方法是通过配置项开关来管理。把功能半成品与系统其他部分一同发布是一个好实践。 将所有的变更都变成一系列的增量小修...
持续交付发布可靠软件的系统方法（交付生态圈）第十一章：基础设施和环境管理
《持续交付发布可靠软件的系统方法》读书笔记 基础设施与环境管理的目标是让所有测试环境（包括持续集成环境）都要与生产环境相似，特别是它们的管理方式。环境是指应用程序运行所需的所有资源和它们的配置信息。有如下这些属性：组成运行环境的服务器的硬件配置信息：如CPU类型和数量、内存大小、硬盘和网卡等；应用程序运行所需要的操作系统和中间件：如消息队列、应用服务器、web服务器及数据库服务器等的配置信息。基础设施代表了所在组织中的所有环境以及支持运行的所有服务，如DNS服务器、防火墙、路由器、版本控制库、存储、监控、邮件服务、日志服务等。准备部署环境及管理它，要基于以下原理，用一个整体方法来管理所有基础设施： 使用保存于版本控制库中的配置信息来指定基础设施所处的状态 基础设施应该具有自治特性，即它应该自动地将自己设定为所需状态 通过测试设备和监控手段，应该时时都能掌握基础设施的实时状况 基础设施还应该具有非常容易重新搭建的特性 为了减少在类生产环境中的部署风险，需要精心管理以下内容: 操作系统及其配置信息，包括各个环境 中间件软件栈及其配置信息，包括应用服务器、消息系统和数据库 基础设...
持续交付发布可靠软件的系统方法（交付生态圈）第十二章：数据管理
《持续交付发布可靠软件的系统方法》读书笔记 应用程序可以通过删除前一个版本，使用新版本替换旧版本的方式部署，但是大多数系统，数据无法使用这种方式进行变更，一旦某个系统发布到了生产环境中，关联的数据将不断增加。数据往往是系统中最有价值的部分。当我们需要对数据系统进行结构修改或者内容修改时，就需要相关的策略。对数据的修改是不可避免的，关键在于将数据迁移过程自动化。目前有一些工具对数据迁移提供了较多支持，它们还允许对数据库进行版本化管理。另一个重要部分是测试数据的管理。 数据库脚本化任何数据库的修改都应该通过自动化过程来管理。包括数据库的初始化，数据库所有的迁移都需要脚本化，并将脚本提交到版本控制库中。几乎所有的数据管理系统都支持通过自动化脚本进行数据存储的初始化工作。 清除原有的数据库 创建数据库结构、数据弯路实例以及模式等 向数据库加载数据 在大多数据项目中，数据库的使用要复杂得多。 增量式修改绝大多数据系统，对数据库更新时，要保留它们的数据。由于在部署时需要保留数据库中的已有数据，所以需要有回滚策略，以便部署失败时使用。这就需要对数据库进行版本控制。 在数据库中创建一个数据...
持续交付发布可靠软件的系统方法（_交付生态圈）第十五章：持续交付管理
《持续交付发布可靠软件的系统方法》读书笔记 实现持续交付不仅仅是搭建一些工具，做一些自动化的工作，它依赖于交付过程中的每个人的协作。通过持续交付实践，可以快速且可靠地交付新版本。 配置与发布管理成熟模型 这个模型的最终目标： 缩短生产周期 减少缺陷 提高软件交付生命周期的可预测性 规范合规 有效发现和管理软件交付相关风险 交付更少缺陷的软件，降低成本 模型指导组织推进持续交付变革，使用戴明环，即计划——执行——检查——处理。 使用模型来分析所在部门的配置与发布管理模式 选择一个领域集中发力，该领域是你的薄弱环节，痛点所在 实施变革。先创建一个实施计划，选择真正感到痛苦的那部分人 一旦发生了变化，使用之前创建的验收条件来衡量这些变化是否达到了预期效果。组织所有相关人员召开回顾会议，找出改进点及潜在改进领域 重复上述步骤，积累知识，增量改进，推广到整个部门 项目生命周期团队的组建与磨合常常有以下五个阶段：创建期、风暴期、规范期、运转期、调整重组期。软件也有五个阶段：立项阶段、启动阶段、初始阶段、开发部署阶段、运维阶段。 立项阶段：业务分析、业务负责人及涉及部门有关人确立 启...
持续交付发布可靠软件的系统方法（基础篇）第一章：软件交付的问题
《持续交付发布可靠软件的系统方法》读书笔记 软件构成部分：可执行的代码、配置信息、运行环境、数据 不同环境下只进行一次编译 对环境的任何修改都应该作为配置信息管理，配置信息的更改都需要经过测试 如果运行环境需要修改，则修改后的环境也需要进行测试。环境包括：操作系统配置、应用程序依赖的软件集、网络配置及任何基础设置、外部系统 数据结构发生变化，同样需要经过测试 反馈流程：指完全以自动化的方式尽可能地测试每一次变更 创建可执行代码的流程 单元测试 质量检测：测试覆盖率以及其他与技术相关的度量项 功能测试验收 性能、有效性、安全性等非功能测试 探索性测试，给客户/最终应用演示 自动化测试反馈【commit阶段】 运行速度快 尽可能全面，75%代码库覆盖率 环境中立，相对生产环境简单廉价 如果出现问题，绝不发布【commit之后测试】 运行速度慢一些，适合并行执行 即使有些测试问题，也可以发布应用程序 运行环境尽可能与生产相同 不同版本、不同环境的配置放在版本控制中 开发人员都拥有自己的专属开发环境 无论部署在什么目标环境都应采用同一种部署方法 开发环境是特例，可以有多...
持续交付发布可靠软件的系统方法（基础篇）第三章：持续集成
《持续交付发布可靠软件的系统方法》读书笔记 持续集成要求每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合，一旦出现问题，开发团队应停下手中的工作，修复问题。持续集成的目标是：让正在研发的软件一直处于可工作的状态。 实施持续集成的先决条件 版本控制，与项目相关的所有内容都必须提交到一个版本控制库中（产品代码、测试代码、数据库脚本、构建与部署脚本、以及所有用于创建安装运行和测试该应用的程序的东西） 自动化构建：必须满足人和计算机都能通过命令行自动执行应用的构建、测试以及部署过程 团队共识：持续集成是一种实践，需要团队所有成员都遵循规则 一个基本持续集成系统 第一次在持续集成工具上执行构建时，可能会缺少一些必须的软件及配置，请将所操作的工作记录下来，并放在自己项目的知识共享库中，应花一些时间将应用程序所依赖的所有软件和配置项提交到版本控制系统中，并将重建全新环境的整个活动变成一个自动化的过程 查看一下是否有构建正在运行，如果有，等它运行完。如果它失败了，则与团队其他人一起将它修复，后再提交自己的代码 一量构建完成且测试全部通过，就从版本控制库中将该版本的代码更...
持续交付发布可靠软件的系统方法（部署流水线）第七章：提交阶段
《持续交付发布可靠软件的系统方法》读书笔记 提交阶段的运行应该少于5分钟，一定不要超过10分钏提交阶段的首要目标是创建可部署的产物 提交阶段的原则与实践 提供快速有用的反馈 何时令提交阶段失败 编译错误 测试失败（包括单元覆盖率低于60%） 精心对待提交阶段 提交阶段中有构建用的脚本和运行单元测试、静态分析等脚本。 随着项目的进行，不断改进提交阶段的脚本的质量、设计和性能 确保将脚本做成模块化，将那些经常使用且很少变化的常见任务与需要修改的任务分开 将部署流水线中不同阶段所用的代码分别写在不同脚本中 不要写出与具体环境相关的脚本，即要把具体环境配置与构建脚本分离 让开发人员也拥有所有权如果必要的话，即使是很普通的变更也都应该由开发人员和运维人员来执行 在超大项目团队中指定一个构建负责人 监督和指导对构建的维护 鼓励和加强构建纪律 在团队开始接触持续集成时，构建纪律还没建立起来时，提醒作用 团队成员轮流当，比如每星期轮换一次 提交阶段结果提交阶段的输入是源代码，输出是二进制包和报告（测试结果和代码分析报告） 制品库 制品库仅保存某些版本，而不是全部。如果在部署流水...
持续交付发布可靠软件的系统方法（交付生态圈）第十四章：版本控制进阶
《持续交付发布可靠软件的系统方法》读书笔记 版本控制用来维护应用程序每次修改的完整历史，包括源代码、文档、数据库定义、构建脚本和测试等。团队可以在一个代码版本控制库上一起开发应用程序的不同部分。一旦团队人数超过一定数量，就需要规划版本控制库的使用，让开发更加高效。 分支与合并分支，即为选择的基线创建一个副本，该副本与原基线相互独立，开发者能在两个工作流上同时开发。团队为什么使用分支？ 物理上：系统物理配置而分支，即为文件、组件和子系统而分支 功能上【最常见】：系统功能配置而分支，即为特性、逻辑修改、缺陷修复和功能增加，以及其他可交付的功能而分支 环境上：系统运行环境而分支，即由构建平台和运行时平台的不同而分支 组织上：团队的工作量而分支，即为活动/任务、子项目、角色和群组而分支 流程上：团队的工作行为而分支，支持不同规章政策、流程和状态而分支 在开发中，经常会遇到分支合并的情况，除非那些为了发布或者技术预研而创建的分支。两次合并时间间隔越长，每个分支上工作的人越多，合并发生冲突的可能性就越大。以下两种方法来减小冲突： 创建更多的分支来减少在每个分支上的修改。这只是...
持续交付发布可靠软件的系统方法（基础篇）第四章：测试策略的实现
《持续交付发布可靠软件的系统方法》读书笔记 项目在一开始阶段，测试人员就会与开发人员及客户一起写自动化测试。这些测试应该在开发前就写好。以上这些测试仅仅是系统进行功能测试，容量、安全性及其非功能性试也应尽早建立，为它们写自动化测试套件。确保不符合需求的问题尽早暴露。 业务导向且支持开发过程的测试在开发一个用户故事之前，应写好验收测试，采取完美的自动化形式。系统的验收测试应运行在类生产环境（UAT)验收测试有价值的特性： 它加快了反馈速度 减少了测试人员的工作负荷 让测试人员集中精力做探索性测试和高价值的活动 这些验收测试也是一组回归测试套件 行为驱动开发，可以以这些测试中自动生成需求说明文档 并不是所有的东西都需要自动化。我们倾向于将自动化验收测试限于完全覆盖Happy Path的行为，并仅覆盖其它一些极其重要的部分。每一种测试都应该覆盖应用程序的80%验收测试一般都是端对端测试，但是这样很多时候验收测试的失败并不是因为真正的缺陷，而是因为界面的变更，这将导致增大了验收测试脚本的维护。有两种方法解决这个问题： 在测试与用户界面之间增加一个抽象层，以便减少因用户界面变更而...