功能測試怎麼寫

【不在於測試用例該怎麼寫，而在於想怎麼測。】

【對用例的理解表達出來，格式自然出來了】呵呵，偶要頂一下，偶不是完全贊同這兩句話。用例的理解跟格式沒有必然的聯絡。

也沒有主次輕重之分。【先保證自己對業務流程和業務規則的理解和熟悉，然後可以對這部分先思考一下，哪些地方需要測試，需要怎樣的測試？如何來施行這些測試？之後再增加對系統中其他規則、特性和演算法的熟悉，繼續增加測試的深度和廣度。】

——這句說的很對。有這麼一個公式， 資料結構+演算法=程式。

這裡類比一下用例設計，jackei和skinapi版主強調的是用例的“演算法”，而文件格式是用例的“結構”。兩者的關係是相輔相成，而不是矛盾的（好像在上政治課哈）。

至於說“對用例的理解表達出來，格式自然出來了”，這個境界太高了，不是一般人可以做到的。面對現實的企業應用，做專案的話你會遇到各種各樣的情況，要做到“格式自然出來”實在是太……厲害了呵呵。

是這樣的：用例格式相當於一個規範，給你一個結構，一個框架（framework），僅此而已，並不因為你的用例模板而能體現用例的好壞。所以， “用例怎麼寫”其實分兩個：用例的“演算法”+用例的“結構” （也就是模板）了。

【不在於測試用例該怎麼寫，而在於想怎麼測。】

【對用例的理解表達出來，格式自然出來了】呵呵，偶要頂一下，偶不是完全贊同這兩句話。用例的理解跟格式沒有必然的聯絡。

也沒有主次輕重之分。【先保證自己對業務流程和業務規則的理解和熟悉，然後可以對這部分先思考一下，哪些地方需要測試，需要怎樣的測試？如何來施行這些測試？之後再增加對系統中其他規則、特性和演算法的熟悉，繼續增加測試的深度和廣度。】

——這句說的很對。有這麼一個公式， 資料結構+演算法=程式。

這裡類比一下用例設計，jackei和skinapi版主強調的是用例的“演算法”，而文件格式是用例的“結構”。兩者的關係是相輔相成，而不是矛盾的（好像在上政治課哈）。

至於說“對用例的理解表達出來，格式自然出來了”，這個境界太高了，不是一般人可以做到的。面對現實的企業應用，做專案的話你會遇到各種各樣的情況，要做到“格式自然出來”實在是太……厲害了呵呵。

是這樣的：用例格式相當於一個規範，給你一個結構，一個框架（framework），僅此而已，並不因為你的用例模板而能體現用例的好壞。所以， “用例怎麼寫”其實分兩個：用例的“演算法”+用例的“結構” （也就是模板）了。

檢視原帖>>。

我這邊有一些測試時應該注意的一些問題和解決辦法，當做拋磚引玉。

1.如何在測試中儘量找出多的問題

頁面，流程，功能，資料正確性以及查詢可以通過用例測試檢查出問題並提交開發人員解決，有些功能須反覆測試，如流程，資料正確性

2.效能問題如何測試

效能測試分應用軟體效能，資料庫效能，伺服器效能以及網路效能

某功能的效能測試可以在做其它相關功能測試時同步測試.

軟體的整體功能測試有待解決.

3.資料有效性如何測試

資料有效性測試通常是先做一些業務，然後通過查詢表及資料庫來檢查，出錯時通常須檢查兩個方面，一方面要保證存入資料庫的位置正確，另一方面要保證查詢語句正確.

4.一些隱性的BUG測試

如資料庫死鎖，軟體出現無窮迴圈，一些通過資料的測試可以測試出來.

另一方面應付突發問題須有出現問題後的解決方案.

它的一般形式是這樣的：

比如對登陸功能的測試用例的編寫：

用例編號：DL_001（編號通常會根據功能或模組編寫）

功能模組：登陸

測試標題：輸入正確的使用者名稱和密碼後，能否正常登陸

前提條件：1. 網路正常（也就是你做這條測試前必須要有的前提條件）

操作步驟：

1. 進入登陸頁面

2. 輸入正確的使用者名稱和密碼

3. 點選登陸按鈕

期望結果：登陸成功

實際結果：

另外附圖另外一個例子：

1. 首先學習軟體測試基本知識和軟體流程。功能測試最開始最基礎的就是分析需求編寫測試用例，測試是把握質量的守關人，保證不漏測的第一步就是要編寫儘可能全面的測試用例。可以學習用例編寫方法、黑盒測試方法，閱讀一些書籍，比如：軟體測試藝術；此外，瞭解軟體流程也很重要，根據迭代所處階段測試可以做不同的事情，需求宣講階段制定測試計劃、分析需求編寫測試用例；開發階段瞭解實現技術細節準備開發自測用例；提測後按用例測試，每天丟擲風險和進度，根據執行質量考慮是否測試多輪，根據質量判斷是非可以上線釋出；上線後及時根據運營問題；

2. 基礎打牢後多實踐。測試是講究經驗的職業，從簡單需求開始，制定測試計劃，編寫用例執行，執行過程及時調整計劃爆出風險和進度給團隊知道非常重要。從簡單需求到複雜需求到迭代跟進，除了執行，技術瞭解和bug跟進分析很重要，瞭解技術實現可以幫助你設計更全面的用例，更好評估功能質量風險；bug分析也是，往往一個經典的bug分析出來會發現更多隱蔽問題；功能測試完成建議編寫測試總結，對測試方案、邏輯實現、發現問題和自己分析過程進行整理；

3. 進行下去後會更加深入瞭解被測物件，從而可以做更多深入測試。比如穩定性測試，效能專項測試，介面測試等；團隊合作下去可能會發現一些流程上的問題，可以思考如何優化流程讓合作更高效，以及沉澱文件和規則；迭代跟進後會有一些質量效率問題，需要思考如何優化：自動化、精準測試、重複工作指令碼化、工具化；根據每個迭代總結和測試資料分析也需要思考哪些資料待提高：漏測情況、bug發現情況；使用者反饋問題多了，可以思考如何專題解決、如何快速定位……將這些工作完成並記錄沉澱下來形成方法論，多做分享擴大自己影響面；

4. 團隊擴充套件後就需要思考如何培養新人，如何開展團隊工作，幫助大家一起進步、高效工作；

專案支援是基本，在這基礎上多發現問題多實踐多思考，擴大自己影響。

？ 概述：對測試物件的功能測試應側重於所有可直接追蹤到用例或業務功能和業務規則的測試需求。

這種測試的目標是核實資料的接受、處理和檢索是否正確，以及業務規則的實施是否恰當。測試目標 確保測試的業務功能正常，其中包導航性質選單，資料輸入，處理和檢索等功能。

測試的範圍 1、介面裡面常用功能按鈕：增、刪、查、儲存、取消等。2、下拉列表、單選、複選、3、文字框技術 利用有效的和無效的資料來執行各個用例、用例流或功能，以核實以下內容：1、在使用有效資料時得到預期的結果。

2、在使用無效資料時顯示相應的錯誤訊息或警告訊息。3、各業務規則都得到了正確的應用。

開始標準 測試執行完成標準 1、完全實現需求中定義的功能2、在功能實現的基礎上實現正確的業務流程需要考慮的特殊事項 ？ 方案：給出具體的針對性的測試方案，為今後設計用例或在測試過程提供一個大綱性質的方案。下拉列表 1、條目內容的檢查，對照需求說明察看條目內容和實際內容是否一一對應。

2、條目的功能能否實現，逐一執行列表框中每個條目的功能。3、在列表框中能否輸入資料，檢查能否輸入或則貼上資料向組合列表框內。

4、能及時獲取得到新增加的資料並顯示。文字框的 1、邊界值和等價類測試用例方法。

2、可以採用隨機測試進行測試用例的補充。3、輸入符合規定的資料。

4、輸入已經存在的內容。5、輸入超常字元。

6、輸入特殊字集。7、輸入空白，或則空格。

複選框的測試 1、多個複選框被選中。2、多個複選框可以被部分選中。

3、多個複選框可以不被選中4、逐一執行每個複選框的功能單選框的測試 1、單選按鈕是否只能同時選中選中一個。2、個單選按鈕的功能是否正確完成3、是否有預設被選中的選項命令按鈕的測試 1、對各類按鈕的測試。

2、功能是否實現。3、提示資訊是否正確。

4、描述、圖示功能是否一致。錯誤處理 1、對於不符合業務背景的輸入資料是否有相應的處理方法。

2、單擊按鈕正確響應操作。3、對非法的輸入或操作給出足夠的提示說明。

4、錯誤說明應當清楚，命了，恰當，讓使用者明白錯誤出處。5、對於無法恢復的操作必須提供確認資訊，給使用者放棄選擇的機會。

我是做軟體測試工作的，仁者見仁智者見智，水平有限，就你提出的問題作一個簡單的回答吧，一是期望對你的問題有所幫助，二也是對我自己的提高。

1、我對你的第一個問題表示質疑，你認為測試是保證軟體質量嗎？能保證嗎？

測試只能提高軟體質量，做不到保證，bug是永遠存在的，測試工作可以讓這

量減少、降低嚴重問題的存在；軟體過程才可能保證它的質量，不是軟體測

試，所以這一點我要明確出來。一個軟體的質量好壞不依賴於測試者，測試

再高明，軟體設計本身的水平面要品質不高，巧婦也有無米之炊的無奈。

2、測試的原本目標就是發現缺陷，挑毛病，工作性質和開發人員相反，但目標

是一致的，都是為了使軟體更完美、更穩定。

3、蓋房子的時候，先打地基，地基如果有毛病（如不夠深、不平），那以後房

蓋起來了住個幾年，你會發現樓上的樑會發裂，滲水，然後越來越讓人擔

憂。這時你要修復怎麼辦，再怎麼補都不放心，因為地基有缺陷啊！這個道

和第三個問題是一模一樣的，修復的代價太大太大了！在測試中有一個規

則，問題越早解決代價越小，單元測試發現的問題解決只要1塊錢，等到整合

測試再解決，要10塊錢，你認為比例有多大？需求分析系統設計是源頭，重

中之重，這個比例我認為要在上面我舉例中增加80%，就是說它會導致你在編

碼階段多付出8塊錢。前期可能不覺得，越到後期將發現非常頭痛，這也是我

的經驗之談，沒有太多的科學性哦。

4、對於測試員，首先是效率減低；對於專案而言，成本增加了。瞧病就錯了

診，影響大麼？將導致後面的百分之八十的事情白做了，百分之二在長遠

目標中有後期幫助，同時證明另外百分之八十步入歧途。這就要在測試設計

的時候要仔細全面，但是這種事情多少都避免不了，早一點發現並改變，也

是很重要的，另外多佈置一些小結會議，有利到測試的工作方向和目標。

usfo，希望我的回答對你稍有幫助哦。