gotolife为每一个提问者都打上那么一长段字，真有耐心！学习一下！
我现在的问题是设计好了测试过程但很多基础语法弄不太清楚。
我现在的问题是设计好了测试过程但很多基础语法弄不太清楚。我不愁设计，测试用例已经设计了好多年，自动化测试的设计没有问题。现在对我来说重要的技巧语法等问题。我同意设计比语法更重要，但是二者缺一不可 都不是一般人 楼主强人也 原帖由 chbanney 于 2007-6-8 08:41 发表 http://bbs.51testing.com/images/common/back.gif我现在的问题是设计好了测试过程但很多基础语法弄不太清楚。我不愁设计，测试用例已经设计了好多年，自动化测试的设计没有问题。现在对我来说重要的技巧语法等问题。我同意设计比语法更重要，但是二者缺一不可
设计测试用例和设计自动化测试过程还是有一点差别的
举个例子：
背景：8个下拉框，每个下拉框下面有5个配置选项，每个下拉框中的配置选项一模一样。验证每个组合的功能。
用例：完全遍历2个下拉框中的配置，每个组合都检查该配置的功能是否可用，遍历完毕再增加2个重新完全遍历，同样每个组合都要检查其功能性。以此类推，直到8个下拉框中的配置遍历完毕且输出所有组合的测试报告。
自动化测试过程：（？？？）
自动化测试实现：（无非是对象、方法、控制语句来实现）
只要能解决自动化测试的过程如何进行，那么，脚本的实现是很容易的。如果脚本语法上存在问题，那么就去学吧！
产品的配置和功能是千变万化的，每个产品都有自己的特色所在。而编程，俗话说，天下程序一大抄。语言里的东西都是固定的，通过学习语言并参考QTP帮助、MSDN等，只要多学多看，掌握语法是极其容易的。
系统分析师为何比程序员薪水高？因为只要需求分析存在，随便拉个程序员来就能做，只要需求分析符合市场需求，产品就肯定能赚到钱。而系统分析师，不是谁都能干的了的。
实际上，以现在的情形来看，中国的IT职业的发展路线是这样的，这也是较为成功的。
编码 -> 测试 -> 设计
编码 -> 测试 -> 管理
编码 -> 管理
可以看到很多高级测试工程师他们过去或者是程序员，或者至少掌握一门程序语言。学习编程，可以让他们从更多的角度观察问题。 向楼主学习 原来如此 楼主说得好，继续努力中！ 看过了，受益ing 学习就是这样
lzhe sf 都将的太好了
很为感动 态度很重要 想完了应该做 ,不应该光想不做 2周还在摸索中 谢谢楼主分享 关注ING...学习ING...
进步ING... 首先说我是一菜鸟，但也发表一下感言。
楼主有开发基础，所以接触QTP能较快地实现脚本重用，但是这是否就可以称得上是自动化测试框架呢？是不是楼主把开发框架的思想转移到测试里面呢。
最后的感觉是楼主有良好的开发基础，但是测试这方面的理论或许还没到达一种深度。 看了很有感触，学习态度，学习方法确实很重要啊 好惭愧啊，我都没有好好读过QTP的帮助文档、参考手册啥的！:$
搞自动化要涉及各种各样的工具，感觉没那么多时间和耐心好好读帮助文档。
我都是拿来就用，用到哪学到哪，边用边自己琢磨用法和原理。 非常不错的以个贴，看清了路就很好走，自学的人是王道，用你这样的方法自学的才是自学中的王道。顶！ mark一下 原帖由 gwell 于 2007-10-24 00:18 发表 http://bbs.51testing.com/images/common/back.gif
首先说我是一菜鸟，但也发表一下感言。
楼主有开发基础，所以接触QTP能较快地实现脚本重用，但是这是否就可以称得上是自动化测试框架呢？是不是楼主把开发框架的思想转移到测试里面呢。
最后的感觉是楼主有良好的开 ...
当时看到这段话，令我沉浸在很深的思考中……
我当时无法解答这个问题，经过一段时间的实际操作，现在有了一些答案。
脚本的重用性设计，确实可以称得上是测试框架，但是，不是像QTP本身这样支持广泛的框架，而是针对某一产品进行测试的自动化测试框架。
脚本的重用性设计，是受产品所限制的，如果一个产品开发的不够规范，那么重用性设计必然难以进行。
首先，手工测试是为了尽可能多的发现产品的缺陷，而自动化测试是要证明产品的逻辑是正确的或是未更改过的（比如更改某个提示信息，而工具是不知道该提示信息是否存在逻辑错误，通过自动化测试报告来由人工最终确认）。
其次，开发要做的事情，是完成客户的需求，并且在转测试之前，保证交付部分的逻辑不存在缺陷。（事实上开发是不能100%保证不存在逻辑缺陷）
所以，要证明产品的逻辑是正确的，就必须确保自动化测试过程的整个逻辑是不存在缺陷的。重用性设计是保证脚本部分减少错误、降低风险的一种手段。
那么，我们和开发又有什么区别呢？ 不一样要对脚本进行调试、单元测试、版本管理等等等等么……
