我不知道我理解的对不对，是这样的，QTP用于回归测试，但版本功能确定下来，且不会有改动，就可以对这些确定的功能进行回归测试，想想一台机器上跑着脚本就把整个回归都做了，你只要到最后看结果就行了，已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归，你在另一台机器上做新功能的最后确认测试，并行处理。此外对于大型网站的固定流程测试，或整个产品的回归测试会有固定的人来做，如果人工耗时很长，可以晚上用QTP跑脚本，早上上班直接看结果。这样看来是省时的，框架如果搭建好，就会省时很多，可是我还没有学到那里，所以我也不能发表什么了 回复 6# 玩不转
我不知道我理解的对不对，是这样的，QTP用于回归测试，但版本功能确定下来，且不会有改动，就可以对这些确定的功能进行回归测试，想想一台机器上跑着脚本就把整个回归都做了，你只要到最后看结果就行了，已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归，你在另一台机器上做新功能的最后确认测试，并行处理。此外对于大型网站的固定流程测试，或整个产品的回归测试会有固定的人来做，如果人工耗时很长，可以晚上用QTP跑脚本，早上上班直接看结果。这样看来是省时的，框架如果搭建好，就会省时很多，可是我还没有学到那里，所以我也不能发表什么了 回复 6# 玩不转
我不知道我理解的对不对，是这样的，QTP用于回归测试，但版本功能确定下来，且不会有改动，就可以对这些确定的功能进行回归测试，想想一台机器上跑着脚本就把整个回归都做了，你只要到最后看结果就行了，已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归，你在另一台机器上做新功能的最后确认测试，并行处理。此外对于大型网站的固定流程测试，或整个产品的回归测试会有固定的人来做，如果人工耗时很长，可以晚上用QTP跑脚本，早上上班直接看结果。这样看来是省时的，框架如果搭建好，就会省时很多，可是我还没有学到那里，所以我也不能发表什么了 我不知道我理解的对不对，是这样的，QTP用于回归测试，但版本功能确定下来，且不会有改动，就可以对这些确定的功能进行回归测试，想想一台机器上跑着脚本就把整个回归都做了，你只要到最后看结果就行了，已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归，你在另一台机器上做新功能的最后确认测试，并行处理。此外对于大型网站的固定流程测试，或整个产品的回归测试会有固定的人来做，如果人工耗时很长，可以晚上用QTP跑脚本，早上上班直接看结果。这样看来是省时的，框架如果搭建好，就会省时很多，可是我还没有学到那里，所以我也不能发表什么了 回复 6# 玩不转
我不知道我理解的对不对，是这样的，QTP用于回归测试，但版本功能确定下来，且不会有改动，就可以对这些确定的功能进行回归测试，想想一台机器上跑着脚本就把整个回归都做了，你只要到最后看结果就行了，已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归，你在另一台机器上做新功能的最后确认测试，并行处理。此外对于大型网站的固定流程测试，或整个产品的回归测试会有固定的人来做，如果人工耗时很长，可以晚上用QTP跑脚本，早上上班直接看结果。这样看来是省时的，框架如果搭建好，就会省时很多，可是我还没有学到那里，所以我也不能发表什么了 做压力测试用loadrunner
页:
1
[2]
