測試工程師和開發工程師怎樣才能最好的合作？

　　從一張表的索引想到的

　　我們有一張保單基礎信息表pol_main，大約有500萬條記錄，算是一張中等數量級的表，它關系著大量的保險業務操作和相關查詢功能。這張表的pol_sts(保單狀態)字段的cardinality(基數)是26，這個字段上有個獨立的索引;另外一個常用的查詢字段plan_code(險種代碼)的cardinality在1000以上，并且在逐年隨著新業務模式的出現而增長，該字段無索引。參照這兩個字段，數據都是非正態的不均勻分布，而且這兩個字段都是非常頻繁的被查詢語句用到。無論是從selectivity還是cardinality的角度考慮，在plan_code上建索引都要比pol_sts好，但是為什么沒有這樣做呢?我曾就這點疑問咨詢過資深的開發工程師和數據庫架構師，他們的觀點是一致的：pol_sts字段上有索引是因為最初在做表結構設計的時候就做了，而當時沒有考慮plan_code這個字段，估計當時在售險種只有幾個吧;而現在不在plan_code上建立索引，主要是因為這個表、這個字段被引用得太多，沒人能夠評估得清楚這樣做的風險有多大。

　　要么刪除pol_sts字段上的索引，要么建立plan_code字段的索引，最不濟就是建立這倆字段的組合索引，看起來很簡單的事情，實際操作起來卻有著這么多的顧慮，為什么?因為沒人愿意去挑戰系統運營的穩定性，拿這個做賭注付出的代價的確是很大的。對于他們的擔憂，其實我解讀出來的信息就是：

　　1、 對軟件測試的質量保證作用信心不足，不論是開發自己做還是測試部門去做;

　　2、 測試的成本太高，為了一個性能的優化，要牽動十幾個人去測試，換來的質量提升很有限，換句話說，可能是測試的手段不夠經濟、不夠高明導致了整個行為的ROI不高;

　　3、 總之，沒有好的質量守護，沒有好的軟件測試，開發不敢輕易修改他們認為軟件中敏感的地方。

　　既然coder對自己開發質量的衡量如此依賴testing(注意：不是tester)，那么他們是否為testing創建了足夠好的環境呢?未必!再舉個例子，我們公司的應用絕大多數是javascript/html+java+oracle這么三層。大部分人都知道SP代碼易發布但是相對于Java代碼來說，測試更麻煩一些;反之Java代碼的發布都要走中間件的部署，需要起、停應用服務，看起來會讓系統服務不連續，但是測試更加簡單。而我們因為有固定的版本發布計劃，所以SP代碼在發布上的優勢其實已經不明顯了，但是大家還是熱衷于寫一些邏輯復雜的、相互調用繁多的SP代碼來實現我們的業務需求，這是為什么呢?

　　剛畢業那會，很幸運在神碼融信的東亞銀行核心項目做QTP的自動化測試試點和推廣工作，真可謂是不舍晝夜的忙碌。早在那個時候，我就夢想著開發如果能夠就一定可以建立標準的UI組件庫，實現標準的拖拽式開發，不會隨意命名一些組件;這樣自動化腳本開發和維護就非常方便，很容易追得上甚至超過編碼的進度?？上н@對我來說只是一個夢想，從未被實現，現如今在帶領大家一起做Selenium/ WebDriver和WatiJ等工具的自動化測試腳本開發同樣面臨這種問題。很多頁面組件沒有id、name，coder們在修改的時候變動隨意性也很大，實現方式五花八門，這樣測試腳本的維護工作量也是非常大的，經常因為人力和工作量的比例不協調導致測試腳本維護不及時，運行穩定性不好。這樣就意味著測試的投入需要增加而質量卻不高，自動化的ROI呈指數曲線下降。有同事說：“測試自動化沒有開發的幫忙就等于是測試自己在YY”。雖然有點夸張，但是意思很簡單：如果coder如果故意不配合的話，自動化測試的確會因為可測性遭遇很多測試腳本開發技術實現上的問題，所以說低質量的應用代碼能鍛煉出自動化測試開發高手來，但是伴隨著這種鍛煉方法的是可恥的資源浪費。高智商的coder們想不清這么簡單的問題么?當然不是，那他們為什么沒有提供更具可測性的代碼給tester呢?

　　反過來tester對coder處境的考慮也是一樣不夠的，例如，很多tester不考慮coder的工作量，死硬地按照流程規范要求coder首次必須移交所有的SRS，拒絕增量迭代開發和移交;這樣其實也是在逼迫coder們權衡之后移交一堆不可測的代碼過來。再例如，tester只顧埋頭想自己的測試設計和執行，不愿意主動幫助coder想設計和實現的方法，認為這不是自己的本職工作或者認為自己不具備這個“資格”去對coder的工作指指點點。高智商的tester們難道不知道自己這些不合理、不積極的做法最終會給自己帶來更大的麻煩、更大的工作量么?他們應該知道，但是他們為什么沒有采取更好的辦法呢?

　　Coder和Tester的淵源

　　接上文，我能想到的原因很簡單：因為負責coding的和負責testing的不是同一群人，所以往往由于他們專心于“本職工作”而忽視了對對方工作進行深入的思考，他們忽視的是對自己造成什么樣的間接影響，最終忽視的是自己交付給客戶的代碼的質量，也是自己的口碑。即便他們中有些人偶爾能想到這些，替對方多考慮一些，他們也無法打敗流程的約束和更簡單實用的誘惑，換句話說：選擇短視，選擇當下可見的便利;選擇無條件服務流程規范，選擇拒絕持續改進。

　　把一個人的“本職工作”變成了多個人的“本職工作”，用流程來約束勢必造成這些現象的出現，但既然coding和testing不由同一撥人負責已成既定事實，那么很明顯，coding和testing的合作變成了coder和tester的合作了。我把二者的合作關系和淵源分成5個層次，僅供參考：

　　1、 原始模式——沒有專職測試人員，沒什么可以討論的;

　　2、 相互指責——我能想到的關鍵字是權力制衡與推諉或過分干涉，?？吹竭@種現象，抱怨的帖子滿天飛;那些自以為善于“權術”的管理者也很喜歡利用coder和tester的沖突和相互推諉去做所謂的“制衡”，相信這種管理者會漸漸退出IT的舞臺，不過這種相互指責的現象貌似短時間內還不會那么快消失。

　　3、 相安無事——我能想到的關鍵字是既定流程下責任共擔與成果共享，我個人感覺這是我們公司現有的一種常態，彼此照章辦事，無過多思考和改進意識;即便彼此心里對對方有更多期待也不便明說，總覺得干涉對方的工作很不禮貌。在我看來，這是虛假的尊重，卻是真正的安于現狀和不思上進的代名詞。

　　4、 相互倚重——我能想到的關鍵字是質量守護和可測性保證，表現在積極的互動和溝通：樂于相互尊重但決不因為害怕沖突而不提出自己的意見;懂得換位思考但決不遷就對方短視或者不經濟、不科學的行為。coder要實現一個重構或者系統改造，他們可以依賴測試的質量保證和守護作用;tester要更快更簡單的測試也可以要求coder使用更合理易測的實現方式，在哲學上叫相互獨立而相輔相成。

原文轉自：http://www.kjueaiud.com