不是要过年了嘛，最近流行一句话“新年第一锅”，可以想象我们QA的处境了吧。
尴尬又不失优雅，我觉得还是踏实写完的的总结吧。比较笨，但是相信走稳每一步的流程，“锅”不会从天而降的！
- 第一趴
这是个必不可上少的起点，从本质上说，这是起定型作用的环节，在开产品需求会的同时，QA就应该站在专业人员的角度分析产品的可行性与风险。毕竟从
在源头上掐断问题比最后测试时花的代价要小的多很多。
起初在这样的会上我只是充当倾听者，原因很简单：
相信产品的经验（其实是狗屁，现在产品要求越来越低，专业技术不过硬）；
认为自己能考虑到的问题还不如“他”呢，觉得做好记录，到时候测试的时候更清楚就行；
再有就是“小罗喽”嘛，在会上不敢表达自己；
后台发现这样还真不行，到时候坑的还是你自己，因为会上没有提出的问题势必会在测试过程中发现，遇到层层阻碍，这时候还是要跟产品去沟通。经历了
几个月，也是相互熟悉了，知道双方都几斤几两，之后的需求会，都尽量去听而且仔细听，有疑问当场提出来，毕竟在场的有领导有开发有各组老道的人，对于
QA提出的问题更能发现本质。
这是写给开发的，他们需要时间来完成需求。设计、前段、客户端、服务端、算法、后台虽然开发的先后顺序不一样，但是都有个联调时间。其实我的困惑
就在这，这个阶段QA需不需要参与进去？能起到什么作用？困惑点卡在自己代码技术不行，好吧是自身的问题。我理想中的QA大牛是可以直接在这个阶段发现
问题的，直接从根上（代码）指出问题所在，减少开发时间。本来嘛，测试就是为了减少开发时间而存在的。
这个阶段跟开发时间基本是同时进行的，因为“提测”了就要开始测试了。你拿什么测？从哪测起？测的全部全面？都是取决于你的测试用例。
一份好的测试用例真的能大大提高测试效率，也能保证测试质量。相信大多数QA人员都是使用的Excel，但这里我们使用的是Xmind，更加简单明了。比起许
多公司要求的测试用例要细致，第一步...第二部...最后...让一个没有接触的人也能看懂也能执行测试，我认为真的没必要。完整写该写的部分就很好，我是客户端起
步的QA，更是偏重软件APP测试，几个关键点，大概就是：
-
包括入口
-
针对用户（满足条件）
-
功能实现流程
-
新功能影响点
-
Y/F情景结构
-
...很碎的东西一一记录
（2）异常场景；
-
需求功能可能出现的异常场景
-
断网
-
切后台
-
杀掉进程
-
Wi-Fi与4G等切换
-
包括iOS与Android交互；
-
iOS9，10，11，12系统兼容；
-
全部机型适配；多语言适配；
这个真的是根据个人习惯，毕竟是你负责的测试项目主要是你自己看。这里就要谈到一个“用例评审”的事了，完整的流程这也是主要一环。我们公司不
太兴起这个，刚入职的时候会有带的人帮忙修改下测试用例，但也就刚入职那会，之后就不再有了。但我们提倡根对应开发对测试用例，为了节约时间，直接
把异常场景给开发评估，看是否有遗漏的地方，也可以在写用例的时候根开发一起口头对需求流程，既是帮开发review一遍也是我们自己梳理一遍。
前提，这是个新需求，功能点很大。
参会人员有讲究：需要产品老大、相关开发人员、测试人员、反馈（技术支持）甚至是运营相关知情人。
展示方式也有很多种，因需求而异。简单做一个PPT，讲解需求规则及“玩法”，最简单的就是直接安装测试包，人手一个手机或PC直接体验。会议是有节奏
的，很是考验QA的演示能力了，开始如何吸引人、如何讲述的简洁明了等，都需要会议前准备完整。
这个环节是我工作之后为了敏捷开发提出来的，有过2次调整！
最先是在产品上线的前一天进行showcase，也就是测试完成、bug修复之后，但这里有一个缺陷就是，产品及相关需求人不知道最终展现的具体效果，施行
过2次，发现showcase会之后总有一堆问题需要调整，甚至整个需求直接被产品老大给否决掉了。这样轻则耽误发版时间，重则开发和测试的努力全白费了。所
以之后又改成开发只要“提测”了，就开showcase会，这要减少了测试的压力，还能督促开发提测。
开始实行这个流程是艰难的，需要每个组的负责人配合，推动起来相对缓慢，当然这项任务由QA推动是最合适不过的。
可以说这个根showcase是前后脚的关系。在showcase过程中需要小伙伴陪同展示，一个人负责记录会议上提出的问题和建议，整理成文字；在会议末尾大家
补充完全。特别注意⚠️每个点落实到个人具体来跟进，不然这个会议就没有意义了，进度还是推进不了。该是产品的问题就需要他们修订需求，该是开发的bug会后
立即修正，该是运营人员线上配置环境立马部署；大家一起体验（特别是有各老大在场）需求，比仅是测试人员来验证要完美的多！
当然这一环不需要追求细节，毕竟还没有进行具体测试。
这个时候需要根据showcase会议完善测试用例。
说到测试用例，一般用Excel我们用Xcode。边测试边完善，条理清晰有助于测试也能看出一个QA的水准。
就是一句话“不要留情，有bug尽管提”。
这个过程的流畅性，测试效率就取决于你对需求的熟悉程度，测试的覆盖面也根据你的测试经验来；（手机端测试）刚开始只是发现界面bug、适配问题比较快；
这是有缺陷的，严重的bug发现晚开发修改也就延后了，一环一环上线时间也就耽误了。
平时最多的还是没有showcase的需求，如是需求上线的时间真的在你！
-
首先“冒烟”测试，排除阻碍问题；甚至是将提测打回；
-
需求逻辑优先验证，最先发现代码深层的问题；
-
最后才是追求细节问题；
-
bug记录工具--TAPD，这是我们的工作量也是以防忘记；（我是这样提完根对应开发微信讲一下，解决更快）
提bug也是讲究技巧的。描述问题更加简洁明确、配置操作步骤、附上问题截图；必要时描述环境（条件）记录和日志时间。最喜欢的是毕现的bug最头疼的是偶现bug，
前者开发很快就能修改，后者真的是麻烦需要想方设法复现问题步骤，每每都是最后再解决耽误上线时间。
需要注意⚠️不能放过任何一个bug，毕竟是手工测试，一个人无法发现所有bug，总会有遗漏。
提bug因人而异。有的开发不喜欢看TAPD、有的开发有自己的工作节奏，有的甚至不喜欢你提bug给他，QA需要根据每个人的习惯特点完成工作。记住一点，效率！
每日汇报测试进度。这个是老大们想看，也是很有必要的，预估需求上线时间、老大们敲定是否跟版等。。。
承接以上，为了更有效率的工作，沟通艺术真的需要加强。
沟通要及时。
交流要到位。
微信交流方便但不如当面沟通清楚，有时候真的需要当面问清楚，切记不要因沟通失误带着问题上线。
其实也不仅仅是跟开发沟通，在测试过程中要根所有相关的人沟通。我们通常每个需求都有一个群，推动不了的问题就丢群里，大家都是要面子的，谁也不想
问题卡在自己那。
线上也是经历过失误，一个活动上线第一天有问题暴露出来：榜单里没有数据。修改了，但是到第二天活动第二关卡又出了问题：榜单上数据没有更新。查原因：
这个需求是运营提出来的，他人在美国，测试和开发人员在北京，没有交代清楚、查需求文档上甚至没有规则说明，这个时候就有理说不清了。按理这样的需求应该打回但是没有，
反而还上线了，虽然问题不在测试但最后的锅就是我们的，所有要时时刻刻保护好自己，不要因烂的需求而坑了自己。这样的例子在这一年里大大小小都在上线，只是暴露的严重
不同，索性我接的需求没有。
这个过程很爽的，一个一个关闭bug但又是因开发而异。
目前的接触的开发都有这个问题“改出新的问题”，只是量的多少问题。原因很简单：
要么，这个需要不是同一个开发做的，改起代码来难免不知道影响范围；
要么，粗心大意，以为解决了也没有自测，其实并没有改好；
要么，真的是意外，上错代码了！！
要么，只是临时的修改并没有真实解决；反正都有坑，我自己掂量吧。
有些需求要线上验证，确保线上环境满足、配置正确、功能正确、奖励正确等。。。
针对每周迭代的版本，少不了要回归测试。
只针对改单个需求时，由于开发和测试工作是在分支上完成的，最终上线的是要合并到master主干的。在分支测一遍后主干需要再来一遍。这个流程被每一个开发和测试吐槽过，
但是始终没有两全其美的办法。我们是每周迭代一版，为了保证上线时间QA会卡需求，没有测试通过的是不允许合并到主干的，所以一般都是在分支开发。若是本周需求都在主干开
发，免不了相互各自影响，难以定位问题。自古忠孝难两全，开发测试也是很难善终。
说到这个回归真的很头疼，避免不了也省略不了。回归用例需要及时更新，用例的详细程度也需要考究，毕竟不能所有需求再测一遍，越来越多回归的点，真的讲究效率。原则是
线上不能有崩溃，保证常用功能点没有问题，一级二级界面的点击没有问题，登录注册、开播连麦、游戏等一定不能有问题。
我们整理过一个“踩坑集”，记录每次耽误上线的需求、线上反馈的bug；回归测试都会把它翻出来验证一下。
回归测试一般在上线前一天，先完成自己需求的可以先进入回归，分工合作有助于提高效率。
我们是看不出细微的差别，但设计不同，前端页面是他们做的，一眼就能看出哪里需要调整。有一次设计图的问题，4个档位的礼物竟让弄反了，双端的开发以为这是正确的，我们
测试交互时也没看到差别，产品也认为本应该如此，最后还是一个QA同事在看H5的规则说明的时候发现差异。由此看来设计走查还不能是一个人完成，得产品和设计同时在。
终于上线了，可以松一口气但是真正紧张的时刻也来了，毕竟只是测试环境测试通过，模拟总与线上真是环境、用户有区别。也需要观察线上数据，结果是否满足预期。很多需求
不止一期，根据数据进行后期修订再完善。