以下是版本迭代的个人总结，总结不算精辟，没有很专业......

算是自己成长的历程......

但是对于软件自动化测试，最好的学习方法不是听课，也不是看视频，

而是在有经验的专业人士指导下进行项目实战、发现问题、解决问题。

实战实战再实战！

总结总结再总结！

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.2、写用例要从底层开始写起，按照逻辑流程写，业务要先搞明白，否则数据来源都不晓得从哪里的来，用例看起来就只有页面上的UI查看，没有深入骨髓的验证。

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一类的，应该是 数据源、数据接入【以后页面步骤修改后，会有歧义，而且不够专业】

3、做事要赶在导师前面，比如导师要审核用例，自己要提前把用例写好、检查好、修改好。不要出现一些低级错误。

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、对织云产品业务逻辑进一步熟悉
• 2、写的用例导师审核通过率有所提高
• 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了）

• 功能测试完成之后，需要考虑其他测试，最基本的就是接口返回太慢

积极主动，越总结越成长！

在经验中总结经验，在总结中继续总结......