讨论，关于可视化自动测试框架的问题

novelty14

各位论坛里的大侠，你们好，我们是诺沃帝公司的技术人员，现在想跟大家讨论一下关于软件自动化测试的问题，通常一个自动化测试从现在的使用QTP录制-回放-加检查点模式，升级一下就可以到自动化测试框架模式，录制脚本即写测试用例，脚本支持自动转化为文字版手工测试用例，这两个比较实用 。
    这样的话，在开展评审的时候，就可以直接看文字版的，避免了不懂代码的业务人员无法评审的问题 。
    但是这世界哪会这么完美，也有问题啊，系统没出原型之前，拿啥录制啊，我靠，纯手敲的话对测试人员的代码功底要求就太高了 ，这会逼死人的。没有框架支持，QTP在项目上100%没法用，一个是需求老变，再一个，系统上线甲方要验收用例，你给人家一堆vb脚本，甲方不得抽死 然后还得重新写一遍文字版的，累死 ，最终忙死。QTP上层也需要框架支持，需要能解决对象识别和实现自动生成脚本的问题。
    那现在跟论坛里的大侠讨论一下，手工测试虽然比较实用，但是也避免不了有诸多问题，那关于可视化自动测试框架的问题，同行业里的大侠有何见解？

novelty14

各位，发帖很累的，麻烦支持下啊。。。

黑羽祭

回复 1# novelty14

1.像你说的“软件还在没出原型的时候”，自然还是要以手工测试为主，不适合开始做自动化。
2.“需求老变”也不适合做自动化，后期维护成本太高。
3.给客户验收哪有给脚本的？给测试用例文档嘛。4.不是所有的测试都用QTP来做的。

        不是所有的项目一上来都适合做自动化测试框架的，需要经过一定的分析的，可以在软件刚成型的时候，给出计划，分析何时开始进行自动化测试框架的介入，分析使用哪种自动化测试工具，分析控件是否能都被识别，分析人员、软硬件、时间是否支持，分析领导是否支持，等等一系列分析，然后才开始着手的。
        我个人的理解是，不是为了做自动化而做自动化，应该是以能节省出更多人力和时间而做自动化。要明确做自动化是为了什么，就知道该怎么做了。
        以上是我的一些个人观点，欢迎讨论。

novelty14

回复 3# 黑羽祭
Thanks