漫談測試平臺—建設模式探討

常常看到不少測試同仁討論測試平臺相關的一些話題，好比爲何要作測試平臺，測試平臺的價值究竟是什麼？怎麼作測試平臺？等等。這些問題說實話，仁者見仁，智者見智，沒有最終的誰對誰錯，全部觀點都要代入到討論者所在的實際工做場景中才能看出來它的合理性。今天我想跟你們探討下在多行業多業務形態下公用測試平臺構建中存在的一系列問題，也但願可以引發普遍的討論與思考。

首先講下場景，什麼是」多行業多形態「。多行業指的是你的公司可能會涉及不少行業方面軟件的開發，好比同時涉及政務、教育，同時涉及醫療、汽車等。多形態指的是，在你的公司的某個行業方向裏，軟件產品有不少種形態，有軟件、有平臺、有硬件等等。通常來講，一個公司規模變大了，其業務基本都會不斷延伸，產品形態也會隨着行業發展和行業須要不斷變化。好比某公司教育行業的產品有app，也有平臺，也有教學一體機，它的汽車行業產品有SDK、app、ROM、車機整機等等。那麼"多行業多形態"給測試平臺建設帶來的挑戰是什麼呢？我這裏先不說，你們先思考，後面的文章裏咱們再探討。

場景介紹完了，咱們進入正題。通常來講，測試平臺建設有兩種模式。
第一種：經過專項技術孵化測試平臺。你能夠簡單的理解成作測試產品，這種模式通常比較適合於單業務或者在某個專業領域技術作的很深的團隊。它經過對某項技術的深度理解和使用經驗的總結，沉澱成可複用的測試技術平臺，具備必定的先進性和被論證的實踐價值。像早期起來的不少移動app雲測平臺，其實就是一個典型的表明。若是你的業務有不少app產品，雲測平臺對你而言是一個很好的選擇，由於相比不少公司而言，他們是專業的（這裏不是作廣告，平心而論，國內絕大多數軟件公司，測試技術水平其實仍是比較差的，因此也要感謝阿里、百度、華爲、testin等這些提供雲測能力的廠商爲行業賦能）。這種模式主要的問題有兩個：
（1）泛技術要領先（技術、場景、方案、玩法，不只僅是技術），不然容易被顛覆，被取代。也就是你須要不斷的去提高這個測試平臺的競爭力，在公司裏不是說它越先進越好，而是最起碼在你的公司裏面要起到引領的做用。不然你在作測試平臺的時候就會面臨這樣的問題：爲何要用你的而不是業界開源的？你的核心競爭力是什麼？你能解決我什麼問題？你的平臺比我當前的測試方式更優的地方在哪裏？對於單業務而言，其實這個問題並不突出，由於你須要知足的對象比較單一，你只要作到平臺比當前的一些玩法略微先進就能夠知足須要了，並且還能夠經過強制使用等管理手段搞定（管理手段不是咱們推崇的，因此後面的全部觀點裏，我都儘量不提這個方式）。
（2）很難知足用戶個性化的需求。跟作產品同樣，在多業務都形態的背景下你的測試平臺不可能作到面面俱到，你們提的需求五花八門。好比，在」多行業多形態「的場景下，咱們作一個移動雲測平臺，照顧到了絕大多數APP類的業務，可是一些智能終端的業務就不幹啦，你得給咱們支持終端的接入，適配咱們的接入協議。不少時候也不是說不能去作這些個性化的需求，由於在作的過程當中咱們須要平衡資源、時間進度、質量效果、技術實力、平臺產品版本控制等等一系列因素，咱們不得不作一些取捨。若是咱們不能知足這些個性化的需求，會致使什麼結果呢？用戶流失。在公司裏，這一類用戶流失，意味着你的平臺就丟失了一塊市場。到這裏，你必定會問，那爲何要在公司層面作測試平臺呢，而不是進入到這些個性化的業務裏去作知足他們須要的平臺呢？這裏涉及到的問題就是策略（測試平臺分級建設）和資源的權衡，後面的文章裏會詳細探討。

第二種模式：根據業務需求產生測試平臺。你也能夠簡單的理解成作功能交付。這種模式比較廣泛，也最直接，用戶給我什麼需求我就作什麼。一樣的，這種模式也有三個主要問題：
（1）需求不必定能經過當前技術實現。說實話這個問題要拆解來看，有多是平臺建設者的平臺技術水平沒達到，另外一方面多是需求確實天馬行空了。相比第一種模式，需求在這種模式裏實際上是很難作到徹底控制的。好比說，一些用戶參加了某些大會，看到某些公司的平臺宣傳材料就以爲它很牛逼，就照葫蘆畫瓢提需求給你。這種模式下，爲了規避實現上的風險，可能會增強需求的審覈。可是若是你須要的是這樣的強勢客戶，你怎麼辦呢？「個人需求你都知足不了，我爲何要給你提需求？」，「這個需求若是你不作，我就不用」。那就偏向虎山行吧！既然決定要作了，你就得在實現需求的過程當中開始你漫長的技術調研。邊實現邊調研，實際上是很是危險的，一方面可能會致使功能交付週期過長客戶失去信息，另外一方面調研成果有很大的不肯定性，剛調研完成就立馬投入平臺建設的技術也存在不穩定不可靠的風險，畢竟沒有通過實踐檢驗。
（2）需求能夠知足，可是可能會出現不少定製化的項目或功能，平臺建設團隊精力可能會被這些大量的定製化消耗殆盡。
（3）業務每每是短視的，能解決當前問題就行，把平臺規劃的重任放到了平臺建設者身上，對平臺建設者提出了更高的要求。而在不少公司裏，平臺建設者實際是跟業務分離的，他只作平臺建設，缺乏業務參與，少了一些對業務測試場景的理解，也就致使最終平臺的規劃存在不足甚至難產。所以，有一些公司意識到這種問題以後，開始把平臺建設者放到業務裏，跟業務測試人員捆在一塊兒one team。

其實咱們在這裏討論測試平臺建設的時候，不少問題其實也一樣能夠放到產品研發、項目研發的角度，你們能夠嘗試體會一下。那麼最後，」多行業多形態「場景下，測試平臺應該選擇哪一種模式進行建設呢？亦或者是否是有更好的模式呢？有哪些問題須要咱們解決呢？感興趣的同窗能夠留言、回覆、私信，各抒己見。下一篇咱們展開討論。

作測試平臺其實不容易，它不是一個直接產出價值的東西，它更多的是一種輔助工具，不少企業其實對測試平臺的認知並不深，在建設上一味的強調價值量化，每每忽略了它最本質的東西：賦能，最終致使在測試平臺的投入上不足同時輕視了平臺建設的複雜度。在這種狀況下，每每須要咱們權衡不少東西，尋找適合各自企業測試平臺建設的模式。

本文由博客一文多發平臺 OpenWrite 發佈！