可以說，誰掌握了功能測試和效能測試的精髓，誰就能在測試外包市場中佔據技術制高點。本文正是為這類軟體服務型企業出謀劃策、提供測試技術決策參考。
雖然功能測試是絕大多數軟體都無法迴避的，但多數開發企業不諳其中滋味，所以，測試外包市場才會如此繁榮而且規模日益壯大。目前，功能測試已跨越了單靠手工敲敲鍵盤、點點滑鼠就可以完成的階段，正朝著自動化和智慧型化方向發展。自動化是指各類測試工具已經得到日益廣泛的應用; 智慧型化是指測試人員從指令碼編制、執行、除錯到結果分析乃至測試方案改進，都需要有深入的了解。
而效能測試的重要性是隨著網路應用的發展而發展的，由於網路環境、資料庫環境、應用伺服器環境、系統平台和技術等的複雜性和多樣性，軟體效能非常難於控制。雖然，改善系統效能不是單單依靠效能測試就能完成的，但效能測試至今仍是控制效能的非常有效的手段，在軟體的能力驗證、能力規劃、效能調優、缺陷修復等方面都發揮著重要作用。
功能測試工具的選擇
那麼，如何高效地完成功能測試？選擇一款合適的功能測試工具並培訓一支高素質的工具使用隊伍無疑是至關重要的。儘管現階段存在少數不採用任何功能測試工具，從事功能測試外包專案的軟體服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟體服務企業取代。
目前，用於功能測試的工具軟體有很多，針對不同架構軟體的工具也不斷推陳出新。這裡重點介紹的是其中乙個較為典型自動化測試工具，即mercury公司的winrunner。
winrunner是一種用於檢驗應用程式能否如期執行的企業級軟體功能測試工具。通過自動捕獲、檢測和模擬使用者互動操作，winrunner能識別出絕大多數軟體功能缺陷，從而確保那些跨越了多個功能點和資料庫的應用程式在發布時盡量不出現功能性故障。
winrunner的特點在於: 與傳統的手工測試相比，它能快速、批量地完成功能點測試; 能針對相同測試指令碼，執行相同的動作，從而消除人工測試所帶來的理解上的誤差; 此外，它還能重複執行相同動作，測試工作中最枯燥的部分可交由機器完成; 它支援程式風格的測試指令碼，乙個高素質的測試工程師能借助它完成流程極為複雜的測試，通過使用萬用字元、巨集、條件語句、迴圈語句等，還能較好地完成測試指令碼的重用; 它針對於大多數程式語言和windows技術，提供了較好的整合、支援環境，這對基於windows平台的應用程式實施功能測試而言帶來了極大的便利。
winrunner的工作流程大致可以分為以下六個步驟:
1．識別應用程式的gui
在winrunner中，我們可以使用gui spy來識別各種gui物件，識別後，winrunner會將其儲存到gui map file中。它提供兩種gui map file模式: global gui map file和gui map file per test。其最大區別是後者對每個測試指令碼產生乙個gui檔案，它能自動建立、儲存、載入，推薦初學者選用這種模式。但是，這種模式不易於描述物件的改變，其效率比較低，因此對於乙個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生乙個共享的gui檔案，這使得測試指令碼更容易維護，且效率更高。
2．建立測試指令碼
在建立測試指令碼時，一般先進行錄製，然後在錄製形成的指令碼中手工加入需要的tsl（與c語言類似的測試指令碼語言）。錄製指令碼有兩種模式: context sensitive和analog，選擇依據主要在於是否對滑鼠軌跡進行模擬，在需要回放時一般選用analog。在錄製過程中這兩種模式可以通過f2鍵相互切換。
只要看看現代軟體的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點滑鼠就可以完成的階段。而效能測試則是控制系統效能的有效手段，在軟體的能力驗證、能力規劃、效能調優、缺陷修復等方面都發揮著重要作用。
3．對測試指令碼除錯(debug)
在winrunner中有專門乙個debug *******用於測試指令碼除錯。可以使用step、pause、breakpoint等來控制和跟蹤測試指令碼和檢視各種變數值。
4．在新版應用程式執行測試指令碼
當應用程式有新版本發布時，我們會對應用程式的各種功能包括新增功能進行測試，這時當然不可能再來重新錄製和編寫所有的測試指令碼。我們可以使用已有的指令碼，批量執行這些測試指令碼測試舊的功能點是否正常工作。可以使用乙個call命令來載入各測試指令碼。還可在call命令中加各種tsl指令碼來增加批量能力。
5．分析測試結果
分析測試結果在整個測試過程中最重要，通過分析可以發現應用程式的各種功能性缺陷。當執行完某個測試指令碼後，會產生乙個測試報告，從這個測試報告中我們能發現應用程式的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話方塊等。
6．回報缺陷（defect）
在分析完測試報告後，按照測試流程要回報應用程式的各種缺陷，然後將這些缺陷發給指定人，以便進行修改和維護。
效能測試的三大步驟
第一步 準備和組織是效能測試過程的第一步，在這個階段，需要明確效能測試的目標和需求，並組織起合適的人員，制訂效能測試計畫。
一般來說，效能測試的應用領域分為能力驗證、能力規劃、效能調優和缺陷修復四個方面。其中能力驗證表明測試的目的是驗證系統能力是否達到預期的效能標準; 能力規劃是要考察系統的可擴充套件性; 效能調優則是為了找到系統的效能瓶頸，為效能調優提供依據; 缺陷修復是為了找出系統中存在的併發等方面的缺陷。
明確目標也就是要把效能測試的目的歸到相應的應用領域，而確定需求則是要更詳細地確定效能測試的基準。對產品的效能測試需求的**是軟體需求、設計文件或是使用者備忘錄等設計和需求相關的文件。當然，並非所有的效能測試需求都在這些文件中以明確的方式標識出來，此時就需要根據不十分明確的文件描述進行進一步的細化。我們的經驗是在文件評審時高度關注所有與效能相關的描述，例如「要求操作響應時間小於……」、「要求……能夠快速……」、「要求……能夠支援……使用者訪問」、「要求……能快速穩定執行」等，然後進行進一步的細化，從而作為測試的依據。
效能測試涉及的裝置、環境、技術、工具較多，效能測試人員的組織也必須兼顧這些方面。乙個效能測試組最好包括系統工程師（負責測試環境搭建、伺服器和應用伺服器的配置）、網路工程師（負責網路環境的維護和驗證）、效能分析工程師（負責測試計畫的擬定，對效能測試結果進行分析，給出效能測試報告）、自動化工程師（負責測試指令碼的編寫和測試工具實施）、資料庫工程師（負責對資料庫層進行效能問題定位）。在條件允許的情況下，還可以包括開發工程師和客戶代表，輔助對效能測試結果進行分析和確認。
效能測試計畫是用來指導效能測試過程的主要文件，在測試計畫中除了要寫明本次測試的測試目標、測試需求外，還需要在測試計畫中給出明確的測試退出條件和測試的時間和資源計畫。
第二步 第二步測試設計，也是效能測試的主要內容。測試設計一般基於測試場景進行，乙個測試場景就是乙個使用者的實際使用系統的剖面。
在效能測試過程中，明確每個場景的參與者人數、比例和具體行為是非常重要的，這些都是構成效能測試指令碼的基礎。根據經驗，可以從應用伺服器的日誌中分析使用者行為。例如，對於乙個oa系統，我們從日誌中分析出在上午9:00～9:30時段內有200個檢視郵件頁面的page view，且檢視時間基本集中在前10分鐘; 而在9:00～9:30時間段內對bug顯示頁面的檢視量是300個page view，對頁面的訪問基本平均分配在整個時間段，則我們可以建立兩個指令碼，前乙個指令碼模擬檢視郵件操作（指令碼1），後乙個指令碼模擬檢視bug操作（指令碼2），考慮執行15分鐘的測試場景，則只需在前5分鐘執行指令碼1，在整個過程中執行指令碼2，通過調整think time使得page view達到實際的數值即可。
當然，並不是每個不同的使用者應用剖面都需要作為測試場景來設計，在多數情況下，可以通過對測試場景出現的機率、重要性、風險等進行分析，從而最終確定需要設計的測試場景。明確了場景之後，根據效能測試應用領域的不同，可以採用不同的效能測試方法來達到效能測試的目標。另外需要提醒的是，效能測試設計還應該包括測試環境、測試資料等的設計，因為影響系統效能的因素很多，保持測試過程中環境和資料的可控性是非常重要的。
第三步 第三步效能測試結果分析，是效能測試過程中最困難，也是最重要的步驟。它需要分析人員對測試結果中的各項資料有準確的認識，明確各指標之間的關係。如果各項資料指標間沒有明顯聯絡，在多數情況下需要綜合考慮各種因素，才能得出最終結論。
根據經驗，在效能測試過程中最容易發生的問題是資料庫訪問層問題、應用伺服器配置問題以及網路問題。因此建議一般按照「從簡至繁」的原則，先排除網路問題，其次對應用伺服器配置進行分析，然後在資料庫訪問層進行效能分析，重點是索引、資料庫cache、死鎖等問題的分析。在確認所有這些因素都不是效能瓶頸的情況下，才對**進行分析和檢查，找出導致效能問題的因素。
只要看看現代軟體的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點滑鼠就可以完成的階段。而效能測試則是控制系統效能的有效手段，在軟體的能力驗證、能力規劃、效能調優、缺陷修復等方面都發揮著重要作用。
sencha touch 效能優化個人經驗談
sencha touch 跟ext js乙個提供了豐富且高階的元件讓我們能快速的開發出乙個跨手機平台而且很絢麗的產品,這聽起來不錯,但很快我們發現了乙個嚴重的問題,手機上的效果根本沒有在pc上用chrome開啟的效果一樣讓人有刷刷的快感 甚至讓人痛苦.sencha touch和ext一樣,元件是類式...
跳槽經驗談
每年年初跳槽最多，跳槽是一門學問，也是一種策略。跳槽並不意味著你就能夠取得職業的成功，當面臨跳槽時，如何順利地完成跳槽，從而取得職業的成功呢？以下是一些切身體會，值得大家參考。1 不要指望會一下子能夠跳到多麼好的公司，絕大多數公司都乙個樣子。比如用友 金蝶 亞信 神馬這些公司，其實基本上乙個樣子。2...
程式設計經驗談
不知不覺做軟體已經做了十年，有成功的喜悅，也有失敗的痛苦，但總不敢稱自己是高手，因為和我心目中真正的高手們比起來，還差的太遠。世界上並沒有成為高手的捷徑，但一些基本原則是可以遵循的。紮實的基礎。資料結構 離散數學 編譯原理，這些是所有電腦科學的基礎，如果不掌握他們，很難寫出高水平的程式。據我的觀察，...