從事軟件測試這項工作算起來正好一年了，對工作慢慢熟悉之後，也對日常工作中需要接觸的一些事和物有了一些想法，今天就測試用例簡單談談我在工作中的看法。
首先我們要明確，什麼是測試用例，它存在的意義又是什麼？在我看來，測試用例就是一份能夠幫助我們完成測試的文檔，它可以對我們的測試覆蓋度進行保障，也可以對我們的測試起到啓示的作用。它存在的主要意義我認爲有兩方面，一是引導協助我們完成日常工作中的測試任務；二是在產品發佈後，提供產品功能上乃至性能、兼容性上的判斷標準。
那麼如何去判斷一份用例寫的究竟是好是壞，這是一個沒法完全保證的問題。每個人都有自己的做事方法，對應的他的用例執行、編寫都有自己的特色。我們只能從客觀的方面去判斷這份用例是否達標乃至優秀，判斷標準無外乎兩點：一，測試覆蓋度；二，發現缺陷效率。這兩者是相輔相成，但又相對獨立的，我們可能會發現一份用例在某一項上表現的特別突出，但是另一項則很失敗。舉個簡單的例子，一個包含4個條件的搜索功能，我們可以用窮舉法對這一個功能寫出上百條用例，覆蓋度非常高，但是缺陷發現效率則會非常低。也就是說，在判斷用例是否達標上，單項的標準是不準確的，更多的應該綜合考慮。但用例編寫完成初期，沒有人能夠衡量出來這份用例的發現效率，這是一個無法解決的問題，我們更多的只能通過經驗、不斷的維護才能逐漸將用例完善好。
以上內容是我對用例的一些看法，下面重點說下我在這段時間中，在用例編寫過程中的一些想法，這裏需要說明的是，每個人的想法、風格不同，以下內容僅供參考，但希望能對大家有所幫助！
一，關於用例框架
這裏必須得強調，用例框架的搭建是一個必不可少的過程，一份用例好不好，很大程度上取決於框架的搭建效果。框架最能體現出一個人的用例設計思想，它不僅能幫助我們完成用例設計，同時也會幫助我們節省很多時間！
先說下框架在我看來有哪些優勢，①框架是思路的表現，對照框架更容易將產品中各個需求、功能理清；②便於修改，用例設計不是一蹴而就的，在設計過程中我們面臨這各種各樣的問題，隨時可能需要對框架、用例進行補充，除此之外，在設計過程中，我們自身也會存在思考不全面，需要補充、調整的情況；③便於查看，毫無疑問，一份Mindjet MindManager設計出來的思維導圖遠比一份excel來的清晰，也更方便檢查。
接下來簡單說下我個人框架搭建的方式，首先我會先思考，將一份需求或者功能分割成哪些模塊（彼此影響小且全部涵蓋）比較合適，這些被分割後的模塊或功能就成爲了我們的一級模塊；接下來是分別對各個一級模塊進行設計，正常情況下，一級模塊對應的就已經是具體的功能點了，這時我會將這個功能實現的過程進行分解，簡單來說就是實現這個功能的前置條件、功能實現的過程、功能實現後的結果及操作中的異常場景，之後根據具體的功能進行措辭，將這些內容作爲二級模塊；再之後就是對每個二級模塊進行測試點的分析，那麼這些測試點就可以最終轉化爲我們的用例。在以上三步過程中，第二步相對來說是最難的，也是調整最多的，那麼在這裏就要說明下，爲什麼前文提到搭建框架會對用例設計節省時間，主要原因就是在這裏。在我編寫用例的過程中，從來沒有一次是框架搭建完成後可以直接使用的，總會在第一次搭建後再進行調整，面對mindjet，我們調整起來會非常方便，並且基本不會出錯，但如果是面對一份完整的excel用例，所面臨的困難及花費時間都是非常大的。
二，關於用例編寫
上文已經說過了，框架搭建的主要意義就是幫助我們完成用例設計，那麼在框架搭建完成後，我們用例是不是就可以完全按照框架來寫了呢？結果是必然的，當然可以，但是在寫用例的過程中我們仍然需要思考，需要對框架、用例進行補充完善。我的習慣是先將框架中的內容完全遷移到excel中，再進行具體用例的填寫，這樣一方面可以避免頻繁切換屏幕導致的工作量浪費；一方面是可以及時對框架、用例進行完善。
那麼在這裏需要注意一點，也是我們不論是在設計還是執行過程中都需要關注的一點，情況大致可以這麼描述，一個測試點中包含了A、B兩個功能或者更多功能，並且在操作B功能的時候，其實A功能也必然需要操作，那麼這時，我們是否還需要單獨將A功能測試寫出來？實際點的例子就是一個輸入框的測試，系統限定字符輸入限制是20個以內，我們是否需要將能否輸入20個以內的字符作爲一條用例？我相信很多人都會認爲沒有必要，因爲我們後面會寫一條輸入超過20個字符的用例，其實這條用例已經包含了之前所描述的檢查點。類似於這種情況的會很多，框架搭建時我們需要寫出來，但是當具體填用例時，我們則需要進行過濾。
一份用例的好壞標準在文章之初已經說過，在一定程度上可以說，用例的覆蓋度和發現效率是成反比的，如何讓兩者平衡，這就需要我們在用例編寫過程中將一些沒有意義的、冗餘的用例給去除掉，也許從理論上它是應該存在的，但從實際角度出發，它的存在完全多餘。
接下來簡單說下我在用例設計中，怎麼去結合所學的用例設計方法。和前面說的類似，完全的照搬理論知識，只會讓用例變得冗餘！首先說下流程法，這個是最容易解釋的，這個方法貫穿了我們整個用例設計，框架搭建過程中的1、2、3級模塊劃分主要採用的就是這種方法，它的優勢主要就在於能夠清晰的讓別人明白你的測試流程，從哪到哪，一目瞭然；其次是邊界值，這個用例設計方法是非常好用的，但是稍不注意，它也是造成用例冗餘的罪魁禍首，這點前面已經解釋過了，這裏就不多贅述，只能說在使用時需要考慮、結合實際功能；最後是正交法，關於正交法，我們在學習這種方法的時候所瞭解的就是在保證用例覆蓋度的同時提升用例的缺陷發現效率，但是在實際過程中，正交法的使用是最複雜的，正交表也僅僅是一張數學表格，它代表的也只是理論，對於一份用例來說，正交表中所給定的場景還是太多了，所以我們在實際過程中需要做的是刪減，而不是補充，至於如何刪減，文字描述過程會比較繁瑣，總結的來說，就是每個條件的每個場景出現次數控制在1-2次內就可以了。對於其他的用例設計方法如圖表法和因果圖，更多的是體現一種測試思想，實際用例設計中並未接觸及使用過。
三，用例覆蓋度及缺陷發現效率的衡量
我認爲，用例的覆蓋度在於你是否將所有功能及特定的異常場景均表現在用例中，發現效率則表示我們在執行用例中會發現的缺陷數量。
首先說關於覆蓋度，就像前文所說的，在我寫用例過程中，我非常反感出現重複、冗餘、無意義的用例。在我看來，用例的覆蓋度不應該用具體寫了多少用例去衡量，更多的應該是寫了多少功能點、寫了多少場景來衡量。爲什麼這麼說，原因在我看來很簡單，用例寫出來之後是由測試人員去執行的，我一直以來的想法是，一份用例的作用不應該是指導完成測試，而應該是引導完成測試。一字之差所代表的含義完全不一樣，前者是傻瓜式的執行，後者是帶着想法去工作，孰優孰劣，一目瞭然。那麼這就要求我們的用例具有一定的擴散性，而一份冗餘的用例是絕對沒有這種效果的，至於什麼樣的用例能帶讓我們在執行過程中起到引導作用而非指導，關於這點還有想到具體好的方法，這裏就闡述下我對用例覆蓋度的觀念。
接下來說用例的缺陷發現效率，怎麼去衡量用例的缺陷發現效率，在我看來，衡量缺陷是不是用例發現的，看的不應該是用例所描述的內容及預期結果，一切在執行用例過程中發現的問題均屬於用例發現缺陷！爲什麼要這麼說，前面已經說過了，用例在保證覆蓋度的同時要精簡，如何去精簡，我認爲就是將一切無用、重複、冗餘的用例都給去除掉。在學習用例編寫初期，導師要求我們的是一條用例對應一個檢查點，同樣這在我看來也只是理論。實際工作中，任何一個步驟做完，它對應的檢查點都不可能只有一個，我們所寫的預期結果，往往是我們認爲最重要或者是更容易出現缺陷亦或者是容易被忽視的情況，但就這些操作本身，所完成的測試點要遠遠不止一個預期結果。也就是說，如果一條用例執行完了，出現了缺陷，但是這個缺陷與預期結果其實沒有多少關係，我們同樣應該將其歸類於用例發現的缺陷。簡而言之就是，用例執行過程中發現的缺陷均屬於用例發現缺陷。
對用例的想法基本就全在這裏了，絮絮叨叨的說了這麼多，在這裏我想用一個場景來描述我所想表達的意思。我們所做的工作大多數情況下是黑盒測試，假設我們要對這個盒子進行測試，往往我們所做的是從外向內測試，保證了深度和基本的覆蓋度，但實際上，我們更應該做的應該是從這個盒子裏面向外測試，也就是說由已有功能對場景進行測試。看似是一樣的，但實際意義則完全不同，當我們對內測試時，再深入，所測的也有限且侷限性很大，因爲我們只能看到我們自有的功能。但我們由功能向外去擴展測試時，所能達到的空間是無限的，這樣的測試才能更好的幫助我們提升產品質量！
最後迴歸到本源，沒有人願意和有耐心重複的去一件無意義的事，這是毫無疑問的。一份用例寫出來後最本質的目的其實就是爲了讓人執行，所以如何讓執行人員願意去執行，並且在執行過程中能夠發現足夠全面的缺陷，這點纔是一份用例的本源。這也是爲什麼我在文章之初寫到，一份用例不應該是指導工作人員完成測試，而應該是引導！
