王烨超,福建seo学校,如何在电脑上建立网站,观影楼网站第一章 对软件测试的全面认识#xff0c;测试不能是穷尽的 软件测试的作用#xff1a; 1.产品质量评估#xff1b;2.持续质量反馈#xff1b;3.客户满意度提升#xff1b;4.缺陷的预防 正反思维#xff1a;正向思维#xff08;广度#xff0c;良好覆盖面#xff09;逆…第一章 对软件测试的全面认识测试不能是穷尽的 软件测试的作用 1.产品质量评估2.持续质量反馈3.客户满意度提升4.缺陷的预防 正反思维正向思维广度良好覆盖面逆向思维深度提升效率狭义到广义动态测试狭义编程之后介入测试动静广义贯穿全程基于质量产品质量质量模型使用质量基于风险测试的持续性工作有侧重2/8原则基于社会性思维能力和探索能力理解用户基于经济以最小代价获得更高收益基于标准验证v模型有效性确认基于Test Oracle检验已知的试验未知的基于批判性思维不断地质疑传统与敏捷模型瀑布模型传统敏捷侧重迭代式与增量型更关注产品本身快速交付
第二章 强调测试是全阶段的DevOps就是推动左移右移的完整链条 测试左移与右移左移是提前介入测试右移是将测试延伸在线测试等测试驱动开发TDD测试优先左移编码在后缺陷预防传统研发模式的测试环分阶段单元集成测试同时进行敏捷研发中的测试环测试融入全程DevOps 与测试打通开发、运维与测试各环节自动化和监控形成生态链。
第三章 测试的基础设施测试工具机器、网络、自动化框架、DevOps工具链 虚拟机与容器技术早期是物理机器虚拟机搭建整体架构容器通过命名空间隔离(更小基础设施即代码 Iac价值体现在环境维护成本、速度和风险持续集成环境 CI自动构建、部署、验证、发布结果供浏览自动化测试框架分不同层次单元、接口、系统DevOps完整工具链构建、测试、工件管理、部署、评估
第四章 个体与团队 个体需要在技术上挖掘深度如某个技术栈的深度 团队 测试3个发展方向技术管理、业务专家、测试开发/专线测试软件测试的系统性思维关注软件质量模型、关注自己的测试质量、效率、缺陷命中率、交付质量、非功能性缺陷可度量分析性思维、批判性思维、创造性/发散性思维软件测试要素思想、方法、方式、技术、流程、管理等敏捷测试关注的能力DepOps对测试的影响测试要快、测试自动化大挑战、业务测试、少量专业测试测试教练、顾问、QA、测试开发SET受宠
第五章 项目启动的准备 产品使用质量模型产品质量模型了解项目背景重要元素项目的目标、交付物、质量要求、范围、进度、可用的资源(开发)团队、开发环境、相关利益者。了解产品元素主要从结构、功能、数据、平台、操作、时间等方面分析。采用合适的测试技术/方法方法有很多要根据每种方法的应用场景以及技术特点来划分。主要为 基于直觉和经验的方法 基于输入域的方法。 组合测试方法。 基于逻辑覆盖的方法。 基本路径测试方法。 基于故障模式的测试方法。 基于模型的测试方法。 模糊测试方法。 基于场景的测试方法。 不同的开发模式就有不同的测试实践如敏捷开发中应该采用更适合敏捷的测试实践。确定测试规范主要从以下几个方面角色的确定进入准则输入项活动过程输出项评审与评估退出准则度量。
第六章 测试需求与测试计划的考虑 计划是一个持续的过程在制定计划前要明确测试的目标既要有优先级又要从测试和业务的角度全面分析如功能、非功能、依赖于项目的特性问题等 根据测试的范围和任务去估算测试的工作量根据一个公式 W代表工作量人时 Rx代表第x轮测试的程度 R是递减的如90% 70% 50% 其中W可以通过“工作分解结构表”WBS任务分解 通过对测试任务一层层细分工时 直到不能分解来计算 测试里程碑敏捷测试 1测试任务定义2测试计划制订和评审通过。3测试需求或测试点 (或测试场景)列表制定4评审通过验收测试结束。测试风险 风险识别的有效方法是建立风险项目检查表按风险内容进行逐项检查 风险检查表 人员风险、环境风险、测试范围(广度)、测试深度、回归测试、需求变更、用户期望、测试技术、测试工具 风险管理风险评估风险控制
第七章 测试用例设计思想、方法和组织角度 从需求到测试用例“从需求、功能特性、用例 (用户故事)到场景、测试数据/条件等” 从用户的需求到使用的场景用户可能会进行的操作来思考可以查缺补漏到一些特殊场景。 基于SUT被测系统结构设计“层次很清晰有业务逻辑层、具体数据层” 设计测试用例需要考虑的因素 1、测试需求目标包含功能性和非功能性。 2、用户实际使用的场景贴近用户更正确。 3、软件功能需求规格说明书、产品设计文档等 描述方式、文档是否详细等。 4、测试的方法对测试用例的设计影响大白盒测试和黑盒测试的思路方式不同。 5、被测试对象被测对象是客户端还是服务端侧重点是不同的。 如何运用测试设计方法 1.测试设计服务测试目标首先用例上3个程度的覆盖20%高优80%基础尽可能覆盖 从代码角度的覆盖 2、可以通过数据流、控制流层面做到覆盖 3、灵活运用多种测试方法如白盒的基本路径覆盖、逻辑覆盖、等价类划分、边界值分析等 非功能性测试如何设计更多的单独后几章讲此处特指本地故障转移 探索性测试没有设计吗处于流程完善性考虑人们提出了基于会话的测试管理方法 基于会话顾名思义就是把一次会话设定为一次不被打扰的进程通过角色扮演的方式实际以用户角度的具体场景进行测试 测试用例的规范性与评审 1、规范性从5W1H上看构成why what when where which how 2、评审建立checkList通过各方面提问模式查缺补漏 测试集的创建 通用的三种测试集的方式 1、按照程序的功能模块组织 2、按照测试用例的类型组织 3、按照测试用例的优先级组织 根据这三种可得出大致框架
第八章 测试的执行与探索型测试 缺陷及缺陷报告 测试的执行过程是立体的前半段强调测试效率、侧重发现缺陷后半段重点是降低风险、系统地覆盖测试范围。 测试的执行的准备 1、测试任务安排预估时间和工作量任务估算分析软件模块之间的关系将关联性很强的若干个 (子)任务安排给一个人不同的阶段可以适当交叉互换测试人员。 2、测试环境建立与配置 开发一个测试环境审计工具自动检查环境的配置项是比较彻底。如果没有就建立一个环境检查表 (Checklist)靠人工逐项检查。测试自动化平台运行要对结果进行分析失败的话 是脚本需要维护还是缺陷3、有效的创建测试集 功能测试会经历以下几轮不同的测试执行阶段 新功能的快速测试。完整的功能性测试并集中在逻辑性、行为方面的测试界面、适用性测试。探索式测试和回归测试。测试集可以按照下列不同维度(功能模块、测试用例优先级、新功能和回归测试、手工测试与自动化测试等)去构建。4、敏捷测试的执行 敏捷开发最有价值的目标持续交付。更依赖于自动化测试。 5、用户体验和易用性7元素符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性 6、回归测试策略兼顾效率和风险 常见的策略 (1)再测试全部用例 (2)基于风险选择测试。风险系数大的优先级高 (3)基于操作剖面选择测试。如从用户角度按照82原则2的优先级高 7、缺陷报告好处加快缺陷的修正、产品的质量评估、预防缺陷 更有效的缺陷报告需要使用简单、准确、专业的语言来抓住缺陷的本质提供了如何复现当前缺陷的所需信息 (包括截图、Trace log 等)。 缺陷属性
第九章 不收尾的测试用户验收、部署验证、在线测试 验收测试传统意义上是和用户一同验收也称交付测试 1、如今验收测试不一定是最后一项测试因为我们还可以进行上线后的测试在线测试。 2、alpha测试a测试戏称“吃自己做的狗食”指在公司内部试用。 beta测试让少数用户/合作伙伴使用反馈。 3、验证list产品规格说明书、用户环境和准则。 4、实际实践中的验收主要是“产运”验收标准大多以‘P0/P1case’为准而UI部分在客户端类型也是重要的一环我们不做验收标准。 部署验证主要针对于客户端类B/S架构的部分存在需要安装插件等 1、安装前考虑测试环境至少准备两种一版之前安装过一版之前从未安装过同时也要考虑两种不同的安装方式先卸再安、直接覆盖安。 2、安装测试中严格按照PRD此外注意容错性、灵活性、占用过多资源等问题。 3、安装结束检查是否达标正常运行。 4、后台系统的部署验证相比客户端会更复杂特别注意系统配置 、配置项选择、配置项组合等 对于我们主要是要注意部署前Apollo的check以及是否存在多个版本并存的问题 在线验证在真实环境上操作 1、产品工程发布的后续过程 1-1、LALimited Available有限可用 1-2、GAGeneral Available全面可用 2、出现有效的线上问题应仔细分析 是否是对需求不清楚、是否确实对应使用情景与case、若有case是否环境错误/case遗漏、回归测试是否不充分等。 通过日志分析Linux的登录日志、移动 App 日志、Web 服务器 Access Log等由于日志数量巨大 需借助一些日志查询工具 ES具有索引自动分片、索引副本机制、restful 风格接口、多数据源、自动搜索负载等功能。 测试过程中评审
1、并非等测试结束后再评审复盘而是在测试过程中发现问题及时纠正。结合测试计划、测试效果了解测试过程是否规范、是否按期进行等
2、与团队成员进行交流每日的早站会与开发人员直接沟通更早的发现情况
具体量化如到目前为止还没有被关闭的缺陷数、每天开发修正的缺陷数、每天关闭的缺陷数等。 团队反思持续改进 1、以用户为中心谁是用户用户关心哪些问题忽视了哪些问题 2、根因分析是什么问题→造成问题的根本原因→找到解决问题的措施 3、数据驱动应该将数据作为分析手段 而非数据驱动目标以价值为导向引领方向更为准确 收集相关测试质量数据可以采用鱼骨图进行分析 4、PDCA循环闭合的、具有螺旋上升的特性 PDCA 是一个用于持续改进的简单但有效的模型代表由计划 (PIan)、执行(Do)、检查(Check)和行动(Action)构成的一个循环过程如图所示。
第十章 引入静态测试从而实现“测试左移(Left Shift)” 重点是“审查“ 常用的评审方法 在不同阶段各种评审方法是交替使用的比如我们的需求初评、需求终评、技术反讲、用例评审等。 常用的技术与工具 需求评审的优秀实践 1、需求评审是软件开发的源头需求评审是做好软件测试需求分析、测试计划和测试设计等工作的基础。 主要考虑以下几点 对软件需求进行正确性的检查以发现需求定义中的问题尽早地将缺陷发现出来降低成本并使后续过程的变更减少降低风险。 并且及时沟通后达成对需求认知的一致性。 2、需求评审标准 主要包含正确性、完备性、易理解性、一致性、可行性、易修改性、可测试性、可追溯性。 完备性主要涵盖涵盖系统需求的功能、性能、输入/输出、条件限制、应用范围等方面。 可追溯性对需求的背景以及存在的理由进行追溯每一项需求定义是否可以确定其来源 3、需求评审方法 4、需求的可测试性在敏捷开发中尤为重要因为对文档的投入较少不够重视文档质量堪忧 需求描述简单容易造成理解偏差需要对需求增加一个验收标准。—验收测试驱动开发ATDD 系统架构的审查os至少目前感觉用不太上 1、软件体系结构一般可以分为客户机/服务器 (C/S) 结构、浏览器/服务器 (B/S)结构和中间件多层结构等也可以分为集中式系统、分布式系统 (如 Cloud、微服务系统)和对等的 P2P 系统(如区块链、以太坊等平台)等还可以分为实时同步系统、异步系统等。 2、设计技术的评审标准 结果的稳定性清晰性高内聚、低耦合低复杂度。 3、非功能性质量特性的设计评审要求安全性、性能、稳定性、扩展性、可靠性。 4、保证设计的可测性 可观察性、可控制性组成的可以考虑增加可预见性。 可观察性(Observability): 在有限的时间内使用输出描述系统当前状态的能力。 可控制性(Controllability ): 在特定的合理操作情况下整个配置空间操作(改变)系统的能力包括状态控制和输出控制。 可预见性(Predictability): 预测系统状态发生变化的能力。 PRD设计规格说明书的复审 PRD的审核应该在整个生命周期的初期非常重要是测试的标准可能会灵活性调整测试人员要想到并且针对变化不断调整计划和方法。 1、编写方式3种 采用良好的结构化和专业语言编写文本型文档。 建立图形化模型这些模型可以描绘系统状态及其之间的变化、转换的过程、数据字典及其关系、逻辑流或对象类及其之间的关系。 编写形式化规格说明通过使用数学上精确的形式化逻辑语言来定义系统设计 2、多层次审查 系统部署设计的审查 代码评审与静态分析 1、如前文所述代码的评审通常采用互查peer review关键代码采用会议评审Inspection方式。 2、有研究表明代码评审会不仅不会降低整个开发效率还会使缺陷率降低15-50% 3、每个公司/团队都有自己的编程规范建立相应的代码评审检查表也可使用相关静态代码检查工具如FindBugs
【OS】
第十章的内容有一些我可能接触不到做一些了解但是在需求评审这里确实是日常需要重视的地方尤其是敏捷开发的特性更需要测试人员去思考补全PRD需求是验收的标准对保障测试质量至关重要。
另一个是代码评审对关键代码/有隐患的应推动MR提前预防。
第十一章 强调全生命周期的性能测试 常见的性能问题 如何确定系统的性能需求 1、新系统“性能基准测试”作为下一版本的基准。 2、需要优化时负载测试“压力测试”、“容量测试”更快的找到性能瓶颈。 3、不同配置下获得性能数据“性能规划测试”可验证系统的可伸缩性。 4、关键指标分析 5、关键业务分析 结合“2-8原则”操作频率和操作计算量、对资源的需求和依赖等。 如搜索-下单-提交订单-支付 搜索频率可能有95%后者是5% 但订单和支付关联的数据多、对数据库的读写操作和支付相关外部接口往往会成为系统的瓶颈。 如何完成性能测试的设计 1、模拟用户操作 2、“负载”可定义为并发用户数 并发用户数并发连接数 请求数据量 思考时间 3、有效模拟加载过程 负载模式的三阶段启动、持续进行、结束 不同的加载模式 我们通常使用的是 递增加载通过阶梯分段逐步达到目标。 【os】在线上真实环境测试阶梯模式在实际性能测试中会更可控。 4、实时准确控制加载同步点“集合点” 同步点就是用于同步虚拟用户恰好在某一时刻执行任务确保众多的虚拟并发用户更准确集中进行某个设定的操作。注意同步点也是“相对”的即使设置同步点 大操作量也无法在几毫秒内完成可能需要几百毫秒但不设置则需要几秒或者几十秒。如何执行性能测试 1、工具Jmeter、Locust、Gatling、Tsung、Flood等 2、工具的具体结构组件 3、组件顺序 1、配置元件 2、逻辑 3、前置 4、定时器 5、取样器 6、后置 7、断言 8、监听 如何分析和评估测试结果 1、借助监控数据分析关键数据 2、对数据分析定位问题 通过关键指标反映问题主要从资源cpu 内存 磁盘和DB相关分析 3、全程性能测试示意图
