現(xiàn)在對(duì)于自動(dòng)化測(cè)試與CI往往有一些很常見的謬見，包括一些專門從事相關(guān)工作的人都未必清楚。在實(shí)際的工作中感觸頗深，所以想撰文討論一下。 第一，自動(dòng)化測(cè)試就是給CI服務(wù)的，或者自動(dòng)化測(cè)試不太能發(fā)現(xiàn)問題。 持有這種觀點(diǎn)的人，建議他們?nèi)タ纯碐oogle或者M(jìn)icrosoft的相關(guān)測(cè)試研究的文章，或者GTAC（ Google Test Automation Conference),也許可以拓寬我們考慮這個(gè)問題的思路。 他們的測(cè)試對(duì)象是搜索引擎，海量的數(shù)據(jù)庫信息，或者提供的各種服務(wù)，比如Google Map，Navigation。他們研究的是搜索引擎對(duì)于海量的數(shù)據(jù)庫處理起來是否有效，搜索結(jié)果是否準(zhǔn)確 。
下面舉幾個(gè)例子： 比如Google會(huì)提供一種 ‘Auto Completion'的功能，你只要在搜索框里敲入一個(gè)詞，google會(huì)根據(jù)與這個(gè)詞的相關(guān)性大小，以及該關(guān)鍵詞被搜索的熱度，自動(dòng)補(bǔ)全一些關(guān)鍵詞，并提示給你。這樣，你就可以參考或者直接用別人的搜索條件。那大家有沒有考慮過，這種功能應(yīng)該如何測(cè)試呢？ 還有導(dǎo)航系統(tǒng)，怎么確保從A點(diǎn)到B點(diǎn)找出來的路徑都是正確的呢？而不是說你要找一個(gè)當(dāng)?shù)氐牟宛^，導(dǎo)航卻告訴你要來一次跨國旅行呢？
面對(duì)這些海量的測(cè)試數(shù)據(jù)，并且基本上也無法預(yù)先給不同的測(cè)試數(shù)據(jù)定義好期望的測(cè)試結(jié)果。所以他們無法采用我們這樣的靜態(tài)的自動(dòng)化測(cè)試，而且通常Manual Testing也無法幫助他們解決問題， 他們必須采用動(dòng)態(tài)的大規(guī)模的自動(dòng)化測(cè)試，或者叫計(jì)算計(jì)輔助測(cè)試。

他們的做法就是采取一種叫HBT( Heuristics Based Testing）的技術(shù)，測(cè)試工程師找出一些測(cè)試是否成功的判斷法則，而不是像傳統(tǒng)的自動(dòng)化測(cè)試一定要明確規(guī)定靜態(tài)的期望結(jié)果，并把這種判斷規(guī)則用代碼實(shí)現(xiàn)。 通過這種方法，再加上一些并行的測(cè)試技術(shù)，他們也許一天可測(cè)上千萬個(gè)case，并且在一種判斷法則已經(jīng)不太能有效地發(fā)現(xiàn)問題的時(shí)候，可以隨時(shí)調(diào)整或者尋找新的判斷成功與否的法則。 而尋找 “測(cè)試是否成功的判斷法則”，也就是常說的Test Oracle的時(shí)候,則很類似傳統(tǒng)手工測(cè)試做manual exploratory testing的過程。測(cè)試人員做手工測(cè)試的時(shí)候，不是重復(fù)地去敲鍵盤，點(diǎn)鼠標(biāo)，而是尋找系統(tǒng)的失效模型，然后利用自動(dòng)化測(cè)試技術(shù)實(shí)現(xiàn)，并把這個(gè)失效模型放大到盡可能大的范圍。 這部分工作，往往是測(cè)試工作中最有意思，最有創(chuàng)造性，往往也是最考測(cè)試人員功力的。 我曾經(jīng)看過一個(gè)他們的例子，Microsoft 的Principal Test Engineer寫的，他們用這種方法，一天執(zhí)行了2200萬個(gè)測(cè)試用例，發(fā)現(xiàn)了20多個(gè)可能的問題，然后和相關(guān)stakeholder討論。 從上面的例子可以看到，Test Automation其實(shí)完全不受限于CI這種模式的下的測(cè)試，完全可以借助自動(dòng)化測(cè)試的手段來做Exploratory Testing. 第二：CI中的測(cè)試一定要保證測(cè)試的全覆蓋。 首先，測(cè)試的全覆蓋本來就是一個(gè)偽命題，從來也沒有一種測(cè)試可以做到全覆蓋。測(cè)試人員要解決的是在測(cè)試設(shè)備有限，測(cè)試人員有限，測(cè)試時(shí)間也有限的情況下，如何能夠讓組織在測(cè)試的投入上，達(dá)到最高的ROI。 然后回到CI，我們來看一下CI的目的到底是什么。 在傳統(tǒng)的開發(fā)模式下，軟件組織在Integration的時(shí)候往往會(huì)發(fā)現(xiàn)模塊的接口定義或者理解有不一致，然后需要返工，甚至因此要改模塊的內(nèi)部設(shè)計(jì)。在各個(gè)模塊都各自完成以后，想讓他們?cè)谝黄鹉芄ぷ?#xff0c;給客戶提供一個(gè)完整的功能，往往還要等待很長的時(shí)間 既然集成這么麻煩，那我們就提倡盡早集成,盡快測(cè)試，以期待盡快發(fā)現(xiàn)問題。同時(shí)開發(fā)人員在實(shí)現(xiàn)代碼的時(shí)候，如果能夠盡快給他們的實(shí)現(xiàn)提供反饋，這對(duì)他們避免在后來的開發(fā)中犯同樣的錯(cuò)誤，也是非常重要的。如果這種反饋的成本比較低，那我們就可以讓這種反饋盡可能頻繁。 具體來說，如果讓盡可能多的測(cè)試都自動(dòng)化了，那我們?cè)诮档头答伒某杀旧暇妥叱隽说谝徊?#xff0c;也是非常重要的一步。 但是大家要思考一下，反饋的速度，頻率和反饋的價(jià)值是不是完全等同？ 開發(fā)人員的開發(fā)過程其實(shí)就是一個(gè)不斷犯錯(cuò)誤，又不斷糾正的過程。 比如說IDE會(huì)頻繁告訴他們的一些語法錯(cuò)誤，然后在編譯鏈接的時(shí)候又會(huì)發(fā)現(xiàn)一些問題，然后在執(zhí)行UT的時(shí)候又會(huì)發(fā)現(xiàn)一些問題，然后在后面的Smoke Testing，Function Testing，System Testing又會(huì)得到一些反饋，然后從最終的客戶那里會(huì)得到更進(jìn)一步的反饋。 隨著軟件技術(shù)的發(fā)展，比如更好的IDE，更好的UT，更好的自動(dòng)化測(cè)試，開發(fā)人員在不斷地降低得到反饋的成本，提高反饋的效率。但是，我們可以問問周邊的開發(fā)人員，特別是那些資深的開發(fā)人員，在他們的開發(fā)生涯中，讓他們印象最深的一個(gè)Bug，是怎么發(fā)現(xiàn)的？ 我會(huì)懷疑讓開發(fā)人員得到的一個(gè)印象很深的Bug，一個(gè)真正有價(jià)值的反饋，往往是一個(gè)好的測(cè)試人員給他的。 在我們的組織里，一個(gè)好的測(cè)試人員是很受開發(fā)人員尊重的，因?yàn)樗还夤馐前l(fā)現(xiàn)產(chǎn)品Bug那么簡單，他還不斷地給開發(fā)人員提供有價(jià)值的反饋，不斷地讓開發(fā)人員以該更加周全思路來考慮問題，也促使開發(fā)人員不斷地成長。
但是CI模式下完全依賴機(jī)器的執(zhí)行，不強(qiáng)調(diào)人的介入的自動(dòng)化測(cè)試，會(huì)是給開發(fā)人員提供反饋的唯一途徑嗎？ 通過我們的經(jīng)驗(yàn)來看： 1. 有些team抱怨這種模式的測(cè)試，我們也叫CRT( Continuous Regression Test)基本發(fā)現(xiàn)不了軟件問題。 2. 個(gè)別Team的經(jīng)驗(yàn)是CRT可以幫助他們發(fā)現(xiàn)很多問題，但估計(jì)和模塊工作的領(lǐng)域有關(guān)，比如該模塊本身就是問題比較多的模塊。 3.即便是上述第2種情況的模塊，也發(fā)現(xiàn)許多軟件深層次的問題，比如一些設(shè)計(jì)上考慮不太周到的地方，往往也是一些Senior Tester才能發(fā)現(xiàn)的。 4.往往一個(gè)測(cè)試中發(fā)現(xiàn)的問題，在另外一些測(cè)試用例里面會(huì)被重復(fù)發(fā)現(xiàn)。意味著我們的測(cè)試用例發(fā)現(xiàn)問題的能力往往是有冗余的。

在這種情況下，再強(qiáng)調(diào)在CI的模式下要保證測(cè)試的全覆蓋，我們來看一下會(huì)給我們帶來什么。 首先，你的測(cè)試用例越加越多，你的測(cè)試周期勢(shì)必越來越長，也就無法給他們提供及時(shí)的反饋。而CI的精華之一就是強(qiáng)調(diào)給開發(fā)人員提供及時(shí)的反饋。 其二, 如果你考慮并行測(cè)試的話，勢(shì)必要增大測(cè)試設(shè)備的投入。在電信領(lǐng)域，測(cè)試設(shè)備往往是很貴的，往往比請(qǐng)幾個(gè)測(cè)試人員還貴。當(dāng)你的自動(dòng)化測(cè)試不能持續(xù)給開發(fā)人員提供有價(jià)值和有深度的反饋，你還不斷要求管理層給你加大測(cè)試的投入，往往也是不現(xiàn)實(shí)的。根據(jù)我們的經(jīng)驗(yàn)，很多采用靜態(tài)測(cè)試技術(shù)的自動(dòng)化項(xiàng)目，往往都會(huì)碰到類似的問題。
所以CI天生是用來解決Integration的問題的，因?yàn)镮ntegration給軟件開發(fā)帶來了很多的問題，是開發(fā)工作中很大的一個(gè)bottleneck，所以采取了Continuous Integration的方式去做。而Test Coverage則是測(cè)試中另外一個(gè)很難解決的問題，意指在測(cè)試階段盡可能保證全面的測(cè)試覆蓋，以避免軟件Deploy到客戶現(xiàn)場，被客戶發(fā)現(xiàn)問題。CI作為一種很好的Practice，應(yīng)該被我們很好地應(yīng)用，但是如果片面追求CI的Test Coverage，反而有可能會(huì)喪失掉CI本身的優(yōu)勢(shì)。

轉(zhuǎn)載于:https://www.cnblogs.com/blue_energy/archive/2012/03/01/2374897.html

總結(jié)

以上是生活随笔為你收集整理的谈自动化测试与CI中一些常见的谬见的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。