1. 我适合做软件测试吗？
没有适不适合。测试不需要天赋，需要自身的努力
测试的固有标签是细心、认真，其实任何行业都需要这两个特质
把测试当做一份工作机会，大多数人都无法以兴趣爱好作为职业
持续学习，不断提升自己
2. 软件测试很简单吗？
入门简单，深入不容易
第一阶段，执行别人给定的测试用例
第二阶段，测试思维形成，基于业务设计测试用例
第三阶段，分析和定位BUG，尝试阅读代码
第四阶段，从整体视角把控项目的测试进度，根据版本特性制定测试策略，考虑测试的有效性和充分性，通过技术升段提升测试效率
第五阶段，推动质量内建，改进研发流程，从根本上提高交付质量。做更多的测试左移、测试右移
3. 测试和开发能否愉快合作？
可以。
开发负责实现需求，测试为开发的代码质量兜底（测试无法保障质量，只能提升和改进）
不再过多关注BUG的数量，更关注产品的交付结果
测试和开发协同工作，相互促进
4. 测试人员是否需要了解软件开发知识？
非常需要！
了解被测系统的架构设计和技术体系，能更准确的定位和分析BUG
能梳理业务的技术架构图和数据流程图，能更好的设计测试用例和场景覆盖
5. 规范的测试流程，会增加项目成本吗？
会增加，但是否要执行严格的测试规范，需要视情况而定
项目所处阶段：研发前期，可以减少测试投入。因为公司需要将产品快速投入市场验证，时间是第一要素，质量其次，保证核心业务正常即可
项目的类型：金融、医药、交通类，质量是第一要素，需要重点保障，否则后果严重
客户的容忍度：To C产品，现阶段同质化产品过剩，如果质量不佳会严重影响用户体验，导致用户流失；To B产品，客户对缺陷的容忍度高一些，在沟通到位的前提下，可以适当放松
6. 测试是否需要过早参与产品需求讨论？
需要
敏捷开发模式中，产品、开发、测试三方需要更早的对齐需求
测试需要适当的左移，协助产品完成需求梳理之后，写好验收文档
好处：
-
需求梳理清楚了，产品知道如何验收
-
开发明确知道要做什么，做成什么样算基本做好
-
测试把核心测试用例设计好了，给开发作为自测标准
-
产品、开发、测试三方达成一致，避免因理解不一致引发的返工
7. 项目总是压缩测试时间，怎么办？
在项目整体规划阶段，争取相对独立的测试时间（专门用于回归测试），按功能点分批提测
测试策略：在有限的时间内，分清主次，更多的投入到高价值的业务中
风险控制：识别风险，对于无法覆盖的到场景，提前考虑会产生那些风险、以及应对策略
信息同步：以上两点落实到文档，并告知相关人员
8. 线上发现bug，都是测试人员的问题吗？
这个问题属于对测试人员的终极灵魂拷问，哈哈哈
如何应对：先解决问题！积极配合开发，不要纠结如何划分责任。事后及时复盘，分清楚问题类型，并计划改进
简单复现的问题：测试人员需要反思，该承担的责任勇于承担
特定场景或数据才会出来的问题：这类问题依赖日常经验积累，需要团队一起承担责任，并确定改进方案，避免以后出现类似的问题
深层次的偶发问题：做好线上监控，及时预警
9. 发现bug越多，说明测试越有效吗？
不是的
测试人员发现BUG是应尽的责任，但不是唯一的责任，不应该以发现更多的BUG为最终目标
