https://mp.weixin.qq.com/s?__biz=MzkwNTI2NjAxMA==&mid=2247484071&idx=1&sn=b53eee60c6870766403f98cf5a4fed4d&chksm=c0fb1492f78c9d84c69383dde50db30511267a892c0a670c22b5d1d6a1c074fc97b75954f7cf&cur_album_id=1979310371207184387&scene=189#wechat_redirect
01 我适合做软件测试么？
如果不是让你特别痛苦（生无可恋），那就继续走下去吧，持续学习，不断改进。最怕的就是半途而废。工作嘛，就是有一份收入。大多数人都不会把好爱和工作绑在一起。
02 软件测试很简单么？
在软件测试的初期，你可能只是需要按照别人给定的测试用例，机械地去执行就可以了，那是相对简单的。但是接下来，你需要形成自己的测试思维，结合业务去做用例设计。你需要学会分析和定位BUG，还需要尝试去看看业务的代码长什么样。
3~4年之后，你要学习从整体上把控项目的测试进度，根据版本特性去制定测试策略，考虑测试的有效性和充分性。同时，需要通过一定的技术手段去提升测试效率。
再之后，你要学习推动质量内建，改进研发过程，从根本上提高代码的交付质量。去做更多的测试左移和右移。测试人员不应当把自己局限在测试的职责范围内，不断扩充自己的边界，不好么？测试难不难，取决于你的自我要求，市场会给你真实的答案，没事多看看相关的招聘信息。
03 测试和开发能否一起愉快合作？
当然可以的。测试、开发只是职责不同，为什么不能愉快合作？原则上他们应该一起更愉快的合作，才能更好地交付业务，开发负责把需求实现，测试为开发的代码提供质量兜底（测试无法保障质量哟，只能提升和改进）。造成开发测试对立的原因，是因为以前的筒仓思维过于严重，对于BUG的归属产生了不同的看法，研发主管要求少写BUG，测试主管要求多发现BUG，二者对立了。所以大家才会“水火不相融”。现在，大家对于BUG的数量不再过多地关注，更多关注的是最终的交付结果，所以二者变的相互促进。如果你的测试主管还以BUG量来考核你，可以考虑离开这样的团队。
04 测试人员是否需要了解软件开发知识？
作为测试人员，个人的建议是，非常需要了解软件开发过程及所使用到的技术体系。如果不了解被测试系统的架构设计知识，在开展测试时，会有处处被掣肘的感觉。不管是定位BUG还是分析BUG，如果你不了解原理，就很难有效的去处理那些问题。作为一名优秀的测试人员，必须要能够自己画对业务的技术架构图及数据流程图。有助于你更好的去做测试用例设计和场景覆盖。例如，当你了解了redis的技术实现，你在设计用例时，就会考虑到数据持久化、数据时效性、数据透传等等场景。而如果你不懂技术，通过业务场景，很难覆盖到这些技术特性。
05 规范的测试会增加项目成本？
测试在某种程度上来说，是会增加项目成本的。个人也遇到过不需要测试直接上线的项目。但是是否值得，需要从3个方面来综合考虑。
项目当前处于什么阶段：对于早期的验证项目，质量并没有那么重要，公司可能需要某个项目进行快速市场验证，这个时候时间是第一因素，那么在保证核心业务没问题的情况下，是可以减少测试的投入。这也是很多初创的项目很少招测试的原因。
项目的性质是什么：对于一般的业务验证，我们对质量可能会有些松懈，但是对于金融、医药、交通类的项目，质量大过天。对于这类项目，质量是需要重点保障的，否则后果会相当严重。
客户的容忍度多高：这个也是要重点考虑的。对于To C的产品而言，质量不佳会严重影响用户体验，进而引发用户流失（现在的同质化产品严重过剩）。而相对于多数的To B产品，客户对于产品缺陷的容忍度会高些，在沟通到位的前提下，可以适当的放松些。
06 测试是否需要过早的参与产品需求讨论？
一般我们会认为专业的事交付给专业的人去做，等产品把需求文档写清楚后，我们根据需求文档来写用例即可。但是在当下敏捷的环境中，产、研、测三方需要更早的对齐需求，达成目标一致。所以测试需要适当的左移，协助产品完成需求的梳理，以实例化的形式把需求表达清楚，写好验收条件。这是非常有必要的。有以下几点好处：
-
产品把需求梳理清楚了，也知道怎么验收了
-
研发知道要做什么，做成什么样算是基本做好了
-
测试在这个过程中，就把核心用例设计完成了。还可以给到研发做为自测的标准。
-
产、研、测三方达成一致，避免因为理解上的不到位引发返工浪费。
注：我们可以适当提问题，做实例化，但不要过多的提意见或者帮产品做决定。因为大家对需求的上下文并不了解，不要太过武断。相信产品人员的专业度。
07 项目总是压缩测试的时间，怎么解？
作为研发链的后端环节，时间被压缩的情况时常会发生。我们需要在项目整体规划的时候，就去争取相对独立的测试时间。这个“独立”指的是专门用于回归测试的时间。在敏捷的环境下，我们希望研发人员尽快交付可测试的功能点，分批提测。同时，在最后的回归测试，需要留出专门的时间来处理。
如果因为项目周期紧，不得不压缩测试时间的情况下，测试需要做好以下几个关键点：
做好测试策略：在有效的时间内，如何做裁剪，哪些是必需要保证的，哪些可以适当放松，一定要分好主次，把有限的时间投入到最高价值的业务中；
做好风险控制：识别系统风险，对于无法覆盖到的场景，需要提前考虑会产生哪些风险，对应的策略是什么，分别对应的预案是什么，提前在组内形成统一的回复口径，避免各说各的。
组内通报：把上面两点落地到文档上，并通报相关人员，大家达成共识。
08 线上发现缺陷，都是测试人员的问题么？
这个问题是对测试人员的终级拷问。花了那么多时间和精力投入到测试中，为什么还会有问题遗留到线上呢。对于这个问题，个人的理解是，先解决问题！测试人员需要积极配合开发，先把问题解决了，这个时候不需要去考虑是谁的责任。
事后追溯的时候，需要先分清楚问题的类型，并加以改进。一般会有以下几类：
简单易现的问题：如果是比较简单就复现的问题，那作为测试人员就要反思下为什么了，这个锅跑不了，还是要有对自己的工作负责的态度。
特定场景或者数据才会出现的问题：这种情况，遇到一次，就完善一次用例（如果能自动化，就最好了），同时思考为什么只有这种情况才会出现，类似的还是不同环境配置引起的问题。这类问题需要注意平时的积累，形成自己的经验，这类问题，可以团队一起背，但要给出改进方案，不能多次在同一个地方跌倒。
深层次的偶发问题：这类问题其实是提升团队技术能力很好的试验场，集中力量解决掉就是了，更能激发技术宅男们的热情。这类问题，一般情况下做好线上监控，能及时预警，比客户更早或者不能落后太多发现，就可以的，让团队有缓冲解决问题的时间就好（准备好相关的话术，安抚客户也是OK的）。
09 发现bug越多说明测试越有效？
还记得第3问么？测试开发为什么会对立，大多数就是因为缺陷的归属问题。测试人员发现缺陷是应尽的责任，但并不是唯一的责任。测试活动并不是以发现缺陷为最终目标。很多测试人员会以挖掘出一个经过N个步骤（N大于10之类的），才会出现的缺陷为荣。个人并不是很认可这种观点。从用户的操作行为来看，可能永远无法发现这类问题。把大量的时间花费在这上面，并不值得（如果这类缺陷会引发重大问题，才有价值）。
测试的本质是希望贯穿整个研发周期，形成闭环，并持续改进测试流程，以终为始、系统地分析测试需求，在资源和测试目标之间寻求平衡， 基于风险的测试策略是必不可少的 在分析和设计的基础上，尽可能地实现自动化测试。
10 测试有没有钱途
这个问题本来想放在第一问的，毕竟是大家最关注的问题。但个人觉的这也不是个问题。软件测试现在虽然不像前几年那么火爆，但还是处在行业的红利期，所以钱途还是有的（隔壁的土木同学都提桶跑路了）。测试不是一个能让你大富大贵的暴利行业。但做为一个安身立命的职业，还是绰绰有余的。大家可能会在忧虑“35岁”现象，但这是你从事大部分行业都会遇到的问题（事业的尽头是编制），我们能做的，是让能力的增长跟上时间的增长，不管是在专业技能上的积累，还是在管理、人脉等软技能上的积累，都需要跟上行业的发展，现在没有什么可以让你躺平的行业（家里有矿的另说）。测试的天花板也没有你们想的那么低。没事多看看招聘信息，多和行业高手互动。测试还是大有可为的。