测试通过：
　　经过两到三轮或四轮的测试后，直到没发现新的问题，或暂时无法解决，或不紧急的问题。通过上级确认，可以通过。编写测试报告与验收方案。
　　验收方案是交由QA进行验证的。在现公司的流程中是将测试与QA分开的，测试人员重点关注的是功能是否可以正常运行。QA关注的是整个流程的质量以及终用户的质量。有些公司QA与测试是不区分的，但这对测试的要求会更高，除了关心功能，还需要关心整体流程与质量。
　　流程分析：
　　对于刚接触这个流程的我来说，这个流程是规范的，测试真正融入了整个流程，而且还担任了很重的角色，从而也有效的保证了软件产品的整体质量。
　　那么这个流程是不是完美的呢？不，这个项目流程太强化各种文档。我们来看测试的工作内容，测试计划、测试用例、测试结 论、测试报告、验收方案、问题的提交跟踪。其实，我们真用于测试的时间是非常少的，在一周的时间，也许只有或不到的时间是在进行测试的。测试人员 只有在测试的时候才会体现出他的价值。而大部分工作却不能体现他的价值。
　　当然，我这里会省略与测试主流程无关的东西，真正的测试工作中琐事很多。
　　敏捷测试流程                                                                                      
　　下面来看敏捷测试，本人并没有接触过敏捷，对敏捷也没花时间学习与研究。接触是听我们测试经理对测度流程讲了两个半小时，听讲的人很多，我站着听的。受益匪浅，凭着记忆也简单谈谈。
　　前面讲的第一种流程，还是第二种流程都是瀑布式的，严格来说第一种简陋的都不能称为瀑布式，对于一个三个月的项目说，产 品把需求分析完了给开发，然后产品没事儿了；开发开发完成之后给测试，然后开发人员也不忙了。测试完成之后上线。那么在产品分析的阶段，开发和测试都是 没事干的（这里只对单一项目）。开发阶段，产品和测试也基本没事儿。同样在测试阶段，产品与开发也是没什么事儿的。
　　敏捷测试的一个核心是迭代，在每个时间点上，所有项目人员都是有事可做的。
　　1、下面是我理解中的敏捷测试流程图：

　　第一阶段：
　　通过上面的流程图，对于一个月的需求分析，在敏捷中，可能三五天确定下来。这个需求定得会很模糊，但整体框架确定。产 品对其中某一模块功能确认，开发人员开始对确认的功能编码，开发人员编码的过程中，测试进行功能分解，因为根据模糊的需求很难写出具体的用例，所以，只能 尽量对功能进行分析得细些，标注需要验证的内容。
　　第二阶段：
　　开发完成后交给测试人员进行测试，开发人员继续开发新的功能。那么测试人员发现的问题怎么办呢？会从开发团队中抽出一个人员来用于解决测试发现的问题。但开发进度并没有因为测试而停止。
　　流程分析：
　　在这个流程中弱化了文档，强调了各个人员的沟通，通过这种迭代的方式，三个月的项目，可以能两个月和两个半月会完成。
　　但这种流程并非完美，加入一个功能在需求分析阶段是错误的，因为它是一个迭代渐进的过程。也只能一路错下去。
　　2、对测试问题的处理

　　上面的图更能清晰看出对问题的处理过程。
　　第一块面板中是开发人员未实现的功能，第二块面板中是开发完成功能，测试人员对其进行测试，发现不通过的放回未开发的面板中，测试通过的将放到第三块面板中。
　　需要说明的是，敏捷测试在国外很流程，在内容，雷声大雨点小，推行的人很多，真正有公司引入的不多。我们所在公司千差万别，测试流程也可能有很大的不同。 对于已经工作两年一个测试员来说，从来没关注过测试流程与结构应该是个悲剧。我希望不被思想局限，所以，努力冲破一个又一个的局限。