我想谈谈自身的经历。

　　我毕业后在外包公司工作，客户是一家美国公司，产品发展前景挺好，也有一笔不菲的风险投资。我想说说他们的测试管理制度。

　　首先，他们有一个很好的资源共享平台，我们叫Wiki，上面包括每一个版本的任务，每一项任务的开发负责人及测试负责人，相关的Spec以及其他开放文档。而且，每当这一版本的任务快完成时，下一版本的任务的雏形就出来了。

　　其次，开发和测试严格按照软件生命周期执行。

　　第一阶段：

　　需求出来后，开发和测试同步进行，开发完成代码实现，测试完成test outline和test case，这些文档都会上传到Wiki上。我们在理解Spec和完成testcase的时候，会及时提出自己的问题，这些问题一般在第二天就能从开发人员得到反馈。而test outline和test case最终完成后也要经过开发人员的验证，有时他们会提出自己的意见，测试要点和一些你未曾想到的case。

　　第二阶段：

　　新功能的测试阶段，测试提交bug，开发修改bug，这一过程由JIRA管理。

　　第三阶段：

　　回归测试：

　　每一个版本的下半阶段都是做回归测试，这是一个比较漫长的过程，一般分两部分，一是执行所有的case（一万之多，有赶超两万之势），二是执行任意测试。在执行case的时候，我们还要同时更新case，有些是更新内容，有些是添加新的bug，有些case可能会过时。当然，新的bug也会提交到JIRA。在这个阶段，测试人员会安排在不同的平台上测试。可以说，在做回归测试的时候，测试覆盖率极高。

　　第四阶段：

　　预发布版本测试：

　　做完回归测试会形成一个较稳定的版本作为预发布版本，预发布版本会被部署到另一台测试服务器上。这时候需要在不同平台上做一次QL（Quick Look）及任意测试。预发布版本上一般不会再迁入changlist，除非在此之上发现了较严重的bug，就会有新的r2的预发布版本以及再一次的测试。

　　第五阶段：

　　内部测试：

　　新版本发布前一两天可以说是全民皆兵，公司里大大小小所有人都进行测试，包括CEO。（当然CEO不会自己来报bug，她会把问题反馈给我们的技术副总裁）。当然他们所报的bug也会成为我们的谈资。作为测试人员，我们不仅追求bug数量，更要追求bug被fix的概率。当发现一个bug时，首先我们得确定它不会成为won't fix或invalid的问题，并且它can be reproduced，然后它不会duplicate某个已有的bug，如果这个已有的bug已经被close了，就应该reopen它。而这些非测试部的人不管三七二十一，看到是个问题的就报，一天下来新加的bug数就该让相关的开发人员头疼死了。好在这些问题都会一个个地得到它们应有的解决方式。

　　第六阶段：

　　产品发布测试：

　　产品发布前会在和产品环境相同的服务器上做一次QL（Quick Look）和任意测试，产品发布后又会在产品服务器上做一次QL（Quick Look）和任意测试。

　　第七阶段：

　　测试整理：

　　这一阶段主要是整理在这一版本生成的测试文档和测试用例，新功能的用例和一些之前未覆盖的用例会被导入测试用例管理工具。

-------------------------------------------------------------------------------------------------

转自：http://www.51testing.com/?uid-344504-action-viewspace-itemid-831768