{"1": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术；软件测试全景图；系统地理解软件测试 测试用例；从就业市场看软件测试；在敏捷时代，如何看待软件测试？ 敏捷开发模式中，提倡整个团队对质量、对测试负责 开发与测试越来越融合，如微软测试人员转型 持续交付倒逼持续测试，但测试最容易成为瓶颈 测试左移、测试前移，让开发做更多的测试 测试驱动开发（ TDD ）：测试在前、开发在后", "如何借助这门课培养学生的分析问题和解决问题的能力？ 强调分析能力， 测试分析是基础 批判性思维，如探索式测试 工程思维，如找到不同的解决方案，从中选出最优的解决方案；如何通过实验教学培养学生的实际能力？ 软件测试是一门实践性很强的课程 做中学 问题驱动教学与实验 实验就是分析问题、解决问题的过程；软件测试方法和技术 2005 年出版，现在是第 版，十一五、十二五国家级规划教材，上海市普通高校优秀教材 300+ 所大学使用，销量超过 万册，过去连续三年获得清华大学出版社畅销书奖 本书共分三篇：软件测试的原理与方法、 软件测试 技术和 软件测试项目", "软件测试的原理与方法 章 引论 章 软件测试的基本概念 章 软件测试方法 章 软件测试流程和规范；软件测试方法和技术 章 引论；1.1 软件测试的必要性 1.2 为什么要进行软件测试 ？ 1.3 什么是软件测试 ？ 1.4 测试和质量保证的关系 1.5 测试和开发的关系 1.6 测试驱动开发的思想"]}, {"no": "1.1", "title": "软件测试的必要性", "paras": ["迪斯尼并不总是带来笑声 1994 年圣诞节前夕，迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏“狮子王童话” 圣诞节后的第一天，迪斯尼客户支持部电话开始响个不停，不断有人咨询、抱怨为什么游戏总是安装不成功，或没法正常使用 这个游戏软件只能在少数系统中正常运行 兼容性问题；一个缺陷造成了数亿美元损失 4195835 3145727 3145727- 4195835 = Intel 公司付出很大代价，回收 CPU ，造成 亿美元损失 浮点计算问题", "火星探测飞船坠毁 机械震动在大多数情况下也会触发着地开关，设置错误的数据位。设想飞船开始着陆时，计算机极有可能关闭推进器，而火星登陆飞船下坠 1800 米之后没有反推进器的帮助，冲向地面，必然会撞成碎片 两个小组本身的工作都没什么问题，就是没有合在一起测试，其接口没有被测，而问题就在这里 集成测试不足；软件测试走了捷径导致灾难再次发生 公司测试载人飞船星际客机软件系统的程序存在严重缺陷，现在计划对测试程序进行修改。造成程序存在严重缺陷的主要原因就是软件测试走了捷径：该公司缩短了对该飞行器软件的一次关键测试，他们将整个飞行过程分成了几个小单元分别进行测试，但最后却没有做完整的、端到端的集成测试，即没有进行时长为 个小时的整体测试。 集成测试不足", "错误指令造成骑士资本集团损失 4.4 亿美元 2012 日上午 点，纽约证券交易所开盘交易，骑士资本的第一位散户投资者发出了买卖其投资头寸的指令。仅仅 分钟后，骑士资本的服务器就执行了 400 万笔交易，使公司损失了 4.6 亿美元，濒临破产 功能容错性问题；AWS 宕机整整 个小时 2017 亚马逊云（ Amazon S3 Cloud ）出现严重的宕机（中断服务）！亚马逊云之前也出现过宕机，但一般在一个小时之内解决问题，而这次非常严重，宕机整整四个小时 性能、稳定性问题", "Uber 泄漏个人隐私，导致用户要求赔偿 亿多元 2017 月，根据据法国费加罗报报道，一名法国商人起诉 Uber ，要求该公司赔偿 4500 万欧元（按当时汇率 7.4 计算，合计人民币 3.33 亿），以弥补隐私漏洞对自己婚姻造成的伤害，其理由是 Uber app 中存在这样的安全性漏洞 安全性：隐私保护问题；预定的酒店住不进去、露宿街头 2019 年国庆假期出行高峰期，通过某知名旅行网预定酒店的不少网友却遭遇“人在囧途” 到达酒店却无法入住，已支付的订单却显示未支付或订单不存在；与此同时，客服电话打不通，想退房也退不掉，有些旅客想重新预定，在这样的出行高峰期，又很难订到房", "更多的悲剧 放射性治疗仪 Therac-25 中的软件存在缺陷，导致几个癌症病人受到非常严重的过量放射性治疗，其中 个人因此死亡 当爱国者导弹防御系统的时钟累计运行超过 小时后，系统的跟踪系统就不准确。从而导致拦截伊拉克飞毛腿导弹的几次失败，其中一枚在沙特阿拉伯的多哈爆炸的飞毛腿导弹造成 名美国士兵死亡"]}, {"no": "1.2", "title": "为什么要进行 软件测试？", "paras": ["为什么要进行软件测试 答案很简单，就是为了保证软件质量 软件总存在缺陷。只有通过测试，才可以发现软件缺陷。也只有发现了缺陷，才可以将软件缺陷从软件产品或软件系统中清理出去。 软件中存在的缺陷给我们带来的损失是巨大的， 软件测试是软件质量保证的关键步骤，测试作为一种“预防和评估成本”的投入，从而降低缺陷造成的劣质成本 软件测试在产品开发中占据着相当重要的位置，也是软件行业几十年的实践所证明的一个道理"]}, {"no": "1.3", "title": "什么是 软件测试？", "paras": ["1.3.1 软件测试学科的形成 1.3.2 正反两方面的争辩 1.3.3 软件测试的定义 1.3.4 软件测试的其它观点"]}, {"no": "1.3.1", "title": "软件测试学科的形成", "paras": ["从狭义的软件测试到广义的软件测试 软件不只是可执行的程序 ，“需求、设计和代码”都属于软件的组成部分，对“需求、设计和代码”评审属于静态测试 既然提出“动态测试”，这就能说明大家认可“静态测试”，软件测试包含静态测试和动态测试 测试进行得越早，成本越低；相反，缺陷发现得越迟研发成本越高 软件测试 程序测试；广义的软件测试可以极大地降低研发成本 缺陷发现得越迟，其修复的成本越高，而且是非线性增长", "软件测试学科的发展 1957 1978 年，以功能验证为导向，测试是证明软件是正确的（正向思维）。 1978 1983 年，以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）。 1983 1987 年，以质量评估为导向，测试是提供产品的评估和质量度量。 1988 年起，以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷。", "不同的阶段划分 初级阶段（ 1957 1971 ）测试通常被认为是对产品进行事后检验 ，缺乏有效的测试方法 发展阶段（ 1972 1982 1972 年第一次关于软件测试的正式会议，促进了软件测试的发展 成熟阶段（ 1983 到现在），国际标准 Std 829-1983 ，形成一门独立的学科和专业，成为软件工程学科中的一个重要组成部分"]}, {"no": "1.3.2", "title": "正反两方面的争辩", "paras": ["软件测试的正向思维 Bill Hetzel 博士（正向思维的代表）： 软件测试就是为程序或系统能够按预期设想运行而建立信心的过程。 “软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果” 测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作；软件测试的反向思维 Glenford J. Myers （反向思维的代表） 测试是为了证明程序有错，而不是证明程序无错误 一个好的测试用例是在于它能发现至今未发现的错误 一个成功的测试是发现了至今未发现的错误的测试", "认知决定着行为 评价一个程序或系统的特性或能力并确定是否达到预期的结果 测试是为发现错误而针对某个程序或系统的执行过程 软件测试 正向思维 验证软件正常工作 逆向思维 假定软件有错误 在设计规定的环境下运行软件的所有功能，直至全部通过 寻找容易犯错误的地方和系统的薄弱环节，试图破坏系统，直至找不出问题"]}, {"no": "1.3.3", "title": "软件测试的定义", "paras": ["什么是软件测试？ 检查、检验 Check 验证软件能否正常运行？ 发现问题 Detect error 证明是对的 Correction proof 质量评估 Quality evaluation 质量保证 Quality Assurance；软件测试 IEEE/ ISO29119 的定义 An activity in which a system or component is executed under specified conditions , the results are observed or recorded, and an evaluation i s made of some aspect of the system or component. [ISO/IEC 24765, Systems & Software Engineering Vocabulary] 特定的条件下 运行系统或组件，观察或记录结果，对系统或组件的某个方面做出", "软件测试 IEEE/ ISO29119 的定义 Testing is comparing what the test item does with what it is expected to do 分析某个 软件项 以发现 现存的和要求的条件之差别 （即错误）并 此软件项的特性；软件测试 的价值 全面评估产品质量，获得有关产品质量的全面、客观的信息 发现问题，督促问题解决，提高产品质量 持续提供质量反馈、及时揭示质量风险，有助于控制项目风险，提高构建的质量 通过缺陷分析，获得缺陷模式，有助于缺陷预防"]}, {"no": "1.3.4", "title": "软件测试的其它观点", "paras": ["从质量视角认知软件测试 软件测试被认为是对软件 质量进行全面 评估活动，给出质量信息，从而确定质量是否满足设计和用户的需求 Bug 软件测试 质量模型；从风险视角认知软件测试 软件测试被认为是对软件系统中 潜在的 质量风险 进行评估的活动 。其实，测试是样本实验而不能穷尽，其风险总是存在的。 基于风险的测试强调对软件开发全过程进行检测，随时发现问题、报告问题，减少对客户不利影响的风险 非功能特性 产品经理、项目经理 开发人员 持续反馈质量风险 持续反馈质量风险", "从经济视角认知软件测试 测试的经济观点 就是以最小的代价获得最高的软件产品质量。经济观点也要求软件测试尽早开展工作，发现缺陷越早，返工的工作量就越小，所造成的损失就越小。测试的成本 < 缺陷造成的损失，测试才有意义。", "Test Oracle 的认知 输出结果是否正确，需要判断准则；批判性思维 的认知 软件测试就是 、反思、推理或沟通等收集信息，并 对软件产品相关的质量信息进行 ，以此评估软件质量，并做出结论 不断探索的过程"]}, {"no": "1.4", "title": "测试与质量保证的关系", "paras": ["什么是 SQA 对软件工程各个阶段的进展、完成质量及出现的问题进行评审、跟踪。 审查和验证软件产品是否遵守适用的标准、规程和要求，并最终确保符合标准、满足要求。 建立软件质量要素的度量机制，了解各种指标的量化信息，向管理者提供可视信息。 软件质量保证（ Software Quality Assurance SQA ）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程。", "SQA 技术方法的应用 正式技术评审的实施 软件测试 标准的执行 修改的控制 质量记录和记录保存；软件测试 vs. SQA SQA 指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。 软件测试是 SQA 重要手段之一，为 SQA 提供所需的数据，作为质量评价的客观依据。 SQA 是一项管理工作，侧重于对流程的评审和监控 测试是一项技术性的工作，侧重对产品进行评估和验证"]}, {"no": "1.5", "title": "测试与开发的关系", "paras": ["测试不是开发下一道工序 需求定义；测试与开发是并行、协作的关系"]}, {"no": "1.6", "title": "测试驱动开发的思想", "paras": ["测试驱动开发的思想 TDD test driven development ）：测试在前，开发在后；TDD 的实践最早来自极限编程；TDD UTDD ATDD ATDD UTDD 单元测试 验收测试 验收指标 TDD 成为思想， UTDD 单元测试驱动开发、 ATDD 验收测试驱动开发则成为实践；如果开发人员测试自己的产品，会有哪些障碍？ TDD 又是如何克服这些障碍的？", "本章小结 理解测试的定义与价值 从不同视角认识软件测试 正向思维、逆向思维，也会决定测试的行为 理解测试、 SQA 、质量、开发等之间的关系 理解先进的 TDD；提问、思考与练习 在日常使用软件过程中，遇到哪些软件质量问题？ 软件测试的正反两方面 观点会如何影响测试工作 软件测试和软件开发的关系是怎样的？如何更好利用这种的关系？ 软件测试和质量保证之间的联系和区别", "学习资源推荐 软件测试方法和技术（第 ，清华大学出版社， 2022 全程软件测试（第 ，人民邮电出版社， 2019 Bug 软件缺陷的灾难与启示 ，人民邮电出版社， 2016"]}], "2": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 软件测试的基本概念；章回顾 什么是软件测试 软件测试的正反两面性 验证软件 发现缺陷 V&V 软件测试和开发的关系 TDD；2.1 软件缺陷 2.2 软件测试的分类 2.3 静态测试与动态测试 2.4 主动测试与被动测试 2.5 黑盒测试与白盒测试 2.6 软件测试层次 2.7 软件测试工作范畴"]}, {"no": "2.1", "title": "软件缺陷", "paras": ["缺陷是质量的对立面 要了解什么是缺陷 (defect) ，就必须清楚“质量 (Quality) 概念，因为缺陷是相对质量而存在的，违背了质量、违背了客户的意愿，不能满足客户的要求，就会引起缺陷或产生缺陷 Bug 软件测试 质量模型；2.1.1 软件质量的内涵 2.1.2 软件缺陷的定义 2.1.3 软件缺陷的产生 2.1.4 软件缺陷的构成 2.1.5 修复软件缺陷的代价"]}, {"no": "2.1.1", "title": "软件质量的内涵", "paras": ["什么是“质量” ？", "什么是“质量” ？ “质量的概念很难定义，因为它不仅是可见的，而且在体现它的作品中以某种方式被直觉地呈现出来。” 质量与大众的审美、品味或风格无关;与地位、体面或奢华无关。相反，它是在一种接受、得体和克制的气氛中显露出来的；客户满意度；软件质量 的内涵 IEEE 是系统、部件或过程满足 明确需求 客户或用户需要或期望的程度不同 软件质量 ：软件产品具有满足规定的或隐含要求能力要求有关的特征与特征总和 (ISO 8492) 软件质量 ：软件产品满足 使用要求的程度", "产品质量 是人们实践产物的属性和行为，是可以认识，可以科学地描述的。并且可以通过一些方法和人类活动，来改进质量. 质量模型: McCall , Boehm 模型, ISO 9126 过程质量: 软件能力成熟度模型 CMM ( Capability Maturity Model) 国际标准过程模型 ISO 9000 软件过程改进和能力决断 SPICE ( Software Process Improvement and Capability dEtermination 在商业过程中有关的质量内容 培训、成品制作、宣传、发布日起、客户、风险、成本、业务等 高质量软件标准体系 商业环境", "产品质量的标准 功能性 Functionality 可用性 Usability 可靠性 Reliability Performance Capacity 可伸缩性 Scalability 可维护性 Service manageability 兼容性 Compatibility 可扩展性 Extensibility 非功能特性；软件质量特征 (ISO 9126) ：与一组功能及其指定性质有关的一组属性，而功能是能满足明确或隐含的需求的能力 ：在规定的一段时间和条件下，软件维持其性能水平的能力有关的属性 ：规定或潜在的用户为使用软件所需作的努力和所作的评价有关的属性 ：与在规定条件下软件的性能水平与所使用资源量之间关系有关的属性 可维护 ：与进行指定的修改所需的努力有关的属性 可移植 ：与软件从一个环境转移到另一个环境的能力有关的属性 其中每一个质量特征都分别与若干子特征相对应", "ISO 9126 软件质量三层模型；Boehm 软件质量模型 互用性 正确性 可靠性 完整性 可用性 可维护性 可测试性 灵活性 可移植性 重复性 阐述性 数据公开性 连贯性 容错性 执行效率/储存效率 存取控制/存取检查 可训练 沟通良好 简单性 易操作的 自我操作性 扩展性 一般性 模块性 软件系统独立性 机器独立性 通讯公开性 正确性 可操作性 产品操作 产品修改 产品维护", "最新质量标准： ISO25000 ISO/IEC25000 软件产品质量要求和评定 SQuaRE；内部质量 外部质量 使用质量 内部质量 外部质量 使用质量 内部度量 外部度量 在使用中度量 依赖于 依赖于 使用语境；内部度量；产品质量模型 https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en GB/T 25000:10 2016 质量模型", "使用质量模型；示例： Web Portal 的使用的质量；2.1.2 软件缺陷的定义 任何程序、系统中的问题，如与产品设计书的不一致性 不能满足用户的需求；First Bug Grace Hopper （1906-1992）；缺点（ defect ） 偏差 （ variance 谬误（ fault ） 失败 （ failure 问题（ problem ） 矛盾（ inconsistency 错误（ error ） 毛病 （ incident 异常（ anomy – Defect, Bug", "软件缺陷 IEEE (1983) 729 软件缺陷一个标准的定义： 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题； 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。 ISO 29119 a flaw in a component or system that can cause it to fail to perform its required function. any condition that deviates from expectation based on requirements specifications, design documents NOTE Defects may be found during, but not limited to, reviewing, testing, analysis, compilation, or use of software products or applicable documentation", "软件缺陷的现象 功能、特性没有实现或部分实现 设计不合理，存在缺陷 实际结果和预期结果不一致 运行出错，包括运行中断、系统崩溃、界面混乱 数据结果不正确、精度不够 用户不能接受的其他问题，如存取时间过长、界面不美观；2.1.3 软件缺陷的判断准则 需求规格说明书和其它需求、设计规范文档 竞争对手的产品 启发式测试预言（ Heuristic oracle 统计测试预言（ Statistical oracle 一致性测试预言（ Consistency oracle 基于模型的测试预言（ Model-based oracle 人类预言（ Huma n oracle Test Oracle 就是决定一项测试是否通过的（判断）的一种机制。 Test Oracle 的使用会要求将被测试系统的实际输出与所期望的输出进行比较，从而判断是否有差异 ，即是否为缺陷", "2.1.4 软件缺陷的产生 技术问题 算法错误、计算和精度问题 接口参数传递不匹配 团队工作 沟通不充分，误解 软件本身 文档错误、用户使用场合 (user scenario) 时间上不协调、或不一致性所带来的问题 系统的自我恢复或数据的异地备份、灾难性恢复等问题；2.1.5 软件缺陷的构成 Requirements-based testing process in practice January 2010 International Journal of Industrial Engineering and Management 1(4):155-161 https://www.scopemaster.com/blog/root-causes-of-software-bugs/", "软件缺陷在不同阶段的分布 在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。 需求的缺陷会在需求评审、设计、编码、测试等过程中会逐步发现，很能在需求分析一个阶段发现；2.1.6 修复软件缺陷的成本 缺陷带来的成本被称为“劣质成本（ COPQ 非线性增长，不及时处理所带来的成本很高"]}, {"no": "2.2", "title": "软件测试的分类", "paras": ["软件测试的分类；不同维度的分类 按测试的对象或范围分类，如底层测试 单元测试、接口测试 集成测试、系统测试、业务层的验收测试等 按测试目的分类（测试类型），如功能测试、性能测试、可靠性测试、安全性测试、兼容性测试、回归测试等 根据测试过程中被测软件是否被执行，分为静态测试和动态测试 根据是否针对系统的内部结构和具体实现算法来完成测试，可分为白盒测试和黑盒测试 按测试方法分类：精准测试、变异测试、蜕变测试、 MBT", "软件测试 静态测试 vs. 动态测试 主动测试 vs. 被动测试 手工测试 vs. 自动化测试 基于脚本的测试 vs. 探索式测试；主持人 记录员 列席人员 内审员 技术专业人员 用户代表 静态测试 vs. 动态测试 通过运行程序发现错误 不执行程序，而是通过人工评审、代码扫描 静态分析发现错误；主动测试 vs. 被动测试 主动测试 被动测试", "vs. 自动化；基于脚本的 vs. 探索式 测试设计 测试执行 探索式测试 Scripted Testing"]}, {"no": "2.3", "title": "静态测试和动态测试", "paras": ["静态测试 静态测试 包括对软件产品的需求和设计文档、代码的评审（技术评审、文档评审等），以及对代码的静态分析等； 管理评审、流程评审不属于静态测试，而是属于质量保证（ 评审的主要形式： 互为评审 (Peer review) 、走查 (walk-through) 、会议评审 (Inspection) 代码的静态分析主要采用工具进行，但人工的代码评审也不可或缺。", "2.3.1 产品评审 评审的对象：需求文档、设计和代码 通过软件评审，可以更早地发现需求工程、软件设计等各个方面的问题，大大减少大量的后期返工，将质量成本从昂贵的后期返工转化为前期的缺陷发现。 评审是对软件元素或者项目状态的一种评估手段，以确定其是否与期望的结果保持一致，并使其得到改进。", "需求评审解决的问题 不正确的需求认识 丢掉的需求点 模糊的描述 多余的或没意义的需求 不一致的理解；需求评审的标准 正确性 完备性 易理解性 一致性 易测试性 易追溯性；如何做好 需求评审 有明确的评审标准（如需求质量 checklist 熟悉评审内容，为评审做好准备 该参加的人都需要参加 针对问题阐述观点，而非针对个人 从客户角度想问题，多问几个为什么 在会前或会后提出自己建设性的意见 对发现的问题跟踪到底 针对需求文档等报告问题 检查需求定义是否合理、清楚，是否具有可测试性", "设计评审 设计评审 系统架构 可测试性 系统部署 保证需求能在设计中得到准确和完整的表示，即保证系统架构设计和产品功能规格说明书的质量 设计规格说明书 从高层 UML 等建模工具 不断从 测试角度去问开发；设计评审解决的问题 是否有设计规范？ 系统架构设计的不合理 单点失效 数据不完整性、不一致性 缺乏可测试性 具体功能设计的问题"]}, {"no": "2.3.2", "title": "静态分析", "paras": ["静态分析分为两种情况 人工检测：人工检测偏重于编码风格、质量的检验， 对设计、代码进行分析， 有效地发现逻辑设计和编码错误。 计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。", "代码静态分析 词法分析 Lexer 、语法分析 parser 、控制流分析、数据流分析 等技术对程序代码进行扫描，验证代码是否满足规范性、质量要求等。 静态分析技术可以 采用模拟程序执行的技术 符号执行、抽象解释、值依赖分析 等，并采用 数学约束求解工具 进行路径约减或者可达性分析以减少误报、增加效率 抽象语法树 AST 中间表示 Token 语法分析 词法分析", "2.3.3 验证与确认（ V&V 软件测试是由“验证（ Verification ）”和“有效性确认（ Validation ）”活动构成的整体 Verification Are we building the product right 是否正确地构造了软件？即是否正确地做事，验证开发过程是否遵守已定义好的内容。验证产品满足规格设计说明书的一致性 Validation Are we building the right product? 是否构造了正是用户所需要的软件？即是否正在做正确的事。验证产品所实现的功能是否满足用户的需求", "验证和确认；2.4 主动测试 vs. 被动测试 主动测试 ：测试人员主动操作被测对象，如输入数据、发送请求等来驱动被测对象，从而验证被测对象的响应或输出结果 被动测试 ：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行而获得系统运行的数据，然后进行分析；实例：在线测试 Product-in Testing)；2.5 黑盒测试方法和白盒测试 基于需求的测试 数据驱动测试 结构化测试 逻辑驱动测试 客户需求 事件驱动"]}, {"no": "2.6", "title": "软件测试层次", "paras": ["软件测试 个层次 集成测试 单元之间 组件／模块／类／函数 集成测试 系统测试 验收测试 由单元构成的 系统承载的用户；不同测试 的任务 健壮性 组件之间的接口 安全性 健壮性 及用户界面 安全性 用户的可接受性 集成测试 系统测试 验收测试；单元测试 单元测试针对程序系统中的最小单元 模块或组件进行测试，一般和编码同步进行。主要采用白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。通常要编写驱动模块和桩模块 单元测试一般由编程人员和测试人员共同完成，而以开发人员为主 单元测试包括代码评审，代码评审可以发现程序 50% 70% 代码的缺陷。", "集成测试 集成测试，也称联调，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题。现在提倡持续集成测试；持续集成、持续测试；系统功能测试 一般在完成集成测试后进行系统功能测试，而且基于产品功能说明书，针对产品所实现的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用；系统非功能性测试 系统非功能性测试 是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件和数据等，在实际运行环境下验证系统的非功能性， 性能测试 安全性测试 稳定性测试 兼容性测试", "验收测试 验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样 安装测试（部署验证）是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试；& 在线测试 Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers‘ site a form of internal acceptance testing Beta testing comes after α testing. Versions of the software, known as beta versions, are released to a limited users outside of the programming team. Testing in production http://blogs.msdn.com/b/seliot/ http://www.thetestingplanet.com/2011/11/the-future-of-software-testing-part-one-testing-in-production"]}, {"no": "2.7", "title": "软件测试工作范畴", "paras": ["软件测试自身工作流程；测试需求分析 明确测试范围，了解哪些功能点要测试、哪些功能点不需要测试； 知道哪些测试目标优先级高、哪些目标优先级低； 要完成哪些相应的测试任务才能确保目标的实现。", "软件测试策略 基于下列这些因素的考虑做出决定： 测试方式 ，包括手工方式与自动化方式、静态方式与动态方式等的选择与平衡，探索式测试或基于脚本的测试、自己团队测试还是众测、外包等平衡； 测试方法 ，包括黑盒测试还是白盒测试方法、基于数据流还是基于控制流的方法、完全组合测试方法还是组合优化测试方法等平衡； 测试过程， 先测什么、后测试什么，对测试阶段的不同划分等。 制定或选择更合适、更有效的测试方式、测试方法和技术等，其目的是为了以最低的时间或人力成本达到最大程度地揭示产品的质量风险、尽快完成测试等。", "测试计划 目标和范围 测试项及其优先级 识别与分析 指定测试策略 进度安排 资源配置 跟踪和控制机制；测试设计 测试设计是解决“如何测”的问题 ，可以分为测试总体设计和测试详细设计 测试总体设计则主要指测试方案的设计、测试结构的设计 测试详细设计主要是指测试用例的设计。 在测试方案的设计中，测试工作涉及的范围比较大，包括选择测试方法、明确测试策略、设计测试技术路线、选择测试工具和规划测试环境等，", "测试用例 测试用例是测试人员在测试过程中的重要参考依据 测试用例将有助于节约测试时间，提高测试效率。 良好的测试用例不断地被重复使用，使得测试过程事半功倍 测试用例是一个知识积累的过程；测试执行 手工执行 基于详细设计的测试用例来完成测试，也可以在没有测试用例的情况下进行的探索式测试。 自动化执行 指采用测试工具来完成，一般都需要开发自动化测试脚本，然后工具执行脚本，在后续“单元测试与集成测试、系统测试和自动化测试框架”等各章会进行详细讨论。", "基于脚本的测试 Scripted Testing (ST) 先设计后执行 Script: 手工测试 Test case/ 自动化的 Test Script 阶段性明显，属于较传统的测试方式 有什么开发就有什么测试；探索式测试定义 2006.6.6 1983 探索式测试是一种软件测试风格 (Style) ，它强调独立测试人员 (Individual Tester) 的个人自由和职责 (Personal Freedom and Responsibility) ，为了持续优化其工作的价 值 (Value) ，将测试相关学习 (Test-related Learning) 、测试设计 test Design 、测试执行 execution 和测试结果分析（ analysis ）作为相互支持的活动，在整个项目过程中并行地执行", "基于脚本的 vs. 探索式 Fully Scripted Testing Ad-hoc Testing Automated Tests Bug Hunting Exploratory Testing Product Exploration Test Design Test Execution 完全自由的探索 规范的脚本 的测试用例 测试场景 角色扮演测试", "ET vs. ST Scripted Testing 先设计、后执行 强调逻辑分析 关注需求和测试文档 有明确的测试标准 强调评审、可控 严谨、规范 Exploratory Testing 学习、设计和执行并行 上下文驱动 强调个人能力 Test Oracle 关注与产品的交互 拥抱变化、乐趣；测试结果和过程评估 测试结果评估 测试结果进行分析，如分析测试覆盖率，以了解测试是否充分；也可以基于缺陷的趋势分析和分布分析，了解缺陷是否已收敛，以及基于缺陷来评估当前被测试的版本的质量 。 测试过程 ，结合测试计划来进行评审，相当于把计划的测试活动和实际执行的活动进行比较，了解测试计划执行的情况和效果 。", "本章小结 缺陷是质量的对立面， 首先要理解质量的内涵，借助产品质量模型、使用质量模型来理解质量 缺陷是内部错误，在外部表现为失效，缺陷产生的原因很多，来源于需求定义、设计和代码。缺陷要尽早发现、尽早修正，否则带来的劣质成本越大 软件测试方式 ：静态 动态、主动 被动、手工测试 vs. 自动化测试、基于脚本的测试 vs. 探索式测试 软件测试方式 ：单元测试、集成测试、系统测试和验收测试 软件测试工作范畴：测试需求分析、测试策略指定、测试计划、测试设计、测试执行、测试结果和过程评估 帮助同学们建立软件测试的整体全景图", "选择同类某 个产品（如词典类、视频播放器等），并针对这个产品进行质量比较： 详细地分析它们的外部质量和使用质量 列出它们之间有明显差异的质量属性； 列出这类软件需求评审需要关注的功能点 列出这类软件设计评审需要关注的非功能特性；思考题 为何说缺陷是质量的对立面？ 为什么静态测试和 动态测试是一对对立统一体？ 为什么说测试需求分析是测试计划、测试设计的基础？", "实验： 完成一个简单的测试过程 基于软件工程或其它课程开发的软件系统，选定 1-2 个功能模块。如果没有，就针对 https://www.saucedemo.com/ http:// automationpractice.com index.php 先做一些初步的功能测试·分析，如了解功能操作的路径、输入哪些数据？有哪些特殊、异常的数据或操作； 基于上述的分析，像用户使用产品操作软件，进行手工测试，发现缺陷并记录。 完成一个非规范的测试报告。 详见教材 P40-P41"]}], "3": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 软件测试基本方法；章 回顾 软件缺陷是软件质量的对立面 软件缺陷 (Bug) 是什么 软件测试的分类：层次、类型和方法 静态测试与动态测试 主动测试与被动测试 黑盒测试与白盒测试 测试层次：单元、集成、系统和验收 软件测试工作范畴：测试需求分析、计划与设计、执行、结果评估；3.1 基于直觉和经验的方法 3.2 基于输入域的方法 3.3 基于组合及其优化的方法 3.4 基于逻辑覆盖的方法 3.5 基于缺陷模式的测试 3.6 基于模型的测试 3.7 形式化测试方法", "方法论和具体方法 从方法论看，更多体现了一种哲学的思想 例如辩证统一的方法，在测试中有许多对立统一体，如静态测试和动态测试、白盒测试和黑盒测试、自动化测试和手工测试等。 软件测试的方法论来源于软件工程的方法论 ，例如有面向对象的开发方法，就有面向对象的测试方法；有敏捷方法，就有和敏捷方法对应的敏捷测试。", "黑盒测试方法和白盒测试 基于需求的测试 数据驱动测试 结构化测试 逻辑驱动测试 客户需求 事件驱动；等价类划分法 边界值分析法 判定表方法 因果图法 Pairwise 正交试验法 功能图法 过去常提 黑盒和白盒 语句覆盖 判定覆盖 条件覆盖 判定条件覆盖 条件组合覆盖 基本路径覆盖 黑盒方法 白盒方法 基于需求的测试方法 结构化测试方法；方法论：测试方法 上下文驱动方法 基于需求验证的方法 基于场景的测试方法 基于模型的 基于经验的方法", "SWBOK 对测试方法的分类 基于输入域的测试（ IDBT 等价类、边界值、两两组合（ pairwise ）、随机测试 黑盒测试 基于代码的测试 （ CBT 基于控制流的标准、基于数据流的标准、 CBT 参考模型 白盒测试 基于故障模式的测试（ FBT 故障模型、错误猜测法、变异测试 基于使用的测试（ UBT 操作配置 operational profile ）、用户观察启发 黑盒测试 基于模型的测试（ MBT 决策表、有限状态机、形式化验证、 TTCN3 、工作流模型 基于应用特性的测试（ TBNA OOS web real-time SOA embedded safe-critical 应用领域", "3.1 基于直觉和经验的方法 3.1.1 Ad-hoc 测试方法和 ALAC 3.1.2 错误推测法；3.1.1 ALAC 测试和随机测试 ALAC Act-like-a-customer （象客户那样做）的简写， ALAC 测试方法是一种基于客户使用产品的知识开发出来的测试方法，它的出发点是著名的 Pareto 80/20；3.1.2 错误猜测法 错误推测法是测试者根据经验、知识和直觉来发现软件错误，来推测程序中可能存在的各种错误，从而有针对性的进行测试。 发现程序经常出现的错误的方法： 单元测试中发现的模块错误； 产品的以前版本曾经发现的错误； 输入数据为 或字符为空； 当软件要求输入时 比如在文本框中 不是没有输入正确的信息，而是根本没有输入任何内容，单单按了 Enter"]}, {"no": "3.2", "title": "输入域的方法", "paras": ["3.2.1 等价类划分方法 等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的 将输入数据分成若干个 等价类 ，从每个 等价类 选取一个代表性的数据作为测试用例 等价类 分为有效等价类（合理的数据）和无效等价类（异常的数据） all inputs；等价类划分方法应用示例 输入条件规定了取值范围或值的个数，则可以划分为一个有效等价类和两个无效等价类 输入条件规定了输入值的集合，可以确立一个有效等价类和一个无效等价类 个条件 in range greater than range less than range value greater than value less than value not member of set member of set", "有效等价类如何划分？ 无效等价类呢？ 等价类 1: Integer 等价类 2: Decimal fraction 等价类 3: Negative 等价类 4: Invalid input；3.2.2 边界值分析方法 很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以 更有效地发现 缺陷。 设计方法： 确定边界情况（输入或输出等价类的边界） 选取正好等于、刚刚大于或小于边界值作为测试数据 BVA – Boundary Value Analysis", "如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。 {X} = 1,20] 1< x <= 20；Test cases : 任意的正常值 随机选择几个选项 边界值 选择所有选项 边界值 一个都不选 边界值 选择一个选项", "一些特殊的边界值 Term 取值范围 Bit Nibble Byte Word Kilo Mega Giga Tera 0 or 1 0-15 <Half byte> 0-255 0-65535 or 0-4294967295 1024 1048576 1073741824 1099511627776 二进制 Character ASCII Value Character ASCII Value Null Space 121 122 123 ASCII Table", "一些特殊的边界值 缺省值、空格、 (none) Null First/last First-1/Last+1 Min/Max Min-1/max+1 Star/Finish Start-1/Finish+1 Empty/Full Less than empty/ more than full Slower/Faster Largest/Smallest Over/Under just Over/Just Under Shortest/Longest … …", "用边界值方法设计下列测试数据 Username 规则： 个字符以内，不能为空 只能用字母、数字、 ，不能用空格 以字母开始 大小写不敏感 2. Password 规则：不少于 个字符 大小写敏感；3.3 基于组合及其优化的方法 3.3.1 判定表方法 3.3.2 因果图法 3.3.3 Pair-wise 3.3.4 正交试验法；3.3.1 判定表 在实际应用中，许多输入是由多个因素构成，而不是单一因素，这时就需要多因素组合分析 对于多因素，有时可以直接对 输入条件（成立或不成立） 进行组合设计，不需要进行因果分析，这时就采用判定表方法。 判定表由“ 条件和活动 ”两部分组成， 即列出一个测试活动执行所需的条件组合 ，所有可能的条件（输入）组合定义了一系列的选择，而测试活动（ 结果输出 ）需要考虑每一个选择。", "判定表 方法术语及应用 条件桩 问题的所有条件 动作桩 ：针对问题所采取的动作 条件项 ：所列条件的具体赋值（输出） 动作项 ：在条件项组合情况下应采取的动作（输出） ：任何一个条件组合的特定取值及其相应的动作 条件桩 动作桩 最后每一列需要设计一条测试用例覆盖，有几条规则（组合）就有几条测试用例；判定表 组合优化讨论 条件桩 动作桩；判定表 方法示例 项目名称 条件项 此商品在经营范围 此商品可以发货 此客户没有拖欠过付款 动作项 货到后允许客户转账 货到客户必须立即付款 重新组织货源 电话通知 书面通知", "3.3.2 因果图方法 更为复杂的 多种输入条件 产生多种结果 测试用例。 设计方法： 分析软件 Spec 描述的哪些是原因（输入条件）、哪些是结果（输出），给每个原因和结果赋予一个标示符。 找出原因与结果、原因与原因之间的对应关系，画出因果图 在因果图上标上哪些不可能发生的因果关系，表明约束或限制条件 根据因果图，创建（转化为）判定表，将复杂的逻辑关系转化为简单的组合矩阵 把判定表的每一列转化为测试用例。", "因果图 的基本符号 有因必有果关系 关系：只有当因 不存在时，果 才出现 关系： 如果因 存在时，结果 才出现。 关系： 只有当因 同时存在时，结果 才出现。", "条件之间的关系 （互斥）：最多只能有一个条件被满足 （包含）：至少有一个条件被满足 （唯一）：正好（只能一个）条件满足 （要求）：满足了条件 要求满足条件 （屏蔽）：满足条件 隐含的要求不满足条件 （无关）：如果满足了条件 ，条件 就无关重要了；And （互斥） （要求）；因果图方法 设计工具 BenderRBT Cause-Effect Graphing http://www.benderrbt.com/bendersoftware.htm#over", "3.3.3 Pairwise 背景： 大部分缺陷是在两个变量取值冲突的测试时被发现的 处理的问题 ：多个变量、每个变量有多个取值的组合 数太大 （不再是条件成立、不成立两种情况） ：确保某个变量取值和另一个变量取值 成对出现 都会被覆盖 效果：可大幅度降低组合的数量 （两两组合）；Pairwise 具体示例 （两两组合） 完全组合测试数是多少？ 开始两两组合设计", "Pairwise 处理更复杂的情况 曝光值 2.0 1.5 0.5 +0.5 +1.5 白平衡 ：白炽灯、荧光灯、闪光灯、阴天等 感光度 ：自动， 100 200 400 800 1600 3200 分辨率：低，中，高，超高 效果：无，负片，灰度，深褐色 完整组合： 3584 Pairwise 56/3584 1.56%；大部分缺陷是在两个变量取值冲突的测试时被发现的，而不需要测试所有的完整组合 Pairwise 方法来自于经验数据", "Pairwise 方法来自于经验数据 不同强度的组合故障覆盖率；Pairwise 方法工具 http://www.pairwise.org/tools.asp；Pairwise 工具推荐 :ACTS；3.3.4 正交实验法 处理的问题 Pairwise 依据与思想 ：依据 Galois 理论，从大量的（实验）数据（测试例）中挑选适量的、有代表性的点（条件组合），从而合理地安排实验（测试）的一种科学实验设计方法 确定影响功能的因子与状态 选择一个合适的正交表 利用正交表构造测试数据集 正交实验法 Orthogonal experimental design https://www.york.ac.uk/depts/maths/tables/orthogonal.htm 正交表", "正交实验法示例 与两两组合一致；正交表生成工具 https://www.weibull.com/hotwire/issue131/hottopics131.htm；基于需求的测试方法 多因素 单因素 等价类划分 边界值分析 因果分析法 决策表 正交试验法 功能图 有限状态机 错误推测法；3.4 基于逻辑覆盖的方法 3.4.1 判定覆盖 3.4.2 条件覆盖 3.4.3 判定条件覆盖 3.4.4 条件组合覆盖 3.4.5 基本路径覆盖", "结构化测试方法 语句覆盖 判定覆盖 条件覆盖 条件覆盖 条件组合覆盖 MC/DC 基本路径覆盖；逻辑覆盖 vs. 路径覆盖 逻辑覆盖 ：以程序或系统的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定 条件覆盖、条件组合覆盖等； 基本路径测试 ：在程序或业务控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计出测试用例。", "（代码行）语句覆盖 设计若干测试用例，运行被测程序，使程序中的每个可执行语句至少被执行一次 ENDIF ENDIF 程序源代码 1. dim a, b as integer dim c as double if (a >0 and b > 0) then c = c / a end if if (a > 1 or c > 1) then c = c + 1 end if c = b + c 程序控制流图 (a, b ,c)= (1, 1, 2)", "语句覆盖不能发现的问题 程序源代码 1. dim a, b as integer dim c as double if (a >0 b > 0) then c = c / a end if if (a > 1 and c > 1) then c = c + 1 end if c = b + c (a, b ,c)= (1, 1, 2) and 程序源代码 1. dim a, b as integer dim c as double if (a >0 and b > 0) then c = c / a end if if (a > 1 or c > 1) then c = c + 1 end if c = b + c 如果开发写错了", "3.4.1 分支覆盖 判定覆盖 ：设计若干用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。 一个判定代表着程序的一个分支，所以判定覆盖也被称为 分支覆盖 (a, b ,c)= (1, 1, 2) (a, b ,c)= (-1, 1, 0)；3.4.2 条件覆盖 条件覆盖的基本思想是设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。 a>0 and b>0 a>0 >0", "示例：列出所有条件 a>0 ： 取 .T. .F. b>0 ： 取 .T. .F. a>1 ： 取 .T. .F. c>1 ： 取 .T. .F.；示例续： 覆盖所有条件 (a, b ,c)= (2, -1, 0) (a, b ,c)= (-1, 1, 2) T1, F2, T3, F4 F1, T2, F3, T4 但有什么问题吗？", "a>0, b>0 a>1 c>1 (a, b ,c)= (2, 1, 2) a>0 AND b>0 M=.T. N=.T. a<=0 b<=0, a<=1, c<=1 (a, b ,c)= (-1, 0, 1) a>1 c>1 M=.F. N=.F. 3.4.3 条件覆盖 条件覆盖是判定和条件覆盖设计方法的交集 ，即设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次", "3.4.4 条件组合测试 条件组合覆盖的基本思想是设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次 它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的 所有可能组合都至少出现一次 a>0 and b>0 .T. .T. (1, 1) .T. .F. (1, -1) .F. .T. (-1, 1) .F. .F. (-1, -1)", "测试用例 覆盖条件 覆盖路径 覆盖组合 输入： a=2 b=1 c=6 输出： a=2 b=1 c=5 1-2-4 输入： ,b,c 输出： a,b,c )=(2 1-3-4 输入： a,b,c )=(-1 2,3) 输出： a,b,c )=(-1 2,6) 1-3-4 输入： a,b,c )=(-1 2,-3) 输出： a,b,c )=(-1 2,-5) 1-3-5 组合覆盖 路径覆盖 覆盖了所有组合，但覆盖路径有限， 1-2-5 没被覆盖", "条件组合效率不高，有些测试是不必要的 条件 还不够强 a>0 and b>0 .T. .T. (1, 1) .T. .F. (1, -1) .F. .T. (-1, 1) .F. .F. (-1, -1)；修正条件 判定覆盖（ MC/DC 每个判定的所有可能结果至少能取值一次； 判定中的每个条件的所有可能结果至少取值一次； 一个判定中的每个条件独立地对结果产生影响； 每个入口和出口至少执行一次 http://en.wikipedia.org/wiki/Modified_Condition/Decision_Coverage http://www.dsl.uow.edu.au/~sergiy/MCDC.html > n+1 test cases for a decision with inputs. a>0 and b>0 ） 会有多少条用例？ .T. .T. (1, 1) .T. .F. (1, -1) .F. .T. (-1, 1)", "3.4.5 基本路径覆盖 设计所有的测试用例，来覆盖程序中基本的执行路径。 测试用例 覆盖路径 覆盖条件 覆盖组合 输入： a=2 b=1 c=6 输出： a=2 b=1 c=5 1-2-4 输入： a=1 b=1 c=-3 输出： a=1 b=1 c=-2 1-2-5 输入： a=2 b=-1 c=-2 输出： a=2 b=-1 c=-2 1-3-4 输入： a=-1 b=2 c=3 输出： a=-1 b=2 c=6 1-3-4 输入： a=-1 b=-2 c=-3 输出： a=-1 b=-2 c=-5 1-3-5", "基本路径覆盖的设计过程 依据代码绘制流程图 确定流程图的 圈复杂度 cyclomatic complexity 确定线性独立路径的基本集合 ( basis set ) 设计测试用例覆盖每条基本路径；从源代码到流程图 Procedure: process records Do While records remain Read record; record field 1 = 0 Then store in buffer; increment counter; Else If record field 2 = 0 Then reset counter; Else store in file; End If 10. End If 11. End Do End", "流程图简化 2,3 4,5；计算圈复杂度 V(G) = 区域数量 由节点、连线包围的区域，包括图形外部区域 V(G) = 连线数量 节点数量 + 2 V(G) = 简单可预测节点数量 + 1 圈复杂度（ Cyclomatic complexity 代码逻辑复杂度的度量，提供了被测代码的路径数量。复杂度越高，出错的概率越大 V(G) modules", "圈复杂度计算示例 V(G)=4 2,3 4,5 Region 1 Region 2 Region 3 Region 4 9 + 2；确定独立路径集合 独立路径 ：至少引入一系列新的处理语句或条件的任何路径 基本集 ：由独立路径构成的集合 由基本集导出的测试用例，保证每行代码语句至少被执行一次 基本集合不一定唯一 不需要活动图 但最好绘制程序流程图 最好每个单元都进行基本路径测试，对关键组件则是必要的", "Path1: 1-2-3-6-7-9-10-1-11 示例：基本路径测试用例 Path2: 1-2-3-6-8-9-10-1-11 Path3: 1-2-3-4-5-10-1-11 Path4: 1-11 保证每条基本路径被执行一次；逻辑覆盖小结 语句覆盖 判定覆盖 条件覆盖 判定覆盖 CC/DC 条件组合覆盖 MCC 基本路径覆盖 BPC Condition Coverage ( Decision Coverage ( Multiple Condition Coverage (MCC) Modified Condition/Decision Coverage ( MC/DC", "数据流覆盖： 数据流程图、代码中变量的定义与引用 控制流覆盖 业务流程基本路径覆盖，代码中的逻辑覆盖；3.5 缺陷模式的测试 3.5.1 常见的缺陷模式 3.5.2 DPBT 自动化实现；3.5.1 常见的 缺陷模式 故障模型 安全漏洞模型 性能模型 并发故障模型 不良习惯模型 代码国际化模型 易诱骗代码模型；3.5.2 DPBT 自动化实现 预处理 预编译 词法分析 (Lexical Analysis) 语法分析 ( Parsing) 和语义处理 ( Semantic Analysis) 抽象语法树生成 控制流图生成 人工确认 DPBT Defect-Pattern-Based Testing", "实现的通用框架 OWASP 程序状态空间 缺陷模式 基于缺陷模式的 逻辑表达式 语法树 数据流等基本分析方法 CERT CWE 函数调用 SSA 指向分析 前后支配 Mod-effect 多态分析 全局变量分析 抽象解释 符号执行 图可达 被测源程序 SMT 检测结果 逻辑表达式求解 SSA：Static Single-Assignment SMT satisfiability modulo theories CWE Common Weakness Enumeration Handbook of satisfiability . Vol. 185. IOS press, 2009", "3.6 的测试 MBT Model-based testing 3.6.1 功能图法 3.6.2 模糊测试方法；什么是 MBT 基于模型的测试 (MBT, Model-based testing 通过构建能够正确描述被测软件系统功能特性的模型，然后基于这个模型产生测试用例并执行这些测试用例的过程；MBT 基本原理（实施过程） 为被测试系统（ SUT ）建模 基于模型产生测试用例 将抽象的测试具体化使测试用例具有可执行性 执行测试 分析测试结果", "MBT；常见的 MBT 有限状态机 finite state machines FSM ），包括扩展的有限状态机（ EFSM 符号执行 (Symbolic Execution) 是指一种使用符号值代替数字值执行程序的程序分析技术 定理证明 Theorem proving ）通过一组能够明确定义系统行为的逻辑表达式 （谓词）来完成模型构建 模型检验 Model checking ）对属性的测试，如果属性在模型中是有效的，模型检验能发现证据或反例 随机／半随机模型 （如模糊测试方法、变异测试、 马尔科夫链 其它方法 ：基于 UML MBT 因果图方法等", "3.6.1 功能图法 每个程序的功能通常由静态说明和动态说明组成 静态说明描述了输入条件和输出条件之间的对应关系 动态说明描述了输入数据的次序或者转移的次序 功能图法就是为了解决动态说明问题的一种测试用例的设计方法 功能图由状态迁移图（ state transition diagram STD ）和逻辑功能模型（ logic function model LFM ）构成", "状态迁移图 状态迁移图，描述系统状态变化的动态信息 动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变；如何设计测试用例？ 从功能逻辑模型（决策表或因果图）导出局部测试用例，覆盖各个状态的各种输入数据的组合 从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径 功能图法设计测试用例，就是如何覆盖软件所表现出来的所有状态，可以转化为两个层次 的测试用例 功能图法是综合运用黑盒方法和白盒方法来设计测试用例，即整体上选用白盒方法 路径覆盖、分支和条件覆盖等，而局部上选用的是黑盒方法 决策表或因果图方法", "3.6.2 模糊测试方法 模糊测试 ：在一个被测试程序中附加上随机数据（ fuzz ）作为程序的输入。如果被测试程序出现问题（例如 Crush , 或者异常退出），就可以定位程序的缺陷。 模糊测试的巨大优势：测试设计极其简单，系统的行为先入为主。 Fuzz Testing；几种不同模糊器的构造 黑盒随机模糊， 对正确格式的输入数据进行随机变异，然后用这些变异的输入运行程序，看是否能够触发异常。 基于语法的模糊， 是模糊复杂格式输入的替代方法，需要指定输入格式的输入语法、哪些输入部分要进行模糊化以及如何模糊化 白盒模糊处理， 由微软研究院于 2008 年首创，这种方法包括：动态地执行被测程序，从执行过程中遇到的条件分支收集输入约束。然后，系统地逐个否定所有这些约束，并使用约束求解器求解，其解被映射到执行不同程序执行路径的新输入。使用系统搜索技术重复这个过程，试图扫描程序的所有可行的执行路径。", "American fuzzy lop AFL 是一款开源的模糊测试工具，是当今使用最广泛的 Fuzzer 这个工具在程序执行前对程序源码进行 instrumentation 以便在程序执行过程中实时获取程序的执行情况。 AFL 遗传算法 对程序的输入进行变异能够在程序运行的时候注入自己的代码， 然后自动产生测试用例进行模糊测试。简化一下，整个算法可以总结为： 将用户提供的初始测试用例加载到队列中。 从队列中获取下一个输入文件。 试图将测试用例修剪到不改变程序测量行为的最小尺寸。 使用均衡的、经过充分研究的各种传统模糊策略，重复地对文件进行变异。 如果任何产生的变异导致 插桩记录 新的状态转换，将变异的输出作为一个新的条目添加到队列中。 转到第 https://github.com/google/AFL https://afl-1.readthedocs.io/en/latest/", "变异测试 mutation testing 变异测试（Mutation Testing）是一种在细节方面改进程序源代码的软件测试方法。变异操作是模拟典型应用错误（定位代码的弱点）、或强制产生有效地测试；变异测试的方法与流程；3.7 形式化方法 3.7.1 形式化方法 3.7.2 形式化验证 3.7.3 扩展有限状态机方法；3.7.1 形式化方法 形式化方法 基于数学的方法（ 、精确的数学语义 ）来描述目标软件系统属性的一种技术 形式化规范说明语言的构成 ：语法、语义和一组关系 形式化方法可应用在软件规格和验证之上，包括软件系统的精确建模和软件规格特性的具体描述，即可以看作是面向模型的形式化方法和面向属性的形式化方法 http://en.wikipedia.org/wiki/Formal_method 可参考：", "巴科斯范式（ Backus–Naur Form, BNF)；形式化三部曲 形式化描述 形式化开发 形式化验证；形式化的具体方法 基于模型的方法，如 语言、 语言等 代数方法，如 OBJ CLEAR ASL ACT 过程代数方法，如 CSP CCS ACP LOTOS TPCCS 基于逻辑的方法，如区间时序逻辑、 Hoare 逻辑、模态逻辑、时序逻辑、时序代理模型等。 基于网络的方法", "3.7.2 形式化验证 形式化验证 ，就是根据某些 形式规范 或属性，使用 形式逻辑方法 证明其正确性或非正确性。 一般通过形式化规范进行分析和推理，研究它的各种静态和动态性质，验证是否一致、完整，从而找出所存在的错误和缺陷。 无法证明某个系统没有缺陷 ，因为不能定义 “没有缺陷”。只能证明一个系统不存在我们可以想得到的缺陷，以及验证满足系统质量要求的属性", "形式化验证的一些具体方法 有限状态机（ FSM ）或扩展有限状态机（ EFSM SPIN 和线性时态语言 UML 语义转换 RBAC 扩展的 RBAC 模型和基于粒计算的 RBAC 符号模型检验 BAN 逻辑模型 多数是基于模型的，也可以归为 MBT；有限状态机 有限状态机 Finite State Machine FSM ）是对象行为建模的工具，以描述对象在其生命周期内所经历的状态序列，以及如何响应来自外界的各种事件", "示例： : nach Spillner, Linz: Basiswissen Softwaretest, 2005 一个堆栈的 状态图 (state diagram) empty filled full Name Initial and final state state transition state init delete push pop [height= 1] pop push [height = max-1] pop [height> 1] push [height < max-1] top top push", "状态图转化为树结构、生成测试用例 init push initial empty empty deleted filled filled filled full full filled full delete push push pop top top push pop pop ERROR pop ERROR top ERROR delete filled ERROR delete", "状态图工具： Spec Explorer；示例： ATS4_AppModel http://ats4appmodel.sourceforge.net/；补充：基于场景的测试方法 测试用例 用户故事（行为） 测试数据 场景：条件、前提、运行环境等；示例：基于场景的测试 入门级用户 熟练用户 首次安装使用 特定时间打开 App 12:00/ 预定成功后 取消订单后 App 随便看看 查找符合自己要求的酒店 预定酒店 入住酒店 离开酒店 上下文", "练习：列出测试场景和数据 针对某典型用例列出测试场景和测试数据；事件流图 作为承兑人，根据委托收款请求，签发承兑 无条件支付？不得转让？已转让了吗？收款人清楚吗？收款人是否破产？金额超过上限？ 有条件支付 已转让 超过上限 收款人破产 不符合条件；基于场景的测试方法 正常场景 从账户中成功取款 可选场景： 无法取款 用户的银行卡号被拒绝 因为银行卡无法被 ATM 机识别 用户三次以上都没能正确地输入密码。 用户三次或三次以上都没能正确地输入密码 ,ATM 机发生吞卡 用户选择了存款或转账功能 而不是取款功能 用户在插入的卡上选择了一个非正确的账户 用户的取款数额不正确 ATM 机的现金不足 用户输入了一个不存在的数额 用户输入的数额超出了每日的取款限额 用户银行卡账户的余额不足 100"]}, {"no": "101", "title": "基于场景的测试方法 （续）", "paras": ["基于场景的测试方法 （续） 102 成功地从账户中提取现金 U1,S1.1,U2,S2.1,U3.1,U4, S4.1,U5,S5.1,S6,S7,S8,S9,U6) 用户银行卡无法被 ATM 机识别 U1,S1.2,S9) 用户输入密码不正确 <3 U1,S1.1,U2,S2.2) 次输入用户密码不正确 U1,S1.1,U2,S2.2,U2,S2.3,S3) ATM 机中现金不足 U1, S1.1, U2, S2.1, U3.1, U4,S4.1,U5, S5.3) 用户账户余额不足 U1, S1.1, U2,S2.1, U3.1, U4, S4.1,U5, S5.6) 用户输入的取款金额不正确 U1, S1.1,U2, S2.1, U3.1, U4, S4.1, U5, S5.2) 用户输入的密码不正确 > 3 U1,S1.1,U2, S2.2, U2, S2.2,U2,S2.3,S3) 用户输入一个不存在的数额 U1, S1.1, U2,S2.1, U3.1, U4,S4.1, U5,S5.4) 用户输入的金额超出了日取款限制 U1, S1.1, U2,S2.1,U3.1,U4, S4.1, U5, S5.5) 用户选择存款或转账 U1, S1.1,U2, S2.1, U3.2, S10)", "测试用例名称 测试用例描述 测试路径 CASE1 投保成功：年龄 ，男性，健康体、有医疗保险 ABC CASE2 投保成功：年龄 ，男性，非健康体且没有基本医疗 ABE CASE3 投保成功：年龄 ，男性，健康体，有医疗保险 “真” “真” CASE4 投保不成功：年龄 ，男性 “假” CASE5 投保成功：年龄 ，男性，健康体，没有医疗保险 “真” “假” 语句覆盖 判定覆盖 请参考《软件测试实验教程》（清华大学出版社，2019）", "完成条件覆盖设计 测试用例名称 测试用例描述 CASE1 CASE2 CASE3 条件覆盖 请参考《软件测试实验教程》（清华大学出版社，2019）；本章小结 方法论 黑盒方法（基于需求的测试方法）、结构化方法（逻辑覆盖和基本路径覆盖）、基于场景的方法 数据流覆盖 数据流程图、代码中变量的定义与引用 控制流覆盖 业务流程基本路径覆盖，代码中的逻辑覆盖 最常用的方法 等价类划分、边界值分析、决策表、 Pairwise 不同层次的覆盖 代码、功能 非功能、业务 最常用的覆盖标准 ：语句覆盖、分支覆盖和 MC/DC", "思考题 为何在航空航天应用软件中会使用 MC/DC 代码覆盖标准？ 为什么敏捷测试中适合使用基于场景的测试设计方法？", "作业一 DC/CC BPC Testwell CTC++ CoverageMeter BullseyeCoverage GCT CppUnit Dynamic Code Coverage TCAT C/C++ COVTOOL gocv 10. xCover 找一合适的函数代码 选择一覆盖率工具 完成三种覆盖率的测试；针对下列因素，使用 ACTS 不同强度 的组合测试，如果存在约束条件，需要添加后进行计算： 驾驶记录 过去五年内没有违规，过去三年内没有违规 过去三年内违规小于 过去三年内违规 次或三次以上、过去一年内违规 次或三次以上。 汽车型号：一般国产车、高档国产车（ >=20 万）、进口车、高档进口车（ >=100 使用汽车的方式：出租车、商务车、私家车 所住的地区：城市中心地带、市区、郊区、农村 受保的项目：全保，自由组合、最基本保险 司机的驾龄： <=1 <=3 <=5 <=10 >10 保险方式：首次参保、第 次参保、连续受保（ >=3"]}], "4": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 软件测试流程和规范；章回顾 基于直觉和经验的方法 基于输入域的方法 等价类划分、边界值分析 组合及其优化 技术： 判定表、因果图、两两组合、正交实验 逻辑覆盖 的方法 判定覆盖、条件覆盖、判定 条件覆盖、条件组合覆盖、基本路径覆盖 基于故障模式的测试方法 基于模型的测试方法 形式化；4.1 传统的软件测试过程 4.2 敏捷测试过程 4.3 软件测试流派 4.4 测试过程改进 4.5 软件测试标准与规范", "软件测试贯穿全生命周期 测试左移 不仅让开发人员做更多的测试，而且需要做需求评审、设计评审，以及第 章介绍的验收测试驱动开发（ ATDD 测试右移 是在线测试（ Test in Production TiP ），包括在线性能监控与分析、 A/B 测试和日志分析等，可以和现在流行的 DevOp 联系起来。", "测试左移和测试右移 专业化 服务化 向需求、设计转移 BDD ATDD 易用性、性能、 场景测试客户化 高度的可视化、集成化的全过程监控 数据驱动质量：客户质量实时反馈；测试左移 需求评审、设计评审等 测试计划、测试设计可以在更早时候开始 TDD ATDD"]}, {"no": "4.1", "title": "传统的软件测试过程 4.1.1 W 4.1.2 TMap Next", "paras": ["传统的软件测试过程 单元与集成测试 需求评审 设计评审 系统测试 验收测试；软件测试 的生命周期 需求缺陷 设计缺陷 代码和接口 系统缺陷 其它各种 设计评审 需求评审 单元与集成测试 系统测试 验收测试；系统测试的层次 系统设计的验证 验证业务需求 需求定义 系统设计 功能规格 详细设计 功能（规格）的验证 单元测试 集成测试 系统测试 验收测试 代码验证", "4.1.2 TMap TMap (Test Management Approach ，测试管理方法 是一种 结构化 基于风险策略 的测试方法体系 目的能更早地发现缺陷，以最小的成本、有效地、彻底地完成测试任务，以减少软件发布后的支持成本。 TMap 所定义的测试生命周期由 计划和控制、准备、说明、执行和完成等 阶段组成 参考： http://eng.tmap.net/Home/", "TMap 描述的生命周期模型；TMap 基本内容 一个基于风险的测试方法 基于风险的测试策略，来有效的分配测试投入 在测试规划的各个时间点进行商业投入；TMap 三大基石 与软件开发生命周期一致的测试活动生命周期（ 坚实的组织融合（ 正确的基础设施和工具（ 可用的技术（ 测试环境；TMap NEXT 之背景 测试的独立性 和开发更紧密的融合 更多种类的测试组织，包括测试工厂 BDTM, Business Driven Test Management 新的测试方法、技术，特别测试设计方法 测试的基础设施、支持流程 测试估算、风险分析 增加测试类型", "TMap NEXT http://www.tmap.net/en/tmap-next 业务驱动测试管理方法 BDTM 结构化的测试流程 完整的工具包 自适应的测试方法；Tmap NEXT 生命周期模型 Setting & maintaining infrastructure；BDTM；4.2 敏捷测试过程 4.2.1 敏捷测试的价值观和原则 4.2.2 传统测试和敏捷测试的区别 4.2.3 敏捷测试流程 4.2.4 SBTM"]}, {"no": "4.2.1", "title": "敏捷测试的价值观和原则 敏捷宣言体现了价值观", "paras": ["深入敏捷宣言背后的原则 尽早和持续地 交付有价值的软件来满足客户 欢迎需求变更 即使是在项目开发后期 要善于利用需求变更 ，帮助客户获得竞争优势 要不断交付可用的软件，周期从几周到几个月不等， 且越短越好 项目过程中，业务人员与开发人员 在一起工作；深入敏捷宣言背后的原则 要善于激励项目人员，给他们以所需要的环境和支持， 并相信 他们能够完成任务 无论是团队内还是团队间，最有效 的沟通方法是面对面的交谈 可用的软件 是衡量进度的主要指标 敏捷过程提倡 可持续的开发 。项目方、开发人员和用户应该能够保持长期稳定的开发速度", "对技术的 精益求精 、对设计的不断完善将提升敏捷性 尽最大可能减少不必要的工作 一门艺术 最佳的架构、需求和设计出自于 自组织的团队 团队要 定期反省 如何能够做到更有效，并相应地调整团队的行为 深入敏捷宣言背后的原则；敏捷测试特征 尽早和持续地开展测试 能及时完成对软件质量全面评估 软件本身是测试研究和分析最主要的对象 在满足所要求的质量，测试进行得越快越好 测试人员必须和项目干系人保持密切协作 对测试人员足够信任和尊重 测试计划、设计和执行力求简单 对测试技术精益求精 不断反思，持续优化测试设计", "4.2.2 传统测试和敏捷测试的区别 重流程 阶段性明确 测试团队独立性 测试人员职责细化 关注需求 测试文档 文档能力 严谨、规范 缺陷预防 测试过程改进 传统测试 以人为本，强调个人技能 TDD ATDD 持续测试 侧重产品的测试 整个团队对测试负责 拥抱变化 批判性思维能力 自我学习能力 敏捷测试；敏捷测试 持续的质量 非功能特性 产品经理 开发人员 用户需求 质量问题持续反馈 质量问题持续反馈 交付价值 4.2.3 敏捷测试流程", "Scrum 测试流程；4.2.4 基于会话的测试管理（ SBTM 测试目标 测试项 测试风险 测试策略 测试点 场景列表；Session 是一段不受打扰的测试时间（通常是 分钟），是测试管理的最小单元。 session 关联一个特定的、目标明确的测试任务（ mission Charter 章程，即测试指导 对每个 session 如何执行进行简要的描述，相当于每个 session 需要一个简要的计划（提纲） 一系列 Session 相互支持，有机地组合在一起， 周密地测试了整个产品。 SBTM", "A session sheet 测试报告 相当于测试报告，供第三方（如测试经理、 ScrumMaster 等）进行检查的材料。它最好能被工具扫描、解析和合成。 Debriefing （听取口头报告） 口头汇报，更准确地说，是测试人和其 lead/Manager 之间的对话。 SBTM；mission-session 测试计划 Mission Mission Mission Charter Charter Charter Time-Box Session Session test suite", "Charter 进一步明确测试范围和策略 Charter 清晰指导 Session 执行任务（ Mission ）：要测什么、怎么测试（强调策略，不是详细测试步骤）、寻找什么样的缺陷、哪些产品质量风险等 可以看做一个或一组用例（ User Case ）的体现，相对用例 use case 的测试思路 通过数据的多样性变化来测试 流程对各种数据的容错能力 通过检查 来测试 模块是否符合 By testing ...through ... to ...", "Charter 规范模板 测试目标 优先级 测试判断依据 环境配置 测试数据 如何测试 去哪儿 VIP 用户，“ 积分兑换 ”功能测试 异常操作、互操作和大数据的测试 优先级一般 参考产品愿景、用户故事等文档 根据用户故事验收标准等判断 Windows/IE Mac OS/Safari… 引用备份的测试数据库 登录、查询积分、去积分商场查询合适商品、兑换、物流选择、补充性支付等", "结果报告： Session Sheet -1 TSB 只要遵循简单的格式，就可产生易于自动分析的报表，通过特定工具汇总，产生测试报告和图表；Session Sheet -2 Session charter 包含任务陈述、测试范围等 Tester name(s)/ 测试执行者 Task breakdown :TBS Test/Bug/Setup ）度量（耗时），这些数据配合简报有助于估算测试速度、评估测试效率 测试数据、数据文件：为测试数据复用提供了基础 Note/ 测试笔记：测试过程中随时记录的有价值的信息， 叙述了测试故事：为什么测试，如何测，为什么这样的测试已足够好 Issues/ ：测试过程中的问题和疑惑 （未来测试的参考资料） 缺陷： 测试的直接产出", "任务报告 （ Debriefing ast （已做了哪些测试） What happened during the session? esults （测试结果） What was achieved during the session? bstacles （障碍） What got in the way of good testing? utlook （未来要做哪些测试） What still needs to be done? eelings （感觉） How does the tester feel about all this? PROOF session 结束后有一个口头汇报 每天测试人员有 次沟通 Note: same Questions Daily Scrum meeting", "SBTM 实践框架"]}, {"no": "4.3", "title": "软件测试流派", "paras": ["五大软件测试流派 分析流派 质量流派 上下文驱动流派 敏捷流派 标准流派；各测试流派的特征 分析流派 ：认为测试是严格的和技术性的，在学术界有许多支持者 标准流派 ：将测试视为衡量进度的一种方法，强调成本和可重复的标准 质量流派 ：强调过程规范性，监督开发人员并充当质量的看门人 上下文驱动流派 ：强调人的价值，寻找涉众关心的bug 敏捷流派 ：强调自动化测试，使用测试来快速验证开发是完整的 敏捷流派可以从上面 4.2 小节得到更多的信息", "上下文驱动测试 CDT: Context-driven Testing 任何实践活动的价值依赖于它所处的上下文 在某个上下文中只有好的实践，没有最佳实践 一起工作的人，才是项目的最重要组成部分 项目的发展往往难以预料 产品是问题的解决方案，如果问题没得到解决，产品是无用的 好的软件测试时一个富有挑战性的智力过程。 只有通过判断和技能，并在整个项目过程中协同练习它们，我们才能在正确的时间做正确的事，以有效地测试我们的产品", "4.4 软件测试改进 4.5.1 TMMi (Testing Maturity Model integration) 4.5.2 TPI (Test Process Improvement) 4.5.3 CTP (Critical Test Process) 4.5.4 STEP (Systematic Test & Evaluation Process)", "4.4.1 TMMi 过程能力 描述了遵循一个软件测试过程可能达到的预期结果的范围。 TMM 的建立，得益于以下 充分吸收、 CMM CMMi 的精华； 基于历史演化的测试过程； 业界的最佳实践。 个别级的一系列测试能力成熟度的定义，每个级别的组成包括到期目标、到期子目标活动、任务和职责等。 一套评价模型，包括一个成熟度问卷、评估程序和团队选拔培训指南。", "TMMi 个级别简述；TMMi 级别内容；TMMi；4.4.2 TPI NEXT TPI Test Process Improvement ）是基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的；TPI 20 个关键域 测试策略 生命周期模型 介入时间 估计和计划 测试规格技术 静态测试技术 测试自动化 测试环境 办公环境 承诺与动力 测试功能与培训 方法的范围 缺陷管理 测试件管理 测试过程管理 底层测试", "TPI 为了了解过程在每个关键域所处的状态，即对关键域的评估结果，通过级别是来体现。模型提供了 个级别，由 是最低级。根据测试过程的可视性改善、测试效率的提高、或成本的降低以及质量的提高，级别会有所上升。 详见表 4-3；TPI 检查点和建议 为了能客观地决定各个关键域的级别， TPI 模型提供了一种度量工具 检查点 。每个级别都有若干个检查点，测试过程只有在满足了这些检查点的要求之后，才意味着它达到了特定的级别 检查点帮助我们发现测试过程中的问题，而 会帮助我们解决问题，最终改进测试过程。建议不仅包含对如何达 到下个级别的指导，而且还包括一些 具体的操作技巧、注意事项等。", "TPI 成熟度矩阵；TPI NEXT 商业驱动作为测试过程提升的基础 为改进目标和度量设定优先级 确保商业可以引导和控制改进的过程；TPI Next；关键域） TPI vs. TPI Next；4.4.3 CTP 关键测试过程 Critical Test Process CTP 内容参考模型、上下文相关的方法，并能对模型进行裁剪 CTP 的过程改进， 始于对现有测试过程的评估，通过评估以识别过程的强弱，并结合组织的需要提供改进的意见 Plan Prepare Perform 和完善 (Perfect) ；计划和完善主要是管理工作，准备和执行是实践工作", "CTP 12 个关键过程 建立上下文关系和测试环境 质量风险评估 测试估算 测试计划 测试团队开发 测试（管理）系统开发 测试发布管理 测试执行 缺陷报告 测试结果报告 变更管理 测试策略 生命周期模型 介入时间 估计和计划 测试规格技术 静态测试技术 测试自动化 测试环境 办公环境 承诺与动力 测试功能与培训 方法的范围 缺陷管理 测试件管理 测试过程管理 底层测试", "4.5.4 STEP STEP Systematic Test and Evaluation Process ，系统化测试和评估过程） 是一个内容参考模型 基于需求的测试策略 在生命周期初始开始进行测试 测试用作需求和使用模型 由测试件设计导出软件设计（ 测试驱动开发 及早发现缺陷或完全的缺陷预防 对缺陷进行系统分析 测试人员和开发人员一起工作", "STEP 强调度量 不同时期的测试状态 测试需求和风险覆盖 缺陷趋势，包括发现、等级和分类分项数据 缺陷密度 缺陷移除效率 缺陷发现率 缺陷引进、发现和移除等阶段 测试成本，包括时间、工作量和资金 已定义的测试过程使用 客户满意度；STEP STEP CTP 比较类似，而不像 TMMI TPI ，并不要求改进需要遵循特定的顺序。 某些情况下， STEP 评估模型可以与 TPI 成熟度模型结合起来使用"]}, {"no": "4.5", "title": "软件测试标准与规范", "paras": ["国际标准 国家标准 行业标准 项目规范 ISO9000-3 Quality management and quality assurance standards ISO/IEC 12119 Information technology - Software packages - Quality requirements and testing GBT 15532-2008 《 计算机软件测试规范 IEEE Std 1008 单元测试标准 IBM 程序设计开发指南", "标准和质量体系认证；SC7 标准集了解软件工程标准的结构；主要软件质量标准 ISO29119 系列标准： GB/T 38634.1-2020 系统与软件工程 软件测试 第 部分：概念和定义 GB/T 38634.2-2020 系统与软件工程 软件测试 第 部分：测试过程 GB/T 38634.3-2020 系统与软件工程 软件测试 第 部分：测试文档 GB/T 38634.4-2020 系统与软件工程 软件测试 第 部分：测试技术 … … 与测试直接相关的标准还有： GB/T 15532-2008 计算机软件测试规范； GB/T 9386-2008 计算机软件测试文档编制规范 GB/T 33447-2016 地理信息系统软件测试规范； GB/T 37715-2019 公安物联网基础平台与应用系统软件测试规范", "软件测试行业标准 JR/T 0175 2019 《证券期货业软件测试规范》； JR/T 0101-2013 银行业软件测试文档规范； JR/T 0191 2020 证券期货业软件测试指南 软件安全测试 GA/T 1765-2021 公安视频图像信息应用平台软件测试规范； DL/T 2031-2019 电力移动应用软件测试规范 JT/T 966 -2015 收费公路联网收费系统软件测试方法（多个子标准）", "完整的软件测试规范是怎样的 规范目的 文档结构 词汇表 参考信息 可追溯性 检查表 参考资料等；制定测试规范需要考虑的内容 角色的确定 进入的准则 输入项 活动过程 输出项 验证与确认 退出的准则；GBT 15532-2008 《 计算机软件测试规范；银行业软件测试规范；环境信息系统的测试规范 确定测试充分性要求。确定测试应覆盖的范围及每一范围所要求的覆盖程度。 确定测试终止的要求。指定测试过程正常终止的条件 如测试充分性是否达到要 求 并确定导致测试过程异常终止的可能情况。 确定环境信息系统测试的质量目标。 确定用于测试的资源要求 包括软件、硬件、人员数量和人员技能等。 确定需要测试的环境信息系统特性。根据合同或系统 子系统设计文档的描述 定系统的功能、性能、状态、接口、数据结构、设计约束等内容和要求。并从中确 定需测试的环境信息系统特性。 确定测试需要的技术和方法 如测试数据生成和验证技术、测试数据输入技术、测 试结果获取技术、是否使用标准测试集等。 根据合同或项目计划的要求和环境信息系统的特点 确定测试准出条件。 确定由资源和被测系统决定的测试活动的进度。 对测试工作进行风险分析与评估 并制订应对措施 设计测试用例。将需测试的环境信息系统特性分解 针对分解后的每种情况设计测试用例。 获取测试数据 包括获取现有的测试数据和生成新的数据 并按照要求验证所有数据。 确定测试顺序 可从资源约束、风险以及测试用例失效造成的影响或后果几个方面考虑。 获取测试资源 对于支持测试的软件 有的需要从现有的工具中选定 有的需要开发。 编写测试程序 包括开发测试支持工具。 建立和确认测试环境。 编写测试说明。", "本章小结 传统软件测试流程 模型、 TMap Next 敏捷测试流程 ：敏捷宣言、敏捷开发 项原则、 TDD SBTM 五大测试流派 ：重点理解上下文驱动测试流派 软件测试改进： TMMi TPI next 软件测试标准与规范；思考题 进一步理解传统测试和敏捷测试 不同点和共同点 测试改进的核心是什么？在 个模型中，哪个模型更适合自己的自我改善？"]}], "5": [{"no": "", "title": "本章导入", "paras": ["篇 软件测试技术 章 单元测试与集成测试 章 系统功能测试 章 专项测试 章 国际化和本地化测试 章 软件测试自动化及其框架；软件测试方法和技术 章 单元测试与集成测试；5.1 代码静态测试 5.2 代码评审案例分析 5.3 代码静态检测工具 5.4 单元测试的目标和任务 5.5 分层单元测试 5.6 单元测试工具 5.7 系统集成的模式与方法 5.8 持续集成及其测试 教材内容", "5.1 代码评审与分析 5.2 5.3 持续集成 重点、难点解析 JUnit 的单元测试实验 现在整合优化为 部分，内容更紧凑些。如果不调整，可在第 版基础上进行修改，这部分第 版变化不大"]}, {"no": "5.1", "title": "代码评审与分析", "paras": ["代码评审的价值 改善代码质量 跨团队共享知识 辅导缺少经验的程序员 坚持遵守代码规范 增强协作 减少项目代价；关注代码评审 是否符合代码规范、代码风格？ 圈复杂度： e-n+2p 信息流复杂度 ：（扇入*扇出） 模块耦合性：功能 数据相关联模块数比例；首推代码规范 https://google.github.io/styleguide/cppguide.html http://google.github.io/styleguide/javaguide.html", "代码互查的优秀实践 一次检查少于 200 400 行代码 努力达到一个合适的检查速度： 300 500LOC/hour 有足够的时间、以适当的速度、仔细地检查，但不宜超过 在复审前，代码作者应该对代码进行注释 使用检查表（ checklist ）肯定能改进双方（作者和复审者）的结果 验证缺陷是否真正被修复 Best Practices for Peer Code Review", "工具支持： Collaborating with pull requests @GitHub https://docs.github.com/en/pull-requests/collaborating-with-pull-requests；示例： change review；缺陷示例：空指针保护案例分析；开发人员走上台介绍其代码 每个人都有机会 随机抽取 现场展示", "其它优秀实践 关键代码的集体评审 代码评审作为一种文化 借助工具更有效 流程定义；代码静态分析工具；代码静态分析工具 SonarLint Java FindBugs PMD Checkstyle C/C++ Clint/ Oclint Cpplint TestC Python Pylint PySonar2 安全： Coverity Fortify https://owasp.org/www-community/ Source_Code_Analysis_Tools 更多的参考：", "https://www.sonarsource.com/products/sonarlint/ 发现缺陷 修正缺陷 几乎支持所有流行的语言和IDE；https://plugins.jetbrains.com/plugin/7973-sonarlint 示例：在 IntelliJ olarLint；可以和 olarQube 集成使用；来自大学的 FindBugs http://findbugs.sourceforge.net/ 2015年3月 FindBugs 3.0.1发布之后 就没有更新了", "FindBugs IntelliJ IntelliJ IDEA 2021.2 之后就基本 干掉 了 FindBugs；IntelliJ 分析功能代替了 FindBugs；代码风格 CheckStyle https://checkstyle.org/ CI/CD mvn checkstyle checkstyle apply from: 'checkstyle.gradle’ 配置文件 config/checkstyle/checkstyle.xml 运行任务 ./gradlew check 检查结果 build/reports/checkstyle/main.html", "CheckStyle；checkstyle 结果显示；SourceMonitor 检测代码复杂度；软件第三方库风险巨大 10% 30% 90% 2015 2020 98% 的正在使用开源第三方库的公司并不了解它们 开源第三方库使用比例急速上升 每年有 4000 新增开源第三方库漏洞被报告 2010；代码级安全分析对象 20% 35% 45% SAST 未知漏洞 CWE SCA 已知漏洞 CVE", "SCA；代码分析工具常见的使用场景 IDE 实时进行 代码每次提交时进行 CI/CD 流水线集成 SQL 跨站脚本攻击 资源泄露 硬编码凭据 配置审查 检测项举例 为开发者 快速返回检查结果 消除常见的安全问题 使用方式 使用目的 规则集 可选有限个检测项 检测耗时 几秒～几分钟；SAST 工具通用框架 OWASP 程序状态空间 缺陷模式 基于缺陷模式的 逻辑表达式 语法树 数据流等基本分析方法 CERT CWE 函数调用 SSA 指向分析 前后支配 Mod-effect 多态分析 全局变量分析 抽象解释 符号执行 图可达 被测源程序 SMT 检测结果 逻辑表达式求解 SSA：Static Single-Assignment CWE Common Weakness Enumeration", "单元测试内容 为何要进行单元测试 单元测试的目标和要求 驱动程序和桩程序 单元测试工具 JUnit 及其实践 Mock 技术与框架（如 Mockito 测试覆盖率工具 JaCoCo；为何要进行单元测试 编程与编译运行结束后，每 1000 行代码中大约残留有 Bug 寻找与修改程序错误的代价占总体开发投资的 尽早发现错误，成本越低 发现问题比较容易 修正问题更容易 单元质量是系统质量的基石，单元测试可以比系统测试测得更彻底 0.8 =0.00123 0.99 0.740", "单元测试的其它价值 支持扩展 如果没有各种类型测试的支持，软件开发无法支持扩展，单元测试就是其基础 引导更好的设计 能够支持单元测试的代码总是不会被人遗弃。单元测试的存在，甚至实现程序可测试性的意识，可避免 方法有太多参数 Monster Methods （巨型方法）、 过多的依赖 ”等问题 支持变化 任何人修改系统的一部分，就必须了解其它哪些部分需要运行验证，以确保不破坏程序 单元测试，提供了所需要的安全网 ，我们在进行代码修改的时候，无需担心无法预料的破坏。 避免回归缺陷 集成为一个庞大 系统后， 靠系统测试 穷尽所有的回归测试几乎是不可能的 保证工作的平稳步调 如果代码编写能够与单元测试配合， 很少会引起意外或最后一分钟问题。 节省测试时间 单元测试是最简单、最快和最廉价的方式实现基础检查，例如边界值验证、输入验证或程序主逻辑路径调用等。 规范行为和记录代码 理想状态下，单元测试是被测代码的行为描述。它也是一个例子，解释代码是如何工作或如何实现一个特定的业务逻辑 总是愿意写 工作完全正确 的代码，而不是写 按照预期的设想工作 的代码 ，但是证明一个程序的正确性几乎是不可能的，除非是大学教材中有关形式化方法的非常简单的代码片段。", "单元测试的目标 单元模块被正确实现（主要指编码），包括功能、性能、安全性等，但一般主要介绍单元功能测试。 （参数）输入是否正确传递和得到保护（容错），输出是否正常 内部数据能否保持其完整性，包括变量的正确定义与引用、内存及时释放、全局变量的正确处理和影响最低 代码行、分支覆盖或 MC/DC 达到要求，如高于 80% 95%；实现两个正整数或零的加法，如果其中有 个数小于或等于 ，则返回 错误在哪里？通过怎样的测试数据可以发现？ package study.myconnect.cn; public class Calculator{ public int add(int num1, int num2){ if(num1>=0 && num2>0){ return num1 + num2; else{ return 0; 一个小练习", "驱动程序与桩程序；驱动程序与桩程序 Function under test Driver Stub；桩程序的灵活性 class ParameterizedStub ICollaborator private int value; public ParameterizedStub (int value) this.value = value; public int ComputeAndReturnValue if (value < 10) throw new InvalidOperationException (); return value; 不会像上一页返回一个 硬编码数值 让一个桩对象返回单个数值是最简单，但也 最不聪明的做法 ，因为 其它测试迟早都需要返回一个不同的数值", "单元测试工具及其应用；单元测试工具 https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks；最常用的单元测试工具 JUnit TestNG GoogleTest pytest unittest Coverage.py EvoSuite Diffblue Cover Java C++ Python 语言的单元测试中，受欢迎的测试工具包括单元测试框架、 两个智能化的单元测试用例自动生成工具、以及 Mock 工具、代码覆盖率工具 JMockit JaCoCo gcov lcov gcovr 详见公众号文章", "JUnit 4 工作原理；JUnit 成员三重唱共同产生测试结果 TestRunner 运行一个 TestSuite TestSuite 可以由一个或多个 TestCase （或者由其他 TestSuite ）所组成。运行结果由 TestResult 收集，由 TestRunner 来报告 JUnit 工作原理；JUnit 5 JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage （复古） JUnit Platform： 基于JVM的执行测试的基础框架及其Test Engine API，还提供了一个控制台启动器（以命令行启动平台），为Gradle和 Maven构建插件支持 CI/CD ，同时提供基于JUnit 4的Runner。 JUnit Jupiter： 在JUnit 5中编写测试和扩展的新编程模型和扩展模型的组合。Jupiter子项目提供了Test Engine在平台上运行基于Jupiter的测试。 JUnit Vintage： 提供了TestEngine在平台上运行基于JUnit 3和JUnit 4的测试 https://junit.org/junit5/docs/current/user-guide/", "Assert Assert （断言）类是 JUnit 框架中非常重要的类 用于判断所返回的实际结果与预期结果是否相符。 Annotation （注释） JUnit 引导标注测试类中不同方法的功能。 Runner 运行器 JUnit 通过运行器 Runner 和显示测试执行结果 需要了解 JUnit 的关键组件；Annotation Annotation 清晰地表达测试程序的逻辑结构和功能 常用的 JUnit Annotation @Test ParameterizedTest Beforeeach Aftereach BeforeAll AfterAll 、@RepeatedTest、@TestFactory、@TestTemplate、@TestClassOrder、@TestMethodOrder、@DisplayName、@Nested、@Tag、@Disabled、@Timeout、@ExtendWith、@RegisterExtension、@TempDir 更详细参考：https://junit.org/junit5/docs/current/user-guide/#writing-tests", "Assert 检查并判断程序的运行结果是软件测试中的一项重要工作 。测试程序必然会包含一些断言条件，程序运行时不满足这些条件，则表明程序的运行状态 结果与期望不一致，程序中存在缺陷 JUnit Assert 类提供了一系列断言方法来判断程序的运行结果，该类位于 junit.framework 包中。断言方法中的参数包括期望变量 var expected 和实际变量 var actual var expected var actual 的值相等，则表明程序运行结果与期望相符；否则表明程序运行结果与期望相异，测试用例运行失败。", "TestCase TestSuite TestResult TestCase JUnit 框架中 为测试用例提供服务 的核心类，同样位于 junit.framework 包中，并继承自 Assert 类，因此可直接使用 Assert 类中的相关方法。单元测试所编写的测试类均需直接或间接继承于 TestCase 类，依靠其提供的方法来实现测试用例（ @Test 所注解的测试方法）的运行与判断。 TestSuite 实现了 JUnit Test 接口，用于管理 JUnit 中的每一个测试用例 TestResult 收集并记录所有测试用例的运行结果。测试用例的运行结果可分为成功、失败、错误等三类", "单元测试脚本 Junit 为例）；Mock；Fake Dummy Double Fake 伪对象 （伪造、假货），反义词 real Dummy 哑对象 仿制品、哑巴、 傀儡） 对被测对象的模拟，特别是缺乏原有的特性或功能而实现欺骗性地替换（ 完全听命行事，不在具体测试里面起任何作用 Double 有相同的行为和响应 Spy ：测试间谍， 能够接收参数并返回值 几乎和产品代码做同样的工作（ 伪装成跟真的一样 ），但为了满足测试要求， 更简单的实现 Dummy Object Test Spy 可归为 Stub", "伪对象 在某些情况下，插桩不够用。被桩对象替换掉的行为是被测对象所需要的。在这种情况下， 伪对象 fake 可能是一种合理的折衷。 伪对象是协作者 的轻量级实现 public Invoice MakePurchase (Customer customer, Product product, Discount discount) var purchase = purchaseFacade. CreatePurchase (customer); purchaseFacade. AddProduct (purchase, product); var invoice = purchaseFacade. CreateInvoice (purchase); if (discount != null) invoice.ApplyDiscount (discount); return invoice;", "Fake 示意图 round-trip test Round-trip test Public interface “front door” 直接输入 DOC Depend-on Component SUT System Under Test；Fake；Fake fake object = enhanced stub DAO ( Data Access Object) 能正常工作，就构造 fake object 代替数据库 HSQLD 是流行的 in-memory database DBUnit", "模拟对象 模拟对象 Mock 在某种程度上是游戏的改变者， 因为它们将测试的焦点从 转换到 ake 聚焦于状态的测试以断言 (assertion) 结束，该断言会核对返回值或以某种方式查询被测对象的状态 （属性）。而 基于行为的测试是完全不同的， 验证模拟对象和被测代码或另一协作者之间特定的 (interaction) 行为，会关注被测对象 是否被调用 调用了多少次以及是否查询了 Value 属性。 @Test public void useLenientMock () { LenientMock campaignMock = new LenientMock (); new PurchaseWorkflow campaignMock addItem getBookByTitle (\"Developer Testing\")) usingExistingCustomer (1234567) enterDiscountCode (\"DEAL\"); campaignMock.verify ();", "Mock vs. Stub；Stub mock Stub 最弱，只是参与测试，为了让测试跑起来 Dummy/Spy 强些， Test Spy 参与测试，还要验证产生的某种结果。 Dummy 是简单、原始的测试替身 Dummy server, 给它不同的输出会有不同的相应，但其内部没有实质计算，是接口或基类的衍生 Mock 更强，要求如何参与，且比较灵活，视情况而定，其行为可能会像 Dummy Stub Spy 够用就行，如果 Stub 够用，就不要用 Mock", "Mock JMock EasyMock Mockito Moco Java API 、独立服务器；EasyMock 通过简单的方法对于给定的接口生成 Mock 对象的类库。它提供对接口的模拟，能够通过录制、回放、检查来完成测试过程，可验证方法的调用种类、次数、顺序，可令 Mock 对象返回指定的值或抛出指定异常 IMocksControl control EasyMock.createControl (); java.sql.Connection mockConnection = control .createMock Connection.class java.sql.Statement mockStatement = control .createMock( Statement.class java.sql.ResultSet mockResultSet = control .createMock( ResultSet.class", "Mockito 设置依赖性 验证交互性操作 Stub 方法调用；Mockito 主要功能 mock()/@Mock: mock 可以通过 Answer/ MockSettings 指定其行为方式 when()/given() 来指定 mock 如何行动 如果提供的返回不符合需求，可以自己写一个返回接口的扩展。 spy()/@Spy 部分模拟，调用真实的方法，但仍然可以被验证 InjectMocks 自动注入带有 Spy Mock 注释的 mocks/spies 字段。 verify(): 检查方法是否用给定的参数调用。 可以使用灵活的参数匹配，例如，通过 any() 的任何表达式 或使用 Captor 来捕获哪些参数被调用。", "Annotation Type Mock 将一个字段标记为 Mock 允许速记的 Mock 尽量减少重复的 Mock 创建代码。 使测试类、验证错误更具可读性 自动检测 MockedStatic 类型的静态 Mock；BDD；测试覆盖率工具；代码覆盖率分析工具 JaCoCo 通过对编译后的 Java class 文件进行统计代码的插装 测试覆盖率 收集与报告 BullseyeCoverage 是一种获取 C/C++ 的代码覆盖率的工具，支持分支覆盖率（ Branch Coverage 的分析 Testwell CTC++, Parasoft Jtest /C++Test, CoverageMeter Jcov CodeCover Coverage.py", "实现覆盖率度量： Jacoco 覆盖率分析维度：指令、分支、行、方法、类、圈复杂度 java 二进制码，无需源文件 on-the-fly instrumentation java agent 的集成 框架：基于 java VM 的应用集成，如 OSGI 框架、 web 容器和 EJB 服务器 兼容所有的 java class file 支持不同的 JVM 多种报告形式： HTML CSV XML 远程协议和 JMX 控制可随时从覆盖率代理获取执行数据 ANT tasks/ Maven-plugin 收集执行数据并创建覆盖率报告 https://www.eclemma.org/jacoco/", "on-the-fly instrumentation //接受jvm參數 package org.jacoco.agent.rt.internal.PreMain public static void premain(final String options, final Instrumentation inst) throws Exception { final AgentOptions agentOptions = new AgentOptions(options); final Agent agent = Agent.getInstance(agentOptions); final IRuntime runtime = createRuntime(inst); runtime.startup(agent.getData()); inst.addTransformer(new CoverageTransformer(runtime, agentOptions, IExceptionLogger.SYSTEM_ERR));", "on-the-fly instrumentation /ASM 注入class method public byte[] instrument(final ClassReader reader) final ClassWriter writer = new ClassWriter(reader, 0) { @Override protected String getCommonSuperClass(final String type1, final String type2) { throw new IllegalStateException(); final IProbeArrayStrategy strategy = ProbeArrayStrategyFactory .createFor(reader, accessorGenerator); final ClassVisitor visitor = new ClassProbesAdapter( new ClassInstrumenter(strategy, writer), true); reader.accept(visitor, ClassReader. EXPAND_FRAMES); return writer.toByteArray();", "on-the-fly instrumentation //ASM回調方法，同时jacoco调用分析方法 Override public final MethodVisitor visitMethod(final int access, final String name, final String desc, final String signature, final String[] exceptions) { final MethodProbesVisitor methodProbes; final MethodProbesVisitor mv = cv.visitMethod(access, name, desc,signature, exceptions); if (mv == null) { methodProbes = EMPTY_METHOD_PROBES_VISITOR; } else { methodProbes = mv; return new MethodSanitizer(null, access, name, desc, signature, exceptions) { @Override public void visitEnd() { super.visitEnd(); LabelFlowAnalyzer.markLabels(this); final MethodProbesAdapter probesAdapter = new MethodProbesAdapter( methodProbes, ClassProbesAdapter.this); if (trackFrames) { final AnalyzerAdapter analyzer = new AnalyzerAdapter( ClassProbesAdapter.this.name, access, name, desc, probesAdapter); probesAdapter.setAnalyzer(analyzer); methodProbes .accept(this, analyzer); //注入数据分析 } else { methodProbes.accept(this, probesAdapter);", "代码覆盖率度量 EclEmma EclEmma 是基于 JaCoCo Eclipse"]}, {"no": "5.3", "title": "持续集成", "paras": ["持续集成测试内容 单体架构的集成测试 微服务架构的集成测试 持续集成及其测试 CI/CD 流水线；单体架构的集成测试 自顶向下 自底向上；单体架构的集成测试 混合策略；微服务架构；微服务架构的集成测试 测试外部的通信以确认通信是否通畅，检查核心功能即可，有助于发现任何协议层次的错误，如丢失 HTTP 报头、SSL 使用错误，以及请求/响应不匹配等 数据库访问测试旨在确保微服务所使用的数据结构与数据库相符，以及检查 ORM 中 设置的映射关系、数据库访问模块能否妥善地处理网络出错等 ORM Object Relational Mapping", "微服务架构的集成测试 消费者驱动的契约测试 Consumer Driven Contract Testing, CDC testing 规定的是接口的调用者（ Consumer/ 消费者）和被调用者（ Provider/ 提供者）之间约定的 Request Response 数据交互格式 另一种观点：用契约测试或协议测试来做集成测试 Consumer 的需求出发设计测试用例并产生一份契约，然后验证 provider 端的功能 一份契约", "测试及其优势 降低服务集成的难度，将其分解为单元测试和接口测试 团队能以一种离线的方式完成验证，并将联调的成本几乎降到零 基于契约让接口的变更有迹可循 常用的 CDT 框架 Janus、Pact、Pacto和Spring Cloud Contract；示例： CDC 测试框架 https://docs.pact.io/；Consumer Stub server", "Provider https://github.com/pact-foundation/pact-provider-verifier/ Contract verifier tests Auto- generate Contract.groovy Call API；Server side service provider Client side service concumer", "如何获取接口信息 Swagger 生成的动态接口文档示例；Mock 技术解除微服务之间的依赖 Mock Service B 微服务 SUT Mock Service C 微服务 API Test 微服务 Mock 请求和响应信息示例；CI/CD 与持续；CI/CD 流水线；倒逼持续测试 持续交付 持续部署 持续测试 持续集成 持续构建；CI/CD 流水线", "示例： Amazon CI/CD；CI/CD 流水线 代码提交 定时触发 事件触发 人工触发 排队限流 Sonar增量扫描 静态扫描 安全扫描 单元测试 自动化测试 代码跨数据 中心同步 编译结果预推送 部署STG 质量门禁 灰度环境 生产环境 制品预推送 动态扩容；持续测试的特点 足够快 整个测试过程要快，一方面高度自动化测试，另方面业务端到端的探索式测试 准确且有效 被测系统往往很复杂，不可能做全回归测试，而是要推行精准测试 平滑有序 打通整个测试过程：测试左移到测试右移、单元测试到系统测试、静态测试到动态测试 CI/CD 与研发的持续构建、持续集成、持续部署、运维等环境的集成", "持续测试实践框架 扫码下载 持续测试白皮书；本章小结 深刻理解代码规范和代码评审的价值，持续进行代码评审，采用互为评审、集体评审，团队有多方面的收益 代码分析工具的使用，今天很流行，包括开发本地扫描代码、与 CI/CD 流水线集成等。 深刻理解单元测试（ ）的价值和 xUnit 框架实现的机制，重视单元测试，掌握 JUnit 这类工具和 mock 工具的使用技巧 单元测试是否充分，需要衡量代码语句 分支覆盖率，一般会使用覆盖率工具进行自动分析 今天提倡持续测试，以促进持续交付；契约测试值得关注，从开发自测开始，比较彻底保证质量", "：单元测试 JUnit 工具，针对 Spring Unit Testing 控制器代码中 ItemController 类进行测试，编写对应的测试类以完成单元测试，最终提交测试代码。", "学习资源推荐 程序开发人员测试指南：构建高质量的软件 ，人民邮电出版社， 2018.5 敏捷测试 ，人民邮电出版社， 2021.8 《 Java 微服务测试 ， 电子工业出版社， 2019.7 https://junit.org/junit5/ https://docs.pact.io/"]}], "6": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 系统功能测试"]}, {"no": "6.1", "title": "功能测试方法与过程", "paras": ["功能测试方法与应用 功能测试要求和基本思路 测试需求分析方法 探索式测试及其测试实践 SBTM 回归测试及其策略 精准测试；系统功能测试究竟测什么？ 功能（ Function 逻辑（ Logic 接口（ API 界面（ 数据（ Data 操作（ Operation 平台（ Platform；系统功能测试应该考虑哪些问题？", "系统功能 测试的基本思路；系统功能 测试的基本思路；的功能测试；HTTP https://www.w3.org/Protocols/ request-line headers blank line request-body status-line headers blank line response-body；Webservice WebService是一个不依赖于语言、平台的SOA的架构，可以实现基于Http协议、不同语言（通过 xml 描述）间的相互调用、网络应用间的交互。 Soap (Simple Object Access Protocol) ，XML Web Service 的通信协议（调用方法的规范），支持不同的底层接口，如HTTP(S)、SMTP WSDL (Web Services Description Language) ， XML 文档 用于说明一组 SOAP 消息以及如何交换这些消息 UDDI (Universal Description, Discovery, and Integration) 根据描述文档来引导系统查找相应服务的机制。UDDI利用SOAP消息机制（标准的XML/HTTP）来发布、编辑、浏览以及查找注册信息。采用XML格式来封装各种不同类型的数据，发送到注册中心或者由注册中心返回所需数据", "的功能测试 重点测试功能逻辑，按功能、子功能、功能点等层次展开测试 基于输入域和组合测试等方法（见第 章）进行输入的设计，驱动测试，并观察输出 扮演用户角色，从应用场景来遍历用户使用产品的主要操作路径 针对不同设置 进行测试 用户界面测试"]}, {"no": "6.2", "title": "自动化", "paras": ["功能测试自动化 面向接口的自动化测试 Web 客户端的 自动化测试 Cypress 自动化测试 Android 应用的 自动化测试 iOS Appium 内容，可以在第 章进行讨论 或让学生参考教材 6.2.5 6.2.6 小节在课外实践、自主学习；分层自动化测试 单元测试更容易实现自动化测试， RoI 也更高（收益显著） API 自动化测试也基本能做到 100% 适当加强手工端到端测试（业务层） 概括起来：以底层测试、接口测试、功能逻辑测试等为主，尽量避免 缺陷更易定位 效率更高 反映真实需求 更加接近业务", "API 自动化；API API 的来源 文档化工具 手工录入 程序扫描 HAR API RAML Swagger Markdown 场景设定 选择和组装 API 基于场景的测试用例 手工组装 HAR 批量生成 代码迁移 触发回归 结果展示 按需回归 定时回归 即时触发 事件触发 RAML RESTful API 描述性语言 HAR ：基于 JSON 、储存 HTTP 响应信息的文件格式", "API 测试流程 HAR 过滤与保存 脚本的修改 Thrift code_gen Dynamic Class Loading Dynamic Call Method 动态测试 Thrift API 的接入步骤 批量生成；Swagger 测试示例；API 测试示例；API；API Mockbin ：可从 HAR 文件生成一个模拟桩 RAP ：淘宝开发的 API 管理工具 Swagger ：流行的 API 定义工具、规范 Easy Mock swagger 生成数据 Doclever ：编写 REST 接口文档，生成测试数据 Mocky ：无需登录，直接生成 response kristofa/mock-http-server wiremock SoapUI Rest-Assured SOAtest APIfortress", "Rest-Assured http://rest-assured.io/ { \"lotto\": { \"lottoId\":5, \"winning-numbers\":[2,45,34,23,7,5,3], \"winners\":[ \"winnerId\":23, \"numbers\":[2,45,34,23,3,5] \"winnerId\":54, \"numbers\":[52,3,12,11,18,22] @Test public void lotto_resource_returns_200_with_expected_id_and_winners() when(). get(\"/lotto/{id}\", 5). then(). statusCode (200). body(\" lotto.lottoId equalTo (5), lotto.winners.winnerId hasItems (23, 54)); http://localhost:8080/lotto/{id} REST-assured 是一个用于测试和验证 RESTful 服务的 Java DSL 使得为基于 HTTP RESTful 服务编写测试变得更加简单 https://github.com/rest-assured/rest-assured", "Rest-Assured 参数化 given(). formParam formParamName ”, “value1”). queryParam queryParamName ”, “value2”). when(). post(“/something”); given() param( \"param1\" \"value1\" param( \"param2\" \"value2\" when() get( \"/something\" when() get( \"/name?firstName=John&lastName=Doe\"", "Rest-Assured JUnit；REST API；自动化 Web 客户端的 自动化测试 Cypress 自动化测试 Android 应用的 自动化测试；Web 的自动化测试 Project name Base URL 设定： Chrome 的插件 Selenium IDE；Web 的自动化测试；Selenium 支持不同脚本语言；Selenium + WebDriver", "WebDriver；UI Object；Page Objects http://code.google.com/p/selenium/wiki/PageObjects；PageFactory http://code.google.com/p/selenium/wiki/PageFactory；Cypress 自动化测试 https://www.cypress.io/", "Cypress；安装和使用简单 https://docs.cypress.io/_nuxt/videos/installing-cli.3465fe6.mp4 /your/project/path npm install cypress --save-dev https://docs.cypress.io/guides 打开： npx cypress open", "Cypress；Cypress；Android App UI 自动化测试 Robotium native/web) UIAutomator MonkeyRunner Android SDK tool Appium Espresso Selendroid native ATAF TestComplete；两种基本的自动化测试机制 Appium 是基于 UIAutomator 实现的。 Appium 测试进程与目标应用进程是分开的，所以 不能直接访问目标应用元素属性进行操作 只能模拟触发事件对目标应用进行操作 Robotium Espresso Seledroid 是基于 Instrumentation 的，其测试进程与目标应用是在同一个进程中作为两个不同的线程运行的", "几款常见的测试工具比较；Instrumentation 以通过从签名来实现让系统认为测试App和被测App是同一个进程 myAppTests.apk Instrumentation 技术控制被测myApp.apk myAppTests.apk 文件是由 InstrumentationTestRunner 进行控制各种方法运行；InstrumentationTestRunner TestCase 包中的类进行单元 性能测试。一般来说，这些都是从下列类继承而来 ActivityInstrumentationTestCase2 ActivityUnitTestCase AndroidTestCase ApplicationTestCase InstrumentationTestCase ProviderTestCase ServiceTestCase SingleLaunchActivityTestCase 在测试包的清单中设置 < instrumentation> 元素的 android:targetPackage 属性，将该属性值设置为 AUT 的包名 adb shell am instrument -w instrumentation ，没有可选参数，以运行所有测试（除了性能测试） 参数为 func true' 运行所有功能测试。这些是源自 InstrumentationTestCase 的测试 e unit true' 运行所有单元测试。这些是不从 InstrumentationTestCase 派生的测试（不是性能测试） class' 设置为运行单个 TestCase AUT App under test https://developer.android.com/reference/android/test/InstrumentationTestRunner", "Monkeyrunner InstrumentationTestRunner 是针对被测 app 而运行测试脚本的执行器 Test tools ：即与 Eclipse IDE 集成的、构建测试的 SDK tools MonkeyRunner API 开发测试脚本，以便能在 Android 代码之外来控制设备 Test package 被组织在测试项目中，遵守命名空间 Test case classes python 脚本实现复杂测试用例的 测试工具，通过坐标、控件 来操作应用的 元素，截取测试执行的 界面，进行图像比较分析来发现问题", "Monkeyrunner MonkeyRunner class 提供了用于将 monkeyrunner 连接到设备或模拟器的方法，也提供了用于为 monkeyrunner 程序创建界面以及显示内置帮助的方法。 MonkeyDevice 代表设备或模拟器，提供了用于安装和卸载软件包、启动 Activity 以及向应用发送键盘或轻触事件的方法、运行测试软件包。 MonkeyImage 提供了用于截屏、将位图转换为各种格式、比较两个 MonkeyImage 对象以及将图片写入文件的方法。 monkeyrunner API 可以跨多个设备或模拟器应用一个或多个测试套件，可以基于 API python 开发一整套自动化系统", "Monkeyrunner；Robotium 支持对 native WebView 的操作 能自动的支持多个安卓 Activities 有单独的录制回放工具 可以和 Mave Gradle Ant 等工具进行集成 https://github.com/RobotiumTech/robotium 能够对各种控件进行操作，模拟各种手势操作、查找和断言机制的 API", "Robotium 脚本示例；UI Automator 测试框架 用于检查布局层次结构的查看器 用于检索状态信息并在目标设备上执行操作的 API 支持跨应用界面测试的 API；UI Automator Viewer；访问设备状态 UI Automator 测试框架提供了一个 UiDevice 类，用于在运行目标应用的设备上访问和执行操作，包括设备属性（屏幕方向或显示屏尺寸等），还能执行以下操作： 改变设备的旋转 按硬件键，如“音量调高按钮” 按返回、主屏幕或菜单按钮 打开通知栏 截取当前窗口的屏幕截图 https://developer.android.google.cn/reference/androidx/test/uiautomator/UiDevice?hl=zh-cn", "UI Automator https://developer.android.com/tools/testing-support-library/index.html Espresso 可以写出类似白盒测试那样的、更美观的自动化测试脚本，可充分利用被测 app 所实现的程序代码，而且能够实现 线程同步，解决了 可能存在的 并发问题，能够改进测试的可靠性。 View matching ViewMachers View 构建的、灵活的 API ，借助 onView 方法来定位 UI layout view ，且支持多层次 view 的定位。 Action APIs ViewActions 一系列扩展的、以完成 交互操作 API 集，即借助 ViewInteraction.perform 方法来完成 view 的操作。 ViewAssertions ViewInteraction.check 方法来判定当前所选定 view 的状态，以完成测试所需的验证。", "UI Automator API UiCollection 枚举容器的界面元素，目的是为了计数，或者按可见文本或内容说明属性来定位子元素。 UiObject 表示设备上可见的界面元素。 UiScrollable 支持搜索可滚动界面容器中的项目。 UiSelector 表示对设备上的一个或多个目标界面元素的查询。 Configurator 可设置用于运行 UI Automator 测试的关键参数。", "UI Automator 代码示例；为什么需要进行回归测试？ 以前都正常的，新的版本反而不正常了 回归缺陷 (Regression bug)；为什么要有回归测试？", "回归测试 一旦程序某些区域被修改了，就 影响原来正常工作的区域，导致 受影响的区域出现回归缺陷。 回归缺陷 ：原来正常工作的功能，没有发生需求变化，而由于受其它改动影响而产生的问题。 回归测试就是为了发现回归缺陷而进行的测试 如果没有回归测试，产品就带着回归缺陷被发布出去了，造成严重后果。 Regression Testing；如何进行回归测试？ 范围？ 策略？", "再测试全部用例 基于风险选择测试 基于操作剖面选择测试 再测试修改的部分；精准测试 测试覆盖率分析 代码和测试用例之间的关系 代码依赖性分析 基于上述工作，可以精准地完成回归测试；测试用例与代码映射关系 测试用例 测试用例；代码依赖性分析；测试覆盖率分析；本讲小结 基于需求、启发式测试策略进行 测试需求分析 先要明确测试目标，再进行 范围、测试项和风险等进行 ，采用分解方法，内容涉及功能、场景、数据等 探索式测试 四要素、 IAPE 、生态建设以及 SBTM 回归测试策略 精准测试", "提问与思考 自动化测试中录制脚本轻松搞定，为何没有成为功能测试自动化脚本开发的主流？ 采用开源自动化测试框架还是自己开发自动化测试框架好呢？ 大家都重视自动化测试，但往往效果不够好，问题在哪里？", "web 应用系统进行功能测试 基于本 所学的测试方法， 进行测试需求分析，按优先级列出主要的测试项 以及识别出 测试风险 20+ 相对关键的 测试用例 ，以发现更多的缺陷 测试用例 思路和方法 Selenium webdriver 将之前设计的 个测试用例转化为测试脚本，如 Java 格式的脚本，在 JUnit 框架上执行和调试这些脚本。 https://www.saucedemo.com/", "学习资源推荐 接口自动化测试项目实战 ，清华大学出版社， 2021.11 从零开始学 Selenium 自动化测试 ，机械工业出版社， 2020 前端自动化测试框架 Cypress 从入门到精通 ，电子工业出版社， 2020.4 《Robot Framework 自动化测试精解 ，人民邮电出版社， 2020.4"]}], "7": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 专项测试；7.1 性能测试 7.2 安全性 7.3 兼容性测试 7.4 可靠性测试 7.5 易用性测试；7.1 性能测试 本节内容进行了优化，压力测试、容量测试和工具等具体内容可以参考教材，但核心内容都已涵盖；性能测试 性能问题是常见的问题，特别是在今天 SaaS 时代、万物互联时代 压力测试、容量测试等也并入性能测试 性能测试也可以分为静态测试和动态测试，通常意义指动态测试 性能测试一般只能通过工具来实现 性能测试的结果分析有挑战，需要良好的技术功底 性能测试与性能调优相辅相成，循环往复、不断提升性能", "性能问题；性能问题外部表现和内因 资源耗尽 CPU 使用率达到 100% 资源泄漏 如内存泄漏 ，最终会导致资源耗尽 资源瓶颈 如线程、 GDI 连接等资源变得稀缺 启动系统、打开页面越来越慢 查询数据，很长时间才显示列表 网络下载速度很低，如 5k/s；什么是性能测试？ 性能测试 performance test 就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。一般在 真实环境 特定负载 条件下，通过 工具模拟 实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析以确定系统的性能状况。 获取系统性能某些指标数据 为了验证系统是否达到用户提出的性能指标 发现系统中存在的性能瓶颈，优化系统的性能 性能测试目标", "负载（ Workload 每次请求发送的数据量 (Request Per Second, RPS 并发连接数 (Simultaneous Connections, SC) 思考时间 thinking time ），用户发出请求之间的间隔时间 RPS + SC + Thinking Time = Concurrent users；思考时间的影响 将系统置于相同的高负载下，将请求之间间隔时间设为零。这样服务器会立即超载，并形成越来越长的等候队列，直至内存耗尽 间隔时间长 间隔时间为零", "负载模式 加载的循环次数或持续时间 加载的方式或模式，如均匀加载、峰值交替加载等；示例： 系统负载测试；性能测试类型 性能基准测试 ：在系统标准配置下获得有关的性能指标数据，作为将来性能改进的基线 (Baseline) 性能验证测试 ：验证系统是否达到事先已定义的系统性能指标、能否满足系统的性能需求 性能规划测试 ：在多种特定的环境下，获得不同配置的系统性能指标，从而决定系统部署的软硬件配置选型 容量测试 可以看作性能的测试一种，因为系统的容量可以看作是系统性能指标之一", "性能测试类型 压力测试 (Stress test) ：模拟实际应用的软硬件环境及用户使用过程的高负载、异常负载、超长时间运行，从而加速系统崩溃，以检查程序对异常情况的抵抗能力，找出性能瓶颈、不稳定等问题。 渗入测试 soak test ），通过长时间运行，使问题逐渐渗透出来，从而发现内存泄漏、垃圾回收（ ）或系统的其他问题，以检验系统的健壮性 峰谷测试 peak-rest test ），采用高低突变加载方式进行，先加载到高水平的负载，然后急剧降低负载，稍微平息一段时间，再加载到高水平的负载，重复这样过程，容易发现问题的蛛丝马迹，最终找到问题的根源", "示例：压力测试；性能测试的层次 Web/App 客户端 应用服务器 数据库访问层 RDBMS 数据库 端口连接 网络通信；全生命周期 性能测试 系统架构 性能需求 （包括 运维需求 业务场景 业务数据 性能测试策略 性能需求和计划评审 架构评估 性能测试策略 性能需求调整修改 执行性能测试 定位性能瓶颈/优化 经验积累 性能建模 性能数据 性能数据", "从需求开始明确性能 最终用户的体验 2-5-10 商业需求 ，如“比竞争对手的产品好” 技术需求 CPU 使用率不超过 标准要求，如数据通信延时 <80ms 用户关注系统的外部表现，如响应时间 业务部门关注系统的容量和数据吞吐量 技术团队关注系统资源占用率、或使用效率 （获取、分析和评审性能需求）；性能需求可测试性 每天要处理 一千万笔交易 清楚而 的性能指标 每秒平均处理约 130 笔交易 高峰期间处理要求是平均值四倍 笔交易／秒", "架构设计评审；代码评审 性能问题 使用 String 的性能是最差 java 代码性能优化总结；性能测试设计与执行 网络及其配置 服务器硬件选型 被测试系统部署 数据库数据量 测试机器池 SUT 测试机 分析器 Web 服务器 数据库 服务器 服务器 被测系统 SUT 产生虚拟用户和负载；测试执行和监控 服务时间 数据库时间 网络时间 数据返回时间 客户端时间 DNS 网络时间 应用处理返回时间 服务时间", "性能测试工具 Google Lighthouse PerfDog Monkey Monekyrunner mobileperf Pyroscope MemoryLeakDetector 客户端性能测试工具 服务器端性能测试工具 JMeter LoadRunner Webload Gatling Vegata Locust Skywalking 详见我之前写的文章", "客户端 PerfDog 详见：教材 P201-203 ，和官方网站 https:// perfdog.wetest.net；性能测试工具 JMeter https://jmeter.apache.org/index.html 测试计划 线程组 取样器 逻辑控制器 后置处理器 监听器；JMeter JMeter 工作台 测试计划 线程组 Thread Group Test Fragment 远程运行控制器 HTTP Proxy 逻辑控制器 Logic Controllers 采样器 Sampler 配置元件 定时器 前置处理器 后置处理器 监听器 setup teardown Log View Templates 函数助手", "JMeter 支持的协议 Web - HTTP, HTTPS SOAP / REST Webservices FTP Database via JDBC LDAP JMS Mail - SMTP JSR223 TCP Java Objects；cli （命令行） 模式 GUI 方式运行 指定运行的测试脚本的地址与名称，可以是相对路径，相对路径的根是命令窗口 的当前路径 指定读取 JMeter 属性文件 记录测试结果到文件 以服务器方式运行（远程方式，启动 agent 停止远程运行 设置代理，一般填写代理 ：设置代理端口 代理账号； ：代理口令 JMeter 属性，等同于在 jmeter.properties 中进行设置 定义系统属性，等同于在 system.properties 中进行设置 加载系统属性文件，可以通过此参数指定加载一个系统属性文件，此文件可以用户自己定义 JMeter 日志级别，比如 DEBUG,INFO,ERROR 开启远程负载机（非 GUI 方式），远程机列表在 jmeter.properties 中指定 JMeter home jmeter n -t my_test.jmx log.jtl my.proxy.server P 8000", "JMeter 录制功能 逻辑控制单元： 录制控制器 非测试元件： HTTP 代理服务器 在浏览器或网络中设置 HTTPS；JMeter 支持分布式环境 JMeter GUI 92.168.0.1 JMeter server 92.168.0.10 JMeter server 92.168.0.11 JMeter server 92.168.0.19 Web Sever 被测试系统 Slaves Requests Requests Requests Master jmeter.properties", "JMeter Plugins Manager jmeter-plugins-manager-1.8 .jar jmeter_Home /lib/ ext 目录下面；插件示例；JMeter 更多参考 http://wiki.apache.org/jmeter/ http://jmeter.apache.org/usermanual/index.html", "性能分析；Tuning；性能监控；全生命周期的性能测试 性能需求收集与定义 内建性能（设计中） 性能建模 单元性能测试 代码优化 性能测试 & 容量管理 代码质量 与性能 性能测试与 工程策略 性能监控 业务度量， DoD 性能度量 KPI Dashboard 环境验证 测试执行 基线、生产负载、可伸缩性等） 容量管理；本节小结 了解性能测试的不同目的（性能测试类型） 清楚一些基本概念：负载、负载模式、虚拟用户、性能指标 性能测试会涉及架构评审、代码评审、性能调优 熟练使用性能测试工具（如 JMeter", "4-1 ：基于 JMeter 的后端性能测试 选一个 web 应用，需要用户登录的 使用代理服务器 录制控制器录制脚本 选用插件，设置线程组相关参数 会使用 2-3 种控制器 会配置 2-3 种采样器 会使用 HTTP 授权、 cookie 管理器 会设置断言 会使用 JDBC 连接预处理 会使用 2-3 种监听器（如查看树、响应时间、吞吐量） 性能测试报告 word 格式，含测试系统、环境、场景设计、执行和结果分析） 性能测试脚本 jmx 文件）", "4-2 ：基于 PerfDog 的客户端性能测试 PerfDog https:// perfdog.wetest.net ，下载正确的桌面应用程序； USB 连接手机，自动检测添加手机到应用列表中。 设定测试模式（ USB 模式测试或 WIFI 模式测试）； 选择被测试的 App 应用开始测试； 测试过程中采集性能数据； 保存测试结果； 进行测试数据统计与分析； 编写测试报告。"]}, {"no": "7.2", "title": "安全性", "paras": ["知道它们的区分吗？ 黑帽黑客 白帽黑客；威胁模型与安全漏洞模式 安全性测试的范围与方法 贯穿研发生命周期的安全性测试 Web 安全性测试 安全性测试工具 安全性；威胁模型与安全漏洞模式；安全性缺陷 脆弱性 vulnerability ），又称弱点或漏洞 系统中存在的可能被威胁利用造成损害的薄弱环节，脆弱性一旦被威胁成功利用就可能违犯安全策略 系统（资产）造成损害", "安全性：漏洞来源 恶意：木马病毒、陷门、逻辑 定时炸弹 非恶意：如隐秘通道 校验错误 范围错误 串行错误 认证／鉴别错误 边界条件错误 其它可利用的逻辑错误；危险、攻击手段 预攻击（扫描） 后攻击 常规信息获取 漏洞扫描 社会工程学 搜索引擎 信息收集 Ping/telnet/ whois Traceoute 端口扫描 snmp,superscan DoS 远程渗透 口令猜测 远程溢出， getadmin 应用攻击： SQL 权限提升（本地溢出、口令嗅探等） 痕迹擦除", "攻击带来的安全性问题 信息泄露 破坏信息的完整性 拒绝服务（ DoS DDoS 非法使用 非授权访问 、窃听 业务数据流分析 、旁路控制 授权侵犯 （内部攻击） （来自用户的攻击） 计算机病毒、恶意软件 信息安全法律法规不完善；软件系统安全威胁： STRIED poofing Identify) ampering) epudiation) 信息泄露 nformation) 拒绝服务 enial of Service, DoS ) 特权升级 levation of Privilege, EoP http://techdo.me/identity-spoofing-and-how-to-protect-yourself-from-it/", "一些常见的安全漏洞模式 缓冲区溢出漏洞 图像格式 (WWF/TIFF/PNG) 竞争条件漏洞模式 SQL 跨站脚本攻击（ XSS 跨站请求伪造攻击（ CSRF Frame-proxy 攻击漏洞 并发漏洞；常见的 C++ 缓冲区溢出问题 strcpy (char * dest , const char * src 可导致 dest 缓冲区溢出 strcat(char *dest, const char *src) 可导致 dest 缓冲区溢出 getwd (char * buf 可导致 buf 缓冲区溢出 gets(char *s) 可导致 缓冲区溢出 [vf]scanf(const char *format, ...) 可导致参数溢出 realpath(char *path, char resolved_path[]) 可导致 path 缓冲区溢出 [v] sprintf (char *str, const char *format, ...) 可导致 str 缓冲区溢出", "OWASP Top10 漏洞模式 OWASP Open Web Application Security Project https://owasp.org/Top10/；安全性测试的范围与方法；安全目标 安全目标 是指能够满足一个组织或者个人的所有安全需求，通常强调 CIA 三元组的目标，即 保密性 onfidentiality) 完整性 ntegrity) 可用性 vailability) 由于这些目标常常是互相矛盾的，因此需要在这些目标中达到最佳平衡。例如，简单地阻止所有人访问一个资源，就可以实现该资源的保密性，但这样就不满足可用性。 可用性 保密性 完整性", "安全性要求 保密性 确保信息只被授权人访问，信息即使被截取也不能了解信息的真实含义 完整性 保护信息和信息处理方法的准确性和原始性，包括数据的一致性，防止数据被非法用户篡改 可用性 ： 确保授权的用户在需要时可以访问信息 真实性 ：保证信息来源真实可靠 不可抵赖性 ：用户对其行为不可否定 可追溯性 ccountability) 确保实体的行动可被跟踪 可控制性 ：对信息的传播及内容具有控制能力 可审查性 ：对出现的网络安全问题提供调查的依据和手段", "信息泄露 拒绝服务 特权升级 不可抵赖性 可用性 完整性；信息泄露 拒绝服务 特权升级 不可抵赖性 可用性 完整性；软件安全性需求 数据安全性 数据结构 安全存储 安全访问 系统安全性 用户身份认证 用户权限限制 异常处理 入口验证机制 系统强壮性设计；示例：系统安全性问题 对用户口令有多少防范措施 ？", "系统安全的基本机制 主动用户、 被动文件、 存储设备 访问：读、写、执行 安全策略 安全审计 强制访问控制；安全三大保障机制；完整的安全策略示例 可接受的加密控制 可接受的使用控制 模拟线路和拨入访问控制 防病毒流程 应用程序提供上（ ASP ）控制 引入评估控制 审核和风险评估 自动转发电子邮件控制 数据库信任编码 外部网络访问控制 远程访问和 VPN 安全控制 敏感信息控制 Internet DNS 设备控制 口令保护 路由器安全管理 服务器安全管理 第三方网络连接协议 无线通信控制", "安全性测试的目标 通常的目标 （强制）访问控制 身份鉴别 完整性保护 进一步的目标 通道分析 可信路径 加密算法、代码规范 潜在的安全漏洞 数据的机密性、完整性、可用性 数据存储、传输和处理；软件安全性测试的范围 安全功能测试 (Security Functional Testing) 数据机密性、完整性、可用性、不可否认性、身份认证、授权、访问控制、审计跟踪、委托、隐私保护、安全管理等 安全漏洞测试 (Security Vulnerability Testing) 从攻击者的角度 以发现软件的安全漏洞为目的。安全漏洞是指系统在设计、实现、操作、管理上存在的可被利用的缺陷或弱点", "功能性测试 vs. 安全性测试 功能性测试 软件做它应该做的事， 验证正确的输出 发现不正确的输出 (Bug) 安全性测试 软件不做它不应该做的事 ，应用输入的验证 以避免不安全的事情发生 在测试软件系统中对危险防止和危险处理设施进行的测试，以验证其是否有效；安全性测试的任务 全面检验软件在 规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应 对软件 中用于提高安全性的结构、算法、容错、冗余、中断处理等方案，进行针对性测试 条件下测试软件，以表明不会因可能的单个或多个输入错误而导致不安全状态 对安全性 关键的软件单元、组件 ，单独进行加强的测试，以确认其满足安全性需求", "安全等级 用户自主保护级 系统审计保护级 安全标记保护级 结构化保护级 访问验证保护级；不同等级的安全要求；不同安全级别的安全功能测试；安全性测试方法 静态测试方法 工具扫描 分析代码 人工评审：架构 专家安全风险评估 动态测试方法 功能测试方法 模糊测试方法 渗透测试方法 基于威胁的方法 从软件 考察其安全性，识别软件面临的安全威胁并测试其是否能够发生 基于漏洞的方法 从软件 考虑其安全性，识别软件的安全漏洞，如借助特定的漏洞扫描工具", "安全性功能测试 身份认证测试 DCE/Kerberos 、基于公共密钥等认证机制） 访问控制策略验证 （如入口访问、权限、目录等控制） 规则验证 负面测试 传输检查 存储检查 控件兼容性 示例：口令；模糊测试方法 模糊测试 ：在一个被测试程序中附加上随机数据（ fuzz ）作为程序的输入。如果被测试程序出现问题（例如 Crush , 或者异常退出），就可以定位程序的缺陷。 模糊测试的巨大优势：测试设计极其简单，系统的行为先入为主。 Fuzz Testing", "几种不同模糊器的构造 黑盒随机模糊， 对正确格式的输入数据进行随机变异，然后用这些变异的输入运行程序，看是否能够触发异常。 基于语法的模糊， 是模糊复杂格式输入的替代方法，需要指定输入格式的输入语法、哪些输入部分要进行模糊化以及如何模糊化 白盒模糊处理， 由微软研究院于 2008 年首创，这种方法包括：动态地执行被测程序，从执行过程中遇到的条件分支收集输入约束。然后，系统地逐个否定所有这些约束，并使用约束求解器求解，其解被映射到执行不同程序执行路径的新输入。使用系统搜索技术重复这个过程，试图扫描程序的所有可行的执行路径。", "American fuzzy lop AFL 是一款开源的模糊测试工具，是当今使用最广泛的 Fuzzer 这个工具在程序执行前对程序源码进行 instrumentation 以便在程序执行过程中实时获取程序的执行情况。 AFL 遗传算法 对程序的输入进行变异能够在程序运行的时候注入自己的代码， 然后自动产生测试用例进行模糊测试。简化一下，整个算法可以总结为： 将用户提供的初始测试用例加载到队列中。 从队列中获取下一个输入文件。 试图将测试用例修剪到不改变程序测量行为的最小尺寸。 使用均衡的、经过充分研究的各种传统模糊策略，重复地对文件进行变异。 如果任何产生的变异导致 插桩记录 新的状态转换，将变异的输出作为一个新的条目添加到队列中。 转到第 https://github.com/google/AFL https://afl-1.readthedocs.io/en/latest/", "变异测试 mutation testing 变异测试（Mutation Testing）是一种在细节方面改进程序源代码的软件测试方法。变异操作是模拟典型应用错误（定位代码的弱点）、或强制产生有效地测试；变异测试的方法与流程；渗透测试 采用探索式测试方式，模拟黑客可能使用的攻击技术和漏洞发现技术，对目标系统的安全做深入的探测，发现系统最脆弱的环节，直观地发现问题 利用搜索引擎 利用开源平台 收集产品资料 风险评估 与总结 价值资产 高风险模块 攻击目标 漏洞挖掘 漏洞利用 权限提升 持久化 测试报告 攻击树分析 结合攻击模式库", "渗透测试－概览 http://www.security-audit.com/ 网络发现 exploration 漏洞评估 exploitation 与报告 指纹识别 端口扫描 网络映射 主机探索 服务识别 平台识别 漏洞研究 漏洞发现 威胁分类 利用开发 概念性证明 权限提升 威胁消除 未来计划 渗透测试；渗透测试的一些具体方法 不同网段 vlan 之间的渗透 端口扫描： 利用网络安全扫描器，如 X-Scan NMAP 远程溢出 ：可利用现成的工具实现远程溢出攻击 （例如：溢出工具 SQL2.exe + 监听工具 nc.exe SQL server 1433 端口） 口令猜测 ：简单的暴力攻击程序 比较完善的字典 本地溢出 ：指在拥有了一个普通用户的账号之后，通过一段特殊的指令代码获得管理员权限的方法 Wincsrss 脚本及应用测试 ，利用脚本相关弱点获取 web 服务器 /DB 目录访问权限，甚至有可能取得系统的控制权限", "渗透测试实施策略 全程监控 ：采用类似 wireshark 的嗅探软件进行全程抓包嗅探 择要监控 ：对扫描过程不进行录制，仅仅在数据分析后，准备发起渗透前才开启软件进行嗅探 主机监控 ：仅监控受测主机的存活状态 指定攻击源 ：多方监控指定源（某主机）进程、网络连接、数据传输等 对关键系统 ，可以采用对目标的副本进行渗透测试；SDLC 安全性测试", "软件安全实施方针 软件安全是一种系统级的问题 ，需要考虑 安全机制 （如访问控制） 基于安全的设计 （如使攻击难以实施的健壮设计） 软件安全必须成为完整的 软件开发生命周期方法 的一部分；全生命周期 安全性测试 将风险分析、安全测试与软件开发过程 (Security Development Lifecycle SDL) 结合起来 在软件开发的各个阶段进行误用模式、异常场景、风险分析以及渗透测试等 尽早地发现高风险的安全漏洞", "体系结构风险分析 ：设计和说明书 发现风险的例子 ：对关键数据的区分和保护很糟糕； Web 服务未能验证调用代码及其用户 系统体系 必须连贯一致，并提供统一的安全防线，应用文档清晰地记录各种前提假设，并确定可能的攻击。 体系结构风险分析 都是必需的，以揭示体系结构瑕疵，并进行评估、降低风险，否则后果严重。在软件生命周期的各个阶段都可能出现风险，因此，应采用持续的风险管理方法，并不断地监控风险", "代码评审示例；基于风险的安全测试 ：单元和系统 安全测试策略： 用标准功能测试技术来进行的安全功能性测试； 以攻击模式、风险分析结果和滥用案例为基础的基于风险的安全测试。 标准的质量保障方法 可能不能揭示所有严重的安全问题。 安全测试 是为了保证坏的事情不会发生，像攻击者一样地考虑问题很重要；Web 安全性测试；Web/ 数据库 渗透测试点 检查应用系统架构 防止用户绕过系统直接修改数据库 检查身份认证模块，用以防止非法用户绕过身份认证 检查数据库接口模块，用以防止用户获取系统权限 检查文件接口模块，防止用户获取系统文件 检查其他安全威胁", "Web 安全性 渗透测试 注入攻击（ Injection 跨站点脚本攻击（ XSS 跨站点请求伪造 (CSRF) 未能限制 URL Failure to Restrict URL Access；XSS 进行测试 XSS ：允许恶意用户将代码植入到“供其它用户使用的 web 页面” 中 例如：一般输入域中能输入： javascript:alert document.cookie 在其它页面显示，具有隐藏性 受害者的敏感数据、 session cookie 等会泄漏 更严重的是黑客能监控用户的行为、用户被迫访问其它站点", "SQL 注入式攻击 SQL 语句的编写规则，附加一个永远为“真”的条件，使系统中某个认证条件总是成立，从而欺骗系统、躲过认证，进而侵入系统 Username= Request.from (“username”) Password= Request.from (“password”) xSql =”select * from admin where username=’”& usename &” ’ and password=’”&password &” ’” Rs.open xSql.com.0.3 If not rs.eof then Session(“login”)=true Response.redirect (“next.asp”) End if ' OR '1' = '1", "XML <?xml version=\"1.0\" encoding=\"UTF-8\"?> <USER role=guest> <name>user1</name> <email>user1@a.com</email> </USER> <USER role=admin> <name>test</name> <email>user2@a.com</email> </USER> <?xml version=\"1.0\" encoding=\"UTF-8\"?> <USER role=guest> <name>user1</name> <email>user1@a.com</email> </USER>", "会话劫持 Cookie Session 判断和跟踪不同的用户，由于 Cookie 失效时间很长，攻击手段一般是盗取用户 Cookie 然后伪造 Cookie 冒充该用户，从而劫持会话。 也可以通过 XSS 来劫持，如 Cross-Site JS document.cookie 方法获得 Cookie；无效认证和 Session 管理方式 用户密码在数据库中 用明文保存、 用户登录使用 未加密连接 用户密码可以被特殊操作覆盖。 例如不正确的实现密码更改功能、恢复密码功能等都有可能造成密码被直接更改 URL Session ID Session ID timeout ，或者 session/token/SSO token 在登出的时候 失效。 用户认证信息、 Session ID 未加密连接传输", "未验证跳转 有些页面跳转会根据用户输入来决定，这就给了攻击者可乘之机，从而将用户导向恶意网站或者未授权链接。 下面页面请求根据 query string URL 字段来进行跳转，很容易伪造类似于以下的跳转链接将客户导向到钓鱼网站。 http:// www.example.com redirect.jsp?url evil.com 又如未授权用户通过下面链接跳过授权检查直接到 admin http:// www.example.com boring.jsp?fwd admin.jsp", "直接对象引用 例如一个网站通过以下代码返回客户信息 String query = \" SELECT * FROM accts WHERE account = ? PreparedStatement pstmt connection.prepareStatement (query , … ); pstmt.setString ( 1, request.getParameter acct \")); ResultSet results = pstmt.executeQuery ( ); 攻击者可以通过修改 querystring 来查询任何人的信息 http:// example.com /app/ accountInfo?acct notmyacct", "直接对象引用 https:// www.onlinebank.com user?acct 6065；功能级权限控制缺失 权限控制一般是写在代码中或者通过程序的配置文件来完成，但开发者人员容易忘记添加一些功能的权限控制代码 例如以下链接本该只有 admin 才能访问，但非 admin 用户可以直接在浏览器中访问该链接，说明网站存在功能级权限控制漏洞。 http://example.com/app/admin_getappInfo", "安全性测试；静态分析工具 100 词汇语法分析类工具 ，通过模式匹配找出特定的函数中可能导致安全问题的缺陷。使用简单、快速，但误报率比较高、很难检测出比较复杂的安全问题。主要有： ITS4 Flawfinder RATS Pscan 约束分析类工具 ，更好地分析函数的安全性，通过对解析树的分析，确定缺陷的位置。但检查缺陷范围比较有限。主要有： BOON CQUAL Splint UNO ESC/JAVA 基于模型测试的工具 ，构建程序的有限状态模型，使用形式化方法表示需要检查的安全属性，设计分析算法检测模型中存在的缺陷。这类工具有： SLAM BLAST MOPS ESP FindBugs", "常见的安全漏洞检测工具 CppCheck Findbugs C++Test/ Jtest Knocwork insight Metasploit Backtrack5 Burp Suite Nikto web scanner W3af ZAP Fortify SSC 详见我之前写的文章；十大漏洞对应的工具 102 注入式攻击 注入类漏洞 跨站点脚本 (XSS) 无效的认证及会话管理功能 对不安全对象的直接引用 伪造的跨站点请求 (CSRF) 安全设置错误 加密存储的不安全因素 不限制访问者的 URL 传输层面的保护力度不足 未经验证的重新指向及转发 SQL Inject Me Zed 攻击代理（ ZAP Firefox HackBar Burp Suite Tamper Data Seride Watobo MatriXay Nikto Wikto Calomel Add-on Watcher", "Burp Suite web security testing An intercepting Proxy which lets you inspect and modify traffic between your browser and the target application An application-aware Spider for crawling content and functionality. An advanced web application Scanner for automating the detection of numerous types of vulnerability. Intruder tool, for performing powerful customized attacks to find and exploit unusual vulnerabilities Repeater tool , for manipulating and resending individual requests. Sequencer tool, for testing the randomness of session tokens Extensibility allowing you to easily write your own plugins, to perform complex and highly customized tasks within Burp 103", "Burp Suite web security testing 104；W3af 105 Web Application Attack and Audit Framework Fuzzing engine Query string POST-data Headers Cookie values Multipart/form file content URL filename URL path implements web / proxy servers which are easy to integrate into your code in order to identify & exploit vulnerabilities Fast HTTP Client Send specially crafted HTTP requests at lightning speeds. Proxy support HTTP Basic/Digest authentication User Agent faking Add custom headers to requests Cookie handling HTTP response / DNS cache File upload using multipart", "本讲小结 106 基于模型的安全功能测试 基于故障注入的安全性测试 模糊测试 Fuzz Testing 基于白盒的安全测试 威胁模型与攻击树理论 形式化安全测试方法 语法测试 基于属性的测试 动态污 分析方法 Dynamic Taint Analysis 基于风险的安全测试；特别推荐；特别推荐"]}, {"no": "7.3", "title": "兼容性", "paras": ["碰到兼容性问题、升级失败 110；软件与硬件兼容性问题 111；软件系统之间的兼容性 112 服务器端 应用软件 中间件 /OS 第三方软件 Red Hat Enterprise Linux 7.1 Red Hat Enterprise Linux 6.6 upgrade MySQL Enterprise Edition 5.7 MySQL Enterprise Edition 5.6 upgrade", "软件系统之间的兼容性 113 服务器端 应用软件 客户端软件 Ver 2.1 客户端软件 Ver 2.2 客户端软件 Ver 3.0 中间件 /OS 第三方软件；最常见的数据兼容性问题？ 文件打不开 数据显示不对 导致系统崩溃；相同系统之间的数据兼容 客户端 版本升级 服务器端 版本升级 上传旧版 下载新版 数据文件 新版本软件 存取历史 原版本软件 schema DB schema", "不同系统之间的数据兼容 Word Editor From Microsoft Running on Windows 11 Word Editor From Apple Running on Mac OS X Spreadsheet From IBM Lotus Running on Windows 11 Network Import/Export File Import/Export File Load/Save Cut, Copy, Paste Backup", "数据兼容性更复杂的案例 导入下列格式文件 下列格式文件 读取已有文件 (better) 另存为；软件环境 兼容性测试 Pairwise 组合测试、正交实验法 根据市场调查数据，设计组合矩阵表 移动设备 Win 10 Win 11 Linux OS X iOS 16 Android WP10 IE 10 IE 11 Edge Firefox Chrome Safari BB10", "向后兼容 可使用之前版本的数据 向前兼容 可使用未来版本的数据 导入／导出 硬件兼容 系统之间兼容 数据之间兼容；7.4 可靠性 增加了现在流行的全链路压测和混沌工程 全链路压测属于稳定性工程，但也可以算性能测试的一类；可靠性测试方法 可靠性： 在规定的一段时间和条件下，软件能维持其性能水平的能力有关的一组属性，可用成熟性、容错性、易恢复性三个基本子特性来度量。 成熟性度量 通过错误发现率 DDP Defect Detection Percentage ）来表现。 DDP 越小，软件越成熟 DDP= 测试发现的错误数量 已知的全部错误数量 容错性 测试在下面一节介绍 恢复性的测试先设法（模拟）使系统崩溃、失效等，然后计算其系统和数据恢复的时间来做出易恢复性评估。", "容错性测试 容错测试 是一种对抗性的测试过程。在这种测试中，通过各种手段让软件强制性地发生故障，或将把应用程序或系统置于（模拟的）异常条件下，以产生故障，例如设备输入 输出（ ）故障或无效的数据库指针和关键字等 之前有故障注入测试，现在有混沌工程，目前掌握混沌工程更有意义；全链路压测；全链路压测的需求；系统流量控制 预分拣 任务分发 下游系统（系统、机房、分组） & & 应用集群（线上集群） Docker1 Docker2 Docker3 Docker4 Docker5 Docker6 Docker7 Docker8 Docker9 互联网 生产流量 & &", "压测平台原理示意图 控制台 CDN CDN CDN CDN 压力机引擎 压力机引擎 压力机引擎 压力机引擎 IDC 压力机引擎 IDC 压力机引擎 IDC 压力机引擎 IDC 压力机引擎 购物车 结算页 内网入口 公网入口；压测平台原理示意图 压测人员 前端页面 脚本仓库 数据库 任务调度服务 结果采集服务 实时计算服务 Kafka VIP Agent Agent Agent 控制器", "压测数据处理过程 压测数据池 压力机 Nginx 大数据平台 核心交换机 Redis MQ（Message queue，消息队列） Redis 代表缓存；流量录制回放的过程 分光分流 Agent GoReplay 录制部分 压测平台 被测应用 回放部分 手工上传；全链路压测全流程 被压系统范围界定 场景、流量、方案 设计评审 基础数据构造 （商品、促销、优惠券等） 脚本、模型 创建调试 准备阶段 压测方案配置 （场景创建、资源准备等） 压测数据分发 发布压测实施计划 小流量验证 线上压测流量验证 校验阶段 机房流量切换 压测执行 动态调整流量 应用降级演练 机房流量恢复 压测报告生成 实施阶段", "压测平台提供的整体能力 压测平台 动态发压 峰值模拟 流量回放 智能寻值 压测数据 日志数据 链路数据 资源数据 调用数据 健康状态 水位告警 结论预研 容量预期 平台用户 单点容量 场景容量 集群容量 链路容量 评估报告 优化方案 风险建议；现在来看开源的 Takin Takin 是基于 Java 语言开发的一套生产全链路压测的系统，可以在无业务代码侵入的情况下，嵌入到各个应用程序节点，实现生产环境的全链路性能测试，适用于复杂的微服务架构系统 业务代码 ：在接入、采集和实现逻辑控制时，不需要修改任何业务代码； 数据安全隔离 ：可以在不污染生产环境业务数据情况下进行全链路性能测试，可以在生产环境对写类型接口进行直接的性能测试 安全性能压测 ：在生产环境进行性能压测，对业务不会造成影响 性能瓶颈快速定位 ：性能测试结果直接展现业务链路中性能瓶颈的节点", "Takin；Takin 界面截图；Takin 开源介绍 Takin https://github.com/shulieTech/Takin；Takin 可参考 https:// news.shulie.io /?p=2987 、 https://news.shulie.io/?p=3661 应用配置 影子库表配置 挡板配置 白名单配置 链路梳理 脚本配置 场景配置、", "JMeter；JMeter 更多参考：https://github.com/shulieTech/Takin-jmeter/blob/main/README.md；压测结果展示；压测结果展示 压测概览；小结：压测平台特点 支持协议广泛 多种发压模式 资源合理分配 多维度结果查看 HTTP/HTTPS JSF HBASE 数据库 中间件 动态发压 智能寻点 标准模式 梯度模式 集合点模式 资源灵活调度 资源重复使用， 减少拉取时间 统筹压力机调度 压测数据秒级反馈 动态增减压结果 自动分段展示 结果区间计算 应用监控结果采集", "混沌工程；从复杂到混沌 Source: Data Center Knowledge；服务中断 小时所带来的损失 © Statista 2022 来源：混沌工程实验室 公司产品可用性 >87.6 >52 >8.7 <5；稳定性风险集中治理 故障画像 异常场景类 节点异常状态下的表现 异常场景下的预案是否完善 链路设计类 各类链路异常预案的正确性、有效性问题，预案验证的常态化问题 预案设计类 故障发生缺乏标准化流程 快速恢复止损优于问题排查 稳定性风险 应用问题 组件问题 网络问题 进程僵死 系统问题 线程池满 连接池满 依赖超时 依赖异常 内存泄漏 慢查询 异步阻塞 缓存异常 热点问题 同步问题 网络抖动 重试风暴 带宽问题 网卡问题 跨机房 CPU 内存争抢 节点异常 集群异常", "混沌工程出现：以毒攻毒 Google searches for \"Chaos Engineering\" 混沌工程 (Chaos Engineering) 分布式系统的实验学科，是 一套基于系统的实验以提高技术架构弹性能力的复杂技术解决方案、 在生产中抵御突发事件能力；混沌工程确实能提升系统可用性 https://www.gremlin.com/state-of-chaos-engineering/2021/", "混沌工程发展历程；混沌工程的原则 在实验中引入反映真实事件的变量，如服务器崩溃、硬盘故障、网络连接断开等 建立一个围绕稳定状态行为的假说 多样化真实世界的事件 在生产环境中运行实验 持续自动化运行实验 最小化影响范围 混沌工程 人员组织 业务应用 基础平台 基础设施 风险保护 报告改进 量化评价 演练可观测 安全审计 故障注入 故障注入 故障注入", "混沌工程关键工作 实验设计 故障画像 上下游依赖梳理 链路受力分析 爆炸半径控制 注入故障能力 稳态标准 私有云、容器化、贝壳云、 】Java Cpp PHP 接口、性能、巡检自动化 线上服务定制化稳定标准定义 链路级稳态定义和管理 灵活的稳态可接入能力 节点可控 链路可控 演练隔离机制 兜底安全策略；爆炸半径控制 实践经验： 选择最小爆炸半径 混沌实验的“分级发布”：随对系统信心增加而逐步扩大实验范围 混沌并不意味着一定要在全量生产环境实施 完备的自动化、高效预案；快速熔断能力 最小实验范围内让系统潜在问题暴露，而不会意外造成更大规模故障 实验环境 线下环境 沙盒环境 金丝雀环境 生产环境 压测流量 mock 引流流量 回放流量 流量抽样 请求粒度 压测流量 实验流量 用户粒度 多实例 测试中间件 请求粒度实验", "混沌工程的局限性 混沌工程有技术、有价值，但它的局限性也很明显 过时的疫苗不一定能增强身体的免疫力。经过混沌工程的系统可能还会继续宕机。头痛医头、脚痛医脚， 不够全面 ，而且 是人为设计的 ，局限于过去发生的故障， 发现未来出现的新的故障 无数的混沌工程将无法修复 泥浆大球 ，在混沌工程实验时发现问题，修正问题已经变得很困难 前进一步，后退两步， 在某一方面的优化工作可能会增加其他方面的脆弱性 以优美的 、自动的 注入故障 的同时，给系统增加了新的复杂性，更多的实验可能给系统更 进一步的伤害 过多关注 故障测试 ，容易导致忽视前期设计工作 和事后 的工作 “一键回滚”具有欺骗性，数据可能在回滚时已经遭到破坏", "国外的混沌工程实践： Slack 的灾难片剧场 2018 月启动，严格的流程，遵循的流程都是为了最大限度地提高学习效果，同时将生产事故的风险降到最低 详细的计划和精心的组织，每次演习都是在指定的时间内进行，专家集中在一起，包括进行探索性的演习、在运营团队中传阅响应计划。 演习的主持人记录如何 ”incite the failure 、运行哪些命令，以及哪些 Amazon EC2 实例将被涉及，还记录了所有应该被监控的日志、指标和警报 主持人会提一系列问题，如对“基于开发环境的容错性预测生产环境的容错性 有多大信心？", "Google's Disaster Recovery Program 零故障 灰色的需要恢复 构建专用架构模式，以标准化灾难恢复方法，恢复能力期望与服务中断场景相匹配 RTO ：恢复时间目标 RPO ：恢复点目标 RTO RPO RTO RPO 为 零 RTO 为 零 RPO 为 零；微软的混沌工程 uses an agent-based fault to add CPU pressure to a Linux VM with the Azure portal CLI ：az vm identity assign --ids $VM_RESOURCE_ID --identities $MANAGED_IDENTITY_RESOURCE_ID", "故障库 Time delay CPU pressure Physical memory pressure Virtual memory pressure Disk I/O pressure (Windows) Disk I/O pressure (Linux) Arbitrary Stress-ng stress Stop Windows service Time change Kill process DNS failure Network latency Network disconnect Network disconnect with firewall rule ARM virtual machine shutdown ARM virtual machine scale set instance shutdown Cosmos DB failover AKS Chaos Mesh network faults AKS Chaos Mesh pod faults AKS Chaos Mesh stress faults AKS Chaos Mesh IO faults AKS Chaos Mesh time faults AKS Chaos Mesh kernel faults AKS Chaos Mesh HTTP faults AKS Chaos Mesh DNS faults Network security group (set rules) Azure Cache for Redis reboot Cloud Services (Classic) shutdown Key Vault Deny Access AKS Azure Kubernetes Service https://docs.microsoft.com/en-us/azure/chaos-studio/", "可观察性；优秀实践 复杂系统韧性 实现之道 来源：中国信息通信研究院，2021年；优秀实践 从灾难中学习、细化实验目标；示例：基于历史问题抽象建设通用故障库 存储热点 内存抢占 读写拒绝 cpu 连接打满 基础架构 业务应用 基础设施 网络抖动 网络拥塞 网络中断 dns 磁盘读写慢 网卡打满 实例迁移 实例部署 格式错误 业务攻击 core oom 配置错误 性能下降 依赖超时 性能下降 环境错误 ……………. ……………. …………….", "优秀实践 从线下到生产、从小到大 测试环境-> Staging 环境 -> 预览环境特定流量 -> 生产集群全流量 可控流量 > 单个接口 > > 单集群 > 单机房 > 全链路；优秀实践 混沌工程可观察性；优秀实践 采用开源混沌工程平台 KubeInvaders https://github.com/lucky-sideburn/KubeInvaders Chaos Toolkit https://github.com/chaostoolkit/chaostoolkit/ Litmus Chaos https://github.com/litmuschaos/litmus Chaos Mesh https://github.com/chaos-mesh/chaos-mesh chaoskube https://github.com/linki/chaoskube kube monkey https://github.com/asobti/kube-monkey Open Source solutions for chaos engineering in Kubernetes https://blog.container-solutions.com/comparing-chaos-engineering-tools", "ChoasBlade https://github.com/chaosblade-io/chaosblade Chaosblade 是阿里内部 MonkeyKing 对外开源的项目，是在十年故障测试和演练实践基础上不断演化而成，支持丰富的实验场景： 基础资源：如 CPU、内存、网络、磁盘、进程等 Java 应用：如数据库、缓存、消息、JVM 本身、微服务等，还可以指定任意类方法注入各种复杂的实验场景； C++ 应用：如指定任意方法或某行代码注入延迟、变量和返回值篡改等； Docker 容器：比如杀容器、容器内 CPU、内存、网络、磁盘、进程等； 云原生平台：比如 Kubernetes 平台节点上 CPU、内存、网络、磁盘、进程实验场景， kill Pod、 kill docker", "ChoasBlade 关键组件 chaosblade 混沌实验的执行工具，执行方式包含 CLI HTTP 两种，包含创建实验、销毁实验、查询实验、实验环境准备、实验环境撤销等命令，并提供完善的命令、实验场景、场景参数说明 chaosblade-exec-os 基础资源实验场景实现。 chaosblade-exec-docker Docker 容器实验场景实现，通过调用 Docker API 标准化实现。 chaosblade-exec-cri 容器实验场景实现，通过调用 CRI 标准化实现。 chaosblade-operator Kubernetes 平台实验场景实现，使用 Kubernetes 资源操作的方式来创建、更新、删除实验场景，包括使用 kubectl client-go chaosblade cli 等方式执行 chaosblade-exec-jvm Java 应用实验场景实现，使用 Java Agent 技术动态挂载 chaosblade-exec-cplus : C++ 应用实验场景实现，使用 GDB 技术实现方法、代码行级别的实验场景注入 chaosblade-spec-go 混沌实验模型 Golang 语言定义，便于使用 Golang 语言实现的场景", "ChaosBlade；一个简单的演示 更多内容请参考：https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/；云原生架构下混沌工程引入 单点故障容忍能力 混沌工程注入单实例故障 SLA 等无波动，业务不受影响 状态可感知 混沌工程注入故障 PaaS 能及时感知实例故障，异常实例能自动迁移成功，且业务指标不受影响 naming service 混沌工程注入故障 异常实例迁移正常，异常实例变化不影响上游对该服务的访问，业务不受影响 部署满足单一包描述 混沌工程注入故障 引发服务扩容， PaaS 平台自动执行，而不用其他前置或者后置人工操作 从而引出面向云原生的Chaos Mesh", "Chaos Mesh 2019.12.31 Open sourced on GitHub CNCF Cloud Native Interactive Landscape 2020.2.6 2020.7.14 CNCF Sandbox project 2021.7.23 2.0 GA 1.0 GA 2020.9.26 Started out as a testing framework “Schrödinger’s Cat” for TiDB 2019 2.1 GA 2021.11.30 2022.2 CNCF Incubating project https://chaos-mesh.org/website-zh/ CNCF ：Cloud Native Computing Foundation CNCF 基于著名的鸿沟理论开展项目管理，将项目分为 沙盒项目 Sandbox) 孵化项目 Incubating) 毕业项目 Graduated)", "声明式 API 定义简化混沌实验管理 PodChaos NetworkChaos IOChaos TimeChaos StressChaos KernelChaos ... CRD (Custom Resources) Kubernetes API；Chaos Mesh 架构 Chaos Dashboard：通过 UI 界面管理和监控混沌实验 Chaos Controller Manager 调度和控制组件 编排引擎 Chaos Daemon：K s 环境执行组件 Chaosd：non-K s 环境执行组件", "监听资源变化 监听 PodChaos, NetworkChaos… 等资源的创建/更新/删除 决定当前该 注入 / 恢复 / 等待 进行简单的注入，比如 PodKill 向 Chaos Daemon / Sidecar 发送请求；故障如何注入？ 监听 PodChaos, NetworkChaos… 等资源的 创建/更新/删除 Container 的实体： Namespace 控制可见性 Cgroup 限制资源 注入的实质 侵入 Namespace / Cgroup 进行干扰、注入", "使用 Chaos Mesh 定义混沌实验 apiVersion : chaos mesh.org /v1alpha1 kind: PodChaos metadata: name: pod-failure-example namespace: chaos-testing spec: action: pod-failure mode: one duration: '30s' selector: labelSelectors app.kubernetes.io /component': ' tikv", "编排混沌实验 Workflow 主要由以下几部分构成 Workflow Entry, 作为入口 引用任一声明过的 Template Template 定义各个行为 种不同类型的模版 Serial / Parallel / Chaos / Suspend / Task Serial, Parallel, Task 允许将其他节点以引用的方式作为子节点 Workflow 需要指定一个节点作为入口（ entry 所有的节点之间形成了一个有向图 apiVersion : chaos mesh.org /v1alpha1 kind: Workflow metadata: name: <name-of-workflow> spec: entry: <refs-to-name-of-one-template> templates: name: <name> templateType : <type> name: <name> templateType : <type> ... 更多的 template Workflow template 1 template 2 入口引用任意 template", "用户场景演练；ull equest；从故障注入到混沌工程 KeChaos2.0 定义实验场景 关联注入能力 确定监测稳态标准 实验运行 爆炸半径控制 实验终止产出报告；基础服务稳定性风险治理 定义实验 做出假设 执行实验 修复问题 实验验证 KeChaos 0.1 核心基础服务稳定性风险探索 KeChaos 1.0 ：核心基础服务常态化的故障注入和异常测试、故障演练例行化", "KeChaos 的故障注入 依赖梳理 故障注入 报警验证 降级验证 链路分析 强弱依赖梳理 依赖降级梳理 其他熔断限流降级能力梳理 报备周知 历史故障画像 专注自身服务 模拟下游异常 模拟依赖异常 报警触达率 报警及时性 报警有效性 降级能力建设 限流有效性 熔断、降级有效性"]}, {"no": "7.5", "title": "易用性 A/B", "paras": ["良好的 好的用户界面包括 个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性、实用性 灵活性 舒适性；用户体验测试方法 探索式测试 ：可确定新产品应包含哪些内容和功能，可评估初步设计或原型的有效性和易用性。 评估性测试 ：在发布前或发布后对最新版本的测试，以确保用户直观使用并提供良好的用户体验。 比较性测试 ：比较两种或更多种产品或设计的易用性，并区分各自的优缺点，以确定哪种设计能提供最佳的用户操作体验。", "用户体验测试模型 GSM 从产品或功能的目标（ Goals ）出发，来分析这些目标会转化为哪些信号（ Signal ），再根据这些信号最终建立适用的、具体的度量指标（ Metric 传统的网站UX衡量指标PULSE： Page view（页面浏览量 Uptime（在线运行时间 Latency（延迟 ）、Seven-day active user（周活用户数 Earning（收益 以用户为中心的指标体系HEART Happiness（愉悦度 Engagement（参与度 Adoption（接受度 Retention（留存率）和Task success（任务完成度", "A/B 有些东西需要 Sense 但大部分东西是可以用 Science 来做判断的 ABTest 是将用户分成不同的组，同时在线试验产品的不同版本，通过用户反馈的真实数据来确定哪一个方案更好；A/B 测试特点 先验性 ：采用流量分割与小流量测试的方式，先让线上部分小流量用户使用以验证设计，再根据数据反馈来推广到全流量，减少产品损失 并行性 ：同时运行两个或两个以上版本的试验完成对比分析，而且保证每个版本所处的环境一致的，避免流程周期长的问题，节省验证时间 科学性 ：基于统计的数据来做出决策，避免主观或经验的错误决策", "ABTest 适应的场景 灰度发布 ：技术 & 算法迭代 功能优化 ：界面模块、样式风格、交互方式等 内容优化 ：推广海报、落地页、内容模块、文案等 运营优化 ：运营策略、沟通话术等；ABTest 适应的场景；核心概念 ：对应业务场景，场景之间完全独立 ：圈定了特定的用户流量，即不同的桶之间流量是互斥的。它从属于场景，一个场景可以有多个桶 ：一类实验的集合，从属于场景，一个场景可以有多个层，处于同一层的各实验之间流量互斥，处于不同层的各实验之间流量正交，各实验流量之和为总流量 ：用来验证某个决定请求处理方式的功能或策略的一部分流量，通常用来验证某个功能或策略对系统指标（如 PV/UV CRT 下单转化率等）的影响 ：指所有用户请求 流量正交 ：不同层之间流量分配方式完全独立，不会互相影响，符合 MECE", "A/B 测试：桶、层、流量；OpenResty 的多层分流模型 MurmurHash 终端唯一标识请求 URI App ，小程序 Redis 实验策略地 100 URI 具体微服务 后端具体服务程序 Cookie ABTest header Mfw_project 跨平台、语言的 ABTest OpenResty是一个基于 Nginx 与 Lua 的高性能 Web 平台，用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关 https://openresty.org/cn/", "OpenResty 分流模型的优势 非OpenResty方式 OpenResty方式 sdk接口，跨语言跨平台成本高 headermap透传，不区分语言、平台 20ms-100ms，偶有超时 1ms-2ms，无超时 侵入业务代码 无代码侵入 同步阻塞，影响业务 异常自动降级 产生二次流量 无二次流量；MurmurHash 参与算法的 Hash 因子有设备 流量层 MurmurHash 用来实现正交和互斥实验的分流，因为有两个明显的特点： 快，比安全散列算法快几十倍 变化足够激烈，对于相似字符串，比如说「 abc abd 能够均匀散布在哈希环上 ：指两个实验流量独立，用户只能进入其中一个实验。 正交： 正交是指用户进入所有的实验之间没有必然关系", "A/B 测试流程 产生实验想法 评估实验优先级 设计和开发实验 分析数据 应用结果；A/B 测试 数据流；A/B SDK 实验配置动态分发 ：实现针对场景标识 用户分流标识的一致性哈希算法，根据场景的实验流量配置，进行实验配置的动态分发 ABTest 请求日志、业务自定义日志以及监控日志 ABTest 埋点规范生成前端埋点标识 abTraceId 请求唯一标识）和 bcm 请求结果标识）、事件标识 （曝光 view 、点击、收藏、转发等 等追踪标识，用以透传到前端埋点来追踪用户行为", "A/B 测试平台功能 ABTest 元数据管理 ，包括应用、场景与实验的创建、编辑，以及配置的发布等。 ABTest 接入的开发和测试支持 。用户可以方便地查看完整可用的接入示例代码，可以输入分流用户标识进行测试，以及查询实时日志等。 实时报表和离线效果报表 。实时报表包含实时请求、点击 、转化率、千次曝光转化等相关指标数据，及其对比分析 异常监控和告警 。平台实时监控 SDK 上报的 ABTest 请求数、失败数和延迟时间等数据，一旦发现异常即发出告警", "A/B 测试评价；A/B 测试优秀实践 采用流量拦截分发的方式，摒弃了原有接口的形式，对业务代码没有侵入，性能没有明显影响，且不会产生二次流量 采用流量分层并绑定实验的策略，更精细直观地去定义分流实验 数据传输：通过在 HTTP 头部增加分流信息，业务方无需关心具体的实现语言 监控体系 用户画像等精细化定制 统计功效支持置信区间、特征值等 AARRR 模型评估实验对北极星指标的影响 AARRR 分别代表：Acquisition 获取、Activation 激活、Retention 存留、Revenue 收益、Referral 推荐。 AARRR模型 把控产品整体的成本 收入关系，用户生命周期价值 LTV) 远大于用户获取成本 CAC) 与用户经营成本（ COC 之和就意味着产品的成功", "A/B 测试优秀实践 提升平台易用性： 支持完备的 ABTest 元数据管理、应用级的角色和权限、实验的商家 或者用户分流标识的白名单 系统优化：多级缓存、 SDK 性能、实现 SDK 配置自动化和透明化、优化一致性哈希算法 支持分别针对 Java Node 示例代码 ，包括引入代码库、初始化、获取实验配置以及前端埋点等。 支持测试 预发、生产等不同的 应用环境 支持输入分流用户标识获取实验配置，以测试和还原 A/B 分流结果。 支持实时日志明细查询，查询条件包括日志类型、实验以及以及分流用户标识等。 ABTest 接入成本与易用性 ABTest 数据价值", "A/B Dashboard 120.9 No Feature Y 27% Satisfaction Improvement 153.8 Feature Y 加权满意度成绩 78% No Feature Y 6.60% Off vs On 85% Feature Y 满意比例 147.3 Feature X Off 5.5% Satisfaction Improvement 154.4 Feature X On 85% Feature X Off 2.3% Off vs On 87% Feature X On 满意比例", "A/B 测试分析 Average session length Views Content occurrences /session 28% Sessions per daily user Lifetime value per daily user 60% Subscribing occurrence per day 24% Time in subscribing per daily user 24% Sign In occurrences per daily user 32% Subscribed occurrences per daily user Daily Active Users", "多因素的 A/B +1.5 登录页面 Button Color Test New Headline Test Totally New Landing Page Another All-new Landing Page +0.8 4.0% +6.0% A/B Testing Improvements To Statistically Significant Confidence 4.5", "A/B 测试结果分析 Landing Page 01 Landing Page 02 Show Product Video No Product Video Remove Navigation Add Navigation Longer Form Page Shorter Form Page Sum newsletter Sign SUM OF AMOUNT", "逐层递进的 A/B 实验：决策树 158 {n=38, 100%} 117 {n=7, 18%} Pageviews < 8460 167 {n=31, 82%} 17 {n=4, 11%} 184 {n=16 42%} 149 {n= 5, 39%} 134 {n=7 18%} 162 {n=8, 21%} 176 {n=16, 34%} 130 {n=5 13%} 171 {n=5 13%} 171 {n=11 29%} 132 n=2, 5% 103 , 8% 124 n=3, 8% 139 n=2, 5% 142 n=2, 5% 164 n=4, 11% 196 n=1, 3% 147 n=2, 8% 154 n=3, 8% 178 n=8, 21% 198 n=2, 5% 222 n=3, 8% 121 n=2, 5% Pageviews < 7720 Clicks >= 775 Experiment >= 0.5 Pageviews < 9907 Pageviews < 9765 DOW = Mon, Wed Clicks >= 730 Pageviews < 9418 Experiment >= 0.5 DOW = Sun, Tue, Fri, Sat Experiment >= 0.5", "A/B Testin 技术架构；A/B 测试平台设计；A/B 测试后端的多级缓存 Worker Lru cache Lru_shared_dict Callback Redis Nginx Worker Lru cache Worker Lru cache mutex I/O fetch lua resty lock 命中率在 99% 命中率在 0.5 % 请求只有 0.03 % 30s 的情况下", "本节小结 兼容性测试覆盖软件于硬件、软件与软件、数据之间的兼容性，而且数据兼容更为重要，因为数据更具价值 全链路压测可看作是性能测试的的右移，全面地提升系统的稳定性。 混沌工程可看作是 故障注入测试 的右移，并提升为工程层次，遵守五项原则，践行优秀实践，熟练使用开源工具 A/B 测试是为了提高用户体验采用的科学方法，让数据说话 A/B 测试包括实验设计、流量分发控制算法等关键内容 建立一个灵活支持 A/B 测试的平台", "去搭建一个简单的 A/B 测试平台 https://www.convert.com/blog/a-b-testing/best-free-and-open-source-a-b-testing-software/ https://posthog.com/blog/best-open-source-ab-testing-tools；学习资源推荐 软件性能测试、分析与调优实践之路 清华大学出版社， 2020.7 全栈性能测试修炼宝典 JMeter 实战（第 ，人民邮电出版社， 2021.5 Web 安全攻防：渗透测试实战指南 ，电子工业出版社， 2018.7 超大流量分布式系统架构解决方案 ，电子工业出版社， 2020.3 混沌工程：复杂系统韧性实现之道 ，机械工业出版社， 2021.6 A/B 测试：创新始于试验 ，机械工业出版社， 2019.4"]}], "8": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 软件本地化测试；国际化生活的体验 去美国旅行，最感不适应会有什么？ 2/3/2009 代表哪一天， 布什（ George Bush ） 属于哪个家族？ 收到邮件，出现乱码；具体例子 中文简体、北京 开始日期： 2008 开始时间： 8:00 ， 中国 标准时间 (GMT +08:00 ， 北京 英文、纽约 Starting date: Sunday November 30 2008 Starting time: 7:00 pm Eastern Standard Time (GMT -05:00 New York)", "示例－阿拉伯语；8.1 什么是软件本地化 8.2 翻译验证 8.3 本地化测试的技术问题 8.4 本地化的功能测试；8.1 什么是软件本地化 8.1.1 软件本地化与国际化 8.1.2 字符集问题 8.1.3 软件国际化标准 8.1.4 软件本地化基本步骤 8.1.5 软件本地化测试；I18N vs. L10N I18N L10N 的基础和前提，为 L10N 做准备 L10N I18N 向特定本地语言环境的转换 I18N 是软件产品源语言开发的一部分，属于 Engineering L10N 可以独立于 Engineering ，可由第三方完成 国际化 本地化 全球化", "I18N Unicode 字符集、双字节的字符； 分离程序代码和显示内容 Hard code Header files 去定义经常被调用的代码段； 改善翻译文本尺寸，具有调整的灵活性 支持各个国家的键盘设置； 支持文字排序和大小写转换； 支持各个国家的度量衡，时区，货币单位格式等的设置； 国际化用户界面设计（自我定义）。", "国际化功能实例；L10N 地区文化、宗教 度量衡和时区等 软件用户界面（ 联机文档 帮助文档和功能性的 PDF 热键设置；8.1.2 字符集问题 字符集是操作系统中所使用的字符映射表 ASCII 字符集 Gb2312 ISO8859-X Unicode UTF-8/ UTF-16/ UTF-32；字符集问题标准 ISO/IEC 10646-1:2003 定义了 编码的通用字符集（ Universal Character Set UCS ），也称通用多八位编码字符集 Universal Multiple-Octet Coded Character Set ISO 639-1:2002 字母语种代码（ alpha-2 ）标准 ISO 3166-1:1997 ，国家代码标准 RFC 3066 ，语言鉴定标签标准 RFC 36 UTF-8", "示例： ASCII；示例： Unicode UCS-4 Unicode Character Set 0×0 0x10FFFF 字节： 0-16 个平面，后两个字节： 0-FF 0-FF 平面： BMP Basic Multilingual Plane UCS-2；示例： UTF-8 http://www.rfc-editor.org/rfc/rfc3629.txt", "8.1.3 软件国际化标准 切换语言的机制。 与语言无关的输出接口。 与语言无关的输入接口和标准的输入协议 资源文件的国际化 支持和包容本地化数据格式；I18N 国际化支持 本地化测试 MBC 字符集和脚本 MBC 输入和显示 MBC 文件（夹）及其处理 区域设置 索引和排序 本地化 OS? 键盘支持 本地化资源 区域设置 hard-coded? 串联字符串 资源文件包含非本地化内容 文字扩展余地 非层次图像的文字 其它组件 Pseudo-translation (Catalyst) 重要部分 MBC- Multiple Byte character 多字节字符集", "国际化测试方法 设计评审和代码审查 针对源语言的功能测试，如不同的区域设置、不同的时区显示 针对伪翻译（ pseudo-code pseudo-translation ）版本的测试；国际化测试点 双向识别功能 硬编码 语言切换方式 多字节和单字节文字的混合 输入法编辑器（ IME 大小写转换、换行 快捷组合键 纸张大小 电话号码 词序问题", "8.1.4 软件本地化基本步骤 配置管理体系 ，跟踪目标语言各个版本的源代码 创造和维护 术语表 源语言代码和资源文件分离 、或提取需要本地化的文本 把分离或提取的文本、图片等翻译成目标语言 把翻译好的文本、图片重新检入目标语言的源代码版本 如果需要，编译目标语言的源代码 测试翻译后的软件，调整 以适应翻译后的文本 测试本地化后的软件，确保格式和内容都正确", "本地化过程 核心功能测试 国际化测试 本地化测试 国际化 软件设计 全球化软件发布 翻译测试；8.1.5 软件本地化测试 功能性测试 ，所有基本功能、安装、升级等测试； 翻译测试 ，包括语言完整性、术语准确性等的检查； 可用性测试 ，包括用户界面、度量衡和时区等； 兼容性调试 ，包括硬件兼容性、版本兼容性等测试； 文化、宗教、喜好等适用性测试 手册验证 ，包括联机文件、在线帮助、 PDF 文件等测试", "软件本地化测试 I18n L10n 翻译的 测试 界面 测试 功能 测试 发布 测试 https://wiki.mozilla.org/Firefox:2.0_QA_Activities:L10n_Test_Plan http://l10n.openoffice.org/localization/L10n_testplan.html；I18N vs. L10N Category I18n functional testing Pseudo l10n testing L10n message testing L10n functional testing What to test Installation and uninstallation of l10n support in CLI/GUI/Silent modes, all functions especially input, output (fonts, display and printing) and internal conversion or processing of non ASCII characters in non English environment. Hardcoded messages button/menu/label width, garbage, white boxes, question marks, mismatched encodings or bad layouts in CLI/GUI installation, CLI commands, BUI, Error messages, OLH, etc. Correct and consistent translations of all of the messages. All of the Locale data, all of the input methods, the fonts, display, and printing in all applications, all of the converters, etc. Who write test cases I18n developers, base team or SQEs (Software Quality Engineers) I18n developers, base SQEs I18n developers, base SQEs L10n developers, l10n SQEs Who to do the testing I18n developers, base team or i18n SQAs (Software Quality Asurances I18n developers, base SQEs, l10n SQEs, l10n Ces , l10n tech leads, etc L10n SQAs 10n developers, l10n SQAs Where to test In one Asian multiple byte locale of each OS release on all platforms In one locale of one OS release On all platforms One language in one release on one platform all releases on all platforms When to test When the features are implemented or bugs are fixed, before l10n message engineering is started During development, while messages are being translated, before l10n testing is started After the message translations are integrated When the features are implemented or bugs are fixed How often to test Whenever there are new features or bug fixes Whenever there are message updates Rotate sub test groups among builds Whenever there are new features or bug fixes"]}, {"no": "8.2", "title": "翻译验证 翻译的内容 目标语言的文化心理 特殊符号", "paras": ["软件本地化与翻译 技术层面的更改 调整大小、调整默认设置、重新编译、创建新的图形、重新编排文档格式； 文化层面的更改 包装、图标、宣传、样品、政治敏感的术语，地方规章和宗教信仰；翻译问题 文字扩展；8.3 软件本地化测试技术 8.3.1 数据格式 8.3.2 页面显示和布局 8.3.3 配置和兼容性问题；最常见的问题 用户姓名 Shaomin Zhu Mr. Zhu"]}, {"no": "8.3.1", "title": "数据格式 日期格式 度量衡的单位 复数问题", "paras": ["区域与语言；本地化问题 数据格式；8.3.2 页面显示和布局 德语最长，汉语比较精炼 乱码 （双字节语言 GB/BIG5/JP/ … 字符索引、排序；不能完全显示；验证的细节 控件相互重叠或排列间隔不均衡。 文字遮挡图像、文字超过边界或者控件中字符没有完整显示等问题 文字方向的问题，如希伯莱文和阿拉伯文是从右到左显示 左右对齐问题，如阿拉伯文应右对齐。中英文之间有区别，中文段落开头需要空两个字的距离，而英文开头则不是。 连字符对多数拉丁语言有效，但对东方语言一般无效。 拉丁语言的大小写问题、多字节语言的显示乱码问题等等", "8.3.3 配置和兼容性问题 配置性包括键盘布局设计，它是语言依赖性最大的硬件、打印机配置等。 兼容性包括与硬件的兼容性、与上一版本的数据兼容及与其他本地化软件的兼容性等等 关注一些点，如 数据库问题、热键；配置和兼容性测试 本地化操作系统 Non-Unicode 数据路径 欧州系统本地化 OEM vs. Windows “ANSI” http://www.w3.org/International/articles/unicode-migration/ Migrating to Unicode"]}, {"no": "8.4", "title": "本地化功能测试", "paras": ["本地化功能测试的具体工作 本地化测试 In-country testing 本土测试 Translation verification testing (TVT) 翻译验证测试；L10N 功能测试 集成测试 索引和排序 联机文档的功能测试 不仅要查看用户界面，而且要对文件保存、打印等类似的功能进行测试，特别要注意语言环境特定的组件，比如时间、日期格式以及文字处理等相关方面的功能进行测试", "本章小结 软件国际化 是研发上多工程问题，在设计、编程上需要遵守 I18N 相应的规范和要求 国际化测试 需要验证双向识别功能、语言切换方式、多字节和单字节文字的混合、输入法编辑器、大小写转换、快捷组合键、词序问题、无硬编码 本地化测试 会涉及“数据格式、 显示和布局、配置和兼容性问题、翻译内容等；参考资源 http://www.w3.org/International/ https://confluence.sakaiproject.org/display/I18N/Home http://www.gala-global.org/ http://blogs.msdn.com/b/kierans http :// java.sun.com/developer/technicalArticles/Intl/IntlIntro"]}], "9": [{"no": "", "title": "Ch9 软件测试自动化及其框架", "paras": ["软件测试方法和技术 章 测试自动化及其框架；自动化测试的内涵与原理 数据驱动 关键字驱动脚本技术 xUnit 测试框架 API 自动化测试框架 Web/ 自动化测试框架；自动化测试越来越受重视 根据我们最近几年的调查，自动化测试是大家最为关注的，自动化测试高水平（达到 90% 以上）从之前的 提高到 ，大部分已实现自动化测试 50% 水平的 32% 提高到达到 43.8% (2021", "自动化测试越来越受重视 人才市场 自动化测试第一；自动化测试分层策略 单元测试更容易实现自动化测试， RoI 也更高（收益显著） API 自动化测试也基本能做到 100% 适当加强手工 E2E 测试（业务层） 概括起来：以底层测试、接口测试、功能逻辑测试等为主，尽量避免 缺陷更易定位 效率更高 反映真实需求 更加接近业务；现实是骨感的；自动化测试四象限 详细讨论见： 软件质量报道 公众号的文章", "自动化测试的内涵 通过平台、系统或工具自动地完成测试的某类工作都可以归为 测试自动化 自动化测试 更侧重的测试用例或测试数据生成、测试执行和测试结果呈现等自动化 自动化测试为评审提供辅助工具和代码静态分析 自动化测试可以覆盖系统的接口测试、 功能测试和专项测试；自动化测试的分类 代码静态分析 单元测试自动化 API （接口）自动化测试 Web 自动化测试 App 自动化测试 自动化测试集成框架", "代码静态分析 原理、框架与工具；代码评审辅助工具 https://docs.github.com/en/pull-requests/collaborating-with-pull-requests Collaborating with pull requests @GitHub；代码静态分析 词法分析 Lexer 、语法分析 parser 、控制流分析、数据流分析 等技术对程序代码进行扫描，验证代码是否满足规范性、质量要求等。 静态分析技术可以 采用模拟程序执行的技术 符号执行、抽象解释、值依赖分析 等，并采用 数学约束求解工具 进行路径约减或者可达性分析以减少误报、增加效率 抽象语法树 AST 中间表示 Token 语法分析 词法分析", "void CoverMe int [] a) if (a==null) return; if ( a.Length >0) if (a[0] == 1234567890 throw new Exception(\"bug\"); 示例：符号执行 被测代码 a==null a.Length>0 a[0]==123… 没有其它路径了。 取反后的条件 Godefroid Klarlund , Sen. DART: directed automated random testing. PLDI 2015 微软 Pex – White Box Test Generation for .NET 详见文章", "值依赖分析 数据流分析中的定值 使用连接的依赖关系，并通过值依赖图来表现 值依赖图 Value Dependence Graph VDG 是一种基于程序值依赖分析的、路径敏感的空指针解引用检测方法，通过结合数据流分析中的到达定值分析、区间分析及指向分析创建了值依赖分析图 Alan Christopher Lawrence ，Optimizing compilation with the value state dependence graph， 2007", "SAST 静态应用程序安全测试 通过调用语言的 编译器或解释器 把高级语言代码（如 JAVA C/C++ 源代码）转换成一种 中间代码 ，将其源代码之间的调用关系、执行环境、上下文等分析清楚。 语义分析 ：分析程序中不安全的函数、方法使用问题 数据流分析 ：跟踪、记录并分析程序中的数据传递过程所产生的安全问题 控制流分析 ：分析程序特定时间、状态下执行操作指令的安全问题 配置分析 ：分析项目配置文件中的敏感信息和配置缺失的安全问题 结构分析 ：分析程序上下文环境、结构中的安全问题 结合多种分析结果，匹配所有规则库中的漏洞特征以发现漏洞 形成包含漏洞信息的检测报告，包括漏洞的具体代码行数以及漏洞修复的建议 Static Application Security Testing", "SAST 工具分类 正则匹配：如 Cobra Raptor 基于语法树：如 P3C Fireline Java 语言可基于 class 文件：如 FindBugs 基于控制流、数据流、函数调用关系等：多数商业 SAST SMT 求解器也被集成到一些大型工具中 HOL/Isabelle ESC/Java2 ACL2 UCLID BLAST ureka,CUTE PEX", "DAST Static Application Security Testing；DAST SAST&IAST；原理、框架与工具；单元测试 如同代码实现，但有自己的结构 初始化环境 环境清理；xUnit；JUnit 4 工作原理；JUnit 5 JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage （复古） JUnit Platform： 基于JVM的执行测试的基础框架及其Test Engine API、控制台启动器（ CLI ）、支持 CI/CD 、基于JUnit 4的Runner JUnit Jupiter： 在JUnit 5中编写测试和扩展的新编程模型和扩展模型的组合，运行基于Jupiter的测试。 JUnit Vintage： 提供了TestEngine在平台上运行基于JUnit 3和JUnit 4的测试 https://junit.org/junit5/docs/current/user-guide/", "Mock round-trip test Round-trip test Public interface “front door” 直接输入 DOC Depend-on Component SUT System Under Test；最常用的单元测试工具 JUnit TestNG GoogleTest pytest unittest Coverage.py EvoSuite Diffblue Cover Java C++ Python 语言的单元测试中，受欢迎的测试工具包括单元测试框架、 两个智能化的单元测试用例自动生成工具、以及 Mock 工具、代码覆盖率工具 JMockit JaCoCo gcov lcov gcovr 详见公众号文章", "API 自动化 原理、框架与工具；API （复习） API 的来源 文档化工具 手工录入 程序扫描 HAR API RAML Swagger Markdown 场景设定 选择和组装 API 基于场景的测试用例 手工组装 HAR 批量生成 代码迁移 触发回归 结果展示 按需回归 定时回归 即时触发 事件触发 RAML RESTful API 描述性语言 HAR ：基于 JSON 、储存 HTTP 响应信息的文件格式", "API Mockbin ：可从 HAR 文件生成一个模拟桩 RAP ：淘宝开发的 API 管理工具 Swagger ：流行的 API 定义工具、规范 Easy Mock swagger 生成数据 Doclever ：编写 REST 接口文档，生成测试数据 Mocky ：无需登录，直接生成 response kristofa/mock-http-server wiremock SoapUI Rest-Assured SOAtest APIfortress 详见公众号文章", "Web 自动化 原理、框架与工具；Web 自动化测试 验证状态（比较）；Web；W3C DOM https://dom.spec.whatwg.org/ document.getElementById (id) document.getElementsByTagName (name) document.createElement (name) parentNode.appendChild (node) element.innerHTML element.style.left element.setAttribute element.getAttribute element.addEventListener window.content window.onload (en-US) window.dump window.scrollTo", "DOM API；定位元素 id 定位 ：driver.findElement(By.id(“id的值”))； name 定位：driver.findElement(By.name(“name的值”))； xpath 定位：driver.findElement(By.xpath(“xpath表达式”))； Class 定位：driver.findElement(By.className(“class属性”))； css 定位：driver.findElement(By.cssSelector(“css表达式”))； TagName 标签名称：driver.findElement(By.tagName(“标签名称”))； Jquery 表达式：Js.executeScript(“return jQuery.find(“jquery表达式”)”) 链接的全部文字 ：driver.findElement(By.linkText(“链接的全部文字”))； 链接的部分文字 ：driver.findElement(By.partialLinkText(“链接的部分文字”))；", "元素定位示例；Selenium + WebDriver；Java HTTP Client Selenium <dependency> < groupId > org.seleniumhq.selenium </ groupId > < artifactId >selenium-java</ artifactId > <version>4. .0</version> </dependency> <dependency> < groupId > org.seleniumhq.selenium </ groupId > < artifactId >selenium-http jdk client</ artifactId > <version>4. .0</version> </dependency> POM Selenium使用HTTP & WebSocket客户端： 向WebDriver发送命令 从Selenium客户端库向网格发送命令 根据网格模式，让各种网格组件相互通信 创建ChromeDevTools协议和BiDi协议会话 目前，Selenium使用AsyncHttpClient（建立在Netty之上的开源库，支持异步地执行HTTP请求和WebSocket支持）", "Selenium Grid；Cypress 自动化测试 https://www.cypress.io/；Cypress；基于图像识别的 自动化测试 https:// github.com RaiMan Implement the API completely as a REST-API backed by a server running on the target machine SikuliX1 SikuliNG", "App 自动化 Appium & Airtest；几款常见的测试工具比较；Appium；Appium https://appium.io/docs/en/writing-running-appium/running-tests/；Airtest Python 语言的测试脚本，其开源组件 Airtest 跨平台的基于图像识别的 自动化测试框架， 提供了一系列跨平台的 API 可供调用， 覆盖各种 常见的操作。 Poco 控件识别的自动化测试框架，支持 Android iOS app 和微信小程序 AirtestIDE 跨平台的 自动化测试编辑器，能够快速编写 Airtest Poco 代码，提供脚本录制、一键回放、报告查看等功能 http://airtest.netease.com", "示例：基于 Poco 开发自动化 测试脚本 http://airtest.netease.com/；OCR OCR 的实现一般分成两个步骤 文本检测 和 文本识别 文本检测 文本识别 文本检测：找到图片上文本的位置和区域（文本框） 文本识别：识别每个文本框中的文字；OCR 文本行 CNN 多层结果合并 NMS 相邻及重叠文本框合并 SER 文本区域特征提取 特征过滤 CNN 特征合并 EAST 文本区域特征图 后处理 框解析 NMS 常用字 DenseNet CTC 繁体字识别 DenseNet CTC 高精度 DenseNet BLSTM CTC CRNN 卷积循环神经网络； BLSTM Bidirectional Long Short-Term Memory Networks CTC Connectionist Temporal Classification MSER Maximally Stable Extremal Regions CTPN + DenseNet + CTC ： https://github.com/YCG09/chinese_ocr crnn_self_attetion ： https://github.com/koibiki/crnn_self_attetion CRNN_Attention_OCR ： https://github.com/wushilian/CRNN_Attention_OCR_Chinese https://github.com/xisnu/CNN-BLSTM-CTC https://github.com/senlinuc/caffe_ocr", "自动化 集成框架；Selenium 关键字驱动 关键字；RobotFramework 关键字驱动 表格方式 Setting Value Value Value Library OperatingSystem Test Case Action Argument Argument My Test [Documentation] Example test Log ${MESSAGE} My Keyword tmp Another Test Should Be Equal ${MESSAGE} Hello, world! Keyword Action Argument Argument My Keyword [Arguments] ${path} Directory Should Exist ${path}", "分离数据与脚本 使用表（ Table ）或数据文件作为测试输入和可验证的输出，以及测试环境设置和控制不采用“硬编码（ hard code ）”的过程；测试数据的管理 Excel CSV Property XML YAML Database JSon 处理业务实体／数据 容易描述特定的需求 读写操作容易（～测试框架） 容易修改／维护测试数据 如果需要，创建 DSL 来描述 不能局限于输入 容易实现比对（ Outputs", "框架的构成 Harness/IDE 脚本语言 (Script Language) Agents Tools 任务安排 Scheduler Report Harness/IDE SUT SUT: System under test；框架应提供的服务 测试件的存储与管理 测试脚本开发调试（ TIDE 测试机 资源的管理 任务安排 测试执行启动与调度 系统监控、 Log 测试结果分析 测试报告查询", "框架设计要点 控制中心 多层次结构 分布式架构 通讯问题 接口定义 对象库 关键字库 数据共享 集成环境 … …；框架支持测试设计；统一规划 不同的测试类型和对象 Driven Script-Execution Module Functional Libraries Composited Tested System Classified Test Data Test Report Generator Load Test Engine Composited Tested System Load Test Engine Based on Platform Type Mobile Engine Application Engine Web Engine Test Suite Batch Execution Depend on the script expression to call existed methods in libraries 驱动组件", "数据管理与对象识别组件 Classified Test Data Test Object identification Scripts and Methods need test data or test object or both；测试报告组件 Test Plan Test Script Execution Log Test Report Generator HTML Report Template", "实例：自动生成用户化的报告 传统的自动化测试报告 （如上图）可读性很差，不能直观的体现整个测试过程 用户化的测试报告 ，可以非常直观的充分还原整个测试过程。极大提升测试结果的分析效率，降低分析难度；Robot Framework 一个通用的、 ATDD 的自动化测试框架，易于使用表格来组织测试过程和测试数据 Tools Data；自带的标准库 http://robotframework.org/robotframework/#standard-libraries", "扩展库 Selenium AutoIT Appium Android Database Http Image Sikuli；Web Windows 一体化自动化测试框架；SpringBoot 的高效模板化自动化测试框架；RF+Selenium 完成某页面测试；SDLC 高度集成 跨平台 过程透明 可测试性保障 需求可执行 支持敏捷、 DevOps", "提问与思考 自动化测试中录制脚本轻松搞定，为何没有成为功能测试自动化脚本开发的主流？ 采用开源自动化测试框架还是自己开发自动化测试框架好呢？ 大家都重视自动化测试，但往往效果不够好，问题在哪里？", "部署自动化测试框架 下载安装 Robot framework Robot framework GUI 界面； 安装第三方库（ Robot framework 插件），如 SeleniumLibrary HTTP RequestsLibrary AppiumLibrary RESTinstance Robot framework ），使用 内建库，完成一些基本的操作的、 自身的关键字驱动脚本。 结合实验 ，实现 的集成，生成测试报告； 和第三方库完成接口测试的脚本等，生成测试报告。", "学习资源推荐 接口自动化测试项目实战 ，清华大学出版社， 2021.11 从零开始学 Selenium 自动化测试 ，机械工业出版社， 2020 前端自动化测试框架 Cypress 从入门到精通 ，电子工业出版社， 2020.4 《Robot Framework 自动化测试精解 ，人民邮电出版社， 2020.4"]}], "10": [{"no": "", "title": "本章导入", "paras": ["篇 软件测试项目实践 章 测试需求分析与测试计划 章 设计和维护测试用例 章 部署测试基础设施 章 测试执行 、缺陷 与跟踪 章 软件测试展望；软件测试工作和测试件；软件测试方法和技术 章 测试 需求分析与测试计划；10.1 测试目标和准则 10.2 测试需求分析 10.3 测试项目的估算与进度安排 10.4 测试风险和测试策略 10.5 测试计划的内容与编制", "软件测试计划的重点工作 明确测试目标 分析与确定测试范围 识别测试项及其优先级 识别测试风险，采取相应对策 测试工作量估算 测试资源、进度等安排 测试阶段出入准则 测试需求分析"]}, {"no": "10.1", "title": "测试的目标和准则", "paras": ["示例：哪个是测试目标？ 能作为测试的目标吗？有什么问题吗？", "设计和执行测试的原因或目的 向风险管理活动提供信息 提供软件系统质量有关信息 评估软件产品是否满足相关利益者的期望 评估缺陷修正（清除）而不带来负面效应 评估软件变更实施而不带来负面效应 评估软件是否完全符合合规性要求；项目的具体 哪些质量风险 新改动的 是否正确实现，对已有业务是否有负面影响 是否满足功能性要求和非功能性要求 在测试 覆盖率 、测试 上的具体要求", "如何确定 目标？ 哪些业务改动，会影响哪些已有业务？ 系统改动会影响哪些系统功能和非功能特性？ 测试覆盖率：新业务 功能？已有业务/功能呢 如何最大程度提高测试效率？ 产品质量要求、业务功能关系分析、测试范围分析、测试策略和方法选择；测试进入的准则 清楚了解项目的整体计划框架； 完成需求规格说明书评审； 技术知识或业务知识的储备； 标准环境 技术设计文档； 足够的资源； 人员组织结构及其责任已确定。", "10.2 测试需求分析 10.2.1 测试需求分析方法 10.2.2 测试需求分析技术 10.2.3 功能测试范围分析 10.2.4 非功能性的系统测试需求；测试分析是基础 测试分析 测试设计；测试分析的输入与输出；软件测试分析的输出 测试目标 测试范围 测试项和测试子项 测试风险 测试优先级 测试策略；需求分析的过程 了解项目 的背景、 产品价值、 待解决的 业务问题 用户是谁， 用户所关心 的需求 系统的特点 质量属性 非功能特性 待测非 功能项 从整体到局部 从上到下 逐层分解 功能特性 功能项 价值分析 风险分析 测试项 优先级", "测试目标 满足业务需求， 包括新改动的业务、已有业务 满足质量要求， 包括使用质量、功能性要求和非功能性要求 测试覆盖率要求 测试效率、周期、成本等目标；测试范围分析 界定影响范围的边界；哪些要测试、哪些不需要测试 …... 项目目标和范围文档 （计划） 功能特性列表 业务流程、规则 、业务数据 Spec 测试项列表 （按优先级） 测试数据 测试边界界定 测试项与需求 映射矩阵", "干系人 约束条件 分析的内容：领域、元素 正确性 完备性 适应性 目标场景决策卡 愿景、目标商业价值；启发式测试策略 Heuristic Test Strategy Model HTSM 项目环境 产品元素 质量标准 可接受的质量 测试技术；测试分析的全局观 业务、用户、产品、系统等 用例驱动、数据驱动、结构化方法、 方法等 用例图、数据流程图、活动图等 头脑风暴、帕累托图、鱼骨图、亲和图、直方图等 接口、功能、数据、质量、约束等", "分析思路：整体 vs. 业务流程、事件流、数据流 状态、状态转换 事件触发、条件约束 环境、场景 质量特性的分解 模块／组件 …...；简单化、抽象化 结构化、层次化 可视化、可观察 类比、隐喻 收集足够的信息或数据 测试需求分析途径；常见分析模型比较 商业建模标准 复用性强 用户最容易接受 并行、异步支持差 跨职能流程图 活动图 时序图 IDEF 建模标准 强调数据流 未表示出谁执行 计费类系统最适用 UML 建模标准 语义最丰富 强调行为流 强调活动内容 UML 建模标准 强调行为流 强调协作 技术类系统更常用", "分析工具 业务流程图 UML 图（用例图、活动图等） 建模工具 思维导图 Excel …...；明确测试项的优先级 产品质量风险的识别 功能重要性排序 风险分析 风险矩阵 经验与历史数据 80/20；示例：测试需求分析结果；分析不准确的风险 项目范围不清楚、项目之间耦合性强 产品业务不够清晰或没说明清楚 具体需求不明确、需求变更频繁 系统复杂性，分解比较困难 系统特性的不可测试性 业务数据种类多、处理环节多 代码质量差、代码结构不好 环境配置复杂、用户配置项很多 平台／维护特性 继承特性 新开发 问题高发区 问题高发区 问题高发区 测试重点", "小结：从基本问题出发完成测试分析 分解了 产品质量目标 基于风险对特性进行了 确定了 测试深度和广度 和测试优先级。 确定了测试的 总体框架 ，知道了 如何安排各种测试活动 预估了测试结果 （缺陷趋势） 产品测试的 六大问题 测试的 对象和范围 是什么？ 是什么？ 测试的 重点和难点 是什么？ 测试的 深度和广度 测试什么， 测试什么 测试的效果", "10.3 测试估算与进度安排 10.3.1 测试工作量估算 10.3.2 工作分解结构表方法 10.3.3 资源的安排 10.3.4 测试里程碑和进度表；这是干什么的？", "测试工作量估算方法 功能点方法 工作分解结构表（ WBS ）方法 历史数据推算（相似规模、同类型） 经验法 （团队或专家小组） 综合方法 工作分解结构 (WBS, Work Breakdown Structure)；AFP( 调整后功能点 )= UFP ( 未调整功能点数目 )* AF ( 影响因子 外部输入数 (EI external input) 外部输出数 (EO external output) 外部查询数 (EQ external query) 内部逻辑文件 (ILF internal logical file) 外部接口文件 EIF external interface file) 软件规模估算：功能点方法", "工作量估算 测试任务由质量需求、测试目标决定 测试范围由产品（新）功能特性或测试任务决定 代码质量越低，测试工作量越大， 如回归测试次数与频率加大 处在不同的开发阶段测试工作量不同 自动化程度高，测试工作量就越低 针对不同的应用领域、技术、编程语言，其估算方法不同 测试工作量是根据测试范围、策划任务和开发阶段来确定的，测试范围和测试任务是测试工作量估算的主要依据。", "工作分解结构表方法 WBS 列出本项目需要完成的各项任务 对每个任务进一步细分，可进行多层次的细分，直到不能细分为止 根据任务的层次给进行编号，就形成了完整的工作分解结构表 测试工作量的估算依赖于测试任务的细化，对每项测试任务进行分解，然后根据分解的子任务进行估算。通常分解粒度越小，估算精度越高。", "示例： WBS；10.4 测试风险与测试策略 10.4.1 测试风险管理计划 10.4.2 基于风险的测试 10.4.3 测试策略的确定；测试风险 测试风险管理 软件测试总是存在较高的风险，风险主要来自软件系统的复杂性、需求频繁变更、测试范围的分析不到位（存在未知区域）、测试的充分性（覆盖率）不足和某些不确定性等 测试风险管理就是设法降低或缓解测试过程中的风险 风险识别 风险分析 风险防范", "风险识别 风险识别的有效方法就是建立风险项目检查表 历史资料、 Brainstorming 等帮助建立项目检查表 风险识别并确定其程度，给出预防或处理措施 风险项目检查表；风险分析常用的模板 风险项 可能性 严重性 预防措施 风险严重性 可能性 * 影响 风险危害 可能性 后果严重程度 发生的可能性 影响程度；示例：测试风险 还有什么高风险的项？", "风险常用控制方法 做好风险管理计划，制定有效的风险应急处置方案 计划时，对于估算资源、时间、预算留有余地 采取措施避免可以避免的风险 高风险转移为低风险 设法降低不可避免的风险所带来的损失；为什么要制定测试策略？ Strategy ：the art of devising or employing plans or stratagems toward a goal adaptation that serves an important function in achieving the goals", "测试策略及其内容 针对风险（工作量、时间等压力）采取对策，如标准 、测试任务的优先级等 更好地执行测试用例以及后续的回归测试 选定使用测试技术和工具 考虑影响资源分配的特殊情况 在受到条件限制、不利因素的影响，为了实现测试项目的目标而不得不采取的对策，针对不同测试阶段或不同的测试对象，其测试的范围、方法、类型等进行必要的调整。 取舍 trade-offs 有得有失"]}, {"no": "50", "title": "% 时间，如何测试？", "paras": ["示例：测试策略 之前的回归测试策略，还记得吗？ Pairwise/ 正交试验法隐含了什么策略？ 还有什么常用的测试策略？ 如交叉测试策略 测试策略 测试执行的两段论；两段论 里程碑 集成测试 新功能验证 自动化每日验证（ SVT/BVT 非功能性的系统测试 功能验证测试 剩余缺陷验证 确认测试 回归测试 探索式测试 针对有风险区 域的功能测试 发现缺陷，强调效率 验证功能，降低风险", "测试策略影响因素 测试方式 动态，探索式方式） 测试方法 （黑盒 白盒） 测试层次 （单元、集成、系统） （责任、能力、独立性） 测试用例选择 （如用例是否有优先级） （设置是否简单、自动部署） （能不能用测试工具、使用简单与否） 质量标准 （采用国内标准或美国 DO-178C；10.5 测试计划的 内容与编制 10.5.1 测试计划的内容 10.5.2 测试项目的计划过程 10.5.3 制定有效的测试计划", "测试计划内容 软件测试计划是指导测试过程的纲领性文件，描述测试目标和测试范围、测试项及其优先级、测试方法、测试风险与策略、资源、任务安排和进度等 测试计划标识符（文档编号） 项目总体情况简介 测试项（ test item ，含需要测试的功能） 方法、策略 测试项通过 失败的标准 测试中断和恢复的规定 测试完成需提交的材料 测试任务、进度表 测试环境要求 测试人员职责、安排 培训需求 人员安排与 潜在的问题和风险 详细见 软件测试方法和技术（第", "退出标准 进入准则 对软件测试切入点的确立 ，即满足什么条件，才启动测试 退出标准： 某个阶段结束 里程碑达到 事先定义的要求 软件测试 每个阶段 需要控制进入 退出标准 以保障测试的质量；示例：系统测试结束标准 对于非严格系统可以采用“基于测试用例”的准则： 功能性测试用例通过率达到 100% 非功能性测试用例通过率达到 95% 对于严格系统，如补充“基于缺陷密度”等准则： 连续几个小时或几天“测试发现的缺陷密度”低于某阈值 代码的缺陷密度要高于某阈值（如上一个版本的平均值）", "软件测试计划更是一个过程 计划不 是一个过程 Planning；本章小结 从产品需求到测试 ，逐层分析：业务、功能、用例、场景 清楚测试上下文（目标、条件、环境等） 测试覆盖率是起点也是终点 风险识别、分析与防范 有效制定 测试计划 也不可忽视；：制定测试计划 小组讨论，分析 SUT ，重新明确测试目标， 非功能性要求； 分析哪些要测试、哪些可以不错，即确定测试的范围； 测试范围进行分解，列出测试项（包括功能测试项和专项测试项）。 WBS 或敏捷中扑克牌估算法等来估算每一个测试项的工作量，并进行汇总。 针对这些测试内容，识别出其中的测试风险，并分析和列出主要的测试风险。 一起讨论，看看能否针对这些测试风险，找到相应的测试对策（策略）。 10.5.1 所需的主要内容，将前面的内容汇总起来，形成一个简要的测试计划。"]}], "11": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 设计和维护测试用例；本章要解决的问题 为什么我们要使用测试用例 测试用例有哪些基本元素组成 测试用例编写和设计时需要遵循哪些基本的原则 测试用例结构和设计过程 跟踪和维护测试用例 注：测试用例设计的具体方法，在第 章已做介绍"]}, {"no": "11.1", "title": "测试用例构成及其设计", "paras": ["如何描述 行为？", "4.1 传统的软件测试过程 11.1.1 测试用例的重要性 11.1.2 测试用例设计书写标准 11.1.3 测试用例设计考虑因素 11.1.4 测试用例设计的基本原则；什么是测试用例 测试用例 进行测试执行的 测试内容的一系列情景和每个情景中必须依靠输入和输出，而对软件的正确性进行判断的测试文档，称为测试用例 测试用例就是将软件测试的行为活动转化为规范化的文档", "11.1.1 测试用例的重要性 如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。 软件测试是有组织性、步骤性和计划性的 ，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例 测试用例是测试工作的指导 ，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障", "测试用例的作用 有效性 可复用性 易组织性 客观性 可评估性和可管理性 知识传递 重要参考依据， 提高测试质量"]}, {"no": "11.1.2", "title": "测试用例设计书写标准 目的？ 输入数据？ 操作步骤？ 期望结果？ 还有呢？", "paras": ["测试用例最基本的内容 前置条件 测试数据 测试环境 操作步骤 期望结果 详细见 软件测试方法和技术（第；测试用例的元素；良好测试用例的特征 可以最大程度地找出软件隐藏的缺陷 可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定 待查的输出结果或文件必须尽量简单明了 不包含重复的测试用例 测试用例内容清晰、格式一致、分类组织", "11.1.3 测试用例设计考虑因素 具有代表性、典型性 寻求系统设计、功能设计的弱点 测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入 需要分析怎样使得这样的错误或者异常能够发生 考虑用户实际的诸多使用场景；测试用例其它重要属性 测试目的、测试类型 优先级 高、中、低等 层次（父、子、孙、 估计用时；示例一；示例二；11.1.4 测试用例设计的基本原则 避免含糊的测试用例 Pass/Failed is clear, 操作环境，操作步骤 将具有相类似功能的测试用例抽象并归类 数据驱动的测试用例 避免冗长和复杂的测试用例 例如：操作步骤 <=7, 一个测试用例一个验证点", "单个测试用例的质量要求 具有可操作性 具备所需的各项信息 各项信息描述准确、清楚 测试目标针对性强 验证点完备，而且没有太多的验证点 没有太多的操作步骤 符合正常业务惯例。", "测试用例的颗粒度 输入不同的用户名和口令，其结果要满足设定的要求 如用户名、口令判断正确与否等 粗颗粒度 细颗粒度 Vs.；整体测试用例的质量要求 覆盖率 ：依据特定的测试目标，尽可能覆盖所有的测试范围、功能特性和代码 易用性 ：设计思路清晰、组织结构层次合理，测试用例操作的连贯性好、执行顺畅 易维护性 ：以较少的时间来完成测试用例的维护工作，包括易读性、一致性等 粒度适中 ：既能覆盖各个特定的场景，保证测试覆盖率；又能处理好不同的测试数据、测试条件（数据驱动），提高测试用例的可维护性", "4.2 测试用例组织和维护 11.2.1 测试用例的属性 11.2.2 测试套件及其构成方法 11.2.3 跟踪测试用例 11.2.4 维护测试用例 11.2.5 测试用例的覆盖率"]}, {"no": "11.2.1", "title": "测试用例的属性", "paras": ["一些属性说明 目标性 ，包括功能性、性能、容错性、数据迁移等各方面的测试用例； 所属的范围 ，属于哪一个组件或模块 关联性， 和软件产品特性相联系 阶段性， 属于单元测试、集成测试、系统测试、验收测试中的某一个阶段 时效性 ，不同的版本所适用的测试用例可能不相同；11.2.2 测试套件及其构成方法 建立合适的、可扩展的测试用例框架，有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等 Test Case Test Suite Test Suite ：测试套件、测试集", "测试集 测试套件 测试套件 (Test Suite) 是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将 服务于同一个测试目标 特定的测试任务 或某一运行环境下的一系列测试用例有机地组合起来 按程序功能模块组织 按测试用例的类型组织 按测试用例的优先级组织；测试套件（ Test suite 测试计划 集成测试 新功能测试 系统性能 测试目标 功能回归测试目标 测试套件 测试套件 测试套件 测试套件", "测试类型与测试用例设计 根据测试类型设计 根据程序功能模块设计 功能测试 易用性测试 配置测试 压力测试 回归测试 界面测试 文档测试 国际化测试 测试用例 测试用例 测试用例 测试用例 测试用例 测试用例 卸载测试 联机帮助测试 软件更新测试 联机注册测试 文件操作测试 测试用例 测试用例 测试用例 测试用例 测试用例 测试用例 数据备份测试", "测试用例的组织和测试过程的关系；测试套件应用场合 只是部分功能模块发生了变化，就可创建由这些改动模块的测试用例构成的测试套件 在修改的模块中，也不需要选择所有的测试用例，针对不同的优先级创建不同的测试套件 测试执行的 第一阶段 可以创建一个特定平台上的测试套件 有必要为 自动化测试 、手工测试分别建立测试套件。 可建立和 测试人员 相对应的、不同平台或模块的测试套件 回归测试 中，可以先运行曾经发现缺陷的测试用例，然后再运行从来没有发现的缺陷的测试用例", "11.2.3 跟踪测试用例 用例执行的跟踪 跟上进度？测试人员每天能执行多少个测试用例？“通过、未通过以及未测试的”各占多少？不能被执行的原因是什么？ 100% 工作量（需执行的测试用例数）"]}, {"no": "11.2.4", "title": "维护测试用例 测试用例的维护是持续改进的过程", "paras": ["测试用例维护流程示例；11.2.5 测试用例的覆盖率 测试用例本身 发现缺陷后补充的测试用例数 总的测试用例数 需求、功能点覆盖率 每个功能点都要有测试用例，平均 >4 /FP 代码覆盖率 借助工具跟踪执行过程，了解代码行、类、方法等覆盖率情况；测试用例框架的构成 更有效、有序地组织测试；本章小结 软件测试用例的基本属性、扩展属性 为了测试字目标，构建 Test suite 测试用例框架、结构：层次关系、依赖关系等 测试用例评审、维护和持续改进", "思考题 在构造测试套件中，哪种方法是最常用的？ 如何有效地维护测试用例？ 有什么工具可以来度量测试用例的覆盖率？"]}], "12": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 部署测试基础设施；12.1 测试基础设施的重要性 12.2 测试基础设施的要素 12.3 虚拟机技术的应用 12.4 测试基础设施的自动部署；12.1 测试基础设施的重要性 12.1.1 测试基础设施的定义 12.1.2 测试基础设施是测试的基础 12.1.3 测试基础设施影响研发效能 12.1.4 测试基础设施保障运维", "12.1.1 测试基础设施的定义 软件测试基础设施 是指支持测试运行、测试开发、测试管理，以及与研发环境、运维环境集成的综合性平台。 测试基础设施是测试执行的基础；12.1.2 测试基础设施是测试的基础 测试基础设施贯穿了软件开发的各个阶段，每个阶段中测试基础设施对测试的影响是不一样的 在系统测试和验收测试活动中，测试环境必须最大限度的接近实际环境，因此被称为准生产环境或者类生产环境 在软件测试中使用错误的测试环境， 引起一系列问题", "12.1.3 测试基础设施影响研发效能 提供测试工具和环境支持 测试活动，让软件测试能够尽早开始。 提供稳定、可靠的测试环境。 利用虚拟化技术和云平台提高各种软、硬件资源的利用率。 Mock 工具等服务虚拟化技术模拟外部依赖对象和系统，提供完整、可靠的自动化测试环境。 提供并行测试能力，缩短测试执行需要的时间；12.1.4 测试基础设施保障运维 不仅用来支撑研发环境，而且延伸到生产环境，成为支撑产品运维的重要组成部分，从而构成一个贯穿研发和运维的完整的 DevOps 测试基础设施", "12.2 测试基础设施的要素 12.2.1 硬件资源 12.2.2 网络资源 12.2.3 软件资源 12.2.4 数据资源"]}, {"no": "12.2.1", "title": "硬件资源 机架式服务器 刀片式服务器 传统式服务器 云真机", "paras": ["12.2.2 网络资源 100M 10G 局域网、广域网、无线网 网络协议 防火墙、代理服务器或网关"]}, {"no": "12.2.3", "title": "软件资源 操作系统 数据库 Web 服务器 测试工具 应用软件 被测试系统", "paras": ["持续集成工具集"]}, {"no": "12.2.4", "title": "数据资源 原有数据 正确数据和错误数据 真实的客户数据 大量的数据", "paras": ["流量回放技术；12.3 虚拟化技术的应用 12.3.1 虚拟机技术 12.3.2 QEMU-KVM 虚拟机解决方案 12.3.3 容器技术与 Docker 12.3.4 集群管理与 Kubernetes 12.3.5 服务虚拟化及其工具"]}, {"no": "12.3.1", "title": "虚拟机技术 两种类型的虚拟机 构建虚拟的测试农场", "paras": ["为什么使用虚拟机？ 充分利用硬件资源 ％的服务器利用率只有 借助虚拟机技术 提高到 节约能源和空间 。例如如果内存加大到 16G 或更高，一台机器可以虚拟 台服务器 提升运作效率 ，几分钟就可装载所需的系统镜像文件 有利于环境的建立和维护 ，容易实现添加、移动、变更和重置服务器的操作；虚拟机工作原理；虚拟机工作原理；常见的虚拟机软件 KVM Kernel-based Virtual Machine Linux 开源软件 QEMU VMware Workstation Fusion 完全免费和开源 Oracle VM VirtualBox Parallels macOS 微软公司的 Hyper-V Manager SW-soft 公司的 Virtuozzo 开源软件 Xen Linux 开源软件 Colinux windows", "12.3.2 QEMU-KVM 虚拟机解决方案 QEMU通过动态二进制转换几乎可以模拟任何IO设备，再将Guest OS的指令转译给宿主机硬件执行。 KVM是Linux内核提供的虚拟化架构，可将内核直接充当Hypervisor来使用。 但KVM的kvm.ko本身只提供了CPU和内存的虚拟化，缺少IO设备的虚拟化。所以KVM必须结合QEMU才能构成一个完整的虚拟化技术", "12.3.3 容器技术与 Docker 容器和虚拟机类似，都可以看作是虚拟实体，满足隔离性和可管理性。但是，容器的核心技术是 Cgroups namespace 命名空间），通过 namespace 实现资源隔离，通过 Cgroups 实现资源控制。", "Docker 构建容器 可以参考： https://docs.docker.com/ https://cloud.tencent.com/developer/article/1435910；容器的优点 镜像体积小，没有内核，属于轻量级应用 创建和启动更快，启动一个虚拟机需要几分钟时间， Docker 容器的创建和启动只需要几秒钟 更高的资源利用率，层次更高，降低额外资源开销，资源控制粒度更小，部署密度更大，占用磁盘空间更小", "12.3.4 集群管理与 Kubernetes Kubernetes 是目前最具影响力的容器集群管理工具之一，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性；集群管理与 Kubernetes 详细内容，请参考： https://kubernetes.io/docs/concepts/", "集群管理与 Kubernetes 详见： https://kubernetes.io/docs/concepts/ Pods Pods Pods Pod 中的最小调度单元，一个 Pod 个容器；基础设施架构 ACM (AWS Certification Manager) ALB (Application Load Balancer) CloudFront CloudWatch EC2 (Elastic Computing Cloud) ECR (Elastic Container Registry) ECS (Elastic Container Service) IAM (Identity & Access Management) RDS (Relational Database Service) Route53 S3 (Simple Storage Service) SNS (Simple Notification Service) SQS (Simple Queue Service) VPC (Virtual Private Cloud 使用的 AWS", "12.3.5 服务虚拟化及其工具 当前比较流行的服务虚拟化工具包括开源的WireMock、Hoverfly等，以及Parasoft Virtualize、Tricentis Tosca等商业软件；开源服务虚拟化工具 Hoverfly 可以在 环境中替代缓慢和不稳定的外部服务或第三方服务； 可以模拟网络延迟，随机故障或速率限制以测试边缘情况； 可以导入 导出、共享和编辑模拟数据； 提供方便易用的命令行界面 hoverctl 提供多种运行模式，可以对 HTTP 响应进行记录、回放、修改或合成。", "12.4 测试基础设施的自动部署 12.4.1 基础设施即代码 12.4.2 基础架构的自动部署 12.4.3 应用程序容器化及集群部署 12.4.4 应用程序的自动配置 12.4.5 CI/CD 流水线；12.4.1 基础设施即代码 Infrastructure as Code，IaC 基础设施即代码 是指通过机器可定义文件管理和配置计算机数据中心的过程。将基础设施以配置文件的方式纳入版本管理，实现更灵活和更快捷的操作", "IaC 类工具特征 版本控制 ：这显然是将基础结构、配置、容器和管道持久化作为代码最重要的部分，该工具的配置文件应具有可读性和版本控制性的语法，所以不能采用大型虚拟机镜像那样的二进制文件 模块化 最好的代码是可复用的，所以支持“模块化”的工具也要具备复用性，且能实现模块的参数化 可实例化或可部署 该工具必须能够将代码（它可以是管道、配置的实例、容器或对云基础架构的更改）输入并部署到环境中，这样的工具必须是纯脚本的，而且是全自动的，不需要手工操作或配置", "IaC 四类工具 基础架构即代码 工具，适用于基础架构的自动部署，如 Terraform CloudFormation 容器即代码 工具，用于应用程序容器化，只有 Docker Kubernetes 配置即代码 工具，用于应用程序的配置管理，有 Chef Puppet Ansible SaltStack 管道即代码 工具，用于持续集成和持续交付环境的自动化部署，如 Jenkins 2.0 Drone.io ConcourseCI", "12.4.2 基础架构的自动部署 Terraform 为例， Terraform 具有完成完整的云基础架构创建的能力，并通过 DSL 以编程方式将各个组件链接在一起，并能将云基础设施的有用部分定义为带有参数化输入的模块，而且可以与其他模块集成，具有良好的复用性。 Terraform 包括两个主要模块： 管理模块，定义 VPC virtual private cloud ）、子网、 NAT network address translation ）网关、路由、安 全组和 PuppetMaster 服务器模块，在其子网中定义多个消息代理和多个自定义服务器的层，并将它们动态链接到公共 ELB （负载均衡）。 最基本的计算资源、存储资源和网络资源，包括网络和服务器的定义、配置和管理。", "TestInfra Testinfra 是一个功能强大的库，可用于编写测试以验证基础设施的状态， 可以使用 Molecule Ansible 角色过程中添加测试关键组件，也可以和虚拟机管理工具 Vagrant Jenkins 等集成起来，轻松完成 DevOps 模式下的全自动化流水线式的验证；TestInfra 支持脚本参数化、与 框架集成", "测试基础设施工具清单 基础架构类，如 CloudFormation OpenStack 容器类工具，如 Docker Rocket ElasticBox 资源编排管理工具，如 Kubernetes K8S Apache Mesos Swarm 微服务平台，如 OpenShift Cloud Foundry Mesosphere 日志管理，如 Elastic Stack ElasticSearch Logstash Kibana Beats Logentries Splunk 系统监控、警告 & 分析，如 Prometheus Icinga Nagios Core Zabbix Cacti Zookeeper 性能监控，如 AppDynamics Datadog DynaTrace New Relic CollectD StatsD 知识管理和沟通协作类工具，如 MediaWiki Confluence Zoom", "12.4.3 应用程序容器化及集群部署 目前测试环境中所需要的各种测试工具及其依赖作为 Docker 容器来安装启动已经越来越普遍。例如，搭建一个 Selenium 的测试环境，不再需要下载 Selenium Server 以及支持特定浏览器的 Web Driver Selenium 官方提供了相应的 Docker 镜像，我们只需要在安装好 Docker 之后执行 docker 命令拉取 Selenium 镜像，然后创建并启动 Selenium 容器即可。", "常用的 docker 从镜像仓库中拉取镜像： docker pull [OPTIONS] NAME[:TAG|@DIGEST] 查看本地已有的镜像： docker images 创建并运行容器： docker run [OPTIONS] IMAGE [COMMAND] [ARG...] Dockerfile 制作镜像： docker build [OPTIONS] PATH | URL | 将本地镜像提交到镜像仓库： docker push [OPTIONS] NAME[:TAG] 创建并启动 docker 容器： docker run [OPTIONS] IMAGE [COMMAND] [ARG...] 获取容器的列表： docker [OPTIONS] 启动一个容器： docker start CONTAINER 停止一个容器： docker stop CONTAINER … …", "Kubernetes 集群环境中部署；12.4.4 应用程序的自动配置 Ansible 是一个基于 Python 开发的自动化运维的开源工具，提供远程系统安装、启动 停止、配置管理等服务，并且可以对服务器集群进行批量系统配置、批量部署和批量运行命令；12.4.5 CI/CD 流水线 为了能实现快速交付、持续交付，需要一系列自动化技术的支持和融合，包括持续构建、持续集成、持续测试、持续部署、持续运维。之所以称之为流水线，就是像工厂里面生产产品的流水线一样，把软件应用的整个生命周期里的各项任务以高度自动化的形式快速、有序的执行 Jenkins 2.0 是最常用的 CI/CD 流水线中的调度管理工具", "Jenkins+Docker 实现持续集成 具体搭建，见教材 P341-350；本章小结 测试基础设施很重要，介绍了测试基础设施的各项要素，包括 基础架构、软件资源和数据资源。 提供了测试基础设施搭建的方法和技术，包括虚拟机技术、容器技术以及服务虚拟化技术 基础设施即代码（ IaaC ，有利于实现基础架构的自动部署，有四类工具 （基础架构即代码、配置即代码、容器即代码、管道即代码） 详细讲解了如何搭建了一个持续交付流水线。", "Jenkins+Docker实现Java应用的持续构建 Jenkins Pipeline Docker 搭建一个 Java 应用的 Jenkins 流水线，完成一个 Java 应用从编译、静态代码分析、单元测试、打包的过程。"]}], "13": [{"no": "", "title": "本章导入", "paras": ["软件测试方法和技术 章 测试执行、缺陷报告与跟踪；章回顾 测试基础设施的重要性 测试基础设施的要素 虚拟机、容器及其集群管理 测试基础设施的自动部署；13.1 软件测试执行与跟踪 13.2 软件缺陷的描述 13.3 软件缺陷跟踪和分析 13.4 产品质量评估与度量 13.5 测试的评估与报告；13.1 软件测试执行与跟踪 13.1.1 测试执行过程的要点 13.1.2 测试项目进度的管理方法 13.1.3 测试过程管理工具", "13.1.1 软件测试 过程的要点 不同测试阶段的执行要点 测试用例执行 团队建设与沟通 测试执行结束；测试执行实践 执行前开一个动员会，严格审查测试环境 抽查性质的探索式测试，验证高风险区域的测试质量 交叉互换测试人员所测试的模块，可以发挥互补作用 良好的沟通，如每周例会，以及和开发人员的及时沟通 测试时间被压缩 测试策略的优化、计划调整 测试需求的优先级、调整测试范围 常规的缺陷审查，及时发现问题、纠正问题，使整个测试进程在控制轨道上发展 阶段性结果分析，保证阶段性测试任务得到完整的执行并达到预定的目标"]}, {"no": "13.1.2", "title": "测试项目进度的管理方法 进度与质量关系 进度与成本的关系", "paras": ["测试进度的 曲线法 曲线法通过对计划中、尝试的与实际的进度三者对比来实现的，其采用的基本数据主要是测试用例或测试点的数量；测试进度的 NOB 曲线法 NOB Number of Open Bug；13.1.3 的工具 AgileTC 是滴滴开源的一套敏捷的测试用例管理平台 Jira Atlassian 公司开发的项目管理工具，常常用于缺陷管理 MeterSphere 是一站式开源持续测试平台，涵盖测试管理、接口测试、性能测试、团队协作等功能 PractiTest 是一个端到端的测试管理系统，提供了测试用例管理，缺陷状态管理，具有可定制的仪表板，并附有详细报告。 TestLink 是一个开源的用于项目管理、缺陷跟踪和测试用例管理的测试过程管理工具 更多工具详见 此公众号文章", "13.2 软件缺陷的描述 13.2.1 软件缺陷的生命周期 13.2.2 严重性和优先级 13.2.3 缺陷的其它属性 13.2.4 完整的缺陷信息 13.2.5 缺陷描述的基本要求 13.2.6 缺陷报告的示例；对缺陷会关心哪些问题？ 描述？ 是否严重？ 是否需要修正？ 当前状态？", "13.2.1 缺陷生命周期 发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。 打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。 修复-关闭：测试人员验证修复过的软件，关闭已不存在的缺陷。", "完整的缺陷生命周期 激活状态 Send email to DEV 是否清楚、 可再现？ 已处理状态 已修正状态 Send email to QA 不能再现 缺少信息 缺陷评审 关闭状态 增强设计 无法解决 需要处理 验证是否通过 Unit test, code review Check in CVS 下一个版本 Yes Yes Bug；Open a bug Dev checks mail & Review bug Duplicate the bug Debug Check out code Fix bug Code Review Unit test Check in code Build a package Upload package Installation/configuration Verify fixed bugs Change bug status to close 14 Steps start end", "13.2.2 严重性和优先级 严重性 severity ）衡量缺陷对客户满意度的影响程度 致命的（ fatal ）、严重的（ critical ）、一般的（ major ）、微小的（ minor 优先级 (Priority) ：指缺陷被修复的紧急程度。 缺陷优先级 立即解决( 缺陷导致系统几乎不能使用或测试不能继续，需立即修复 高优先级( 缺陷严重，影响测试，需要优先考虑 正常排队( 缺陷需要正常排队等待修复 低优先级( 缺陷可以在开发人员有时间的时候被纠正。", "优先级的计算 可重复性 (Repeatability) 可发生性 (Visibility) 严重性 (Severity) 优先级 （可重复性 可发生性） 严重性；13.2.3 缺陷的其它属性 type ），如功能、 、性能、文档 缺陷产生 可能性 frequency 可再现的概率 source ）：需求、设计、编码 cause ）：数据格式、计算错误、接口参数、变量定义与引用等 P.361 362", "13.2.4 完整的缺陷信息 ：提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。这些信息对开发人员是关键的，视为修复缺陷的向导 期望结果 ：与测试用例标准或设计规格说明书或用户需求等一致，达到软件预期的功能。是验证缺陷的依据。 实际结果 ：实际执行测试的结果，不同于期望结果，从而确认缺陷的存在；还需要什么重要的信息？ 版本信息 Trace Log 录制这个操作过程", "缺陷完整的信息 操作步骤 期望结果 实际结果 严重程度 优先级 缺陷提交人 缺陷指定解决人 产生原因 构建包跟踪 版本跟踪 提交时间 修正时间 验证时间 所属项目 产品信息 P363 13-7；13.2.5 缺陷描述的基本要求 单一准确，每个报告只针对一个软件缺陷 可以再现。提供缺陷的精确操作步骤 完整统一。提供完整、前后统一的软件缺陷的步骤和信息 短小简练，包括使用关键词 特定条件一定要注明 不做评价 哪点比较关键？", "13.2.6 缺陷报告示例 优秀的缺陷报告 重现步骤 : 打开一个编辑文字的软件并且创建一个新的文档（这个文件可以录入文字） 在这个文件里随意录入一两行文字 选中一两行文字，通过选择 Font 菜单然后选择 Arial 字体格式 一两行文字变成了无意义的乱字符 期望结果：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。 实际结果:它是字体格式的问题，如果改变文字格式成 Arial 之前，你保存文件，缺陷不会出现。缺陷仅仅发生在 Windows98 并且改变文字格式成其它的字体格式，文字是显示正常的 见所附的图片<有一个链接，点击即可看到>", "散漫的缺陷报告的示例 重现步骤 Windows 上打开一个编辑文字的软件并且编辑存在文件 文件字体显示正常 我添加了图片，这些图片显示正常 在此之后，我创建了一个新的文档 在这个文档中我随意录入了大量的文字 在我录入这些文字之后，选择几行文字.并且通过选择 Font 菜单然后选择 Arial 字体格式改变文字的字体。 有三次我重现了这个缺陷 Solaris 操作系统运行这些步骤，没有任何问题。 Mac 操作系统运行这些步骤，没有任何问题。 期望结果 ：当用户选择已录入的文字并改变文字格式的时候，文本应该显示正确的文字格式不会出现乱字符显示。 实际结果 ：我试着选择少量的不同的字体格式，但是只有 Arial 字体格式有软件缺陷，不论如何，它可能会出现在我没有测试的其它的字体格式", "13.3 软件缺陷跟踪和分析 13.3.1 软件缺陷处理技巧 13.3.2 缺陷趋势分析 13.3.3 缺陷分布分析 13.3.4 缺陷跟踪方法 13.3.5 软件缺陷跟踪系统；13.3.1 软件缺陷处理技巧 确保被发现的缺陷能够被及时处理 及时沟通，如 reopen bug 前，事先 线下沟通 只有测试人员有关闭缺陷的权限 明确定义优先级和严重级衡量标准 注释清楚、达成一致意见 周期性的会诊 Bug 实时监控 Bug Dashboard 不要试图隐藏 Bug 收集缺陷数据，进行必要的缺陷分析", "一些缺陷处理的基本操作 可以由测试管理员、项目管理员或其他人来进行，审阅缺陷报告的质量水平； ：如果审阅者决定需要对一份缺陷报告进行重大修改，应该和测试人员一起讨论，由测试人员纠正缺陷报告，然后再次提交； ：完整地描述了问题的特征并将其分离，那么审查者就会肯定这个报告； ：分配给适当的开发人员，如果不知道具体开发人员，应分配给项目开发组长，由开发组长再分配给对应的开发人员；", "一些缺陷处理的基本操作 。缺陷的修复需要得到测试人员的验证，同时还要进行回归测试，检查这个缺陷的修复是否会引入新的问题； 重新打开 。重新打开一个缺陷，需要加注释说明、电话沟通等，否则会引起“打开-修复”多个来回，造成测试人员和开发人员不必要的矛盾 。只有测试人员有关闭缺陷的权限，开发人员没有这个权限。 。如果每个人都同意将确实存在的缺陷移到以后处理，应该指定下一个版本号或修改的日期。一旦新的版本开始时，这些暂缓的缺陷应该重新被打开。", "软件缺陷的处理和跟踪 确保每个被发现的缺陷都能够被解决，“解决”的意思不一定是被修正，也可能是其他处理方式 例如，延迟到下一个版本中修正或者由于技术原因不能被修正） 收集缺陷数据并根据缺陷趋势曲线识别测试处于测试过程中的哪个阶段； 决定测试过程是否结束，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。", "review 缺陷： 三国会议” 参加者： 项目经理和开发组长、测试组长 Bug 数据库评估每个未解决的 Bug Bug fix 优先级 可否等到下个里程碑或版本解决？ 谁来解决 预测项目实际进度和发布时间；13.3.2 缺陷趋势分析 打开/关闭 已修正的 缺陷随时间的变化 产品开发质量情况取决于累积打开 关闭曲线的趋势。 项目进度取决于累积关闭 打开曲线起点的时间差。 开发人员、测试人员的工作进度、效率也能得到反映 实时缺陷趋势分析", "累积缺陷趋势分析 累积缺陷趋势分析；收敛点 Bug 的数量 报告的 Bug 解决的 Bug Bug 收敛点；不断反弹之中收敛；13.3.3 缺陷分布分析 缺陷分布报告 ，缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。", "示例：缺陷分布分析；缺陷分析：从 Bug 中学习 eople rocess echnology 根因分析 Root Cause Analysis 案例分析与学习 Case Study 缺陷预防 ：代码规则、设计 Checklist What’s problem? What’s root cause? What’s solution?"]}, {"no": "13.3.4", "title": "缺陷跟踪方法 –Bug dashboard", "paras": ["缺陷报告 缺陷分布报告 ，允许将缺陷计数作为一个或多个缺陷参数的函数来显示，生成缺陷数量与缺陷属性的函数。如测试需求和缺陷状态、严重性的分布情况等。 缺陷趋势报告 ，按各种状态将缺陷计数作为时间的函数显示。趋势报告可以是累计的，也可以是非累计的； 缺陷年龄报告 ，显示缺陷处于活动状态的时间，展示一个缺陷处于某种状态的时间长短，从而了解处理这些缺陷的进度情况。 测试结果进度报告 ，展示测试过程在被测应用的几个版本中的执行结果以及测试", "Bug bash ” 活动 缺陷大扫除活动；必须做的 尽早定义和推广 Bug 管理流程 明确定义优先级和严重级衡量标准 清晰设置 Bug 提交必须的信息 周期性的会诊 Bug 周期性的检查 Bug；不要做的 I18N Bug L10N Bug 混为一谈 试图隐藏你的 Bug 解决和关闭你自己的 Bug 未经诊断发布一个补丁；13.3.5 软件缺陷跟踪系统 推动团队内部的有效沟通 提供报表和分析 按照优先级排列重要 Bug 跟踪任何一个 Bug 的整体生命周期 纪录任何跟 Bug 有关的操作 报告任何一个 Bug 的当前状态", "MantisBT 主要功能；开源缺陷跟踪系统 Mantis http://mantisbt.sourceforge.net/ Bugzilla http://www.mozilla.org/projects/bugzilla/ Bugzero http://bugzero.findmysoft.com/ Scarab http://scarab.tigris.org/ TrackIT http://trackit.sourceforge.net/ Itracker http://www.itracker.org/ 更多工具详见 此公众号文章", "13.4 产品质量评估与度量 13.4.1 基于缺陷的质量度量 13.4.2 经典的种子公式 13.4.3 基于缺陷清除率的估算方法 13.4.4 软件质量的度量；软件度量的分类与过程 分类： 软件过程度量、项目度量、产品质量度量 识别目标 分析出度量的工作目标和列表，并由管理者审核确认 定义度量过程 定义其收集要素、收集过程、分析、反馈过程、 支持体系，为具体的收集活动、分析、反馈活动和 设备、工具开发提供指导 搜集数据 工具进行数据收集工作，并按指定的方式审查和存储 数据分析与反馈 根据数据收集结果，按照已定义的分析方法进行数据分析，完成规定格式的图表，进行反馈 过程改进 根据度量的分析报告，管理者基于度量数据做出决策", "13.4.1 基于缺陷的质量度量 代码的缺陷密度，每千行代码（ KLOC ）的缺陷数（ Bug# /KLOC 缺陷清除率：各个阶段的缺陷清除率和总的缺陷清除率 缺陷逃逸率：未在研发阶段发现的缺陷意味着逃逸出去，即线上发现的缺陷（生产环境发现的缺陷），缺陷逃逸率 线上发现的缺陷数 （线上发现的缺陷数 研发环境下发现的缺陷数）； 缺陷趋势是否良好，是否收敛 缺陷分布是否符合正态分布？是否过于集中在 1-2 个模块？", "缺陷度量 度量项 低水平 缺陷清除效率 >95% <70% 原有缺陷密度 每个功能点 <4 每个功能点 >7 缺陷数 /KLOC <2 >=4 缺陷数 /100 case >3 <1 缺陷数 /Man-day > 3 < 1；13.4.2 经典的种子公式 已测试出的种子 Bug (s) 已测试出的非种子 Bug (n) 所有的种子 Bug (S) 全部的非种子 Bug (N) 则可以推出程序的总 Bug 数为： N = S * n /s 是所进行实际测试时发现的 Bug 总数。如果 n = N, 说明所有的 Bug 已找出来，说明做的测试足够充分。 这种测试是否充分，可以用一个信心指数来表示，即用一个百分比表示，值越大，说明对产品质量的信心越高，最大值为 = 1 if n>N = S/(S-N+1), if n<=N", "13.4.3 基于缺陷清除率的估算方法 为描述软件规模用的功能点； 为在软件开发过程中发现的所有缺陷数； 为软件发布后发现的缺陷数； 为发现的总缺陷数。 D=D1+D2 = D2/F 缺陷注入率 = D/F 整体缺陷清除率 =D1/D 缺陷源 潜在缺陷 清除效率 (%) 被交付的缺陷 需求报告 1.00 0.23 1.25 0.19 1.75 0.09 0.60 0.12 错误修改 0.40 0.12 5.00 0.75", "13.4.4 软件质量的度量 软件可靠性度量、复杂度度量、缺陷度量和规模度量 c1×f1 c2×f2 cn×fn 是一个软件质量因素 SQRC 层各项待计算值 是影响质量因素的度量值（如 SQDC 层各项估计值）， 是加权因子。", "质量度量的统计方法 说明不完整或说明错误 (IES) 与客户交流不够所产生的误解 (MCC) 故意与说明偏离 (IDS) 违反编程标准 (VPS) 数据表示有错 (EDR) 模块接口不一致 (IMI) 设计逻辑有错 (EDL) 不完整或错误的测试 (IET) 不准确或不完整的文档 (IID) 将设计翻译成程序设计语言中的错误 (PLT) 不清晰或不一致的人机界面 (HCI) (MIS)", "质量度量的统计方法 百分比 百分比 百分比 百分比 IES 296 22.3% 28.2% 18.6% 146 23.4% MCC 204 15.3% 9.2% 17.0% 15.9% IDS 4.8% 1.0% 6.1% 5.0% VPS 2.6% 0.5% 3.7% 2.2% EDR 182 13.7% 19.5% 17.6% 8.7% IMI 6.2% 7.2% 4.1% 7.5% EDL 4.8% 10.3% 3.3% 4.3% IET 140 10.5% 8.7% 10.0% 11.6% IID 4.1% 1.5% 5.5% 3.7% PLT 6.5% 11.3% 5.1% 6.3% HCI 3.2% 2.1% 5.3% 1.8% MIS 6.1% 0.5% 3.9% 9.6% 1330 100% 195 100% 512 100% 623 100%", "质量度量计算 阶段错误度量 = W ) + W ) + 总体质量度量 )/P = 1, 2, 3, 4, 5 代表需求分析、设计、编程、测试、发布 = 1, 2, 5, 10, 100) , W , W = 0.6, 0.3, 0.1；度量及其指标 Designed cases Executed cases Found bugs/Day Missed bugs 度量可以推动测试流程的改进 不良的度量也可以使测试流程的执行变形", "13.5 测试的评估与报告 13.5.1 测试过程的评估 13.5.2 测试充分性的评估 13.5.3 测试报告；测试过程的评估 是否完成了测试计划所要求的各项测试内容？ 测试用例是否经过开发人员、产品经理的严格评审？ 系统测试是否包含了性能、兼容性、安全性等各项测试？ 如果执行了，又是怎么进行的、结果如何？ 需要执行的测试用例是否百分之百地完成了？ 所有严重的 Bug 都修正了？ 测试过程评审，结合测试计划来进行评审，相当于把计划的测试活动和实际执行的活动进行比较，了解测试计划执行的情况和效果， 可以多提问，例如：", "发现测试过程的风险；13.5.2 测试充分性的评估 测试结果分析的一项重要工作就是 测试充分性的评估 ，通过了解测试覆盖率的值，可以知道测试是否充分、测试能否结束 测试覆盖率 是用来衡量测试完成程度、或评估测试活动覆盖产品代码的一种量化的结果，评估测试工作的质量，也是产品代码质量的间接度量方法 测试覆盖率可以看作由 业务需求、系统特性功能／非功能特性和代码 等多个层次的等构成", "测试覆盖率分析 三个层次、两种视角；13.5.2 测试报告 在国家标准 GB/T 17544 1998 （附录 ）对测试报告有了具体要求，对测试纪录、结果如实汇总分析，报告出来 产品标识； 用于测试的计算机系统 使用的文档及其标识 产品描述、用户文档、程序和数据的测试结果； 与要求不符的清单； 针对建议的要求不符的清单，产品未作符合性测试的说明； 测试结束日期。", "本章小结 讲解了如何有效地执行测试，包括测试进度控制等。 讲解了如何正确、规范地描述、分离、分类、记录和跟踪软件缺陷，以保证它们有效地、快速地被修复、最终得到解决。 需要建立软件缺陷跟踪数据库存储、搜索和分析软件缺陷，从而生成一系列的图表，分析项目的发展趋势，控制项目进度，并进行根因分析，找到问题所在，预防缺陷。 讲解了如何评估产品质量和度量质量，包括基于缺陷的方法、经典的种子公式等 测试过程评审，测试结果分析以及测试报告", "安装和使用缺陷跟踪系统 MantisBT https://mantisbt.org/；10: MeterSphere 的综合实验 在线或离线安装 MeterSphere 创建项目、建立项目成员和基础测试配置环境； 完成一个完整的接口测试，包括接口调试与定义、接口测试用例的设计、基于真实场景的自动化测试等； 完成一个完整的性能测试，包括场景配置、压力配置、高级配置、结果分析等； 完成一个完整的功能测试流程：设计用例、用例评审、制定一个测试计划、缺陷管理和生成报告。 课程资源提供了详细的指导实验的视频，本实验可作为课程的大作业 实践考试"]}], "14": [{"no": "", "title": "软件测试展望", "paras": ["软件测试方法和技术 章 软件测试展望；14.1 大数据的测试 14.2 系统的测试 14.3 助力软件测试 14.4 软件测试工具的未来 14.5 彻底实现持续测试 14.6 软件测试发展趋势；14.1 大数据测试 14.1.1 大数据的特性与挑战 14.1.2 大数据的测试方法 14.1.3 大数据的测试实践 14.1.4 大数据的测试工具", "大数据的测试 每个节点上的业务逻辑验证 数据聚合或隔离规则验证 生成的键值对验证 验证正确的数据被提取并加载到正确的 HDFS 检查转换规则 检查数据完整性、一致性；ETL 过程示例 EXF (Extracted Format) 由数据源Extract产生的文件，文件结构与Source相似，经过过滤，部分字段被忽略。 CIF (Common Interface Format) CIF是ETL经过C/S/S过程产生的中间数据文件。 PLF (Pre-Load Format) 经过数据转换，用于直接加载到数据仓库的文本文件，其数据结构与数据仓库中的表定义一致。 ETL ：数据 Extraction Transformation Loading", "数据抽取与清洗 全量、增量抽取 清洗异常数据、不符合规范的数据 空值处理 规范化数据格式 实现数据规则过滤 准确性，能将业务系统中的变化数据按一定的频率准确地捕获到 性能，不能对业务系统造成太大的压力，影响现有业务。 抽样测试验证 对比处理前后的数据量变化 验证数据合法性 字段逻辑验证 枚举类型的字段查看枚举分布，如性别、年龄、地域、学历等分布，以及活跃小时段分布", "数据转换及其测试 数据替换 字段映射 数据过滤 数据加解密 数据类型统一转换 拆分数据 数据按主题划分 数据排序 白盒转换测试：检查转换逻辑和映射设计、代码实现逻辑、转换后的数据与文档中的数据进行比较 黑盒转换测试：准备测试数据来反映文档中列出的不同转换场景；数据映射验证 连接验证 ：必需端口均已连接，并且所有连接都有效。 表达式验证： 所有表达式都有效。 对象验证： 独立对象定义与映射中的实例匹配。 数据流验证 ：数据必须能够从源流到目标，而不会在阻止转换处挂起", "大数据测试保障维度 数据清洗 数据分析 数据加工 数据正确性验证 数据过滤验证 业务场景验证 数据正确性验证 数据过滤验证 业务场景验证 数据正确性验证 业务场景验证 主流程调度验证 接口协议验证 性能指标验证 掌握整体请求链路 化整为零，各个击破 真实数据丰富用例场景 注意点；大数据测试主要工作 测试数据准备 ETL测试 OLAP和Cube测试 报告测试 验证所要求的数据和数据源 数据分析 数据质量&性能 验收标准 数据转换规则 查看数据字典 (元数据) 验证源与目标映射 ETL/DW的验证体系结构 数据模型的验证 （建模维度、规范化治理） 索引、分区等 档案/清洗策略 错误日志/异常处理/可恢复性 并行执行&优先级 ETL pull 全量/增量 ETL Extraction-Transformation-Loading ）：用于完成 的数据转存 DW：Data Warehouse（数据仓库）； OLAP ：在线分析系统； Cube ：面向多维数据库的立方体 数据采集清洗测试 数据转换测试 专项测试 四个阶段", "大数据 ETL 流程与测试；大数据架构设计 ADS ：应用数据层，存放数据产品个性化的统计指标数据，主要面向 和报表展示。目前包含 mysql druid kylin DWS ：汇总数据层，根据主要的维度进行轻度聚合，构建公共指标数据层。目前数据存放在 hdfs 上，提供 hive DWD ：明细数据层，采用维度退化的方式，将维度退化的事实表中，减少事实表和维度表的关联。目前主要存储模型数据，存放在 hdfs 上，提供 hive 结构分层 ADS DWS DWD DWD ADS 服务日志 外部接口数据 报表查询 告警服务 大数据平台 离线处理层 实时处理层 ... 数据服务 数据源", "大数据计算链路 DWD 实时计算 DWS DWD ADS 数据分析 离线计算 数据服务 告警服务 财务系统 数据仓库；大数据测试流程（清洗、分析） 智能化测试 数据来源 数据关系 计算逻辑 大数据任务配置 维度字段：映射转换 指标字段：计算逻辑 过滤条件 异常场景 配置文件、数据通道、产物路径等 多方报表对比验证 接口协议测试 服务主流程 服务日志 代码评审 测试框架评审 服务日志构造工具开发 报表数据构造工具开发 diff 工具开发 测试数据验证功能 现网数据回归测试 现网数据，新老版本数据对比 多方报表对比验证 接口协议测试 主流程各任务调度 定时任务调度 服务告警触发 服务日志 总量上验证 多方报表对比验证 数据准备 测试执行 现网验证 需求分析 设计评审 测试框架编写", "大数据测试自动化 目标：缩短测试过程，提高测试效率和效果 数据准备自动化 数据验证自动化 回归测试自动化 服务日志和报表数据 的构造工具开发 diff 工具开发 引入接口自动化平台 所有服务日志 所有数据来源报表 清洗阶段 分析阶段 数据服务阶段 离线报表 实时报表 数据服务报表；数据准备自动化 数据格式转换 测试数据构造 解析现网日志 拉取最新日志 数据表：最新天数据 配置表：全量同步 真实数据： 脚本同步 特殊数据：造数平台 服务日志构造 报表数据构造 效果：解决输入输出不明确问题；数据可复用、维护成本低、准备时间有效缩减", "数据验证自动化 数据验证 手工测试 直接获取 联表查询得到 维度字段测试 简单聚合 复杂场景计算 多层计算，分帐逻辑 指标字段测试 维度测试 指标测试 多表测试 2017 数据验证 自动化测试 程序直接输出不一致的结果 维度字段测试 保留中间计算结果，以备排查问题 输出每种场景下实际、期望结果 指标字段测试 可复用 一次运行，所有表结果自动输出 多表测试 2017 容易疲劳测试、易出错 每个指标都需要计算，比较耗时 类似表处理逻辑，手工计算无法复 复用性高 计算速度快，测试耗时缩短了 90% 定位问题方便", "14.2 系统的测试 Test for 14.2.1 系统的不确定性和不可解释性 14.2.2 系统的白盒测试 14.2.3 系统的算法验证 14.2.4 示例：针对智能语音的设计与执行；Test for AI ~ 从图灵测试说起 计算能力 产生随机数 推理力；如何测试 软件？ 测试AI软件，检验它有没有学习能力，本质上，就是算法的验证，即对元 启发式搜索算法、 深度）强化学习等算法或其组合进行验证，一般通过实验进行，借助大量数据进行普适性验证。", "测试方法 验证与测试 质量需求 模型解释 模型检验 测试标准评估 评估报告 Passed failed Neuron coverage Neuron boundary coverage 结构化 黑盒方法；机器学习开发流程 &；机器学习研发生命周期：简化模型 定义问题 数据收集 特征工程 模型训练 数据质量 特征质量 模型质量；机器学习测试难点 技能、知识要求高 抽象、因素多、数学深 数据获取、问题分析难 强数据相关 数据质量要求高 特征维度多 模型模型优化慢 上线才刚开始 迭代慢 验收标准不确定 上线效果不确定", "机器学习测试特点 传统软件测试 机器学习测试 被测试的对象 软件功能 、工程代码 算法模型 、数据和代码 产品目标 客观具体 主观抽象 测试的输入 操作、输入数据 数据或者代码 评测输出 不确定 Test Oracle 需求文档 由开发及特征工程师一起确认 测试充分的标准 覆盖率 不确定 Bug 较常见 承担测试的角色 测试工程师 模型（数据算法）工程师，开发工程师", "机器学习测试的重点 Model Training Running System Unit Tests Infrastructure Tests Integration Tests 数据测试 Data Monitoring Prediction Monitoring System Monitoring 特征测试 模型测试 Data Data", "数据质量 正确性 Accuracy) 数据是否正确体现真实的业务或可证实的来源 完整性 Integrity) 基于业务分析，数据（字段 参数等）是否充分、完备 一致性 Consistency) 数据是否被一致的定义或理解 有效性 Validity) 数据是否在业务定义的、可接受的范围之内 时效性 Timeliness) 数据是否已过时？ 可获取性 Accessibility) 数据是否易于获取与使用", "数据质量分析方法 某模块涉及哪些表？ 表的关联关系？ 数据时序上是 否存在问题？ 每个字段是否有 问题？ 数据是否一致？ 输出血缘关系图 血缘基数分析 波动分析 值域分析 数据分布分析 （异常分析） 有效字段一致率；特征测试的关键 特征阈值 特征相关性 重要性 特征与结果变量的关系 特征适合性 计算成本 特征合规性 特征工程 单元测试 特征工程 静态检查 特征一致性", "特征测试要点示例：风控模型场景 特征在线 前后一致 跑批日志 特征值一致 响应时长 覆盖率一致 特征回溯验证 离线在线一致 监控效果 特征调度 回溯数据处理 loan_dt 空字符处理 异常处理 命名规范 性能 跑批时间 四元组顺序 HQL 应用逻辑准确 Map 特征离线 计算逻辑 Shuffle( 特征产出顺序 特征回溯 接口响应时间 编码规范 分区修改 性能 计算时长 命名规范 异常测试", "特征效果分析指标 特征分析指标 指标说明 PSI Population Stability Index 评估特征稳定性 CSI Characteristic Stability Index 指数，回答了哪个变量导致数据分布变化的问题 Kolmogorov-Smirnov 用于特征对于风险区分能力的评估 Information Value 特征预测能力评估", "特征稳定性测试架构 离线diff 样本获取 f 处理模块 f 处理结果 MapReduce请求 在线的不同环境 MapReduce请求 在线接口 获取离线特征 获取离线特征 统一dif 各环境下的整体覆盖率 相同覆盖下的diff样本及对应的特征 每维特征的diff率 覆盖率不同的样本 相同覆盖样本 下的整体diff率 在线diff 在线/离线diff", "算法验证 Review （评审） 测试数据集 具体验证指标 交叉验证 cross validation 对抗验证 A/B；算法评估指标 评价性能指标 可释方差分数 均方方差 （Mean Square Error, MSE） 平均绝对误差 （Mean Absolute Error, MAE） 召回率 精准率 准确率 ROC AUC （Coefficient of determination，决定系数） ROC eceiver perating haracteristic 横轴： False positive rate, FPR 特异度 纵轴： Recall(true positive rate, TPR) 灵敏度 AUC ：Area under ROC Curve", "分类算法评价指标 P-R 精确率越高，则模型对负样本区分能力越强 召回率越高，则模型对正样本的区分能力越强 如果类别比较均衡，使用 Micro Macro 如果认为大样本的类别应该占据更重要的位置， 使用 Micro 如果认为小样本应该占据重要的位置，则使用 Macro Micro << Macro ， 则意味着在大样本类别中出现了严重的分类错误 Macro << Micro ， 则意味着小样本类别中出现了严重的分类错误", "示例：分类问题指标计算 实际：猫 实际：非猫 预测：猫 预测：非猫 TP – True Positive FN – False Negative TN – True Negative FP – False Positive 准确率 Accuracy TP+TN)/(TP+TN+FP+FN) 精准率 Precision TP/(TP+FP) 召回率 recall TP/(TP+FN) 实际：猫 实际：非猫 预测：猫 预测：非猫 （上一例子的数据） 准确率 7/10 =70% 精准率 75% 召回率 3/6 60%", "示例：回归类算法验证 回归类 算法评价指标；算法的专项测试 数据隐私 预测效率 可靠性 公平性 可解释性 安全性；常用的测试方法 蜕变测试 效果测试 数据测试 常规逻辑 小样本试验 /AB 根据公式特点，特定变换数据，结果比较 ETL 质量，特征质量， Fuzz 数据构造异常 业务逻辑、性能 样本验证评估 专业评测指标 类别标签乱序； 属性乱序； 增加无信息属性； 一致重复预测； 分布、 diff 、性能时长等 PSI 精确率 召回率 F1-Score AUC", "示例：可靠性测试 用FGSM方法生成的一个对抗样本。 左：一张干净图片，被模型正确分类为熊猫 中：扰动 右：扰动后的熊猫图片，被模型识别为长臂猿；14.3 助力软件测试 14.3.1 基于图像识别技术的 14.3.2 的、全自动化的 API 14.3.3 助力代码深度分析 14.3.4 驱动测试 14.3.5 测试工具；测试的智能化 智能的单元测试 智能的 UI/API 驱动的脚本 或补充 质量风险评估的自我调整 缺陷诊断机器人（ DDB 测试环境的 Test smarter, not harder Applitools、Appvance IQ、 Eggplant AI、Test.AI、 Functionize", "应案例： SikuliX https:// github.com RaiMan Implement the API completely as a REST-API backed by a server running on the target machine SikuliX1 SikuliNG；应用案例：目标检测技术；驱动的智能测试 基于游戏图像来开发游戏 的开源工具包，包括 检测、 元素识别、 算法等功能 https://wetest.qq.com/product/game_ai_sdk https://github.com/Tencent/GameAISDK/", "应用案例： OCR OCR OCR 文字识别能力可以很好地帮助解决 webview 页面元素无法识别的问题；OCR 技术应用于测试 https://docs.openvinotoolkit.org/latest/index.html https://github.com/openvinotoolkit/openvino；应用案例： NLP 约定测试用例描述规范 建立专业知识图谱 与用例管理系统打通 一键批量转化", "应用案例：神经元演化算法 Monte Carlo 树搜索算法、自动启发式构建算法、 增强拓扑的神经元演化算法 测试工具 (bots) ，模拟人类交互能力，完成对游戏程序的测试或评估 Alexander Andelkovic King/Midasplayer AB 获得训练数据：预测成绩 创建随机的机器人（ bots 竞争测试（计算成绩） 创建新的机器人 选择最好的机器人（基于 ANN ANN 选择移动、继续操作游戏 最合适的 bot bots", "应用案例：失败用例分析 相同失败用例聚类 智能化算法辅助分析 用例全量执行日志 日志分析 聚类信息 粗清理 精细清理 关联的调用链 关联的业务代码 关联的用例脚本 关联的业务配置 离线分析 在线分析 失败原因推荐 人工反馈 可疑点 可疑点 可疑点 可疑点 建立用例级多源数据画像 执行环境 用例执行日志 业务日志 服务自身 服务依赖系统 用例脚本 用例覆盖代码 调用链日志 流水线部署参数 失败用例分析 Service JavaAgent 单用例级", "基于形式化语言的 API 智能测试 问题反馈 执行日志 在线数据 交付场景 测试数据 特征提取规则库 数据清洗模型库 特征数据清洗 去量纲化 模型参数训练 数据样本集 真实数据学习 强化学习 加速学习 周期性同步 测试覆盖度组合 API 参数关联分析 测试脚本关联关系 测试相似度聚类 测试脚本库 测试模型库 测试脚本筛选和测试模式选择 精准测试任务调度和执行 测试管理平台 测试数据采集与分析", "低代码测试平台；低代码测试平台 为测试用例创建一个模型，直观地展示测试执行的路径，适合设计复杂的测试场景 在需求分析阶段就创建测试步骤，有助于团队内部沟通澄清需求；零代码智能测试工具 APIAuto；MBT+AI 合力相助测试；MBT+AI 合力相助测试 NLP E2E Web 测试依赖项检测 验证所有依赖关系，并使用一个新的恢复算法来确保在最终的测试依赖关系图中没有遗漏任何真正的依赖关系 ，提高回归测试覆盖率", "14.4 软件测试工具的未来 14.4.1 软件测试工具的发展趋势 14.4.2 Codeless 测试自动化；软件测试工具的发展趋势；低代码测试平台；零代码智能测试工具 APIAuto；14.5 彻底实现持续测试 14.5.1 重新理解持续测试 14.5.2 实现框架 14.5.3 持续测试成熟度模型 14.5.4 彻底的持续测试；持续测试 测试可以随时开展起来，且具有连续性 测试和开发、运维能很好地融合、匹配和同步起来 以最少的测试、最快的速度覆盖交付所面临的业务风险", "持续测试的特点 足够快 整个测试过程要快，一方面高度自动化测试，另方面业务端到端的探索式测试 准确且有效 被测系统往往很复杂，不可能做全回归测试，而是要推行精准测试 平滑有序 打通整个测试过程：测试左移到测试右移、单元测试到系统测试、静态测试到动态测试 CI/CD 与研发的持续构建、持续集成、持续部署、运维等环境的集成；持续测试实施框架；14.6 软件测试发展趋势 14.6.1 MBT 的应用前景 14.6.2 软件测试六大趋势", "一个新时代 我们可以 用很多词汇 来形容这个时代：移动互联 Cloud 数字化 等等，但更是 软件定义一切的时代 移动互联 数字化 软件定义一切；MBT 通过使用 MBT 工具会让这个建模过程更加规范和可视化，增加了模型的可读性和重用性。 在敏捷开发中采用 MBT 可以促进持续交付，有效的应对敏捷测试中的风险 技术和 MBT 结合会更强大，使用 技术创建训练测试模型，利用算法为不同的测试覆盖率基于风险推荐测试路径", "示例：模型检测 LTL 模型检测工具 SPIN Simple Promela Interpreter ）对并发系统进行建模并检测一个有限状态系统是否满足 PLTL CTL 模型检测工具 SMV CMU 采用二叉图表示状态转换关系，以计算不动点的方法检测状态的可达性及其所满足的性质 演算工具 CWB （爱丁堡大学及美国北卡大学） 用于检测系统间的等价关系、 PRE-ORDER 关系及系统是否满足 演算公式 NuSMV ：符号模型检测器（ SMC ），基于 BDD SAT 的模型检验 NuXmv SMC ，但可以支持同步的有限状态或无限状态系统的分析 Murphi （斯坦福大学 犹他大学） 是许多模型检测的基础，例如在此基础上开发的 CMurphi Preach", "软件测试六大趋势 敏捷化：测试左移到位（ ATDD ）、测试右移显著增强 超级自动化：让自动化测试成为流水线 云化：基础设施支持自动化运行 服务化：一切测试皆 API ，提升自动化测试效率 模型化： MBT 让自动化测试更彻底 智能化：基于大数据与 ，让自动化测试更智能；示例：云化；测试服务化 基础设施即代码 IaC API 、服务的云平台 支持一键部署 自动监控、高度可视化 在线实时收集数据 大数据处理能力", "示例：手淘 RXT 测试机器人 加载时长体验数据分析 实际案例 计算点击消息 Tab 加载时长 240fps 高速摄像头 <5ms) ，无需参照目标，自动识别准确率 >=95% 基于视频特征分析的加载时长自动化过程；大数据的测试贯彻数据清洗、转换、存储、加载等全过程，包括抽样测试验证、数据对比分析和数据映射验证等。 智能应用（如机器学习）的测试是为了更好地保证数据质量、特征质量和模型质量，目前有成熟的评价指标体系。 技术（图像识别、 NLP OCR 等）应用于软件测试的各个方面，从单元测试、系统的 API 测试、 测试和测试日志分析等，而且可以和 MBT 结合起来产生更好的效果 未来软件测试六大发展趋势：敏捷化、高度 超级自动化、云化、服务化、模型化、智能化"]}]}