测试覆盖率

• 测试覆盖率被用来衡量测试测充分性和完整性，从广义角度讲，测试覆盖率主要分为两大类，一类是面向项目的需求覆盖率，一类是偏向技术的代码覆盖率

需求覆盖率

• 需求覆盖率是指测试对需求的覆盖程度，通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系，最终目标是保证测试可以覆盖每个需求，以保证软件产品的质量
• 通常采用ALM，Doors和TestLink等需求管理工具建立需求和测试的对应关系，并以此计算测试覆盖率
• 现在人们口中的测试覆盖率，默认指代码覆盖率(因为需求覆盖率是传统模型下的工程时间，难以适应当今互联时代下的敏捷开发)

代码覆盖率

• 简单说，是指至少被执行一次的条目数占整个条目数的百分比
• 常用的三种代码覆盖率指标
  • 行覆盖率又称为语句覆盖率，指被执行的语句占总可执行语句的百分比
  • 判定覆盖率又称分支覆盖，指代码中每个判断的取真分支和取假分支是否被覆盖至少各一次
  • 条件覆盖，判定中的每个条件的可能取值至少满足一次，判定每个条件中结果的TRUE和FALSE是否都被测试到了

代码覆盖率的价值

• 代码覆盖率的根本目的是找出潜在的遗漏测试用例，并有针对性的进行补充，同时可以识别出代码中那些由于需求变更等原因造成的不打达的废弃代码
• 代码覆盖率的提高，会付出很大的代价(后期需要大量的桩代码，Mock代码和全局变量配合)
• 在企业中，只有单元测试对代码覆盖率有较高的要求

代码覆盖的局限性

• 代码覆盖率的计算是基于现有代码的，并不能发现那些’未考虑某些输入’以及’未处理某些情况’形成的缺陷
• 只能反映已有代码的哪些逻辑被执行过了，对于代码未实现部分，就无能为力
• 搞得代码覆盖率不一定能保证软件的质量低的代码覆盖率一定不能保证软件的质量

代码覆盖率工具

• 以java为例， jaCoCo可以很方便嵌入到Ant,Maven中，和主流的持续集成工具(jekins)和代码静态检查工具(Sonar)，都有很好的集成
• java代码覆盖率统计报告
  • 绿色的行表示已经被覆盖，红色的行表示尚未被覆盖，黄色的行表示部分覆盖；左侧绿色菱形块表示该分支已经被完全覆盖、黄色菱形块表示该分支仅被部分覆盖

代码覆盖率工具的实现原理

• 实现代码覆盖率统计，最基本的方法就是注入(Instrumentation)，简单的说，注入就是在被测代码中自动插入用于覆盖率统计的探针(Probe)代码，并保证插入的探针代码不会给原代码带来任何影响
• 对于java来说，根据注入目标不同分为源代码(source code)注入和字节码(byte code)注入两大类，基于JVM本身特性，目前主流工具都使用字节码注入，具体实现采用ASM技术
  • 根据注入发生的时间点，字节码注入又分为两大模式：On-The-Fly和Offline
  • On-The-Fly注入模式，特点在于不需要修改源代码，可以在系统不停机情况下，实时收集代码覆盖率信息，缺点是必须使用java Agent
    • 主要有两种技术方案：开发自定义的类装载器和借助java Agent
  • Offline注入模式，无需修改源代码，但是需要在测试开始之前对文件进行插桩，事先生成插过桩的class文件，适合于不支持java Agent的运行环境以及无法使用自定义类装载器的场景，缺点是系统停机获取

缺陷报告

• 缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出
• 要把缺陷准确无歧义的表达清楚
• 好的缺陷报告不是信息的堆叠二十以高效的方式提供准确有用的信息

缺陷标题

• 是对缺陷的概括性描述，通常采用‘在什么情况下发生了什么问题’的模式
• 首先，对’什么问题’的描述不仅要做到清晰简洁，最关键的是要足够具体
  • 描述问题的同时还要清楚的表述发生问题时的上下文(问题出现场景)
• 其次，标题应该尽可能描述问题本质，而避免只停留在问题的表面
  • 如:商品金额输入框，没有对内容进行校验
• 最后，缺陷标题不易过长，对缺陷更详细的描述应该放在’缺陷概述’中

缺陷概述

• 通常提供更多概括性的缺陷本质与现象的描述，是缺陷标题的细化(是开发工程师最先关注的内容)
• 可以列出同一类型缺陷可能出现的所有场景；是否在之前的版本中重现等，使用概括性语句描述
• 清晰简洁描述缺陷，使开发工程师能够聚焦缺陷本质

缺陷影响

• 描述的是，缺陷引起的问题对用户或者对业务的影响范围以及严重程度
• 决定了却显得优先级(Priority)和严重程度(Severity)
• 前提：必须对软件的应用场景以及需求有深入的理解

环境配置

• 环境配置用以详细描述测试环境配置的细节，为缺陷的重现提供必要的环境信息
  • 通常有操作系统的类型和版本，被测软件版本，浏览器种类和版本，被测软件配置信息，集群配置参数，中间件版本信息等
• 按需描述，只描述那些重现缺陷的环境敏感信息

前置条件

• 指测试步骤开始前系统应该处在的状态，目的是减少缺陷重现步骤的描述，合理的使用前置条件可以在描述缺陷重现步骤时排除不必要的干扰，使其更有针对性

缺陷重现步骤

• 缺陷重现步骤是整个缺陷报告中最核心内容，目的在于用简洁的语言项开发工程师展示缺陷重现的具体操作步骤
• 操作步骤通常是从用户角度出发来说的，每个步骤都应该是可操作并且连贯的，往往采用步骤列表的表现形式
  • 通常在写缺陷步骤前，要反复执行步骤三次以上：一是确保缺陷的可重现性，二是找出最短的重现路径
  • 避免笼统的描述，步骤不可操作，步骤与缺陷重现无关，没有测试数据

期望结果和实际结果

• 期望结果来自对需求的理解，实际结果来自测试执行的结果
• 描述期望结果时，需要说明应该发生什么而不是什么没发生

优先级(Priority)和严重程度(Severity)

• 缺陷优先级指缺陷必须被修复的紧急程度，缺陷严重程度指因故障对软件产品的影响程度
• 严重程度是缺陷本身的属性，通常确认后就不在变化
• 优先级是缺陷的工程属性，会随着项目进度、解决缺陷的成本等因素而变动
• 一般缺陷越严重、影响范围越大优先级越高，或者严重影响了测试/自动化测试进行
• 有些缺陷优先级高，但是修复成本和技术难度会使他优先级较低

变通方案(Workaround)

• 提供一种临时绕开当前缺陷而不影响产品功能的方式
• 变通方案的有无以及实施的难易程度，是决定缺陷优先级和严重程度的重要依据

根原因分析(Root Cause Analysis)

• 根原因分析就是通常说的RCA，如果能在发现缺陷的同时，定位出问题的根本原因，清楚的描述缺陷产生的原因并反馈给开发。

附件(Attachment)

• 附件通常是为缺陷存在提供必要的证据支持
  • 界面截图，测试用例日志，服务端日志，GUI测试的执行视频等

测试计划

• 由于敏捷开发模式，很多非产品型公司很少会去制定传统意义上的测试计划了
• 但是测试计划依旧存在，只是从原来的一次性集中指定测试计划，变成了以迭代的方式指定测试计划

测试计划的目的

• 知道具体的测试范围，以及具体的测试策略
• 预计具体的工作量和所需要的测试工程师数量，明确分工
• 控制整体测试进度，预估完成时间节点
• 能够应对突发事件

测试范围

• 描述的是被测对象以及主要的测试内容
• 测试范围的确定通常是在测试需求分析完成后进行，也是对测试需求分析的进一步检验，有助于早期发现潜在的测试遗漏
• 要对测试内容有取舍，明确’测什么’和’不测什么’

测试策略的话题

• 就是需要明确‘先测什么后测什么’和‘如何来测这两个问题’
• 明确测试重点，以及各项测试的先后顺序
• 还需要说明，采用什么样的测试类型和测试方法
• 1，功能测试
  • 根据测试需求分析的思维导图来设计测试用例
  • 主线业务功能测试经常需要回归测试，应该考虑自动化测试，选择合适的自动化框架
  • 注意：先实现主干业务流程的测试自动化
• 2，兼容性测试
  • web需要确定覆盖的浏览器类型和版本，移动端测试需要确定覆盖的设备类型和具体系统版本
  • 一般是功能测试后期，但是如果前端引入新的框架/组件库，会先在前期做兼容性
  • GUI自动化框架，就需要能在同一套脚本不做修改的前提下，运行不同的浏览器
• 3，性能测试
  • 明确性能需求(并发用户数，响应时间，事务吞吐量)
  • 如：在API级别发起压力测试，必须模拟用户基于协议进行，(基于模块/发起全链路压测)
  • 如果性能是背景数据敏感的场景，还需要确定背景数据量级与分布，并决定产生背景数据的·1技术方案
• 还有比如，接口测试、集成测试、安全测试、容量验证、安装测试、故障恢复测试等

测试资源

• 明确谁来测和在哪里测
• 测试工程师经验和能力可以弥补人员数量上不足
• 要把具体的任务清晰的落实到每个人身上，建立清晰的责任机制

测试进度

• 主要描述各类测试开始时间，所需工作量，预计完成时间，以此为依据决定最终产品上线发布时间
• 在敏捷开发模式下，测试活动贯穿整个开发过程，很多测试工作会和开发工作同步进行，如行为驱动开发(BDD)，最知名的框架就是Cucumber

测试风险预估

• 原因：需求变更，开发延期，发现重大缺陷，人员变动
• 指定测试计划时，就要预估整个测试过程可能存在的潜在风险，以及发生风险的应对策略

核心竞争力

• 测试开发岗位的核心是测试，开发的目的是更好的服务于测试

传统测试工程师的核心竞争力

1，测试策略设计能力

• 对于各种不同的被测软件，快速理解需求，在有限时间和资源下，明确测试重点以及最合适的测试方法
• 可以非常明确的解决关键问题
  • 测试要具体执行到什么程度
  • 测试要借助社么工具
  • 如何运用自动化测试以及自动化测试框架，以及如何选型
  • 测试人员资源如何合理分配
  • 测试进度如何安排
  • 测试风险如何应对
• 不是一朝一夕的事情，需要经过大量项目的实际历练，潜移默化形成的
• 是最核心的能力，也是最难培养的

2，测试用例设计能力

• 无论对于什么类型的测试，都能设计出高效地发现缺陷、保证产品质量的优秀测试用例
• 做好测试用例设计，不仅要深入理解被测软件的业务需求和目标用户的使用习惯，还要熟悉软件的具体设计和运行环境（包括技术架构、缓存机制、中间件技术、第三方服务集成等）
• 需要不仅仅局限于熟悉业务领域的测试用例设计，而且能够融会贯通，熟练把测试设计方法和具体业务有机结合
• 平时要多积累，对常见的缺陷模式，典型的错误类型以及遇到的缺陷，要不断的总结，归纳，才能逐渐形成体系化的用例设计思维，同时还可以阅读好的测试用例设计实例开阔思路

3，快速学习能力

• 对不同业务需求和功能的快速学习与理解能力
• 对于测试新技术和新方法的学习与应用能力
• 学习新工具，建议直接看官方文档，最新最权威；学习新内容，一定要理解其原理，不能只停留在表面，简单的操作和使用

4，探索性测试思维

• 在执行测试过程中不断学习被测系统，同时结合基于自己经验的错误猜测和逻辑推理，整理和分析出更多有针对性的测试关注点
• 本质上，探索性思维是’测试用例设计能力’和’快速学习能力’有机结合的必然结果
• 优秀的探索性思维可以帮组你实现低成本的’精准测试’，通俗理解可以概括为针对开发代码的变更，目标明确并且有针对性地对变更点以及变更关联点做测试，这也是目前敏捷测试主推的测试实践之一

5，缺陷分析能力

• 对于已发现的缺陷，结合发生错误的上下文和后台日志，可以预测或者定位缺陷发生的原因，甚至可以明确指出具体错误的代码行
• 根据已发现的缺陷，结合探索性思维，推测同类缺陷存在的可能性，并找出所有相关的潜在缺陷
• 对于一段时间内发生的缺陷类型和趋势进行合理分析，由点到面预估整体质量的健康状态，并能够对高频缺陷类型提供系统性的发现和预防措施，用来调整后续的测试策略
• 三个是依次递进的关系，越往后越能提醒按测试工程师的核心竞争力

6，自动化测试技术

• 可以从大量的重复性手工劳动中解放出来
• 自动化技术不需要绑定被测对象，也要有一定的代码能力
• 自动化测试的核心价值还是’测试本身’，自动化仅仅是手段

7，良好的沟通能力

• 一方面需要对接产品经理和项目经理，确保需求的正确实现和项目整体质量的达标
• 另一方面，要和开发人员不断沟通协调，确保缺陷及时修复与验证
• 良好清晰的沟通能力，是资深测试工程师/测试主管的核心竞争力

测试开发工程师的核心竞争力

• 代码开发能力是基本要求，合格的测试开发工程师一定可以一成为一个合格的开发工程师

1，测试系统需求分析能力

• 除了代码开发，更要具备测试系统需求分析能力，能站在测试架构师角度，识别测试基础架构的需求和提高i澳旅的应用场景(更像一个产品经理)

2，更宽广的知识体系

• 不仅要和传统的测试开发工程师打交道(是测试工具/平台的用户)，还要和CI/CD/运维，有密切联系，因为构建的测试工具/平台，需要介入CI/CD的流水线以及运维的监控系统中
• 还要了解更高级别的测试架构部署和生产架构部署，必须对开发采用的各种技术非常熟悉

非测试知识

• 除了专业知识外，还需要掌握更多的其他技术种类，只是技术深度不如开发工程师
• 开发工程师是深度遍历，关注的是点
• 测试工程师是广度遍历，关注的是面

网站架构的核心知识

• 如果要向做好功能测试以外的其他测试(性能测试、稳定性测试、全链路测试、故障切换(Failover)测试、动态集群容量伸缩测试、服务降级和安全渗透测试等)就要掌握网站的架构知识
• 如缓存系统测试知识：
  • 分布式缓存集群的应用场景和基本原理、缓存击穿、缓存雪崩、缓存预热、缓存集群扩容局限性等
• 如性能测试和全链路压测知识：
  • 网站的可伸缩性架构设计、应用服务器的各种负载均衡实现原理、数据库读写分离技术等

容器技术

• 优势：轻量化、资源占用、运行效率
• 通常开发交给测试的软件版本就是一个Docker Image，直接再容器上进行测试
• 有些公司还会把测试用例和执行框架打包成Docker Image，配合版本管理机制，实现用容器测试容器
• 目前支流的Selenium Grid已经提供了官方的Docker版本，可以直接使用容器测试执行环境，大大减轻了批量虚拟机节点上的web driver、浏览器版本和守护进程版本等升级维护的工作量
• 实现测试工具开箱即用
• 熟练掌握Docker和Kubernetes的原理和使用方法
• 学习资料：Docker官网教程

云计算技术

• 把生产环境从原本的集中式数据中心模式转向私有云或者混合云模式
• 理解服务在云端部署的技术细节
  • 测试基础服务也在逐渐走向云端(如：测试执行环境服务/测试数据准备服务)
  • 公有云服务：Sauce Labs
  • 私有云：典型就是Appium+Selenium Grid
• 理解掌握基本的云计算知识和技术

DevOps思维

• 强调的是，开发、测试、运维等组织团队之间，通过高效自动化工具的写作和沟通，完成软件的全生命周期管理，实现频繁的持续交付，提升业务的交付能力
• 具体表现形式可以是工具、方法和流水线，但是更深层次的内涵还是在思想方法，以敏捷和精益为核心，通过发现问题，以系统性的方法或者工具来解决问题，从而实现持续改进
• 深入理解DevOps西乡的核心和精髓。将各个工具有机结合，提供高效的CI/CD流水线
• 可以从Jenkins之类工具开始，到熟练应用和组合各种plugin来完成灵活高效的流水线搭建

前端开发技术

• 可以高效的做前端的测试，更容易发现缺陷，还可以自己构建测试页面，来完成各类前端组建的精细化测试，大大提高测试覆盖率和效率
• 首先掌握基本的Javascript，CSS，HTML5等知识，然后再学习一些主流的前端开发框架，如：VUE，Angular, Node等

建议

• 针对测试项目有针对性学习，对项目所永技术必须深入掌握
• 对于主流通用技术(容器、网站架构等)，可以业余时间学习，学习的程度取决于这个技术本身的特点，至少应该掌握基本概念和常规使用方法