评论

#Edmond 发表于2006-07-04 19:37:00  IP: 211.162.8.*

Kerry
拜读了你的文章,关于最后的问题,我说说我自己的看法,我还是比较倾向于第二种.两种方式的好处和坏处你都已经说明的很清楚了,我只说明我选择第二种的原因.因为由专门的团队去负责会形成一种机械的方式去完成脚本.他们可能只是写些常用的scripts,因为他们对测试中某些特殊的问题并不能有正确的遇见.而测试人员只会拿着写好的脚本run一遍就可以了.如果将产品承包给团队,TA人员参与到写script和测试中去,他们对产品中的某些问题可能会产生自己的独特的case script,这样可能会更好的去发现问题.另外一方面也可能需要leader去作一下正确的引导作为辅助的措施.个人意见,如有不对,希望指正.

#Kerry 发表于2006-07-04 20:06:00  IP: 61.191.27.*

agree, thanks! TA team 自己去完整地完成一个task, 可以从TA角度去看问题，脚本结构会好些、更流畅些。作为TA engineer, 了解功能特性也是必要的。

#ll 发表于2006-07-05 08:20:00  IP: 61.191.27.*

我觉得首先，TA工程师应该是测试工程师，这一点首先得弄清楚。
如此，我也比较倾向于第二种做法，TA工程师不了解产品，不能写出很好的脚本，尽管和case完全一致；其他测试工程师执行他的脚本很费劲，好不容易得出个结果，还不一定是自己想要的；我们目前的情况就是如此。

#Derek 发表于2006-07-07 10:27:00  IP: 218.108.8.*

是否可以有这样的考虑：
1、为将来可适用性强（针对多平台，多中测试要求）的测试需求而预留合适的资源去开发基础的TA平台。毕竟我们目前所能得到的所有TA框架根本不可能是包罗万象的，可以选择比较合适的几个进行整合。并针对公司的产品做小规模的扩充，可直接在框架之上，也可以根据具体需求做些系统级的小扩展。
2、TA的实现不仅是要实现自动化。更重要的一点，或许是可以帮助严格地定位缺陷发生的位置和条件。因此，在这点上，不能光依赖于生硬的脚本执行，而要引进系统的测试方法和模式。TA脚本开发是否可以从这方面多作考虑。
3、为什么我们只能余兴事先设计的有限CASE？TA所谓自动化的一面有待更智能化的提高。有几样事情我们可以试着去做：
1）对CASE的智能化管理和跟踪，在有限基本脚本集的基础上建立动态的执行CASE集。
2）TA脚本执行步骤的精细化与监控。
3）测试的策略管理与资源优化及分配。

#Derek 发表于2006-07-07 10:46:00  IP: 218.108.8.*

TA的最伟大目标：实现结构化、智能化的动态脚本集与相应的测试模式。
可参考的模式：
1、谓词驱动的测试。
2、UML表述的CASE与TA脚本的相互映射。
3、CASE管理与执行状态集的自动机（或状态机）模型。

# Derek 发表于2006-07-07 12:16:00  IP: 218.108.8.*

从技术可行性考虑，TA几乎可以实现手工操作可能实现的所有操作。唯一的缺点是资源的约束和依赖于测试的模式。目前的TA脚本可共用性差，开发时考虑的层次过低，局限于短期应用，是引进TA过程中最头痛的问题。但，对于一个足够持续的产品开发链，TA所带来的经济效益和可靠性等方面也是显而易见的。
手工操作的好处是可以机动地引进一些操作，从宏观的角度，针对性比较强，在可操作的范围内，想到什么做什么。

#Kerry 发表于2006-07-08 11:46:00  IP: 61.191.27.*

To Derek: TA脚本相对每一个test case不是独立的，不容易形成动态执行的test suite. TA在UI验证、客户经验、逻辑、创造性等方面还是有很大局限。对于“结构化、智能化的动态脚本集与相应的测试模式”，能给出一个具体例子，或参考文献？“为将来可适用性强（针对多平台，多中测试要求）的测试需求而预留合适的资源去开发基础的TA平台”，如何理解？

#Austin 发表于2006-08-09 09:50:00  IP: 61.191.27.*

大家好，经常关注朱老师的blog.学到了不少好东西:-)
我想能不能再增加一个模式：3)将TA的工程师，派发到各个项目测试组里去。以提高每个项目组的自动化测试覆盖和自动化测试效率。提高自动化测试覆盖率和效率是每一个TA的工程师的主要工作任务和职责。这里的好处是：TA跟进项目，没有游离在项目之外;知识的互动是双向的。但TA的工程师之间缺少了沟通，不利于TA作为一个整体团队的发展。

#Kerry 发表于2006-08-09 12:27:00  IP: 61.191.27.*

Good suggestion, thanks!

#asf 发表于2006-11-15 09:35:00  IP: 59.40.182.*

现在拍马屁的越来越多了.我也来拍拍,的确不错,好文章.

#liuyang630 发表于2006-12-26 23:59:56  IP: 222.131.143.*

呵呵，99%的理论，没有实践又有什么意义呢？现在国内的测试行业已经不缺乏理论专家了。个人见解，请见谅^_^

#KerryZhu 发表于2006-12-27 09:56:53  IP: 61.191.27.*

实际上国内实干的人很多，理论专家很少。据我所知，大师级的人物99％来自国外。从我们自身讲，做出国际一流产品和服务（占全球市场份额65％）， 有200多人测试的团队，7年多历练，包括在自动化测试上的经验和教训，涉及服务器、Windows/Java client、、数据库、XML和Web等，经验不少，但理论有待加强。

#am2000 发表于2006-12-30 10:20:27  IP: 61.191.16.*

理论结合实际才是最好的..........

#lantianwei 发表于2007-12-31 19:59:42  IP: 218.104.39.*

TO Kerry
个人认为自动化人员应该在手工测试就介入到项目中(也做手工测试),这样可以更好的把控自动化脚本的设计;当然如果手工人员可以提供非常详尽的自动化用例,那也可以写出好的脚本,但基本上很少有公司可以做到.
TO Derek
对于你说的自动化用例自动产生不知道你们现在有没有已经实现了,我对这方面技术非常感兴趣,我觉得自动化测试就应该做到这一步.

#KerryZhu 发表于2008-01-01 16:45:21  IP: 61.191.27.*

Lantianwei, 同意你的看法。新年快乐!

#julian_zhu_2002 发表于2008-05-05 10:58:34  IP: 203.110.162.*

拜读大作，收益匪浅