测开学习笔记01（乱七八糟版）

测开学习笔记01（乱七八糟版）

在写笔记的时候发现虽然已经有了前端学习乱七八糟和技术学习乱七八糟，但是测试方向内容也很多很杂，小菜鸟于是又开了一个 新坑 学习计划。

24.4.16

1. 缺陷逃逸率

学习链接：浅谈测试缺陷逃逸的原因和改进措施 - 知乎 (zhihu.com)

定义

缺陷逃逸率是指软件产品发布后发现的缺陷数量与该软件产品在整个生命周期发现的所有缺陷数量的比率。缺陷逃逸也叫“测试逃逸”，缺陷逃逸率通常用来衡量软件开发团队与测试团队对软件质量控制的水平。

计算公式

（1）测试缺陷逃逸率的计算公式一般如下：缺陷逃逸率=考核周期发现的生产缺陷数/(测试阶段发现缺陷数+考核周期发现的生产缺陷数）×100%

注：缺陷逃逸率都是在产品上线后进行统计计算的，所以考核周期都是在系统（实施型项目）或变更（运维型项目）上线后的一段时间，考核频率和周期可以人为限定，如一个月一次、一个季度一次等。

（2）行业内比较普及的指标，缺陷逃逸率一般在7%~10%，算作一般，小于7%算优秀；大于10%就比较差了；当然，这个数值需要大家根据自己公司的实际情况来进行统计和分析，找到适合自己的区间。

原因分析

（1）造成缺陷逃逸的直接原因主要有两种：一种是测试人员设计测试用例不全面导致的遗漏，一种是测试用例设计到了，但是测试执行过程存在疏漏，导致一些显而易见的软件缺陷或本来应该发现的软件缺陷没有被测试出来。

（2）排除掉测试设计人员和执行人员的主观因素（偷懒、懈怠、重视程度不够等等），可能的客观原因有如下几种：

① 需求不够明确，导致测试人员对需求理解不到位，测试设计不够全面;（软件开发和测试最大的坑，往往就是需求的坑）

② 需求变更频繁，如在测试过程中发生需求变更，则容易导致测试人员获取到的需求不够及时、准确，测试案例不足以覆盖变更后的需求;

③ 测试计划安排不够合理，测试时间过于紧张，导致测试人员没有充足的时间设计用例和执行测试；

④ 测试设计人员对系统需求不够熟悉，或设计能力有限，案例覆盖度不够高；

⑤ 测试执行人员与设计人员不同，不能全面理解测试用例的测试要点；

⑥ 测试环境或版本与生产环境有差异，某些缺陷难以在测试环境被发现；

⑦ 某些特殊数据才会出现的缺陷，因测试数据不足而难以发现；

改进措施

① 测试尽早介入，在需求阶段就参与进来，加强需求的分析、确认和评审等工作，使测试人员可以充分理解需求以便设计准确而全面的测试用例；

② 控制需求变更的频次和时间，尤其是进入测试阶段后，尽量减少或避免需求变更，并再必要变更出现时加强信息的传达；

③ 合理安排测试计划，和开发计划，避免开发时间延后从而挤占测试时间，为测试保留相对合理的设计和执行时间；

④ 安排熟悉系统需求并掌握测试用例设计方法的人员设计测试用例，并加强对测试用例的评审；

⑤ 如测试执行人员与设计人员不同，可安排案例评审和讲解会，确保测试执行人员全面掌握测试要点；

⑥ 加强环境和版本管理，使测试环境尽量与生产环境一致；

⑦ 多使用存量和特殊数据进行测试，并适当进行破坏性测试，挖掘可能隐藏的问题；

2. 客户端质量保证手段

主要参考链接：阿里测试团队：如何建设软件质量保障体系 - tzmok - 博客园 (cnblogs.com)

移动客户端的质量包括功能和体验两方面，需要每一个参与项目的角色借助合格的开发流程进行维护，建立稳定并在执行中不断优化的质量保障体系。

文档管理

文档包括需求文档、设计文档、测试文档

测试文档从业务领域来说包括测试计划、测试用例、业务总结

（1）测试计划

描述测试活动的规划。重要的几个点是测试范围、测试策略、测试进度、准入准出标准、风险评估。

① 测试范围，内部需要细化到模块，外部是否有依赖方或被依赖方，需要提前告知对方，安排联调。

② 测试策略，人员的安排，每一阶段的测试活动，工具的使用、自动化、性能的介入。测试进度，需要固定的跟踪，如定期同步测试进度，告知风险。

③可提测的准入标准，测试后期是否符合上线条件的准出标准，业务人员的及时验收、反馈。风险评估，一般是时间规划不足，不能按时交付。

（2）测试用例

测试执行文档，不建议做迭代维护，可读性差，描述更多的是对业务细则的如何测试，包含边界值、有效等价类等测试方法，过于琐碎，不适合提炼维护。所以，我对测试用例的定义是，当前版本有效。

（3）业务总结文档

对当前系统业务的描述、汇总，通过该文档，可以一目了然当前系统的基础逻辑。更侧重于从业务逻辑角度描述系统，是测试人员的帮助文档，需要在每次迭代后及时更新，无需去翻看测试用例。熟悉、掌握系统核心业务，是测试人员的一项基础能力。

评审机制

信息的传递具有时效性，一份需求从产品->项目经理->研发团队->测试团队，如果测试团队在最后测试准备阶段接入，会丢失很多的信息。软件的生命周期如果用W模型来定义，那么每个阶段，测试的活动都是联动的。

所以，每个阶段的产出对应的评审是必不可少的：需求评审、开发设计评审、测试计划评审、测试用例评审。

准入、准出标准

（1）准入标准

即提测标准，为冒烟测试用例通过，验收人为测试人员，通过率可以酌情而定，比如超过70%的通过率则提测通过，否则打回。冒烟测试用例会维护并分享给开发人员，提测前，开发人员内部自测下，提高沟通效率。

（2）制定提测标准

目的是为了约束开发工作能按时交付，如果测试的周期为10天，开发提测质量较差，导致修复阻塞性问题花费了两三天，这样会影响版本按时上线。出于质量的考虑，项目会顺延上线，每个环节都是螺丝钉，环环相扣，不能顾此失彼。

（3）准出标准

即符合上线的标准，一般参考点有两个：测试报告、业务验收。例如通过率超过95%才能符合上线，遗留缺陷登记P3的数量，是否影响业务功能。业务验收，介入越早越好，可以分批验收。

（4）生产验证

一般是在发布后，使用测试账号在生产进行可测试性验证。生产的发布比较复杂，包括代码的发布、配置变更、DB变更、运维操作、网络层通信等，每个环节的疏忽或误操作，都会影响到本次发布。

重视回归测试

版本测试是为了保证当前版本需求的质量，而回归测试时保证整个系统业务的质量。

生产问题定期复盘

（1）问题复盘：包括潜在风险、已暴露问题。

（2）潜在风险：如排期过短、流程不规范等，需要提前介入，重新评估，避免风险在最后暴露。

（3）已暴露问题：一般为生产问题，需要做团队内部的复盘整理，参与方，包括产品、研发、测试。建议一个月至少一次，总结问题，进而完善质量保障体系。

生产监控、报警机制

版本发布成功以后，还需要监控新版本系统的运行健康情况。

具体操作包括灰度/放量，埋点等等

监控包括：数据库监控、应用服务监控、异常日志报警、数据量暴或暴减异常预警。

3. 黑盒测试与白盒测试

学习链接：软件测试中的黑盒与白盒测试 - 知乎 (zhihu.com)

黑盒测试

（1）定义

也称功能测试、数据驱动测试，它将被测软件看作一个打不开的黑盒，主要根据功能需求设计测试用例，进行测试。

因无法看到盒子中的内容，所以不知道软件是如何实现的，也不关心黑盒里面的结构，只关心软件的输入数据和输出结果。

（2）内容

• 检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏；
• 检测是否有人机交互错误，是否有数据结构和外部数据库访问错误，是否能恰当地接收数据并保持外部信息（如数据库或文件）等的完整性；
• 检测行为、性能等特性是否满足要求等； 检测程序初始化和终止方面的错误等。

（3）方法

等价类划分、边界值分析、因果图、决策表分析

① 等价类划分

完全不考虑程序的内部结构，只根据程序规格说明书对输入范围进行划分，把所有可能的输入数据，即程序输入域划分为若干个互不相交的子集，称为等价类，然后从每个等价类中选取少数具有代表性的数据作为测试用例，进行测试。

划分原则：区间、数值、数值集合、限制条件或规则、细分等价类

② 边界值分析

边界值和等价类密切相关，输入等价类和输出等价类的边界是要着重测试的边界情况。在等价类的划分过程中产生了许多等价类边界。边界是最容易出错的地方，所以，从等价类中选取测试数据时应该关注边界值。

在等价类划分基础上进行边界值分析测试的基本思想是，选取正好等于、刚刚大于或刚刚小于等价类边界的值作为测试数据，而不是选取等价类中的典型值或任意值做为测试数据。

对于一个n变量的程序，边界值分析测试会产生4n+1个测试用例。

③ 因果图

（1）确定软件规格中的原因和结果。分析规格说明中哪些是原因（即输入条件或输入条件的等价类），哪些是结果（即输出条件），并给每个原因和结果赋予一个标识符。

（2）确定原因和结果之间的逻辑关系。分析软件规格说明中的语义，找出原因与结果之间、原因与原因之间对应的关系，根据这些关系画出因果图。

（3）确定因果图中的各个约束。由于语法或环境的限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。

（4）把因果图转换为决策表。

（5）根据决策表设计测试用例。

④ 决策表分析

在所有的黑盒测试方法中，基于决策表的测试是最严格，最具有逻辑性的测试方法。

决策表是把作为条件的所有输入的各种组合值以及对应输出值都罗列出来而形成的表格。

它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。

步骤：

• 列出所有的条件桩和动作桩；
• 确定规则的个数；
• 填入条件项；
• 填入动作项，得到初始决策表。
• 简化决策表，合并相似规则。

对于n个条件的决策表，相应有2n个规则

决策表合并原则：即若表中有两条以上规则具有相同的动作，并且在条件项之间存在极为相似的关系，便可以合并。

白盒测试

（1）定义

也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能。

（2）内容

基本覆盖标准：逻辑驱动、循环、基路测试等，主要用于软件验证。

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。

（3）方法

语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖

4. 测试覆盖率

学习链接：为什么测试覆盖率如此重要 - 知乎 (zhihu.com)

定义

测试覆盖率被定义为一种测试技术指标，它表明我们的测试用例是否真正完全覆盖了应用程序代码中的各种可能以及在运行这些测试用例时执行了多少代码。

测试覆盖技术

语句覆盖、分支覆盖、路径覆盖、条件覆盖、边界值覆盖

测试覆盖率指标

代码级指标、功能测试指标、应用程序指标、测试覆盖率矩阵

5. Android 和 iOS的测试区别

学习链接：iOS测试和Android测试的区别_安卓和ios测试的区别-CSDN博客

系统与框架结构

（1）Android系统的底层建立在Linux系统之上；ios基于UNIX系统。
① 造成了Android与iOS的生态不同：Android完全开源，任何软件开发商或者个人都能开发安卓的软件；ios完全封源开发。

（2）Android的编程语言是Java和KotLin；而ios的则为ObjectC和Swift。

① 在根本上造成了iOS与Android性能不同：Android和Window一样，目的是打造一款通用性非常好的系统，在任何机器上面都可以运行；ios目的是让软件和硬件完美的结合到一块，该操作系统只能在极少数机器上面才能运行。

（3）运行机制：ios采用的是沙盒运行机制；安卓采用的是虚拟机运行机制

① iOS采用伪后台，当用户HOME键退出应用时，IOS其实关闭了程序，只保留应用的图像入口，只会默认将最后的运行数据记录在RAM中。

② 安卓手机的后台是真后台，将应用保留在RAM中，之所以能够收到推送，也因为它常驻内存。

③ 所以Android在软件关闭的情况下，无法接收推送信息；ios在软件关闭的情况下，依然可以接收推送信息

④ iOS系统在系统内存不足时会自动释放内存。

渲染机制

（1）iOS最先响应屏幕

① IOS的UI渲染采用实时优先级，Android的UI渲染遵循传统电脑模式的主线程普通优先级

② IOS的响应顺序依次为Touch–Media–Service–Core架构

③ Android系统的优先级响应层级是Application–Framework–Library–Kernal架构

测试

APP测试中，iOS测试和Android测试主要会针对以下几个点进行测试：

• 分辨率的测试：Android端有20多种，iOS相对少一点。
• 操作系统版本：Android的操作系统版本比较多，现在常见的是Android9和Android10，还有不同手机厂商的版本，比如小米的MIUI，魅族的Flyme；
  iOS的比较少，而且它只支持单向升级，不能支持降级。
• 操作习惯的不同：像Android，习惯的去点击back键，虽然现在很多都是全面屏，都是通过手势滑动返回，但还是属于back键的功能，所以Android需要测试back键是否被重写了，点击了back键系统的反馈是不是正常的。
• 推送消息的测试：Android点击home键后，程序运行到后台，那么这个时候，推送消息是否可以正常被推送，以及点击应用程序，唤醒到前台运行的时候，然后点击消息，是否可以正常的跳转；
  iOS点击Home键或是锁屏，或者是关闭程序的时候，消息推送是否是正常的。
• 安装和卸载测试：Android的安装的平台和渠道相对会比较多，而iOS的话一般只支持官方的渠道比如说 APP store 、 iTunes 工具以及 testflight 的下载

---

该笔记后续还会持续更新……