觀點1：這個場景額組合設計情況太復雜了，沒有必要這么做吧!
答：場景是非常復雜，至少本人下午花了一個多小時才剛剛理清楚開始的頭緒，但不能因為復雜，任務量重就不做了，畢竟這是核心業務功能。按道理來講，其他枝節末梢的功能點在時間進度或資源受限的情況下可以選擇放棄，但是這個還真得做。
說明：被測試的軟件這次是第二次新版本的發布，在早些時候第一次版本發布之前的測試中沒有涉及場景的邏輯覆蓋，全憑隨機測試和探索性測試，幸運的是，軟件合同方進行過驗收測試后沒有發現較大的缺陷。
觀點2：你不可能將情況組合設計的面面俱到的，就像你不可能發現軟件中所有的缺陷一樣
答：或許在組合設計的過程中有遺漏存在，那么勢必就需要進行組內甚至聯合開發進行評審，以確定覆蓋率和有效性。其實個人認為上述兩者之間沒有實質上的可比性。前者注重邏輯覆蓋，這是寫代碼時候必須要思考清楚的;后者是一個概率學上的問題，有時候存在一定的缺陷是被允許甚至被推崇的，特別是一些細節缺陷在發布之前肯定是不會修改的，但是你跟開發說在業務流程上發現了個缺陷，開發估計會先想到出現的概率，如果用戶經過此路徑的概率在一定比例之上，那么勢必會考慮版本的延遲發布或其它方案!
觀點3：對于場景組合設計我不需要設計成表格吧，我只要按照我的思路順著寫測試用例就行了
答：個人推崇表格設計的方法，其實靈感來自于我現在的Leader，一位有7年測試經驗的老測試。之前我在一個項目上也采用了當前這位組員的方式，順著自己的思路寫場景用例，后來發現其缺點還是比較多的：第一，其條理沒有表格設計方法來得清晰，別人和自己都會看得比較暈;第二，相關用例之間的條件和結果對比沒有表格測試法來得清楚，且表格測試法可以通過用例之間各信息的對比，能快速發現遺漏的，沒有覆蓋到的用例。
觀點4：開發其實自己都不是很清楚其中的邏輯流程，讓我們測試先理清楚其中的流程覆蓋，然后他們去看代碼以修復我們其中可能發現到的問題，這好像不是測試要做的事情吧
說明：現有的核心代碼并不是當前的開發團隊所完成，開發他們核心代碼也是在不久前剛剛拿到。
答：開發的意見或許有些讓人覺得不爽，OK，那換種說法，總不能要求開發去把代碼看完，然后給你畫個流程圖，告訴你流程圖上有哪些路徑需要覆蓋，如果真的是那樣，要測試做什么?并且那樣也容易被開發繞進他們的思維流程中去，做測試最忌諱就這個，我們要發現問題，勢必要自己挖掘現有測試軟件中可能涉及到所有路徑，然后一一去驗證。其實測試本身和開發是一樣的，如果你把主要場景流程捋順了，那么你相當于走了一遍開發走過的設計道路，如果你再會一門語言，那么差不多你能也模仿著做出相同功能的軟件。
觀點5：碰到場景中涉及到的有些似問題，又好像不是問題的問題，開發自己都說不管了，我們也就別管了
答：開發可以不用管，但QA不能不管，因為軟件最終的質量保證靠的是我們，從某種程度上說，我們測試受制和聽命于開發，但為了分清楚責任，我們有必要羅列清楚所有情況的組合，并且在出現問題的組合情況后面列出問題結果，然后將最終結果發給開發，由他們決定是否進行修改，我相信，這是有震懾力的，因為他們必須以白字黑字的形式進行表態。這是0或1的結果。如果開發說這個問題可以skip，那行，最終如果真出問題了，那不是我們測試的問題，因為我們已經做了我們能做的所有事情!
觀點6：那你進行組合設計吧，完了我follow你的case執行，如果中間有遺漏，你負責
答：我不想過多的說明責任歸誰的問題，其實作為項目Leader，我很清楚自身的責任，即使設計由組員完成，且發生了遺漏，那么顯然責任也是我的，且我的責任最大，原因是我沒有引導和開展好必要及正確的測試工作方法。我想這是作為一個領導者應該具備的素質。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
