冒烟测试
使用场景：
冒烟测试原本是硬件测试的行话，后来引入到软件测试中，是指，完成一个新版本的开发后，先投入较少的人力和时间，对该版本最基本/核心的功能进行测试，保证基本/核心的功能和流程能走通。如果不通过，则打回开发那边重新开发；如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。冒烟测试理论上是要由测试人员做。但这样无法约束开发代码人员的发版质量，所以现在一般让开发代码人员做。跑通了基本/核心功能后，再提交测试人员后续测试。优缺点：冒烟测试的优点是节省测试时间。缺点是用例覆盖率比较低。解决办法：开发与测试人员充分沟通，利用冒烟的优势特点，制定合适的冒烟用例。使其既可作为版本的快速校验工具，管控提测版本质量；也可以在紧急发版的客观要求下，作为软件发版的测试用例，点检关键功能。像我上面所述的“功能快速点检表”，就可以视为冒烟测试用例。回归测试
回归测试主要是指修改旧代码修复bug后，重新进行测试，以确认修改有没有生效，或者有没有引进新的错误。回归测试可以分为增量回归测试（选择性回归测试）和全量回归测试。1、增量回归测试定义：新增功能开发完成，或bug修复后，回归测试时，只针对新增功能或出现问题的这些功能进行验证，没有涉及到的功能就不进行测试。优缺点：重点测试修改的功能，节约时间和人力成本。但非常容易出现bug修改后，潜在的关联功能可能从正常变为失效，而导致测试遗漏。解决办法：(1)前期功能充分沟通，测试用例备注关联模块。前期在开发和测试人员功能分析时，需要充分沟通，了解功能/函数之间调用关系，了解可能的关联项。并在测试用例中注明关联项。(2)开发人员主动注明。最了解功能之间关联项的是开发人员。因此开发人员在新增功能或修复bug时，务必注明，这个bug是由什么原因引起的、bug修复的逻辑，以及可能会对关联功能产生的影响。小小举动，事半功倍。（3）关键功能测试。虽然，分析下来，有些关键功能跟本次的修改没有直接关联，但出于保险起见，关键功能最好也趟一遍测试用例。因为这是用户权重占比较高的功能，一旦失效，影响会比较大。（4）主观把控。在测试和开发人员的长期拉锯中，对对方的能力水平心里大概都有了数。好的开发修改缺陷时，关联功能会直接就改好，提测的bug修复版本不会出现按下葫芦浮起瓢的情况。而部分能力不足的人员可能考虑的较少，解起bug来顾头不顾腚。那对于这种总会出现2次bug的开发，测试人员就要加大测试力度，如果时间充裕的话可能要对整个模块进行回归。2、全量回归测试定义：字面意思，不管之前查出多少个问题，提测后，所有功能，全，都，测，试。优缺点：全都测试的优点是对所有功能进行验证，尽最大可能地确保系统没有问题。缺点也显而易见，测试人力、时间成本大大提高。动辄三千多的台架测试用例，一千多的实车用例，认认真真肝一遍，没个两三周下不来。而且，长期反复全量回归还涉及到测试心理学问题：随着测试的不断迭代，测试的心理会发生变化，从“捉虫式”测试，逐渐变成了“无罪证明式”测试。解决办法：（1）充分利用冒烟测试、增量测试，降低全量回归测试次数；（2）面对不可避免的多次全量回归测试，合理调度测试人员的测试模式，全量回归测试和冒烟测试/增量测试轮换着进行，以免出现测试心理的变态，额，变异。软件测试流程
对软件的测试流程做个基本的梳理吧。
1、功能分析（1）零件的爸爸（FOP）提交功能文件给测试人员；（2）FOP和测试人员review功能文件（必要时引入供应商开发人员），标注关联功能，细化功能实现逻辑；2、编写测试用例（1）编写全量用例（2）整理冒烟用例（3）FOP和测试人员评审全量和冒烟用例3、实际测试（1）开发完成后，冒烟；（2）冒烟通过，进入全量测试；（3）测试人员全量测试后，输出测试报告（用例执行结果+bug清单）；（4）开发修改bug。修改完后，注明可能影响的关联功能。完成后，冒烟。（5）冒烟通过后，增量回归测试。重点测试修改bug的部分及关联部分。输出测试报告。注：（4）-（5）多轮循环，直至增量测试无bug。（6）测试人员全量测试，输出测试报告。注：（4）-（5）-（6）多轮循环，直至无bug，或bug不影响功能发版。（7）测试完毕，版本发布。总结：测试不易，且行且珍惜。大小bug，没有什么bug是一杯情真意切的咖啡解决不了的。如果一杯咖啡不够，那……就打一架吧。后记：作者非软件专业科班出身，只是结合专业人士的科普以及工作中摸索出的经验所做总结，如有偏颇，还望专家指正。声明：本文内容及图片由BC-AUTO转载至网络,信息来源于