業務線會增加一個新的分類，跟原來的分類相差不大，不過由於從供應商、服務器架構、接口等都有較大的改動，因此還是需要對新增加的這個分類進行全量測試。
同時，由於整體流程和功能與原來的與原來的分類大致相同，在綜合考慮後，決定沿用之前分類的測試用例，於是，需要對之前的用例進行增、刪、改，根據新的需求和新版本，即時更新之前的用例。
在仔細的看過之前的用例之後，發現用例是從一個頁面一個頁面一個功能一個功能寫的，然後再跑了十幾個業務流程。
對於這種設計思路，有以下幾點思考：
（1）、這種設計思路整體上來說是先功能、後流程，以功能爲主，流程次之，功能和業務流程用例有區分，在執行時，能夠讓測試人員專注於某一個頁面或某一個功能進行測試，不至於因爲測試過程中頻繁的去關注功能和流程直減的切換而分心。
（2）、單獨功能和頁面有充分測試。對於每一個頁面、每一個功能都有測試用例，對於功能和頁面的測試比較充分，這方面遺漏比較少，充分保證了功能測試的全面。
（3）、對編寫人員和新人深入瞭解所有頁面和功能有較大的促進作用。根據每一個頁面的每一個功能來編寫的用例，所以對於所有可能存在的頁面和功能都有着比較可靠而完整測試，無論是對於編寫用例的老員工還是新人，在促進深入瞭解功能方面，都有很大的幫助。
（4）、對編寫人員對於業務流程的理解要求非常高，學習成本相對較高，而對於編寫的整個過程，是相對比較簡單流暢的。用例編寫的時候，需要編寫的人對整體業務流程、每種可能出現的頁面都要有非常深入的瞭解，這一般需要一段相對較長的時間，學習成本相對比較高，對於新人快速瞭解整體業務流程和用例的設計思路有較大的阻力。不過，只要對頁面和功能有足夠的瞭解，在編寫用例的時候，則是相對比較簡單流暢的。
（5）、頻繁切換測試入口，增加執行成本和步驟，導致執行時間無法準確有效評估。每一個頁面或功能相關的用例都是相互關聯的，而與其他流程之間的用例，則相對過於獨立，所以經常就會出現前面一個用例測完離提交訂單隻有一步之遙了，而到下一個用例的時候，就莫名其妙的跳到了另一個分類的提交訂單頁面，而步驟卻少的可憐，只有預置條件中說了一句處於某個分類的填寫訂單頁面，而且用例之間還相互關聯，甚至依賴。這樣頻繁的切換入口，無形中增加了測試用例的執行難度和執行步驟，對於根據用例數量來評估執行時間進而評估整體測試時間是不利的。
（6）、流程測試相對不夠充分。在算上爲了進行功能測試而同時執行過的業務流程，再加上專門執行的業務流程用例，一共執行了20來個業務流程用例，而在根據整體業務流程各個條件進行組合後發現，若將所有條件都考慮進來，則有上千個業務流程組合，在儘可能壓縮條件的情況下進行交叉組合，也存在一百來個業務流程，即使去掉重複或不存在的流程，也至少存在大幾十甚至上百的可能組合。很明顯，之前的用例對於業務流程的組合情況考慮的不夠充分，存在業務流程的遺漏。
（7）、在執行流程測試的時候，難免會存在對功能測試的重複執行。
爲了避免流程遺漏，執行時間可控，決定花時間對用例進行整體改造。
最初的想法比較簡單，既然之前的用例是以功能爲主，流程次之，那麼就想當然的認爲改成流程爲主，功能次之。不過存在以下幾個問題：
（1）、業務流程會比較充分的測試了，不過對於頁面和功能，則難免會存在遺漏，尤其是有些出現機會很少的例外頁面以及功能。而且，對於頁面和功能的測試則難免會不夠充分。如何確定兩者之間的關係？
（2）、對於頁面和功能的測試，是單獨擰出來，還是穿插着測試？單獨擰出來，會不會出現重複執行，會不會遺漏？
（3）、怎麼去篩選流程，才能儘可能的保證流程測試比較充分？怎麼確定流程就充分測試了？
（4）、怎麼平衡用例數量和測試的充分性？如果要充分的、全量測試，光流程都有上千了，量太大，執行起來更加要懷疑人生了。對於數量和充分的平衡點，怎麼確定？
好了，你們看完了文章，我也給你們分享一下資料。
接口測試相關資料
鏈接：https://pan.baidu.com/s/1ojpoWnpxxReR1sO2Gxy_YQ 密碼：dgfa
性能測試相關資料
鏈接：https://pan.baidu.com/s/1_oZhvOIRvcz0JGcCWUGT-g 密碼：d82b
軟件測試入門提升電子書
鏈接：https://pan.baidu.com/s/1Fp8CFE0D2p0uAZk6xcexhQ 密碼：exna
自動化測試相關資料