2019独角兽企业重金招聘Python工程师标准>>>
以下是版本迭代的个人总结，总结不算精辟，没有很专业……
算是自己成长的历程……
但是对于软件自动化测试，最好的学习方法不是听课，也不是看视频，
而是在有经验的专业人士指导下进行项目实战、发现问题、解决问题。
实战实战再实战！
总结总结再总结！
2018-03-22
- 1、用例的标题：一看标题，就知道自己的测试重点是哪个。
- 1.1、若新来测试人员看你的用例，确保没有异议，并且别人看你的标题时 不用费很多时间理解；
- 1.2、能够一语击中要害。
- 2、写好用例要检查一遍，确保不会自相矛盾、不会出现低级错误。
- 3、对于第一次结束的产品，要多操作几遍，检查是否有遗漏的用例没有覆盖到。
- 4、测试用例算是我的武器，工欲善其事、必先利其器。
- 5、执行“测试计划”时，用例不需要点开看详情，就知道测试点，为最好！（简洁明了又省时间）导师常说：测试资源是非常非常宝贵的。
- 6、【写用例要从底层开始写起，逻辑流程要先搞明白，按照流程的顺序写。】
2018-04-08
- 1、某一个功能多入口的情况；单条正常、多条也要正常、长度限制等等场景；
- 2、正常情况、异常情况（破坏场景下）；
- 3、功能与功能之间的关联性；
- 4、每一个“步骤”都要注意，可能出现的可能性；
- 5、用户的体验如何；
- 6、拿到需求，不要着急测试，一定要补充和完善用例。（等到真正测试的时候，头脑可能会模糊，但是用例设计好了，就可以机器似的跟着用例测试）
- 7、基于python写自动化测试脚本， 根据tapd上的测试用例进行编写，主要写【core】的用例。
- ps，以后写用例要加上【UI】【core】的标识
- 用例要简洁，一眼看出测试重点，为了写代码时debug，可以一眼定位问题
- （代码规范、代码步骤、api、封装包）
- 8、自动化脚本执行的时，创建的数据最后要清理。
- 9、重新发布版本后，先过core基本核心的功能，基本核心功能不行的话，版本是需要重做。
- 10、学习 Chrome开发者工具 ，Cmd+Opt+I ，F12
- 11、掌握Linux的常用命令，不是去背，而是真正使用，放弃界面操作，直接命令代替
- 12、放弃百度搜索引擎，首选google、必应
2018-04-30
- 1、关于测试环境代码是否是最新，需要再三确认
- 【开发虽可以自己合代码到环境，但每日构建可以会遗漏】
- 2、缺陷的回归验证，一定要等到每日构建完成后
- 【若代码不是最新，浪费时间、精力、心情】
- 3、发现问题，要多测试几遍，保证不是自己眼花手抖后，再反馈给开发
- 【准确区分是web 或 server端问题会更好，F12】
- 4、织云产品的业务一定要熟悉，哪怕是一些细枝末节
- 【关键字、专业术语、页面展示、业务逻辑、模块间关联、用户体验、思维扩展等】
- 5、织云用户可以小白，可以大神，测试人员也需要是小白，是“大神”
- 【切换不同身份对织云进行测试（不要怕把系统搞坏了）坏了可以修】
- 6、有关咨询和问题
- 6.1、刚开始第一次接触此产品，若不懂问同事们，同事们会理解
- 【若接触很久还是不懂，再问，会被白目】
- 6.2、尽量不要有问题就跑去反馈给导师或者开发，大家都很忙，思维也不想经常被打断
- 【自己先研究下，若还是不理解或者阻塞问题，再去打扰】
- 6.3、整理好需要问的清单，一次性问完
- 【节省彼此的时间 】
- 7、测试用例：对于新的业务，不知道该如何下手，那就先从模仿师父的用例开始
- 【但不要邯郸学步】
- 8、刚开始暂时不要评论产品设计的好与坏，博观而约取、孤陋而寡闻
- 【刚开始要学会认真聆听，带有思考的聆听，不想当产品的测试不是好开发】
- 9、照顾好自己的身体，不要生病
- 【在身体不好的背景下，其他一切都是虚的】
- 10、有些时候不是自己等着开发完成后主动找你测试，需要的是主动跟进，这样就不会令时间太赶
- 鉴于 V3.7.5作业工具后期增加功能自己没有测试的惨痛经历得来的。
2018-05-25
1、TCE功能相对少一些，但是基本功能还是要全面仔细的测试，不厌其烦。
2、多维监控写用例总结
2.1、多维监控，相当于新的产品，用例从零开始写起
2.2、每一个模块用例大致可以分为 UI、core、其他
2.3、每一个功能都会有一个core功能点，比如C R U D
2.4、若core的用例都不通，其他的用例就不用测试了
2.5、多维监控分为四个模块：多维分析、数据接入、页面定制、后台管理
2.5.1、刚开始我思路是先写简单的多维分析啊，其实是不对的
2.5.3、正确的步骤：
数据接入(新增流程) -> 后台管理(分配流程) -> 数据接入(启动流程)->
页面定制(对指标和维度进行二次筛选和加工) -> 多维分析(展示页面定制后流程的指标趋势图和维度分析)
2.6、最后检查用例
2.6.1、是否和产品最终的描述一致
2.6.2、逻辑是否一致
2.6.3、下拉框的数据
2.6.4、单选、多选
2.6.5、用例的等级【等级的分类】
2.6.6、标题的修改，一目了然
2.6.7、不要写步骤1、步骤2一类的，应该是 数据源、数据接入【以后页面步骤修改后，会有歧义，而且不够专业】
4、正式环境，黑石需求的测试
4.1、在test环境测试几遍后，prd环境还是有一些问题，本来是可以避免的，还是自己不够认真导致的，用例的覆盖没有100%
4.2、部署到正式环境，要首先保证基本功能正常
4.3、刚开始先不要纠结于小的细节，先保证基本功能ok，在测试其他
4.4、测试数据要及时删除
2018-06-22
- 1、测试用例是根据原型图写的，开发完成后，需要更新完善测试用例
- 2、核心功能：不单纯是 增删改查，还需要有产品的设计初衷
- 比如：新增了规则，记录中要有记录，屏蔽了规则，就不能收到告警
- 这也是 【核心用例】
- 3、核心用例也就是整个产品的最基本的功能
- 4、过一遍，意思就是 过一遍核心功能。
- 所以测试用例写的时候，一定要把 核心功能 设计好，设计完成
- 5、测试问题的闭环思维【重点的重点】
2018-07-05
- 1、对织云产品业务逻辑进一步熟悉
- 3、测试方法和效率的小提高，没有刚开始的手忙脚乱，【番茄工作法】
- 4、总结学习该行业的专业术语，以及IT术语，写缺陷单不会太Low
2018-08-15
- 1、在工作量比较大的时候，测试有时候会断片：
- 有的功能明明已经在第一轮测试通过，第二轮时发现新的问题，断片了，怀疑自己，所以合理安排测试计划。 【番茄工作法】
- 2、用例等级一定要划分好：高、中、低
- 一轮测试，二轮测试，三轮测试时，可以筛选出不同的用例来进行测试。
- 3、模糊搜索：不止特殊字符、前后空格，还需要增加大小写的用例
- 4、产品体验的时候，自己也要去体验，更新添加测试用例（工欲善其事必先利其器）
- 5、测试问题的闭环意识：发现的问题 要及时的跟进，一环扣一环的往前推动，不管需要经历多少人。
- 6、多研究下前端的专业术语 和 知识。
- 7、保持浏览器F12常开，出现问题可以马上查看Network、Console
- 8、这次测试有点不完整（实例列表-高级搜索-搜索栏的删除图标功能有问题，XD），以后测试要把全部的按钮都点击。
2018-09-21
- 1、本期主要的需求就是重构
- 2、测试用例编写时间比起第一期大大缩短，刚开始需要借助XMind，先整理需求，拆分需求，非常细化后才开始动手写用例，要不然没有安全感。
- 现在基本上用evernote写写大纲就可以着手写用例。
- 3、本期测试时间较其他版本充裕，测试进行了2轮功能细测，1轮冒烟测试。
- 4、发现了问题，先记录下来，复现成功提缺陷。复现不成功时，不阻塞测试就先记录下来，等待开发空闲查log。
- 5、积极推动项目进度，每天做测试进度给leader
2018-11-26
- 1、拿到不同的需求，先列出主要功能，汇总下，方便知道本次迭代的核心功能,类似每个软件的升级说明
- 2、测试的时候，还需要看产品设计是否合理，用户体验是否良好，eg：体验优化，执行工具后的任务查询，应缩短访问路径
2019-01-17
- 发现问题，就要记录下来，不要觉得可能是开发没有搞好，环境问题啥的。就要提出来就对了。
- 特别是需要和第三方进行对接的场景下，第三方修改了接口，我们不知道，就会出现异常。
- 之前版本是ok的，现在不ok，就是问题，就需要提出来。不要怂，开发不是魔鬼。
2019-03-22
- 测试用例是需求评审之后写的，期间又接触了一些项目，开发阶段需求的修改，没有及时的修改测试用例。导致执行测试的时候，大部分是根据需求测试的。不能保证全面覆盖需求。
- 问产品需求、开发问题时，被别人说过3次：你的问题点在哪里
自己对需求的不熟悉，自己糊里糊涂，就问不到点上；
自己不经常与人沟通，紧张、不自信吧；
- 缺陷单，能贴上复现链接就贴上吧。
- 系统与系统的数据对比，尽量是相同的参数进行。（这次把两种不同的场景数据进行对比，提的单被开发diss了）
功能测试完成之后，需要考虑其他测试，最基本的就是接口返回太慢
积极主动，越总结越成长！
在经验中总结经验，在总结中继续总结……
文章知识点与官方知识档案匹配，可进一步学习相关知识Python入门技能树首页概览208019 人正在系统学习中 相关资源：【内存遍历工具】Cheat.Engine.V5.4.简体中文版-专业指导文档类…
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！