改造功能測試用例時的一點思考

業務線會增加一個新的分類，跟原來的分類相差不大，不過由于從供應商、服務器架構、接口等都有較大的改動，因此還是需要對新增加的這個分類進行全量測試。

　　同時，由于整體流程和功能與原來的與原來的分類大致相同，在綜合考慮后，決定沿用之前分類的測試用例，于是，需要對之前的用例進行增、刪、改，根據新的需求和新版本，即時更新之前的用例。

　　在仔細的看過之前的用例之后，發現用例是從一個頁面一個頁面一個功能一個功能寫的，然后再跑了十幾個業務流程。

對于這種設計思路，有以下幾點思考：
　　（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

自動化測試相關資料

鏈接：https://pan.baidu.com/s/1yeD1EMg-HalNuRBDODGx7g 密碼：ofdg