最近在找资料的时候，翻出了早期从别的地方看到的关于测试基本知识 30 问。重新看了一遍，有很多感慨，原来自己也踩过那么多坑。故重新梳理了下，精简成 10 问，一起来看看那些看似小白，但又不太好回答的问题。
个人认为，没什么合适不合适的。测试不需要天赋异禀，只要你努力，达到中上水准的测试能力基本没啥问题，还到不了拼天赋的情况。所以，如果你有幸选择了测试（不管是自己选择的还是别人忽悠上路的），那就埋头学习呗。以前对测试有些标签是 “细心”、“认真” 等等，其实不论哪个行业都需要这两个特质。笔者也不是自己选的测试，只是当时有这么一份工作机会而已。如果不是让你特别痛苦（生无可恋），那就继续走下去吧，持续学习，不断改进。最怕的就是半途而废。工作嘛，就是有一份收入。大多数人都不会把好爱和工作绑在一起。
在软件测试的初期，你可能只是需要按照别人给定的测试用例，机械地去执行就可以了，那是相对简单的。但是接下来，你需要形成自己的测试思维，结合业务去做用例设计。你需要学会分析和定位 BUG，还需要尝试去看看业务的代码长什么样。
3~4 年之后，你要学习从整体上把控项目的测试进度，根据版本特性去制定测试策略，考虑测试的有效性和充分性。同时，需要通过一定的技术手段去提升测试效率。
再之后，你要学习推动质量内建，改进研发过程，从根本上提高代码的交付质量。去做更多的测试左移和右移。测试人员不应当把自己局限在测试的职责范围内，不断扩充自己的边界，不好么？测试难不难，取决于你的自我要求，市场会给你真实的答案，没事多看看相关的招聘信息。
当然可以的。测试、开发只是职责不同，为什么不能愉快合作？原则上他们应该一起更愉快的合作，才能更好地交付业务，开发负责把需求实现，测试为开发的代码提供质量兜底（测试无法保障质量哟，只能提升和改进）。造成开发测试对立的原因，是因为以前的筒仓思维过于严重，对于 BUG 的归属产生了不同的看法，研发主管要求少写 BUG，测试主管要求多发现 BUG，二者对立了。所以大家才会 “水火不相融”。现在，大家对于 BUG 的数量不再过多地关注，更多关注的是最终的交付结果，所以二者变的相互促进。如果你的测试主管还以 BUG 量来考核你，可以考虑离开这样的团队。
作为测试人员，个人的建议是，非常需要了解软件开发过程及所使用到的技术体系。如果不了解被测试系统的架构设计知识，在开展测试时，会有处处被掣肘的感觉。不管是定位 BUG 还是分析 BUG，如果你不了解原理，就很难有效的去处理那些问题。作为一名优秀的测试人员，必须要能够自己画对业务的技术架构图及数据流程图。有助于你更好的去做测试用例设计和场景覆盖。例如，当你了解了 redis 的技术实现，你在设计用例时，就会考虑到数据持久化、数据时效性、数据透传等等场景。而如果你不懂技术，通过业务场景，很难覆盖到这些技术特性。
测试在某种程度上来说，是会增加项目成本的。个人也遇到过不需要测试直接上线的项目。但是是否值得，需要从 3 个方面来综合考虑。
项目当前处于什么阶段：对于早期的验证项目，质量并没有那么重要，公司可能需要某个项目进行快速市场验证，这个时候时间是第一因素，那么在保证核心业务没问题的情况下，是可以减少测试的投入。这也是很多初创的项目很少招测试的原因。
项目的性质是什么：对于一般的业务验证，我们对质量可能会有些松懈，但是对于金融、医药、交通类的项目，质量大过天。对于这类项目，质量是需要重点保障的，否则后果会相当严重。
客户的容忍度多高：这个也是要重点考虑的。对于 To C 的产品而言，质量不佳会严重影响用户体验，进而引发用户流失（现在的同质化产品严重过剩）。而相对于多数的 To B 产品，客户对于产品缺陷的容忍度会高些，在沟通到位的前提下，可以适当的放松些。
篇幅原因，后续的 5 问下期再聊。敬请期待。