軟件測試技術的發展方向(2)

　　這些問題可以在設計的時候就提出，而不是等binary出來，然后去測試，然后再發現問題。測試架構師可以通過自己寫一些Demo來了解上面這些技術是如何work的。

　　當架構師去review開發人員的code的時候，可以先大概了解整個軟件的架構，哪些模塊是負責處理什么的，不需要深入到API的細節; 等了解到哪些是關鍵的路徑，比如如何獲取secret key，然后再深入去了解這段API。 之前有些文章提到API的參數處理，其實這里面不需要過多的關注，特別是Java和.Net的程序，因為這里面有的類型判斷，所以一個處理String參 數的API不可能去接受一個Int型的參數，編譯的時候就無法通過。 碰到自己不熟悉的API，最好的方法，一個是Google一下，另外就是自己寫個簡單的程序用一下這個API就豁然開朗。

　　另外一個是，多從開發的角度其思考問題，最好有空就自己去寫一些實用的程序。思考程序是如何設計的。

　　1)網上短網址服務，你有想過這個短網址生成的算法是什么，如何能做到能最短?怎么查詢?你也許覺得會用key-value的NoSQL。那么，如果對于同一個URL，如果要重用已生成的短網址，你怎么用key-value的NoSQL來解決?

　　英漢詞典的檢索和這個很相似，如果通過英文查漢語，又通過漢語查英文?如果是N多種語言的互相翻譯呢?你的數據存儲和檢索如何做呢?

　　2)當我看到Dropbox這樣的云同步的軟件的時候，我不知道你是否會和我一樣會去思考，在多個設備間的文件同步是怎么做的?如果網盤上有幾 萬， 甚至幾百萬個文件，當要和我的本地數據同步時，他如何比較經濟地知道哪些文件更改了?需要向服務端同步或是向客戶端同步。更進一步，你有沒有想過沒有中心 結點的文件同步問題?你有沒有想過，文件沖突的問題?

　　3)我們的新員工入職的時候，有一些公司會給新員工的帳號生成一個隨機口令，然后新員工可以在登錄后修改口令(我一直在想我們的銀行應該為用戶 生成 一個隨機口令，而不是設置一個6個0或是6個8的初始口令)。那么，對生成隨機安全口令的算法知道怎么做嗎?如果你寫出這個算法來了，你怎么證明這個算法 是足夠隨機，生成的密碼強度足夠大的?(你會發現，測試口令是否隨機是否安全的程序，會比生成器更難寫)

原文轉自：http://www.uml.org.cn/Test/201206151.asp