什么时候开始使用QTP
大虾们是什么时候开始使用QTP的，是软件已经手工测试基本正常运行了，然后录制调试脚本准备回归测试还是一开始就通过编写脚本实现自动化测试
我觉得应该是第二种，但是我不会编写脚本，所以正在迷茫中，还请各位大虾给支招。 回归测试的时候 常用在回归测试，因为此时待测系统已经比较稳定，不过产生较大变化。
如果从项目开始就实现自动化测试，需要投入的成本太大，而且因为自动化案例和系统界面结合比较紧密，也和流程结合比较紧密，一旦发生重大改变，会影响很多自动化案例。
所以一般都是在系统测试后期，系统界面和流程都趋于稳定之后，才来做自动化。 但这个时候测试已经基本结束了，再用QTP进行测试有意义吗，还是说我只录制有问题的，在手工测试阶段录制还没有解决的问题，然后进行回归测试。但这样相当于测试工作大部分还是手工测试。 回归测试通常是把之前的流程全部执行一遍，QTP来做和人来做的区别只是在于时间效率上有很大不同，用QTP去做那些重复做的事情，可以把人力解放出来处理其他的事情。
现在确实大部分的测试都是手工测试，你总不会想把所有的测试工作都交给自动化来实现吧。自动化的部分在整个测试活动中占到20%以上就已经很不错了。
自动化更多的好处是重用，在系统改动不大的情况下，由自动化把之前的案例全部来执行，当你使用他回归的次数越多，使用率越高，越是省了人力的成本。单单只从一个版本来看是看不出什么的，如果你连续做5个版本的测试，回归测试部分全部用人工来做和用自动化做，你可以比较一下效果。 呵呵，了解了，谢谢 在回归测试阶段引入自动化测试，是折衷之选，绝非王道。
从整个软件开发流程来说，一般的模型下软件测试都处于整个开发流程的后端，加之我们现在的需求分析，设计阶段的缺失，造成了软件在整个开发过程中要经历多次大面积修改，往往涉及到界面的修改非常多，所以很多时候都是在回归测试阶段引入UI自动化测试。
但真正的初衷绝非如此，而是在软件的前端，需求，设计等等阶段，细化设计，然后稳定UI设计，这样，软件的研发和自动化测试同步进行，在软件进入可测试态之后用同步写成的脚本测试软件的功能性。
虽然现在现实是回归测试阶段引入自动化测试。
QTP新兵：
并不限制在测试的哪个阶段感觉手工操作不靠谱的时候，就启用QTP。
比如，注册用户限制1W人，日志文件超过100W条执行删除等等
[ 本帖最后由 zhuwenfeng 于 2010-3-31 09:48 编辑 ]
回复 8# 的帖子
你说的这些场景完全不必用QTP，如果有权限访问数据库，直接数据库操作，如果没有权限，html Dom，构造http数据包等办法高效快捷还稳定这个帖子讨论的QTP感觉是系统的引入QTP做测试，而非简单的一个场景一个需求
回复 7# 的帖子
在前段引入是好的想法，但由此产生的维护成本是非常高的。因为QTP做的案例还是和界面已经功能流程有很大关系，这些在前期发生变化的机会非常大，由此会产生很多的维护量。如果想做到从前期介入不是不可以，只不过投入的成本过高，只要有企业愿意这样投入，不是不可以从一开始就介入。这也是目前为什么还是主要都用QTP做回归测试的一个原因吧。另外的原因我想应该是QTP人员本身的开发水平限制，并不是所有用QTP的测试人员都很懂开发，懂得设计脚本，很多企业的应用还停留在录制回放，顶多加上一些简单的脚本维护，对于高端应用QTP来说，测试人员和开发人员做的事情没什么区别了，测试人员在做开发自动化脚本的工作，这个也不是大部分测试人员能做的到的。以上是我个人对QTP应用的想法，或许再过上1-2年，QTP也许会有更成熟的应用吧。
回复 8# 的帖子
你说的这些不属于QTP应用方面的事情。这只是数据准备方面的事情，你总不会是让QTP帮你一个一个的注册，一条一条的添加吧，不清楚这样做的意义，或者说我不认为这样应用QTP有多大的意义。 qtp也好，其他自动化测试工具也好，首先要评估一下使用自动化测试的价值，如果没有价值的话，没有必要非要自动化测试的。
页:
[1]
