【正文】 ductor 和 Player 的技術(shù)要點 7213．10 數(shù)據(jù)分析工具 Analysis 7213．11 結(jié)束語 72十四 性能測試原理及性能測試實例分析 7314．1 軟件測試中的性能測試 7314．1．1 性能測試的含義 7314．1．2 性能測試的分解 7314．2 一個性能測試實例 7414．2．1 被測系統(tǒng) 7414．2．2 對被測系統(tǒng)進行性能測試 7514．5 總結(jié) 80十五 軟件GUI測試中的關(guān)注點 8015．1 不能不說的二個問題 8115．1．1 軟件測試中的“二八”原則 8115．1．2 軟件黑盒測試解決的問題 8115．2 軟件黑盒測試常見錯誤類型及說明 8115．2．1 用戶界面錯誤 8115．2．2 功能性 8115．2．3 人機交互 8215．3 命令結(jié)構(gòu)和錄入 8715．3．1 不一致性 8715．3．2 “最優(yōu)化” 8715．3．3 菜單 8915．4 遺漏的命令 9015．4．1 狀態(tài)轉(zhuǎn)換 9015．4．2 危機預(yù)防 9015．4．3 由用戶進行的錯誤處理 9115．4．4 其他問題 9115．5 程序僵化 9215．5．1 用戶可調(diào)整性 9215．5．2 控制方式 9315．6 性能 9415．6．1 降低程序速度 9415．6．2 緩慢回應(yīng) 9415．6．3 如何減少用戶吞吐量 9415．6．4 反應(yīng)拙劣 9415．6．5 沒有提前輸入 9515．6．6 沒有給出某個操作會花很長時間的警告 9515．6．7 程序太多提示和詢問 9515．6．8 盡量使用簡單命令和提示 9515．7 輸出 9515．7．1 不能輸出某種數(shù)據(jù) 9515．7．2 不能重定向輸出 9515．7．3 與一個后續(xù)過程不兼容的格式 9615．7．4 必須輸出的很少或很多 9615．7．5 不能控制輸出布局 9615．7．6 荒謬的精度輸出級別 9615．7．7 不能控制表或圖的標(biāo)記 9615．7．8 不能控制圖形的縮放比例 9615．8 錯誤處理 9615．8．1 錯誤預(yù)防 9615．8．2 錯誤檢測 9715．8．3 錯誤恢復(fù) 9815．8．4 邊界相關(guān)的錯誤 9915．8．5 計算錯誤 10015．9 小結(jié) 100十六 軟件測試技術(shù) 100 軟件測試基礎(chǔ) 101 測試目標(biāo) 101 測試原則 101 可測試性 102 測試用例設(shè)計 104 白盒測試 104 基本路徑測試 105 流圖符號 105 環(huán)形復(fù)雜性 106 導(dǎo)出測試用例 106 圖矩陣 108 控制結(jié)構(gòu)測試 108 條件測試 108 數(shù)據(jù)流測試 110 循環(huán)測試 111 黑盒測試 112一 軟件測試 從零開始【摘要】本文面向軟件測試新手，從測試前的準(zhǔn)備工作、測試需求收集、測試用例設(shè)計、測試用例執(zhí)行、測試結(jié)果分析幾個方面給出建議和方法。如果你把這個問題提給項目經(jīng)理，他往往會這樣回答： “ 發(fā)現(xiàn)我們產(chǎn)品里面的所有 BUG ，這就是你的工作目的 ” 。目前，從國外引入的軟件測試書籍有很多經(jīng)典之作，但是，翻譯成中文后，翻譯質(zhì)量對閱讀效果有很大的影響。測試用例寫作一般會包括測試用例項和根據(jù)測試用例項細化的測試用例，下面舉例說明。如果你是一個軟件測試技術(shù)專家，但是對產(chǎn)品業(yè)務(wù)知識一無所知，那么也只能測試出來純粹的軟件缺陷，而面對眼前出現(xiàn)的產(chǎn)品業(yè)務(wù)相關(guān)的缺陷，很可能是視而不見，如此這般，軟件測試的效果會大打折扣。 當(dāng)拿到相關(guān)的資料后，從哪些方面分析需求？如何與開發(fā)人員交流需求？其實，只要把握需求分析的幾個關(guān)鍵的點就可以解決問題：輸入、處理過程、輸出、性能要求、運行環(huán)境，下面針對每一個項目逐一分析： 軟件輸入： 與該需求相關(guān)的一切可能輸入，可以從這幾方面考慮，輸入來源、輸入?yún)?shù)的數(shù)量、輸入?yún)?shù)的度量單位、輸入?yún)?shù)的時間要求、輸入?yún)?shù)的精度和輸入?yún)?shù)的有效輸入范圍。 運行環(huán)境： 軟件的運行所需的環(huán)境，包括硬件平臺的要求、操作系統(tǒng)的要求、數(shù)據(jù)庫的要求，以及其它相關(guān)支撐軟件的要求。當(dāng)開發(fā)人員通過郵件討論問題、通知召開技術(shù)會議的時候，測試人員可以及時知曉，如果必要，可以參加開發(fā)人員的技術(shù)會議。 1．4 測試用例設(shè)計 測試需求收集完畢后，開始測試設(shè)計。一般來說，如果軟件需求的優(yōu)先級為 “ 高 ” ，那么針對該需求的測試用例優(yōu)先級也為 “ 高 ” ；反之亦然， 測試輸入： 提供測試執(zhí)行中的各種輸入條件。具體的測試用例設(shè)計方法可以參見相關(guān)的測試書籍，白盒測試方法和黑盒測試方法在絕大多數(shù)的軟件測試書籍中都有詳細的介紹，這里不作贅述。 1．4．3 利用已有的軟件 Checklist 在上面一個小節(jié)中，按照不同的規(guī)則劃分了不同的軟件類型。 1．4．5 定義測試用例的執(zhí)行順序 在測試用例執(zhí)行過程中，你會發(fā)現(xiàn)每個測試用例都對測試環(huán)境有特殊的要求，或者對測試環(huán)境有特殊的影響。 如果開發(fā)人員拒絕提供相關(guān)的安裝指導(dǎo)書，搭建測試中遇到問題的時候，測試人員可以要求開發(fā)人員協(xié)助，這時候，一定要把開發(fā)人員解決問題的方法記錄下來，避免同樣的問題再次請教開發(fā)人員，這樣會招致開發(fā)人員的反感，也降低了開發(fā)人員對測試人員的認(rèn)可程度。而不用測試人員重新搭建測試環(huán)境，為開發(fā)人員重現(xiàn)問題。 1．5．3 及時更新測試用例 測試執(zhí)行過程中，應(yīng)該注意及時更新測試用例。 軟件配置： 包括操作系統(tǒng)類型版本和補丁版本、當(dāng)前被測試軟件的版本和補丁版本、相關(guān)支撐軟件，比如數(shù)據(jù)庫軟件的版本和補丁版本等。 1．6 測試結(jié)果分析 軟件測試執(zhí)行結(jié)束后，測試活動還沒有結(jié)束。二 軟件測試的常識2．1 引言軟件開發(fā)和使用的歷史已經(jīng)留給了我們很多由于軟件缺陷而導(dǎo)致的巨大財力、物力損失的經(jīng)驗教訓(xùn)?？上У氖?，我們中的很多人更傾向于把軟件缺陷看成運行時出現(xiàn)問題上來，認(rèn)為軟件測試僅限于程序提交之后。為此作為軟件測試，我們一般采用等價類和邊界值分析等措施來進行實際的軟件測試，尋找最小用例集合成為我們精簡測試復(fù)雜性的一條必經(jīng)之道。 2．2．3 測試是 “ 泛型概念 ” （全程測試） 我一直反對軟件測試僅存在于程序完成之后。否則自身不正，難以服人。因為軟件測試只能夠保證盡可能多地發(fā)現(xiàn)軟件缺陷，卻無法保證能夠發(fā)現(xiàn)所有的軟件缺陷。一般說來，在軟件測試中我們應(yīng)該盡量地保持軟件測試簡單性，切勿將軟件測試過度復(fù)雜化，拿物理學(xué)家愛因斯坦的話說就是： Keep it simple but not too simple 。軟件缺陷是經(jīng)過對比而得出來的。 2．2．9 結(jié)論： 軟件測試是一個需要 “ 自覺 ” 的過程，作為一個測試人員，遇事沉著，把持尺度，從根本上應(yīng)對軟件測試有著正確的認(rèn)識，希望本文對讀者對軟件測試的認(rèn)識有所幫助。以達到最終目標(biāo)。所以對程序員的要求就很高了。這就意味著項目的某些部分得重新推倒重來，如果這個部分跟已完成的多個部分有牽連的話，那就后果更可怕了。3．3 代碼編寫當(dāng)需求定下來數(shù)據(jù)庫也定下來后， 其實我們就可以進行實質(zhì)性的編碼了，按照我的看法，一個人單獨編程最好，能隨時偷懶?；诤唵我撞僮鞯脑瓌t，貼近用戶考慮，用戶界面采用Windows風(fēng)格的標(biāo)準(zhǔn)界面，操作方式亦同Windows風(fēng)格，這樣在實施過程，可以降低對客戶的培訓(xùn)，也可以使用戶容易上手，簡單易學(xué)。（5）注釋：對注釋有以下三點要求： A、必須是有意義； B、必須正確的描述了程序； C、必須是最新的。因為只有你自己知道)。一般公司教育的方式有四種。所以本文，我就著重寫點我自己從事測試工作的一些感受。實際上各個項目在開展測試的時候：各個階段劃分的不會太明顯；某些階段的功能會弱化，某些階段的功能會延伸；下面我指出目前測試工作中基本上做的不足的或者比較常見的問題（有則改之、無則加勉）：測試策略文檔的普遍缺失； 測試范圍的確認(rèn)經(jīng)常被其他文檔或經(jīng)驗所取代； 測試計劃受制于開發(fā)計劃； 測試任務(wù)應(yīng)該像BUG一樣有明確的分級，不同類型的測試應(yīng)該有相應(yīng)的測試用例集合與之對應(yīng)； 關(guān)鍵路徑概念在測試規(guī)劃時容易被項目經(jīng)理弱化。問題往往暴露在測試這個階段，即使很多企業(yè)號稱全面質(zhì)量管理，往往也是如此。 Word 格式的文檔可以滿足設(shè)計需要，但不利于跟蹤和自動統(tǒng)計執(zhí)行結(jié)果報告。 測試用例執(zhí)行步驟、期望結(jié)果； 測試用例執(zhí)行結(jié)果 —— 執(zhí)行時填寫，分為通過、失敗、警告、阻塞、忽略。如何使結(jié)果明了又能精確反映實際結(jié)果，需要精明選擇包括哪些狀態(tài)。本文全面介紹了質(zhì)量的概念，提出了從流程、技術(shù)、組織管理、人員技能發(fā)展等多個角度提高軟件質(zhì)量的重要性；并對目前國際上流行的 CMM 標(biāo)準(zhǔn)進行了介紹，提出了使用 PSP 和 TSP 來實現(xiàn) CMM 的方法。因此如何提高軟件的質(zhì)量成為軟件工程研究的一個重點。 符合需求。因此在控制一個產(chǎn)品的質(zhì)量的過程中必須關(guān)注這些隱含的需求，并給予應(yīng)有的驗證。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟件的人員，而忽略了其它一些人員對軟件的要求或?qū)浖斐傻臐撛诟偁?，這包括維護人員的要求、系統(tǒng)管理人員的要求、軟件上下游人員的要求、先前版本的情況、市場上競爭對手的軟件情況等。 一個高的質(zhì)量要求需求規(guī)格說明書足夠詳細，以便產(chǎn)品可以根據(jù)這些規(guī)格說明書進行定量的分析。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標(biāo)共同努力，這樣可以防止人員工作間的內(nèi)耗，極大的提高工作效率。瀑布模型是應(yīng)用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是顯而易見的。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發(fā)過程模型，它是一個面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務(wù)流程【 9 】。核心支撐工作流包括：環(huán)境工作流、項目管理工作流和配置與變更管理工作流。是一個端到端的流程。沒有流程就成功是不可能得到保證，但有了流程并不意味著肯定能夠成功。在國內(nèi)有一個普遍的非正?，F(xiàn)象，就是大家覺得只有編程能力才是玩電腦的真正技能。在《軟件需求》一書中關(guān)于如何進行需求分析給出了比較詳細的介紹【 7 】， RUP 中關(guān)于需求的指導(dǎo)也是很實用的。在嵌入式方面， SDL 也是一種非常好的選擇。如果大家是在做研究性的項目或純粹興趣性的項目，那么充分發(fā)揮自己的編程天才也無可厚非。根據(jù) IBM 的研究表明，假定在分析階段發(fā)現(xiàn)的錯誤其改正成本為 1 個單位的話，那么在測試之前（設(shè)計編碼階段）發(fā)現(xiàn)一個錯誤的修改成本約為 個貨幣單位，在測試時（集成測試，系統(tǒng)測試和驗收測試）發(fā)現(xiàn)一個錯誤的修改成本約為 15 個貨幣單位，而在發(fā)布之后（已經(jīng)交到用戶手上）發(fā)現(xiàn)一個錯誤的修改成本約為 60 到 100 個貨幣單位。 IEEE 給出的驗證和確認(rèn)過程可以用下圖來表示。而測試工程的發(fā)展已經(jīng)進入到了全流程的測試，包括開發(fā)過程前期的靜態(tài)測試。 規(guī)格說明書 記錄了用戶的需求。事實上也是這樣。一個好的測試是發(fā)現(xiàn)至今沒有被發(fā)現(xiàn)的錯誤。 什么是確認(rèn)？ 確認(rèn) 就是要用數(shù)據(jù)證明我們是不是制造了正確的產(chǎn)品。如前面提到的，軟件開發(fā)也是一個工程性的工作，因此必須提高整個工程的質(zhì)量。測試結(jié)果發(fā)現(xiàn)，印度程序員設(shè)計的程序使用的算法并不是最優(yōu)，但卻是最不容易出錯的，并且?guī)讉€程序員寫出來的代碼如出一轍。設(shè)計人員需要掌握一定的建模技術(shù)。返工會耗費開發(fā)總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的錯誤所導(dǎo)致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。兩者結(jié)合就是完美。并且對于一些小的項目，也不是非常適合使用該流程。圖1 RUP 工作流程示意圖 IPD （ Integrated Product Development ）流程是由 IBM 提出來的一套集成產(chǎn)品開發(fā)流程，非常適合于復(fù)雜的大型開發(fā)項目，尤其涉及到軟硬件結(jié)合的項目。每個階段都使用了迭代的概念。該模型的最大優(yōu)點就是隨著成本的增加，風(fēng)險程度隨之降低。由于流程來源于成功的經(jīng)驗，因此，按照流程進行開發(fā)可以使得我們少走彎路，并有效的提高產(chǎn)品質(zhì)量，提高用戶的滿意度。 軟件產(chǎn)品的開發(fā)同其它產(chǎn)品（如汽車）的生產(chǎn)有著共同特性，即需要按一定的過程來進行生產(chǎn)。 質(zhì)量經(jīng)常是和成本緊密聯(lián)系在一起，一個高質(zhì)量的產(chǎn)品同時也意味著高投入。了解了這個區(qū)別，對于你在分析需求的重要性的時候就可以進行參考。 ” 注意，在這個定義中包含明顯的需求和隱含的需求。目標(biāo)是客戶所定義的，符合目標(biāo)即判斷我們是不是在做需要做的事情。伴隨著軟件應(yīng)用的越來越廣泛，軟件的質(zhì)量問題就變得越來越突出。如果您有好的解決方案，我將很樂意知道。因此必須指定雙重狀態(tài)，如 Block/Fail ， Block/Warn ， Skip/Pass ， Skip/Closed 等。 可接受級測試，該級測試用例只要執(zhí)行一次通過即可，該級測試用例通過意味著可以準(zhǔn)備發(fā)布了； ?這幾年測試技術(shù)和理論有了長足的發(fā)展，就功能測試用例設(shè)計要素而言，樣式上均大同小異，一般都包含主題、前置條件、執(zhí)行步驟、期望結(jié)果等。沒有做過自動化測試的人，都夢想能精通一個自動化工具，期望以此來提高自己的江湖地位，并解決手工測試帶來的痛苦； 正在做自動化測試的人，都很清楚自動化往往是一個大麻煩，老板總認(rèn)為自動化上來了（當(dāng)然是盜版的）就能解決所有的問題，堵槍眼就靠他了； 其實，自動化測試是一個很廣泛的概念，目的不同需要的工具也不一樣，每種工具都有自己獨特的屬性，在做一般功能測試的時候往往覺得所有的工具都差不多，當(dāng)自動化測試開展到一定精細程度的時候，就會發(fā)現(xiàn)最初選擇工具的重要性了。下面，我個人對各種角色按照普遍的概念對其做一個簡單描述：項目經(jīng)理：對項目的所有問題負(fù)責(zé)；業(yè)務(wù)分析人員：清楚的了解客戶的需求并以文檔形式及時傳遞給每一個角色；設(shè)計人員：根據(jù)需求文檔做概要設(shè)計（或詳細設(shè)計）程序開發(fā)人員