【話題討論+送書福利】敏捷開發(fā)過程中如何提升測試的效能？

飄絮絮絮丶

獲獎用戶：

2樓    renxiao2003      @renxiao2003
4樓    東風(fēng)玖哥            @東風(fēng)玖哥
6樓    forgaoqiang       @forgaoqiang
7樓    ylky_2000         @ylky_2000
8樓    aloki                 @aloki
10樓   Fl_wolf            @Fl_wolf

及時站內(nèi)短信聯(lián)系我哦~

話題背景：  
  
     目前大部分軟件開發(fā)團隊使用敏捷開發(fā)模式進行日常開發(fā)。敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都要經(jīng)過測試，具備交付客戶或上線的可能性。在敏捷開發(fā)過程中，迭代版本周期短與迭代版本數(shù)量多，試想如果通過傳統(tǒng)的手工測試來保證產(chǎn)品質(zhì)量，將面臨測試問題多與壓力巨大的情況。因此在敏捷開發(fā)過程中對測試的要求越來越高，傳統(tǒng)的手工測試肯定是不能滿足測試要求的。測試如何與敏捷開發(fā)中的快迭代、快產(chǎn)出相匹配呢？那就需要自動化測試的介入。敏捷開發(fā)過程中，科學(xué)合理地開展自動化測試，能夠有效提升測試效率，縮短測試周期，讓產(chǎn)品變得更可靠，讓測試工程師的工作效率值得到提升，減輕測試工程師壓力，從而讓他們更加專注于更有價值的工作。
    為了幫助各位測試工程師快速掌握自動化測試的相關(guān)技術(shù)和方法，機械工業(yè)出版社近期出版了《從零開始學(xué)Selenium自動化測試（基于Python•視頻教學(xué)版）》一書。該書重點討論了自動化測試過程需要掌握的技能和方法，以及當(dāng)前主流的單元測試框架和自動化框架的設(shè)計與實現(xiàn)。本次活動便是以此為契機，和各位測試工程師就自動化測試的相關(guān)話題展開討論，歡迎大家踴躍發(fā)言。

本次話題:

1.敏捷開發(fā)過程中開展自動化測試的先決條件有哪些？
2.敏捷測試中的分層自動化測試如何開展？
3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？


嘉賓介紹：

李曉鵬  國家軟件評測師、微軟最有價值專家（MVP）、OCP、51CTO博客專家。目前在某互聯(lián)網(wǎng)公司任職項目總監(jiān)。從事軟件測試工作10余年，在軟件測試流程設(shè)計與優(yōu)化、自動化測試（Selenium和UFT等）及性能優(yōu)化等領(lǐng)域有多年的項目實戰(zhàn)經(jīng)驗，參與和主持了多個大型測試項目，并出版了相關(guān)書籍。在IT教育領(lǐng)域踐行“視頻教學(xué)+網(wǎng)絡(luò)解答”的模式，降低了學(xué)員的學(xué)習(xí)成本，帶領(lǐng)廣大測試技術(shù)愛好者不斷成長。


本期獎品：

最佳積極參與經(jīng)驗分享獎5名，獎勵價值99元的《從零開始學(xué)Selenium自動化測試（基于Python•視頻教學(xué)版）》圖書1本。
從零開始學(xué)Selenium自動化測試（基于Python?視頻教學(xué)版）
李曉鵬  夜無雪  著
書號：978-7-111-67003-2
印張：20.5（共328頁）
定價：99.00元
上架建議：計算機/軟件測試


參與方式：

直接在該主題下回帖即可。

活動時間：2021年3月30日-2021年4月25日

圖書購買：

京東：https://item.jd.com/12784287.html
當(dāng)當(dāng)：http://product.dangdang.com/29177828.html


圖書試讀：簡介+前言+目錄    第1、2、5章（試讀） 前言+目錄.pdf (531.45 KB, 下載次數(shù): 56)

2021-03-30 09:59 上傳

點擊文件名下載附件

第5章.pdf (3.67 MB, 下載次數(shù): 62)

2021-03-30 09:59 上傳

點擊文件名下載附件

第1-2章.pdf (1.41 MB, 下載次數(shù): 60)

2021-03-30 09:59 上傳

點擊文件名下載附件

renxiao2003

沙發(fā)坐起。
1.敏捷開發(fā)過程中開展自動化測試的先決條件有哪些？
CSDN觀點1（針對普通自動化測試）：
a、  自動化測試是長期的，只有長期的，多次重復(fù)的測試才能發(fā)揮自動化測試的作用。
b、  要有足夠的資源，包括人員和技能。保證腳本的開發(fā)和維護。
c、  確保軟件的成熟穩(wěn)定。
CSDN觀點2（針對敏捷下的自動化測試）：
a、對于自動化工程師的要求更高，除了解決種種突發(fā)異常的自動化技能以外，還需要對項目的業(yè)務(wù)知識有比較多的了解。
　　在敏捷模式中，文檔不會像傳統(tǒng)的模式中那樣完備，測試的case可能會相對簡易，不少內(nèi)容都只是口口相傳，敏捷團隊的成員也不可能專門派一個人出來輔助自動化工程師解決業(yè)務(wù)問題，那么就要求自動化工程師對于業(yè)務(wù)知識比較了解了，就算對項目了解有限，但至少要有背景知識，大多數(shù)情況下能理解一句話中所包含甚至是隱含的一系列業(yè)務(wù)操作。
b、項目成員結(jié)構(gòu)上，自動化工程師需要成為敏捷團隊的一員，而不是編外人士。理由很簡單，敏捷團隊經(jīng)常會召開類似頭腦風(fēng)暴的會議，一個短暫而激烈的會議足以決定一個變更，然后大家立馬投入工作中。這時自動化工程師若作為編外人士，那很可能就得不到這第一手的消息了，很可能吭哧吭哧好不容易碼完的腳本還沒跑過就得改了。
c、對于項目、產(chǎn)品的要求。被測系統(tǒng)必須是非常適合自動化的，在自動化腳本開發(fā)過程中不應(yīng)當(dāng)遇到被某個技術(shù)實現(xiàn)難倒的問題，敏捷模式下是沒可能有幾天甚至一周的時間去處理某個自動化的技術(shù)細節(jié)的。這就需要在接受項目前做自動化可行性評估的時候考慮周全，是否有某些核心的功能無法被自動化，可以接受多少功能不被自動化。
　　另外各story間不能有太強的依賴，因為很可能自動化工程師無法完成對所有功能的自動化，而一個story的需求變更也不應(yīng)導(dǎo)致其它story有太多變化。
d、對于BA的要求。BA需要對產(chǎn)品的主要功能非常了解，非常清楚哪些功能是不太會變更，而哪些部分是不太有把握的，同時對客戶也要有一定的掌控能力。這樣除了提供主要的測試點以外，還能結(jié)合變更來給同為最高級別的測試點附加上自動化優(yōu)先級，在很大的程度上避免自動化工程師的重復(fù)勞動。
　　總的來說，要實施自動化，對團隊的成員素質(zhì)要求非常高，也要求成員間的配合比較默契。說實話，真的很難，但并不是不可實現(xiàn)。
51testing觀點：
　1）軟件需求變動不頻繁。
　　進行測試時能發(fā)現(xiàn)Bug可以提高測試人員的自信心。在自動化測試的執(zhí)行過程中，如果被測軟件不穩(wěn)定，可能會導(dǎo)致自動化測試失敗，出現(xiàn)崩潰性錯誤，這會極大地打擊自動化測試執(zhí)行人員的自信心。
　　2）項目周期足夠長。
　　這一點我們在前面已經(jīng)討論過了，此處不再贅述。
　　3）產(chǎn)品結(jié)構(gòu)相對復(fù)雜。
　　對于產(chǎn)品結(jié)構(gòu)相對復(fù)雜的軟件建議采用自動化測試。
　　4）資源投入相對充裕。
　　對于人力及財力資源相對充足的項目使用自動化測試。
　　5）測試時間相對長，且存在大量需要執(zhí)行回歸測試的軟件項目。
　　對于整個項目周期較短的測試，使用自動化測試會入不敷出。
　　6）待測軟件系統(tǒng)界面基本穩(wěn)定，沒有較大的功能上的更改。
　　一定要等到待測軟件系統(tǒng)界面基本穩(wěn)定時，才能使用自動化測試工具進行功能、性能等測試。

2.敏捷測試中的分層自動化測試如何開展？
CSDN觀點1（針對普通自動化測試）：
a、  選取適合的項目
b、  選取適當(dāng)?shù)臅r間，太早軟件不成熟，變化太多，太晚影響項目進度。
c、  選擇合適的測試人員
d、  做好成本預(yù)算
CSDN觀點2（針對敏捷下的自動化測試）：
a、需求，需求通常來自于PM，在一個release周期的開始，QA通常沒太多事情需要做，比較重要的工作就是跟PM溝通當(dāng)前feature的一些情況，在這個時候，QA可以做一些自動化測試的準備。例如在某個release里面我知道在接下來的測試當(dāng)中我需要頻繁地比較CSV文件，那么作為QA就應(yīng)該在項目還不是很緊張的時候就開支準備自動化測試的腳本，例如剛才說的這個CSV文件比較工作
b、開始開發(fā)，如果公司是實時TDD開發(fā)，那么這個時候QA可以做的事情大概有2個，幫助開發(fā)寫單元測試用例，并且實施自動化測試（主要是單元測試），另一個是review（雖然不是自動化測試的內(nèi)容）
c、正式提交測試，OK，這個時候是我們QA比較忙的時候了，這時候很有可能出現(xiàn)幾個情況，1. 跟我的預(yù)想一樣，我真的需要一個CSV文件比較工作，并且只需要這一個工具，并且我已經(jīng)完成了，那么就可以進行測試了。2. 可能有一些新的自動化測試需求跑出來了，例如每天晚上自動比較幾萬個CSV文件并且把測試結(jié)果發(fā)給相關(guān)的人，這時候作為QA，在考慮資源允許的情況下，應(yīng)該盡早完成這個工具，而不是每天晚上爬起來看結(jié)果并非法郵件
c、發(fā)布完畢以后，回過頭來看工具，是否有值得改進的地方，是否能夠改進一下就能夠給整個Team使用

3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
個人感覺不是。
　敏捷開發(fā)也是開發(fā)，產(chǎn)品不是孫悟空，不會某一天就從石頭里面爆出來了。在產(chǎn)品開發(fā)的前期（例如0.1, 0.2版本之類），盡可能地想辦法搭建一個自動化回歸測試的框架，這個框架的特點有：1. 快速完成回歸測試； 2.能夠快速地添加測試用例并且跑起來；3.能夠隨著產(chǎn)品的演化而不斷改進（不能是那種用1~2個release就要扔的東西）；4.維護的成本要低（在一個release周期里面如果自動化測試需求有變化，不應(yīng)該需要超過1個星期的時間才能改好，當(dāng)然翻天覆地的變化除外）
a、至少一個自動化回歸測試框架，保證release前能夠?qū)Ξa(chǎn)品進行覆蓋較為全面的回歸測試
b、工作中*不斷地*開發(fā)自動化測試工具，提高自己的生產(chǎn)率   

4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？
下面觀點來自網(wǎng)絡(luò)：
對自動化測試金字塔結(jié)構(gòu)的解讀可以分為以下幾個方面：
    越下層投入應(yīng)當(dāng)越多，這是金字塔結(jié)構(gòu)主要提出的觀點，認為單元測試的穩(wěn)定性和投入保證了產(chǎn)品質(zhì)量；
    越下層效率會越高，因為軟件的漏洞最終是落在具體的程序代碼上的，所以底層的測試效率是最容易發(fā)現(xiàn)和修改錯誤（BUG）的；
    越下層成本會越低，因為底層代碼測試進行的最早，此時發(fā)現(xiàn)錯誤修改起來較為容易，牽連的其他內(nèi)容也很少，越向上再發(fā)現(xiàn)問題往往需要修改的代碼量會成倍增多，所以說下層測試和修改的各項成本都是相對低的；
    越下層實現(xiàn)專業(yè)性要求越高，雖然底層的修改是直接且容易的，但是這是基于擁有經(jīng)驗豐富的程序員或測試員的前提下，高度的專業(yè)性意味著人才的需求和人力成本的提高。

與UI測試的區(qū)別
    接口測試比UI測試更容易發(fā)現(xiàn)底層問題。
    接口測試的介入時間可以比UI測試更早，更容易提前發(fā)現(xiàn)問題。

接口測試的介入時間
    只要接口開發(fā)好了，就可以進行接口測試了。
    建議：
    如果時間允許，至少應(yīng)該進行一輪以上的接口測試，以檢測底層問題。
    只要后端控制好了，剩下的問題就都是前端的了，更方便定位問題。
    如果繞過前端直接往接口發(fā)送非法數(shù)據(jù)，接口是否有相應(yīng)的處理措施，這是很重要的測試點。

oyzx_sp

大力支持，踴躍發(fā)言。

東風(fēng)玖哥

1.敏捷開發(fā)過程中開展自動化測試的先決條件有哪些？
（1）自動化測試是長期的，只有長期的，多次重復(fù)的測試才能發(fā)揮自動化測試的作用。
（2）要有足夠的資源，包括人員和技能。保證腳本的開發(fā)和維護。
（3）確保軟件的成熟穩(wěn)定。

2.敏捷測試中的分層自動化測試如何開展？
（1）選取適合的項目
（2）選取適當(dāng)?shù)臅r間，太早則軟件不成熟，變化太多；太晚則影響項目進度。
（3）選擇合適的測試人員
（4）做好成本預(yù)算
3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
不是，自動化測試用例的覆蓋對全面開展自動化測試太過保守。對于一個項目來說，應(yīng)該是有一個合理的自動化測試覆蓋區(qū)間，甚至可以僅僅用自動化測試覆蓋冒煙測試，最多不要超過90%。
4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？
一個合理的分層自動化接口測試和UI測試框架是由一個或多個自動化測試基礎(chǔ)模塊、管理模塊、統(tǒng)計模塊等組成的工具集合。應(yīng)該至少包含測試對象、測試組件、基礎(chǔ)類和函數(shù)工具類、測試數(shù)據(jù)、異常處理、測試日志、斷言和測試報告等模塊。設(shè)計自動化測試框架要注意高內(nèi)聚低耦合、腳本分離、腳本可復(fù)用等等。

seesea2517

地板坐一下。

forgaoqiang

z占坑 先讀試讀 這次的活動書籍有300來頁不算長，試讀部分內(nèi)容較少，提供3個章節(jié)
從目錄來看，本書的主要結(jié)構(gòu)是：
1）自動化測試的一些基礎(chǔ)概念
2）Selenium（硒）的基礎(chǔ)內(nèi)容 + 如何安裝，以及開發(fā)IDE PyCharm的內(nèi)容（IDEA一家的產(chǎn)品，好使）
3）元素定位和WebDriver的API使用，單元測試
4）高級話題（不乏docker容器的使用）

第一/二章節(jié)）
自動化測試是程序化的測試，有很多工具可以實現(xiàn)，個人使用的是LoadRunner和Jmeter，為什么使用自動化測試
1）重復(fù)、繁雜
2）周期短，人工操作復(fù)雜
3）需要快速出結(jié)果

自動化測試的使用場景：
1）人工手動測試一次還是必要的
2）新版本的測試就可以開始自動化測試
3）自動化測試第一次編寫程序麻煩，一旦完成，后續(xù)就會很輕松（AOT還是JIT的爭論）
4）另外Selenium免費的特性更是吸引人

第五章節(jié)）元素的定位
不同的瀏覽器有著細微差距，比較常用的chrome和firefox也有不同，web元素定位通過 selenium提供的 find_element_by_id/name/class_name/xpath/tag_name/css_selector/link_text 更像是jquery或者爬蟲引擎，找到對應(yīng)的元素。
對于ID定位是最常用的方法，對應(yīng)著元素的id，是CSS精準匹配常用的方法，這一章節(jié)分別就這幾種定位方式進行了講解（理論上會CSS的人都能很容易看懂）

——————————————————————————————分割線--------------------------------------------------------------------------------------------------
1.敏捷開發(fā)過程中開展自動化測試的先決條件有哪些？
1）大量重復(fù)的測試工作
2）有著明確的返回結(jié)果
3）目前web應(yīng)用和APP比較適合，桌面圖形化應(yīng)用自動化測試并不適用
4）軟件版本有足夠多的更新，自動測試編寫樣例比手工測試合適。

2.敏捷測試中的分層自動化測試如何開展？
敏捷開發(fā)講究多迭代，快速開發(fā)，分層主要根據(jù)系統(tǒng)層次：
（1）測試用例層，表達應(yīng)用程序的測試邏輯。
（2）領(lǐng)域?qū)樱?用業(yè)務(wù)領(lǐng)域術(shù)語來給待測系統(tǒng)建模，封裝 HTTP 請求、瀏覽器控制、結(jié)果解析邏輯等，給測試用例層提供一個接口。
（3）待測系統(tǒng)層，第 2 層構(gòu)建在這一層之上。
個人認為主要在單元測試，也就是第一層次上面，確保各個單元的正常。

3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
個人認為不是這樣的，大部分項目并不能全面的自動化測試，覆蓋范圍應(yīng)該主要在一些重復(fù)性工作較多的地方，或者說位于底層單元模塊的位置，高層業(yè)務(wù)數(shù)量少，更適合人工來進行。
需要平衡人工和自動化測試，一些復(fù)雜的高層業(yè)務(wù)邏輯需要編寫復(fù)雜的測試用例，特別是一些容易發(fā)生變更的模塊，如果版本更新不頻繁，用例編程比業(yè)務(wù)編碼工作還要多反而得不償失。

4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？

話題比較高深，個人認為自動化測試更適合接口測試，對于UI因為不同的屏幕等原因，如果無法正確的定位元素，而是采用像素模擬的方式很多時候反而人工效率更高一些。
自動化測試框架和用例編寫應(yīng)該遵循自底向上的方法，從單元結(jié)構(gòu)到業(yè)務(wù)服務(wù)，再到整體系統(tǒng)。

ylky_2000

公司正在做這個工作。
感興趣。：1.開發(fā)過程中開展自動化測試的先決條件有哪些？
   一般做接口自動化都是前后端分離的，后端接口做數(shù)據(jù)檢驗
2.測試中的分層自動化測試如何開展？
   測試分三層的，單元，接口，界面
3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
   單元是開發(fā)層面要做，接口可以開發(fā)做可以測試做，整個軟件過程都要做測試，自動化主要快速回歸
這個針對產(chǎn)品成熟穩(wěn)定開展才有好效果，頻繁改動項目不適合
這個要花時間，花精力去維護，而且是長期性。不是簡單做兩下就可以出成績

4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？
   Ui很考驗頁面元素穩(wěn)定性，它的不穩(wěn)定性比接口高，維護成本更高
  自動化按目前測試劃分是測試開發(fā)方向
  不是所有做黑盒測試的測試人員就能做自動化，也要會技術(shù)，黑盒測試是技術(shù)的前提

aloki

1.敏捷開發(fā)過程中開展自動化測試的先決條件有哪些？
敏捷團隊中的測試人員主要負責(zé)執(zhí)行各種測試，以滿足“已完成”的定義，從而為團隊在重復(fù)迭代中努力交付的持續(xù)價值創(chuàng)造做出貢獻。對于測試人員來說，擁有敏捷的心態(tài)是至關(guān)重要的，如果沒有敏捷的思維方式，他們可能就不能果斷地計劃、劃分優(yōu)先級并執(zhí)行他們的任務(wù)，因此會無意中影響團隊滿足迭代目標的能力。敏捷的思維方式是測試人員展示正確行為的先決條件，這些行為能夠加速整個團隊的性能。
測試人員除了學(xué)習(xí)Selenium，UFT，Appium等新工具。還必須學(xué)習(xí)如GitLab，Jenkins，Codeship等CI / CD工具

2.敏捷測試中的分層自動化測試如何開展？
新項目中，可能由于時限原因或者開發(fā)人員習(xí)慣問題，一開始并沒有把單元測試準備得很完善；而某些遺留老項目，可能原本就沒有多少單元測試。
在上述情況下，一般的做法是先將重心放在中間層的測試上，原因有以下兩點：
第一，中間層投入產(chǎn)出比較高，可以實現(xiàn)較高的自動化率；
第二，可以幫助加強開發(fā)跟測試人員之間的協(xié)作，提高測試質(zhì)量。這一層需要開發(fā)跟測試人員共同定義，因為開發(fā)知道內(nèi)部實現(xiàn)的細節(jié)，測試掌握業(yè)務(wù)場景。

3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
做過自動化測試的同仁都應(yīng)該對“自動化測試用例能發(fā)現(xiàn)多少缺陷”這話題不陌生，業(yè)界也有很多支持“自動化測試用例主要不是用來發(fā)現(xiàn)缺陷，而是提高回歸測試效率”這個觀點的文章。即便這樣，“發(fā)現(xiàn)缺陷”也像是自動化測試人員“肉中的一根刺”，很多時候大家不愿意去觸碰它。這樣時間久了，很可能會讓自動化測試人員喪失發(fā)現(xiàn)缺陷的斗志。
“自動化測試主要不是用來發(fā)現(xiàn)缺陷”這一觀點的主要依據(jù)是“自動化測試是嚴格按照已有用例進行的自動回歸測試”。說白了就是“它每次做的事兒相同的”，所以不能像手工測試那樣依靠人的主觀能動性來發(fā)現(xiàn)新的缺陷。
“它每次做的事兒相同的”，這一點我們改變不了。
但我們能做的是在不同的場景中做“相同的事兒”！從而增加發(fā)現(xiàn)缺陷的幾率，降低軟件釋放后風(fēng)險。

4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？
接口自動化測試，主要驗證模塊間的調(diào)用返回以及不同系統(tǒng)、服務(wù)間的數(shù)據(jù)交換。接口測試自動化一般在業(yè)務(wù)邏輯層進行測試。根據(jù)接口文檔是 RESTful 還是 RPC調(diào)用被測試的接口，構(gòu)造相應(yīng)的請求數(shù)據(jù)，得到返回值，是成功或者失敗。不管輸入的參數(shù)是怎樣的，我們都將得到一個結(jié)果，最終斷言返回的結(jié)果是否等于預(yù)期結(jié)果。如果相等，測試通過；如果不相等，測試失敗。
所以，接口測試關(guān)注的是數(shù)據(jù)。只要數(shù)據(jù)正確了，功能就做成大半，剩下的無非是如何把這些數(shù)據(jù)展示在頁面上。
常見的接口測試工具有 postman、jmeter、loadrunner 等。
UI 層是用戶使用產(chǎn)品的入口，所有功能通過這一層提供給用戶，目前測試工作大多集中在這一層，這種測試更貼近用戶的行為，模擬用戶點擊了某個按鈕、在輸入框里輸入了某些指令。有時可能用戶看到登錄成功了，但 UI 自動化并不知道它剛才的點擊有沒有生效。所以要找“證據(jù)”，比如登錄成功后頁面右上角會顯示“歡迎，xxx”，這就是登錄成功的有力“證據(jù)”。當(dāng) UI 自動化登錄成功后，就去獲取這個數(shù)據(jù)進行斷言，斷言如果相等，測試通過；如果不相等，測試失敗。
所以，UI 自動化的關(guān)注點用戶操作形為，以及 UI 上各種組件是否可用。常見的測試工具有 UFT、Robot Framework、Selenium、Appium 等。
每種自動化測試都有自己的側(cè)重和優(yōu)劣勢，在實際工作中不可能做到均分，因此我們需要制定合理的測試策略對其進行組織和分配，包括每部分測試投入多少、測試用例比例是多少等。

forgaoqiang

吐槽下官網(wǎng)：


總之 WEBDriver的變化很大，使用不同版本的時候要注意區(qū)別

Fl_wolf

1.敏捷開發(fā)過程中開展自動化測試的先決條件有哪些？產(chǎn)品：是否滿足自動化測試的條件。
單元測試，回歸測試，接口測試，協(xié)議測試。

人員：人員是否具備自動化測試工具使用的基礎(chǔ)，或者是自動化測試語音基礎(chǔ)。

2.敏捷測試中的分層自動化測試如何開展？
首先可以把敏捷測試分層為各單元測試，然后判斷各單元測試是否是可重復(fù)或者可匹配的測試，
如果可以，那則可以采用自動化測試，并且根據(jù)具體的內(nèi)容進行自動化單元測試。

3.自動化測試用例的覆蓋對全面開展自動化測試是否是最優(yōu)的選擇？為什么？請做簡單論述。
這個還需根據(jù)具體的情況而定，人工測試是有主觀能動性的，而自動化測試的測試方向與離散度較為聚集，
如果不需要主管判斷的測試，當(dāng)然是采用全面覆蓋為好。


4.如何構(gòu)建分層自動化接口測試和UI測試？如何設(shè)計自動化框架？
我理解分層自動化接口其實就是把各個單元測試合并成一個整體的自動化測試集。
自動化測試框架，我司也是分為了 WEB PC與WEB PHONE 兩個方面，
針對不同的系統(tǒng)與平臺，工具也是不一致的，PC設(shè)備的可以用 UFT 、Selenium
手機端則用 airtest 。再進行分單元，分模塊去測試。