什么时候开始使用QTP

jiachang

大虾们是什么时候开始使用QTP的，是软件已经手工测试基本正常运行了，然后录制调试脚本准备回归测试
还是一开始就通过编写脚本实现自动化测试
我觉得应该是第二种，但是我不会编写脚本，所以正在迷茫中，还请各位大虾给支招。

yujie6832

回归测试的时候

shotstar

常用在回归测试，因为此时待测系统已经比较稳定，不过产生较大变化。
如果从项目开始就实现自动化测试，需要投入的成本太大，而且因为自动化案例和系统界面结合比较紧密，也和流程结合比较紧密，一旦发生重大改变，会影响很多自动化案例。
所以一般都是在系统测试后期，系统界面和流程都趋于稳定之后，才来做自动化。

jiachang

但这个时候测试已经基本结束了，再用QTP进行测试有意义吗，还是说我只录制有问题的，在手工测试阶段录制还没有解决的问题，然后进行回归测试。但这样相当于测试工作大部分还是手工测试。

shotstar

回归测试通常是把之前的流程全部执行一遍，QTP来做和人来做的区别只是在于时间效率上有很大不同，用QTP去做那些重复做的事情，可以把人力解放出来处理其他的事情。
现在确实大部分的测试都是手工测试，你总不会想把所有的测试工作都交给自动化来实现吧。自动化的部分在整个测试活动中占到20%以上就已经很不错了。
自动化更多的好处是重用，在系统改动不大的情况下，由自动化把之前的案例全部来执行，当你使用他回归的次数越多，使用率越高，越是省了人力的成本。单单只从一个版本来看是看不出什么的，如果你连续做5个版本的测试，回归测试部分全部用人工来做和用自动化做，你可以比较一下效果。

jiachang

呵呵，了解了，谢谢

xiaoyaoke

在回归测试阶段引入自动化测试，是折衷之选，绝非王道。
从整个软件开发流程来说，一般的模型下软件测试都处于整个开发流程的后端，加之我们现在的需求分析，设计阶段的缺失，造成了软件在整个开发过程中要经历多次大面积修改，往往涉及到界面的修改非常多，所以很多时候都是在回归测试阶段引入UI自动化测试。
但真正的初衷绝非如此，而是在软件的前端，需求，设计等等阶段，细化设计，然后稳定UI设计，这样，软件的研发和自动化测试同步进行，在软件进入可测试态之后用同步写成的脚本测试软件的功能性。

虽然现在现实是回归测试阶段引入自动化测试。

zhuwenfeng

并不限制在测试的哪个阶段
感觉手工操作不靠谱的时候，就启用QTP。
比如，注册用户限制1W人，日志文件超过100W条执行删除等等

[ 本帖最后由 zhuwenfeng 于 2010-3-31 09:48 编辑 ]

xiaoyaoke

你说的这些场景完全不必用QTP，如果有权限访问数据库，直接数据库操作，如果没有权限，html Dom，构造http数据包等办法高效快捷还稳定

这个帖子讨论的QTP感觉是系统的引入QTP做测试，而非简单的一个场景一个需求

shotstar

在前段引入是好的想法，但由此产生的维护成本是非常高的。因为QTP做的案例还是和界面已经功能流程有很大关系，这些在前期发生变化的机会非常大，由此会产生很多的维护量。如果想做到从前期介入不是不可以，只不过投入的成本过高，只要有企业愿意这样投入，不是不可以从一开始就介入。这也是目前为什么还是主要都用QTP做回归测试的一个原因吧。另外的原因我想应该是QTP人员本身的开发水平限制，并不是所有用QTP的测试人员都很懂开发，懂得设计脚本，很多企业的应用还停留在录制回放，顶多加上一些简单的脚本维护，对于高端应用QTP来说，测试人员和开发人员做的事情没什么区别了，测试人员在做开发自动化脚本的工作，这个也不是大部分测试人员能做的到的。
以上是我个人对QTP应用的想法，或许再过上1-2年，QTP也许会有更成熟的应用吧。

shotstar

你说的这些不属于QTP应用方面的事情。这只是数据准备方面的事情，你总不会是让QTP帮你一个一个的注册，一条一条的添加吧，不清楚这样做的意义，或者说我不认为这样应用QTP有多大的意义。

mote

qtp也好，其他自动化测试工具也好，首先要评估一下使用自动化测试的价值，如果没有价值的话，没有必要非要自动化测试的。