测试如何沟通和如何顺利通过试用期

1.测试工程师如何沟通
第一个话题：
报 bug 的礼仪：
A 同学说：开发你这个代码有 bug
B 开发的第一反应是：1.你的测试环境有问题吧；2.*****你会用吗。
出现这个问题原因大家心里都会清楚，你愿意会让别人贬低你么，或者是说你愿意让人挑刺么，比如
1，你写了测试用例，在大家评审的时候，很多人对你指手画脚的，你心里舒服不，
2：你花了很多时间搞一个东西，让你朋友过来帮忙，他不帮你，对你指手画脚的，你心里舒服不
如果你委婉的说：嗨！哥们，你这个程序和预期结果不一致，你过来帮我看看是不是我使用的方法有问题，还是数据搞错了。
他本能的会想，操，是不是出现 bug 了
说到这里大家应该心知肚明了，我们换种方式沟通，出现的结果不一样,第一种方式，粗鲁，粗鲁，粗鲁

第二个话题
需求沟通问题:
1，找别人沟通问题，是不是要知己知彼，百战百胜，很多学员上岗，需求都不了解清楚，业务也不清楚，这里说的不清楚是更改没仔细去看，明明需求文档里面提到的，写得很清楚，他就是不仔细，为什么这么说。
2很多学员学习时拿到需求文档，把需求文档从头拉到尾，从尾拉到头，不知道看什么，不知道提出测试点，不知道哪些是重点，只知道拉来拉去，到后面，别人写好了测试点，写好了用例，评审的时候，都不知道别人说的是什么，怎么写出这么多。
我想说的是，别人会读书，会思考，会抓重点，这个不是天生的，这个是后期养成的，遇到问题，他总想搞个明白，所以到了后面，很多人说，咳，跟不上了，其实，你跟不上，为什么不把你的问题记下来，下课时间多问，这不就跟上了么，然后再思考，当时我没做到这些原因是缺乏哪些，你要相信“天道酬勤”，这个我深有体会，我的地位，我的生活，都是我自己诚诚恳恳，一步一步踏出来的，不要怨天尤人。这个只是给大家一个建议，可以试着做下，摸着石头过河，一步一步，踏踏实实做好每一件是，我的名言是，要么做，做就要做好，要么不做，回家睡大觉，做了做不好，浪费时间，浪费生命，浪费金钱。

回到话题，你都不仔细去看需求问题，然后和别人去沟通，这不是找死的节奏么，以我的经验，我会这样想，
1，第一点。做一个测试，仔细认真基本功都做不到，需求上写的很清楚，很明白，妈的，还来问，第一次我客气点，第二次*的你飞起来，老子还有这么多需求分析，测试执行，***的天天问这些低级的问题。
2，第二点，你沟通的时候，提不出重点，好比，你说我这个不清楚，这个不清楚至的是哪些，别人就在想，这个业务的需求点这么多，你那个点不清楚，不可能要我从头开始讲吧，他只能说这个太多了，你再去看下，然后来找我，到了这里。

以我的经验，其实他不想和你沟通，不在一条线上，说的具体点，你如果说这个要写数据到 A 系统，这个写的点怎么写的，我不清楚，老司机，来带我飞一下（幽默点），这个别人就好说了是吧，沟通起来心情也好了。
这个说明，第一我们要仔细去看需求，一个一个字去看，第一遍不行，第二遍，第三遍不行，把还看不懂得地方记录下来，思考下，不行就找老司机带你飞，而且要找合适的时间点去找，不要每次遇到问题一个一个问，记下来，集中一个点去问，你永远要站在别人角度想问题，别人也要天天干活，要测试，不要打扰别人的思路，还有不要再浪费时间，因为给你需求分析就那么 2 天，不要**的去看第四遍，第五遍了哈！！，最后一天，老大问题分析完了没有，你一个屁都蹦不出来，那就尴尬了，还有就是分析需要，重要的前提是要熟悉业务流程，不熟悉业务流程的需求分析，那是流氓，那是扯淡。熟悉需求是测试在公司立足的根本，你不熟悉需求，不知道怎么测试，测试有遗漏，要你有个屁用。

第三个话题：
用例评审：
这个话题很简单，给别人指出缺点时候，不要他坦率，要委婉点，例如用例步骤不清楚，你应该说，美女，这个有点不太清晰，我怕后面的人不知道怎么执行，你补下好点，不然后面估计有点麻烦，因为你这是在找茬，在找茬，所有委婉点好

第四个话题-问问题：
很多新进去的人，有很多问题要问，记住，问之前不管什么，例如业务，我先操作一遍，遇到点记下来，例如，别人发给你一个样例，先自己分析下，别一看到就懵逼，自己先摸索下，执行到哪一步，卡主了，再去沟通，这个时候，你沟通时候应该要有技巧，例如，fiddler 抓包，你抓不到包，你应该沟通时候讲，我手机和电脑都在一个局域网，而且手机的的 wifi 手工代理也配置了了，我检查了一遍，ip 我是配置对的，就是抓不到，这个时候别就给你分析，那么应该是 fiddler 里面的配置有问题，他会告诉你问题出在哪一块。
如果你直接讲，我抓不到包，是什么问题，一个 fiddler 配置这么多东西，难道要我一个一个说，还不如我直接自己给你操作一把，给你配置好，配置好后，我会告诉你好了，其他的我懒得和你说，大家是不是遇到过，这个说明什么，和你沟通很费劲，费劲！沟通的时候，你要把你做过的，弄过的，自己确定没问题的告诉他，让范围缩小，减少沟通成本，记住了哈，要自己确定没问题，很多人，就是配置过了，你自己检查你配置的是否正确，然后就是一顿乱说，到后面被别人*，还有测试熟悉业务，什么都不是难事，你不懂，无非是不熟悉业务。

2.如果顺利通过试用期
1.试用期期间多加点班，加班不是做样子，既然留下来加班，就要有点收获，我们要在最短，最快的时间里面熟悉业务，去前台操作业务，不是只看不做假把式，只有熟悉业务，你才能在公司立足，才能活下去。
多看看老司机留下来的业务总结文档，然后发现有不对的，自己修改下，保存好，后面有人要得时候，你可以**了，你可以大声的说，这个以前他们留下来的，我刚来的时候看了，好多不对，我改好了，发给大家，以后可以用这个，是不是**了一把，是不是领导对你印象好很多，这个有么有，好比你们自习，留下来自习，留下来就学点东西，否则男人何苦为难男人，女人何苦为难女人呢
2.刚刚进公司，你不是大爷，你要主动去问，去要，要什么呢，第一天，你进公司你要你们所有测试需要的环境信息，把测试需要的环境搭好，什么xshell，navicat，接口jmeter工具等，前台地址，密码，数据库的用户名密码都要过来，把他们的总结业务文档，svn地址等都要过来。

第二天，如果没有搭好，继续，但是一般一天半就够了，然后就是熟悉业务，如果公司给你立马分配需求，记住，我们要把这个需求相关的业务总结文档，如果这个业务有以前用例，这次需求只是优化，那么也向老司机要过来这些资料，先操作一遍业务，再熟悉需求。
3.注意时间点，例如，你需求分析几天，测试几天，什么时候转测试等，到点要把工作完成，如果发现完不成的，要接到任务第二天和测试老大沟通，因为老大最痛恨的是，你接了干不完，到后面时间快完了才说，你耍我是不是，大家应该都有这个体会
4.如果****，你业务搞定了，需求搞定了，我们是不是没事做了，记住，把你需求，用例再看一遍，完善用例，精益求精，你一进公司接到的都是简单的业务，不是核心模块，你要赶紧把核心模块的业务熟悉了，还有你总有遗漏的地方，和低级错误的地方，排版好不好，语句通顺不，这个别人看了你的用例，能不能看懂等，实在不行，学习充电都要加下班，例如你开始进去要确定你后面主要负责哪一块，然后你在这一块赶紧充电，不忙也要忙的样子

5.做事要仔细认真，IT最多的就是文档，做任何文档，你要想清楚给哪些人看，排版，说辞等都要注意，任何事都注意细节，有些事，都是细节打败了你，因为测试基本功就是仔细，认真，注意细节，很多bug都是出在细节不注意的地方，很多领导注意细节，我记得我在公司时候，开会的时候，有个人从来不怎么发言，但是每次领导都会问他怎么看，有没有好的意见，好比狄仁杰问李元芳怎么看，但是你们想过没有，因为李元芳的稳重，做事仔细认真，每次探案能抓出很多细节，能够给狄仁杰带来很多利益，所有才重视他。希望你也能做你们公司的李元芳
6.对人要尊重，对人要感恩，态度要诚恳，踏实，也就是和睦相处，谦虚请教，踏实学习，你要自己每天问下自己，这些你今天做到了么，感恩就是，你问了老司机这么多问题，别人教了你这么多，别一瓶水都舍不得给，问老司机问题，他*你一顿，你要虚心接受，因为他没有义务教你，他的工资不是你发的，教会了你，饿死了我，所以教你，都是他对你的恩赐，不要记仇，如果别人教了你很多，应该请别人吃一顿，这个花不了几个钱，对于你后面的发展来说，那是九牛一毛。
我记得有个学员28班的，进去2个月，没转正，过年了，公司都给他发了1千多的年终奖，他拿这个年终奖给公司群里面发了200块红包，请公司项目组的人每人一杯咖啡，后面他在这个公司过的很滋润，别人愿意教，大家相处和睦啊，你尊重别人，感恩别人，你会有意想不到的收获。

1.接口性能测试流程
1-5是性能流程
1.接到需求，先把接口功能调通 参数化（常用的参数化方法），关联（正则表达式），检查点（我们要检查哪些），看需不需要集合,如果这个接口依赖上一个接口，那么这个需要用到参数的传递，看接口
需不需要用到cookie session等，请求头等
2.设置并发数和循环次数，线程组和循环控制器都有循环次数，可以用时间来控制，报错怎么处理，并发数太多了，如果PC机性能不够好，分布式部署（负载均衡）
3.查询接口的测试，要考虑db中表的数据量，一般保证10W左右数据量，造10W数据的目的是看这个查询sql语句有没有性能问题，插入数据使用存储过程造数据
4.我们性能测试最重要的是看聚合报告，聚合报告有很多参数，我最主要的是关注平均响应时间
5.结果分析（聚合报告，图形报告），分析的是报告，要看哪些指标
6-9属于性能分析，看哪些指标，怎么分析
6.看报告的同时我们还有看服务器的硬件资源使用情况，cpu 内存，磁盘读写，网络 nmon（收集服务器的资源使用情况）
top free （实时查看的命令，使用这个命令要边压测边看）
如果超过85%，要分析是哪一进程占用资源比较多，把进程名给开发，告诉开发占用资源（具体是哪一个资源）很高，改完之后我们要再压测一次
7.并发量很大（200），TPS上不去（平均响应时间上不去），响应时间比较长，但是app服务器和db服务CPU/内存都没上去（说明服务器资源很空闲，
代表我们的请求在排队，说明的的连接数太少了，（3种情况：1.db连接数，2.httpd连接数太少（apache中间件）,3.你的请求没有发送到服务器，这个
原因要么是你的pc性能不行，网络带宽不够））。响应时间长，可能是db连接池过小，导致线程等待时间长。
8.并发量很大（200），TPS上不去（平均响应时间上不去），响应时间比较长，但是app服务器和db服务CPU/内存/磁盘读写很大，很高,性能瓶颈出现在服务器硬件问题
要看哪一个进程使用硬件资源比较大，把进程名给开发，告诉开发占用资源（具体是哪一个资源）很高，开发分析下，如果开发分析不出来了，并发数往下调
看硬件资源使用率在合理的范围之内后，我们的并发数和响应时间是多少，如果客户一定要求200并发，开发也尽力了，经过多天的技术攻克，都搞不定了
只能和老板，或者客户说加硬件资源
9.并发量很大（200），TPS上不去（平均响应时间上不去），响应时间比较长，但是app服务器和db服务CPU/内存都没上去，查看过了，连接数都没问题（1.db连接数，2.httpd连接数）
排除PC机，网络，服务器资源都没问题，最终的可能，就是代码问题
把线程池从10~50，改成100~200后，响应时间缩短一半，在高并发的时候
1.做第一次压测 要保存报告
2.做性能调优（肯定是出了问题，才做调优） 比以前的报告的数据要好，服务器资源没有问题，在合理范围，就可以了
3.并发数，看你们公司业务使用情况，一般一个单个接口做80-100个并发足够了 响应时间快的0.几秒就返回，慢一点的是1.几秒
服务器都有两台的，注意：上面所述的硬件资源使用情况都需要看两台服务器的
APP服务器，数据库服务器
APP要调用数据库服务器,app要调用，数据库服务器肯定提供了通道，这个通道就叫做连接池

面试问题-测试流程
我们公司的测试流程是这样子的：
1. 我们的产品经理会提前1天把需求文档发下来，给我们看，熟悉熟悉。一般第二天会开一个需求澄清会议，要对需求的理解达成一致，以及弄清楚模块与模块之间的关联，产品经理还会讲解一下测试的重点。澄清会议之后，我们测试就会开个小会，主要是进行人员的分配和测试模块的初步分工。
2. 接下来就是编写测试计划，这个是我们经理写的。我们测试人员，会根据经理分派的模块仔细研究和评估测试需要多少时间。然后会开一个测试计划评审会议。主要是明确分工，确定时间进度安排，明确测试策略，测试风险分析。
3. 下一步就是需求分析。我们一般会用xmind罗列测试点。然后一般会开一到两次评审，主要是为了集思广益，确保更全面的罗列出测试点。
4. 然后就是写测试用例。根据罗列的测试点，写测试用例。一般都会有两轮的测试用例评审。第一轮评审完，修改完成之后，还再做第二轮评审。有时候还要根据第二轮的情况，决定还做不做第三轮的评审。目的是为了查漏补缺，让测试用例更好的覆盖测试点。
5. 接下来，下一步就是执行测试用例了。当然，开发要给到我们一个UT（user test）报告，我们才会开始测试的。先做一个冒烟，把主体业务流程跑一遍，做个评估，没问题的话，就开始执行测试用例：发现bug，提交bug，回归测试，以及写测试报告。我们是用禅道这个工具来对bug进行管理的。对bug的管理也比较简单。一般我们的bug是直接提交给开发的，他们修复完成之后，直接重新指派给我们，我们就做回归测试，通过的话就关闭，不通过就继续修复。
6. 然后就是写测试报告。我们测试人员，就是自己把自己的测试情况做总结。把留档的证据截图、自己模块的测试情况（发现了多少bug，修复了多bug，还有哪些没修复的等等）发给经理，他会做一个汇总。等bug修复完成了，经理就会把报告出出来。
7. 产品上线：一般会在半夜一两点的时候进行。因为这样的话就不会对客户的使用造成影响了。
8. 最后，我们会做一个测试总结。总结一下这个项目测试的情况，有没有遇到什么问题，下次应该如何避免，怎么解决等等。

第四问，接口是怎么测的:
接口测试的话，主要是对接口文档里的请求参数进行分析。一般请求参数的格式都包含有参数名称、参数编码、字段值（必选）、描述和样例等几个方面。比如说开户接口的其中一个参数，注册手机号。它的参数名称：注册手机号；参数编码：mobile；字段值：必选；描述和样例：注册手机号。这里面我们会对字段值和描述进行分析：比如说，它的字段值是必选，那么我们就分析，填写了这个参数，能否开户成功，不填这个参数，能否开户成功。另外还有它的描述是注册手机号，就是说这个手机号是注册时的号码。那么我可以分析，填我注册时的手机，能否开户成功；填注册时的手机号，但是这个号码，不是我注册的号码，能不能注册成功等等。这个就是我对请求参数的分析。
然后就是在工具上填参数，执行测试用例。
我们公司是在jmeter这个工具上执行的。在jmeter上执行的话，首先，要添加一个线程组，在线程组下面添加http请求和察看结果树。然后，根据接口文档，在输入接口协议，接口地址，请求方式，端口号。最后是输入请求参数，点击运行，查看返回值。

第五问
接口自动化测试：（参数化）
自动化是根据手工测试用例来编写执行的。
首先是录制脚本。我是用badboy这个工具来录制的。因为badboy录制的话，它会自动屏蔽静态资源，录制出来另存为jmeter使用的.jmx格式，就可以直接试用了。如果用jmeter代理录制的话，你要设置排除模式，排除静态资源，录制的时候还要设置浏览器的代理，比较麻烦。
然后是参数化。接口自动化最主要的就是参数化。比如说，注册这一块。一个手机号，只能注册一次，但是我自动化是不可能只跑一次的，所以就要对手机号参数化，让他自动生成不同的手机号来注册。参数化的方式，我知道的有用户自定义变量、正则表达式提取、从数据库提取以及函数助手四种。我用的最多的就是函数。比如说random这个随机函数，就说刚才注册那里，就可以使用random函数，先输入180然后接rondom函数，就可以每次运行都得到一个11位的随机号码了。
最后是结果检查。可以在响应数据里直接查看，但是这样就太麻烦了。一般都是设置断言。在断言里面，设置预期的返回结果，返回值。如果返回值与断言一致，断言显示绿色，表示通过；若果显示红色，就要看看自己设置的参数是否正确，如果正确，那就是用例不通过有bug。