以下是版本迭代的个人总结，总结不算精辟，几乎没有技术问题，不专业，算是自己成长的历程......
对于软件测试，最好的学习方法不是听课，也不是看视频，而是在有经验的专业人士指导下进行项目实战、发现问题、解决问题。
实战实战再实战！总结总结再总结！
2018-03-22
1、用例的标题：一看标题，就知道自己的测试重点是哪个。
【若新来测试人员看你的用例，确保没有异议，并且别人看你的标题时 不用费很多时间理解】
【能够一语击中要害】
2、写好用例要检查一遍，确保不会自相矛盾、不会出现低级错误。
3、对于第一次结束的产品，要多操作几遍，检查是否有遗漏的用例没有覆盖到。
4、测试用例算是我的武器，工欲善其事、必先利其器。
5、执行“测试计划”时，用例不需要点开看详情，就知道测试点，为最好！
【简洁明了又省时间】【导师常说：测试资源是非常非常宝贵的】
6、写用例要从底层开始写起，逻辑流程要先搞明白，按照流程的顺序写。
2018-04-08
1、某一个功能多入口的情况；单条正常、多条也要正常、长度限制等等场景。
2、正常情况、异常情况（破坏场景下）。
3、功能与功能之间的关联性。
4、每一个“步骤”都要注意，可能出现的可能性。
5、用户的体验如何。
6、拿到需求，不要着急测试，一定要补充和完善用例。
【在真正测试时，头脑可能是模糊，若用例提前设计好，就可以机器似的跟着用例测试】
7、基于python写自动化测试脚本， 根据tapd上的测试用例进行编写核心用例。
【以后写用例要加上【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功能点，比如CRUD。
? ??2.4、若core的用例都不通，其他的用例就不用测试了。
? ??2.5、多维监控分为四个模块：多维分析、数据接入、页面定制、后台管理：
?? ?? ??2.5.1、刚开始我思路是先写简单的多维分析啊，其实是不对的。
?? ?? ??2.5.2、写用例要从底层开始写起，按照逻辑流程写，业务要先搞明白，否则数据来源都不晓得从哪里的来，用例看起来就只有页面上的UI查看，没有深入骨髓的验证。
? ??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、做事要赶在导师前面：
????【eg：导师要审核用例，自己要提前把用例写好、检查好。不要出现一些低级错误】
4、正式环境，黑石需求的测试：
? ??4.1、在test环境测试几遍后，prd环境还是有一些问题，本来是可以避免的，还是自己不够认真导致的，用例的覆盖没有100%。
? ??4.2、部署到正式环境，要首先保证基本功能正常。
? ??4.3、刚开始先不要纠结于小的细节，先保证基本功能ok，在测试其他。
? ??4.4、测试数据要及时删除。
2018-06-22
1、测试用例是根据原型图写的，开发完成后，需要更新完善测试用例。
2、核心功能：不单纯是 增删改查，还需要有产品的设计初衷。
【eg：新增了规则，记录中要有记录，屏蔽了规则，就不能收到告警】【这也是“核心用例”】
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、测试用例编写时间比第一期大大缩短（基本上用evernote写完大纲就可以着手写用例）
【刚开始借助XMind，先整理拆分需求，细化后开始动手写用例，要不然没有安全感】
3、本期测试时间较其他版本充裕，测试进行了2轮功能细测，1轮冒烟测试。
4、发现问题，先记录下来，复现成功提缺陷。复现不成功时，不阻塞测试就先记录下来，等待开发空闲查log。
5、积极推动项目进度，每天做测试进度给leader。
2018-11-26
1、拿到不同的需求，先列出主要功能，汇总下，方便知道本次迭代的核心功能（类似每个软件的升级说明）
2、测试的时候，还需要看产品设计是否合理，用户体验是否良好（eg：体验优化，执行工具后的任务查询，应缩短访问路径）
2019-01-17
1、发现问题，就要记录下来，不要觉得是开发没有搞好，环境问题啥的。提出来就对了。
2、特别是需要和第三方进行对接的场景下，第三方修改了接口，我们不知道，就会出现异常。
3、之前版本是ok的，现在不ok，就是问题，就需要提出来。不要怂，开发不是魔鬼。?
2019-03-22
1、测试用例是需求评审之后写的，期间又接触了一些项目，开发阶段需求的修改，没有及时的修改测试用例。导致执行测试的时候，大部分是根据需求测试的。不能保证全面覆盖需求。
2、问产品需求、开发问题时，被别人说过3次：你的问题点在哪里？
????2.1、自己对需求的不熟悉，自己糊里糊涂，就问不到点上；
????2.2、自己不经常与人沟通，紧张、不自信吧。
3、缺陷单，能贴上复现链接就贴上吧。
4、系统与系统的数据对比，尽量是相同的参数进行。
????【这次把两种不同的场景数据进行对比，提的单被开发diss了】
5、功能测试完成之后，需要考虑其他测试，最基本的就是接口返回太慢。
2019-06-18
1、经常看看别人的测试用例，简洁明了。
2、发现问题就是问题。不要老是command+r、f5（系统报错，就是问题。偶先也是问题）
3、首先关注的功能是否实现，之后再是用户体验问题（eg：日志检索，打开控制台，再关闭控制台，列表高度不会随之变化）
4、自己写用例的条数，明显下降，测试点没有少，反而多了，是因为开始关注系统的核心功能，用户使用主路径。
5、提测的时候，有验证问题，还是发到群里吧，总是默默的提单，领导们察觉不到验证性，总感觉压住了问题严重性。
2019-07-23
1、发现问题，若超过半天开发没有解决，还是要发到开发大群里，不要再私聊对应开发。
因为有的时候别的开发已经碰到过相同的问题，会直接解答，可以节省很多时间。
（从ULS开放云API，通过postman调用失败，此单得出的结论）?
2019-08-01
目前测试时，不像之前，严格按照用例一条一条的执行，而是知道了需求点，根据需求测试
最后在看一遍用例，看是否自己有漏测的，顺便更新用例。
2019-08-09
当提测延期时，或者在提测前先进行功能验证时，不能提单的情况下。可以excel中列出功能点，然后根据功能点测试，有问题直接补充到excel
最后的总结发到开发群里即可。
2019-09-15
测试前，有时间还是需要研究下 接口文档。知道页面调用的具体接口、入参、出参。 真的有用。此经验来源于-自助接入平台V1.1，被开发diss，只根据结果来at他，应该把过程都分析一遍。
提出的问题，若开发不想改，只要觉得合理，就应该坚持到底，不能妥协。 有些开发比自己年长，拒绝修复时，要心平气和的讨论，不能不给他面子。? 最终他们是会修改的。
只要怀疑是问题，那就有可能是问题。经验值+1 。刚才到mark位置看了，是因为cookie的命名有重复的，我这边修改下，添加上域名
2022-03-08?
临近上线，没有时间进行全量测试，莫要频繁动代码。
已提测，就不要频繁修改需求了， 用例和需求对不上，增加工作量。
开发的需求，有时需求对不上，若不支持，应该在需求评审、或者用例审批时提出来。
2022-08-01
一些逻辑很多在测试时才发现没有实现或者不通
该如何避免？（需求评审、技术评审、用例评审？）
开发自测，不能说因为造不出场景，没有自测
2022-09-08? 产品体验时反馈给我的
数据源修改密码后的影响，自始至终都没有考虑这种场景（大概是因为实例无法登陆，也不是自己的，没有权限也没有机会修改密码，所以无法考虑到）
当真是无法挣到认知水平以外的钱
2022-09-14?
上线要严格执行上线流程，开发一定要写上线步骤文档
上线后群里一定要反馈
上线后，相关开发最少要留下30min才能走
积极主动，越总结越成长！
在经验中总结经验，在总结中继续总结......