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