学习笔记（一）

2022-02-21

自动化应用框架：

通用框架：pytest unittest robotframework(web/app偏向)
接口自动化框架：httprunner(httprunnermanager)
selenium？？
java+testng+httpclient+selenium
python+unittest

自我简介：

python 看 django logu 的源码 会收益比较大
java 看 jdk springboot 的源码 会收益比较大

有趣的bug：
有意义的bug：
工作中遇到的问题：
印象最深刻的bug：下拉框全量查询

ETL 工具逻辑原理

不同的同步方式适用场景:

触发器：在源数据库建立增、删、改触发器，每当源数据库有数据变化，相应触发器就会激活，触发器会将变更的数据保存在一个临时表里

• 优点：能做到实时同步
• 缺点：降低业务系统性能，影响到业务系统，因为需要在业务系统建立触发器

日志：通过分析源数据库日志，来获得源数据库中的变化的数据

• 优点：基本不影响业务系统
• 缺点：有一定的延时，对于没有提供日志分析接口的数据源，开发的难度比较大

时间戳：在要同步的源表里有时间戳字段，每当数据发生变化，时间戳会记录发生变化的时间

• 优点：基本不影响业务系统
• 缺点：要求源表必须有时间戳这一列

数据比较：通过比较两边数据源数据，来完成数据同步。一般用于实时性要求不高的场景

• 优点：基本不影响业务系统
• 缺点：效率低

全表拷贝：定时清空目的数据源，将源数据源的数据全盘拷贝到目的数据源。一般用于数据量不大，实时性要求不高的场景

• 优点：基本不影响业务系统，开发、部署都很简单
• 缺点：效率低

测试分析：

一、测试需求分析的过程：

1.根据需求规格提取独立的功能点，确定测试范围；
2.对独立功能进行分析，确定各独立功能的测试点；
3.对业务场景即功能组合进行分析，提供业务场景的测试点；
4.对非功能特性进行分析，了解需要测试的非功能特性；
5.针对系统级接口进行分析，了解被测试对象、测试规格。分析可测性，确定测试方法、工具。

二、测试需求分析需要考虑的一些问题和细节：

问题：
1.已文档化的需求是否被正确实现；
2.是否存在遗漏需求；
3.是否存在画蛇添足的问题(实现了不存在于需求规格的需求)。
细节：
1.需求项与测试项关联、与测试用例关联（避免遗漏）；
2.区分出测试项的优先级（80/20法则）；（可以使用两次80/20法则，将优先级快速分为三个层次：5%、15%、80%）
3.针对可能存在的需求遗漏和疑似额外的实现，主动联系需求提出方，进行沟通并确认；
4.若需求项（测试项）可测试性差，及时反馈（涉及接口的，需要看到API，或接口文档）。

三、测试需求主要通过以下途径来收集：

　　1） 与待测软件相关的各种文档资料。如软件需求规格说明书、用户手册、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。
　　2） 与客户或系统分析员的沟通。
　　3） 业务背景资料。如待测软件业务领域的知识等。
　　4） 正式与非正式的培训。
　　5） 其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。

接口中的系统级别输入参数和应用级别输入参数指的是什么？

系统级别输入参数：
其中多个接口可以共用的一些参数，比如appid，appkey，version之列的，这些参数在这一套接口中都是必备的，甚至传到值很可能是一样的（也可以叫公共请求参数）
总结： 各个接口，大家都有的参数

应用级别输入参数：
当前这一个接口，由于业务需要，传入的参数的名称和值都是本接口需要的，一般不会和其它接口相同或者共用
总结： 当前接口业务需要的参数

公共响应参数：
响应参数，调用接口时，接口返回的数据，这些数据就是响应数据，里面的字段就是响应参数
所有接口返回都带的内容一致的参数

什么是API，具体是什么意思？

可以把SDK想象成一个虚拟的程序包，在这个程序包中有一份做好的软件功能，这份程序包几乎是全封闭的，只有一个小小的接口可以连通外界，这个接口就是API
比如：我们现在要在企业erp系统中增加某个功能（比如自动备份、数据分析、云存储等），但又不想耗费大量时间、也没那么多研发亲自去做这个功能，这是我们可以选择使用这个“SDK”软件吧，把erp系统连接上API接口，就可以使用SDK软件包里的功能
贴近生活讲讲两者的关系：
有一杯蜜蜂饮料，它的名字叫做“SDK"
饮料上插着吸管，吸管的名字就叫“API"
所以：
SDK=放着你想要的软件功能的软件包
API=SDK上唯一的接口
前端事件：
前端事件是一种全新的数据获取的方式，可以在数据提交或者表单填报时，主动调用外部接口，从而可以实现接口取数、数据验证、数据分析、触发时间等一系列的操作，用户可以基于现成的商业接口进行配置（无需编程），也可以根据自身需求封装接口，灵活的满足自身业务需求（需编程）

分布式架构和微服务架构的区别？？

1.分布式
将一个大的系统划分为多个业务模块，业务模块分别部署到不同的机器上，各个业务模块之间通过接口进行数据交互。区别分布式的方式是根据不同机器不同业务。
注：分布式需要做好事务管理。
2.微服务：
微服务的设计是为了不因为某个模块的升级和BUG影响现有的系统业务。微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器

1. 微服务的诞生
   微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
   每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建

2. 微服务架构与SOA架构的区别
   微服务是真正的分布式的、去中心化的。把所有的“思考”逻辑包括路由、消息解析等放在服务内部，去掉一个大一统的 ESB，服务间轻通信，是比 SOA 更彻底的拆分。
   微服务架构强调的重点是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发，设计，运行和运维的小应用，这些小应用之间通过服务完成交互和集成。

3. 微服务架构引发的问题
   随着整个业务数据被分散在各个子服务之后，也带来了两个最明显的问题。
   业务管理系统对数据完整性查询，比如分页查询、多条件查询等，数据被割裂后如何来整合?
   数据分析挖掘，这些需求可能需要分析全量的数据，并且在分析时不能影响到当前业务
   从技术方案来讲，我们一般有两种选择来处理这些问题，第一种是在线处理数据，第二种是离线处理数据。

在线处理数据的方案：通过微服务提供的接口来获取数据，然后进行数据整合，不过这种方式有着明显的弊端，就是调用者需要编写大量的代码进行数据处理。其次在对各个微服务进行调取数据时会影响微服务的正常业务处理性能

离线处理数据方案：将业务数据准实时的同步到另外一个数据库中，在同步的过程中进行数据整合处理，以满足业务方对数据的需求，数据同步过来后，再提供另外一个服务接口专业负责对外输出数据信息，这种方案有两个特点：①数据同步方案是关键，技术选型有很多，如何选择切合公司业务的技术方案；②离线数据处理对微服务正常业务处理没有影响。
推荐使用第二种，利用 Spring Boot 和 MongoDB 可以轻松的解决这个问题，通过技术手段将分裂到 N 个微服务的数据同步到 MongoDB 集群中，在同步的过程中进行数据清洗，来满足公司的各项业务需求

在微服务架构中，有 大难题，那就是 服务故障的传播性 、 服务的划分 和 分布式事务 。
分布式和微服的架构很相似，只是部署的方式不一样而已
微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互，所以分布式也属于微服务
微服务特点：
按照业务划分服务，单个服务代码量小，业务单一，易于维护每个微服务都有自己独立的基础组件，例如数据库、缓存等且运行在独立的进程中微服务之间的通信是通过HTTP协议或者消息组件，且具有容错能力微服务有一套服务治理的解决方案，服务之间不耦合，可以随时加入和剔除单个微服务能够集群化部署，并且有负责 均衡的能力整个微服务系统应该有完整的安全机制，包括用户验证，权限验证，资源保护整个微服务系统有链路追踪的能力有一套完整的实时日志系统

测试分析与测试用例设计方法：

测试分析方法：
1.质量模型分析法
针对每个功能使用软件质量模型进行分析，分析盈测特性，确认功能的测试点及测试项软件内部质量（中间产品的静态测量）外部质量（测试其外部属性，即代码执行时的行为）软件系统作为完整的整体运行时所表现出来的各方面的质量特征（ST测试）使用质量（软件产品的使用）最终用户在其真实环境中运行软件系统时，所感受到的软甲各方面特性与其目标的符合程度（验收测试、α、β测试）
α测试（内测）：
就是把用户请到公司内部进行测试使用。
α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试；

目的：是评价软件产品的FLURPS(即功能、局域化、可使用性、可靠性、性能和支持)。
注意！α测试不能由程序员或测试员完成。

β测试（公测）：
用户在不同场所进行测试。
β测试是一种验收测试。β测试由软件的终用户们在一个或多个场所进行。

区别：
它们都是验收测试！
α测试是指把用户请到开发方的场所来测试
β测试是指在一个或多个用户的场所进行的测试。

α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。
β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。

α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长外部质量和内部质量分别有6个特性：
一、功能性
1.适合性
2.准确性
3.互操作性
4.保密安全性
5.功能性的依从性

二.可靠性
1.成熟性：软件产品为避免因软件故障而导致失效的能力
2.容错性：软件产品在软件发生故障或者违反指定接口的情况下，维持规定的性能级别的能力
3.可恢复性：软件产品在失效发生的情况下，重建规定的性能级别并恢复直接影响的数据的能力

三.易用性
1.易理解
2.易操作
3.易学习
4.吸引性
5.易用性的依从性

四.效率
1.时间特性
2.资源利用率
3.效率依从性

五.可维护性
1.易分析性
2.易改变性
3.稳定性
4.可测试性
5.可维护性的依从性

六.可移植性
1.适应性
2.易安装性
3.共存性
4.易替换性
5.依从性

测试在具体分析测试的时候，是有特定的方法的。常见的可以从以下几点分析:

1、从业务角度进行分析:通过业务流程，业务数据，业务操作等分析，明确要验证的功能，数据，场景等内容，从而确定业务方面的测试要求来确定我们分析的范围的广度。

2、从技术角度分析:通过研究系统架构设计，数据库设计，代码实现等，分析其技术特点，了解设计和实现要求，包括系统的稳定可靠，分层处理，接口集成，数据结构，性能等方面的测试要求。

其实从上面两点就可以看出来软件开发的两个重要的影响软件质量的因子。一个是需求，因为那是业务的源头，那就是开发设计的源头，也是测试设计和分析的源头。另一个就是开发的相关设计，那是影响需求实现效果的最关键的环节，当然如果按照测试左移的思想，也会衍生出来很多的测试流，比如说单元测试TDD(零缺陷质量思想)，BDD等较为先进的测试思想和测试实践

非功能测试类型汇总：
魅力属性
产品有多吸引人？
审美性的特性
可靠性
产品工作有多安全可靠？
健壮性、异常处理、数据完整性

易用性
产品有多容易使用？
易学、易操作、易获得

安全性
产品抵御非法入侵的能力有多强？
鉴权、授权、保密性、安全漏洞
可规模化属性（可维护性、可移植性）
产品是否能规模化部署？

性能
产品运行多块、资源利用率多好？

安装性
产品是否易安装？
安装、卸载、升级、配置

兼容性
产品与外部组件或系统是否兼容

2.功能交互分析法
针对不同的功能确认各功能之间的交互操作，分析各功能交互时的测试特性，测试注意点，确认测试项；

3.用户场景分析法
针对所有功能，站在用户的角度考虑用户会怎么操作和使用这个功能，分析确认测试点以及测试项；
质量分析风险：

黑盒测试用例设计方法：

1.等价类划分
　　等价类划分是将系统的输入域划分为若干部分，然后从每个部分选取少量代表性数据进行测试。等价类可以划分为有效等价类和无效等价类，设计测试用例的时候要考虑这两种等价类。

2.边界值分析法
　　边界值分析法是对等价类划分的一种补充，因为大多数错误都在输入输出的边界上。边界值分析就是假定大多数错误出现在输入条件的边界上，如果边界附件取值不会导致程序出错，那么其他取值出错的可能性也就很小。
　　边界值分析法是通过优先选择不同等价类间的边界值覆盖有效等价类和无效等价类来更有效的进行测试，因此该方法要和等价类划分法结合使用。

3.正交试验法
　　正交是从大量的试验点中挑选出适量的、有代表性的点。正交试验设计是研究多因素多水平的一种设计方法，他是一种基于正交表的高效率、快速、经济的试验设计方法。

4.状态迁移法
　　状态迁移法是对一个状态在给定的条件内能够产生需要的状态变化，有没有出现不可达的状态和非法的状态，状态迁移法是设计足够的用例达到对系统状态的覆盖、状态、条件组合、状态迁移路径的覆盖。

5.流程分析法
　　流程分析法主要针对测试场景类型属于流程测试场景的测试项下的测试子项进行设计，这是从白盒测试中路径覆盖分析法借鉴过来的一种很重要的方法。

6.输入域测试法
　　输入域测试法是针对输入会有各种各样的输入值的一个测试，他主要考虑?极端测试、中间范围测试，特殊值测试 。

7.输出域分析法
　　输出域分析法是对输出域进行等价类和边界值分析，确定是要覆盖的输出域样点，反推得到应该输入的输入值，从而构造出测试用例，他的目的是为了达到输出域的等价类和边界值覆盖。

8.判定表分析法
　　判定表是分析和表达多种输入条件下系统执行不同动作的工具，他可以把复杂的逻辑关系和多种条件组合的情况表达的即具体又明确

9.因果图法
　　因果图是用于描述系统输入输出之间的因果关系、约束关系。因果图的绘制过程是对被测系统的外部特征的建模过程，根据输入输出间的因果图可以得到判定表，从而规划出测试用例。

10.错误猜测法
　　错误猜测法主要是针对系统对于错误操作时对于操作的处理法的猜测法，从而设计测试用例

11.异常分析法
　　异常分析法是针对系统有可能存在的异常操作，软硬件缺陷引起的故障进行分析，分析发生错误时系统对于错误的处理能力和恢复能力依此设计测试用例。

白盒测试方法：

白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，白盒指的是程序的内部结构和运作机制是可见的。

白盒测试的目的：
　　通过检查软件内部的逻辑结构，对软件中的逻辑路径进行覆盖测试；在程序不同地方设置检查点，检查程序的状态，以确定实际运行状态与预期状态是否一致。

白盒测试的方法：
大致分为静态方法和动态方法两大类。
A. 静态分析：
　　是一种不执行程序而进行测试的技术。静态分析的主要目的是检查软件的表示和描述是否一致,没有冲突或者没有歧义。
B. 动态分析：
　　当软件系统在模拟或真实的环境中执行前、过程中和执行后,对其行为分析。它显示了一个系统在检查状态下是否正确。在动态分析技术中,最重要的技术是路径和分支测试。下面要介绍的六种覆盖测试方法属于动态分析方法。
（1）语句覆盖
使程序中的每个可执行语句都能执行一次的测试用例
（2）判定覆盖（分支覆盖）
对于判断语句，在设计用例的时候，要设计判断语句结果为True和False的两种情况
（3）条件覆盖
设计用例时针对判断语句里面每个条件表达式true 和 false各取值一次，不考判断语句的计算结果
（4）判定条件覆盖（分支条件覆盖）
设计测试用例时，使得判断语句中每个条件表达式的所有可能结果至少出现一次，每个判断语句本身所有可能结果也至少出现一次。
（5）条件组合覆盖
设计测试用例时，使得每个判断语句中条件结果的所有可能组合至少出现一次
（6）路径覆盖
设计测试用例时，覆盖程序中所有可能的执行路径
优点：这种覆盖方法可以对程序进行彻底的测试用例覆盖，比前面讲的五种方法覆盖度都要高。
缺点：于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。路径覆盖虽然是一种比较强的覆盖，但未必考虑判断语句中条件表达式结果的组合，并不能代替条件覆盖和条件组合覆盖。

什么样的用例是好的用例

　　测试用例并没有好坏之分，只要能测出 Bug的用例都是好用例。但是能用较少的用例发现较多的缺陷的用例肯定是优质的。
　　个人觉得一个优质的用例应该具备以下几点：
　　1.测试用例覆盖程度广；
　　2.测试用例达到工作量最小化；
　　3.测试用例的分类以及描述清晰易懂；
　　4.测试用例明确指出测试的目的；
　　5.测试用例易于维护；
　　以上只是自己对于测试用例这块的理解，其实每个公司对于测试定位以及测试用例的设计、维护、执行都是有区别的，根据自己的实际情况，选择适合自己的才是最重要的！

Android、ios、Windows、Mac、web、Linux平台的基础特性：
WEB平台：
Web（World Wide Web）即全球广域网，也称为万维网，它是一种基于超文本和HTTP的、全球性的、动态交互的、跨平台的分布式图形信息系统。是建立在Internet上的一种网络服务，为浏览者在Internet上查找和浏览信息提供了图形化的、易于访问的直观界面，其中的文档及超级链接将Internet上的信息节点组织成一个互为关联的网状结构。

Servlet（Server Applet）是Java Servlet的简称，Java编写的服务器端程序。其主要功能在于交互式地浏览和修改数据，生成动态Web内容。
Servlet的工作模式：
客户端发送请求至服务器
服务器启动并调用Servlet，Servlet根据客户端请求生成响应内容并将其传给服务器
服务器将响应返回客户端
Servlet 的工作原理：
Servlet接口定义了Servlet与servlet容器之间的契约：
Servlet容器将Servlet类载入内存，并产生Servlet实例和调用它具体的方法。
在一个应用程序中，每种Servlet类型只能有一个实例。

ServletRequest对象和ServletResponse对象：
ServletRequest对象和ServletResponse对象都是由Servlet容器（例如TomCat）封装好的，并不需要程序员去实现，程序员可以直接使用这两个对象。

ServletContext对象：
这个对象中封装了上下文（应用程序）的环境详情，可以共享应用程序的信息。每个应用程序只有一个ServletContext。

ServletConfig对象：
配置信息
HTTP协议1.1版本中的状态码可以分为五大类，如下所示：
状态码范围 作用描述
100-199 用于指定客户端响应的某些动作。
200-299 用于表示请求成功。
300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。
400-499 用于指定客户端的错误。
500-599 用于指出服务器错误。

生产场景常见的重要状态码及对应的作用整理为如下：
状态代码 详细描述说明
200 – ok ß服务器成功返回网页，这是成功的http请求，返回的标准状态码。
301 – Moved Permanently ß永久跳转，所有请求的网页将永久跳转到被设定新的位置，例如：从xuliangwei.com跳转到www.xuliangwei.com
403 – Forbidden ß禁止访问，这个请求是合法的，但是服务器端因为匹配了预先设置的规则而拒绝响应客户端的请求，此类问题一般为服务器权限配置不当或者没有默认主页所导致
404 – Not Found ß服务器找不到客户端请求的指定页面，可能是客户端请求了服务器不存在的资源导致。
500 – Inter Server Error ß内部服务器错误，服务器遇到了意料不到的情况，不能完成客户的请求，这是一个较为笼统的报错，一般为服务器的设置或者内部程序问题导致。例如：selinux开启，而又没有为http设置规则许可，客户访问就是500
502 – Bad Gateway ß坏得网关，一般是代理服务器请求后端服务时,后端服务不可用或者没有完成响应网关服务器，一般为代理服务器下面的节点出问题导致。
503 – Service Unavailable ß服务当前不可用，可能因为服务器超载或停机维护导致，或者是代理服务器后面没有可以提供服务的节点。
504 – Gateway Timeout ß网关超时，一般是网关代理服务器请求后端服务器时候,后端服务没有在特定的时间内完成处理请求，一般是服务器过载导致没有在指定的时间内返回数据给代理服务器

Linux平台：
Linux的基本思想有两点：
第一，一切都是文件；
第二，每个软件都有确定的用途。其中第一条详细来讲就是系统中的所有都归结为一个文件，包括命令、硬件和软件设备、操作系统、进程等等对于操作系统内核而言，都被视为拥有各自特性或类型的文件

Linux支持多用户，各个用户对于自己的文件设备有自己特殊的权利，保证了各用户之间互不影响。多任务则是现在电脑最主要的一个特点，Linux可以使多个程序同时并独立地运行。

敏捷开发：
敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。
DevOps（开发运维一体化）:
DevOps 是 Development 和 Operations 的合成词，其目标是要加强开发人员、测试人员、运维人员之间的沟通协调。如何实现这一目标呢？需要我们的项目做到持续集成、持续交付、持续部署。

时下流行的 Jenkins、Bamboo，就是两款优秀的持续集成工具。而 Docker 容器则为 DevOps 提供了强大而有效的统一环境。

CI、CD：
最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。
持续集成：的重点是将各个开发人员的工作集合到一个代码仓库中。通常，每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。
通过持续集成，开发人员能够频繁将其代码集成到公共代码仓库的主分支中。开开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。
这里的一个重要想法是让开发人员更快，更频繁地做到这一点，从而降低集成成本
持续交付：的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。
实际上是 CI 的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。CD 集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。此流水线是一个自动化系统，可以针对构建执行一组渐进的测试套件。CD 具有高度的自动化，并且在一些云计算环境中也易于配置。在流水线的每个阶段，如果构建无法通过关键测试会向团队发出警报。否则，将继续进入下一个测试，并在连续通过测试后自动进入下一个阶段。流水线的最后一个部分会将构建部署到和生产环境等效的环境中。这是一个整体的过程，因为构建、部署和环境都是一起执行和测试的，它能让构建在实际的生产环境可部署和可验证。
持续部署：是一种更高程度的自动化，无论何时对代码进行重大更改，都会自动进行构建/部署。
持续部署扩展了持续交付，以便软件构建，在通过所有测试时自动部署。在这样的流程中，不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容。
采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速处理任何明显的缺陷。用户对无用或者误解需求的功能的快速反馈有助于团队规划投入，避免将精力集中于不容易产生回报的地方。随着 DevOps 的发展，新的用来实现 CI/CD 流水线的自动化工具也在不断涌现。这些工具通常能与各种开发工具配合，包括像 GitHub 这样的代码仓库和 Jira 这样的 bug 跟踪工具。此外，随着 SaaS 这种交付方式变得更受欢迎，许多工具都可以在现代开发人员运行应用程序的云环境中运行，例如 GCP 和 AWS。最受欢迎的自动化工具是 Jenkins（以前的 Hudson），这是一个由数百名贡献者和商业公司 Cloudbees 支持的开源项目。

使用python进行测试工具开发：

自动化测试框架：
Robot Framework
Robot Framework 是为测试人员提供了的成熟解决方案;它使用驱动的方法来使测试可读和易于创建。它还有许多测试库和其他可以使用的工具。
Selenium WebDriver库可能是最常用的外部测试库，但Robot Framework可以测试FTP，MongoDB，Android，Appium等网站以外的其他内容。除了所有这些开放源代码的美妙之处以外，它还有很多API可以帮助它尽可能的扩展。

python数据类型：
不可变数据：
数字
字符串
元组：与列表很像，元组一旦初始化则不可修改
可变数据：
列表：有序的集合（索引），可以随时添加和删除其中的元素
字典：字典是另一种可变容器模型，且可存储任意类型对象，如字符串、数字、元组等其他容器模型
集合：无序不重复元素的序列

八大数据结构分类：
1.数组
数组是可以再内存中连续存储多个元素的结构，在内存中的分配也是连续的，数组中的元素通过数组下标进行访问，数组下标从0开始。
优点：
1、按照索引查询元素速度快
2、按照索引遍历数组方便
缺点：
1、数组的大小固定后就无法扩容了
2、数组只能存储一种类型的数据
3、添加，删除的操作慢，因为要移动其他的元素。
适用场景：
频繁查询，对存储空间要求不大，很少增加和删除的情况。
2.栈
栈是一种特殊的线性表，仅能在线性表的一端操作，栈顶允许操作，栈底不允许操作。 栈的特点是：先进后出，或者说是后进先出，从栈顶放入元素的操作叫入栈，取出元素叫出栈。
适用场景：
栈常应用于实现递归功能方面的场景
3.队列
队列与栈一样，也是一种线性表，不同的是，队列可以在一端添加元素，在另一端取出元素，也就是：先进先出。从一端放入元素的操作称为入队，取出元素为出队
适用场景：因为队列先进先出的特点，在多线程阻塞队列管理中非常适用
4.链表
链表是物理存储单元上非连续的、非顺序的存储结构，数据元素的逻辑顺序是通过链表的指针地址实现，每个元素包含两个结点，一个是存储元素的数据域 (内存空间)，另一个是指向下一个结点地址的指针域。根据指针的指向，链表能形成不同的结构，例如单链表，双向链表，循环链表等。
链表的优点：
链表是很常用的一种数据结构，不需要初始化容量，可以任意加减元素；
添加或者删除元素时只需要改变前后两个元素结点的指针域指向地址即可，所以添加，删除很快
缺点：
因为含有大量的指针域，占用空间较大；
查找元素需要遍历链表来查找，非常耗时。
适用场景：
数据量较小，需要频繁增加，删除操作的场景
5.树
树是一种数据结构，它是由n（n>=1）个有限节点组成一个具有层次关系的集合。把它叫做 “树” 是因为它看起来像一棵倒挂的树，也就是说它是根朝上，而叶朝下的。
它具有以下的特点：
每个节点有零个或多个子节点；
没有父节点的节点称为根节点；
每一个非根节点有且只有一个父节点；
除了根节点外，每个子节点可以分为多个不相交的子树；
在日常的应用中，我们讨论和用的更多的是树的其中一种结构，就是二叉树。
6.散列表
散列表，也叫哈希表，是根据关键码和值 (key和value) 直接进行访问的数据结构，通过key和value来映射到集合中的一个位置，这样就可以很快找到集合中的对应元素。
7.堆
堆是一种比较特殊的数据结构，可以被看做一棵树的数组对象，具有以下的性质：
堆中某个节点的值总是不大于或不小于其父节点的值；
堆总是一棵完全二叉树。
将根节点最大的堆叫做最大堆或大根堆，根节点最小的堆叫做最小堆或小根堆。常见的堆有二叉堆、斐波那契堆等
堆的定义如下：n个元素的序列{k1,k2,ki,…,kn}当且仅当满足下关系时，称之为堆。
(ki <= k2i,ki <= k2i+1)或者(ki >= k2i,ki >= k2i+1), (i = 1,2,3,4…n/2)，满足前者的表达式的成为小顶堆，满足后者表达式的为大顶堆，这两者的结构图可以用完全二叉树排列出来
因为堆有序的特点，一般用来做数组中的排序，称为堆排序。
8.图

Linux常用命令：

TCO:
TCO 即Testing Coverage Outline
TCO测试覆盖大纲，就是从测试的角度定义需求的过程，以便所有人都明了针对当前被测系统有哪些测试需求、测试要点。

一.为什么需要TCO:
在日常的工作交流（需求、方案、实现）或是在做KYM的时候，我们面临着大量的碎片化信息需要梳理。我们需要将碎片化的信息进行提炼、重组和结构化，这就是TCO的过程。（一个好的结构化的TCO也应该便于日后原始信息的还原。）在这样过程中我们就能够对被测系统、测试点做到心中有数。

二.做TCO的形式和内容：
形式上，目前用的比较多的是思维导图（脑图）,也可以是其他任何便于交流和理解的方式。
内容根据项目的上下文特点可能会有一些差异：

TCO的用途：
TCO可以帮助达成3个目的：信息提炼、信息重组、心中有数。
内容重组包含两层意思：对信息源中提取的信息进行重新组织，以及对于信息源中没有的信息的添加。
TCO可以帮助我们快速地提取那些关键的信息，从而加快学习了解被测对象的时间。
TCO是开展预防性测试很好的一个手段。
Curation and Subtraction Heuristic（过滤与剔除启发式方法）包含两层意思：提取有价值的信息以及信息的结构化整理。
信息提取和信息重组均不是一次性的工作，这个过程需要反复地进行。
可以用“SFDIPOT Heuristic”画TCO。
可以用MFQ的思路画TCO。
TCO准备阶段，可以画TCO草稿图以及开展头脑风暴得出更多的test ideas.
使用“逻辑听力”对信息提炼和重组，识别横向逻辑和纵向逻辑。
用逻辑听力理解发言，用概括归纳选择取舍。
MFQ的三维视角是一个通用的思路，适合于各个业务领域。
M和F的概念是相对的。
管理者或者每个测试人员都可以基于MFQ的划分结果进行测试管理。

画TCO的方法：
方法1 SFDIPOT画TCO：
需要快速地得到一些test ideas时，用“SFDIPOT Heuristic”画TCO
Structure(结构)产品是有什么组成的？
Function（功能）产品是做什么的？
Data（数据）产品处理什么数据？
Interface（接口）产品与外部有哪些接口？
Platform（平台）产品所依赖的东西？
Operation（操作）产品是怎样呗使用的？
Time（时间）产品与时间相关的任何方面？

方法1 MFQ画TCO：
想对被测对象进行深入地、系统地分析的话，用MFQ的思路画TCO，一级节点有识别出的M(单功能)、F(功能交互)、Q(质量属性)、bugs、issues、risks(风险)、questions(问题)等
针对不同产品，针对每一个非功能的质量属性，其测试方法可能差别非常大，实际上每一个Q均属于专项的测试领域，有专门的测试技能，一个人需要在这个领域沉淀多年才有积累。我自问在这些专项测试领域的积累实在过于匮乏，所以，关于Q的部分本书也不做过多介绍了，而是把笔墨集中在M单功能的测试分析与测试设计上。