大家好,今天小編關(guān)注到一個比較有意思的話題,就是關(guān)于保險自動化設(shè)計的問題,于是小編就整理了1個相關(guān)介紹保險自動化設(shè)計的解答,讓我們一起看看吧。
1、銀行保險自動化測試流程?
在項(xiàng)目中通常情況下,在設(shè)計了測試用例并通過評審之后,由測試人員根據(jù)測試用例中描述的規(guī)程一步步執(zhí)行測試,得到實(shí)際結(jié)果與期望結(jié)果的比較。在此過程中,為了節(jié)省人力、時間或硬件**,提高測試效率,便引入了自動化測試的概念。
最初的自動化測試,是為了替***執(zhí)行重復(fù)的手動測試,主要是用于回歸測試和測試同一軟件的新版本。因此在測試前要考慮好如何對應(yīng)用程序進(jìn)行測試,例如要測試那些功能、操作步驟、輸入數(shù)據(jù)和期望的輸出數(shù)據(jù)等。
目前自動化測試的腳本編寫,通常情況是基于已有的手工用例的基礎(chǔ)上,將手工測試用例編寫成對應(yīng)的自動化腳本。
不是所有的項(xiàng)目都需要作為自動化測試項(xiàng)目,有時候手工測試可能比自動化測試反而簡單,有些時候因?yàn)榧夹g(shù)或者環(huán)境等因素,某些功能也無***實(shí)現(xiàn)自動化。
通常適合于軟件測試自動化的場合:
與手工測試相比,測試自動化的優(yōu)勢是明顯的。首先自動化測試可以提高測試效率,使測試人員更加專注于新的測試模塊的建立和開發(fā),從而提高測試覆蓋率;其次,自動化測試更便于測試資產(chǎn)的數(shù)字化管理,使得測試資產(chǎn)在整個測試生命周期內(nèi)可以得到復(fù)用,這個特點(diǎn)在功能測試和回歸測試中尤其具有意義。
通過流程圖可以看到,自動化測試流程圖和手工測試流程在測試用例編寫前基本一致,不同之處是,測試用例輸出完成后是腳本開發(fā)者開始編寫腳本,腳本編寫完成后執(zhí)行自動化測試。
在對一個項(xiàng)目開展自動化測試以前,需要對軟件需求進(jìn)行分析,以觀察其是否適合使用自動化測試。對于適合自動化測試的項(xiàng)目或者模塊開展自動化測試,對于不適合的應(yīng)該及時提出。
可以開展自動化測試,通常需要同時滿足以下條件:
需求的穩(wěn)定性決定了自動化腳本的維護(hù)成本。如果軟件需求變動過于頻繁,測試人員需要根據(jù)變動的需求來更新測試用例以及相關(guān)的測試腳本,而腳本的維護(hù)本身就是一個***碼開發(fā)的過程,需要修改、調(diào)試,必要的時候還要修改自動化測試的框架,如果所花費(fèi)的成本不低于利用其節(jié)省的測試成本,那么使用自動化測試將沒有任何意義。
項(xiàng)目中的某些模塊相對穩(wěn)定,而某些模塊需求變動性很大。我們便可對相對穩(wěn)定的模塊進(jìn)行自動化測試,而變動較大的仍是用手工測試。
自動化測試需求的確定、自動化測試框架的設(shè)計、測試腳本的編寫與調(diào)試均需要相當(dāng)長的時間來完成,這樣的過程本身就是一個測試軟件的開發(fā)過程,需要較長的時間來完成。如果項(xiàng)目的周期比較短,沒有足夠的時間去支持這樣一個過程,那么將沒有必要引入自動化測試,手工測試完全可以勝任。
根據(jù)項(xiàng)目時間安排,制定自動化腳本的交付時間和交付范圍。
在展開自動化測試之前,最好做個測試**,明確測試對象、測試目的、測試的項(xiàng)目內(nèi)容、測試的方***、測試的進(jìn)度要求,并確保測試所需的人力、硬件等**都準(zhǔn)備充分。制定好測試**后,下發(fā)給測試組內(nèi)人員,測試組內(nèi)人員根據(jù)**完成各自分配的任務(wù)。
自動化用例的設(shè)計和手工用例的設(shè)計一致,絕大多數(shù)情況并沒有單獨(dú)區(qū)分,而是統(tǒng)一由用例設(shè)計者設(shè)計出來,手工測試執(zhí)行用例的過程中,自動化人員編寫測試腳本。自動化用例的設(shè)計在實(shí)際項(xiàng)目中,一般分為兩種情況:
通常情況下這類的企業(yè)已經(jīng)有成熟的用例,需要招聘自動化編碼人員將已有的用例,實(shí)現(xiàn)自動化。這類的公司的自動化人員只需要根據(jù)已有的用例實(shí)現(xiàn)自動化即可。
有些公司對于測試的質(zhì)量尤其看重,這個時候往往需要一個經(jīng)驗(yàn)豐富且對需求非常熟悉的測試人員來專門負(fù)責(zé)測試用例的編寫,以防止設(shè)計漏測的發(fā)生。
這種情況大多是對于已有的用例進(jìn)行修改和補(bǔ)充,方便自動化腳本適配。
這種情況一般是由于公司里面的測試不多。每個人都分配任務(wù),這個時候需要自動化測試人員根據(jù)所分配的任務(wù)設(shè)計用例,同時還可能負(fù)擔(dān)起手工測試,以及用例編寫者和用例執(zhí)行者的身份。
腳本的編寫和命名要符合管理規(guī)范,以便統(tǒng)一管理和維護(hù)。腳本編寫好了之后,需要反復(fù)執(zhí)行,不斷調(diào)試,直到運(yùn)行正常為止。調(diào)試的期間也有可能發(fā)現(xiàn)產(chǎn)品質(zhì)量問題,這個時候需要提單跟蹤。
腳本的質(zhì)量會影響到整個自動化執(zhí)行的效率以及質(zhì)量,更是影響到后期的維護(hù)成本,每一個自動化腳本在誕生后,都會在后續(xù)的版本上持續(xù)運(yùn)行,如果某個腳本存在質(zhì)量問題,那么就意味著這個腳本所檢測的測試點(diǎn),會被一直漏測。
自動化腳本開發(fā)人員,應(yīng)該是一個合格且經(jīng)驗(yàn)豐富的測試人員。
方便后續(xù)對于腳本的查找。
在后續(xù)通過腳本的備注,就可以方便的知***腳本里面的寫的是那條用例,和用例的詳細(xì)信息。
第一個好處是:一眼就可以看出腳本的創(chuàng)建人創(chuàng)建時間,修改人修改時間,方便找人定位問題。
第二個好處是:后續(xù)腳本出現(xiàn)問題,責(zé)任劃分明確。
腳本的檢測點(diǎn)太多,會導(dǎo)致兩個問題。其一,腳本篇幅太長,不利于后期維護(hù)。其二,檢測點(diǎn)過多,不利于問題定位。
如果在編寫腳本的時候沒有對腳本修改或者創(chuàng)建的內(nèi)容進(jìn)行復(fù)原,很可能會對之后運(yùn)行的腳本產(chǎn)生影響。
在腳本開發(fā)人員編寫好腳本后,不應(yīng)在直接交付腳本參與測試,而是應(yīng)該組織組內(nèi)專家,對腳本進(jìn)行檢視。確認(rèn)腳本無問題后,才可參與測試。(檢視一般有兩種。一種是交叉檢視,又組內(nèi)腳本開發(fā)人員互相檢視。另一種方式,是由測試經(jīng)理或者自動化負(fù)責(zé)人統(tǒng)一檢視)
自動化測試的執(zhí)行并不依賴人員,任何時候都可以執(zhí)行自動化測試。但不是任何時候都適合執(zhí)行自動化腳本。
一般情況下都是在設(shè)備空閑的時候運(yùn)行自動化測腳本,因?yàn)椴煌哪_本之間會產(chǎn)生影響,如果同時運(yùn)行多個腳本,或者在運(yùn)行腳本的同時有其余人員在使用設(shè)備,那么會引發(fā)難以定位的問題。例如:運(yùn)行腳本在運(yùn)行過程中需要刪除某一個數(shù)據(jù),但是恰好在腳本運(yùn)行前有人使用環(huán)境人為的刪除了腳本要刪除的數(shù)據(jù),那么腳本就會出錯,如果不看產(chǎn)品的運(yùn)行日志,或者說日志記錄不清楚,那么很可能被當(dāng)成一個“bug”來處理。但是這個“bug”并非一個真正的bug,沒有辦***定位和修改,最后會被當(dāng)成一個無***復(fù)現(xiàn)的問題。這期間既浪費(fèi)了開發(fā)的人力也浪費(fèi)了測試的人力。
自動化執(zhí)行人員和腳本編寫人員可以不是同一個人,在實(shí)際項(xiàng)目中,很可能是某一個人運(yùn)行產(chǎn)品的所有自動化腳本。如果腳本運(yùn)行失敗,運(yùn)行人員需要大致對腳本失敗原因進(jìn)行分析:如果是產(chǎn)品問題,需要提單跟蹤;如果是腳本問題,那么可以找對應(yīng)的腳本開發(fā)人員進(jìn)行修改;如果是環(huán)境問題,那么就修復(fù)環(huán)境。
應(yīng)該及時分析自動化測試結(jié)果,如果沒有專人執(zhí)行自動化測試,建議測試人員每天抽出一定時間,對自動化測試結(jié)果進(jìn)行分析,以便盡早地發(fā)現(xiàn)缺陷。如果有專人負(fù)責(zé)自動化測試,可以交給專人完成。
理想情況下,自動化測試案例運(yùn)行失敗后,自動化測試平臺會自動大致判斷一下是什么缺陷,然后對于缺陷進(jìn)行一個初步的分類(腳本問題?環(huán)境問題?產(chǎn)品問題?)。如果是產(chǎn)品問題,就會自動上報一個缺陷。測試人員任然需要,確認(rèn)這些自動上報的缺陷,是否是真實(shí)的系統(tǒng)缺陷。如果是產(chǎn)品缺陷就提交開發(fā)人員修復(fù),如果不是系統(tǒng)缺陷,就檢查自動化測試腳本或者測試環(huán)境;如果是環(huán)境問題,需要去環(huán)境上面確認(rèn);如果是腳本問題,腳本開發(fā)人員修改腳本。
測試記錄的BUG要記錄到缺陷管理工具中去,以便定期跟蹤處理。開發(fā)人員修復(fù)后,需要對此問題執(zhí)行回歸測試,就是重復(fù)執(zhí)行一次該問題對應(yīng)的較薄的地方,執(zhí)行通過則關(guān)閉,否則繼續(xù)修改。自動化測試回歸相對于手工測試回歸方便很多,只需要將失敗的用例和開發(fā)修改點(diǎn)相關(guān)的用例運(yùn)行一遍即可。
如果問題的修改方案與客戶達(dá)成一致,但與原來的需求有所偏離,那么在回歸測試前,還需要對腳本進(jìn)行必要的修改和調(diào)試。
在自動化腳本運(yùn)行完成后,測試組長需要對測試的所有結(jié)果進(jìn)行分析,分析結(jié)果一般以數(shù)據(jù)為主。例如:一共執(zhí)行了多少條自動化用例,覆蓋了哪些功能模塊,用例通過百分比,沒有通過的腳本有多少是產(chǎn)品問題,是否所有的產(chǎn)品問題都已經(jīng)提單跟蹤。
通過對于腳本的分析,大概了解項(xiàng)目的運(yùn)行情況,可以及時調(diào)整人員安排和**的制定。
很多自動化腳本不可能寫了之后一運(yùn)行就是好幾年,永遠(yuǎn)不會變化。
一般情況產(chǎn)品的需求都可能發(fā)生變化,需求發(fā)生變化用例和腳本也會隨之發(fā)生變化。這樣就需要自動化腳本編寫者新增腳本,或者對于不適用的腳本及時的進(jìn)行剔除或者修改。
不只是需求會發(fā)生變化腳本才會變化,可能在運(yùn)行腳本的時候發(fā)現(xiàn)腳本穩(wěn)定性、可靠性不好等因素,導(dǎo)致某些腳本有時候運(yùn)行成功,有時候運(yùn)行不成功。這樣也需要腳本開發(fā)者對腳本進(jìn)行加固處理。
關(guān)于保險自動化設(shè)計和自動保險裝置的介紹到此就結(jié)束了,不知******從中找到***需要的信息了嗎 ?如果***還想了解更多這方面的信息,記得收***關(guān)注本站。 保險自動化設(shè)計的介紹就聊到這里吧,感謝***花時間閱讀本站內(nèi)容,更多關(guān)于自動保險裝置、保險自動化設(shè)計的信息別忘了在本站進(jìn)行查找喔。