作為軟件測試人員（SQA/SQC），做的最頻繁并且最主要的活動之一就是編寫測試用例了。首先，請記住以下所有的討論都是關(guān)于編寫測試用例，而不是設(shè)計/定義/確認(rèn)測試用例（TC）。
這項主要活動有幾個重要的關(guān)鍵因素，讓我們先來大概了解一下吧。
A、測試用例要易于定期修改和更新
我們生活在 一個不斷變化的世界，軟件也不能免于變化。需求也是如此，這就直接的影響到了測試用例。不論什么時候，一旦需求發(fā)生變化，測試用例就需要更新。然而，并不 是只有需求的變化才會引起測試用例的版本變化和更新。在測試用例執(zhí)行過程中，腦海中會涌現(xiàn)出許多的想法，單個測試用例的許多子條件會引起更新甚至測試用例 的補(bǔ)充。除此而外，在回歸測試中一些補(bǔ)丁和/或波紋都會需要修訂或是新的測試用例。
B、測試用例要易于分配于執(zhí)行用例的測試人員
當(dāng)然了，讓單獨一個測試員執(zhí)行完所有的測試用例是幾乎不太可能的。正常情況下，一個單獨的應(yīng)用程序會有幾個測試員分別負(fù)責(zé)測試不同的模塊，因此，根據(jù)他 們自己在應(yīng)用程序中測試的部分測試用例也會相應(yīng)的分配開。一些和應(yīng)用程序集成相關(guān)的測試用例有可能會由多人執(zhí)行而有的則只是由單獨的個人執(zhí)行。
C、測試用例要易于集群和批處理
屬于一個測試場景的測試用例通常都會要求以一些特定序列或小組格式來執(zhí)行，這很正常，也是很常見的。可能會有一些測試用例是其他測試用例的先決條件，同 樣的，根據(jù)AUT的業(yè)務(wù)邏輯，一個單獨的測試用例會在幾個測試條件中存在，而一個單獨的測試條件也可能會由多個測試用例組成。
D、測試用例有相互依賴的趨勢
測試用例中一個有趣并且重要的行為就是他們彼此之間是相互依賴的。在具有復(fù)雜業(yè)務(wù)邏輯的中型到大型應(yīng)用程序中，這種趨勢則更為明顯。任何應(yīng)用程序中能明 確的觀察到這個行為的最清晰的地方就是，相同甚至不同應(yīng)用的不同模塊之間的互操作性。簡單的說就是，不管相異模塊或應(yīng)用程序是在哪里相互依賴的，相同的行 為都體現(xiàn)在了測試用例中。
E、測試用例要易于在開發(fā)者間分配（尤其是在測試用例驅(qū)動開發(fā)環(huán)境中）
關(guān)于測試用例，重要的一點就是，它并不是只被測試人員使用的。在正常情況下，當(dāng)開發(fā)人員修改bug的時候，他們間接的使用了測試用例來修改問題。同樣 的，如果遵守的是測試用例驅(qū)動開發(fā)，那么開發(fā)員則直接使用了測試用例來構(gòu)建他們代碼的邏輯并覆蓋測試用例中處理到的所有的場景。
所以，將以上的5點記住，這里給出一些編寫測試用例的建議：
要簡潔但是不能太簡單；要復(fù)雜但是又不能太復(fù)雜。
這句話似乎是自相矛盾的，但是我發(fā)誓并不是如此。走完測試用例的每一步，正確序列和預(yù)期結(jié)果的正確映射都得要精確，這就是我所說的讓測試用例保持簡單。
而，使其復(fù)雜一點實際上指的是測試用例得和測試計劃以及其他測試用例相融合。當(dāng)需要的時候，參照其他的測試用例，相關(guān)工件，GUI等。但是做此事的時候 得均衡一下，不能讓測試人員為完成單個測試場景就來回的搬運大堆的文件。另一方面，不要讓測試人員希望你會壓縮這些測試用例文件。在編寫測試用例的時候， 請時刻記住你或者別人不得不修改并且更新這些測試用例。
測試用例編制完成之后，以一個測試人員的角度再審視一遍：
永遠(yuǎn)不要以為你寫完測試場景的最后一個測試用例后就算完事了。回過頭去從開始將所有的測試用例再看一遍，但是不要當(dāng)自己是個測試用例的編寫者或 測試策劃者，以測試人員的角度審視所有的測試用例。理性的思考并且干運行你的測試用例，評估一下你所提到的每一步都是清晰易懂的，并且預(yù)期的結(jié)果和這些步 驟也是相協(xié)調(diào)的。
測試用例中規(guī)定的測試數(shù)據(jù)不僅要對實際的測試人員是可行的，而且也得是依據(jù)真實的實時環(huán)境的。要確保測試用例中沒有依賴沖突，而且也要確認(rèn)對于其他測試用例/工件/GUI的所有參考都是精確的，否則測試人員會陷入大麻煩中。
約束測試人員，但同時也讓他們感到容易。
不要把測試數(shù)據(jù)都留給測試人員，給他們一個輸入的范圍，特別是當(dāng)執(zhí)行運算的時候或者是應(yīng)用程序的行為是取決于輸入的時候。也許你會把測試項目的 值分給他們，但是永遠(yuǎn)不要讓他們自己來選擇測試數(shù)據(jù)項目，因為，有意無意的，他們會使用相同的測試數(shù)據(jù)因而在執(zhí)行測試用例的時候一些重要的測試數(shù)據(jù)會被忽 略掉。
根據(jù)測試類別和應(yīng)用程序的相關(guān)領(lǐng)域?qū)y試用例進(jìn)行組織，這能讓測試人員感到容易一些。清晰的指出哪些測試用例是相互依賴的/或是可批處理的。同樣的，明確的指示出哪些測試用例是獨立的，孤立的，因此，測試人員就可以按照自己的意愿管理他/她的全部測試活動。
成為一個貢獻(xiàn)者
從不接受FS或設(shè)計文檔原來的樣子，你的工作不僅僅是將FS瀏覽一遍然后明確測試場景。作為一個和質(zhì)量相關(guān)的資源，你要毫不猶豫的去貢獻(xiàn)。要給 開發(fā)人員提建議，特別是在測試用例驅(qū)動開發(fā)環(huán)境中。建議一些下拉列表，日歷控件，選擇列表，單選按鈕，更有意義的信息，警告，提示，可用性的改進(jìn)等等。
不要忘記最終的用戶
最重要的利益相關(guān)者就是將會實際使用AUT的最終的用戶，所以，在編寫測試用例的任何階段都不要忘記他。事實上，在SDLC的任何階段也都不能 忽視最終的用戶，但是目前我只強(qiáng)調(diào)和我討論的話題相關(guān)的。所以在識別測試場景的時候，不要忽視這些大多情況下被用戶使用的用例，或者是那些甚至不太使用的 業(yè)務(wù)關(guān)鍵用例。把你自己想象成最終的用戶，把所有的測試用例瀏覽一遍，判斷一下你文檔中測試用例執(zhí)行的實際價值。
總結(jié)：
測試用例的編寫是一項會對整個測試階段產(chǎn)生重要影響的活動。這個事實使得測試用例文件編制這個任務(wù)變得非常的關(guān)鍵并且微妙。所以，編寫測試用例 得先適當(dāng)?shù)挠媱澮幌拢€得非常的具有條理性。編制測試用例文件的人必須記住，這項活動不是為他/她自己而做的，而是為了整個團(tuán)隊，這個團(tuán)隊包括了其他測試 人員和開發(fā)者，還有那些會被這項工作直接或間接影響到的客戶。
所以，在這項活動進(jìn)行的過程中必須給予適當(dāng)?shù)年P(guān)注。對所有的使用者來說，測試用例文檔必須是很好理解的，方式明確，維護(hù)簡單。除此而外，測試用 例文檔必須介紹所有重要的特征，必須覆蓋AUT所有重要的邏輯流，伴隨著實時和實際可接受的輸入。你編寫測試用例的戰(zhàn)略是什么？和我們的讀者分享你的建議 吧~也可把你的問題寫在下面的評論中。