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