很多公司都客观的讲究时间管理，人员管理，绩效管理。那么如何做好对于测试流程的管理呢?

　　随着敏捷模式的不断引入，测试的小迭代化更加明显，很多的情况下测试作为发布流程的后一环，却是发布的关键一环，如何在短至几个小时内做好测试的管理呢?技术，管理，流程缺一不可。有好的技术人员，没有流程和管理的支持将会不断的流失。

　　切合 Test2.0 的理论测试更为关键的一点需要逐渐的向SQA的方向发展，测试更多的作为流程的监督者。

　　从项目管理的四要素 范围，时间，质量，成本 出发，下面简要介绍下对于测试管理的个人理解。

　　范围：测试范围决定了测试的时间，间接的决定了测试的质量

　　如何确定测试范围，这也是测试的一种艺术——测试

　　测试说白了是针对代码，测试点关注于release间的diff而不是全局case，更多关注增量代码和差异代码。

　　这样的流程需要管理流程上的配合，当前release只包含上线功能，不包含已废弃，开发ing的工程代码。

　　时间：一直是牵制测试人员比较大的一个因素
对于大多数的业务测试人员来说时间是大的敌人
　　业务线人员如何能将时间利用到呢? ——测试配合自动化测试

　　测试将本次测试的范围精确化，更好的确定关联模块。

　　自动化测试更多的是在持续集成代码checkin之后，自动触发将自动化测试通过作为迭代的代码准入原则。

　　质量：如何评估测试效率

　　非常难评估一个测试人员的贡献，测试漏测率，BUG发现率，这些客观的衡量功能测试的指标也已经越来越不明确了。

　　测试人员有更多的思考和发展，测试都是以发现BUG为目的的，但是实现的途径多种多样，自动化已经成为互联网的趋势，但是自动化够了吗?平台化，工具化将自动化的工作移交给普通的PD，PM，DE等。

　　所以一个SDET开发一个工具用了一个月却简化了其他业务线20%的工作时间，这样的评估需要很好的衡量。

　　我个人认为测试的质量分为两类，当前规避BUG有效率，未来规避BUG有效率。结合 Test2.0 的理论，BUG更多的不应该发现更应该规避?

　　从管理流程的角度，测试必须从产品idea形成初期进入测试，这样更好的为产品进行风险评估及自动化工具开发。担负客户成功的责任，测试的客户是PM，PD，DE，UED等。更好的从客户的角度出发，换位思考。

　　真正测试的质量也应该由一组数据分析得出，可以是线上故障率，high level BUG数，代码覆盖率等多元metrics综合计算得出。

　　成本：一般测试管理关心的hc，不是本次讨论的重点。

　　如何将测试从管理的角度执行完善，在各个环节都需要技术和流程的支持，好的流程是成功的一般，rules rather than codes。