之前在某外包公司做测试，下面是我在做测试时所经历的测试流程，关于在外包公司的其他体验不便多说，但是我觉得测试相关的流程还是可以分享一下的，感觉还是比较完善的。
（1）需求查看阶段
在进行需求评审之前，我们测试组长会把需求分给对应的测试，然后测试会有两天左右的时间仔细查看手中的需求；这个时候就要对原始需求文档和具体的实现方案文档进行仔细的阅读，找出其中任何不明白和有问题的地方并记录下来，要注意实现方案是否合理，是否有遗漏的地方，例如涉及到接口的部分，接口文档是否给出，接口所涉及到的请求参数和返回参数是否有明确规定（这里包括正常场景和异常场景），还有接口的请求方法请求服务是否给出；如果是功能测试相关的实现文档就看是否有相关的业务场景（正常和异常）的返回结果是否有明确规定，还有需求中是否有模棱两可的地方都要注意；特别要注意原始需求文档和实现方案不一致的地方。这些都要在需求评审的时候给产品经理或者产品经理提出来。在这个阶段一定要尽可能的熟悉需求！（这里原始需求是客户出的，然后实现方案是产品经理出的）
（2）需求评审阶段
在需求评审时，产品经理会将测试，开发，维护和客户组织在一起开一个需求评审会。这个时候产品经理会先对需求的实现方案进行全流程的讲解，然后会对需求的一些特别要注意的地方进行重点说明，然后就由测试，开发，客户和维护对需求的一些问题还有实现方案是否合理进行提出来（这个时候就要将上一个阶段所记录的问题向产品经理确认清楚了），产品经理会对提出的问题进行讲解，将所有提出的问题都确认清楚，如果有需要另外花时间核实的，产品经理会发出邮件进行说明；如果需求实现方案评审通过则进行接下来的流程，如果不通过则这个需求就会从上线版本列表中剔除（需求方案不通过这种情况在我离职前的最后一个月还真遇到过一次，不过这种情况的概率真的是非常低的）。注意：在这个阶段一定要把这个需求绝大部分的问题给扫清，因为这个时候方案就已经定性了，之后再有很多涉及方案的问题的话就需要重新修改方案，这样就极有可能造成开发已经写好的代码作废，测试要重新设计测试方案，增加工作量，耽误进度！所以这个阶段是非常重要的阶段，是一定要非常重视的。（需求变更这种事我也遇到过很多次啦，客户说改就改，这也是非常无奈的）
（3）用例编写阶段
开发在需求评审通过之后就会去写代码了，然后我们测试就会去编写测试用例。所有需求的用例编写完成大概会给一周左右的时间（紧急需求另当别论），我们编写用例的原则就是首先遵循业务场景来，正常场景和异常场景；然后就是根据常规的一些正常和异常的判断，这里会用到的主要还是等价类划分，边界值，场景法，错误推测法等常用的方法来编写用例。（因为框架都是些用了很久的老框架，所以就不会存在太多框架方面的问题，异常场景相对来说少一点点）要注意用例尽量覆盖全面一点，多看几遍需求，需求越熟悉才能想到更多场景。
（4）用例评审阶段
在用例编写完了之后，会先将用例发给组内评审，主要就是组内成员和组长进行评审，主要就是看用例的覆盖是否全面。组内评审了之后还要发给客户方进行评审（客户评审问题不大，他们都不一定看的懂）。
（5）开发将需求转测试阶段
在需求评审完之后，开发会在需求管理平台（专门管理需求的网站，内部用的）标注需求转测试的时间。在转测试的时间到了之后，开发会将需求所涉及到的脚本提到svn的归档目录下，将涉及到的代码提到主机的归档目录下；测试就从归档目录将代码和脚本取下换到测试环境进行测试。注意：开发提的sql脚本，测试一定要先检查一遍，看有没有错误的地方，比如select * 这种低效sql，或者写错了查询条件，update没跟条件，ddl提成了dml等问题；发现了及时给开发说，让开发及时修改！
如果涉及到的需求工作量很大，时间不充裕的情况，可以催开发，让开发加快进度或者让开发做一部分转一部分，免得到时候快上线了才转测试，然后影响上线质量！
（6）需求测试阶段
当需求转测试之后，首先会把涉及到的基本功能都粗略的测试一遍（就是冒烟测试），如果发现基本功能不通过的，立马告诉开发并提上bug单，视情况将需求标为不通过或者新建打回（这个其实也要看具体情况，首先要看是不是数据或者环境问题，然后再确认是不是代码或者脚本问题，这个一定要先自己定位一下，不要太快下结论，但是如果拿不准的，就先问下开发）。冒烟测试之后，就开始对着用例一个个的仔细测试吧；发现bug的话，就给开发提bug，最好附带有日志截图之类的，方便开发定位问题作出修改。如果遇到争议性的bug，可以和开发与产品经理共同商议。注意：如果遇到实现方案相关的问题需要改方案的一定要尽快向产品经理提出并告知开发（开发没有权利私自修改方案以及接口字段表结构等，必须由产品经理同意才可以）。测试报告的相关截图可以在测试的时候，边测试边截图。（在测试的时候涉及到数据库的一定要检查数据的正确性，还有接口返回的字段是否正确，对涉及数据量大的要进行大量的数据测试看是否超时，兼容性也要进行检查）需求在测试环境测试完成之后，还要再预发布环境再次测试一次，因为这个环境更接近生产，也是有可能发现问题的，这个环境测试完成才算测试完成。
（7）代码评审阶段
在需求标注为测试完成之后，开发组的组长会组织人员进行需求的相关代码进行评审，就是代码走读。这时测试主要会将这个需求测试了哪些内容大致讲一遍，涉及到的关键测试点是否测试进行一些汇报，然后开发组的大佬会直接将代码在评审会上评审，也会将涉及到的一些特殊业务场景提出来让测试进行测试。这是保证上线质量的最后一道关卡。
（8）UAT阶段
上线前两天会通知客户来进行uat验收，主要就是给客户演示需求所实现的功能看与客户要求的是否一致，通过之后客户会进行签字，然后才能上线。（自我觉得UAT就像渡劫一样，有时候客户会在这个时候提出一些很不合理的要求很是让人无奈，这里不多说）
作为一个测试，在外包的流程差不多就这个样子，自我感觉还是挺完善的；实际流程还要更复杂一点点，但是这些还是可以稍微借鉴一下。