關于靈活和自動化測試的一點心得

中華傳統文化源于《易》，成于孝，孝為德之本。孝順：孝則順，不孝則不順。

不久前，參加Thoughtworks組織的一場自動化測試的分享，同僚由于出差國外不能參加，特意囑托我提問兩個問題：

在網際網路這個将“靈活”與“持續內建”進行積極實踐的環境裡，“靈活測試”與“自動化測試”成了一個大家經常探讨的話題，

那麼自動化測試最佳的實行時間是在什麼時候？如何推行最有效的自動化測試？

以下謹代表個人觀點：

個人整理了一些測試最佳實踐并參考查閱了一些測試理論的書籍，又綜合了個人工作經曆的一些經驗，總結了以下幾點：

1、測試人員盡可能早的進入産品或項目的相關工作(這裡指的産品或項目，指的都是從頭開始的)，從産品的計劃、需求調研、評審工作的開始測試人員就進行參與，這麼做的目的有如下幾點：a.讓測試人員盡可能多的了解需求、了解業務，積極的提出問題，b.在下一步系統架構和接口設計之後，測試人員可以進行盡早設計系統的接口測試用例，c.還可以為下一步編碼工作的單元測試做一個良好的鋪墊，在後期設計單元測試用例的同時，懂代碼的測試人員可以直接的檢查開發人員的代碼邏輯和業務邏輯是否符合要求，這也就實作了用最少成本“雙人程式設計”。

2、綜合一些實際情況考慮：根據一些實際調研，一般開發與測試的比例在1:6--1:10左右，能達到1:6的已經很不容易了，暫時不去讨論這個比例問題，因為這個需要根據項目的實際情況來看，個人看來：一些大型的網際網路公司是不差錢的，是以他們會盡可能的在測試方面多投入或者說投入較高的，還有一些公司是不願意在測試方面多投入但是又想多做測試的，還有一些就是盡可能少投入的，其實這些都可以調整，調整的依據是兩個方面：一是確定公司對這個項目的重視和公司是真正的做測試，如果沒有上司的支援，準确的說沒有大上司的支援，測試工作是很難有效推進的，二是有效的安排測試人員，就是在項目的不同階段安排不同測試人員，在測試不是很多是時候，可以使用半個人或者更少的測試人員，實作這一點的方法就是讓一個測試人員去服務多個項目即可，當然這個多個也是有數量限制的，因為一個人的精力也是有限。

3、從第前2條提出來的一個疑問：作者一直提倡讓測試人員盡可能早的接觸産品和項目，這樣能讓測試人員充分了解項目，那麼如何讓一個人服務于多個測試項目？首先：明确一點，不是測試人員不從項目的開始就介入，測試人員就不能了解需求、不會測試。對于一個有經驗的測試人員來說，快速的熟悉項目的需求并不是一件難事，如果說項目的各種邏輯真的是很複雜，項目經理也可以根據使用者故事或者進行一些更為細緻的安排來讓這些協調過來的測試人員開展測試工作。一人服務于多個項目，這種事情在國内應該是屢見不鮮的。

4、如何安排人員也是一個如何花錢的問題：這種體會最深的就應該是外包公司，是先花錢還是後花錢還是超支還是項目失敗，想必外包公司對這方面算的是最細的了。早期發現問題早解決問題，後面的壓力就會小，不能早期的發現的問題，後面的團隊壓力就會像滾雪球一下越來越大。早期的測試投入看成一份成本的話，用這一份成本，來提早的發現問題的降低風險，後期才開始投入測試的話，也算是用一份成本，但是如果發現問題，開發人員就追蹤、修改的成本是要遠遠大于初期的，項目的龐大和不穩定是讓開發人員準确定位問題最大的困擾，還有測試人員做測試驗證、回歸測試、自動化腳本的修改這一切成本。

5、在項目的中後期如何做好自動化測試工作？在項目中期的時候，問題會逐漸積累，測試的東西也會越來越多，開發和維護的東西越來越多，維護是指測試人員測試出來的bug需要修複，但是又不能因為修複bug就停止項目開發工作。随着項目的推進，測試的效率保證是一個關鍵問題，這個時候自動化的推進和效率卻成了一個沖突的問題。原因有三：1.自動化代碼需要編寫和調試

2.自動化代碼測試結果需要和手動測試結果進行比對

(自動化測試結果和手動測試結果不一緻會有發生)3.自動化測試代碼需要維護，尤其是在需求變更和設計變更的時候，手動測試隻需要肉眼對比，而自動化測試可能會将代碼進行較大改動。這三個問題大大降低了測試效率，這是手動測試必須成為項目的主導。解決這一問題的辦法就是在項目測試集中的階段調整手動和自動測試人員的比例，自動化人員測試的範圍需要有一個合理的規劃，必須定時的送出自動化測試代碼，在手動測試完成後必須盡快的補充自動化測試代碼，在完成測試工作的同時也自然的與手動測試的結果進行了比較，相當于進行了1次回歸測試。也就說還是全部由手動測試人員進行第一輪全面覆寫的測試。

6、在“靈活”開發過程中，自動化工程師先對哪一部分功能進行優先的用例實作：可以從以下幾個方面進行考慮：1.優先考慮資料對比類型的功能，這種功能人工操作比較費眼力和時間

2.優先考慮已經測試出問題的功能，這樣可以有效的對bug的功能進行回歸檢查 3.使用者使用比較頻繁的功能

4.項目優先級比較高，比較核心的功能

7.強調一點：手動測試和自動化測試對于項目來說同等重要，不存在自動化測試人員進階于手動測試人員。如果說一定要說哪個最重要的話，隻能是看項目的不同階段，在項目前中期的時候的時候，手動測試占據了核心地位，在後期的時候，自動化的全面覆寫保證了回歸測試的有效進行。

8.總結：關于靈活開發和靈活測試的一點心得：靈活現在已經被推向了一個高潮，何為靈活？太多人有不同的見解，說到最後與靈活最分不開的一詞就應該是“實踐”，靈活是實踐出來的，不是效仿出來的，現在太多的公司和團隊在盲目的追求靈活，拿scrum來說，有多少公司在做的隻是scrum最最表象的一些東西，安排站會，制定sprint，總結會等等，但是這些真的給你的團隊帶來了改善了嗎？想必答案隻有他們自己清楚。我心中的靈活：靈活---敏-結，敏就是靈活，簡單的說就是要一個高效率，結：是指項目團隊的協作和内部團結,這一點非常重要。看那些成功實施靈活的團隊和諸多的最佳實踐團隊他們都是團結一心的，整個項目團隊都有一個共同的目标和追求，而不是每天項目經理在驅使着大家在前進，每個人都積極上進學習，遇到不懂的問題去總結、去學習，去突破，再去分享，而不是說，“這個問題太難了，這個技術太難了，這個。。。我可做不了”，如果每個成員都采用這種排斥的心裡，那麼這個團隊就永遠都靈活不起來，還有就是在需要協作的時候，兩個項目組不要互相“踢皮球”，而是要勇于承擔責任，最普遍的現象就是項目出現了問題，然後大家在會上開始掐架。這時候有人會問，自己出來擔責任不是傻嗎？其實不然，一個明智的老闆當然看的懂到底是誰的責任，是否真正的需要人來承擔責任。如果這都做不到，證明這個老闆也就。。。再談實踐，筆者看來，很難有一個很細緻的又可以公用的靈活方法，即使現在最流行的scrum，也是一個非常抽象的概念，是以才有諸多屢實施又不見成效的團隊，最好的推進靈活的方法就是實踐，隻有實踐才能發現問題，才能解決問題，最好找到一個适合自己的靈活方法。