这段时间一直都在研究TM(Rational TestManager)的使用,虽然帮助手册都是英文的,但幸好俺的英语一直都还比较good,所以觉得感觉还不错。始终都在担心TM不太适合我们公司的实际使用,而且用了一下RequestPro,好像打开word时也有错,不知道是什么意思。不过回头想想,学肯定是要学的,这里用不上,或许到其他地方就用上了呢!呵呵

好久没有来了,把这几天的学习结果总结一下。我现在还只看到了Implementing Tests那部分,对于比较重要的suite部分还没有真正涉及。一直到Implementing Tests这部分之前,总共还包括了Plan Test、Design Test,之后还有Executing Test、Evaluating Tests,可以说是流程齐全,整个测试阶段分得有条有理,清晰易懂。就我现在已经看完的,我觉得TM中的测试过程就是这样:先利用RequstPro或excel来建立TestInput(也就是测试需求,Test What),然后建立测试计划(Test Plan)。好像也可以不建TestInput直接建测试计划,不过测试计划是必须要建的,不然就建不了其他东东了。建立了测试计划后,再在计划下面建立测试用例包(TestCaseFolder),然后再在这个包下建立测试用例(TestCase),最后将测试脚本与TestCase联系起来就可以执行了。执行的时候可以将TestScript放入suite批量执行,这样就可以很省事了。当然如果觉得这样一步一步的建比较费力,当然也可以编写脚本让计算机自己完成这些工作,不过需要用到TM的API(现在好像还没有,不过可以在VB里面用OLE Viewer来看到它内置的方法和属性)。有了一个清晰的流程,相信工具用起来应该就会比较轻松一些了。无奈现在学的还不深入,有时间真的应该把User's Guide看个两三遍才好。

今天暂时还写到这里了,要学的真的太多了,我现在才理解到,测试既可以说是最简单的工作——一个刚毕业的稍懂计算机的就可以做。也可以说是最难的工作——要想把测试做精做专,需要各方面的知识:编程、网络、系统、硬件……唉,用句流行的话来说就是“我容易吗我?”:)

posted @ 2005-11-25 09:02 LoVeTESt 阅读(146) | 评论 (0)编辑 收藏
 

做软件测试一年多了,越做越觉得自己的知识太少,越做越觉得需要学习的东西还有很多很多。由于我不是计算机专业出身,属于半路出家那种,所以编程方面的能力比较匮乏。现在的测试对编程要求越来越高,不得不学阿。我想了一下,要学的包括:数据库(先把查询方面的SQL搞定吧,别的以后再说了)、vb(以前学过一点点,现在刚入门,准备继续深入)、rational系统自动化测试软件(学习ing)、xml(找到些教程,看看吧,懂总比不懂好啊)。

目前想先学习的就这些了,唉,压力也蛮大的阿……真是测试人人都能做,但并非人人能做好。

posted @ 2005-11-25 08:43 LoVeTESt 阅读(86) | 评论 (0)编辑 收藏
 
在目前的软件行业的项目中,相信有90%以上的项目都是在时间非常吃紧的情况下进行的。由于设计开发阶段占用大量时间,可能留给测试的时间就更少得可怜了。那么在这种时间短、任务重的情况下如何更好地完成系统的测试任务呢?结合我一年多的测试经验,就在此发表一些个人的看法吧,欢迎大家一起讨论。

1. 首先,测试组应该尽早准备测试,不要非等到开发完毕以后才开始进行测试的需求收集、用例设计、实施,不然时间肯定是不够用的。在系统的需求确定以后,测试人员就可以开始随之确定测试需求,并分析需求的测试可行性,其实这也是对需求的合理性、正确性的进一步验证。测试的需求确定以后,就可以开始测试用例设计了。做测试用例设计的时候,如果有系统原型,可以结合原型来写测试用例(如果没有,那你的运气就不太好了,不过没事,也是可以写的)。测试用例准备好了之后,就可以进行评审。可能此时系统开发还没有完,没有关系,如果开发人员对系统设计有所改变,我们只要及时修改我们的测试用例就ok了。等系统开发结束以后,开发人员一提交第一个版本的时候测试人员要立即根据测试用例对系统进行测试。这样可以保证项目时间被充分利用而不会出现开发完了再慌慌张张地写测试用例的局面,即可以节省时间又可以使测试工作做得有条不紊。

2. 在测试用例设计阶段,一定要根据测试需求来确定测试用例的优先级。因为当时间根本不允许你进行完全的测试的时候,为了能够最大限度地保证系统功能的正确性,可能你唯一能做的就是把对系统使用影响最大的功能优先测试完,如果有时间再进行其余测试用例的测试。为了能够说明哪些功能对系统而言是最重要的,就要求我们对用例进行优先级的划分。用例的优先级一般可以简单地分为高、中、低三个级别。执行测试的时候,我们可以优先执行高优先级的用例,因为它们通常都是测试系统最重要的功能的,这部分非测不可,不然系统或许就根本不可用。高优先级的测试完后,如果时间允许,可以再测中优先级的,这部分对系统的影响相对不那么重要,如果没有测试的话,或许客户也不会那么生气,嘿嘿(不是我们偷懒,时间不允许啊!)。最后,如果上帝保佑你,你还有时间,那么就把优先级最低的也测一测吧,这样或许你们的系统会更完美一些。至于如何划分用例的优先级,我在这里就不再赘述了,网上的经典文章很多,大家可以参考参考。

以上是我对项目时间相对较紧的项目而言根据自己的经验的一些小小的总结,希望对各位有所帮助,也希望大家把自己的经验一起拿出来进行分享,大家一起进步,呵呵:)

PS:这是我以前写的,现在也一起搬过来了。

posted @ 2005-11-25 08:36 LoVeTESt 阅读(295) | 评论 (0)编辑 收藏
 
搬家可真累,都已经先后搬了两三次了,嘿嘿,没办法,希望在这常住吧!
posted @ 2005-11-25 08:21 LoVeTESt 阅读(143) | 评论 (0)编辑 收藏
仅列出标题
共2页: 1 2