互联网公司的研发团队结构：
测试流程：
1.需求分析阶段
通常是以被测产品的需求为原型进行分析转变而来，测试需求主要通过以下途径来进行收集：
- 与待测软件相关的各种文档资料。如软件需求规格、Use
case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。（需求文档一般是产品经理写，需求分析书是测试来写） - 与客户或系统分析员的沟通。
- 业务背景资料。如待测软件业务领域的知识等。
- 正式与非正式的培训。
- 其他。如果以旧系统为原型，以全新的架构方式来设计或完善软件，那么旧系统的原有功能跟特性就成为了最有效的测试需求收集途径。
提取功能点就从大往小细分：整理成树状结构
2.测试设计阶段
测试计划，方案和策略可以合起来写到测试计划书中
5W+1H：
是对选定的项目、工序或操作，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。
1、对象 （What）——什么事情
公司生产什么产品？车间生产什么零配件？为什么要生产这个产品？能不能生产别的？我到底应该生产什么？例如:如果这个产品不挣钱，换个利润高点的好不好？
2、场所 （Where）——什么地点
生产是在哪里干的？为什么偏偏要在这个地方干？换个地方行不行？到底应该在什么地方干？这是选择工作场所应该考虑的。
3、时间和程序 （When）——什么时候
例如这个工序或者零部件是在什么时候干的？为什么要在这个时候干？能不能在其他时候干？把后工序提到前面行不行？到底应该在什么时间干？
4、人员 （Who）——责任人
这个事情是谁在干？为什么要让他干？如果他既不负责任，脾气又很大，是不是可以换个人？有时候换一个人，整个生产就有起色了。
5、为什么（Why）——原因
为什么采用这个技术参数？为什么不能有变动？为什么不能使用？为什么变成红色？为什么要做成这个形状？为什么采用机器代替人力？为什么非做不可？
6、方式 （How）——如何
手段也就是工艺方法，例如，我们是怎样干的？为什么用这种方法来干？有没有别的方法可以干？到底应该怎么干？有时候方法一改，全局就会改变。
可参考：
https://blog.csdn.net/u011090984/article/details/90724494
https://blog.csdn.net/zimingzim/article/details/81709142
测试用例：根据之前的需求分析说明书转换来的，看看跟需求比较覆盖率达到了多少
总体编写思路：
黑盒测试用例（优先）+白盒测试用例（补充）=完整测试用例
总体编写策略：
对于测试用例编写来说，常用的四种方法基本就够用了，等价类、边界值、正交实验法、错误推断法，辅以场景测试法、需求/设计转换法、探索式测试思想，可以应付绝大多数产品的测试。个别的产品还需要在某一点细化和扩充，需要就事论事。
使用各种编写方法的综合设计策略；
1)在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2)必要时用等价类划分方法补充一些测试用例，尤其注意无效等价类情况。
3)如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法（或判定表法、正交试验法）。
4)用错误推测法再追加一些测试用例，主要是利用测试经验。
5)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例；参照白盒用例编写。
6)对程序的应用场景进行研究和思考，增加不同场景下的测试用例；用户场景测试必须重视，很大一部分程序错误就是因为测试场景与用户真实场景的差异性带来的。
7)对业务和程序有更深的理解之后，可以充分发挥发散思维和探索式想法；大家不要误解探索式测试就是漫无目的的测试，其实探索式测试有非常详细的测试指导思路。
测试完以后进行评审，看看测试的咋样：
3.测试执行阶段
测试执行阶段，看预期结果和实际结果对比，有bug的话要提交，然后在版本二上面做回归测试
4.测试总结阶段
对bug的统计包括，bug的数量，状态，等级如何，哪些开发各种提交了多少bug，各个开发名下的bug有多少。从而根据这些写一个总结，看看哪些开发bug少，哪些测试挑的bug少，分析原因 是因为开发对需求理解不太高？测试偷懒？开发代码能力不熟练？测试刚开始接触比较陌生？从而做成统计分析
