全程軟件測試實(shí)踐：從需求到運營(yíng)(2)

　　作為測試人員的主要實(shí)踐如下：

　　功能要點(diǎn)確認

　　Xmind是一個(gè)非常好用的腦圖工具，通常在開(kāi)發(fā)人員進(jìn)行編碼前，測試人員會(huì )針對需求處理的用戶(hù)故事，與開(kāi)發(fā)人員進(jìn)行確認，修正理解偏差，確保需求理解一致。

　　圖-5-腦圖用例模板

　　測試用例設計

　　測試人員主要設計測試故事點(diǎn)，使用DSL(Domain Specific language)，infoq文章(敏捷測試之借力DSL)，對測試用例進(jìn)行描述，包括三個(gè)基本要素：

　　Feature、Scenario、Example，補充要素：xmind、Requirement。

　　Feature：把測試分類(lèi)到某個(gè)模塊，并對這個(gè)特性本身的業(yè)務(wù)目的進(jìn)行相關(guān)描述，帶進(jìn)業(yè) 務(wù)目標，傳遞業(yè)務(wù)知識。

　　Scenario：標明這個(gè)Feature的測試場(chǎng)景，可以使用文字描述步驟，或者使用xmind腦圖

　　描述，場(chǎng)景中的數據使用Examples中列出的。

　　Example：引出具體的數據表格把用到的數據都展示出來(lái)，避免相同步驟因為測試數據 的變化而重復若干遍造成冗余。

　　Xmind：腦圖文件，展示測試故事點(diǎn)

　　Requirement：關(guān)聯(lián)需求管理系統的需求id。

　　用例評審

　　主要是堅持同行評審的原則，主要在測試組內進(jìn)行，負責該任務(wù)的開(kāi)發(fā)人員也會(huì )參與，簡(jiǎn)單來(lái)說(shuō)就是對測試用例進(jìn)行查漏補缺的工作。

　　測試探索

　　進(jìn)行了“功能要點(diǎn)確認”和“用例評審”后，為了保證測試場(chǎng)景的覆蓋率，需要再進(jìn)行測試探索。在開(kāi)發(fā)人員完成雛形之后，使用探索式測試的策略，對功能基本流程進(jìn)行有目的的快速走查，挖掘功能不確定的地方和補充測試場(chǎng)景，避免不確定的因素拖延到開(kāi)發(fā)階段后期，造成返工。

　　其中：功能測試、Bug Tracking、回歸測試、系統測試、驗收測試都是日常測試工作所需環(huán)節。

　　燃盡圖發(fā)布

　　另外，測試人員還有一項重要工作，每日發(fā)布燃盡圖，讓團隊了解當前進(jìn)度情況，總結問(wèn)題

　　所在，尋求耗時(shí)超過(guò)預期時(shí)間任務(wù)的解決辦法。

　　圖-6-燃盡圖

　　圖形特點(diǎn)：

　　1)剩余工時(shí)在計劃基準上方，代表進(jìn)度有所延遲，應抓緊進(jìn)度;

　　發(fā)現此類(lèi)問(wèn)題，需要分析總結，原則是保證交付時(shí)間，對相應任務(wù)進(jìn)行調整，擁抱變化，發(fā)現任務(wù)粒度太大，該拆分的繼續拆分;對于重構需要慎重，不要過(guò)度深入重構，給測試帶來(lái)額外工作量，影響整個(gè)進(jìn)度，對于整個(gè)版本而言，只有開(kāi)發(fā)、測試在承諾的時(shí)間內完成任務(wù)，才是真正完成，僅僅開(kāi)發(fā)完成交付算不上成功。

　　2)剩余工時(shí)在計劃基準接近，代表進(jìn)展良好，繼續保持;

　　此時(shí)也需要查看在這種進(jìn)度下，優(yōu)先級高的任務(wù)是否得到時(shí)間保證，而不是因為處理完簡(jiǎn)單任務(wù)才使得燃盡圖長(cháng)的好看。往往有些開(kāi)發(fā)人員，喜歡挑著(zhù)任務(wù)來(lái)做，把簡(jiǎn)單易做、優(yōu)先級的任務(wù)先完成了，因為這些總在預期內能夠完成，所以前期燃盡圖的趨勢看起來(lái)沒(méi)有問(wèn)題。

　　缺陷經(jīng)驗庫

　　每個(gè)團隊都存在開(kāi)發(fā)/測試新人和開(kāi)發(fā)/測試老人，當測試人員與開(kāi)發(fā)新人進(jìn)行需求確認的時(shí)候，還需要進(jìn)行缺陷經(jīng)驗教訓的提醒，避免多走彎路。

　　(點(diǎn)擊圖像放大)

　　圖-7-缺陷總結

　　提升開(kāi)發(fā)自測質(zhì)量

　　測試人員可以提供相關(guān)checklist(大家可以根據原作者提供的修改為符合團隊的)幫助開(kāi)發(fā)人員在編碼過(guò)程中關(guān)注開(kāi)發(fā)自測的要點(diǎn)，從而提升質(zhì)量。

　　(點(diǎn)擊圖像放大)

　　圖-8-web軟件測試checklist

　　持續集成

　　利用持續集成(Jenkins)平臺，做到快速的構建開(kāi)發(fā)代碼，自動(dòng)的單元測試化，來(lái)提高開(kāi)發(fā)代碼的效率和質(zhì)量。

　　負責單元測試的開(kāi)發(fā)人員，會(huì )收到失敗構建的郵件;

　　負責集成測試的開(kāi)發(fā)人員，會(huì )收到失敗構建的郵件;

　　負責自動(dòng)化測試(Selenium)的測試負責人員，會(huì )收到失敗構建的郵件;

　　這種方式，確保單元測試、集成測試、自動(dòng)化測試，有相關(guān)人員關(guān)注和維護。

　　(點(diǎn)擊圖像放大)

　　圖-9-持續集成

　　Sonar反饋

　　Sonar is an open platform to manage code quality. As such, it covers the 7 axes of code quality。

　　(點(diǎn)擊圖像放大)

　　圖-10-sonar分析結果

　　測試人員主要反饋問(wèn)題如下：

　　Code coverage：團隊要求代碼覆蓋率在80%以上;

　　Test success：團隊要求測試成功率在100%;

　　Duplications：團隊要求代碼重復率在10%以下;

　　Violations：團隊要求Major類(lèi)別的代碼規則缺陷在20以下;

　　開(kāi)發(fā)團隊必須保證每個(gè)環(huán)境的質(zhì)量目標，才能夠保證整個(gè)的質(zhì)量目標。

　　小結：

　　測試人員與開(kāi)發(fā)人員永遠不是敵對關(guān)系，而是協(xié)助關(guān)系，確切來(lái)說(shuō)是質(zhì)量天枰的兩邊，任何一邊的工作沒(méi)有做好，都會(huì )失去平衡。

　　4 發(fā)布階段測試

　　在發(fā)布階段，開(kāi)發(fā)人員、測試人員、QA人員主要做的事情，如下表所示：

原文轉自：http://www.infoq.com/cn/articles/whole-software-testing-practice-requirements-to-operational