軟件測試中敏捷：系統測試的噩夢(mèng)
很早就聽(tīng)說(shuō)過(guò)敏捷軟件開(kāi)發(fā)的概念，覺(jué)得是個(gè)新生事物，挺好玩，現在IT的炒作已經(jīng)太多了，后來(lái)發(fā)現敏捷的思想越來(lái)越深入人心，大大小小的公司開(kāi)始使用敏捷的模式進(jìn)行軟件開(kāi)發(fā)。終于，敏捷來(lái)到了我的身邊。
首先敏捷測試是敏捷的一種，原有測試定義中通過(guò)執行被測系統發(fā)現問(wèn)題，通過(guò)測試這種活動(dòng)能夠提供對被測系統提供度量等概念還是適用的。 敏捷測試是遵循敏捷宣言的一種測試實(shí)踐： 1、強調從客戶(hù)的角度，即使用系統的用戶(hù)的角度，來(lái)測試系統。 2、重點(diǎn)關(guān)注持續迭代的測試新開(kāi)發(fā)的功能，而不再強調傳統測試過(guò)程中嚴格的測試階段。 3、建議盡早開(kāi)始測試，一旦系統某個(gè)層面可測，比如提供了模塊功能，就要開(kāi)始模塊層面的單元測試，同時(shí)隨著(zhù)測試深入，持續進(jìn)行回歸測試保證之前測試過(guò)內容的正確性。
在傳統的軟件開(kāi)發(fā)模式中，系統測試屬于軟件開(kāi)發(fā)過(guò)程的較后階段，基本是在所有開(kāi)發(fā)代碼全部完成，開(kāi)發(fā)人員拿出所有精力修改bug時(shí)才會(huì )正式進(jìn)行系統測試，包括安裝啦、穩定性啦、負載啦等等。
這次項目開(kāi)始大約半年了，是一個(gè)小版本的升級，采用了scrum模式，我切實(shí)的感覺(jué)到敏捷系統測試不太對勁。在scrum中，根據開(kāi)發(fā)的實(shí)際情況，設定一個(gè)時(shí)間間隔（比如每?jì)蓚�(gè)周）為一個(gè)sprint周期，每個(gè)周期都有需求跟蹤和實(shí)現，然后在進(jìn)入下一個(gè)sprint階段。
目前，我發(fā)現了幾個(gè)敏捷系統測試的主要問(wèn)題：
不斷增加的新功能導致測試結果失效。
既然是敏捷，當然是時(shí)刻適應需求的變化，于是功能不斷的改變。系統測試的結果在一次次的代碼變化之后失效，比如測試應用的穩定性，跑了兩天，內存和其他參數都沒(méi)問(wèn)題，然后開(kāi)發(fā)人員在下一個(gè)sprint對代碼做了很多修改，你說(shuō)要不要重測？？通常這種回歸測試都是在系統測試的最后階段，拿到最后的build的之后再測，現在呢，不得不測，如果說(shuō)系統測試的工作量少也就算了，但事實(shí)上，系統測試的壓力特別大，搞的大家身心疲憊。
發(fā)現問(wèn)題，開(kāi)發(fā)人員無(wú)法適當處理。
如果在測試中發(fā)現了問(wèn)題，按理說(shuō)開(kāi)發(fā)人員應該盡快解決，但在敏捷開(kāi)發(fā)模式下，開(kāi)發(fā)人員每一個(gè)sprint都有相應的需求要實(shí)現，精力有限，于是他們對于細微的bug根本置之不理，一般都會(huì )拖到最后才解決，這就導致了一個(gè)問(wèn)題， 這些bug在若干次build之后會(huì )不會(huì )重現，可能在報完bug之后3個(gè)月，開(kāi)發(fā)人員才開(kāi)始考慮這個(gè)問(wèn)題，此時(shí)這個(gè)bug報告還有效嗎？？是不是需要重新測試？？于是我們測試人員之前的測試工作根本沒(méi)意義了。另一方面，對于嚴重的bug，開(kāi)發(fā)人員也無(wú)法集中全部精力來(lái)處理，三心兩意，你說(shuō)bug能解的順利嗎？后果就是開(kāi)發(fā)人員和測試人員都滿(mǎn)心抱怨。
在我看來(lái)，這種緊跟敏捷的系統測試不是完全沒(méi)有意義，有些嚴重bug可以提早發(fā)現，開(kāi)發(fā)人員可以盡早解決，但是體現了帕累托現象：我們用80%的努力得到了軟件質(zhì)量20%的提高，的確，從公司老板的角度看，這樣值得，反正軟件質(zhì)量提高了，但對于開(kāi)發(fā)和測試人員來(lái)說(shuō)確實(shí)非常痛苦。我記得敏捷的思想來(lái)自于計算機界的各位大牛，他們在設計軟件開(kāi)發(fā)模式時(shí)，沒(méi)有考慮過(guò)系統測試的特殊性嗎？還是他們從沒(méi)把系統測試包含在敏捷思想里面，只是某些人狂熱的把敏捷錯誤的用到了系統測試當中？
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
