测试人员的考核：
　　用Bug对测试人员进行考核，意味着开发和测试开始对立
　　综合考核
　　选对人，“将能君不胜”
　　有价值的测试人员？
　　一个测试团队，测试人员水平很高，发现的bug少，而且都是核心问题；
　　测试真的需要写Test Case吗？ -- 需要看写Case占用的时间占总测试时间的时间百分比
　　高水平与低水平测试人员的区别：Case的覆盖度和对业务的理解；
　　自动化测试过程，而不是自动化测试
　　测试的两个指标--质量振幅；高效的提高软件测试用例的覆盖度
　　软件测试的目标是什么？
　　稳定控制软件产品质量的振幅
　　高效提高Test Case 的Coverage（通过Case的复用；数据驱动；有效的测试设计方法）
　　软件测试管理的两个派系？ -- CMM和敏捷
　　怎么做项目分级，在这个基础上进行软件测试裁剪呢？
　　对测试过程进行裁剪
　　测试策略的制定
　　确定测试需求；
　　确定测试目标
　　确定测试类型和方法
　　测试风险分析
　　测试计划制定--5W
　　确定测试的目标、方法、环境、工具等（功能性需求；非功能性需求--性能指标、可靠性稳定性指标、安全性指标）
　　确定时间段
　　确定资源
　　自动测试分析（解决什么问题；花费多少成本；提高多少效率）
　　确定测试过程监控方法
　　风险分析
　　如何提高工作效率
　　可复用的产品多（指标：测试资源复用率）；无用的工作少（指标：有效测试工时率）；和开发的配合好（指标：协作点数量，协作点正确率）；测试项目进度贴合度好（指标：项目变化率，工期贴合度）；自动化测试提高效率（指标：自动化手工测试用例率）
　　测试用例的覆盖度
　　是个求积分的过程
　　有效度量测试用例覆盖度增加的条件（定义baseline；定义颗粒度--单位；单个功能点进行有效的规整--确定小测试范围；提高的方式是功能点的组合和测试数据的增加；每轮增加case的量和率）
　　我的看法：
　　不写case，那么测试的大价值在人身上，而非case或工具上，这时如果有人员流动，risk会很高；而且如果对于经验相对不足的测试人员，即使时间很短，让其使用探索式测试，很可能会陷入局部优，case的coverage低于写case的Coverage，从而导致效率低下
　　测试，本身是一门综合能力要求相对较高的专业，那么要求测试人员无论从业务，还是测试能力上都要有广度，并有相应的深度；中庸之道很重要 ，走某一个极端都会物极必反
　　对于如何提高测试效率，测试人员可以在某方面通过改进测试得以提高，但某种程度上起决定作用的还是Boss对测试的重视程度，以及测试人员在整个项目过程中的地位
　　以人为本；以项目ROI为本