一个项目的整个测试流程

最近经常在进行接口自动化的检测工作，同时针对一个项目的整个检测步骤进行了梳理，希望可对你有用~~~

需求提取 -> 需求分析 -> 需求评审 -> 更新后的检测需求跟踪xmind

功能能否跟画面强关联网络拓扑如何满足用户需求跟竞争对手比较差距功能能否可满足用户实际应用画面是否考虑了客户的实际操作范围明确性（参数、类型宽度范围）清晰性限制等范畴无法预知影响的意愿提出进行确认，风险概念模糊【大概念、第三方支持、与下个版本同样】支持与不支持等范畴一个需求描述可发生多种理解需求一致性【用户需求、需求规格、需求矩阵三者是否同意】需求完整【隐形需求】关联性【与新老功能、与内置硬件设施】实现检测必须的软件、方法【调试、接口命令】定位方法【日志等方式观察】复杂环境、容量边界、操作时过程不可见测试需求跟踪缺陷预防bug软件需求整理出明确的需求点检测地图明确产品给用户带给的价值明确产品支持跟不支持的用途明确产品各个功用的约束性了解研发实现功能清楚测试预测跟产出测试点把确立的需求点转化成测试项缺陷预防整体模块分析逻辑分析【这一点主要是从产品推动的机理上去剖析可能的妨碍】全部服务的异常监控、服务重启各类传输对空间的挤占、占满、是否应该做储存的接口检测所有种类的管理员、操作权限测试、支持的多少管理员并发操作对流程图的挖掘 -- 流程图全部步骤检测、流程图重要的节点异常检测对状况的挖掘 -- 所有状况的相互转换必须覆盖全、状态转换是否合理、每一个状态上什么操作可做哪些不可做，多个状况能否可以共存对关联项的挖掘 -- 流程进展至那一步关机重启/服务重启、和备份配置的关联，和操作日志的关联等等任务的并发操作检测、是否能配置、是否会出现性能不足，是否依照用户场景异常处置措施测试，异常处理机制是否健全指标检测，开发的指标设计能否合理该组件是否涉及至一些全新的概念(比如我们的 bbc 全量包)，需要确立?该模块包含这些服务?该组件涉及至这些内存技术(如 mysql、dap、redis)?具体如何传输的?占用大小怎么?该组件的操作步骤有什么?是否有子流程图?该组件能否有多个状况的转换?是否有明晰的状况转换图?该组件对多个管理员是否区分，管理员权限怎么设计?该组件能否有一些特殊的操作限制?操作限制是否有明晰的表格?该组件的任务能否有并发需求?并发的设计?该组件的所有指标怎么?该组件能否有异常处理机制?在设施诸多异常时，该组件的设计能否满足可稳健运行?从客户的使用习惯跟使用方式去探讨制约检查当前实例是否覆盖到客户场景考虑你的组件所在整个平台的地位，分析上下游的妨碍对老功能的制约版本预测模块分析测试项补充测试地图等价类划分法【将输入域跟输出域划分为不同的等价类，等价类之：显示输入框输入边界值法【需要结合等价类划分法方法，在界定出来的等价类选择有代表性的值】正反对比【一般会放在同一个用例里覆盖】字符多样性【考虑不同字符的输入】测试类别选中会有高亮显示单击跳转到对应页面当前页面对应的名称上有差别显示所有字符种类验证为空验证模糊搜索准确搜索搜索不存在的关键词验证自动刷新验证手动刷新验证持续刷新点击下移，往下挪动一行点击上移，往上移动一行最前面的行，上移不能点击，图标红色更上面的行手机完整测试流程?，下移不能点击，图标蓝色功能基本步骤逻辑覆盖业务流程多样性覆盖客户操作习惯的多样性模块配置的多样性数据流的多样性覆盖平级分类相对独立上下级分类有关联下级从上级明确而来模块与模块之间的组件与功能之间模块与软件之间部署模式【比如客户通常使用2主机还是3主机推进集群】数据流业务流【用户是如何使用申请工单，是怎么样的完整步骤】操作排序【创建云主机的次序之类的】配置方式【用户通常如何配置使用静态路由】使用时间【用户会不会连续长时间开启云主机】用户角色【一般这些角色做哪些操作】最常见的功能最容易出现网上问题的功能典型用户使用的用途版本的功耗验证兼容性可靠性【测试产品在异常状况上能够正常工作以及是修复正常工作，可靠性重点检测对组件自身处理的覆盖】。 补充：容错性测试【测试平台在非正常操作、非正常的内部环境上能否还能处理错误跟正常运行】

eg：

针对的检测：【磁盘空间不足、文件丢失、无读写数据权限、写数据时断电、写数据时强行关闭mysql、读写速度】针对网络设备：【网络中有攻击数据、丢包时延大、IP冲突、网络线路断开、同时掉电】针对程序：【 客户端进程被自动中止、设备后台资源cpu、内存占满】

3. 安全性【主要是验证程序有什么弊端可能会造成安全方面的问题】

eg：

密码加密方法【什么时候用明文，什么时候用密钥显示】隐私数据隐藏【用户的隐私显示】设备的完整目录【完整的目录会降低后台被伤害的危险】文件上传功能【检查上传的文件类别；限制上传文件的权限】防暴力破解【对于连线认证等等的操作应冻结、禁用其连续错误尝试操作】

4. 脚本测试

文件夹以01-xx，02-xx区分开每个文件夹下不能超过10个用例每个测试用例一个测试点在02-功能测试的表述中，备注说明功能测试框架的模式

eg：

2、精通测试步骤和检测用例设计方式，能主动进行科技钻研7. 精通测试步骤跟检测用例设计方式,能主动进行科技钻研3. 精通测试步骤和检测用例设计方式，能主动进行技术钻研

3. 测试步骤：

5.后置条件 无 6.扩展点 无 7.相关的数据 用户信息表 8.问题表明 无 删除用户用例日期 2014.4.6 版本 草案 说明 草案版本 作者 梁燕 1.简要说明 本用例描述平台管理员删除系统客户的操作需求不总是显而易见的,而且它能来自各个方面. 需求并不总是容易用文字清楚无误地表达. 存在不同种类的需求,其具体程度各不相同. 如果不加以控制,需求的总量将无法管理. 需求彼此之间或者与流程的其它能交付工件之间以多种方式相关联. 需求有唯一的特点或特征值.例如,它们又非同等重要,处理的难度也不同. 需求涉及很多相关利益责任方,这意味着需求应由跨职能的各组人员来管控. 需求出字塔形式的管控方法,来组织跟管理我们获得的信息甚至最后的意愿.为了完善一个真正满足用户意愿的平台,项目团队首先需要确认平台应解决的难题.然后,团队需要确认涉众,从中获得业务跟客户必须,对其进行表述,并区别两者的优先级.从那一组高层希望或意愿出发,对产品或平台特点集达成一致看法.而后,由产品特点来抽取工具需求,在我们的建模中,软件需求是以用例模型的方法来表述.从检测的视角来看,测试项一定来自于硬件需求,即软件需求中确认了什么需求项,测试还要按照这种需求项来建立跟实现.系统越小越复杂,出现的需求种类就越多.一个需求种类不过是指需求的一个类.通过确认需求类型,团队可以把少量需求组织成含义明确且更容易管理的组.在一个项目中构建不同类型的意愿有助于团队成员对更改请求进行分类,并让彼此之间的交谈更为清楚明晰.从上述的剖析中我们可以看见,通常,一类需求可以细分即分解成其它种类的需求.这里,我们就把需求分解为几种类型,并在人们之间搭建相应的关联.业务规则跟形势声明包括高层次的意愿,团队可以从中导出客户必须,特性跟产品需求种类.用例和其它模型手段驱动设计需求,该需求能分解为工具需求,并可以用预测设计建模来表明.测试需求源于软件需求,它被分解为详细的检测过程.如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以让项目更容易管理.上述的这种需求种类同时存放在对应的rup文档跟中需求分析建模1.主观推断预测

4. 预期结果

反思用户希望操作完会有哪些结果思考用户更关注的测试点预期结果应可以观察到，不要写的太模糊把重点检查的检查点覆盖至强弱正反之业务重点突出之强度目的明确之语言框架覆盖之检查逻辑场景之经验建议用例级别执行排序【bvt、leve1、leve2、leve3】建议用例区域执行排序【基本用途、高风险区域、复杂逻辑优先测试】Not Complete：用例无效、用例错误、无检测环境等过程状态Passed：执行通过No Run：默认状态，未执行N/A：无须执行，需核对备注，需处理；Failed：执行成功，需填写BUGIDBlocked：被其它问题阻塞Not Modify：由Failed状态而来，用例发现的bug不设置，bug为halt、Won't Fix覆盖全部bvt用例大部分level1（基本的功能一定要覆盖）首先应看执行备注（模块备注、文件夹备注、用例备注），了解这个模块是做哪个的，需要留意这些点跟执行的辅助命令和软件之后把一个模块上的所有用例大概过上，能一起执行的可以一起执行增改查删顺序执行用例一类的用例一并执行，比如说测试多种不同的nfv设备的授权等等操作，虽然每个nfv设备都是一个用例，但是都可以一起操作执行UI限制的用例，可以把限制条件整理起来，做成模板，直接套用执行的之后关注的测试点，遇到测试点很简单但是测试方法很复杂的，可以异测试点检测为主，和用例编写的人协商优化一些执行流程，或者是先自己改进再备注，后面统一跟用例执行人讨论可不可以这样改进不理解的用例可以问执行过的人甚至是写用例的人耗时甚至是异常的用例【可以在对方休息睡觉的闲暇时间去执行，不要影响公共检测环境】在执行用例以及是回归bug的之后遭遇level1级别的用例没有覆盖的一定要补充用例覆盖用例覆盖点过多，把几个级别的用例覆盖了，需要拆分用例

包括：功能问题,性能问题,稳定性,可靠性,关联,兼容性,需求方案等优化,易用体验性,异常容错；分析出主要类型后，在进一步探讨各个类型造成的根本因素，比如用例编写问题（测试方法达不到测试目的，用例有歧义等）；改动导致（是需求、方案变动带来的抑或纯粹的改一个bug导致另一个？）

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-131999-1.html