最近一直在进行接口自动化的测试工作，同时对于一个项目的整个测试流程进行了梳理，希望能对你有用~~~
对状态的挖掘 -- 所有状态的相互转化需要覆盖全、状态转化是否合理、每一个状态下哪些操作可做哪些不可做，多个状态是否可以共存
对关联项的挖掘 -- 流程进展到哪一步关机重启/服务重启、和备份配置的关联，和操作日志的关联等等
该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占用大小如何?
BVT【最最最基本的功能】-BVT(10%)：模块最基本的功能验证(含常用部署、基本关联)，推荐1级用例的20%左右
level1【基本操作、基本场景】-Leve1(30%)：基本需求点，基本逻辑，基本可靠性，基本关联，基本用户场景
level2【比较少见的正常操作】-Leve2(40%)：常见功能/逻辑细化点/专项细化点，常见关联/容错/边界值/用户场景
level3【异常操作；后续不需要再执行】-Leve3(20%)：错误提示、极少测试的用例、非常见部署方式/用户场景/容错/边界值等
Not Modify：由Failed状态而来，用例发现的bug不修改，bug为halt、Wont Fix
首先要看执行备注（模块备注、文件夹备注、用例备注），了解这个模块是做什么的，需要注意哪些点和执行的辅助命令和工具
一类的用例一并执行，比如说测试多种不同的nfv设备的授权之类操作，虽然每个nfv设备都是一个用例，但是都可以一起操作
执行的时候关注的测试点，遇到测试点很简单但是测试步骤很复杂的，可以异测试点测试为主，和用例编写的人协商优化一些执行步骤，或者是先自己优化再备注，后面统一和用例执行人讨论可不可以这样优化
包括：功能问题,性能问题,稳定性,可靠性,关联,兼容性,需求方案等改进,易用体验性,异常容错；分析出主要类别后，在进一步分析各个类别产生的根本原因，比如用例编写问题（测试步骤达不到测试目的，用例有歧义等）；改动引发（是需求、方案变动带来的还是纯粹的改一个bug引发另一个？）
检查响应内容【查看响应内容是否有缺少{缺少的话是后端返回的问题；如果没有缺少的话有可能是前端处理的问题}】
根据行号查看异常日志内容 ：tail -n +203915 文件名 head -n 200行 （显示文件中第203915行之后的200行）
对比法【比如说acmp上私有云的功能都是沿用acloud的功能，想判断acmp上的问题可以对比查看acloud上是不是有也有这个问题，如果有很可能是acloud引入的问题】
客户导向法【对于一些新功能，我们可以根据用户场景去判断这个功能实现是属于正常的操作还是不合理的设计】
逻辑分析【有时候开发自己设计的产品实现原理不一定是合理的，可以分析下实现步骤，看看是不是有问题】
判断是否是必现问题【先查看是否是必现的【到别的环境去试下问题是否能必现】；非必现的问题【排查网络问题；资源不足的问题】】
判断是前端的问题还是后端的问题【抓包查看请求，请求中的返回数据是否显示完整。显示完整，那么一般就是前端没有处理好数据显示，找前端看看；如果返回数据有空缺或者是不完整，那就找后端看看】
