经常在网上看到有在国内从事软件测试的同行抱怨:测试不受重视,测试管理混乱,产品质量差等问题。说到底这都是管理上的问题。
我想谈谈自身的经历。
我毕业后在外包公司工作,客户是一家美国公司,产品发展前景挺好,也有一笔不菲的风险投资。我想说说他们的测试管理制度。
首先,他们有一个很好的资源共享平台,我们叫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)和任意测试。
第七阶段:
测试整理:
这一阶段主要是整理在这一版本生成的测试文档和测试用例,新功能的用例和一些之前未覆盖的用例会被导入测试用例管理工具。
【在国外做软件测试工作的体会】相关文章:
软件测试求职信01-29
给孩子做智力测试有必要吗?12-01
月经多久后可以做早孕测试08-17
月经过了多久可做早孕测试08-09
诚信教育在国外12-07
女性月经过了多久可做早孕测试08-23
孩子在国外应该学几门语言10-18
游客在国外脱团怎么处理05-12
抑郁测试心理测试06-28