真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

關于軟件測試

自己記隨筆,反正寫的好不好不重要,重要的是找個地方放著,還有朋友可以看到,喜歡的呢,開心一下,不喜歡的可以拍磚~

1、關于測試的殺蟲劑效應

? ? ? ? 最近看到的這個詞,可能有點落伍,但覺得很有道理,當一個測試和一個開發(fā)團隊合作時間很長,就像同一款農(nóng)藥對農(nóng)作物上面的害蟲的效果,最開始的時候鋒芒畢露,有奇效,慢慢的效果會越來越差,也就是害蟲知道了殺蟲劑的弱點在哪,盲區(qū)在哪,因而產(chǎn)生了耐受性,免疫殺蟲劑。測試就像殺蟲劑,想去去除開發(fā)出來的軟件上面的蟲子(bug),而長時間的一直合作,測試同學的手法、思維方式會在一定區(qū)間內禁錮,使得這個區(qū)間之外的bug不容易被看到,事實上這個問題也不是不能解,借鑒農(nóng)藥的例子,也許可以想一下:

創(chuàng)新互聯(lián)公司是專業(yè)的劍閣網(wǎng)站建設公司,劍閣接單;提供成都做網(wǎng)站、成都網(wǎng)站設計,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行劍閣網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

  1. 換別的牌子的農(nóng)藥,也就是測試崗輪換,每個人的思維方式不同,每個人的盲區(qū)也不同,這個時候輪換可以將重疊的部分加固,盲區(qū)部分被一點點發(fā)現(xiàn),相輔相成互相溝通,可成活水。

  2. 農(nóng)藥升級,修改配方,也就是測試同學通過各種途徑,拓展自己的視野和思路,試著消滅自己的盲區(qū),這個拓展和提高不僅局限于技術,還包括思考方式以及對業(yè)務核心的理解等。

  3. 多用集中不同農(nóng)藥,也就是交叉測試,跟換品牌農(nóng)藥差不多一個意思,多種不同的覆蓋面,會讓盲區(qū)變得小,但也可能會導致副作用,比如耗時會比較長,ROI低。

  4. 提升農(nóng)藥濃度,也就是加大測試密度和強度,這樣也可以解決一部分盲區(qū),一些耐受力不強的蟲子會被去掉,但也有弊端,比如ROI低,高密度和強度會使頑固的bug更加頑固,還會使降低工作積極性和成就感。

2.關于測試的逆向思考

? ? ? ?我們一直在做自動化覆蓋的核心思路是:“我來看看系統(tǒng)是不是有bug,是不是和之前不一樣了”,就像有一條路,有一個機器人按照既定路線往前走,看看原來平坦的地方是否有坑了。

? ? ? ?按照這個思路再拓展一下,另一個核心思路也許是“系統(tǒng)里現(xiàn)在可以確認有1個bug,能不能找到”,就像有一條路,現(xiàn)在明確了有1個坑,這個機器人按照它既定的路線走,能否找到這個坑。

? ? ? ?再按照這個思路往下想想,發(fā)現(xiàn)也許也可以這么想

  • 系統(tǒng)里現(xiàn)在有1-10個bug,能不能都找到

  • 系統(tǒng)里現(xiàn)在有至少10個bug,能找到多少

  • 系統(tǒng)里面有1個關于數(shù)字格式化的bug,能不能找到

  • 系統(tǒng)里面有1個關于數(shù)字格式化的bug,有1個空指針bug,能不能找到

  • 系統(tǒng)里有3個類型的bug各2個,能不能都找到

  • ...

? ? ? ?想了想,今年云棲大會上有人的分享了一個思路,修改被測代碼、用AOP等手段注入故障或者修改運行時數(shù)據(jù),以此來檢查測試用例有效性,也就是說,不再是從未知的一片漆黑中找坑,而是制造明確的1個或者多個坑,看看我們的用例是否能找得到。

? ? ? ?這個思路可以做的事情其實還挺多的,也是對于測試同學對業(yè)務代碼的理解要求更高了一層,需要能夠通曉業(yè)務代碼,并且有模擬故障模擬bug的能力,然后以此去測試自己的自動化的覆蓋能力,也許這就是有同學曾經(jīng)問過,但至今不知道怎么回答的那個問題:

“你用自動化去測試業(yè)務系統(tǒng),那用什么來測試你的自動化呢?”

現(xiàn)在這個問題也許可以這么回答:“用自動化的斷言測業(yè)務系統(tǒng),用業(yè)務系統(tǒng)的bug測自動化,測開閉環(huán),相輔相成”

3.用開發(fā)業(yè)務系統(tǒng)的思路寫自動化測試用例

? ? ? ?我們測試業(yè)務系統(tǒng)的時候,從單元考慮到接口考慮ui然后考慮大qps考慮多并發(fā),考慮容錯考慮異常處理,考慮監(jiān)控考慮.....

? ? ? ?設計自動化測試的用例的時候,也許也應該試試能不能這么做,比如:

  • 單元能力封裝,可能是接口,可能是數(shù)據(jù)準備,每個單元可以單獨運行,可以復用

  • 單元能力編排成流程,可能是接口-接口-數(shù)據(jù)可能是數(shù)據(jù)-數(shù)據(jù)-接口,每個編排可以單獨運行,可以復用,比如編排成提交流程、發(fā)起審批流程、審批通過流程

  • 流程編排成業(yè)務,可能是提交-審批-通過可能是提交-審批-拒絕

  • 考慮并發(fā)問題,單個用例多觸發(fā),同時觸發(fā)運行

  • 單元用例,也是需要測試的輸入--運行--輸出--斷言,就像業(yè)務代碼中的1個方法一樣。

  • 把自己業(yè)務線的自動化用例封裝成一套以單元用例、單元流程、單元業(yè)務組成的一套有層次有驗證側重點的框架,比如單元用例主要校驗單個接口或者數(shù)據(jù)準備的健壯性、可靠性、正確性等等,單元流程用例主要通過每個單元用例吐出的數(shù)據(jù)進行業(yè)務流程串聯(lián),以驗證單個流程【或者某頁面,1個頁面的渲染需要很多接口同時生效】正確性,業(yè)務用例主要通過各流程的能力串聯(lián)完成完整的業(yè)務,驗證業(yè)務正確性。

  • 以接口為單位封裝單元用例,以頁面為單位封裝流程用例,以頁面操作步驟為單位封裝業(yè)務用例,大致思路如是。

4.關于自動化測試

  • 數(shù)據(jù)構造類自動化,核心目的是構造測試數(shù)據(jù),如果能構造出來預期數(shù)據(jù),代表其中的各個環(huán)節(jié)、接口是ok的,順帶驗證了功能,作用是人工測試可以替代的。

  • 業(yè)務驗證類自動化,核心目的是驗證業(yè)務功能,大約需要3個基本板塊,作用是人工測試可以替代的。這一類自動化,被數(shù)據(jù)、環(huán)境問題嚴重干擾其穩(wěn)定性和結果可信性。

    • 數(shù)據(jù)構造,用于給后續(xù)的流程生成將要驗證的數(shù)據(jù)

    • 執(zhí)行驗證,通過既定數(shù)據(jù),進行相關業(yè)務邏輯操作,驗證正確性

    • 數(shù)據(jù)銷毀,將構造的數(shù)據(jù)、執(zhí)行后產(chǎn)生的臨時數(shù)據(jù)、垃圾數(shù)據(jù)進行銷毀,保證自動化的清潔。

  • 必要自動化,核心目的是完成一些必要的枚舉和排列組合的相關驗證,其作用是人工測試無法替代的。

? ? ? ? 業(yè)務驗證類自動化,多數(shù)是以驗證業(yè)務完整性為準繩,這類自動化核心邏輯是“它本來應該是這樣的,等下次我再跑的時候,看看它還是不是這樣”,對于bug發(fā)現(xiàn)能力其實相對較弱,必要自動化能很大程度上發(fā)現(xiàn)排列組合各種極限場景的bug,但需要這種自動化的場景也較少,數(shù)據(jù)類自動化,其發(fā)現(xiàn)問題的能力、發(fā)現(xiàn)bug的能力都是最弱的,但對于手工測試的提效是最為明顯的。

  • UI自動化

    • 前端是最貼近用戶使用習慣,用戶對系統(tǒng)能力的直觀感認知,直接決定用戶對系統(tǒng)的評價

    • UI自動化的穩(wěn)定性、可靠性、ROI一直是阻礙這個其實最應該沖在業(yè)務最前沿猛士的核心原因。

  • 接口自動化

    • 服務端業(yè)務邏輯的正確和健壯,是業(yè)務能夠平穩(wěn)運營的根本,也是讓業(yè)務贏的根基。直接決定對業(yè)務的支撐能力和擴展能力。

    • 接口自動化相對于UI,更穩(wěn)定,能驗證的點更多,更深入,更容易發(fā)現(xiàn)服務端業(yè)務邏輯的問題,保證業(yè)務核心邏輯的正確完整

  • 單元測試

    • 單元邏輯的正確和健壯,直接決定了由單元拼裝起來的接口、業(yè)務的能力,是整個工程健壯、穩(wěn)定、擴展性的基石。

    • 單元測試相對于接口自動化,極穩(wěn)定,一般都與業(yè)務在同一工程,驗證顆粒度更細,驗證更全面、深入,更能發(fā)現(xiàn)每個邏輯單元的問題,保證每個邏輯單元基礎的正確、完整、健壯,但,目前單元測試難于推進,實施難度相當大,增加開發(fā)時長、增加項目時長,也增加工作量,因此目下多數(shù)應用都沒有鋪設單元測試。

  • 安全測試

    • 試圖通過技術手段,站在***的角度,嘗試攻破系統(tǒng),類似于安全演練,挖掘更深層次的框架、或者部署架構、或者網(wǎng)絡、或者中間件等相關的bug。

    • 對專業(yè)技能要求極高,不僅對網(wǎng)絡、操作系統(tǒng)、中間件、開源框架有整體了解,更需要對當前業(yè)務系統(tǒng)的業(yè)務有深層理解和分析,甚至要比開發(fā)同學更了解業(yè)務系統(tǒng)代碼,綜合從各方面對系統(tǒng)進行全方位的專業(yè)性技術測試,保障的是系統(tǒng)的安全性

  • 性能測試

    • 通過對系統(tǒng)進行各方面的大量摧殘,去看系統(tǒng)的支撐能力、反應速度等,比如同時又10000個人在用會不會出問題,10000個人能同時用多久不出錯,最多能同時支撐多少個人用等。其實是為了保證系統(tǒng)的可用性,一個系統(tǒng)在業(yè)務能力滿分,UI設計交互等滿分的時候,如果總是不能用或者用起來很慢,那么業(yè)務能力滿分,UI設計交互等滿分這樣的好東西就會蕩然無存。

    • 對專業(yè)技能要求較高,不僅需要對系統(tǒng)的整體部署接口很了解,也需要對系統(tǒng)所采用的的框架、實現(xiàn)方案、數(shù)據(jù)庫、網(wǎng)絡結構等進行評估,還需要對業(yè)務特點進行分析,從而通過對系統(tǒng)進行各種場景的模擬,對系統(tǒng)的支撐能力進行全面評估,大致有,穩(wěn)定性測試(大并發(fā)撐很久不出問題),容量測試(系統(tǒng)最大能抗住多少并發(fā)),并發(fā)測試(某個業(yè)務被同時操作時的業(yè)務邏輯處理,增減庫存問題)。

其實無論哪種測試,當積累抽象到了一個層面時,就可以進行自動化,性能測試自動化、安全測試自動化,UI、接口等等各種自動化,甚至借助于AI可以自動生成自動化case,自動修正等等,但問題在于,當把這些東西都做成自動化了,那么就需要有一個手段來驗證自動化,否則自動化變成一個開環(huán)的東西,往往會變成“為了完成目標”,最終自動化也沒起效果,手工回歸覆蓋也不做了,從而廢棄。

5.測試【自動化測試】

? ? ? ? 斗膽說接下來的話:

? ? ? ? 業(yè)務系統(tǒng)的能力有自動化測試作為衡量手段,但自動化測試的能力卻幾無衡量手段。

  • 代碼覆蓋率,分支覆蓋率,核心業(yè)務覆蓋率,這些可以證明,測試覆蓋過,或者覆蓋了,但無法體現(xiàn)自動化的能力,譬如我加了case,但沒做斷言,覆蓋率會上去,但事實上是無效case

  • 在衡量自動化提效比例或者時長時,鮮有將維護自動化投入時間的比例、時長算進去,如果每提效5分鐘就需要維護1小時,那么就需要考量是自動化沒有必要,還是自動化有問題亟待解決

  • 單一、不閉環(huán)衡量標準很多時候會造成“為了衡量標準”!自動化測試對業(yè)務系統(tǒng)有制衡,但自動化測試卻無物制衡。

  • 試試想一想集中自動化和業(yè)務系統(tǒng)的閉環(huán)衡量方式衡量業(yè)務系統(tǒng):用自動化去卻

    • 衡量業(yè)務系統(tǒng):用自動化去確認業(yè)務系統(tǒng)某個功能或接口或前端是否符合預期。

    • 衡量自動化:用接口返回的某個功能或接口或前端不符合預期去確認自動化是否會發(fā)現(xiàn)。

  • 也許需要做的幾件事

    • 從體系化的業(yè)務場景定義出發(fā):看自動化核心驗證的是什么,保障的是什么,如果是保障業(yè)務,那么就挑核心業(yè)務、故障場景定義了的業(yè)務,在其中隨機挑選一個點進行bug注入。

    • 從用戶使用直觀感出發(fā):可以進行隨機挑選,把自己看成一個用戶,或者找到旁邊的同學,讓他看看自己在這個系統(tǒng)上會關心什么樣的功能和地方,然后在這些場景里面進行隨機注入。

    • 從競技角度出發(fā):如果我是你系統(tǒng)的用戶,你是我系統(tǒng)的用戶,那么我們調過來,你把自己用我系統(tǒng)最多的地方進行注入,我也對你的系統(tǒng)做同樣的事,我們都來看一看互相的自動化是否能夠對對方關注的業(yè)務點有問題有感知能力。

    • 從紅藍角度出發(fā):開發(fā)同學在發(fā)布的時候,隨機對自己認為最重要的地方專門寫一個bug,檢查自動化測試是否能在發(fā)布后可以發(fā)現(xiàn),或者將注入能力提供給開發(fā)同學、PD、業(yè)務方,這樣的行為可以大大提高開發(fā)同學、PD、業(yè)務方對測試專業(yè)性、對自動化的認可,以及對自動化結果可信性的認可。

    • 很大一個問題是,這個bug、故障給注入到哪

    • 依然需要通過數(shù)據(jù)mock、環(huán)境探活、數(shù)據(jù)準備等手段,確保自動化運行時,需要驗證的業(yè)務邏輯所必須的條件都具備,而后需要通過技術手段或者直接改代碼(不推薦)對系統(tǒng)進行bug注入,然后執(zhí)行自動化,盡可能嘗試在一切必要條件都完備的時候,模擬系統(tǒng)出現(xiàn)了bug的情況,用這個確切已知的bug驗證自動化的能力。

    • 服務端的bug多數(shù)時候很難被用戶感知,但前端的很容易被用戶感知,因此,前端的bug注入驗證自動化能力,變得價值更高,數(shù)據(jù)返回對,但前端沒加載、數(shù)據(jù)返回不對但前端展示了、后端報錯前端沒有彈窗、前端圖標位置不正確等等。盡可能嘗試將前端這個用戶感知最明顯的地方,將自動化驗證的能力放大到像真正的用戶在進行操作。

    • 逆向方式“我系統(tǒng)今天告訴你我有bug,我倒要看看你自動化有沒有這個本事找到”?

    • 通過數(shù)據(jù)mock、環(huán)境探活、數(shù)據(jù)準備等手段,確保自動化運行時,需要驗證的業(yè)務邏輯所必須的條件都具備,嘗試盡可能將驗證業(yè)務邏輯這件事做的純粹。用自動化驗證系統(tǒng)的業(yè)務能力。

    • 通過數(shù)據(jù)清理、數(shù)據(jù)恢復,將自動化運行后產(chǎn)生的中間數(shù)據(jù)、臨時數(shù)據(jù)等進行清理,嘗試盡可能將自動化做的,我來過,看過,但不帶走一片云彩,不留下一篇垃圾。

    • 正向方式“我自動化今天要看看你這系統(tǒng)有沒有bug”?

6.還在思考,會把思考的東西都放在這里,當然,有相關實現(xiàn)和有效果的東西也會拿出來更新~



分享題目:關于軟件測試
URL網(wǎng)址:http://weahome.cn/article/gpeoej.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部