几个可能和面试时有关的问题

个人观点”

第1题可就你认识的流程 可能我们都差不多经历几家公司，可能有大公司小公司，过CMMI或者未过CMMI的公司。然后整理一个自己认为比较合理的的流程，然后用自己的经验阐述为什么要这么做。

首先我理解这是一个测试流程，我的第一家公司是一家外包公司，过了CMMI3，主要做一些对华为或者移动的软件项目，开发流程较为规范，瀑布开发模式，测试流程大概是““分析需求---指定测试计划(人员项目风险成本)---编写测试方案(或者叫测试策略)---评审测试方案---编写测试用例---评审测试用例---预测试（会在用例中提取高级别的用例测试通不过打回）---完整测试---完整测试---回归bug(会有几轮，每一轮都会有报告)---系统测试(在走一边用例级别高的用例和主要bug)---分析性能测试需求---性能测试---性能测试报告---根据不同需求可能有文档测试等，但都小case了。

ps.因为是外包公司我们主要完成功能测试，和面子上的性能测试，质量还行吧，但是流程规范，咋一看不知道那会有问题，但是这个会很耗时间，会时间成本搞的公司完全不适用。

第2家公司是国内比较知名的互联网公司，敏捷开发，测试流程””分析需求---指定测试计划(时间成本)---测试设计(用画图的方法提取测试点直观方便(因为是cs项目所以比较适合画流程图))---评审这个测试设计---编写测试用例---评审用例---新功能测试---回归测试---系统完整测试---checklist---发布更新测试---线上测试。测试设计或者编写测试用例的时候有机会会去参加开发的代码review，这个过程仁者见仁了，发布更新测试结束后会有测试报告知会项目组每个人。

ps.开始的时候我总是感觉这个流程有问题，因为我们编写用例和测试设计的时间太短了，后来发现这其实是个行之有效的好方法。适用于用自己产品，并迭代开发的公司。

第3家公司是也是一家互联网公司，业务电子商务方向，BS架构，迭代开发，测试流程很多一部分是我来规范的““分析需求(我们很多时候做不到这点，因为需求太多主动权不在技术部而是来自公司各个方面的高层)---测试用例设计(使用自己比较擅长的方法总结测试店，画图也行，直接描述也行，但是保证要让别人能看懂)---编写测试用例(这个一般都是和测试设计结合一起做，所以我们测试设计之后没有评审)---评审设计和用例(保证发现问题马上改，做到效率最大化)---测试新功能---checklist(这一点参考上一家公司)---线上测试(也有一个list)---测试报告。

ps：BS架构，迭代开发，其实意味着我们无时无刻都有新需求(差不多每天都有小版本)，我问过相关类型公司的同行，能写测试用例的很少了已经，完全靠经验，因为小需求多，所以及时用例不多也可能不会出现太多bug，但是这样的流程对于一个像提高自己测试技术和业务经验的人不太适合，项目本身的计划就补规范，也就以为这测试不会太规范，所以需要像很多工作来弥补计划不规范的损失，简历公共用例库，bug库，尽可能保证功能不出问题。