在我們的團隊中，QA角色身兼兩職：測試和過程改進。以往我們對新進來的員工的期望值是先承擔測試任務，在能較好地完成測試任務之后，才考慮讓他參與一些SQA的工作。因此，有些已經進來大半年的同事，感覺對SQA還是沒有什么概念，更沒有機會去實踐。或者有的同事想參與一些SQA的工作，卻感到沒有頭緒，不知如何下手。而實際工作中我發現，QA的能力可以在每日工作中從點滴、從最開始就培養，這個與以往有沒有SQA的知識和經驗沒有關系。因為簡而言之，QA的工作主要圍繞持續改進展開。而無論你是否有經驗，每天的工作中你都在以自己獨特的視角看問題，并可能看到改進的空間。那么，測試人員如何在日常工作中去逐步培養自己的QA能力呢？

1.找到問題

感受到一個問題，有時是出于關懷，你發現有人/自己正因為某件事情而痛苦；有時是出于懷疑，你發現有件事情和你想象/預計的不一樣；還可能是出于直覺。但感受到問題其實并不是一件容易的事情。

如果感受不到問題，我們可以試圖通過多種方法積極尋找。

如果你剛到一個項目組,提不出問題，可以先去聽聽別人（項目組成員、用戶等等）的抱怨，或者想想自己痛苦的地方（比如找不到文檔，系統操作不直觀學習起來困難等等），這些就可能是問題。另外，為了培養自己找問題的習慣，可以給自己一個定量目標，每周去總結一個“疑似問題”。經過實踐，這個帶點自我強迫的方法對于找問題很有幫助。比如，雖然你的測試用例經過了和開發人員的評審，但是測試時你卻發現幾個重要的分支或者邏輯還是在代碼中忘記實現了。除了報告缺陷，是否還有什么有共性的問題存在，并值得改進呢？

如果你在一個項目組大家合作得不錯，似乎沒有什么問題，但一個看 似不錯的結果其實可能隱藏了問題。比如，完成工作，交付高質量的軟件產品可以通過多種渠道實現，而非一定體現了高質量。可能是犧牲了時間進行好幾輪的測試 和修復和全面的回歸測試，又或者某一塊有一個英雄人物能夠以一己之力確保這塊沒有問題。又如，雖然大規模代碼重構的時候，內部測試能找到大部分重要的缺 陷，但是否測試人員心理還是很抗拒和沒底的？雖然這些問題不是單靠測試人員就能改善或者達到，但找到影響質量的問題確實需要測試人員的獨立視角和貢獻。如 果一個測試人員、一個測試團隊能夠跳開測試的圈圈，從更廣闊的角度看到影響質量的其他環節，幫助開發人員克服一些老的制約生產力和質量的毛病或者習慣，從而提高開發團隊的水平，而更高開發水平的開發團隊又對測試團隊會提出更高的要求，那么這樣的良性互動是我們都想看到的。現在被大家所廣泛追捧的敏捷開發就提倡忽略角色的分工，大家一起為質量貢獻自己的一份力量。

前面說的是流程方面的問題，其實即使是被測程序的問題也存在于在整個軟件開發周期。雖然傳統對測試的理解是測試找問題更多集中在執行階段，但借用QA的預防為主的思路，程序的問題也可以通過對需求和設計的評審及時發現和糾正，避免后期更大的浪費。

2.探究問題

感 受到問題之后，需要一種探尋真相的精神去一探究竟。很多人能感受到問題，但是很遺憾地是當有更具體的任務在手頭的時候，往往就忽略了這個問題。或者知道問 題很大，也知道有各種原因的阻礙，因此采取放任自流的態度。這里要介紹一個好的習慣，就是把你當前沒有時間去細想的問題先記錄下來，以后再找機會去跟蹤執行。類似outlook的任務或者一些桌面電子便簽等工具可以幫助你設定任務及提醒執行。除了記錄，還有一個好習慣就是去外部尋找一些同行的交流。如果看到同樣/類似的話題，相信會驅使你有更大的興趣去看自己碰到的問題，也啟發你從不同角度看問題。

QA的工作更多的針對的是有共性的問題，所以對這類問題的探究往往需要多個樣本。換言之，在報告每一個缺陷的時候我們是在做測試，而對測試結果進行總結、歸類、抽象出背后共性的問題則向QA靠近了一步。

3.判斷問題

3.1判斷一個問題是否真的是問題

測 試人員通常看到實際執行結果后就能馬上判斷出其與預期結果之間的差異，從而判斷是否存在問題。但過程改進相關的問題就沒有那么一目了然了。比如，我們收到 一個來自生產環境的缺陷，是因為一個需求變更的影響點大家都沒有想到，直到生產環境暴露出來。開會的時候有人提出我們的開發流程不完善，如果能夠建立起需 求、設計和測試用例的跟蹤矩陣，那么在做影響分析的時候就能順藤摸瓜，避免此類問題了。聽起來不錯，是么？可是，如果我們細想，這種類似問題在生產環境對 用戶的影響大么？可以繞過去么？此類問題出現的次數多么？如果我們建立這個跟蹤矩陣，維護代價有多高？前提還是我們首先要想到所有的內在聯系（而這個本身 就是無法確保的）。兩相權衡，“沒有這個跟蹤矩陣”是我們現在的問題么？

“判斷一個問題是否真的是問題”最好能廣泛聽取不同的意見，并找到根源。

3.2判斷一個問題是否需要被馬上解決

“判斷問題是否需要馬上解決”在某種程度上這有點象測試人員去設定缺陷的優先級。雖然所有被發現的缺陷都被記錄，但是當前版本需要修復的或者可能只是其中一部分，而這一部分中還有需要盡快修復的和可以稍后修復的差別。過程改進的問題也是一樣，有個主次和優先級之分。

4.解決問題

對于確實是問題的，我們應該去積極地尋找解決方案。但是新到一個公司或者項目組，發現了問題之后，不要急著去提出自己的解決方案，而應該先試圖了解它的來龍去脈和曾經進行過的改進嘗試，以及執行中實際的一些阻礙。

解決問題通常牽涉到開發團隊中各個角色，除了明確負責的一方，還要對參與的其他方也進行充分的溝通。

確認開始執行之后，為了確保執行的正確性和力度，一定要跟蹤執行。一個沒有跟蹤執行的方案如同瞎子射箭。這樣的話，無論射多少回，都是沒有目的性和方向性的，也無法在以前的基礎上持續改進的。質量理論中常提到的PDCA循環講的也是這個道理。

在解決問題方面，有很多和測試、質量無關，但和思維、管理類相關的書和文章。例如：《第五項修煉》中就提出對解決問題很有幫助的五大方面：系統思考、自我超越、心智模式、建立共同愿景、團隊學習。《金字塔原理》中提出的界定問題、結構化思考、演繹與歸納等多種模式也能幫助我們剝繭抽絲，抓到問題的本質和可行的方案。

6.QA能力進階

從上面我們看到，QA能力的培養貫穿于每日工作的點滴。其進階可以大致分為以下級別。

(1)發現的問題級別:

       初級:問題已經發生,而且大家都感受到了(項目組中大家都覺得有問題的問題)

       中級:問題已經發生,但只有少量人感受到了(問題已經發生,但是其危害還沒有擴散)

       高級:問題還沒有發生,很多人沒有意識到(一個解決方案在不同的實施環境中會有的問題)

(2)解決問題的能力的級別：

       初級：可以提出方案，但不能提出很合理的、可以實施的方案

       中級：可以提出合理的可以實施的方案，但是實施效果不太好（方案中存在著一些重要的影響執行的因素沒有考慮到）

       高級：可以提出合理的方案，且實施效果好，整個團隊受益

　　當今的企業需要掌控其關鍵業務應用的所有功能測試，以確保所有業務流程工作符合預期。通過實施自動化的功能測試，企業可以極大提高測試速度和精度，從挼間項目中得到更高的投資回報并且顯著地降低風險。

　　本文簡要描述了自動化功能測試的優勢和挑戰，幫助企業考慮實施最佳測試自動化的方法。

　　1.介紹

　　毫無疑問，嚴格的功能測試是成功開發應用的關鍵。開發人員，測試小組和管理人員所面臨的挑戰是，如何加速測試流程和提高測試的精確性和完備性，同時還不能增加已然很緊張的預算。

　　通過將功能測試的關鍵環節自動化，可以滿足有挑戰性的發布時間安排，測試得更加全面和可靠，檢驗業務過程功能的正確性，從而從上線的運營中，獲得極高的產值和客戶滿意度。然而，功能測試的自動化會產生一些新的顧慮：

　　測試過程自動化的成本是多少？其投資回報率（ROI）是什么？

　　哪些應用/過程適合做自動化測試，哪些不合適？

　　是否需要新的培訓，這將對當前的開發計劃安排產生怎樣的影響？

　　自動化測試得正確地方法論是什么？

　　自動化測試時涉及到哪些情況？

　　當比較自動化測試產品時，哪些功能最重要？

　　在自動化測試項目開始之前，以上和其他一些問題應該得到全面地調查和了解。

　　2.功能測試與單元測試

　　功能測試是指確保應用按期望運行，也就是按照用戶的期望運行。功能測試以一種有效的方式捕獲用戶的需求，讓用戶和開發人員對業務過程滿足需求充滿信心，同時使得QA團隊可以檢驗軟件已發布就緒。

　　功能測試是單元測試的補充，但有很大不同。簡言之，單元測試說明了代碼執行是否正確；功能測試說明了完成的應用是否做正確的事情。單元測試往往是從代碼開發人員的角度來看，而功能測試是從最終用戶和業務過程角度來看。

　　3.為什么將功能測試過程的自動化？

　　現在，IT部門的壓力越來越大。管理部門希望IT部門通過軟件可以交付新功能，抓住新的商業機會和提供有競爭力的優勢。這就意味著需要完成更多的業務應用開發項目，而時間會很緊迫，并不是都有更多的預算或資源。

　 　同時，管理部門越來越意識到軟件和銷售額的重要關系。Web Services，聯機事務處理和ERP應用不僅是非常關鍵的，而且，它們直接關系到公司的產值能力。現在企業非常依賴非常復雜的計算機基礎設施。如圖， 一個典型的企業可能依靠多個應用，運行在不同的系統上，使用幾種不同的前端客戶端，涉及到大量的業務過程并且與很多種數據集交互。

　　可能的組合是高度復雜，需要成百上千的測試場景。

　　當軟件出現故障時，其代價是非常大的，包括銷售額下降，員工的低效率，客戶的不滿和開發和QA人員的士氣低落。在軟件開發周期中，缺欠發現的越晚其代價越高。上線后發現的缺欠的改正成本可能比在設計階段發現的高出100倍。自動化是提高軟件測試過程的速度，精確度和靈活性的關鍵，使公司可以更早發現和改正缺欠。

　　4.手工功能測試的挑戰

　　手工功能測試過程本身存在很多挑戰：

　 　時間過長。有限的IT資源和緊張的交付時間使得手工測試對于滿足業務目標來說過于耗時。采用手工測試，測試和開發人員不得不計劃冗長的每步測試過程，然 后手工執行，再現問題，快速消耗了有價值的時間和資源。根據Aberdeen Group，一個獨立行業分析公司，90%的IT項目交付出現延遲，手工測試是其中一個因素。

　　覆蓋不完全。平臺，操作系統，客戶端設備，業務過程和數據集等的組合對于手工測試過程來說，工作量非常大。需要驗證功能的測試用例數量非常巨大。所以當修改完成后手工回歸測試花費的時間過長，以至于不能做全面的回歸測試。

　　風險更高。手工測試過程比計算機過程的錯誤和疏忽更多。人們會變得疲倦，輸入數據錯誤，不能總是正確執行測試，并不是總有時間測試所有應該測試的內容。

　　5.自動化測試的好處

　　自動化測試有很多好處，包括：

　 　快速執行。計算機在執行功能測試腳本的時候比人快得多，因此在有限的時間里能測試的更多，在給定的時間里更多的應用可以被測試，可以按時完成更多的工 程。并且和人不同，計算機一天工作24小時，還包括晚上，周末和假期；他們不會感到無聊或者疲倦；而且他們從不對該作的事情和不該作的事情自作主張。

　 　提高測試覆蓋。自動測試產品支持在所有流行的瀏覽器，操作系統等上執行測試腳本，用自動化的工具對不斷變化的應用和環境做回歸測試，要比手工測試容易得 多。通過整合的數據驅動表單的功能，自動化測試產品允許開發和測試團隊執行計算，操作數據集，以及快速創建多種反復的測試，使得擴大測試覆蓋范圍。使用自 動測試工具可以仿效任何混合的事務和任意的用戶負載。

　　提高測試精確度并提早發現更多錯誤。自動化測試給開發人員提供了一種再現和記錄軟件缺陷的非常容易的方法。這將在所有環境，數據集和業務過程等之間確保功能的正確性，同時對開發過程起到加速作用。

　　提供規范化的過程。自動化測試鼓勵測試團隊規范化他們的過程，以得到更高的一致性和更好的文檔記錄。

　　提高測試的重用性。測試一旦腳本化，開發人員可以使用和重用這些腳本，可以將腳本添加到測試套件中，以適應應用的變化。沒有必要為每個應用的相同功能而重新創建腳本。

　　支持ERP/CRM。現在越來越多的用戶使用ERP/CRM解決方案，對端到端的回歸測試的需求正變得越來越頻繁和越來越重要。

　　6.在什么情況下采用自動化測試？

　　一般來說，把自動化測試的工作集中在關鍵的業務過程，復雜應用，以及由這些組成的用例方面（相對于低級別任務，例如系統級的驗證）是很有意義的。

　 　如果一個企業擁有眾多每天工作很多小時的軟件測試人員，但是產品仍然出現質量和功能問題，那么這家企業肯定能從自動化測試中受益。是否決定實行自動化測 試應當充分考慮到投資回報，但是一般情況下，如果一個應用需要多次構造/補丁/修改；需要在大量的硬件或軟件配置下進行測試；并且支持眾多并發用戶等，那 么將會是值得采用自動化測試。另外，如果涉及到重復性的工作，例如數據裝載和系統配置等，或者應用需要滿足特定的服務等級協議（SLA）,那么自動化測試 當然也會節約成本。

　　7.如何確定自動化測試的投資回報？

　　任何投資回報都可以從一個簡單的計算得出：

　　投資回報=投資的凈現值/總初始成本

　　當采用測試過程的自動化時，成本是切實可見的，但是凈現值仍舊包含許多無形的因素。最好的方法就是盡量精確計算直接成本，然后與自動化測試產生的直接和間接的效益進行對比。

　　在ROI計算中需要考慮的直接成本包括:

　　購買成本：購買自動化測試軟件產品的成本。

　　硬件成本：功能測試所必需的硬件成本。有代表性的是，功能測試不需要特殊的硬件，只需帶有以太網端口的標準臺式電腦或者工作站即可。

　　勞動力成本：培訓職員編寫測試用例腳本或進行手工測試的成本因素。確認要包括招聘，雇傭，支付工資，和保留熟練的QA工程師的成本。

　　培訓成本：依賴于所選擇的測試產品，培訓使用者精通編寫自動測試腳本是值得的。當然，公司可以選擇雇用專業的服務公司創建最初的自動化測試。

　　當衡量自動化的潛在益處時，考慮隱性效益是很重要的，例如測試人員高漲的士氣和對工作的滿意度，改進的客戶滿意度和忠實度，還有因為最終用戶使用的可信賴的軟件而不斷提高的知名度。

　　8.如何評估自動化測試軟件？

　　很多商家提供自動化測試產品。每個解決方案都有自身的優勢和劣勢，獨特的功能，和市場環境。每個企業需求的特殊性決定了最適合的一種選擇。然而，任何自動化測試產品都應當包含一些關鍵的性能：

　　自動化測試的“Scriptless”表示法：產品應該提供一個可點擊的界面，在測試時與應用組件進行訪問和交互——而不是呈現出一行行的腳本。測試者應該可以可視化每一步的業務過程，并且直觀的觀察和編輯測試用例。這將減少測試者在學習上走彎路，并幫助測試團隊面對緊迫的最終期限。

　　集成的數據表：自動化功能測試的一個關鍵的好處就是可以使系統快速產生大量數據。還有一個重要的功能就是操作數據集，執行計算，并以最小的代價快速創建數以百計的重復測試和組合。企業應該尋找擁有提供強大計算能力的集成電子數據表單的產品。

　 　清晰明確的報告：如果測試結果不容易理解或解釋，那么即使運行大量測試數據也不會有什么好處。測試產品應當自動的產生并顯示所有測試運行方面的報告，并 用易讀的格式解釋結果。報告應當提供的細節包括：應用在什么地方發生了失敗和使用了什么樣的測試數據；為應用的每一步提供高亮或有差別的屏幕顯示；并提供 每個檢查點通過和失敗的詳細解釋。當然還應當能夠在不用修改的情況下，在測試和開發團隊之間共享報告。

　　9.要點列表：自動化測試成功的五個關鍵

　　即使已經證明了測試的自動化是經濟有效的，然而如何確定轉變到自動化測試過程上的最佳方法依然是困難的。這部分略述了執行自動化測試過程的五個基本原則。

　　1.完成一個測試計劃文檔。理解被測應用的目標是任何測試成功的基礎。這包括全面的預先計劃以確保測試需求被正確的實施。測試工具應提供為所有被測應用管理測試用例和需求的能力。

　　2.將測試細分為自動測試用例。一個組織自動執行一個測試計劃的所有方面是不可能的。自動化測試應該集中圍繞在需求設計的復雜應用上和急迫的業務過程功能上，許多組織發現他們使用自動化測試只占總測試用例的60%，而余下的40%為手工測試。

　 　3.創建自動化測試。測試工具極大簡化了準備測試數據和腳本的過程。這使得更多的完全測試可最佳地使用測試資源和結果。使用測試工具，使用者可以不必作 任何實際腳本而創建測試。測試工具應能自動捕獲目標應用的業務過程，并允許使用者創建一個可以被保存的而且可以被管理的測試流程。

　　4.提高測試覆蓋的數據驅動測試。測試者就可以為應用創建一個使用儲藏在Excel電子表格里的特殊關鍵字的依賴于數據的測試。這就允許測試者通過應用驅動大量的測試數據。

　　5.給測試增加驗證。需要在測試中添加了“通過或失敗”的測試標準。這包括了應用的前端，中間層，或后端數據庫的驗證。內置的數據庫驗證使數據庫值的存儲得到確認，并確保處理的精確性和已更新、刪除或增加的數據記錄的完整性。

　　10.總結

　　功能測試可以不是耗時或高成本的問題。采用自動化功能測試，企業可以將重點放在改進自動業務過程方面。開發和QA組可以增加測試過程的速度和精確度。整個IT部門可以獲得更高的投資回報，而且降低了大量風險。

1       概述

       本測試過程作為功能測試的最佳實踐，用于實施不同機構的功能測試工作。它可以作為測試計劃工作的基礎，應用于每個軟件開發的項目。在這個測試過程中描述的活動既可以用于新開發的組件，亦可以用于改進現有的回歸測試。

2       測試管理

為了能順利地獲得測試的結果，將測試作為獨立管理的過程是非常必要的。測試管理可以分為下面四個領域。

1）測試計劃

2）測試執行

3）測試控制

4）測試過程改進

1.1    測試準備
    測試的準備是一個獨立的、分離的階段，測試員在這個階段中基于需求文檔準備測試（業務設計圖）。測試的準備要依據標準的方法，并應基于本階段的工作生成標準化的文檔。
1.1.1   業務功能測試
    基于風險評估，針對每個業務功能的不同風險級別都應有一個對應的測試過程和方法組合：
1）A級風險
利用等價類和組合進行系統性的測試完全自動化

2）  B級風險
利用等價類進行系統性的測試完全自動化

3）  C級風險
隨意性測試手工執行，在TestDirector中提供文檔化的執行過程

       對于每個測試過程和方法組合，要提供一個標準的文檔進行方法論級的闡述和規定，每個測試人員依據這些標準的測試過程和方法組合進行測試。

    在TestDirector中要將測試用例的準備結果作為業務功能的附件。

1.1.2   業務流程測試
    業務流程測試是將所有的業務功能組合在一起，使用同一組數據進行工作。
    測試員的任務就是要確定每個業務功能的組合是否能連貫的執行。
    判斷的結果使用矩陣來表示，例如下圖：
注：yes（+）；no（-）

業務流程矩陣

 
業務流程矩陣的設計如下圖：

　　從配置管理員處申請軟件配置：《需求規格說明書》和《設計說明書》；根據需求規格說明書和設計說明書，詳細理解用戶的真正需求，并且對軟件所實現的功能已經準確理解，然后著手制訂測試用例。

　　二、測試用例制定的原則

　　測試用例要包括欲測試的功能、應輸入的數據和預期的輸出結果。測試數據應該選用少量、高效的測試數據進行盡可能完備的測試；基本目標是：設計一組發現某個錯誤或某類錯誤的測試數據，測試用例應覆蓋方面：

　　1、正確性測試：輸入用戶實際數據以驗證系統是滿足需求規格說明書的要求；測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，并且正常。

　　2、容錯性（健壯性）測試：程序能夠接收正確數據輸入并且產生正確（預期）的輸出，輸入非法數據（非法類型、不符合要求的數據、溢出數據等），程序應能給出提示并進行相應處理。把自己想象成一名對產品操作一點也不懂的客戶，在進行任意操作。

　　3、完整（安全）性測試：對未經授權的人使用軟件系統或數據的企圖，系統能夠控制的程度，程序的數據處理能夠保持外部信息（數據庫或文件）的完整。

　　4、接口間測試：測試各個模塊相互間的協調和通信情況，數據輸入輸出的一致性和正確性。

　　5、數據庫測試：依據數據庫設計規范對軟件系統的數據庫結構、數據表及其之間的數據調用關系進行測試。

　　6、邊界值分析法：確定邊界情況（剛好等于、稍小于和稍大于和剛剛大于等價類邊界值），針對我們的系統在測試過程中主要輸入一些合法數據/非法數據，主要在邊界值附近選取。

　　7、壓力測試：輸入10條記錄運行各個功能，輸入30條記錄運行，輸入50條記錄運行……進行測試。

　　8、等價劃分：將所有可能的輸入數據（有效的和無效的）劃分成若干個等價類。

　　9、錯誤推測：主要是根據測試經驗和直覺，參照以往的軟件系統出現錯誤之處。

　　10、效率：完成預定的功能，系統的運行時間（主要是針對數據庫而言）。

　　隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷發展：從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門；測試工作也從簡單測試演變為包括編制測試計劃、編寫測試用例、準備測試數據、開發測試腳本、實施測試、測試評估等多項內容的正規測試；測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。

　　一、測試用例是軟件測試的核心

　　軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。

　 　影響軟件測試的因素很多，例如軟件本身的復雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客 觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如 何保障軟件測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量。可以把人為因素的影響減少到最小。即便最初的測試用例 考慮不周全，隨著測試的進行和軟件版本更新，也將日趨完善。

　　因此測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則，更是軟件測試質量穩定的根本保障。

　　二、什么叫測試用例

　　測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略，內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

　 　不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件 的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件 的每個特定功能或運行操作路徑的測試構成了一個個測試用例。

　　三、編寫測試用例

　　著重介紹一些編寫測試用例的具體做法。

　　1、測試用例文檔

　　編寫測試用例文檔應有文檔模板，須符合內部的規范要求。測試用例文檔將受制于測試用例管理軟件的約束。

　　軟件產品或軟件開發項目的測試用例一般以該產品的軟件模塊或子系統為單位，形成一個測試用例文檔，但并不是絕對的。

　 　測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體 測試用例都將包括下列詳細信息：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、注釋等。以上內容涵蓋了測試用例 的基本元素：測試索引，測試環境，測試輸入，測試操作，預期結果，評價標準。

　　2、測試用例的設置

　　我們早期的測試用例是按功能設置用例。后來引進了路徑分析法，按路徑設置用例。目前演變為按功能、路徑混合模式設置用例。

　　按功能測試是最簡捷的，按用例規約遍歷測試每一功能。

　　對于復雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在于可以避免漏測試。

　 　但路徑分析法也有局限性。在一個非常簡單字典維護模塊就存在十余條路徑。一個復雜的模塊會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合 適的使用規模。若一個子系統有十余個或更多的模塊，這些模塊相互有關聯。再采用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那么 子系統模塊間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設置用例的由來。

　　3、設計測試用例

　 　測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測 試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。

　　設計備選事件 和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重復 必須報錯，并且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，并同時盡量發現 其中的軟件缺陷。

　　可以采用軟件測試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質采用不同的方法。如何靈活運用各種基本方法來設計完整的測試用例，并最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。

　　LAYO最近下載了幾篇PPT；又看見了這樣一段描述。

　　G.J.Myers給出了關于測試的一些規則，被軟件工程領域認可：

　　（1）測試是為了發現程序中的錯誤而執行程序的過程；

　　（2）好的測試方案極有可能發現迄今為止尚未發現的錯誤；

　　（3）成功的測試是發現了至今為止尚未發現的錯誤。

　　上面這段話是測試行業經常能看到的一段關于測試的工程的一種解釋；可能有些太理性或者說是書面化的解釋，作為一個TESTER我很表示同意；但是一直沒有認真理解這段話。

　 　測試是為了發現程序中的錯誤沒錯；但是我認為有些狹義的想法；綜合整體的軟件質量去評估去看；不單單在過程中去發現程序中的錯誤；而包括在設計之初的錯 誤邏輯和不合理的流程以及操作方式都是測試的過程中要關注的因子；所以就不僅僅是為了發現程序的錯誤；一個認真思考的TESTER是不拘在程序之內的范 疇。所以我認為測試是為了發現整個項目中任何不合理的錯誤；包括文檔的錯誤、業務流程中的漏洞、程序中的BUG、不正規的操作方式、不合理的數據流程。當 然這算是一種理想測試過程。

　　好的測試方案極有可能返現迄今為止尚未發現的錯誤；我總是認為這句話帶有鉆牛角尖的意味；好的的是方案其實 是一種無窮盡的操作；記得有一個夸張的小道理：一百萬只猴子，給他們每人一個鍵盤，給他們足夠的時間，讓他們打出莎士比亞全集。就是在接近無窮的測試下會 讓程序的問題完全暴漏無疑；一個好的測試方案應該是合適項目的測試方案；到什么山唱什么歌；看菜吃飯、量體裁衣；根據項目去指定測試方案，這種方案下去測 試該項目才能真正說明項目問題。

　　成功的測試是發現了至今為止尚未發現的錯誤；我認為將測試工作進行了一次反革命性的引導；行業需要創新思維；需要吹毛求疵；只能說在現有的需求下去發現不應該出現的問題。測試用例是在有限的資源下設計出涵蓋面最廣而最有效的用例；不是說為了測試而測試。

　　測試用例文檔的價值在微軟和軟件測試行業之間有爭論。有幾個因素可以幫助決定是否選擇測試用例文檔。測試用例文檔有如下一些好處：

　　歷史借鑒。測試用例的存在要遠遠超過產品發布。持續工程以及產品未來版本的負責人往往需要借用測試用例來了解測試過什么，以及如何測試的。測試用例文檔以及一個有組織的儲存系統，對長期支持或修訂產品的一部分是至關重要的策略。

　　測試進展跟蹤。通過測試用例文檔，可以跟蹤一些額外的屬性，如測試用例的執行數目、測試用例的通過或失敗數目，以及每個功能領域的測試用例總數。

　　可重復性。好的測試用例文檔可以由任何人在任何時候執行。這同樣適用于自動和手動的測試用例文檔。重復準確地執行同樣的測試對重視步驟或檢驗回歸是至關重要的。

　　測試用例文檔也有如下缺點：

　　建立文檔的時間。如果建立測試用例文檔的時間比運行測試用例所需的時間還長，建立測試用例文檔也許就沒有意義了。經常有這樣的情況，即測試用例只需要在一個單一的環境下執行寥寥幾次。

　　功能變化引起測試用例過期。建立測試用例所需的時間很可能因為功能經常變化而增加，以至于失去控制。如果測試用例的功能領域變化頻繁，建立測試用例文檔就不一定是明智的。這種場景之一是嘗試寫測試用例以驗證用戶界面組件。

　　很難設想讀者的知識。寫測試用例的人往往對被測試的功能極為熟悉。這些人常犯的錯誤是在測試用例中使用術語或縮寫，而將來運行測試用例的人很可能看不懂這些測試用例。出現這種情況時，測試用例已不再能準確地重復，測試用例也失去了這一關鍵屬性。

　 　測試用例通常用測試用例管理器（TCM）來建立文檔，微軟大部分團隊用測試用例管理器記錄絕大多數測試用例。重要的是要記住，測試用例并沒有定義所有的 測試活動。如缺陷大掃除，那是整個團隊致力于數小時或數天的時間，專注于使用功能或應用程序，尋找可能被測試用例過的缺陷，這種測試活動在微軟的各團隊是 常見的。許多團隊也在產品周期中花時間致力于客戶的使用場景。例如，一些Visual Studio的團隊經常花一些時間，整個團隊除了在Visual Studio開發環境創造和建立各種應用程序外，什么都不做。

　　通常軟件測試會暴露軟件中的缺陷，經過修正后可以保證軟件系統的功能滿足需求并正確運行。但是，在系統測試和 確認測試中，測試人員容易遺漏一些隱藏的缺陷。眾所周知，軟件測試不可能發現所有的缺陷，而軟件開發周期各個階段仍然存在注入缺陷的可能，但是，有一些缺 陷是測試中容易忽略的，也就是說，通過測試方法和用例可以充分暴露這些缺陷，遺憾的是，它們往往被忽略或者某種原因忘記測試了，這就給軟件留下了隱患或者 危機。這些容易被忽略的缺陷包括：

　　1、安裝缺陷

　　通常項目組完成代碼后，發布時候安裝打包是最后一個環節，而軟件測試人員通常在測試的時候，沒有仔細的測試這一部分，而把用例集中在其他功能上。安裝時候的缺陷通常通過拷貝而不是運行安裝程序方式給測試人員安裝軟件，結果正式安裝時候出現問題，引起例如控件沒有注冊，注冊表沒有導入等。刪除時候沒有注意安裝文件夾是否存在用戶文件，造成數據丟失;使用絕對路徑;安裝順序沒有說明書。

　　2、配置文件

　　有些文件在ini等配置文件中寫出了管理員口令密碼等信息，而且是明文的！這是一個安全隱患。另外，有些安裝文件的 XML 文件，為了方便在數據庫和中間層連接文件中寫入了Admin 口令和密碼。作為一個合格的軟件測試人員，必須檢查這些可以用記事本打開的文件。因為，一個稍有常識而且喜歡探索的用戶，可能從中獲取信息而成為不自覺的黑客。所以，配置文件可能成為軟件安全方面的一個缺陷。

　　3、網頁安全缺陷

　　現在網站開發已經注意到：登陸網站進入其內部網頁后，直接拷貝網址，然后粘貼到另一IE 窗口輸入，可以繞過登陸直接訪問。也許商業網站很關注這個問題，但是很多行業軟件卻很容易忽略。

　　網頁安全缺陷還可能存在于 IE 彈出的子窗口。有些設計不嚴格的軟件，在主頁面關閉的時候子頁面還可以運行，這是一個明顯的漏洞，而且還大大增加了錯誤發生的幾率。

　　4、判斷順序/邏輯缺陷

　 　對界面進行多個輸入判斷的時候，非常容易出現這種問題。例如判斷年月順序，判斷長度，判斷非空等。假如操作員僅僅滿足單個條件，保存不能成功;而按界面 從上之下順序一一滿足條件之后，保存是沒有問題的。但是，改變一下輸入的次序，校驗失效。例如，一一滿足條件之后，不保存，倒過來將上面的輸入改成非法輸 入，然后保存，結果居然也能成功，這是因為原先的判斷由于發生過，或者根據語句順序只檢查最后一個判斷，所以沒有報錯。這種錯誤尤其在 Java scrīpt 腳本的頁面中要注意。能夠保存不能保證數據正確，有可能引起系統崩潰或者后續數據錯誤。所以，在測試的時候，不要按照正常的順序輸入，而是要打亂步驟，看 看代碼是否強健，是否在判斷邏輯上沒有錯誤。良好的代碼應該經得起折騰，至少保存時會再此全部進行判斷，而不只是簡簡單單走到判斷的最后一行。

　　5、調試語句和冗余信息

　 　維護項目和升級改造的推廣系統最容易潛伏這類缺陷。典型表現在沒有刪除或者屏蔽調試語句。彈出一個界面不友好的提示信息，會使不明真相的用戶產生誤以為 系統發生了嚴重故障，從而引起對軟件的不信任感。頁面中某個角落存在當前客戶不需要的冗余按鈕和功能也是一種缺陷。多余的功能會使用戶以為是額外附加部分 而去使用，其結果可想而知;而多余的按鈕會誤導好奇心強的用戶操作，產生不必要的錯誤。

　　同樣值得關注的還有參數設置，由于沒有實際數據，開發人員在調試或者單元測試的時候，習慣性的進行自我設定而忘了刪除，軟件測試人員可能會忽略掉了這部分測試，也可能導致在客戶現場發生錯誤而影響系統發布和驗收。

　　6、不可重現的故障

　　新參加軟件測試的人員或者新來的開發人員總是要問，不可重現的缺陷是否需要記錄，有必要嗎?回答是肯定的。測試必須如實的記錄發生的問題，也許不能重現，或者使非軟件系統本身問題，但是，可能這些偶然性背后是有規律的，不記錄這些，就不可能發現這些規律。

　　7、多節點的逆向流轉缺陷

　　當前軟件不少喜歡使用工作流來驅動。工作流的問題，就是可能出現多個流向分支。測試容易忽略的部分，就是工作流多節點的逆向流轉。例如，通過不 通過涉及兩個分支，但是流程逆轉的時候，有可能不是回到上一節點而是平級的另一個節點去了。軟件測試要格外注意這類用例的設計。另外，有些時候默認分支在 向前的時候是有默認值的，例如默認通過，那么保存的時候要提示用戶是否通過，否則可能由于操作疲勞而走錯了節點，引起回退。

　　8、輸入框缺陷

　　試過往輸入框粘貼數據而不是直接輸入嗎?可能這里會出現問題。按 Ctrl+V 的時候，輸入框會根據長度大小自動截斷輸入長度。但是用鼠標，截斷可能會失效。有一次測試人員就是用這種方法把一篇 Word 文檔輸入進去了，保存的時候，數據庫崩潰。有些網站登陸的口令****可以拷貝下來的，只要放在剪貼板里面馬上明文顯示。

　　輸入框可以說是問題最多的部分，能夠引起的麻煩也很多。日期、數字、文本等等，都需要耐心的測試一下。

　　9、界面布局缺陷

　　曾經有一次，項目經理回來向測試部反映一個問題，客戶對界面不滿意。原因很簡單，因為界面上刪除按鈕和保存按鈕挨得很近。結果有些操作不熟練的 業務人員，很容易誤按。這個問題是測試人員沒有意料到的，因此注意關閉、刪除、退出按鈕與保存、下一步等按鈕的距離。類似的按鈕應按此規則排列分布。

　　界面布局還可能發生在窗口最大化和最小化上，有可能窗口縮小的時候沒有下拉框或不匹配分辨率，對用戶來講，這個錯誤實在很低級。有些用戶由于操 作習慣，非常不喜歡騰出手使用鼠標，尤其是大量輸入的界面，因此，要注意設置鍵盤的快捷方式。還有，按 Tab定位到下一焦點時要注意順序，避免跳轉太靈活而讓操作人員感到無從適應，在界面進行維護或者修改的時候，不要忘了軟件測試開發人員是否無意改變了這 些快捷方式和跳轉順序。

　　10、版本和補丁包的環境問題

　　理論上講，這屬于兼容性測試應該覆蓋的問題。有些客戶很喜歡更新最新的軟件版本或者微軟時不時打些補丁包，問題就出現了。有時候升級不一定是好 事。這些問題最好在測試的時候增加幾個用例，多用不同軟件版本的機器跑一跑。軟件測試有個定律是：你沒跑過的地方，就一定會出事。經常聽到開發人員抱怨， 怎么我的機器沒問題，你的機器就有事了呢?這不能完全靠配置管理員解決問題，環境配置項是大家最容易忽略的。

　　11、用戶管理缺陷

　　用戶管理的角色和授權需要好好研究一下，作過測試的人員都知道，有時候為了測試的方便，測試用戶都是具有超級權限的用戶。而且，比較容易忽略用戶管理這一部分的測試。往往發往客戶的時候，很多測試用戶都沒有刪除。

　　另外，有些接口的用戶和口令，到軟件使用壽命結束都沒有更改過。在一次測試中，軟件測試人員發現，給一個用戶授超級用戶權限，之后更改這個用戶 為受限權限。使用中發現，用戶居然沒有真正回收權限，用戶管理界面上沒有任何不對。及早準備用戶管理用例，不要等到測試快結束時候才想起。

　　12、常識缺陷

　　從邏輯或者統計學上講，計算機是允許如此處理的，但是從常識上來講，這些情況不可能發生。例如電話號碼不可能出現小數點，終止時間不能大于開始 時間等等。除此之外，常識還要結合業務特點來進行判斷，因此，開發和測試人員要格外注意對自己知識的培養以及增加對需求細節的了解。不能因為一味追求進度 而采用最簡單的代碼來實現，對用戶來說，這些錯誤可能是很荒謬的。

　　盡管我們不可能完美的測試一個軟件，但是我們仍然可以改進我們的軟件測試。每次測試結束，及時總結測試中的不足，進一步完善用例。思考一下那些容易忽略的軟件缺陷，能提高對軟件測試的認識，提高所在組織軟件的質量。

　 　第一：“明確”待測試項目的需求。對于任何一個項目，無論你接手的項目有多小，甚至可能都算不上一個項目，而僅僅是一個小工具，明確需求非常重要。可能 很多人會說，公司現狀，測試能看到需求文檔幾乎不可能；也或者公司有需求文檔，但與實際的待測試項目相差甚遠；也或者還有其他的各種可能情況，但無論是什么原因，明確需求是任何一名測試用例設計者必須堅持也必須執行的一條原則。如果你是測試部的負責人，在面對需求不明確的項目時， 請你先收集待測試項目盡可能多的“文檔”，這些文檔有時并不一定需要是已經現成成稿的，其實我們可以通過“不恥下問”之后自行整理。測試負責人自己必須對 待測試項目做到“胸有成竹”。

　　第二：“分析”待測試項目。可能很多人這個時候會非常不以為然了，為什么要經過這么一個過程？“分析”待 測試項目的目的是讓我們更進一步的了解待測試項目，那可能大家這個時候又會問了，了解什么？大家想想，你明確了需求，可是你知道待測試項目的體系結構是什 么嗎？你知道我們采用了什么技術嗎？你知道這個項目蘊涵的業務知識有哪些嗎？對了，我們就是要通過更進一步的分析，整理出更為詳細的資料，服務于我們的測 試工作。

　　第三：“學習” 待測試項目的業務知識。這一點我相信很多人都能認同，比如你是做銀行相關項目的，那你肯定要具備銀行相關方面的知識，只有這樣，才能非常容易的明白為什么 這么設計，或者這么設計的優勢在哪里？針對采用的某種實現技術，只有更進一步的學習了解，你才能明確這種技術的優勢與弱勢分別是什么，針對這種技術的弱 勢，我們測試又需要重點測試哪些地方等等。這些問題都需要在我們提升我們自身業務水平的同時得到解決。

　　第四：內部討論。對于這點，我有 非常切身的感受，作為項目測試負責人，一定要更自己的測試團隊針對某個項目進行多次內部的討論，通過內部討論更進一步發現我們忽律的地方，同時也讓大家的 資源共享，用最短，最快的方式收獲最好的效果。