1、剛剛從事軟件測試職業，如何快速掌握編寫測試用例的方法？該怎樣編寫測試用例呢？

專家分析：

1、根據需求文檔，完全按照需求文檔框架/功能描述，根據自己的理解整理為用例。簡單來說，就是將需求文檔描述的內容，重新按照用例的格式編輯一次，把能想到的各種可能性添加進去。

2、搜索其他測試人員編寫的同類型功能用例，先理解，再根據項目實際需求的較小差異，重新新增/刪/改，組成滿足需求的用例組。

快速掌握用例其實沒有什么竅門，只有多看，多想，多寫，多評審。

2、怎樣的測試用例是好用例?

如果用一條用例覆蓋一個功能點在實際操作中有很大的缺陷。首先不能確保測試人員進行集成測試時對功能用例執行到位，可能會出現遺漏。因此我們在測試用例輸出過程中，建議測試人員就測試因子使用工程方法進行流程功能覆蓋。但是這樣引入另外一個問題，客戶的需求是不斷變化的，需求在執行設計和測試用例輸出時，很大幾率產生變化，這種變化勢必對原輸出的測試用例造成沖擊。調整的工作量有時會很大，有可能對整個功能推倒重新輸出用例。面對這樣的情況該如何解決？

專家分析：每個用例覆蓋一個功能點，是最佳的理想狀態。但條件覆蓋有個缺點就是每次執行會存在一個較長的周期，如果部分不可套用自動化，會導致測試和開發并行產生無法按時驗證完每個版本的分支。

有兩種方式可供參考：

1.在原本測試用例的基礎上，再次放大用例描述的模糊度，以利于用例可用于相似但細節不同的功能。以登陸界面的字符長度為12雙字節的用戶名提示框為例：

原始用例步驟：在登陸界面用戶名輸入框輸入11個中文字符。

修改后的用例步驟：在登陸界面輸入不超過字符長度限制的用戶名。

點評：原始用例步驟僅適合登陸界面用戶名字符長度限制為11以上的編輯框。修改后的用例可用于任何字符長度的用戶名編輯框。此方法還可用于對流程描述，如”進入編輯用戶名界面”可替換為”編輯用戶名”。

2.建立較為完善的基礎用例庫，項目用例作為基礎用例庫的子集存在。這樣的用例庫在針對單個功能時，存在多種不同的描述和設計。如1點的模糊程度不同可作為相同用例的不同兩支用例存在。而在以后的實際項目中，根據項目實際需求，從基礎用例庫篩選合適的用例組作為項目用例組。

3、有些公司的黑盒測試用例會演進為自動化用例。如果單一覆蓋點測試用例，會導致自動化腳本代碼復用率不高。像這樣的問題，應該如何解決？

專家分析：首先一般都是按照測試用例去做的，單一運行，假如希望腳本復用高，需要整理業務函數腳本，把常用的業務函數化調用。這個是你們負責設計框架的人去想的。如果覺得業務利用率不高，就寫成公共方法調用。

4、是不是性能測試適合男生？有專家說性能測試和功能測試沒多大關聯，沒必要先學功能測試再學性能測試。這個觀點對嗎？

專家分析：其實性能測試并沒有趨向于男生，就像開發人員也沒有男生優先的招聘條件一樣。之所以有這個說法，無非是大多數男生比女生更喜歡邏輯推理而已。

性能測試與功能測試還是有關聯的。有些性能測試還必須在一定功能測試基礎上測試。

5、做了幾年測試，自我感覺沒有什么提升，始終是在做一些手工測試，項目來了先不寫測試用例而是先測試，等以后項目不緊張了再補充測試用例。

我個人認為這樣是很不規范的。我一直都認為寫測試用例是最關鍵的，但是這幾年好像沒怎么寫過測試用例。還有面試的時候考官也會給你出一道題，讓你大概說下你設計測試用例的思路。這些總讓我感到腦子里好像空空的，沒什么思路。專家能否給些指點。

專家分析：1.“項目來了先不寫測試用例而是先測試，等以后項目不緊張了再補充測試用例”其實這種方式并不規范。如果你們已經有基礎測試用例組，那么在項目需求確認后，第一時間開始用例的篩選和更新適用的用例組，并在項目前期交付于項目組各個部門評審。這樣的操作無論對于項目質量控制還是項目出現問題后，對于測試人員的責任分攤，都是有極大利益的。

測試用例的設計本身是測試技能中最重要的技術之一。但是由于它本身涉及整個測試系統的其他各個技能，所以對用例的理解，實際上就是測試人員對測試的理解。若發現無法再寫出更好的用例，可多看看業務相關的資料，同時學習測試流程，將自身的測試思想涉及相關業務的邊邊角角，并融入到實際使用的測試流程中。這時你將發現之前的測試用例設計思想存在較大的提升空間，也逐漸能開始通過分析測試環境（不僅僅包括執行測試環境），熟練駕馭測試框架，制定測試策略。而之前設計用例欠缺的立足點，也會相應得到補足。有理有據，自然用例設計邏輯就清晰起來了。

文章來源：網絡 版權歸原作者所有

上文內容不用于商業目的，如涉及知識產權問題，請權利人聯系小編，我們將立即處理

總結

以上是生活随笔為你收集整理的软件测试技术之如何编写测试用例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。