今日將框架完整走通，給測試試用。但從測試表情看，顯然沒有surprise的意思，反而有種因為改變使用習慣並要學習新框架的厭煩。
儘管事前，我們已經對需求做過自認為相當全面的分析，而且在框架設計上也充分進行了斟酌和權衡。但是，結果就是這樣的。
當然了，分析這個原因的前提，在於我對自己的要求還是挺高的。期望也是挺高的。那麼，原因到底在什麼地方了？人如何才會surprise呢？
驚奇，從字面上講，就是超出其期望。我們在做軟體的時候，想到的是如何滿足需求。要考慮如何超出其需求，確實比較難。因為這和正常工作是不一樣的。
聯想起windows xp，其實超強的使用者體驗，一定是可以讓客戶有surprise的感覺的。超酷的介面、超酷的動畫、超酷的自動化！
我們將我們的客戶想像成享受型的，那麼，
第一、要滿足他們的懶惰心理。能不用做的就不用做了。要做的，最好也能不做、或者少做。拿我們的測試來說，說到程式設計就頭疼。儘管你可以讓框架簡單，但是程式設計還是必不可少的。因此，從測試看來，如果有腳步錄製（不需要寫**了），那就非常好了！
第二、要滿足他們的獵奇心理。男人和女人都有這種心理。表現起來可能不大一樣。談到工作，也是如此。如果工作介面總是一樣的，對他們絕對是創造力的慢性毒藥。
當然了，這些分析，並不一定都能對應到目前的情況上去。可是有一點情況必須清楚，測試們為什麼要一些功能。下面是在試用過程中提到最多的，也是最關心的。
自動錄製指令碼
不要修改原始軟體版本
第1個剛才已經分析了。第2個，表面分析起來非常奇怪，因為在我看來，給軟體增加乙個每日構造，構造乙個適合自動化測試的版本，是非常容易，也是非常可以接受的事。但是對他們來說，好像就是不容易理解。細細分析起來，可能這是角度的問題。因為測試是懷疑一切的，只要修改了程式，他們可能潛意識裡就會認為這個程式已經不再是原來的程式了。
不管分析如何，總之這次演示並沒有預期中的效果出現。看來我的功底還是欠缺啊！忽視了最重要的懶惰心理，也許是沒有surprise的最大原因。但願我以後可以做到！
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...
自動化測試框架指南
這 是我以前寫的一篇文章，用於整理自己對自動化測試的理解。當時寫這個文章的目的，是因為剛剛掌握qtp，又使用自動化測試參與公司乙個大專案的測試，結果 發現原來掌握qtp距離自動化測試還有很遙遠的路要走，原來一直以為掌握了qtp的指令碼編寫 可以寫出所有的測試方法指令碼則自動化測試就可以大功告成了。但...