以下是版本迭代的个人总结，总结不算精辟，几乎没有技术问题，不专业，算是自己成长的历程......

对于软件测试，最好的学习方法不是听课，也不是看视频，而是在有经验的专业人士指导下进行项目实战、发现问题、解决问题。

实战实战再实战！总结总结再总结！

1、用例的标题：一看标题，就知道自己的测试重点是哪个。

【若新来测试人员看你的用例，确保没有异议，并且别人看你的标题时 不用费很多时间理解】

2、写好用例要检查一遍，确保不会自相矛盾、不会出现低级错误。

3、对于第一次结束的产品，要多操作几遍，检查是否有遗漏的用例没有覆盖到。

4、测试用例算是我的武器，工欲善其事、必先利其器。

5、执行“测试计划”时，用例不需要点开看详情，就知道测试点，为最好！

【简洁明了又省时间】【导师常说：测试资源是非常非常宝贵的】

6、写用例要从底层开始写起，逻辑流程要先搞明白，按照流程的顺序写。

1、某一个功能多入口的情况；单条正常、多条也要正常、长度限制等等场景。

2、正常情况、异常情况（破坏场景下）。

3、功能与功能之间的关联性。

4、每一个“步骤”都要注意，可能出现的可能性。

6、拿到需求，不要着急测试，一定要补充和完善用例。

【在真正测试时，头脑可能是模糊，若用例提前设计好，就可以机器似的跟着用例测试】

7、基于python写自动化测试脚本， 根据tapd上的测试用例进行编写核心用例。

【以后写用例要加上【UI】【core】的标识】

【用例要简洁，一眼看出测试重点，为了写代码时debug，可以一眼定位问题】

【代码规范、代码步骤、api、封装包】

8、自动化脚本执行的时，创建的数据最后要清理。

9、重新发布版本后，先过core核心功能，基本核心功能不行的话，版本是需要重做。

11、掌握Linux的常用命令，不是去背，而是真正使用，放弃界面操作，直接命令代替。

12、放弃百度搜索引擎，首选google、必应。

1、关于测试环境代码是否是最新，需要再三确认。

    【开发虽可以自己合代码到环境，但每日构建可以会遗漏】

2、缺陷的回归验证，一定要等到每日构建完成后。

3、发现问题，要多测试几遍，保证不是自己眼花手抖后，再反馈给开发。

4、织云产品的业务一定要熟悉，哪怕是一些细枝末节。

    【关键字、专业术语、页面展示、业务逻辑、模块间关联、用户体验、思维扩展等】

5、织云用户可以小白，可以大神，测试人员也需要是小白，是“大神”。

    【切换不同身份对织云进行测试（不要怕把系统搞坏了）坏了可以修】

    6.1、刚开始第一次接触此产品，若不懂问同事们，同事们会理解；

    6.2、尽量不要有问题就去反馈给导师或者开发，大家都很忙，思维也不想经常被打断；

    【自己先研究下，若还是不理解或者阻塞问题，再去打扰】

7、测试用例：对于新的业务，不知道该如何下手，那就先从模仿师父的用例开始；

8、刚开始暂时不要评论产品设计的好与坏，博观而约取、孤陋而寡闻；

    【刚开始要学会认真聆听，带有思考的聆听，不想当产品的测试不是好开发】

9、照顾好自己的身体，不要生病；

10、不是自己等着开发完成后主动找你测试，需要的是主动跟进，这样就不会令时间太赶；

1、TCE功能相对少一些，但是基本功能还是要全面仔细的测试，不厌其烦。

2、多维监控写用例总结：

    2.1、多维监控，相当于新的产品，用例从零开始写起。

    2.5、多维监控分为四个模块：多维分析、数据接入、页面定制、后台管理：

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

3、做事要赶在导师前面：

    【eg：导师要审核用例，自己要提前把用例写好、检查好。不要出现一些低级错误】

4、正式环境，黑石需求的测试：

    4.1、在test环境测试几遍后，prd环境还是有一些问题，本来是可以避免的，还是自己不够认真导致的，用例的覆盖没有100%。

    4.3、刚开始先不要纠结于小的细节，先保证基本功能ok，在测试其他。

1、测试用例是根据原型图写的，开发完成后，需要更新完善测试用例。

2、核心功能：不单纯是 增删改查，还需要有产品的设计初衷。

【eg：新增了规则，记录中要有记录，屏蔽了规则，就不能收到告警】【这也是“核心用例”】

3、核心用例也就是整个产品的最基本的功能。

4、过一遍，意思就是 过一遍核心功能。

    【所以测试用例写的时候，一定要把 核心功能 设计好，设计完成】

5、测试问题的闭环思维【重点的重点】

1、对织云产品业务逻辑进一步熟悉

2、写的用例导师审核通过率有所提高

3、测试方法和效率的小提高，没有刚开始的手忙脚乱【番茄工作法】

4、总结学习该行业的专业术语，以及IT术语，写缺陷单不会太Low

1、在工作量比较大的时候，测试有时候会断片：

有的功能明明已经在第一轮测试通过，第二轮时发现新的问题，断片了，怀疑自己，所以合理安排测试计划。 【番茄工作法】

2、用例等级一定要划分好：高、中、低：

    【一轮测试，二轮测试，三轮测试时，可以筛选出不同的用例来进行测试】

3、模糊搜索：不止特殊字符、前后空格，还需要增加大小写的用例

4、产品体验的时候，自己也要去体验，更新添加测试用例（工欲善其事必先利其器）

5、测试问题的闭环意识：发现问题要及时跟进，一环扣一环往前推动，不管需经历多少人。

6、多研究下前端的专业术语 和 知识。

7、保持浏览器F12常开，出现问题可以马上查看Network、Console。

8、这次测试有点不完整（实例列表-高级搜索-搜索栏的删除图标功能有问题 XD），以后测试要把全部的按钮都点击。

1、本期主要的需求就是重构。

2、测试用例编写时间比第一期大大缩短（基本上用evernote写完大纲就可以着手写用例）

【刚开始借助XMind，先整理拆分需求，细化后开始动手写用例，要不然没有安全感】

3、本期测试时间较其他版本充裕，测试进行了2轮功能细测，1轮冒烟测试。

4、发现问题，先记录下来，复现成功提缺陷。复现不成功时，不阻塞测试就先记录下来，等待开发空闲查log。

5、积极推动项目进度，每天做测试进度给leader。

1、拿到不同的需求，先列出主要功能，汇总下，方便知道本次迭代的核心功能（类似每个软件的升级说明）

2、测试的时候，还需要看产品设计是否合理，用户体验是否良好（eg：体验优化，执行工具后的任务查询，应缩短访问路径）

1、发现问题，就要记录下来，不要觉得是开发没有搞好，环境问题啥的。提出来就对了。

2、特别是需要和第三方进行对接的场景下，第三方修改了接口，我们不知道，就会出现异常。

3、之前版本是ok的，现在不ok，就是问题，就需要提出来。不要怂，开发不是魔鬼。 

1、测试用例是需求评审之后写的，期间又接触了一些项目，开发阶段需求的修改，没有及时的修改测试用例。导致执行测试的时候，大部分是根据需求测试的。不能保证全面覆盖需求。

2、问产品需求、开发问题时，被别人说过3次：你的问题点在哪里？

3、缺陷单，能贴上复现链接就贴上吧。

4、系统与系统的数据对比，尽量是相同的参数进行。

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

1、经常看看别人的测试用例，简洁明了。

2、发现问题就是问题。不要老是command+r、f5（系统报错，就是问题。偶先也是问题）

3、首先关注的功能是否实现，之后再是用户体验问题（eg：日志检索，打开控制台，再关闭控制台，列表高度不会随之变化）

4、自己写用例的条数，明显下降，测试点没有少，反而多了，是因为开始关注系统的核心功能，用户使用主路径。

5、提测的时候，有验证问题，还是发到群里吧，总是默默的提单，领导们察觉不到验证性，总感觉压住了问题严重性。

1、发现问题，若超过半天开发没有解决，还是要发到开发大群里，不要再私聊对应开发。

因为有的时候别的开发已经碰到过相同的问题，会直接解答，可以节省很多时间。

（从ULS开放云API，通过postman调用失败，此单得出的结论） 

目前测试时，不像之前，严格按照用例一条一条的执行，而是知道了需求点，根据需求测试

最后在看一遍用例，看是否自己有漏测的，顺便更新用例。

当提测延期时，或者在提测前先进行功能验证时，不能提单的情况下。可以excel中列出功能点，然后根据功能点测试，有问题直接补充到excel

最后的总结发到开发群里即可。

测试前，有时间还是需要研究下 接口文档。知道页面调用的具体接口、入参、出参。 真的有用。此经验来源于-自助接入平台V1.1，被开发diss，只根据结果来at他，应该把过程都分析一遍。

提出的问题，若开发不想改，只要觉得合理，就应该坚持到底，不能妥协。 有些开发比自己年长，拒绝修复时，要心平气和的讨论，不能不给他面子。  最终他们是会修改的。

只要怀疑是问题，那就有可能是问题。经验值+1 。刚才到mark位置看了，是因为cookie的命名有重复的，我这边修改下，添加上域名

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

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