在这里可以跟大家说一下，我就曾经在产品发布权限不在测试这里部门的情况下，成功的让研发决定推迟发布了大约一半以上的项目,。大多数的测试部门主管，很难顶住来自项目/技术经理的压力是有理由的，因为他们根本不了解你做了哪些工作。有时候一些情况下，看似不可能的事情任务要想做成完成，关键要看在于事情的技巧。流程表示了只是一个大方向的东西，而且，你永远也无法将责任推卸给流程也许是对的，更多情况下，作为测试主管，需要但将做事的方法与风格可以影响到推广到测试流程的推广中。

    在测试互联网项目时，还有一个更重要的就是如何保证性能。

    也许大家会说不就是性能测试并不是单独存在的。其实不是完全正确，如果有充足的优秀高手人力资源做性能测试当然很好，但性能测试也不能完全保证所有的项目完全没有性能问题都完美无缺，因此，项目投入期间，同时性能测试是一个这个费时费力的工作，所以往往都是一般在资源不足的情况下开展的。作为测试主管，更应该，要学会判断那些相对更加重要的问题项目影响面会更广，需要集中做性能测试。这时你也许会问，那么会有人问其它相对不太重要的项目与问题怎么办？其实做过性能调优的人都知道，大部分的性能问题都是由于一两个弱智的SQL语句导致的，所以可以从流程上加强对SQL查询语句在I/O问题的跟踪与评审,，从而避免大部分性能问题。

    上面分析了不同公司根据上文的分析，不同类型的产品在测试流程上的是有很大差异的。这时，也许大家你也许可以把握测试流程大的方向了，但真正是否适合现有的测试团队与研发团队，则仍需要精心的调整。当我遇到问题的时候，第一时间往往有时候不是去寻找流程不对的问题，而是通过现有资源与执行的方法可能需要着手来微调一下你的测试流程，直到发现问题的所在，并纪录下来，最后整合到原来设定的流程中。

    这样的情况大概常常发生：比如说在需求上的处理，可能会有很多的测试人员会经常指责需求人员撰写的文档非常粗糙不详细，无法进行测试。好像在我的记忆中，需求人员常常就是被骂的得灰头土脸，但是经过这些年在测试岗位上的工作，我才渐渐发现，其实有时候需求人员更需要鼓励鼓励是比职责更加有效的工作方式。这可能是一个放之四海皆准的工作态度。，指责只能加深对立。其实在验收需求时，由于当时大家也只是知道一个大概我们的需求人员也只能从大致上把握核了解，可能大多数情况下是：原则上没有问题就通过了。但然而，这种不负责任的态度却是给我们在做的测试工作带来相当多的麻烦。也只有在这样的时候，这些问题才能真正暴露出来，从而使测试设计时就会发现很多问题并没有写清楚。一般情况下，很多测试人员这时就多半会放弃手边的工作，并消极地认为认为无法做工作无法继续下去，等东西出来，并将问题最终归结到是需求给的不详细，而大加指责。

    从我对测试主管工作的记事以来，就在印象中保留了这样的一幕。记的刚进一家公司时，我团队中的人员就开始经常会有下属跟我说抱怨，公司的需求工程师让我们太失望了。需求如何如何不好，然而，多少有些经验的我，当时我是把几家国内我服务过的顶尖公司情况作了一个简单的对比，的需求跟公司的需求人员的需求做了比较这时才发现，原来我们公司的需求人员还是做的得不错的。让测试人员把心态调整过来是测试主管的另外一件事。试问，如果是你做需求作为需求工程师，是否会比他们做的好吗得更好？有了这样的基调，就可以让然后建议测试人员去总结不清楚的地方，给需求人员一个相对比较具体和明确的意见，这样顺利的了解了需求。
 
    其实有时候不是流程不对流程在这其中并没有太多值得指责的地方，而是相互的理解与支持,换位思考而对流程的执行态度，却是更加关键的。我们不得不学会如何换位思考，并更多地从他人的角度来看待这些问题。

    同样的问题还出现在还有需求变更上，很多测试人过不了这一关。总是他们指责研发人员，让研发那些本来就已经恼火的软件工程师更加火冒三丈。换位思考一番，其实不难了解，其实需求变更对研发工程师来说是更大的麻烦。他们需要修改设计、代码，相较而测试只要需改测试用例，他们的工作确实更加麻烦。简单来说，就ok了，其实大家要分析什么样的需求变更最可怕，而不是眉毛胡子一把抓,其实测试对需求变更并不可怕，怕的是只有在提交时才发现，导致测试时间不够，才会真正让测试人员心慌。这时需要从研发流程上保证变更及时的通知到测试就可以了行。也许有人会说你也需要说，说的倒很容易，如果研发不按照你的要求做怎么办！其实这里你只要用我所采用的方法是用数据说话，在项目进行时统计发生过多少次这样的事情，让研发管理层知道，让项目组之间有一个比较。一方面，如果是一家公司重视质量的公司，必然会引起重视；另一方面，从质量管理部门角度本身出发，也应该推动公司重视质量，随着时间的增加，需求变更给测试人员的反馈一定会有下降的趋势。关键是测试不能抓住鸡毛就一直揪着不放宽容一些来看待身边的同事，要允许别人他们犯错，对于解决问题本身来说会大有裨益。只要趋势是好的就可以了。同时如果出现这样的情况并且极大影响到了测试进度，则要与研发部门沟通清楚，如果研发不认可的情况下还可以请上级进行评估一下。

    上面说的是不同态度在同样流程下的实现不同结果,下面主要讲一下关于自身资源是否胜任做流程上规定的事情，某些工作，也许并不一定是测试部门的优势，而另外一些，则需要根据测试团队的基本能力和资源进行评估。比如像性能测试、SQL的trace、自动化功能测试、单元测试集成、游戏性测试。其实这些流程上的关键点，可能大多数从功能测试上来一路走来的测试人员是无法做的到，这时要善于利用资源，不一定要测试做，可以从通过流程上保正有人来做积极调动其它部门的同事，或是找有能力的人来做，测试可以进行监控。其实这种技术含量高一点的测试，对人的因素要求更大高，可以借助研发团队一起来做会有更好的效果。记的第一次做Oracle数据库性能监控时，就是请的Oracle的DBA专家帮助设计了性能参数，成功的地进行了关于Oracle应用的性能测试。现在国内的测试人员普遍的技术水平不高，严重的限制了测试的发展，希望测试的同行能真正的提升测试技术水平，把这些高难度的测试做起来，而不是仅仅只是工具上玩玩。只有真正提升测试团队的技术含量，这样别人才会更信赖你，这也是我这么多年来的一点经验。如果你对开发很精通，、同时又精通对测试颇有研究，善于诊断性能与架构上的问题，经常会帮助研发部门解决一些他们无法解决的事情，同时又还懂的如何做测试管理，并了解研发人员的心态，那就真得的找不出你还有不成功的理由了任何理由让人不对你刮目相看了。