● 制定测试计划中，人员不充分，经验不足怎么办？从工程的角度考虑问题，不仅仅是要求测试人员之间分享经验，还需要有效的标准。一个好的模板，是节约人力成本的好办法。还能弱化对每个人的依赖度。还要检查需求细不细，避免主观语句（性能高，响应速度快等这样的形容词），速度响应快，快到多少秒。一定要量化需求，而不是主观感受。凡事以数据说话，这样才能有说服力。

　　● 如何提高测试用例的编写水平？第一，积累测试素材，比如对于文本框的验证，一般都是验证那几项，有效数值，无效数值。空格，空等等。这些测试用例在每个项目中都可以反复使用。第二，测试方法的复用，对于有继承性的项目来说，用之前编写的测试脚本或自动化测试工具以达到测试方法的复用。

　　● 如何判定测试是否充分？验证到每个对象的每个属性值，结合自动化做深度测试。

　　● 测试对bug的理解不一致怎么办？有争议的地方和开发人员商定，确认后建立checklist或者user guide line，列出检查清单。以后如发现此问题，对照清单解决问题。

　　● 如果衡量缺陷的质量？1）检查环境，测试环境是否正常2）是否可重现3）检查是否是重复bug 4）详尽的操作步骤5）问题的定位6）要能提出修改意见就更好了

　　● 缺陷的分类比一般的分类多的项有：测试引起的；由其他bug引起的；功能未实现的。

　　执行测试的过程当中，限定解决缺陷的时间，即check-in ETA估计完成时间。真正把每个问题都落实到微观。这些缺陷分配是由Triage Team来做,由上面说的高层领导组成，试想这样一群人看过90份文档之后，对项目的细节都清清楚楚，自然能够有效的保障产品的质量。通过缺陷管理平台，微软的高层清楚的知道某个开发人员的代码有效率是多少即使他们未曾谋面。目前有很多跨地域管理的问题，管理者不可能时刻都盯着手下的人在做什么。重要的得到信息的方式，做到用数据管理，以事实说话。

　　测试后期到准备发布阶段，发布评估标准（Release Criteria）：

　　● 95%的测试用例通过率，且持续时间>5天。

　　● 允许有5%的case不通过，但级别不能是重要的case..

　　● 代码覆盖率>85%

　　● ZBB零bug边界，保持15天

　　测试项目之中的管理，以数据为依据，分析bug的曲线，做到防微杜渐，知道目前的项目进展状况并估算项目的进度是否在可控范围内，才能保证项目顺利进行。对于项目的流程的制定，过于复杂的流程如果过于难以执行，则会降低纪律的可执行力，所以针对不同的项目制定不同的流程。但是一旦制定，就要落实。分配任务的时候要落实到每个人头上，不能把一个任务交给一群人做，要明确到每个人做什么模块。合理的制定里程碑之间的工作计划，循序渐进逐步完善：

　　● 短期计划：制定计划模板，添加bug的规范，check-in之前做代码检测。

　　● 中期计划：调整缺陷管理库，做到测试用例和bug关联

　　● 长期计划：开发测试工具，做到自动化测试。

　　2天微软的测试培训时间并不长，也没有介绍任何的测试工具，但是确确实实的给我们讲了一种做项目的方法和态度。微软之所以能够成为做产品的大哥，关键在于对产品质量的要求，“在质量面前什么都不重要”。我对于项目的朴素的理解就是，每个阶段把握每个细节，认真落实文档，目的是让其他人帮你想遗漏的地方，然后严格遵循文档开发，用实际的数据说话。每个人都担当起QA的职责，监督团队的其他人，互相促进和发展，项目的质量就会大有保证。