亚洲欧美另类久久久精品,天美传媒妇乱XXXXX视频,思思久久精品超碰

如何進(jìn)行汽車軟件測試管理（一）：手動(dòng)測試篇

發(fā)布日期：2023-01-17

有個(gè)問題應(yīng)該不用過多贅述了：線下測試管理（excel、word...）的效率和質(zhì)量，不如線上測試管理（測試管理系統(tǒng)）。如果還在做線下測試用例管理，團(tuán)隊(duì)leader需要思考一下：不同測試工程師執(zhí)行同一份測試用例，測試結(jié)果的一致性夠嗎？測試用例的評(píng)審好做嗎？如何確保測試用例的場景覆蓋度夠全面？會(huì)不會(huì)漏掉某些場景？測試用例修改之后，其他人知道嗎？測試工程師離職之后，新來的工程師，能快速撿起來嗎？每次測試完成后，還在花很多時(shí)間整理bug嗎？測試結(jié)果記錄在哪兒呢？版本發(fā)布越來越多，現(xiàn)有人力還能不能cover得過來？

如果還能cover，是業(yè)務(wù)場景太簡單，導(dǎo)致了測試用例數(shù)量有限；還是沒有維護(hù)測試用例，導(dǎo)致測試用例數(shù)量有限？

前者是由業(yè)務(wù)屬性決定的，而后者導(dǎo)致的產(chǎn)品質(zhì)量問題，就屬于人禍了。

今天這篇文章，我們主要來講解：如何做線上測試用例管理的思路。會(huì)包含一些工具的介紹。

首先，我們來明確一下測試管理的范圍。測試管理包含了哪些部分？

在我看來，測試管理至少包含了：測試用例的管理，測試用例的評(píng)審、測試計(jì)劃的管理，Bug 的創(chuàng)建及跟蹤，測試用例與需求的關(guān)聯(lián)。

測試用例的創(chuàng)建

是所有測試活動(dòng)的基礎(chǔ)。如果沒有測試用例，很難保證測試的一致性。如果完全沒有測試用例，可以認(rèn)定為這是感知測試。基于每一個(gè)人感知程度的不同，得出的結(jié)論也不一樣。所以，針對(duì)一個(gè)嚴(yán)謹(jǐn)?shù)墓こ添?xiàng)目，一定需要做測試用例的管理。
測試用例應(yīng)該怎么創(chuàng)建？有一些團(tuán)隊(duì)是在線下，用 excel 、word來創(chuàng)建測試用例。有很多團(tuán)隊(duì)是用思維導(dǎo)圖的方式創(chuàng)建測試用例。思維導(dǎo)圖是一個(gè)非常好的工具，它最大的優(yōu)點(diǎn)就是思維的連貫性。也就是，測試工程師可以從一個(gè)待測點(diǎn)出發(fā)，不斷地去延伸。這種思考方式，和產(chǎn)品經(jīng)理思考產(chǎn)品的思路，以及開發(fā)工程師解決問題的思路是近似的。對(duì)于產(chǎn)品工程師來說，他最初得到的也是一個(gè)idea，從這個(gè) idea 出發(fā)，衍生出產(chǎn)品的各種使用場景。

對(duì)一個(gè)開發(fā)工程師來說，他最初需考慮的是實(shí)現(xiàn)某一個(gè)功能，針對(duì)這個(gè)功能，可能要寫幾個(gè)函數(shù)，每一個(gè)函數(shù)有幾個(gè)分支，所以這天生也是一個(gè)樹狀的思考模式。所以，思維導(dǎo)圖這種工具，非常適合用來寫測試用例。很多團(tuán)隊(duì)會(huì)用思維導(dǎo)圖來“草擬”測試用例，但是“草擬”完之后，仍然是把思維導(dǎo)圖導(dǎo)出成一條條的用例，放在excel或者其他工具中。這種方式，舍棄了思維導(dǎo)圖最大的優(yōu)勢(shì)：思維的連貫性。為什么這些團(tuán)隊(duì)需要把思維導(dǎo)圖重新轉(zhuǎn)成條目化？因?yàn)樗季S導(dǎo)圖可以作為測試用例編寫工具，但卻無法執(zhí)行。

基于這個(gè)場景，我們開發(fā)了一款全新的研發(fā)管理工具 MappingSpace。在這款工具里面，思維導(dǎo)圖不僅就是測試用例，攜帶了測試用例所需的全部信息，如：前置條件、測試步驟、預(yù)期結(jié)果，以及可定制的各種字段。

測試用例的評(píng)審

在很多團(tuán)隊(duì)里面，可能不重視這一條，或者說無法落地，流于會(huì)議形式，在評(píng)審過程中很少能發(fā)現(xiàn)錯(cuò)誤。實(shí)際上，對(duì)于測試用例，評(píng)審時(shí)間的投入，是一個(gè)絕佳的低投入、高產(chǎn)出的過程。如果我們?cè)谠u(píng)審測試用例的過程中，就能夠發(fā)現(xiàn)測試場景的不全，或者測試用例的錯(cuò)誤，甚至發(fā)現(xiàn)代碼分支考慮的場景不全，本身就可以避免大量的犯錯(cuò)，節(jié)省大量時(shí)間。

比如，由于測試用例的錯(cuò)誤，導(dǎo)致了測試人員認(rèn)為測出來一個(gè)bug，但實(shí)際上是由于他對(duì)于需求理解不準(zhǔn)確導(dǎo)致的，不僅浪費(fèi)了測試人員的時(shí)間，也浪費(fèi)了開發(fā)人員分析問題的時(shí)間。

比如，測試用例本身的不全，可能導(dǎo)致某些場景或者某些分支沒有被測到。一旦這樣的問題流入市場或者客戶之后，再進(jìn)行返工的成本是巨大的，對(duì)于企業(yè)聲譽(yù)的影響也是巨大的。

比如，在我們團(tuán)隊(duì)進(jìn)行測試用例評(píng)審時(shí)，經(jīng)常會(huì)發(fā)現(xiàn)某些極限場景，開發(fā)工程師或者產(chǎn)品工程師未考慮到，從而讓開發(fā)或產(chǎn)品及時(shí)補(bǔ)全（這也是TDD測試驅(qū)動(dòng)開發(fā)這種方式的優(yōu)勢(shì)所在）。

假如我們能夠在測試用例執(zhí)行之前，就能有效地進(jìn)行測試用例的評(píng)審，會(huì)大幅節(jié)約整個(gè)團(tuán)隊(duì)的時(shí)間，提升軟件的質(zhì)量，同時(shí)節(jié)約成本。

測試用例要怎么進(jìn)行評(píng)審？一種方式，同樣是類似于 excel，條目化地進(jìn)行評(píng)審。很多線上的測試工具，其實(shí)只是簡單地把線下的 excel 搬到了線上，評(píng)審過程還是一條一條地進(jìn)行評(píng)審。這種評(píng)審方式不太好，同樣放棄了思維的連貫性。測試用例是用思維導(dǎo)圖來寫，而思維導(dǎo)圖的思路是連貫的，因此，基于思維導(dǎo)圖的評(píng)審，更容易發(fā)現(xiàn)每一個(gè)分支的缺陷或遺漏。所以，我們?nèi)匀唤ㄗh，測試用例的評(píng)審也可以直接在思維導(dǎo)圖上進(jìn)行。

當(dāng)測試用例也評(píng)審?fù)曛?，接下來我們?huì)創(chuàng)建測試計(jì)劃。測試計(jì)劃可能是針對(duì)一次迭代的，也可能是針對(duì)一次大版本的。在測試計(jì)劃里面，我們會(huì)添加很多測試用例，由于測試用例是在系統(tǒng)中管理的，因此，只需要去選擇和這次待測的需求相匹配的測試用例即可。如果用戶已經(jīng)把需求和測試用例進(jìn)行了關(guān)聯(lián)，系統(tǒng)會(huì)自動(dòng)添加測試用例，避免人為漏掉某些測試用例。

測試計(jì)劃的執(zhí)行

首先，我們需要指定測試計(jì)劃的負(fù)責(zé)人，在測試計(jì)劃里面可能有成百上千條的測試用例。執(zhí)行的過程，可以按照類似于 excel，或者大多數(shù)線上測試管理工具的方式，一條一條去執(zhí)行。這種執(zhí)行的方式，存在兩個(gè)缺點(diǎn)，第一是執(zhí)行效率太低，需要一條條點(diǎn)擊執(zhí)行，無法批量操作。第二是同樣拋棄了測試用例的編寫思路。如果測試執(zhí)行人員能夠按照測試用工程師的編寫思路來執(zhí)行測試用例，它的效率會(huì)非常高（因?yàn)槭且粋€(gè)人思考問題的正常思路，先點(diǎn)擊A，看看結(jié)果A1，再點(diǎn)擊B，看看結(jié)果B1），而且很快就可以記下所有測試用例（孰能生巧）。就像剝洋蔥一樣，是從最外層往里面，逐層抽絲剝繭。而不是東剝一下，西剝一下。在測試過程中，這種方式也會(huì)由于它的跳躍性，導(dǎo)致測試場景很容易被遺失。

執(zhí)行測試用例的過程中，不可避免會(huì)發(fā)現(xiàn)一些缺陷，這個(gè)時(shí)候我們就要創(chuàng)建Bug。

創(chuàng)建Bug

在測試管理工具中，也需要能夠進(jìn)行Bug管理（這也是線下工具的一個(gè)缺點(diǎn)：創(chuàng)建、跟蹤bug的過程太復(fù)雜）。在 MappingSpace里，測試用例的執(zhí)行過程中，可以直接創(chuàng)建 Bug，輕易就與測試用例建立了關(guān)聯(lián)。如果測試用例已經(jīng)和需求做好了關(guān)聯(lián)，在測試報(bào)告中，可以看到覆蓋度報(bào)告。在覆蓋度報(bào)告里面，可以看到這次測試的需求是什么，測試用例是什么樣的，針對(duì)這些測試用例，測試出來哪些bug，這些 bug是否已經(jīng)被解決。