<pre id="ff7yo"></pre>

      <form id="ff7yo"><legend id="ff7yo"></legend></form>
        <nav id="ff7yo"><listing id="ff7yo"></listing></nav><nav id="ff7yo"></nav>

        <nav id="ff7yo"><listing id="ff7yo"></listing></nav>
        <small id="ff7yo"></small><nav id="ff7yo"><dd id="ff7yo"></dd></nav>
      1. <nav id="ff7yo"></nav>
          <form id="ff7yo"></form><nav id="ff7yo"></nav>
          <nav id="ff7yo"></nav>
          <sub id="ff7yo"></sub>
          更多課程 選擇中心

          軟件測試培訓
          達內IT學院

          400-111-8989

          敏捷的軟件測試 這十大誤解必須糾正

          • 發布:軟件測試培訓
          • 來源:IT168
          • 時間:2017-03-07 15:04

          敏捷方法已經獲得了越來越廣泛的應用。這是很容易理解的,特別是從開發人員與用戶的角度來看。

          1. 用戶——系統的需求與過程上的細節問題似乎永遠也問不完,然后還要仔細閱讀大量的說明文檔,而他們明白這些文檔會成為將來法庭上的證據。

          2. 開發人員——需要嚴格地遵循說明文檔而無法表達自己的想法或發揮創造性天賦。他們知道即使有更好的辦法,他們也不能更改說明文檔,否則這就會成為將來法庭上的證據。

          但是對于質量保證人員來說,敏捷方法卻會帶來麻煩——在原來的理想情況下,他們只需要用既有的說明文檔來驗證"完成"的產品。要根據一個變化的背景驗證一個活動的目標是很不直觀的。這表示所使用的技術與自動化也更復雜,并且需要一個新的測試方式,一種類似于用戶和開發人員之間的關系的方式。

          所有的敏捷方法都有(至少)一個共同的特征,那就是對QA職業的影響。如果所謂的影響是質量上的一次大飛躍,那倒也不是什么壞事。但是,如果決策是根據無效的范例做出的,改變就不一定能與過程同步了。對于開發人員來說,新提出的軟件開發范例以開發人員為中心可能是很平常的事。Abraham Maslow曾經說過:"擅長用錘子的人喜歡從釘子的角度考慮問題。"但是作為質量保證人員,我們不能裝作敏捷開發不存在的樣子,我們必須保證那些拿著錘子的人不會去硬敲一顆螺絲。

          某些人可能會對QA提出懷疑,認為測試驅動開發(TDD)才是測試的關鍵。但是,伴隨著需求和方案的發展,QA在整個過程中都是與敏捷小組直接發生聯系的,是整個測試設計團隊不可或缺的一部分。但這只是QA團隊所面臨所必須解決的眾多誤會中比較表面的一個。

          對測試的誤解

          最近看了網絡上所謂專家寫的文章,發現了一些對TDD與QA部門的誤解。本文將解釋部分誤區,并集中討論QA團隊要在敏捷的世界里獲得成功所必須解決的一些問題。

          1. "你只需要做單元測試——TDD測試已經足夠"

          對于大部分商業開發來說,根本就沒有這回事。即使是敏捷開發的強力擁護者也承認他們需要一系列的測試技術。

          TDD程序設計人員需要這些測試來驗證代碼的正確性。如果需求(測試用例)解釋錯誤,那么你構建的代碼也將無法達到目標要求。

          大多敏捷項目都會使用探索性測試方法(黑盒)來支持白盒測試,而不會認為這兩種技術只能選一。優秀的探索性測試可以在開發地過于深入之前發現開發人員所忽略的問題。

          2. "你可以重用單元測試來創建回歸測試集"

          有些TDD擁護者認為常規的下游測試(downstream testing)是多余的,因為每一行應用代碼都有對應的測試用例;他們認為重用單元測試就可以做到用戶驗收測試和回歸測試所能做到的一切。

          這聽起來挺有道理,但由于某些原因,這是不現實的:TDD中的白盒單元測試的粒度與目標與下游黑盒測試的目的是不同的。

          雖然單元測試的整體目標是保證代碼能夠實現所需的功能,但是回歸測試的目標是保證被改動的應用代碼不會產生意料外的效果。這兩個目標是不同的--比如,檢查一項屬性是否具有合法的日期格式,與檢查輸入域中是否存在所需的日期是不同的。

          3. "開發人員可以用開源工具寫測試,因此我們不需要測試人員或者自動測試工具了"

          職業測試人員實現的是與其開發同僚不同但同樣有效的作用。

          人們普遍認識到傳統的自動測試工具并不像供應商們炒作的那么有效。原始軟件的源碼和供應商的產品一樣可以改善數據庫測試環境下的效率。這是因為沒有合適的工具可以提供用戶界面測試,所以我們才把方案擴展到了這一領域;我們的傳統是有效地實施測試而不是屏幕抓取自動測試。我們開發了測試驅動,是因為在過去的二十年里傳統的供應商錯過了這個機會。

          通常,TDD項目的測試代碼至少與應用代碼一樣多,因此其本身就是應用軟件。這種測試代碼是需要在目標應用的生命周期中進行維護的。

          4. "有了單元測試就不需要手動測試了"

          手動測試是一項重復性很強的工作;成本昂貴、枯燥并且容易出錯。雖然TDD可以減少功能測試所需的手動勞動,但是它不能消除對黑盒測試(手動和自動)的需求。

          通過自動抓取測試人員的過程并記錄其鍵盤和鼠標動作,測試人員能夠騰出更多的時間來進行更有意義、更有價值的活動,比如測試難以(甚至無法)自動化的復雜場景。雖然手動測試很費時間(因此也很昂貴),但是如果因為不進行手動測試而漏掉一些錯誤,則通常意味著將來可能要付出更大的代價。

          5. "我們不再需要用戶驗收測試"

          在敏捷開發中,用戶驗收測試的定位通常是和用戶協作確定"錯誤的需求",而不是檢查功能是否與需求匹配。用戶在最開始定義需求的時候,他們是根據自己的期望值來描述的。當他們看到"活生生"的系統的時候,他們必然還會產生一些不同的、或者額外的需求。雖然敏捷方法可以減少這種事情的發生概率,但是要完全解決這種問題還是不可能的,因此我們無法回避用戶驗收測試。商業用戶的用戶界面驗證就更無法回避了,因為他們想象的可能與開發人員稍有不同。而這就得由我們來……

          6. "自動化是不可能的"

          在敏捷項目早期實現自動化通常很困難,但是隨著系統的發展和成長,某些方面已經確定,這時就該進行自動化部署了--通過自我修復腳本等處理改動。

          開始的時候,用戶與QA的所有測試幾乎都是手動的,但是如果能夠抓取并重用這些測試活動和設計,這對以后的工作了是有益的。

          自動化的時機很難掌握,因此一定要使用能夠先支持手動測試而后可以將其發展為自動測試的工具。

          7. "開發人員都有足夠的測試技能"

          前提是測試簡單到所有人都可以做,并且每次提交的代碼都是完美的。可惜,許多企業都只在開發人員的編碼技術和為他們提供最新的集成開發工具上投資,而忽視了發展他們QA團隊的測試技能,或者沒有為他們提供與開發人員同樣有效的工具。

          一個獨立的測試團隊就像一個客觀的第三方,可以清楚地看清"全局",能夠驗證可交付產品的功能與質量。雖然開發人員會盡力提供所需的系統功能,但是一個優秀的測試人員還是要客觀地提出"萬一……"之類的問題。如果你還考慮到了商業用戶測試,那你就更有可能完成一個符合要求的系統。

          最后,雖然下面的觀點可能引起爭議,我還是要說大多開發人員實際上并不想花大量的時間先寫測試再寫代碼來驗證測試。如果以下描述的協作過程,開發人員可以獲得足夠的功能測試方面的幫助,從而集中精力編寫精準、穩定的代碼。

          8. "單元測試就是設計說明書的全部"

          不管用什么開發方法,在編寫代碼之前都要想清楚需求。雖然TDD說"做得不錯"可以代表設計說明中的很大一部分已經完成,我們仍然需要考慮單元測試中的一些空白。還有其它同樣可行的方案。TDD要驗證需求采集的準確性,而他們的依據并沒有得到歷史的證明。

          用定義測試用例的方法來驗證需求的準確性與簡潔性已不是什么新概念。比如V模型,就是一種了解測試需求的有效方法--通常指功能性需求。就像TDD一樣,如果業者比較嚴格,而開發過程比較靈活,那么V模型以及其它模型就沒有辦法了。軟件工程并不像機械工程,強制順應只會浪費精力。不管你選擇了哪種方法,都要問每個用戶需求:"我怎么來測試這個?"關鍵是要在代碼構建前檢查測試用例,否則你會花費更多的時間進行代碼重構.

          通過協作對需求進行精簡以后,開發人員就可以拿到一份比較穩定的說明文檔,這份文檔可能會較少地發生變動,因為它已經經過了多方面的評定。

          9. "TDD適應于任何項目"

          隨著項目規模的增大,進行測試的時間也越來越長。這個問題可以用對項目和/或測試進行劃塊的方法解決。無論哪種方法都會產生要根據其與當前代碼的相關度運行的測試。這導致了對測試計劃和執行管理需求。為了獲得較高的效率,除了白盒測試,你還需要考慮:

          集成測試——"我需要哪些測試來保證新代碼與其它代碼能夠無縫合作?"

          系統測試——"新代碼支持的功能與系統或其它系統的功能結合密切嗎?"

          回歸測試——"為了保證新代碼不會產生不可預料的反作用,我需要以多大的頻率運行回歸測試?"自動回歸測試可以有效地驗證敏捷開發技術。

          用戶驗收測試——"雖然TDD(與業務用戶協作)可以保證某個特定的功能能夠正常工作,但是經過各種各樣的變動之后,累積的影響還能被用戶接受嗎?"

          然而,在今天的環境下是無法將這些測試階段當作一系列獨立的活動的。通常,每次我們加入新代碼的時候,就需要同步進行這些測試。隨著項目團隊(及測試)規模的擴大,測試也變得無法"自我描述(self-documenting)"。項目的參與人越多,項目就越容易受到各種對說明文檔的不同解釋的影響--對這些定義的誤解正是導致失敗的原因。

          隨著項目規模的增大,需要編寫的測試代碼也就越多。任何測試代碼都需要在應用的整個生命周期中得到支持--這極大地增加了維護的難度。

          隨著測試負擔的提高,項目需要增加自動測試來最小化人力干預并減少進行這些測試所需的時間。

          10. "開發人員與測試人員,是油與水的關系"

          開發人員與測試人員自誕生之初就是"他們與我們"的關系。這通常是一種健康的共生關系。如果處理得當,兩個團隊之間互助的關系可以為客戶提供更高質量的產品。

          應該重點討論的是:

          ·滿足業務目標的軟件交付(滿足要求、及時、并且控制在預算內),而不是誰控制過程中的哪一部分。

          ·需求采集階段測試人員怎樣參與到TDD過程中?

          ·測試人員如何最大程度地重用開發階段中創建的資產?

          ·TDD中有沒有"傳統的測試人員"?他們(就像開發人員)是否應該學習新技能以適應新的范例?

          ·測試人員與開發人員在利用先進的軟件開發和測試工具的時候如何發揮互助的作用?

          正如開發人員的軟件工具和方法使開發方式發生了轉變一樣,下一代自動測試工具也為測試人員帶來了新的機遇,使他們可以在交付周期中更早地進行自動測試而不會遇到傳統的自動測試工具所帶來的繁重的腳本維護負擔。

          總結

          敏捷項目實際上是讓QA部門引領敏捷過程的好機會——沒有人比他們能更好地將用戶與開發人員聯系到一起、了解兩者的要求、滿足他們的要求并保證在部署之前完成所有工作。QA除了要繼續保證整個系統的進展能夠滿足業務目標并符合要求,他們還應該在決定結果及怎么做上有優先權利。這需要QA人員能夠靈活應變,拋棄原有的范例并集中精力研究技術以獲得最優的測試方法。

          預約申請免費試聽課

          填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

          上一篇:2016年軟件測試從業人員調查報告新鮮出爐
          下一篇:軟件測試工程師特有的職業特點

          變革中的軟件測試——組織篇

          五種比較好Android自動化測試工具推薦

          • 掃碼領取資料

            回復關鍵字:視頻資料

            免費領取 達內課程視頻學習資料

          • 視頻學習QQ群

            添加QQ群:1143617948

            免費領取達內課程視頻學習資料

          Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

          選擇城市和中心
          黑龍江省

          吉林省

          河北省

          陜西省

          湖南省

          貴州省

          云南省

          廣西省

          海南省

          神马影院-战旗影院-首播影院-新视觉影院-在线观看中文字幕dvd播放 百度 好搜 搜狗
          <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>