华体会网页登录入口
  • 华体会网页登录入口:一、功能测试概要
  • 发布时间:2022-08-04 13:00:30  来源:华体会体育全站app  作者:华体会网页登录入口 点击数量:9
  •   3)测试准备:各方具体负责人员、测试环境访问地址、数据库地址、账号、密码、代码版本、功能等确认

      环境,工具,时间进度,需求范围,相关的产品、开发、测试人员等,找个模板,按自己需要的改,目的是保证测试工作有序进行,所有相关项清晰,测试工作无失控混乱风险。

      (PS:因为之前的工作要么一个人负责全部项目或整条产品线,没人可安排;要么负责到具体哪些模块,领导无测试计划文档,个人一般不会做完整的计划,具体开发产品基本熟悉,正在进行的项目或版本进度也是实时掌握,要使用到的工具都熟悉,一般是做备忘录做一个进度掌控和追踪督促)

      登录、注册、文件导入(上传)、文件导出(下载)、窗口、搜索、列表展示、增加、删除、查询、修改、输入框、单选、多选、下拉选择、保存、输入框、分页、日期格式、邮箱格式、手机号格式、验证码、UI、浏览器兼容等等,都有很完善的用例,到处都是,灵活使用。

      3)方法:边界值分析、等价类划分、因果图、错误推断法、判定表、正交实验法、场景法,简单来说,多写多思考多观察多总结,我个人很喜欢看别人写的用例,收集不同的用例,学习优点,避免缺点

      4)例子:涉及进销存系统的报损功能测试(新建报损单,添加商品,填写相关数据,提交,审核,数据生效)

      ①需求梳理:报损涉及哪些模块,有哪些入口?有哪些出口?真实的报损场景是怎么样的?报损后做哪些处理? 完整的报损流程是怎么样的?报损列表有哪些字段?涉及到数量、金额怎么做统一处理?.........简而言之,搞清楚这个需求相关的所有问题。

      新增:必填、非必填、、必填+非必填、金额(非数字、空、负数、0、正数、小数、不同位数小数)、数量(非数字、空、负数、0、正数、小数、不同位数小数、超过当前库存),添加报损商品(标品、非标品)、不添加报损商品新增,添加一个商品新增,批量添加商品新增,添加标品、非标品新增,新增报损单验证(新增显示字段、值、条数、时间、用户等)、添加超多商品新增,新增多个一样的报损单,新增报损单不审核(无库存扣减),新增报损单审核(库存扣减验证),新增结果验证(条数、值、时间、审核状态、相关人员等),新增保存关闭,新增不保存关闭等

      查询:输入查询、模糊查询、精准查询、默认查询条件、默认置灰查询提示、查询条件组合、查询范围、查询结果(空、不满一页、超过一页、字段、值、值null\值空\值计算\值与数据库对比\值与上下游关联数据计算\值显示超长)、查询报错提示、查询超时提示、查询加载状态、结果列表上下左右滚动触发及显示等等

      删除:单条删除、批量删除、无数据点击删除(正常要置灰不可点击)、不选择点击删除、删除结果验证(删除后查询或数据库查看或关联上下游查找)、删除提示、删除确认、删除取消、删除关闭、有上下游关联单据的数据删除、删除未审核单据、删除已审核单据等等

      修改:修改与已有单据重复提交,删除必填提交,删除非必填提交,删除所有提交,修改未审核单据,修改已审核单据,修改参数为非法长度、非法数据类型提交等等

      业务:正常新增报损单审核,新增重复的报损单审核,报损数量超过库存审核,报损单新增时与审核时库存不一致,退货库存报损(关于客户退货),入库库存报损(关于采购退货),盘点库存报损(关于分拣损坏),报损涉及标品不同单位和拆分,两个报损单前后报损同样商品同时审核等等。

      ③测试用例编写:编号、模块、功能、标题(测试点)、重要级别(涉及后期转自动化用例)、前置条件、操作步骤、预期结果、实际结果、执行情况(已执行/未执行)、执行结果(通过/不通过)、bug描述、其他(撰写人、日期、版本、备注等)

      ④备注:用例要素可灵活调整,遵从以下原则即可:有效性,可重用性,易组织性,可评估性,可管理性(有点抽象,找到优秀的用例,仔细理解旧知道咋回事了)

      4.报告:用例覆盖、用例执行、bug严重程度分布,时间准确度,bug与开发关联等等,也可根据模板具体调整,根据公司具体情况灵活处理,模板百度能找到无数种

      2)抓包分析:源、目标、字节数、协议、版本、文件格式、请求参数、响应内容、响应时间、网速、滑动窗口、切片大小、丢包等等

      3)数据分析:Navicat连接数据库,查数据(条件、聚合函数、多表、嵌套等),查sql,查线程,查表结构,具体用法百度,以需求目标为导向,要对什么现象做定位

      4)日志分析:Xshell远程连接服务器,cat、more、less、tail、head、grep、awk、sort、uniq、wc、find、expr等,具体参数百度,以需求目标为导向,要分析什么日志,要从日志中得到什么信息,对这些信息要做什么处理。(PS:自己练习的时候基本都用过,但是真实测试过程中,分析日志的场景不多,参数基本记不住,背下来意义不大,更多是需要用的时候翻出来)

      ②因为需求一般过剩,大多测试最熟悉的需求是自己负责的部分,不熟悉需求的情况下,评审除了占用大家时间,几乎无效

      ③最理想的情况是有专门的人来做评审工作,包括需求、概要设计、详细设计等评审,这样的人要求熟悉所有需求,包括历史需求,且有丰富的测试经验

      ②产品做需求初期未考虑到的功能,没有仔细推敲到细枝末节;或只考虑了自己负责的部分,未充分与其他人负责部分的交叉影响范围

      ③公司整体产品层面缺乏一些统一的产品规范,如果产品、开发、测试都周知这些规范,会提高一定效率

      ④功能串讲能有效避免以上部分问题,之前呆过的公司都没有这个环节,还是需求过剩导致,兵荒马乱赶上线)关于测试人员水平参差不齐,部分公司有一些内部培训,大部分没有,但是效果都不显著,比如学习能力,主动

      的处事态度,认真负责这些,教再多理论,也需要员工自己本身认可并主动去那样做,大部分时候人们更多认为工作只是工作,完成好不出差错即可,这也是我自己工作前两年的想法,后来才会想着不但要完成,还想做的更好一些4)关于文档问题,要么太乱,要么缺少,加上人员更替,导致历史需求经常因为不被理解而重做,其实旧版本已经实现5)善用百度,除了生命财产相关,百度能解决大部分问题,特别是工作辅助:关键词搜索、精品内容判断、内容理解认同、实操验证可用性、经验转换积累,不可尽信,适合自己的才是最好的。

      6)完整的评审规范和控制流程覆盖每个项目生命周期,加一个执行力很强的leader,完美解决90%的问题,这是偶的梦想,之前短暂的呆过一个很大的公司,有非常完善的质量管理流程和各种规范,很惊叹,涉及产品、开发、测试,但是因为公司很大,具体到落地,我的感受是:冗长、繁杂、延迟、避责,更多的要求是不出错,关于需求、进度、人员、时间等不能快速准确掌握,既不能适应又不能改变,一言难尽选择离职了。

上一篇:市政府关于公布南通市第九届自然科 下一篇:名企设计核武器:总图设计标准(超
联系我们|版权声明|诚聘英才|网站地图|在线调查