推荐做任务网站,给传销做网站,php在网站开发中的作用,网站的最近浏览 怎么做最近一直在进行接口自动化的测试工作#xff0c;同时对于一个项目的整个测试流程进行了梳理#xff0c;希望能对你有用~~~ 需求分析#xff1a; 整体流程图#xff1a; 需求提取 - 需求分析 - 需求评审 - 更新后的测试需求跟踪xmind 分析流程#xff1a; 1. 需…最近一直在进行接口自动化的测试工作同时对于一个项目的整个测试流程进行了梳理希望能对你有用~~~ 需求分析 整体流程图 需求提取 - 需求分析 - 需求评审 - 更新后的测试需求跟踪xmind 分析流程 1. 需求提取 分析依据包括需求矩阵、产品交互图、需求说明书获取需求的纬度客户价值可以为客户带来哪些价值可以解决哪些问题根据以上问题定位功能是否合理 UI功能 - 展示功能模块关联-历史模块新功能模块关联考虑是否关联耦合部分是否需要支持客户使用场景-部署方式网络特性客户使用服务器常见外设性能参数-性能要求网卡最低速率硬件支持输出提取最原始的测试需求2. 需求分析 分析依据五维分析用户场景功能是否和场景强关联网络拓扑能否满足客户需求和竞争对手比较差异功能是否能满足客户实际应用场景是否考虑了用户的实际操作明确性范围明确性参数、类型长度范围清晰性限制等范畴无法预知影响的需求提出进行确定风险二义性概念模糊【大概念、第三方支持、与上个版本相同】支持与不支持等范畴一个需求描述能出现多种理解完整性需求一致性【用户需求、需求规格、需求矩阵三者是否同意】需求完整【隐形需求】关联性【与新老功能、与外置软件设备】可测试性实现测试需要的工具、方法【调试、接口命令】定位方式【日志等形式观察】复杂环境、容量边界、操作时过程不可见输出测试需求跟踪缺陷预防bug工具需求整理出明确的需求点测试地图分析思路误区需求和实现的区别【现有需求才有代码实现不能把代码实现当作需求】需求分析的意义明确产品给客户带来的价值明确产品支持和不支持的功能明确产品各个功能的约束性知道开发实现功能知道测试分析和产出测试点 测试设计 测试分析 1. 我们需要做什么 把明确的需求点转换成测试项缺陷预防2. 怎么做 整体模块分析逻辑分析【这一点主要是从产品实现的原理上去分析可能的影响】怎么做开发的设计文档补充和挖掘测试点全部服务的异常监控、服务重启各类存储对空间的占用、占满、是否需要做存储的接口测试所有类型的管理员、操作权限测试、支持的多少管理员并发操作对流程图的挖掘 -- 流程图全部流程测试、流程图重要的节点异常测试对状态的挖掘 -- 所有状态的相互转化需要覆盖全、状态转化是否合理、每一个状态下哪些操作可做哪些不可做多个状态是否可以共存对关联项的挖掘 -- 流程进展到哪一步关机重启/服务重启、和备份配置的关联和操作日志的关联等等任务的并发操作测试、是否可配置、是否会出现性能不足是否符合用户场景异常处理机制测试异常处理机制是否完善指标测试开发的指标设计是否合理修正不合理的需求如何分析逻辑原理该模块是否涉及到一些全新的概念(比如我们的 bbc 全量包)需要明确?该模块包括哪些服务?该模块涉及到哪些存储技术(如 mysql、dap、redis)?具体怎么存储的?占用大小如何?该模块的操作流程有哪些?是否有子流程图?该模块是否有多个状态的转化?是否有明确的状态转化图?该模块对多个管理员是否区分管理员权限如何设计?该模块是否有一些特殊的操作限制?操作限制是否有明确的表格?该模块的任务是否有并发需求?并发的设计?该模块的所有指标如何?该模块是否有异常处理机制?在设备各种异常时该模块的设计是否满足能稳健运行?场景分析从用户的使用习惯和使用方法去分析影响检查当前案例是否覆盖到用户场景关联测试分析考虑你的模块所在整个系统的地位分析上下游的影响对老功能的影响经验补充分析版本分析模块分析输出测试项补充测试地图 测试设计 需要做什么 把测试项细化成测试点 缺陷预防 2. 需要做什么 基本设计方法等价类划分法【将输入域和输出域划分为不同的等价类等价类之内的操作结果相同】使用范围显示输入框输入边界值法【需要结合等价类划分法方法在划分出来的等价类选取有代表性的值】正反对比【一般会放到同一个用例里覆盖】字符多样性【考虑不同字符的输入】测试类型产品专项测试正交组合设计【正交矩阵覆盖各个参数间的组合情况】业务逻辑设计【根据业务设计测试点】3. 输出 基本测试点 用例设计 1. 需要做什么 把测试点用文字完整表述出来2. 怎么做 功能用例框架模块框架模板需求类UI测试【如果UI用例可以被功能用例覆盖这里可以不写】公共测试类链接选中会有高亮显示点击跳转到对应页面当前页面对应的名称下有区别显示翻页按钮输入框【这个功能用例一般可以覆盖】下拉框排序条目选择【这个很重要第一次集成测试一定要保证每个选项都是有效的】搜索所有字符类型验证为空验证模糊搜索精确搜索搜索不存在的关键词刷新验证自动刷新验证手动刷新验证持续刷新拖动移动点击下移往下移动一行点击上移往上移动一行最上面的行上移不能点击图标灰色最下面的行下移不能点击图标灰色功能测试测试点功能基本流程逻辑覆盖业务流程多样性覆盖用户操作习惯的多样性模块配置的多样性数据流的多样性覆盖测试目录平级分类相对独立上下级分类有关联下级从上级细化而来关联类模块与模块之间的模块与功能之间模块与硬件之间场景类建模思路部署方式【比如用户一般使用2主机还是3主机部署集群】数据流业务流【用户是怎么使用申请工单是怎么样的完整流程】操作顺序【创建云主机的顺序之类的】配置方法【用户一般怎么配置使用静态路由】使用时间【用户会不会连续长时间开启云主机】用户角色【一般那些角色做什么操作】用户操作的设计方向最常用的功能最容易出现网上问题的功能典型客户使用的功能版本的性能验证专项类兼容性可靠性【测试产品在异常情况下能否正常工作或者是恢复正常工作可靠性重点测试对模块自身处理的覆盖】. 补充容错性测试【测试系统在非正常操作、非正常的外部环境下是否能够处理错误和正常运行】eg 针对数据库的测试【磁盘空间不足、数据库文件损坏、无读写数据权限、写数据时断电、写数据时强制关闭mysql、读写速度】针对网络设备【网络中有攻击数据、丢包时延大、IP冲突、网络线路断开、同时掉电】针对程序【 客户端进程被手动停止、设备后台资源cpu、内存占满】3. 安全性【主要是验证程序有哪些缺陷可能会造成安全方面的问题】 eg 密码加密方式【什么时候用明文什么时候用密码显示】 隐私数据隐藏【用户的隐私显示】设备的完整目录【完整的目录会增加后台被攻击的危险】文件上传功能【检查上传的文件类型限制上传文件的权限】防暴力破解【对于连线认证之类的操作要冻结、禁用其连续错误尝试操作】4. 脚本测试 使用注意细节文件夹以01-xx02-xx区分开每个文件夹下不能超过10个用例每个测试用例一个测试点在02-功能测试的描述中备注说明功能测试框架的思路用例整体规范用例标题【好的标题需要准确的表达你的测试目的、要测试的测试点】eg 测试。。。验证。。。。。。的测试与。。。的关联测试。。。的异常测试。。。的兼容性测试用例属性测试环境【默认的前置条件可以不用写写的前置条件要准确不要写的模糊】测试方法优先级BVT【最最最基本的功能】-BVT(10%)模块最基本的功能验证(含常用部署、基本关联)推荐1级用例的20%左右level1【基本操作、基本场景】-Leve1(30%)基本需求点基本逻辑基本可靠性基本关联基本用户场景level2【比较少见的正常操作】-Leve2(40%)常见功能/逻辑细化点/专项细化点常见关联/容错/边界值/用户场景level3【异常操作后续不需要再执行】-Leve3(20%)错误提示、极少测试的用例、非常见部署方式/用户场景/容错/边界值等用例格式前置条件测试步骤【单个用例全部步骤不能超过8步】后置条件【不是必填的】预期结果备注【不是必填的】语言规范语言简练不能出现模糊的形容词【比如说大概、可能、很多、差不多】可维护性灵活运用模块备注设计原则目的明确【一个用例对应一个测试点测试步骤和测试目的一致】用例效率保证设计出来的用例10分钟内可以执行完成用例需要的环境可以整理出来然后写到模块备注中让执行者先准备好环境一次性执行全部用例执行的时候按照测试集方式来执行有工具可以实现的用例不要采用脚本方式实现3. 测试步骤 用户角度设计的用例要符合用户的操作顺序和操作习惯符合用户的使用环境符合用户的配置可执行不要出现那种用例设计没有错但是执行起来很复杂或者是依赖环境很夸张的用例正反对比这一点很重要很多时候我们会把有正反操作的用例分开写其实是可以合在一个用例里面写强弱关联对于强关联的步骤一定要写清楚对于弱关联的可以备注或者是不写测试用例不能出现操作步骤直接写需要做的操作就可以了4. 预期结果 用户角度反思用户期望操作完会有什么结果反思客户最关注的测试点可检查预期结果要可以观察到不要写的很模糊把重点检查的检查点覆盖到用例编写口诀强弱正反之业务重点突出之效率目的明确之语言框架覆盖之检查逻辑场景之经验 用例执行和回归 用例执行标准 1. 执行优先级 建议用例级别执行顺序【bvt、leve1、leve2、leve3】建议用例区域执行顺序【基本功能、高风险区域、复杂逻辑优先测试】2. 用例执行状态 Not Complete用例无效、用例错误、无测试环境等过程状态Passed执行通过No Run默认状态未执行N/A无须执行需填写备注需处理Failed执行失败需填写BUGIDBlocked被其他问题阻塞Not Modify由Failed状态而来用例发现的bug不修改bug为halt、Wont Fix3. 自动化用例 覆盖全部bvt用例大部分level1基本的功能一定要覆盖4. 执行技巧总结 执行前首先要看执行备注模块备注、文件夹备注、用例备注了解这个模块是做什么的需要注意哪些点和执行的辅助命令和工具然后把一个模块下的所有用例大概过下能一起执行的可以一起执行执行时增改查删顺序执行用例一类的用例一并执行比如说测试多种不同的nfv设备的授权之类操作虽然每个nfv设备都是一个用例但是都可以一起操作执行UI限制的用例可以把限制条件整理出来做成模版直接套用执行的时候关注的测试点遇到测试点很简单但是测试步骤很复杂的可以异测试点测试为主和用例编写的人协商优化一些执行步骤或者是先自己优化再备注后面统一和用例执行人讨论可不可以这样优化不理解的用例可以问执行过的人或者是写用例的人耗时或者是异常的用例【可以在别人休息吃饭的空闲时间去执行不要影响公共测试环境】执行后 bug回归标准 1. bug分类 low【UI问题、体验问题】medium【基本功能问题】high【性能问题】urge【宕机、无法使用、数据丢失、业务无法使用】 补充用例 在执行用例或者是回归bug的时候遇到level1级别的用例没有覆盖的一定要补充用例覆盖用例覆盖点过多把几个级别的用例覆盖了需要拆分用例 质量分析 1. Bug的类型主要是哪几类 包括功能问题,性能问题,稳定性,可靠性,关联,兼容性,需求方案等改进,易用体验性,异常容错分析出主要类别后在进一步分析各个类别产生的根本原因比如用例编写问题测试步骤达不到测试目的用例有歧义等改动引发是需求、方案变动带来的还是纯粹的改一个bug引发另一个 2. 模块质量分析 缺陷分析用例质量分析测试漏侧分析需求变更分析模块改动分析发散测试分析重点难点分析开发人员评价回归测试分析bug定位 前端定位 1. 工具 谷歌浏览器network检查参数【是否准确、是否有缺少】检查响应时间【查看加载时间】检查响应内容【查看响应内容是否有缺少{缺少的话是后端返回的问题如果没有缺少的话有可能是前端处理的问题}】source【在测试用例的时候可以打开source调试有一些页面的错误可以被俘获到】 postman【模拟请求发送是否正常】 后端定位 1. 后台报错日志 方法一cd日志文件所在的目录 | grep -rn 关键词根据行号查看异常日志内容 tail -n 203915 文件名 | head -n 200行 显示文件中第203915行之后的200行 方法二less 具体的目录文件 #进入指定的目录文件然后 /关键词2. 数据库【mysql】 非技术方法 对比法【比如说acmp上私有云的功能都是沿用acloud的功能想判断acmp上的问题可以对比查看acloud上是不是有也有这个问题如果有很可能是acloud引入的问题】客户导向法【对于一些新功能我们可以根据用户场景去判断这个功能实现是属于正常的操作还是不合理的设计】逻辑分析【有时候开发自己设计的产品实现原理不一定是合理的可以分析下实现步骤看看是不是有问题】 总结下排除思路 判断是否是必现问题【先查看是否是必现的【到别的环境去试下问题是否能必现】非必现的问题【排查网络问题资源不足的问题】】判断是我们平台本身的问题判断是前端的问题还是后端的问题【抓包查看请求请求中的返回数据是否显示完整。显示完整那么一般就是前端没有处理好数据显示找前端看看如果返回数据有空缺或者是不完整那就找后端看看】 转载于:https://www.cnblogs.com/sunshine-blog/p/9782201.html
