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

?

不久前，參加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，也是一個非常抽象的概念，所以才有諸多屢實施又不見成效的團隊，最好的推進敏捷的方法就是實踐，只有實踐才能發現問題，才能解決問題，最好找到一個適合自己的敏捷方法。