如果還能cover，是業(yè)務(wù)場景太簡單，導(dǎo)致了測試用例數(shù)量有限；還是沒有維護測試用例，導(dǎo)致測試用例數(shù)量有限？
前者是由業(yè)務(wù)屬性決定的，而后者導(dǎo)致的產(chǎn)品質(zhì)量問題，就屬于人禍了。
今天這篇文章，我們主要來講解：如何做線上測試用例管理的思路。會包含一些工具的介紹。
首先，我們來明確一下測試管理的范圍。測試管理包含了哪些部分？
測試用例的創(chuàng)建
是所有測試活動的基礎(chǔ)。如果沒有測試用例，很難保證測試的一致性。如果完全沒有測試用例，可以認定為這是感知測試?；诿恳粋€人感知程度的不同，得出的結(jié)論也不一樣。所以，針對一個嚴(yán)謹(jǐn)?shù)墓こ添椖浚欢ㄐ枰鰷y試用例的管理。測試用例應(yīng)該怎么創(chuàng)建？有一些團隊是在線下，用 excel 、word來創(chuàng)建測試用例。有很多團隊是用思維導(dǎo)圖的方式創(chuàng)建測試用例。思維導(dǎo)圖是一個非常好的工具，它最大的優(yōu)點就是思維的連貫性。也就是，測試工程師可以從一個待測點出發(fā)，不斷地去延伸。這種思考方式，和產(chǎn)品經(jīng)理思考產(chǎn)品的思路，以及開發(fā)工程師解決問題的思路是近似的。對于產(chǎn)品工程師來說，他最初得到的也是一個idea，從這個 idea 出發(fā)，衍生出產(chǎn)品的各種使用場景。
對一個開發(fā)工程師來說，他最初需考慮的是實現(xiàn)某一個功能，針對這個功能，可能要寫幾個函數(shù)，每一個函數(shù)有幾個分支，所以這天生也是一個樹狀的思考模式。所以，思維導(dǎo)圖這種工具，非常適合用來寫測試用例。很多團隊會用思維導(dǎo)圖來“草擬”測試用例，但是“草擬”完之后，仍然是把思維導(dǎo)圖導(dǎo)出成一條條的用例，放在excel或者其他工具中。這種方式，舍棄了思維導(dǎo)圖最大的優(yōu)勢：思維的連貫性。為什么這些團隊需要把思維導(dǎo)圖重新轉(zhuǎn)成條目化？因為思維導(dǎo)圖可以作為測試用例編寫工具，但卻無法執(zhí)行。
基于這個場景，我們開發(fā)了一款全新的研發(fā)管理工具 MappingSpace。在這款工具里面，思維導(dǎo)圖不僅就是測試用例，攜帶了測試用例所需的全部信息，如：前置條件、測試步驟、預(yù)期結(jié)果，以及可定制的各種字段。
測試用例的評審
比如，由于測試用例的錯誤，導(dǎo)致了測試人員認為測出來一個bug，但實際上是由于他對于需求理解不準(zhǔn)確導(dǎo)致的，不僅浪費了測試人員的時間，也浪費了開發(fā)人員分析問題的時間。
比如，測試用例本身的不全，可能導(dǎo)致某些場景或者某些分支沒有被測到。一旦這樣的問題流入市場或者客戶之后，再進行返工的成本是巨大的，對于企業(yè)聲譽的影響也是巨大的。
比如，在我們團隊進行測試用例評審時，經(jīng)常會發(fā)現(xiàn)某些極限場景，開發(fā)工程師或者產(chǎn)品工程師未考慮到，從而讓開發(fā)或產(chǎn)品及時補全（這也是TDD測試驅(qū)動開發(fā)這種方式的優(yōu)勢所在）。
假如我們能夠在測試用例執(zhí)行之前，就能有效地進行測試用例的評審，會大幅節(jié)約整個團隊的時間，提升軟件的質(zhì)量，同時節(jié)約成本。
測試用例要怎么進行評審？一種方式，同樣是類似于 excel，條目化地進行評審。很多線上的測試工具，其實只是簡單地把線下的 excel 搬到了線上，評審過程還是一條一條地進行評審。這種評審方式不太好，同樣放棄了思維的連貫性。測試用例是用思維導(dǎo)圖來寫，而思維導(dǎo)圖的思路是連貫的，因此，基于思維導(dǎo)圖的評審，更容易發(fā)現(xiàn)每一個分支的缺陷或遺漏。所以，我們?nèi)匀唤ㄗh，測試用例的評審也可以直接在思維導(dǎo)圖上進行。
測試計劃的執(zhí)行
創(chuàng)建Bug
V模型
需要明確向用戶表明，測試用例屬于哪個類型，測試用例是針對需求、還是架構(gòu)進行測試的。在MappingSpace里，天然支持這樣一個V模型的視角。
轉(zhuǎn)自汽車電子與軟件
