把BBS的文章拿来总结一下。有的公司很正规，不须要测试直接同开发人员进行打交道。可是对于规模较小的项目团队或者处于起步阶段的公司里面的测试人员来讲，与开发打交道是一件不可避免的事情。面试
当处于这种情况时，如何和开发打交道更多的是一个沟通的技巧。工具
超越自我says:学习
首先,要确保本身能重现BUG的过程;(要真正能模拟到该问题的存在)
其次,要将系统出现BUG给用户带来的影响要逐一解释和说明,让开发人员真正了解问题的所在,也节省开发人员的时间,
并分析系统存在瓶颈会引发更多问题,
再次,也要分析修改BUG后,将会带来什么问题,用户是否可接受?并要把修正BUG所引发的问题减小,
而不是增长另外的BUG,而经过本身对系统的熟悉程度,开发人员
也会对测试人员提交的BUG引发足够的关注度和重视,从而让BUG完全解决,
最后,经过开发人员对BUG的修正,本身也进行一次回归测试,让开发人员以为测试人员是对质量的负责,而不是针对开发人员,以便利于下一次问题的提交和修正!
总之:测试人员是对产品质量,而不是针对某一我的,并且也要把BUG及时提交,不要错过提交BUG的最佳时间,
由于BUG越不解决,积累的问题越多!
因此测试人员要对发现BUG要有信心和足够的时间重现BUG,让产品更具备质量性!
测试
maguschen says:搜索引擎
1.把本身的Bug Report完善；有时候开发看到一些莫名其妙的Bug Report会很生气，这样首先就影响了你在他心目中的印象，要让别人改正，首先要保证本身是正确的、完善的。
2. 对事不对人；找开发的时候应该针对具体的问题，能够用“咱们的软件出现了这样的问题”，而不要说“你这里写的不对”。
3. 摆事实；对于具体的bug，能够给开发说明一些事实，例如某个样式问题其实十分影响用户体验。
4. 挖历史；若是之前有相似的问题，能够把那个问题，以及形成的后果给开发阐述一下。
5. 平时跟开发拉好关系
6. 把更高层的人拉进来；不少时候都是公说公有理婆说婆有理，这时候就须要一些第三方的同事来帮忙，这我的一般要是能说事的才行，例如研发总监或者项目经理，可是主要不要让人以为狐假虎威的感受，这招不适宜常常用。google
男孩子 says:[正规的公司作法:]编码
感受之因此提出这个问题，是由于公司的体制根本就不完善。
测试人员的职责是测试，研发人员的职责是研发，测试人员提bug，研发人员改bug，谁赋予了测试人员去督促研发人员修改bug的权利了？测试人员又有什么义务去督促研发人员修改bug呢？
以前跟一个在NEC工做的哥们聊过，在他们单位，测试人员是不直接跟研发人员打交道的。测试和研发中间有个中间角色，咱们暂称其为bridge。测试人员的bug提交给bridge，bridge鉴定其是否为bug，是bug，流转给研发，不是bug，驳回给测试。一样道理，研发人员若是reject，也是由bridge与其交流。固然，bridge不是随便抓我的就能够当，级别得至关于“技术总监”吧。
固然，目前接触的好多单位都把这个角色省掉了。一个产品或者项目的测试可能总共也就2-3我的，怎么舍得派这么个大牛给你们呢？因此题目描述的问题又是一个不得不面对的事实。
从个人经验来看，出现这样的状况一般不是一些重要的bug，因此测试人员应该尽可能将本身的bug描述的细致清晰，而后将bug转交给项目leader处理或者留在评审会时讨论，而不该该跟研发人员在这个问题上作过多的争论，这样一来耗费时间，而来会影响在后续工做中的合做。
研发人员由于在开发技术上的优点，经常会对测试存在必定偏见，测试人员应该可以认识并理解这一点。spa
乐游 says：设计
若是我认为这个bug更多的是从技术角度考虑，须要修改的，那么我会把SA引入到对这个bug得判断上来，由SA决定这个bug是否须要修改。
若是我认为这个bug更多的是从用户角度考虑，须要修改的，那么我会把CS引入到对这个bug得判断上来，由CS给出这个bug是否须要修改的建议。
最后，若是说这个bug得发现是在项目的敏感期（大部分都是项目后期，接近release的时候）f发现的，那么我会直接找到PM，告诉PM这个bug得相关状况，而后请PM决定是否须要修改这个bug.索引
sun_0910 says:
1. 扭转研发领导的思想，提升研发人员的响应速度：
a). 让研发团队的领导重视缺陷：
不少研发团队的领导都是销售出生，懂技术的不多，他们和搞技术的想法明显不同。我在的第一家公司，发布版本时不少时候，都是没有测试结束，功能开发的差很少就把产品卖掉了，后面再对版本不断升级，结果这个公司没多久大概3年不到就散伙了。后面一家公司的领导是作质量管理出生的，明显对测试的质量要求就不同，每次要求都特严，对之前测试结束标准都作了进一步的修改。若是领导对缺陷都视而不见，你说研发人员还愿意花大量的力气去修改Bug吗？因此说，团队的领导的想法或意识，对缺陷是否修改起到很是重要的做用。我记得之前测试高手zhuzx也在每周一问中提到过，你们也能够借鉴一下。
b). 采用经常使用的缺陷管理工具（QC9.0），提升缺陷的透明度：
咱们公司使用缺陷管理工具（QC9.0）,测试经理任管理员，给公司高层领导、项目经理、开发经理都分配了权限，本身能够登陆系统查询相关信息。在测试后期，特别是要发布版本先后，领导们一有空，也随时上去浏览一把，无心识给开发人员施加了较大的压力。若是这个时候还有不少Open的缺陷，开发人员天然不敢怠慢。
c). 把开发人员的修改缺陷的响应速度，记入绩效考核内容：
因为公司总监特别关注产品质量，咱们公司对缺陷修改这一点作得比较好，每次都是递交缺陷之后，开发人员响应特别快。若是有疑问，就立刻和测试人员一对一交流，尽快修复或解决该缺陷。 咱们公司的口号是：“宁愿花出100倍的代价，也不让发现的缺陷留给客户”。还有一点就是开发人员绩效考核的时候，咱们测试人员要给开发人员打分，很重要的一点就是：开发人员对测试缺陷的响应速度，若是这一项很低的话，老大要找你谈话的，问具体缘由是什么？呵呵。因此，咱们公司不多有测试人员追着开发修改缺陷的状况，把修改缺陷的响应速度归入我的绩效考核，我我的觉的是一种比较好的方式，值得借鉴或推广。
2. 组建一个合理的研发团队，规范测试规范：
a). 关键是创建一个完善的研发机制：
在大多数状况下，是否是软件缺陷或者需不须要修改，怎样修改不是测试人员和开发人员说了算的，应该是靠研发部门的相关制度或相关部门去约束。毕竟在国内软件的软件企业缺乏这样的部门，因此说把修改缺陷相关的重任推到了测试人员的头上，其实对测试人员实在是太不公平了。要解决这个问题，最关键就是创建一个完善的研发机制，让QA等相关部门督促解决这类问题，比较好。
b). 分清团队成员的具体责任：
对于研发团队中的每一个成员，必须责任明确，不然像督促缺陷修改这样的事情原本不是测试人员的责任，如今都推到测试人员头上了。很郁闷！！
c). 完善测试规范，明确Bug管理制度：
大部分的公司，都没有单独的部门来单独管理督促缺陷是否修改，都默认为是测试部门的事情。我的觉的最好是赋予项目组中相关人员必定的资质，让他们去处理这些杂事。常常碰到这样的状况，不少争议的缺陷都一直放到后面一个版本，一段时间下来，几个版本争议的缺陷就多于100个，弄得后面版本也很差发布。咱们的作法是，发布前几天，对每一个争议的缺陷用邮件先发给项目组成员先看，后面在召开缺陷评审会议，若是经过，毫无疑问修改，不然关闭或保留到下一个版本。
3. 从源头上杜绝无效缺陷的递交：
a). 测试前细化测试需求,避免递交歧义缺陷：
不少研发不肯意修改的缺陷，大部分都是因为需求不明确或者理解歧义引发的。因此，最好的作法是在测试之前，开个项目会议，细化一下测试需求，让研发去确认或项目组成员集体Review，达成一致观点。尽可能减小理解上的歧义，力争尽早消除无效或争议的软件缺陷，避免递交的缺陷成争议的缺陷。测试人员没法说服研发，让研发去修复缺陷，长期这样，测试部的威信就大大下降了。
b). 把握不许的缺陷，递交之前最好讨论一下：
特别是在测试初期，因为测试介入项目时间较短，有时候测试人员对业务或需求了解不深，递交错Bug也是常有的事情。这个时候，每每测试认为本身递交正确了，开发人员认为本身开发软件是对的，各执己见，若是处理很差，很容易弄僵关系，弄得你们都不是很愉快。要是项目中出现这样的Bug，是很难说服研发去修改的，还有可能成为研发抓你的“小辫子”的有力证据，要是这样之后就更难作了。我的的一些作法：全部的测试缺陷相互审核后，才递交到缺陷系统上公开，是最为保险的方法。
c). 清楚无歧义的描述Bug，减小随机测试，带来不可重现的Bug：
不少时候，测试人员把缺陷描述不清楚或者缺陷有歧义，开发人员看不懂，不明白具体的意思，加上开发人员任务重时间紧，很容易产生逆反内心，这就让开发人员对测试人员有见解，之后递交的缺陷承认度就大大下降了。还有就是要减小随机测试，必定要保证递交的缺陷可以重复出现，最好要有截图、图片或者用数码相机照下来，让开发人员认识到这个问题确实存在，而且更具说服力。
d). 作好版本配置管理工做，保证测试环境的准确性：
不少同事发现的缺陷，只有在测试环境下重现，而在开发环境下不可以重现。这样的缺陷开发人员每每是看不到的，他们很容易得出结论，说测试人员递交无效的缺陷而被拒绝，大部分状况发现是版本弄错啦！！咱们惟一能作的就是作好源代码的配置管理工做，保证测试环境版本的正确性和独立性，本身编译本身部署测试环境。只有这样，才会减小无效缺陷的递交，避免“费劲周折”说服开发人员修改缺陷。
4. 正确分析测试中的软件缺陷：
a). 为递交的每一个缺陷准备几条充足的理由：
通常状况下，咱们提到一个Bug时，开发人员都会说出不少能够不修改缺陷的理由，尽可能搪塞住咱们的口，要求咱们关掉缺陷或者置为无效或者延期到下一个版本。若是你很牛，你能够为本身递交的每一个缺陷准备很充足的理由去说服开发人员；若是你不是太强，那就能够求助部门同事，集中测试部门团队的力量，想一些好的、站得住脚理由，详细介绍给研发人员听，只要咱们递交的Bug，每一个都具说服力的话，我想他们也会尽快修改的。这种方法还真是不错，你们不妨试一试。
b). 详细分析缺陷给项目带来的各类可能影响或缺陷风险：
好比说，咱们递交一个缺陷，若是研发的觉的这个缺陷能够修改或能够不修改时。咱们必定要给研发分析修改这个缺陷的必要性，不修改，对客户带来哪一种可能影响或存在哪些风险。要在修改缺陷的代价与修复成本的关系上去衡量。相信，当咱们对缺陷分析的很详细时，研发人员必定会修改Bug的。
5. 作一个聪明的测试工程师：
a). 注意和研发人员的沟通技巧：
若是测试人员没有作过开发工做，理解也许就比较片面。有的测试人员，对待问题没有耐心，性情比较急，也是常有的事。若是没有较好的沟通技巧，也许就是几句话的功夫，就和同事争吵了起来，弄得你们都比较尴尬。我的建议：谈话时，要注意沟通技巧，要有换位思惟的方式，作事情对事不对人，处理事情必定要有一颗宽容的心。只有这样，才可以很好的说服研发去修改Bug。
b). 和研发人员搞好私人关系，作研发的听众：
比较明智的测试人员，必定要学会倾听研发人员的心生。不少时候，开发人员碰到工做困难的时候，很但愿和人倾述，若是测试人员是他的听众，那么大家的关系必定会不错。搞好了私人关系，工做中你递交的缺陷，他们就不会那么斤斤计较了，毕竟关系是基础，关系好了好说话呀，在中国就是如此。若是私人关系好了，说服研发修改Bug就是很容易的事情。不过得提醒一句：不能由于关系好就把Open的缺陷给关了。
6. 抓住时机，不要错过百年不遇的好机会：
a). 求助公司上层领导：
不少时候，测试到后期，开发人员把缺陷也修改的差很少了，公司领导（好比说老总、总监、项目经理或开发经理）就会随时来测试部门，找测试经理或负责人了解项目测试的具体状况。若是有一些问题都是争议问题，做为测试Leader的你不妨给领导聊聊，把更高层的人拉进来为测试部门说话，为测试部门撑腰，可是凡事都有一个度，不能太过度，不然很伤同事的和睦。
b). 要求客户表明援助：
不少GUI的缺陷或可改可不应的缺陷，可能做为客户使用不是很方便。咱们能够和客户表明聊聊这样的缺陷，若是客户表明赞成这样作，那没问题，能够不修改；若是客户不一样意，他天然会直接找项目经理或高层人员协调解决这个问题，这就不用咱们测试人员操心了。由于客户就是上帝，这招不错吧！！！
yetties2005 says:
本身的BUG要定义明确.告诉本身那是个BUG.跟开发谈的时候别人家一说什么你就想这究竟是不是BUG啊,是否是本身错了.千万别有这样的想法,就算有,也不要在跟人谈的时候出现.还有就是经过需求.说明BUG不改客户是不能接受的.在就是像前面所说的.要软硬兼施
coffeg says:
据我我的的经验主要是下面几点：
1.bug自己的质量。这个很是重要，若是是严重的bug不用去说服，研发天然会去修改。
2.bug会产生的影响。这个考验测试人员的功力了，并非要夸大bug的严重性，而是你有没有比开发看得更远。比方说是一个验证框颜色的bug，开发认为可改可不改，但你若是能说出若是用户是色盲就没法看清楚，也就没法登录，进而没法使用咱们的服务，并且中国色盲的人数是多少这么一报，那么他确定得改。
3.对本身的能力的认同。须要说服的bug自己就存在争议，确实也存在可改可不改的bug，你若是认为确实须要改，就必定得坚持，找到充分的理由，而后在评审中一击必中，确立本身在研发心中的形象。就是说你发现的bug基本上在评审上都须要回去反工的，之后不用你本身说，他们本身就会去改了，也不存在什么说服了。
4.提高本身的能力。若是说前三点是技巧，最后一点可就是基础。开发人员和测试人员都是这样子，双方都有一个比较，让他们以为在测试这块你就是权威你的能力起码不能比他们差，就算是没参与编码也须要一看就知道大概是他们会是怎么作的，经过少数几个问题便可知道问题容易产生的地方。
总的来讲我我的以为没有说服的bug，主要看你是否有充足的理由，和合理的方法。固然公司的评审制度也须要有，没有这个话彻底靠测试我的是不行的。
吴如领 says:
让开发心甘情愿的修改BUG，咱们能够从下面几个方面来考虑：
1、为何定为BUG
- BUG描述------测试员在提出BUG时，要注意对BUG进行必要的描述，例：BUG出现的环境、出现该BUG进行的操做、预期结果和实际结果、BUG出现的概率，若是使用的BUG管理工具的容许，能够对该BUG添加一些附件：截图、脚本等，Jira、Lotus好像均可以添加附件。一方面增长开发对BUG的阅读、定位，另外一方面能经过有利的论据证实该问题是BUG
- BUG复现------提交BUG后要保证BUG复现，这样在项目经理、测试经理、开发人员争论BUG时，能强有力的证实该BUG是存在的。
- BUG依据-------理论上，产品中不知足用户提出的需求就能够定为BUG，这也是测试前期进行需求评审的缘由。可是，目前不少公司的软件项目对其中的细节描述很不具体，致使了开发与测试关于BUG的歧义。在定BUG的时候咱们能够本着这样一个原则：和当今流行产品作对比，好比说公司在作个搜索引擎，开发将搜索引擎的位置放在页面的底部，咱们就能够说这是一个BUG。理由很简单，百度、google的搜索框都在页面的上部。
2、测试经理对BUG的认同
- 测试经理的经验-----测试经理通常来讲都是工做几年，有至关丰富的项目经验，我公司测试人员提出的BUG，一线的测试经理都要审核，审核经过才转到项目经理，这样避免了因为测试员工做经验不足和我的主观意愿致使BUG错误认定的状况。
- 测试经理的信赖-----测试经理对BUG认同后，也就说明了该问题是BUG，在后续的争论中不会出现测试经理搪塞的状况，对测试人员也是很是有利的。
3、有效的沟通
- "牺牲色相"-----该方法要求测试人员为了工做，主动和开发创建良好的关系。譬如：请开发吃饭等等，这种方法最有效，也是百试百灵。但我的不建议这么作，工做就工做，耍手段是很差滴。
- "良好的同事关系"----这种方法要求测试和开发平等的地位，测试要本着"个人工做职责就是让软件运行的更好"，经过合理的沟通手段，让开发能认同本身的观点，并进行BUG的修复。不要由于本身对技术了解不如开发深，就不敢提问题。
- "强调BUG的影响"----沟通中提出修改BUG带来的好处，不修改BUG将要致使的问题，让开发明白问题的严重性。那怕是用户体验的BUG，也能够借助用户的场景，说明修复BUG的必要性
4、利用身边的资源
- 上级领导-----借助测试经理和项目经理，有时候我的不能协调解决的问题，就不要逞强，让测试经理和项目经理来协调，切忌不要悄悄的在项目经理面前说开发的坏处，你们都是打工的何须呢，何况不必定能起到做用。要记住--本身找项目经理和测试经理是协议矛盾的，解决问题的。
- 部门例会-----不少公司，每周或每个月都会进行部门例会，方便各个部门间交流沟通，能够由测试经理反映下最近测试状况，测试员发现多少BUG，开发修改多少BUG，遗留多少BUG。若是经过公司的运营了解到，用户也出现了遗留BUG中的问题，那更好。经过数字让公司认识到测试的重要性，那么之后BUG的修复工做就更好进行。
- 公司制度-----在国内之前测试员的绩效考核每每是有开发组长来评分，如今不少公司都作到，经过测试发现的BUG数、BUG严重程度来衡量开发人员的工做水平，这也能促进测试工做的开展
- BUG管理平台------目前，国内对BUG管理平台的使用还不成熟，我的见到过口述BUG的、纸制BUG单等等，我的不赞同这么作，口述BUG和纸制BUG单保留时间有限，对于有本身产品的公司，历史的BUG颇有参考价值。肯定BUG时能够拿出以往的BUG库作参考。
总结，我的只提出一些实际工做中的经验，也建议你们在工做中学习，不要只看大道理，在特定的环境中掌握的技能才是根本。呵呵，以上是本身的一些想法，但愿你们都提出宝贵的意见。
fairy_lu says:
我认为，测试人员应该很明确的记录这个bug，而后查看设计中是否有相关的设计，若是是设计中有而开发人员没有实现，那么就拿着设计文档和开发人员谈。若是设计中没有，就看需求中是否有相关内容，若是有就要找项目经理来看，是否是须要在设计中加入这一块内容。若是需求中都没有，可是测试人员仍旧认为是一个bug，那么就应该找项目经理谈，由项目经理决定是否确认其为bug，是否须要修改。总之，不可以随意放过任何一个测试出来的bug，也不可以和开发人员弄僵关系。咱们应该让他们知道，咱们作的一切都是为了项目可以更好的完成，并且就算咱们找来项目经理讨论，不是打小报告，而是找来比较权威的人士来作决策。
zengyixun says:
因为我作过两年的开发，5年的测试，在测试过程当中，本身也作过些测试工具，也有测试人员对个人测试工具来进行测试的经历，因此我首先站在一个开发人员的角度来看，什么样的bug与测试人员能说服我呢？要说这个问题，咱们首先要有有一个假定：假定开发人员不是一个神经病（多数其实都不是，若是是，那么应该由人力资源部负责），既然开发人员不是神经病，那么你必定要相信他对于本身所作的模块也是抱着认真负责的态度，但愿把功能顺利实现，而不会出现什么意外情况的，因此当有人给我提出一个bug是我确实没有想到的，而又实在的影响到这个模块的功能，我作为一个开发人员会考虑修改这个问题。
若是这个问题还有一点点深度，我会更加开心，抱着挑战的态度，也抱着赶快把此功能搞定的急迫心情去修改它，由此获得一个好的绩效与认同，因此像这样的bug，须要测试人员来讲服我么？固然不须要。而后再看看什么样的问题我不喜欢，曾经我作过一个测试工具，新来的测试人员对个人工具进行了测试，在测试的同时，也使新人学习了各类业务知识，在这些测试者中，我就很明显的对那种能提出功能性错误，或者我考虑不周形成的错误（这必定要用专业的测试方法才能测出的）的新人，我会报着一种对他的欣赏的态度去修改他提出的问题，而对那些，没事找事，老是按本身的主观意愿提出一些使用上问题的人，给以鄙视，好比新来的测试负责人，在我修改完全部问题后，叫我把下拉框改为tab页，嘿嘿，你喜欢tab页，我就喜欢下拉框，测试部难到没有别的事情作了吗，作这么无聊的事，也就是说，有关操做习惯问题本就是你有你的习惯，我有个人习惯，凭什么就说你的习惯是表明了广大人民群众呢？是吧？
看了上面一段，相信你们就知道了什么样的问题会获得认同，这样的问题，根本不用你去说服谁，可是，这个世界若是如此简单，就不会有战争了，是吧，因此，我刚才说的只是开发人员的立场，说这些只是让你们明白一个心理特性，并不意味着，开发人员的这种立场在任何场景都是正确的。
因此，还有一个测试人员的立场问题，对测试而言，咱们有各类测试方法去发现bug，有时有的测试方法作出来的测试结果确实发现了问题，但这个问题可能会引起开发人员的反感，这是由于开发人员对测试的工做不了解形成的，好比，咱们用边界测试发现一个问题，但开发人员会说，谁会去输入这样的数值呢，在实际工做中，人家是不会这样操做的，因此拒绝修改这样的问题，怎么办呢？这个时候，其实若是一味的让每一个测试人员去与每一个开发人员讲道理作宣传，其实效率是低下的，而应该把这一类问题记录下来，由测试部门进行一个评估，而后与项目负责人进行沟通，在一个适合的时间点（致命问题、严重问题都改得差很少且还有时间的时候），对此类问题进行一个全面的修改，若是是一个好的公司与部门，还会就此类问题进行总结归类，并对此类问题定义出严重程度与修改的优先等级，如此就完成了一项过程改进，当下个项目出现相似的问题时，一个制度化的结果已经在这里了，开发人员再次见到相似问题，本身就会在已经把致命与严重问题修改完成的状况下，对此种等级的问题再进行修改，而不须要再次作没有必要的沟通了。
再好比使用操做性问题，其实就是一种体验测试，若是这种问题由每个测试人员零星提出，不但没有科学调查与说服力，也会获得开发人员的白眼，因此有关使用方便的问题，也应该单独的当成一个总体事件去作，而立下科学调查的标准化决议，当项目组与测试部与市场都搭成统一标准后，作这些事，还会有阻力吗？
我看有的人的解决方法是人情世故，有的人的方法则是权利压人，还有的人的方法是每回都去以理服人（以德服人，怎么感受测试老是低三下四的？难怪人家不改你的问题），还有总总方法，但不是有后遗症，就是回回都要如此，搞得效率低下，因此真正的方法应该是，把一项不太受到开发人员重视，但又确实是不可小视的那些问题，想办法经过外交努力，搭成统一的科学的标准化的制度化的行业规范，当一个制度在这里时，没有人会以为你是和他过不去，只会以为，这是制度的要求，咱们本就都该这样作，就好像你迟到了，你不会认为是人事MM对你有偏见，也不会认为人事MM水平低，不懂得以人为本的道理吧？固然不会，由于几点上班是一项制度。有人见过搞人力资源的人在网上发贴问：请问人事如何更有效的说服员工们不要迟到呢？呵呵，一家之言哈！
至于那些根本就不是问题的问题，求求大家千万不要用你和开发人员的好关系，把不是问题的问题给修改了（还好有问题审核与软件配置管理），个人主呀，阿米托佛！
我认为，测试人员应该很明确的记录这个bug，而后查看设计中是否有相关的设计，若是是设计中有而开发人员没有实现，那么就拿着设计文档和开发人员谈。若是设计中没有，就看需求中是否有相关内容，若是有就要找项目经理来看，是否是须要在设计中加入这一块内容。若是需求中都没有，可是测试人员仍旧认为是一个bug，那么就应该找项目经理谈，由项目经理决定是否确认其为bug，是否须要修改。总之，不可以随意放过任何一个测试出来的bug，也不可以和开发人员弄僵关系。咱们应该让他们知道，咱们作的一切都是为了项目可以更好的完成，并且就算咱们找来项目经理讨论，不是打小报告，而是找来比较权威的人士来作决策。
最后
欢迎关注公众号：测试人追风，领取一线大厂Python自动化面试题总结+各知识点学习思惟导+一份100页pdf文档的软件测试开发核心知识点总结！