資訊專欄INFORMATION COLUMN
摘要：測試的工作量更加分散，不會出現一段時間無事可做，一段時間忙的要死的情況。如果測試一味地只管提交，而不考慮開發的工作習慣和目標的可執行性，就會導致效率大大降低。這種看似投機取巧的方法會讓測試的用例編寫工作事半功倍，效率大大提升。
臨近年末，各家公司都進入了緊張的年前項目沖刺階段，我們也不例外。每天開完早會，就聽大家在抱怨任務太多做不完、一個月都沒正常過周末了云云。
據開發部門的同事說，他們的任務列表的長度都快趕上老婆雙十一的購物清單了，而作為與開發組聯系最緊密的測試組，我們的處境也好不到哪去，畢竟用的都是一款協作工具。
為了提高測試與開發的協作效率，個人在嘗試方法過程中也總結了幾條小技巧，在這里和大家分享一下，歡迎互相探討。
如何用敏捷方法做測試？敏捷的核心就是個“快”字：快速開發，快速推出，快速驗證產品方向。說白了就是管理每個小目標，保證他們能夠按時完成。
想要運用敏捷方法，要注意幾點：
開發做完一個小功能馬上開始測試，減少等待時間。
測試的工作量更加分散，不會出現一段時間無事可做，一段時間忙的要死的情況。
每次的bug都是針對剛剛開發完的功能，開發處理起來會更得心應手，減少溝通成本。
在與同事溝通中，我還了解到，將bug加入開發計劃會大大影響他們的目標完成進度，往往問題剛整理出一些思路，就因為某些bug需要處理而被迫中斷了。
所以很多時候，直到deadline臨近，目標中還會存留大量任務。如果測試一味地只管提交bug，而不考慮開發的工作習慣和目標的可執行性，就會導致效率大大降低。
內容截圖自teamin演示案例，結構略有修改，下同
解決這個問題，需要將bug多帶帶管理，同時做到合理分配，有節制，分緩急。
比較好的做法是，測試根據當前的開發計劃設置自己的計劃，將所有bug按緊急、重要、一般3種優先級來劃分（分幾級不重要，重要的是如何處理分級不同的bug），優先挑選緊急bug放入當前目標，重要bug根據當前進展情況適量分配，一般bug可以暫時不考慮。
另外，bug最好能建立多帶帶的項目來管理，保證開發的任務集中度，避免產生過多冗余信息（屬于當前版本卻優先度不高的bug）。
項目、目標、標簽，三位一體
舉個不恰當的例子，測試與開發的配合就像父母喂孩子一樣，不能等到孩子餓了才給吃的，這樣容易一次喂太多，引起消化不良；也不能什么都給孩子喂，要注意合理配餐，否則營養失衡影響健康發育。回頭心疼的不還是你這個做父母的嗎？（哎！好像哪里不對……）
計劃經常需要修改，測試如何應對？計劃變更頻繁可以說是敏捷開發的另一大特點。上文提到了將bug多帶帶管理，并將篩選后的bug加入計劃，那么這種多帶帶管理bug的方式就可以解決計劃頻繁變更的問題嗎？
顯然不能，因為bug最終還是要加入計劃，計劃出現變更，之前分配好的bug也會隨之發生變化，這樣之前設定的測試目標豈不亂套了嗎？而且想必大家也會有疑問，我分配到開發計劃中的bug，相當于從測試項目中移走了，那么修改后我如何得知，又如何統一審核呢？
簡單來說，我需要任務支持跨項目協同，這樣可以將同一個任務分配給不同的項目，達到測試與開發既各自獨立、又相互聯動的效果。這其實比較難實現，好在我用的協作工具支持我這樣做，具體怎么做我不太好描述，直接上圖吧：
跨項目協同，任務狀態共享
這樣一來，我在測試項目中設置的目標計劃，不會隨著開發計劃的變更而變化，計劃的調整都是自主和可預期的，另一方面，也能解決任務狀態同步和后期審核的問題。
如何編寫測試用例？計劃開始階段沒有測試工作，主要就是做測試用例了。我想這也是不少測試小伙伴的心頭大患。測試用例結構復雜，分支眾多，很難做的很詳盡，一開始更是不知道從何寫起。
到目前為止，我還沒有找到一款非常合適的管理工具能夠比excel做的更好，管理工具即使能夠自定義功能，也很難達到excel的靈活性。與其在軟件中記錄分支，我寧愿將需要參考的相關任務導出成excel，然后自己添加情況分支，做優化修改。
導出任務列表，便于用excel編寫用例
我一般會在開發前期就將產品的整體計劃導出，作為總的測試用例大綱；再將開發當前正在做的計劃導出，作為版本測試的用例大綱。
經常寫測試用例的測試小伙伴可能都深有體會，用例最頭疼就是整理結構大綱，而產品的整體計劃本身就是一個結構性很強的需求大綱，相當于一個全部功能點的索引目錄。
我們只要導出，稍作修改和補充，用例的完成度就會相當高。而且這樣做還省去了與產品、開發一條條對接溝通的麻煩，減少了大量的溝通成本。
這種看似“投機取巧”的方法會讓測試的用例編寫工作事半功倍，效率大大提升。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/8737.html
摘要：為了構建可伸縮的測試自動化框架，需要記住以下三個最重要的干凈編碼實踐。因此，組織期望其或測試自動化架構師設計和開發健壯，可維護的智能測試自動化框架。包括適當的文檔在測試自動化框架開發項目中工作的程序員不太可能獨自編寫代碼。 ...
摘要：于年獲得的職位，并發現了一個需要徹底改革的部門。此外，該報告還將云計算確定為了最需要專業開發的領域之一。為了能夠成功過渡到云，首席信息官們正在重新組建他們的IT團隊，使其變得敏捷、跨職能，并且擁有新的技能、角色和高度適應性的思維方式。 Paul Ryan于2017年獲得OpenX的CTO職位，并發現了一個需要徹底改革的IT部門。 OpenX，一家制作程序化廣告平臺的技術公司，服務...
摘要：近年來，云計算無疑成為企業開展業務的關鍵組成部分，特別是當企業考慮數字轉型的競爭時。其次，整體可見性和態勢感知水平基于遙測和與所有職能團隊的整個組織相關的。尤其是數字轉換和云計算，是創新和更廣泛業務轉型的組成部分。近年來，云計算無疑成為企業開展業務的關鍵組成部分，特別是當企業考慮數字轉型的競爭時。在全球范圍內，企業正在將他們的應用程序和服務轉移到云端，從而獲得更低的資本性支出和運營支出的好處...
摘要：坎貝爾說我們已經看到，隨著團隊采用微服務，從提交到制作的周期時間顯著縮短。轉向微服務代表著一場大變革，各個組織需要做好應對這種重大轉變的準備。表示，企業還應考慮根據業務優先級為每個微服務的性能和可靠性定義服務水平協議。如今新應用程序的開發都與交付速度有關。向敏捷環境的大規模轉移已經持續了數年，這促使人們有一種輕松快速地部署軟件的意識。微服務是面向服務的體系結構（SOA）的一種變體，它將應用程...
閱讀 2033·2021-11-19 11:37
閱讀 724·2021-11-11 16:54
閱讀 1171·2021-11-02 14:44
閱讀 3065·2021-09-02 15:40
閱讀 2374·2019-08-30 15:44
閱讀 961·2019-08-29 11:17
閱讀 1066·2019-08-26 14:06
閱讀 1560·2019-08-26 13:47
