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