第一阶段：API自动化
之前的想法是：通过API创建数据，访问数据，进行数据操作，存储数据库，通过模拟前端的操作来想象API的访问流程。
然后，验证数据库是否存储正确。后来发现该想法流程就是错误的。
问题：
- 模拟前端的操作需要对每个前端操作后调用的API非常熟悉，这已经超过了测试的范围，属于开发的范畴。
- 每个API的集成测试应该是独立的，有顺序的对API的测试使得API之间存在相互依赖的关系。然而每个API的正确性并不能保证。
- API本身是具有很强的独立性，不应该通过前端模拟操作来对其进行相对的验证，操作逻辑应该由前端负责。
总结：
- 使得API具有健壮性，对正常的数据传输和异常的数据传输，服务器端都能正确的响应和返回正确的响应码。
- 对于API的集成，务必使得每个API都独立验证，不能具有相互依赖性。
- API的正确性为前端逻辑的自动化验证提供了稳定的基础。
工具可使用：unittest，pytest(推荐)
第二阶段：自动创建测试数据
前端的一些UI验证，需要一些组合数据，每次更新环境，版本迭代，自动化创建需要的数据。
此时需要依据测试用例(UI显示部分)来保证每种情况，包括边界，越界情况的显示正常。此些数据在每次新环境都需要验证的情况下，手动创建太过于浪费时间，通过Python读取excel预先设计好的，通过API或者直接写入数据库的方式自动化创建批量的数据。写入的方式通过具体的业务来选择。
第三阶段：前端操作自动化
第二阶段和第三阶段的顺序不太重要，也可以先执行第三阶段。
这里的前端操作自动化，通俗的讲是对前端控件响应的一些自动化验证，属于基础的前端测试。如文本的输入，按钮点击响应，表单提交后的正常显示等。
依据就是需求文档，覆盖需求文档的一些基本的点就可以。不需要太多的复杂的流程和操作。
工具使用appium。
第四阶段：用户实操自动化
用户实操依据是使用该软件的过程中，用户操作的真实场景，为最后的收尾自动化测试。
如用户可能在使用的过程中，停留在该页面10分钟，然后锁屏，然后解锁，查看该APP是否还在生存中。
如用户可能在使用的过程中，是程序退入后台。这里的具体操作需要了解不同的平台对程序生命周期的定义阶段不同。
前端自动化和接口自动化
之前一直在思考前端自动化和接口自动化分别侧重点是什么。
前端自动化侧重点在于组建的响应，数据显示(包括长度,小数正确取位等),后端侧重在于数据处理的正确性验证。
之前主要通过Appium检验前端的各个按钮响应是否都正确，某个元素是否显示出来了，忽略了一个动作操作完后对其他界面数据显示的影响检测。其实前端和后端的自动化侧重点不同，但是对于数据的检测可以是双重检测。这样测试完后的数据更有保障。
关于数据准备和数据删除
数据生成(准备)与测试放在分开的模块中，混到一起，容易中断测试代码。
先数据生成测试需要的数据然后再运行测试代码。
pyqt-> flask
1016.12.9更新
最近又把pyqt的测试平台折腾回了flask的网页版平台。然后接下来在数据准备时遇到了纠结点：
- 自动创建测试数据逻辑放在每个test_case中，每次跑该case重新创建新的
- 用自动化平台提前创建好数据，并写入到excel或者数据库，然后在test_case中读取静态数据来使用(后来想想读取这个步骤也是test以外的逻辑)
今天和xbo还有jl讨论了。测试的代码和自动创建数据的结构是不相同的，，这里是两套，所以想的是两种最好不要糅合到一起去。
第1种
好处：避免每次手动去复制粘贴一部分数据(自动后台创建好，手工复制到excel)，其实手工部分复制的很少。
坏处：在test_case因为会跑很多次，如自己测试测试代码的时候，以及测试不通过开发多次修改后，都会跑很多次，造成大量的垃圾数据，会很快冲掉他人的数据，导致他人使用不方便。
给的建议：每次setup的时候创建当前的测试所需要的数据，scope为function，执行完后删除，该建议有个难度，因为测试时也有其他人在用该环境，导致不能全部清空数据库，你必须知道该接口影响到了哪些表的哪些字段，再去操作数据库恢复，这个量很大。
第2种，在测试平台上创建所有需要使用的数据创建好，保存到excel或者数据库中，在跑case的时候，直接读取这些静态数据。
好处：和test_case逻辑分离，少量的数据生成，不用删除数据，操作逻辑相对清楚。
坏处：有的数据会重复使用在多个test case中，也未达到完全自动化。
个人倾向第二种。
分享会之数据准备
2016.12.19更新
带着以上疑问，去参加了一个测试的分享会。
基本上所有人呢在数据准备和后期数据删除时都遇到过相同的困难。
数据准备：
- 直接拷贝线上的数据，过滤敏感信息后做为测试数据。问题：新模块无数据，用真实数据感觉对数据保护不好。
- 用创建数据的接口创建数据。问题：不是所有的公司都提供了改接口。
- 写sql语句生成数据。问题：需对功能涉及到的数据表很熟悉，维护复杂，工作量也大，无人来保证写的sql语句正确。
依据当前已有的条件，第2种最符合。
数据删除：
- 每个test case执行后清空所有的数据表。问题：影响其他同时在测试或者使用该环境的人。
- 依据生成的数据，删除关联表的关联字段。问题：需对功能关联的表很清楚，也无保证sql语句正确。
- 在本地计算机做一个服务和数据库的镜像，每次执行后清空本地的数据。问题：每个人都需要做一个镜像，且不能完全测到真实环境数据，维护也复杂。
- 让开发提供put，post的delete接口。
第4种方法是最好的，虽然需要协商，但是数据表的变化会同时更新给delete接口，不需要去维护。
接口自动化和UI自动化
接口自动化验证数据逻辑正确性。
UI自动化验证业务逻辑自动化。
如果接口已经将逻辑基本覆盖完成，UI自动化就应该避免这部分的验证，而只是从用户角度去验证业务上的逻辑。
注:UI上面也可以验证数据的逻辑性，但是由于UI响应很慢，且其关键点不应该放在UI上面，测试应该按照金字塔原则去分配时间。
使用flask写测试小工具
2017.1.9更新
使用flask和bootstrap提供自动化创建数据的方式，打算放弃。
每次直接运行python能快速创建，为了能给开发使用每次新功能都需要写新的界面，比较耗时间。
采用excel同一类测试数据创建一次，找个文本的地方标注该数据的使用目的，如果有问题，该数据也可供开始后期调试使用。
每次创建的原始数据，保存，每次回归或者需要重新测试的时候，一键创建。
关于数据准备与清楚
2017.3.1更新
测试环境都是很干净的环境，迭代版本时需要全部都清空数据，从头开始(兼容老数据另说，一般在兼容性测试时，导入线上大量数据来测试)。
清空数据，现阶段的方法是通过，python脚本删除所有的数据表。数据表变更，所有的python代码需要跟上，为了清空数据库维护一份删除全数据的脚本，麻烦，不节能。
改进步骤1：手动删除整个数据库->跑创建数据库数据表的脚本->修改和创建必须要的初始化数据。
改进步骤2：写shell脚本，集成删除库与创建表以及创建必要数据
改进步骤3：发现在测试app端显示和其他手动测试时，需要大量不同的测试数据，这些数据通常是通过手动创建的，而测试的主要点未在创建的功能上面。此时可以将所有创建数据功能和所有创建涉及到的post接口集成到一起测试。通过创建接口来创建所有后期api测试需要的数据和前端测试需要的数据。
该步骤在初始化的时候做4件事情：
- 删除数据库
- 自动创建所有数据表
- 初始化运行程序的基本数据
- 测试所有创建数据的(一般为post方法)接口，同时创建所有测试所用数据
自动化总结
2017.6.22更新
测试行业的发展会向更专业，细分类的方向发展，UI的自动化需要结合业务来取舍，如多数是用的模板创建的相似的项目，适合使用UI自动化。单一的项目最好是结合实际情况，对某个控件，某个流程，某个业务场景，某个页面等，单独提出来做UI自动化，而不是所有的逻辑都依赖自动化，一些检测如果肉眼更快，则不选择UI自动化，如，检测一个元素是否在界面上.....。
自动化也是依照测试用例进行的，所以，切记花太多时间在UI自动化爬坑上面。有多于的时间提高变成技术，如测试需要的各种小工具。
以后的测试会更靠近开发的技能，所以前后端的技术都需要跟上才是。
当然，所有的选择都要根据目前公司的产品和结构来定。
数据从excel到mysql
通过模块分表，表数量已经增长到十几个，表之间通过excel的行数来链接起来，这样的坏处是，如果在某张表中间插入一行数据，该行后面的所有数据的行数就变了，导致链表之间的key就错误。如果表增加到几十个，那就无法维护了。
解决方法：后面将表迁移到数据库中，通过类型来链接所有的数据表。
>2017.12.6更新
对于测试，兜兜转转，想出一种适用于每次测试开始，数据库被清空的情况：
- 写初始化数据工具，可以挑出所有api包括的所有post和put方法，将测试点写入创建数据的title或者其他字段中，跑初始化数据的所有脚本, 该步骤不包含测试所有异常的情况，测试开始跑该自动化初始数据脚本，该脚本通过，保证大部分写入数据的步骤正常
- 挑出从用户使用角度的核心api，写api测试，如为新增加功能的api，则多覆盖异常情况，旧的api没有时间就写正常流程的测试，有时间也尽量添加异常的测试
- 挑出从用户使用角度的核心用例，移动端写appium的自动化测试，web端写selenium自动化测试
- 挑出对性能有高要求的接口，根据时间来控制数量，做一部分性能测试
以上为最近总结的测试怎么从全方面去保证系统的健壮性。
ps: 最近了解到了契约测试的概念，下一步的学习方向
最简约的测试框架
2018.6.28更新
最近写了一个特别简洁的API测试框架，参见GitHub，个人感觉比postman，requests库都要简洁。