測試腳本也好，需求也好，一直在變化，如何在變化之后，還能保證追溯的正確性？質(zhì)量經(jīng)理需要保證此處的覆蓋度是完全的，并且也需要向ASPICE評審老師提供證據。而此處追溯性證據的出示，也是ASPICE評審最耗時(shí)的地方之一。有沒(méi)有什么好的方案能解決這個(gè)問(wèn)題？既省時(shí)、又準確，還能保證追溯性的建立。
是否一定要建立自動(dòng)化測試用例和需求之間建立追溯性？
這個(gè)話(huà)題在不同團隊內部，應該都經(jīng)過(guò)了反復討論。一般來(lái)說(shuō)，測試工程師傾向于不去建立這樣的追溯性關(guān)系。對于他們來(lái)說(shuō)，自動(dòng)化測試用例的生成過(guò)程，就是他們基于對需求的研究，一條條寫(xiě)下來(lái)的，他們天然認為測試用例和需求是對應的，再要花時(shí)間去建立這種追溯關(guān)系多此一舉。況且，軟件出了問(wèn)題再改不就行了嗎？即使所有需求都關(guān)聯(lián)了測試用例，也無(wú)法確保測試用例不會(huì )遺漏，因為一條需求可能對應多個(gè)測試分支，而關(guān)聯(lián)性無(wú)法保證所有分支都被發(fā)掘出來(lái)了。那為什么不等著(zhù)軟件出問(wèn)題之后，再去解決呢？
這種想法顯然不對，在開(kāi)發(fā)早期發(fā)現越多問(wèn)題，付出的改動(dòng)成本就越小。但如果為了追求這種早期的覆蓋度，而需要付出巨大的精力，這又不得不讓我們懷疑，是否可以把這個(gè)工作負荷，放到問(wèn)題出現之后了。
這種巨大的精力來(lái)自哪里？不同于手動(dòng)測試用例，自動(dòng)化測試用例是由腳本語(yǔ)言來(lái)編寫(xiě)的，腳本不同于excel一行一行的，方便建立條目化的對應關(guān)系，相反，他們難以與需求之間建立準確的對應關(guān)系。由于自動(dòng)化測試腳本的更新速度很快，而需求也可能產(chǎn)生變化，需求產(chǎn)生變化之后，更新追溯性關(guān)系的重任，必然落到測試工程師頭上。這是一份相當繁瑣且乏味的工作，對于自動(dòng)化測試工程師來(lái)講，會(huì )有巨大的時(shí)間壓力，特別是當項目比較緊張的時(shí)候。
可是，如果站在需求工程師或者項目經(jīng)理的角度來(lái)說(shuō)，如果無(wú)法看到測試用例和需求之間的覆蓋度數據，心里會(huì )沒(méi)底。如果需求文檔是從甲方客戶(hù)而來(lái)，這種擔憂(yōu)更加明顯。甲方客戶(hù)一般無(wú)法知曉乙方的測試用例生成過(guò)程和測試執行過(guò)程，所以更加需要需求的測試用例覆蓋度數據這一“心理安慰劑”（這大概也是ASPICE提出這一要求的原因吧）。
所以，這個(gè)問(wèn)題就變成了是提前做，還是往后放？是在早期就盡可能地建立追溯性關(guān)聯(lián)關(guān)系，確保需求沒(méi)有被遺漏考慮；還是在問(wèn)題被發(fā)現之后，再去debug，更進(jìn)一步補充測試用例？
我們認為前者有價(jià)值，但如果需要付出巨大的勞動(dòng)和精力去執行，那么投資回報率很低，可能效果還不如后者。那么是否有可能，在不付出那么多精力的情況下，能達到前者的目的？
如何建立自動(dòng)化測試用例和需求之間的追溯性？
我總結了一下，大概應該有如下幾個(gè)步驟：
1、在自動(dòng)化測試用例的注釋中，標注對應的需求編號或名稱(chēng)，確保測試用例和需求之間建立了追溯性。
標注需求名稱(chēng)是萬(wàn)萬(wàn)不行的，因為后續很難通過(guò)識別需求名稱(chēng)，去確定每一條需求是否被覆蓋，從而算出需求覆蓋度。
標注需求編號的前提是，需求要有全局唯一的編號。這句話(huà)說(shuō)起來(lái)很簡(jiǎn)單，但很多團隊往往做不到。有些團隊使用word管理需求，需求沒(méi)有編號，只有章節號。而章節號會(huì )隨著(zhù)章節的增減而自動(dòng)變化，很快，對應關(guān)系便陷入混亂，不可自拔。
2、獲得需求和測試用例之間的矩陣表
如何獲得？
手動(dòng)把上述需求編號和測試用例編號摘出來(lái)，做成一張矩陣表。這當然是個(gè)方法，但前提是測試用例要有全局唯一的編號。但測試用例是用腳本來(lái)維護的，腳本中不會(huì )自動(dòng)生成編號，又回到了上面的困局：人為對測試用例進(jìn)行編號。缺點(diǎn)參照上面，容易出錯，且需要一個(gè)配置管理員不時(shí)就拉著(zhù)測試工程師審查一下。測試工程師還不得mmp。
想辦法給某一條測試用例，自動(dòng)賦予全局唯一的編號，并且自動(dòng)生成上述矩陣表，這是更高效的解題方法。
3、維護矩陣表的正確性
如果是手動(dòng)獲取的矩陣表，當然得手動(dòng)維護，這時(shí)候工作量就大了。
測試用例新增了：需要新增測試用例編號（查一下配置表，找到正確的編號規則，確認目前編到多少號了……），需要對應需求編號（找一下對應的需求）；
測試用例刪除了：需要刪除無(wú)用的測試用例編號，且此編號最好以后都別用了，以免引起混亂，還得確保此處更新，全局更新，如果文件是線(xiàn)下的，譬如這份excel存在多個(gè)人的電腦里，這基本就是新的災難的開(kāi)始。
按照上面的思路，我們開(kāi)發(fā)的MappingSpace也提供了一個(gè)方案，用于管理需求和測試用例，并且自動(dòng)化地建立它們之間的追溯性。詳見(jiàn)下圖：
轉自汽車(chē)電子與軟件
