有付出必有回报。 有得必有失。 有酸甜苦辣的生活才是真正的生活。 我愿意像蜡烛一样发光发热,来照亮我的人生征途!! 日志上的资料都是我个人喜欢的或是对自己有用的,当然有很多是从别人处转载来的,但是都是为了共同进步!希望和大家一起分享! 牛年让自己更"牛"一点!!!

近期测试工作的总结

上一篇 / 下一篇  2008-12-24 09:55:41 / 天气: 晴朗 / 心情: 高兴

近期测试工作的总结

最近主要的工作是

1.      SmartControl管理层测试的测试需求分析和用例的设计

2.      SmartControl公司层面和流程层面导入功能的测试

测试流程:

1.      本次管理层测试模块的需求评审和原型设计评审比较到位,所以需求的变动比较少,更重要的是,需求和原型设计是测试人员做测试需求分析的一个很重要的标准,是测试人员工作的基础。所以测试需求分析做得很顺利,(利用工具Rational ROSE画用例图,活动图和功能流程图)工作效率比较高。在做测试需求分析的时候,对管理层测试模块的测试范围就很明确了,再把各个功能点的显式需求和隐式需求进行挖掘,就不会遗漏需求了。

2.      设计测试用例。对用例的设计要用到多种设计方法,如等价类边界值方法,流程图法,状态图,因果图等方法,但原则是:用最少的用例覆盖最多的需求,用最少的用例发现最多的BUG

3.      执行用例。在做用例执行前,应该对提交过来的测试版本做一个冒烟测试,也可以先执行用例中优先级别为高的用例,这样可以对软件的质量有一个基本的认识。如果连最正常的功能都没有实现,这样的版本再继续测试下去只是浪费时间,根本没有任何意义。如果是这样的测试版本,测试组应该打回开发组,让他们重新提交一个至少实现了正常功能的版本。到了正式执行用例的时候,应该严格按照用例中的描述步骤来测试。如果与我们的预期输出不一致,我们要多次重复执行,直到确认这是一个BUG,我们才能往BUG库上记录,记录的时候应该尽可能地描述清楚,最好的效果就是让开发人员一看就明白问题出在哪里,在这一点上,我做得不够好,今后一定会往这方面加强。

4.      系统的回归测试。开发人员修改BUG后,我们要进行验证,如果此BUG确实修复了并且没有引入新的问题,我们就可以关闭此BUG。如果此BUG仍然存在,或是引起了别的问题,我们应该重新开启此BUG,并描述清楚新的问题是如何引起的,以便让开发人员定位问题.

5.      编写测试报告。主要对此次测试过程进行评价,对此次测试的版本进行总结,对各版本的BUG进行统计,BUG严重性等要用图表形式表示出来以及对测试结论是怎样。

 

在做完一个项目之后,应该进行个人的总结。在本项目中,你学到了哪些知识和经验,有哪些地方做得好,哪些方面需要改进。有总结才会有进步!

 

 


TAG:

 

评分:0

我来说两句

Open Toolbar