在寫測試部落格之初寫過一篇名為「
關於測試用例的詳細程度
」的文章，現在看來有些雜亂，也缺乏一定的嚴謹性和條理性，那篇文章更多側重的是有感而發。
今天和所帶專案的一位組員**測試用例的時候，關於測試用例的詳細程度發生了明顯的分歧。靜下心來，還是想好好整理一下思路。
對於軟體測試用例（只涵蓋功能測試，不包括效能測試）大類，個人目前的認知基本由以下幾部分組成： n
業務場景測試：驗證軟體核心業務流程，包含主要功能點的邏輯路徑覆蓋。 n
功能點測試：包括測試方法和測試資料的組織兩個部分。
關於業務場景測試，個人認為要畫出詳細的業務流程圖及路徑覆蓋組合，因為這部分是軟體的核心功能，在任何種類的回歸測試中都要著重進行測試。至少在每次基線版本發布前進行全回歸測試。如果條件允許，將之逐步實現成自動化測試將會帶來非常大的效率改善。這裡並不是說不強調其中穿插的測試資料和測試方法，只是對於其本身，更多想說明的是業務流程的高覆蓋率的重要性。
關於功能點測試中測試方法和測試資料的設計，網上有很多非常好的文章可以參考，這裡不再進行另行**。
對於專案組員的些許觀點，這裡想著重引出，在每個觀點後給出自己的意見和說明，這也是寫下本文的主要目的：
觀點1
：這個場景額組合設計情況太複雜了，沒有必要這麼做吧！
答：場景是非常複雜，至少本人下午花了乙個多小時才剛剛理清楚開始的頭緒，但不能因為複雜，任務量重就不做了，畢竟這是核心業務功能。按道理來講，其他枝節末梢的功能點在時間進度或資源受限的情況下可以選擇放棄，但是這個還真得做。
說明：被測試的軟體這次是第二次新版本的發布，在早些時候第一次版本發布之前的測試中沒有涉及場景的邏輯覆蓋，全憑隨機測試和探索性測試，幸運的是，軟體合同方進行過驗收測試後沒有發現較大的缺陷。
觀點2
：你不可能將情況組合設計的面面俱到的，就像你不可能發現軟體中所有的缺陷一樣
答：或許在組合設計的過程中有遺漏存在，那麼勢必就需要進行組內甚至聯合開發進行評審，以確定覆蓋率和有效性。其實個人認為上述兩者之間沒有實質上的可比性。前者注重邏輯覆蓋，這是寫**時候必須要思考清楚的；後者是乙個概率學上的問題，有時候存在一定的缺陷是被允許甚至被推崇的，特別是一些細節缺陷在發布之前肯定是不會修改的，但是你跟開發說在業務流程上發現了個缺陷，開發估計會先想到出現的概率，如果使用者經過此路徑的概率在一定比例之上，那麼勢必會考慮版本的延遲發布或其它方案！
觀點3
：對於場景組合設計我不需要設計成**吧，我只要按照我的思路順著寫測試用例就行了
答：個人推崇**設計的方法，其實靈感來自於我現在的
leader
，一位有
7年測試經驗的老測試。之前我在乙個專案上也採用了當前這位組員的方式，順著自己的思路寫場景用例，後來發現其缺點還是比較多的：第一，其條理沒有**設計方法來得清晰，別人和自己都會看得比較暈；第二，相關用例之間的條件和結果對比沒有**測試法來得清楚，且**測試法可以通過用例之間各資訊的對比，能快速發現遺漏的，沒有覆蓋到的用例。
觀點4
：開發其實自己都不是很清楚其中的邏輯流程，讓我們測試先理清楚其中的流程覆蓋，然後他們去看**以修復我們其中可能發現到的問題，這好像不是測試要做的事情吧
說明：現有的核心**並不是當前的開發團隊所完成，開發他們核心**也是在不久前剛剛拿到。
答：開發的意見或許有些讓人覺得不爽，
ok，那換種說法，總不能要求開發去把**看完，然後給你畫個流程圖，告訴你流程圖上有哪些路徑需要覆蓋，如果真的是那樣，要測試做什麼？並且那樣也容易被開發繞進他們的思維流程中去，做測試最忌諱就這個，我們要發現問題，勢必要自己挖掘現有測試軟體中可能涉及到所有路徑，然後一一去驗證。其實測試本身和開發是一樣的，如果你把主要場景流程捋順了，那麼你相當於走了一遍開發走過的設計道路，如果你再會一門語言，那麼差不多你能也模仿著做出相同功能的軟體。
觀點5
：碰到場景中涉及到的有些似問題，又好像不是問題的問題，開發自己都說不管了，我們也就別管了
答：開發可以不用管，但
qa不能不管，因為軟體最終的質量保證靠的是我們，從某種程度上說，我們測試受制和聽命於開發，但為了分清楚責任，我們有必要羅列清楚所有情況的組合，並且在出現問題的組合情況後面列出問題結果，然後將最終結果發給開發，由他們決定是否進行修改，我相信，這是有震懾力的，因為他們必須以白字黑字的形式進行表態。這是0或
1的結果。如果開發說這個問題可以
skip
，那行，最終如果真出問題了，那不是我們測試的問題，因為我們已經做了我們能做的所有事情！
觀點6
：那你進行組合設計吧，完了我follow
你的case
執行，如果中間有遺漏，你負責
答：我不想過多的說明責任歸誰的問題，其實作為專案
leader
，我很清楚自身的責任，即使設計由組員完成，且發生了遺漏，那麼顯然責任也是我的，且我的責任最大，原因是我沒有引導和開展好必要及正確的測試工作方法。我想這是作為乙個領導者應該具備的素質。
1個app的完整測試用例 詳細的測試用例介紹
1.什麼是測試用例？測試用列 test case 是為了實施測試而向被測試的系統提供的一組集合，這組集合包含 測試環境 操作步驟 測試資料 預期結果等要素。2.測試用例的要素 測試用例的標題 測試思路 預設條件 步驟 預期輸出 乙個好的測試用例是乙個不熟悉業務的人也能依據用例來很快的進行測試。評價測...
測試用例（四）測試用例編寫
一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來，但它不是從乙個等價類中任選乙個例子作為代表，而是...
手機測試用例 STK測試用例
id 功能描述 操作步驟 預期結果 test time p fcomment tester test time p fcomment tester stk服務 sim卡適應性測試 1 選取支援stk功能的sim卡，插入手機中 手機應支援stk功能，會將stk選單自動加入主選單列表中 2 進入stk功...