專家分析：對於黑盒測試來說其實研究透了，你也非常厲害，像自動化測試、效能測試它們有時候還是需要有些功能測試的功底的。

12、在測試資源不足的前提下， 是否可以用粗顆粒度的用例和測試人員跑場景流程過程中的經驗來取代大量的用例呢？例如： 用例只有一個，但是跑的過程中利用測試者的觀察力與經驗，順帶的間接檢查其他功能點。

　　專家分析：測試用例是測試工作的核心。測試工作是講究投入產出比的工作，這也是測試用例設計的指導思想。

　　測試用例有度的概念，正如亞里士多德在《倫理學》中討論道德為例：道德意味著過與不及之間的狀態。面向測試用例，網上流傳著這麼一句話：“不同的機構會有不同的測試目的；相同的機構也可能有不同測試目的，可能是測試不同區域或是對同一區域的不同層次的測試”。

　　如果外部環境引數較多，並且互相矛盾，比如團隊新手多，但測試專案對質量要求很高，並且專案週期短時，如何構建測試用例的顆粒度，就更需要測試管理人員的平衡。

13、對於產品的測試，每次更新版本的功能都不一樣，而每次都要進行舊功能的測試，怕新增加的功能影響到周邊的功能，怎樣設計用例更加全面呢？

　　專家分析：這是最常見的形式。可以分成新功能測試和老功能迴歸兩塊。新功能測試不講了，你也清楚，老功能迴歸這塊需要一個迴歸測試，視測試自動化的程度來定，自動化程度低，那就需要制定詳細的迴歸策略，和開發討論清楚新增、修改功能的影響範圍，來定迴歸測試用例；自動化程度高的，那就直接全面迴歸就行了。

14、什麼樣的用例才是好的用例呢

　　專家分析：做好以下三點就是一個好的用例。

　　第一：依據分明

　　眾所周知，一個專案首先立項，然後經過一系列的動作到了需求分析，做完需求分析後，測試就可以做測試需求，然後就可以寫測試用例了。所以寫測試用例的依據就是需求。這麼說太籠統，舉一個例子。一個系統經過前期的需求分析，詳細設計，模組設計等一系列的動作，最後生成了詳細的需求說明和詳細設計文件等等，在這些文件中，已經很詳細的描述了所有的需求點和功能點，也有較詳細的技術說明，接下來的工作就是怎麼把這些功能點和需求點變成測試點，這就需要做好測試需求分析和測試方案工作，生成一個個可測試的測試點。這也是需求必須可測的一個體現。

　　假設經過上一步工作，分析出這個系統有5個模組，50個大的功能點，500個具體需求點，最後生成了5000個測試點。那麼ok，我們就要寫5000以上個測試用例。還是那句話，一個測試用例只能對應一個測試點，測試點和用例是1對1的關係；一個需求點可以對應多個用例，需求點和用例是1對多的關係。這樣做的目的在統計中講。

　　第二：目的明確

　　用例都有個測試目的，這就是要目的明確，並且也只能有一個目的。前面無論多少步驟，都是為了找到這個目的途徑。功能從大到小有層次的劃分，我們做測試用例也是有層次的，不然你怎麼定義用例的優先順序呢？等到測試最小的功能點時，支援這個功能點的其他上層功能點，我們都預設正確就可以了，這就是我們的預期，所以在測試步驟中不用對上層的功能專門考慮測試資料，只要把他當成一個正確的找到目前的功能點的途徑就行。換句話說，你要測試的功能點需要點10個連線才能找到，那麼前9個連線我們在以前就應該設計了用例，在第10個連線中預設他們正確就ok，這個用例的前9步，只是告訴你如何找到第10步。就是這樣。

　　第三：便於統計

　　測試用例對整個測試過程的質量控制和評估有很重要的意義。

　　一、可以做測試需求覆蓋分析。這樣如果一個用例寫幾個測試點，那麼就無法完成需求覆蓋分析工作，至少是不符合規則的。

　　二、做用例成功率分析。一個用例中有多個測試點，肯定會造成用例數量減少，用例失敗率大大增多。那麼你做的用例成功率還有什麼意義？

　　你還可以通過模組劃分，來分析哪個模組存在的問題較多，還有可能存在更多的問題（應為程式設計師不同，能力就不同，缺陷喜歡扎堆分佈，這個大家都知道），存在問題較多的模組需要做進一步的測試或者下一次作為測試重點。如果你統計的資料不準確，會誤導結果的。

　　三、做缺陷分析。用例失敗了，就生成一個缺陷。如果一個用例中寫了多個測試點，迴歸的時候，這幾個測試點也有迴歸，有些可能與缺陷毫無關係的測試點，都被你迴歸了。

15、易用性的測試用例在編寫上有什麼技巧？從網上看過類似的易用性用例，但是感覺這方面的用例寫得太籠統，有時大家理解會有不同.針對易用性和介面性的用例，有怎樣的區分標準呢？

　　專家分析：易用性用例涉及的測試點通常都未在需求文件中明確定義。但由於其本身與普通的功能/UI用例的結構沒有明顯區別。故較為常見的兩種處理方法如下：

　　A．在設計用例階段，將此部分用例標記並在用例評審中進行討論和澄清。確認其用例預計輸出後，再將其放入相應的功能/UI用例組中。

　　B．在測試執行階段，出現此類用例時，tester與RD爭執較小的部分，兩個部門單獨溝通即可；而當tester與RD無法獨立達成共識，申請PM一起評審此部分用例的預期結果，以達成共識。

　　小結：易用性用例在設計階段通常不需要額外劃分。

16、功能性測試用例，在編寫前有明確的測試策略和測試方法，但是在實際編寫中每個人寫的情況不一樣，有的寫的細、覆蓋全，有的則比較粗。如何解決這類問題呢？

　　專家分析：此問題主要涉及單個測試團隊的測試策略，通常來說，一個測試團隊在測試單個專案時，測試策略不會作大幅改動。所以，測試用例的粒度在某一段時間內通常固定為一個範圍。

　　測試用例的粒度取決於多個測試環境因素：測試用例設計水平，執行測試測試技能水平，專案測試周期和資源分佈，專案出場標準要求……而作為測試領導者，應根據實際測試的環境，制定合適的測試用例粒度。如，專案週期長且測試資源充足，則儘量將用例粒度細化，以求達到對測試過程活動的充分控制（理想狀態，標準跨國型企業使用較多）；專案週期短且測試資源匱乏，則將用例設計中心放在測試檢查點引導，以少量測試用例結合自由測試的方式，達到對重要的專案風險點的控制，而降低甚至放棄低優先順序測試點的風險控制。

　　所以，不同公司，不同測試團隊，不同測試專案，其用例粒度可能不同，但是，若相同公司，相同測試團隊，相同測試專案，用例粒度不同，則可能就需要檢討測試團隊的用例設計規則是否合理，各個tester是否清晰瞭解公司用例設計理念。（一句話，該培訓的就培訓，該檢討的就檢討改正。如果用例評審後還出現此類問題，多半這個團隊的測試主管就該“背背書”了）

17、在編寫用例時，組內是否會規定用例編寫的順序，比如先寫控制元件，再寫功能，再寫介面的。

　　專家分析：用例設計規範需要先行於實際用例設計。測試的領域中，沒有絕對的正確和錯誤，只有適合與不適合。

18、如何評定用例的優先順序？

　　專家分析：用例的優先順序規範都大同小異，把握2個出發點即可：產品的核心和客戶的需求。

　　由於專案產品不同，優先順序有一些差異，以下列舉一個用例優先順序排序，供參考：

　　A、第1優先順序為主功能實現用例和客戶特殊要求的功能實現用例

　　B、第2優先順序為子功能實現用例和1~2級互動用例

　　C、第3優先順序為3~N級互動用例和NFT用例組

19、常用的黑盒方法都瞭解，但是在專案緊的情況下，最常用的也就是等價類和邊界值了.畢竟用例設計也是需要時間的，在編寫用例方面有哪些技巧和方法呢？

　　專家分析：不同的企業採用不同的方式來節約用例設計和用例執行的資源，以下幾項可酌情參考：

　　A、建議基礎用例庫與測試資源庫，用例與測試需要的環境均從庫中呼叫後更新，降低用例設計週期和測試環境搭建週期，並在一定程度上保證不同水平的tester能設計出質量差不多的用例組

　　B、根據用例的實際使用環境，運用多種用例格式設計用例。如，UI用例組使用流程圖代替；互動用例組使用判定表代替

　　C、用例設計前期可只依靠需求文件和基礎設計方法（等價+邊界）完成，其他標準用例設計方法則作為評審標準或手段引入，以保證基礎用例組的快速開發。

20、對於用例寫作質量如何進行評價、如何進行度量？在做測試執行策略時，對於繼承用例的處理是否有好的經驗可以借鑑？

　　專家分析：編寫用例之前，定義好用例的編寫規範。根據用例的要素，裁剪出我們需要的。求同存異，上下一致達到共識。有利於預審、評審時每個參加的人能夠很快熟悉用例編寫者的格式。

　　測試用例內部評審：

　　當一個QA完成了手頭的測試用例之後，可以讓相關的開發人員、攥寫需求文件的人員和相對senior或者有專業知識背景的測試人員一起對測試用例做一個review，在review過程當中一般會發現測試用例的不足和需要改進的地方。這些用例的不足之處以及需要改進的地方可以從一個側面反映出用例的質量。具體的衡量標準由管理人員制定（有些時候測試用例的不足是由於需求文件本身的問題造成的，這就不應該算作是測試用例質量的問題）。

　　外部評審：

　　如果公司開發的軟體比較大的話，一般會有partner或者諮詢公司為軟體做代理或者實施。這些partner和諮詢公司在實施公司新版本軟體之前自己一般會做一些測試（他們自己會有自己的測試用例）。公司可以考慮收集這些合作商的測試用例，然後和QA所寫用例比較，以作為對測試用例的評價或考核。當然公司也可以反過來做，即把公司的測試用例拿出去讓合作伙伴評審（這樣做的我看到的不多）。

　　按客戶反饋評審：

　　當軟體釋出後，客戶使用一段時間一定會發現有問題，或者在設計方面不符合他們的要求。我們可以將客戶報告的BUG收集起來加以分析（嚴重性，BUG型別，複雜程度），並和通過測試用例發現的BUG作個比較，從而評定測試用例的質量。

21、怎樣做好網站測試？

　　專家分析：很多人認為網站建設在程式上傳那一刻就結束了，其實這個是一個很錯誤的想法。其實，網站建設在程式上傳後，還有一個很重要的環節就是測試網站。不要小看測試環節，這個測試細節要是沒到位，網站會存在很多問題，比如圖片變形，網站連結錯誤啊，還有資料錯誤等等。我就從我個人的角度來談談網站測試要注意的事項。

　　第一， 要做的事情就是看設計要求，雖然，設計師是看設計要求做，但是難免會存在失誤，或者理解上的失誤。按著設計的要求去測試功能。

　　第二， 就是看傳上去的圖片是否變形，如果變形先看圖片本身的規格是否是網站要求上傳的規格。

　　第三， 要先熟悉後臺，測試每個後臺上的內容是否能在前臺找到。或者是否出現錯誤頁面。

　　第四， 我們作為專業的網站設計公司，要想客戶沒想到的東西，這麼做能讓網站更美觀，更符合網站的整體效果，特別對於網站的色調這塊。

　　第五， 檢視是否有404頁面，這個雖然不是屬於設計範圍。但是，多個404頁面會讓使用網站的人感覺不夠友好。

22、剛剛進入測試行業，正處於學習中，對於測試用例設計仍然不得要領，想問一個具體的問題，比如：一個程式具有檔案新建，複製，重新命名，刪除功能。我只能想到一兩個測試用例，應該如何設計測試用例呢？

　　專家分析：假設測試目標程式只有“新建、複製、重新命名、刪除”4個功能。可以參考以下測試思路：

　　1）根據功能特點提取公共測試點：文字框

　　（1）文字框的測試思路大都沒有什麼變化，根據支援文字型別，在ASCII表中使用等價法選擇具有代表意義的字元，如：A，a，特殊符號（特殊符號這部分可能還需要根據系統特色做一些篩選，如Windows系統的檔名對“\”，“*”等9個符號有限制）

　　（2）如果想更深入測試，可考慮本地化測試部分，引入不同編碼的字元測試，如Unicode，GB等.

　　（3）最後使用邊界值對字元長度設計一些簡單的容錯用例。

　　2）準備好公共的功能測試點用例，則可以開始各個功能的基礎功能用例設計。（這部分其實就是你提到的“每一種只能想到一個或者兩個測試用例”）。而在需要用到公共用例的部分，將公共用例連結進去。如新建、重新命名等涉及文字框的功能都需要匯入文字框用例組。（可能不同的文字框對字元的限制不一樣，如字元長度或字元型別，所以實際匯入的過程中，需要進行簡單的篩選）

　　3）根據設計好的基礎功能用例，選擇出可被中斷的用例組，設計互動用例組。

　　可被中斷的用例通常滿足：

　　（1）用例單個步驟的操作需要系統響應0.5~1s.

　　（2）用例單個步驟的操作可持續執行。（關於持續執行的概念，有兩種理解。一是執行緒被掛起，如新建功能可在申請彈出新建編輯框後，長時間不釋放資源退出。二是1個操作執行後，系統會批量處理一堆執行緒，如批量刪除功能。兩種概念都可以作為持續執行操作的選擇依據，只是看用例的粒度需要達到什麼成程度而已）然後可以開始選擇中斷手法，常見的中斷方式通常為高優先順序的程序/執行緒或致命缺陷的到來。高優先順序的程序/執行緒需要對整個系統功能進行分析，如系統提示框到來（記憶體資源申請失敗），電量不足提示（如果是有限電源的話）。而致命缺陷通常只能從使用者使用環境得到（可運用場景法和錯誤推斷法得到），如系統崩潰，系統斷電。

---------------------------------------

23、剛剛接觸測試，還在培訓中，想向前輩們討點迷津，怎樣學好軟體測試？現在感覺很糊塗。

　　專家分析：首先了解什麼是軟體測試？

　　軟體測試就是利用測試工具按照測試方案和流程對產品進行功能和效能測試，甚至根據需要編寫不同的測試工具，設計和維護測試系統，對測試方案可能出現的問題進行分析和評估。執行測試用例後，需要跟蹤故障，以確保開發的產品適合需求。是幫助識別開發完成（中間或最終的版本）的計算機軟體（整體或部分）的正確度（correctness） 、完全度（completeness）和質量（quality）的軟體過程；是SQA（software quality assurance）的重要子域。軟體測試的發展，是伴隨著軟體開發技術的進步，以及軟體質量管理觀念的形成。軟體測試是從軟體質量保證過渡而來，軟體測試的職位從傳統的白盒測試逐漸演變到黑盒測試，從單一的測試崗位發展到眾多的測試崗位，如：WEB測試、資料庫測試、安全測試、手機測試。

　　學好軟體測試

　　首先，是重點概念，現在有很多同學說概念或理論自己看書就能解決，主要是沒有實際工作經驗，其實老師在講解概念或理論的同時，也在不斷灌輸軟體測試的實質，沒有理論上的掌握，你就無法理解一個軟體產品怎麼測試，為什麼這麼測試，怎麼去考慮測試的方法或策略，軟體測試術語是怎麼引申來的，其實都在啟發你的邏輯思維能力；也在不斷的講授和上機練習中體驗軟體測試的流程，軟體測試的過程，由無形到有形，從無序的知識點到有序的系統的知識體系。

　　其次，要有統籌兼顧，全盤考慮的思想，做測試工作不是一個孤立、片面的工作，很多同學都曾說過以前的學哥學姐都傳授過經驗，測試就那麼回事，等到了工作單位，每天就那點活，老是機械式的重複，這些都是我們沒有看到或沒有意識到的，目前的軟體開發與軟體測試已不再是小作坊式的規模了，它需要大量的人力來協同工作，每個人的工作都是必不可少的一部分，所以需要在全域性上把握，從巨集觀上考慮，這就是軟體測試策略的由來，但是具體測試工作還是微觀上的，還需要掌握軟體測試的各種方法，另外還要站在專案管理的層面上，從時間上、成本上、效率上、人員分工上、測試團隊的能力上、風險上等諸多方面來統籌考慮，要做到從事軟體測試工作要從巨集觀到微觀、從全面到區域性去認識，不能再盲人摸象或者摸石頭過河，要從認識論昇華到方法論上；

　　最後，要多上機實踐，這個是非常關鍵的一點，多思考，會思考，找出疑難與不解，要從軟體測試實踐中總結出測試理論，再用測試理論去指導實踐，這是個迴圈往復的過程，只有當你的認識達到一定的高度，你就深刻理解了什麼是軟體測試，你才會發現原來軟體測試是那麼的有意思、那麼有動力、那麼具有挑戰性，以後還有很多未知的迷團需要你去撥開，還有更多的知識需要你去掌握。軟體測試技術到目前為止，還是一門新興學科，還沒有形成固定的理論體系，還需要很多人的努力，最終將這門藝術變成一種科學。

24、一份需求文件，裡邊有很多功能點，就會有更多測試點。那麼一般用用例設計方法來設計某一模組，具體操作起來是怎樣的流程？那些用例設計方法的物件是功能點還是測試點？

　　專家分析：用例的根本目的是給測試人員使用，故在設計用例時，若脫離用例本身的使用環境而空空其談，也就違背了用例設計的根基，直接導致被設計出的僅僅是無效用例而已。

　　所以，經常被談到用例粒度、覆蓋率等，雖然提及的次數多，但一直沒有明確的標準規範。其很大程度就是因為用例本身的使用環境差異較大，若不進行實際情況分析，就無法得到恰當粒度的用例。

　　比如，針對某一模組，如手機電話本進行用例設計，大致流程如下：

　　（1）根據電話本需求文件列舉所有的功能點。若不能很好掌握功能點劃分的粒度，可考慮使用UI結構圖代替

　　（2）分類各個功能點，主要依據為在實際測試中，各個功能點是否可能被其他用例補充。如，後臺執行的功能點需單獨分割作為被中斷用例的前置環境；被動訊息功能點則會被作為中斷用例的操作步驟；與其他模組存在介面的功能點則會作為其他模組的補充用例….等等

　　（3）根據單個功能點的複雜程度，考慮是否存在需要提取公共用例。如將各個功能點的編輯框提取出來設計單獨的編輯框用例。

　　（4）使用常規的用例設計方法，通常為等價和邊界設計基礎用例。若功能點過於複雜，可考慮繼續繼續分割功能點或使用高階用例設計方法。

　　（5）完成以上4步後，使用容錯和場景法對設計用例的覆蓋率進行驗證。

　　（6）最後，根據此功能模組在系統流程圖中的位置，設計該模組被其他模組呼叫的補充用例。（若每個模組都能保證完成以上5個步驟，第6步其實可以省略）

　　（7）根據設計要求，考慮NFT用例的分佈，通常會根據每個功能點單獨提取，也可以通過用例優先順序控制。（NFT用例分佈策略通常取決於公司測試策略，主要適用即可，不需要太糾結於形式）

25、根據用例設計方法來設計一個模組的測試用例，如果該模組最後有300條用例，那麼一般設計這些用例需要多長時間？

　　專家分析：排除設計人員本身技術高低或用例管理工具難易程度等其他因素，就用例本真而言，用例設計時間通常被兩個因素影響：

　　（1）功能複雜程度

　　（2）用例粒度（也可以簡單理解為用例個數）

　　所以，建議比較合理的是自己先試驗一次，然後再通過考慮其他因素影響，評估出貼近實際的時間。

26、在專案緊急，沒有需求文件，沒有用例評審，又只能獨自完成測試的情況下，如何保證測試用例不會漏測呢？

　　專家分析：嚴格來說，這個問題只看”測試用例不會遺漏”已經是偽命題。 至今沒有哪個公司敢宣稱：咱們的測試用例覆蓋率100%。

　　所以，這個問題還是回到了實際環境分析出發，建議先分析以下幾點得到大致的測試標準：

　　（1）客戶對產品的質量要求程度。簡單可以理解為： 客戶使用什麼樣的方式來驗收產品。常見的方式為：3個月試用、1個月客戶測試團隊複檢、1天客戶體驗…不同的驗收的方式在很大程度上決定了產品的預期質量目標。

　　（2）產品的功能覆蓋和2級互動測試，一般被作為滿足產品輸出的最低質量保證。單黑盒方面來說，這部分可考慮自己設計功能結構圖，然後通過1次功能點分類得到。

　　（3）再補充一個常用的用例設計資訊：用例設計的時間通常不會超過測試周期總時長的1/3，用例遺漏的部分，最快速的方式是使用探索測試完成。（當然，測試人員或開發人員的實際使用測試也能為補充測試洩露提供一定程度的幫助）

27、對於一個複雜的java管理系統，功能中主要以增刪改查、新增-審批-釋出，類似這些重複的功能特性，請問在設計測試用例時，如何保證設計的全面性？

　　專家分析：（1）先按照流程圖或場景法先清理測試點的思路框架。

　　（2）提取多次被重用的子功能測試點單獨設計公共用例組。公共用例組保證為子功能的最大合集，並注意分類方式，方便被提取時，可快速刪選。需要注意公共用例組的粒度，可能它不僅僅只是一個小功能，比如編輯框；在某些情況下，也可以考慮將一小段流程整個作為公共用例組，如審批過程。

　　（3）由於ERP系統完整流程執行一次的時間較長，且可被中斷的測試點較多，通常會將互動用例組單獨分割出來，然後逐個重新載入到需要模組基礎功能測試用例組中。

　　（4）NFT的部分，可參考互動用例組的處理方式。

　　（5）最後，留下設計用例整個週期約1/4左右的時間評審和完善用例組。

　　（6）至於黑盒外的測試用例組，除使用標準的白盒用例設計方法外，在測試資料選擇方面，建議考慮以量的方式來補足。畢竟白盒測試的執行速度遠遠高於黑盒用例。

28、對於一些特殊的專案，比如說時間短，開發文件不齊全，我們是不是非要執著於去編寫測試用例？如果寫，時間從何而來；如果不寫，如何保證測試的全面和保證測試人員測試的情況？

　　專家分析：除了經常涉及的簡化測試用例的方法外，針對極限條件（無需求，無測試用例），提供一些相關資訊，供參考：

　　必要條件：

　　（1）測試領導者對測試原理有較深刻認識（至少需要達到裁剪測試流程水平）

　　（2）測試團隊具備較高的可控性（至少能理解測試領導者每個測試任務的實際內容，並且能”踏實”的完成執行測試）

　　（3）測試團隊僅限於單個site。（跨Site測試團隊合作專案，可考慮每個獨立測試團隊分派不同的任務）

　　測試策略：

　　極限測試條件下，首先需要高度保證測試過程的執行策略的易操作性。

　　雖然複雜的測試策略的風險更小，但是它需要消耗更多的時間去理清資訊和調整。在極限條件下不可能有那麼多的時間和資源完成，所以，把握測試的核心，以己之力，牽動整個團隊的步伐，達到最終的目標。（這裡並不是說決策者不會失誤，只是單個決策者比多個決策者的效率更高而已。）

測試執行：

　　（1）測試任務每日分派，任務來源與測試計劃的細化。（至少需要細化到每個人。當然，如果小組長技能水平較高，可考慮細化到小組）

　　（2）每日週期跟蹤各個單位任務執行狀態（比較合理的週期可考慮，取決於跟蹤單位任務執行消耗的時間為決策者1/2的工作總時間）

　　（3）每日對當天的bug進行分析，將分析結果轉化為測試點分配到各個負責單位。每週進行一次bug分析彙總，修訂周測試計劃的重點。

　　（4）每週進行一次測試狀態檢查，可選擇的方式有交叉測試或核心測試人員抽檢。

　　（5）測試決策者每日與RD就bug修改方案溝通的時間不少於總時間的1/4。

　　（6）至於其他特殊環境或情況，只能說：見招拆招。

　　（7）第一階段為複製。適用於測試新手，基本所有的測試人員設計用例都是從這個出發點開始的。

　　（8）第二階段為重置。通常在測試人員入行半年以後開始，通過對之前人員設計用例的模仿，加上自己對測試功能的理解，運用簡單的測試方法，重新設計屬於自己風格的測試用例。

　　（9）第三階段為擴充套件。努力的測試人員在1年後開始進入此階段，其表現基本與你現在的狀態基本一致。此階段的根本目的是瞭解和學習更多測試用例設計相關資訊和資料，最終掌握它們，週期因為個人的努力程度和機遇，各有不同。列舉一些此方面的需要了解和掌握的資訊：系統原理、硬體特性、驅動原理、軟體設計、市場資訊、編碼技術、自動化測試技術、自動化工具原理、缺陷管理工具原理….

　　其實可以用簡單一句話概括：所有與測試相關的技術，均需要了解。

　　（10）第四階段為大同。當在第三階段收集的資訊數量達到滿足自身測試的需求後，可開始通過各種資訊直接提煉出新的測試點，對第二階段測試用例的遺漏點進行補足，進一步提升測試用例的覆蓋率。

29、N個輸入條件時怎樣用正交法設計測試用例？

　　專家分析：通常，正交表解決問題分為兩類：

　　1）測試元素滿足標準正交表條件，可直接套用。

　　2）當測試元素不滿足標準正交表條件時，可先考慮測試元素是否是某個標準正交表的子集。

　　如，某個功能有4個測試元素（因子），每個測試元素的水平分佈如下：A4，B3，C2，D2 。

　　我們可以直接選擇L16（5^4）正交表，將僅有的4個測試元素和水平放入表內，得到16組測試用例。

　　也可以選擇先將某些測試元素的水平先組合再分離的方式來設計。如上述例子使用將A元素的4個水平中的兩個組合在一起看做1個水平。然後套用L9（4^3），得到9組用例後，再將A元素組合的兩個水平拆開（包含組合水平的用例有2個），得到4個新的用例，最終得到12個用例組成的新用例組。

30、如果某個專案很大時間很長，寫出來的用例都是上千上萬的，請問，測試用例用什麼樣的模板比較好，word還是excel？

　　專家分析：條件允許的情況下，建議使用專門的用例管理工具。沒有條件的情況下，強烈建議使用Excel而非Word。原因很簡單，單是資料統計一項，Word已經捉襟見肘。而且一個excel檔案可以包含多個表。

31、測試前期，需求和設計發生變化，需要去修改原先的測試用例，這個無可厚非，但問題是如果已經開始測試了，發現自己寫的測試用例部分不符合需求與設計、發現可以新增一些測試思路、用例。請問：在這種情況下，我們還要去修改、新增用例？時間從何而來？用必要補充已經測試的用例嗎？等專案測試完了，有補充的必要嗎？如果專案一個接著一個，時間問題要如何解決？

　　專家分析：若用例與需求完全不符，需立即修改。若用例存在遺漏，可先只增加基礎功能用例，其他型別用例組有時間再增加。（增加用例的原則，可考慮根據用例的實際用途，如，首先保證關鍵里程碑用例組的完整性）