微软的软件测试方法–（附读后感）

[读后感：一个成熟的软件企业有能力应当选取如下 的测试工艺流程来生产它的软件产品，就像拥有一套标准化的流水线来完成将产品最终定型的任务。而众多无力进行这种经营规模如何在进行“手工”产品加工的过程中严格保证质量呢，我想一个是一人兴邦的原则即有一位统领全局“一把手”来分析需要分析与现实实现的差距，而这样的人才一定要有远大的发展眼光才能足够重视软件品质并基于此开展开发与测试的质量保证。另一种可能性，就是国家的传统部门应当跟上时代潮流，能有相应的软件产品质量保证的质检部门应运而生来研究对这类常常难以定位的产品来进行类似传统商品的质检，而不是被动的依赖几家国有型的生产厂家每年投入大量的政府采购了。并有益于新的竞争机制下有更多的公司成立起来，保证市场的健康发展！]

微软的软件测试方法

对于TL_geong提到的随机测试造成收敛的缺陷趋势出现严重的发散现象，在微软也有。通常Bug Bash会产生超乎寻常数量的Bug。一般我们认为，产生Bug的量越大越好。因为，如果产生Bug的数量少，你很难判断是因为产品的质量确实很高，还是Bug Bash做得不彻底。而且事实往往是后者。 那么对Bug Bash所产生的大量Bug该怎么办微软，我们有“Bug Triage （测试，开发和项目管理，三方会审）”的制度。对于每个Bug，经过会审后不外乎有以下三中归宿（总体上来说）： （1）被确认为“缺陷性”Bug，这样的Bug必须交开发人员解决，然后由原发现人验证。 （2）被调整为非“缺陷性”Bug，不用开发人员作任何更改，但必须将问题纳入产品用户文档，明确向用户解释，并告诉用户如何避免和应对。比如这里举一个假想的例子：产品的某个功能在系统内存严重不足的情况下，会暂时停止工作，并生成很多不易被用户理解的警告信息。这显然是个Bug（按微软的标准），正确的应该是，首先软件不应该完全停止工作，其次不应该多次警告，第三，警告信息应简明易懂，并给用户以措施和建议。但是考虑到，一方面这种情况在用户实际使用产品时发生的机率很低，而另一方面，从开发角度，解决这个问题有很大的技术难度，影响面也太大。这种情况下会把这个Bug改为“文本性”Bug，也就是要求文本遍写人员将这一情况作一技术性解释，并建议用户不要将此产品同其他消耗大量内存的软件同时使用。这类的Bug在Bug Bash中很常见，因为大家在这种测试活动中思维方式比较超常。（3）被完全否定，立刻关闭，不再纠缠。这类的情况在Bug Bash中也很常见。因为参与Bug Bash人并不都很了解产品功能的准确用法，误 是难免的。尽管对这类问题没有直接的后续措施，但这些信息仍然是有一定价值的，因为将来用户中的新手很可能会犯同样的毛病，而产品支持部门如果预先有这样的经验，就能及时准确地提供帮助。所以这些信息要保存在Bug的管理库中，以备将来产品支持部门查询。 经过这样的会审，筛选，如果（1）（2）类Bug，特别是（1）类Bug仍然很多，那测试部门很可能需要重新论证原先的测试计划和测试用例设计，看是否需要增加测试用例。必要时还要尽早提出更改项目总体计划和发布日期。大量Bug的出现也许不是件愉快的事，但和把这些Bug留给用户相比，代价要小得太多了。总之对于产品的Bug，要相对待身体的疾病一样，切末讳疾忌医。