新手測試周報(bào)范文

當(dāng)您開始作為自動化測試員的旅程時(shí)，錯(cuò)誤肯定會發(fā)生。 如果您不參加Selenium自動化測試腳本的深入研究而參加自動化網(wǎng)站測試，也可能會發(fā)生這種情況。 雖然可以從錯(cuò)誤中學(xué)習(xí)，但最好還是從別人那里學(xué)習(xí)，以防患于未然。

在處理自動化測試項(xiàng)目時(shí)，您承擔(dān)著巨大的責(zé)任。 您不正確的簽收可能導(dǎo)致生產(chǎn)中斷，最終可能導(dǎo)致客戶和聲譽(yù)損失。 我已經(jīng)去過接收端幾次了，這不是一個(gè)愉快的經(jīng)歷。 因此，作為一個(gè)自動化測試人員，我現(xiàn)在要確保避免這14個(gè)錯(cuò)誤，我將與您分享這些錯(cuò)誤。 請確保對它們進(jìn)行記錄，以免出現(xiàn)紅臉。

必要時(shí)自動化

當(dāng)我承擔(dān)了為我的Web應(yīng)用程序自動化Selenium測試腳本的責(zé)任時(shí)，我感到非常高興，因?yàn)檫@是我對團(tuán)隊(duì)的第一份工作。 第一印象總是至關(guān)重要的，我希望我的完美。 我被要求自動化Web應(yīng)用程序的一個(gè)模塊，我對此感到很自在。 但是，我想做更多的自動化工作，所以我從自己的理解中選出了另一個(gè)模塊。 我碰到了死胡同，卻未能自動化。 現(xiàn)在，嘗試自動化新模塊沒有錯(cuò)。 我在沒有咨詢我的前輩的情況下試圖自動執(zhí)行該模塊是錯(cuò)誤的。 原來，該模塊并不是要自動化的，因?yàn)榧上到y(tǒng)可能會導(dǎo)致多個(gè)誤報(bào)和誤報(bào)。 我花了我的時(shí)間在那個(gè)永遠(yuǎn)不會自動化的模塊上。 我什至最終忽略了我的其余職責(zé)。 這么多給一個(gè)好印象吧？

我已經(jīng)看到許多新的自動化測試儀會發(fā)生這種情況。 畢竟，好奇心可以帶您到位。 當(dāng)您學(xué)習(xí)自動化測試時(shí)，您可以嘗試在每個(gè)項(xiàng)目中引入自動化。 這不是必需的。 您也許可以自動化某件事，但這是否可行？ 眾所周知，自動化可以節(jié)省時(shí)間和精力，但回答以下問題絕對重要：為什么需要使該項(xiàng)目自動化？ 如果您得到務(wù)實(shí)的答案，則只有向自動化顯示綠燈。 避免將此錯(cuò)誤作為自動化測試人員至關(guān)重要。

定義范圍

定義要執(zhí)行的測試范圍是非常必要的。 當(dāng)我是一名新的自動化測試人員時(shí)，我嘗試測試所有內(nèi)容并使每項(xiàng)測試自動化。 問題是，盡管您可以成功地自動化所有測試，但是它既不可行也不可行。 首先，代碼的許多部分不需要經(jīng)常測試，我們可能需要花費(fèi)大量時(shí)間來開發(fā)僅用于這些代碼的框架或腳本。

例如，在使用Selenium測試網(wǎng)站時(shí)，自動化網(wǎng)站的每個(gè)元素并在其上運(yùn)行腳本是沒有用的。 這不值得花費(fèi)時(shí)間和金錢。 其次，使一切自動化將增加測試自動化百分比，這會讓您感到自己做得非常出色，這是不對的。 在紙上看起來可能不錯(cuò)，但這不是必需的。 定義測試范圍，并僅考慮可行的代碼以提供實(shí)時(shí)價(jià)值的自動化測試。

明智地選擇自動化測試工具

作為自動化測試人員，另一個(gè)最常見的錯(cuò)誤是沒有選擇正確的自動化測試工具。 一個(gè)項(xiàng)目包含著重于不同測試目標(biāo)的許多組件。 這些目標(biāo)應(yīng)分為不同的工具，可以幫助更有效地實(shí)現(xiàn)該目標(biāo)。 例如，如果要測試網(wǎng)站的API，則最好選擇Postman，但如果要確保在不同瀏覽器中完美呈現(xiàn)Web應(yīng)用程序，則在線Selenium Grid是進(jìn)行自動跨瀏覽器測試的最佳選擇。

這種情況的直接方法是不要跳到軟件上，然后嘗試通過該軟件解決問題。 首先，找到問題，然后找到合適的工具。

與研究員測試人員協(xié)調(diào)良好

測試團(tuán)隊(duì)中有很多人。 所有這些人都具備不同的技能。 例如，某人擅長業(yè)務(wù)測試，而某人擅長功能測試。 但是，這沒有理由讓您不與他們討論任務(wù)的進(jìn)度。 協(xié)調(diào)是加快產(chǎn)品交付的關(guān)鍵。 確認(rèn)誰在研究什么，他們在使用什么工具，他們對哪種用于自動化測試的編程語言感到滿意。 為什么？

這肯定會幫助您對Selenium自動化測試腳本進(jìn)行故障排除。 因此，萬一事情往南走，您將知道在哪里敲門，或者更確切地說是誰在敲門！

了解您的團(tuán)隊(duì)還可以幫助您在需要時(shí)進(jìn)行管理。 正如最后一點(diǎn)所討論的，一個(gè)項(xiàng)目可能需要使用不同的工具來實(shí)現(xiàn)合并的目標(biāo)，最好讓測試人員使用他喜歡的工具。

重要的是不要強(qiáng)迫任何人隨意使用任何任務(wù)和工具。 為此，您始終可以在開始測試過程之前進(jìn)行空運(yùn)行。 如果沒有適合的西裝，則需要進(jìn)行相應(yīng)的培訓(xùn)。

檢查投資回報(bào)率

僅將測試人員的薪水視為與整個(gè)測試過程相關(guān)的成本，這是一個(gè)非常菜鳥的錯(cuò)誤。 在最初的日子里，我做過同樣的事情。 顯然，事實(shí)并非如此。 例如，假設(shè)您要對網(wǎng)站執(zhí)行跨瀏覽器測試 。 測試人員的薪水顯然是成本的一??部分。 如果您的團(tuán)隊(duì)不知道這種類型的測試或與之相關(guān)的任何工具，那么您需要通過培訓(xùn)他們來提高他們的技能。 這產(chǎn)生了額外的費(fèi)用。 此外，您需要具有正確的自動化工具或框架來執(zhí)行自動化瀏覽器測試 。

現(xiàn)在，您可能正在考慮選擇像Selenium這樣的開源框架。 這樣，您可能不必支付更多，對嗎？ 嗯，就像其他所有東西一樣，Selenium不是完美的。 Selenium自動化測試面臨一些挑戰(zhàn)。 主要問題在于可伸縮性。 如您所知，Selenium Grid將幫助您執(zhí)行并行測試，這很棒。 但是，您只能通過提供Selenium Grid的計(jì)算機(jī)中安裝的瀏覽器來測試您的網(wǎng)站。 現(xiàn)在，您可能必須測試數(shù)百種瀏覽器，以及針對移動和臺式設(shè)備的不同操作系統(tǒng)上的瀏覽器版本。 自行執(zhí)行此操作將非常耗時(shí)且昂貴。 選擇設(shè)備實(shí)驗(yàn)室將傷您的口袋。 所以，你可以做什么？

您可以尋找在線Selenium Grid，例如LambdaTest。 我們的Selenium Grid可幫助您跨2000多種真實(shí)的瀏覽器和真實(shí)的操作系統(tǒng)測試您的網(wǎng)站。 最好的部分？ 一切都在云上，這意味著您可以擺脫維護(hù)內(nèi)部基礎(chǔ)結(jié)構(gòu)的麻煩，而選擇使用托管在云上的分布式計(jì)算機(jī)。 您不僅會節(jié)省時(shí)間，而且會節(jié)省金錢。

這只是一個(gè)例子。 同樣，在執(zhí)行Web應(yīng)用程序自動化測試的過程中還會遇到其他投資。 但是，它們一定會出現(xiàn)。 因此，應(yīng)仔細(xì)考慮測試成本，同時(shí)牢記您將獲得的這些投資的回報(bào)。 如果回報(bào)較少，則需要更改策略并重新計(jì)算。 但是最后，您需要在整個(gè)測試過程中獲得良好的投資回報(bào)率。

并非每個(gè)開源都將成為黃金

開源工具每天都在流行。 他們在用戶，支持和社區(qū)方面確實(shí)很棒。 開源軟件的最好之處在于，全球有大量的開發(fā)人員參與其中，從而可以更快地進(jìn)行改進(jìn)。 但是，這并不意味著您僅選擇或搜索開源工具。 開源工具的開發(fā)者也需要像其他人一樣的錢。 因此，更多時(shí)候您可能找不到帶有功能的開源軟件，即使很少有開源提供大量功能，也無法告知需要多長時(shí)間！ 軟件錯(cuò)誤可能會彈出，而社區(qū)支持程度較低的開源工具將很難找到這些錯(cuò)誤的修復(fù)程序。 您可能最終意識到，這是您作為自動化測試員的大錯(cuò)誤。

因此，始終建議使用具有大型社區(qū)支持的開源框架（例如Selenium）進(jìn)行Web應(yīng)用程序自動化測試。 因此，在開始之前，不要只將目光投向開源類別。 如果開源可以滿足您的要求，那很好，但如果不滿足，那么您就需要擁有合適的軟件。

將無代碼自動化視為墊腳石

盡管無代碼自動化測試工具的學(xué)習(xí)范圍狹窄且易于上手，但它們無法幫助您建立自動化測試人員檔案所需的相關(guān)技能。 作為一個(gè)初學(xué)者，他們很好地幫助您入門，但是隨著您在測試自動化事業(yè)中的發(fā)展，您會意識到他們并沒有您期望的那樣有幫助。 而且，如果您決定以無代碼自動化工具的智慧參加一次自動化測試人員資料的采訪，或者如果您認(rèn)為僅憑無代碼自動化就可以使復(fù)雜的Web應(yīng)用程序自動化，那么您將需要花費(fèi)大量的時(shí)間來破解它。

在這些類型的工具中，可靠性是另一個(gè)大問題。 最終，您需要學(xué)習(xí)代碼以調(diào)試自動化測試套件執(zhí)行出錯(cuò)的地方。 同樣，如果您要處理一個(gè)復(fù)雜的網(wǎng)站，那么您將找不到無代碼的自動化測試工具，它沒有您想要的那么靈活。 建議不要逃避代碼，而是要熟練地學(xué)習(xí)它。 最重要的是，這將是您簡歷的魅力。 因此，請確保避免作為自動化測試人員的常見錯(cuò)誤。

維護(hù)測試設(shè)計(jì)

測試設(shè)計(jì)是將一般測試目標(biāo)轉(zhuǎn)換為有形測試用例和條件的過程。 作為開發(fā)人員，我們傾向于認(rèn)為既然測試需要編碼，為什么開發(fā)人員無法完成這項(xiàng)工作？ 好吧，如果真是那樣，那么測試人員將不存在。

作為一個(gè)初學(xué)者，我不了解測試設(shè)計(jì)的重要性，這可能是我作為自動化測試員的最大錯(cuò)誤。 隨時(shí)進(jìn)行任何測試都是荒謬的想法。 為了有效地進(jìn)行測試，測試人員需要設(shè)計(jì)測試，然后對它們進(jìn)行編碼。 設(shè)計(jì)測試有助于創(chuàng)建有意義的測試，并使整個(gè)測試過程非常有效。

避免出現(xiàn)假陽性和假陰性結(jié)果

當(dāng)測試結(jié)果錯(cuò)誤地表明測試通過但實(shí)際上沒有通過時(shí)，就會出現(xiàn)假陽性。 反之亦然。 在測試人員中盲目相信測試報(bào)告是一個(gè)非常普遍的錯(cuò)誤。 這也可以稱為您正在測試的元素的非驗(yàn)證。 例如，假設(shè)您正在使用使用不同測試用例編寫的測試腳本來測試登錄頁面。 測試報(bào)告表明登錄已通過。 在這種情況下，您需要驗(yàn)證登錄是否成功。 作為自動化測試人員，請不要因總是誤報(bào)和誤報(bào)而陷入錯(cuò)誤。

專注于代碼可重用性

一個(gè)測試用例并不是它所應(yīng)用的代碼所獨(dú)有的。 在一個(gè)項(xiàng)目中，會出現(xiàn)許多相似的組件，它們需要相似的測試設(shè)計(jì)和測試套件。 例如，在使用Selenium進(jìn)行跨瀏覽器測試時(shí)，我們發(fā)現(xiàn)網(wǎng)頁的四個(gè)元素都是輸入字段，并且需要類似的測試用例。 在這里，您可以通過僅針對第一個(gè)元素編寫測試來復(fù)制粘貼代碼。 盡管這將提供預(yù)期的結(jié)果，但問題在于，將來開發(fā)人員可能會以某種方式更改元素。 現(xiàn)在，要更改測試用例，您需要更改您編寫的每個(gè)測試套件中的代碼。 整個(gè)時(shí)間都浪費(fèi)在查找和修改這些測試代碼上。 我犯了這個(gè)錯(cuò)誤，我可以看出，測試時(shí)這變得非常難看。
為避免這種情況，您應(yīng)始終專注于代碼的可重用性。 而不是一遍又一遍地粘貼代碼，您應(yīng)該構(gòu)造一個(gè)帶有適當(dāng)參數(shù)的函數(shù)，并在每個(gè)元素上調(diào)用此函數(shù)。 這樣，如果將來有任何更改，您只需要修改功能就可以了。

100％自動化是神話

不要迷戀這個(gè)神話，因?yàn)檫@將是一個(gè)自動化測試員的嚴(yán)重錯(cuò)誤。 作為測試自動化領(lǐng)域的新手，我很高興為項(xiàng)目帶來自動化。 這導(dǎo)致我犯了一個(gè)錯(cuò)誤，認(rèn)為自動化測試可以完全替代手動測試過程。 隨著時(shí)間的推移，我知道這是不可能的。 用自動化測試完全替代手動測試（100％）是一個(gè)神話。 它永遠(yuǎn)不可能實(shí)現(xiàn)。 作為該領(lǐng)域的初學(xué)者，請勿嘗試實(shí)現(xiàn)此目標(biāo)。 僅在必要時(shí)自動化，并且僅在那些需要自動化的事物上自動化。

遵循地面向上的方法

在測試時(shí)，您會遇到不同類型的問題。 您將需要設(shè)定目標(biāo)并對這些問題進(jìn)行分類。 全面的方法意味著使用較小的模塊而不是較大的模塊開始自動化測試。

作為自動化測試儀，最大的錯(cuò)誤之一就是要使用更大，更復(fù)雜的模塊開始自動化。 不要那樣做！ 您缺乏對每個(gè)用戶交互中涉及的入站和出站流程的了解。 您甚至可能缺乏處理棘手的測試用例的能力，并且最終可能會浪費(fèi)大量時(shí)間而無所適從。 因此，從小處著手，并從根本上增加自動化測試的覆蓋范圍。

參與探索性測試

作為自動化測試人員，常見的錯(cuò)誤之一就是不將探索性測試納入您的每周例行程序。 探索性測試是一次偉大的冒險(xiǎn)，它有助于尋找新的測試用例。 當(dāng)我們進(jìn)入自動化階段時(shí)，探索性測試至關(guān)重要。 僅使用測試腳本可能會忽略自動化測試中一些意外的重要測試用例。 作為一個(gè)初學(xué)者，我們只想依靠腳本和預(yù)先編寫的測試，應(yīng)該避免這種情況。

花一些時(shí)間進(jìn)行探索性測試。 您可能永遠(yuǎn)都不知道在野外測試時(shí)可能會捕獲哪些錯(cuò)誤。

UI不滲透的設(shè)計(jì)測試

在較早的版本中，軟件的用戶界面發(fā)生了很大變化。 自動化測試可以幫助我們重復(fù)執(zhí)行測試，如果沒有實(shí)現(xiàn)，那就沒有意義了。 在早期階段，測試人員會像自動化測試人員一樣忽略這些類型的錯(cuò)誤，我也這樣做。 現(xiàn)在，我知道我不應(yīng)該擁有！！

用戶界面的更改迫使我們更改測試腳本。 有時(shí)，某個(gè)元素在將來的版本中會更改其位置，而腳本會利用該位置進(jìn)行進(jìn)一步測試。 由于位置更改是測試所依賴的，因此完整的測試執(zhí)行失敗。 例如，在自動瀏覽器測試中，如果某個(gè)圖像的位置發(fā)生更改，則Selenium自動化測試腳本將無法找到該位置。 這將使整個(gè)測試失敗。 這些依賴于用戶界面的測試應(yīng)盡可能少地編寫。

結(jié)語

自動化是一個(gè)蓬勃發(fā)展的行業(yè)。 從小型JUnit測試到大型Selenium腳本，每個(gè)人都在朝著自動化邁進(jìn)。 您可能會在添加了小的補(bǔ)丁的情況下遇到相同的代碼，并且不得不再次運(yùn)行相同的測試。 借助自動化，重復(fù)性任務(wù)中的錯(cuò)誤容限已減少至零。 但是，只有在一些自動化方面的實(shí)踐和經(jīng)驗(yàn)之后，才能達(dá)到此階段。 當(dāng)人們第一次進(jìn)入自動化領(lǐng)域時(shí)，他們注定會犯一些錯(cuò)誤。 盡管犯錯(cuò)不是犯罪，但是如果您在公司或團(tuán)隊(duì)中工作，這些錯(cuò)誤會浪費(fèi)您的金錢，時(shí)間和其他關(guān)鍵資源。 這就是為什么事前安全要好一些的原因。 我希望您不會因?yàn)樽詣踊瘻y試員而屈服于這14個(gè)錯(cuò)誤。 測試愉快！

翻譯自: https://www.javacodegeeks.com/2020/02/14-mistakes-i-did-that-you-should-avoid-as-a-newbie-automation-tester.html

新手測試周報(bào)范文

總結(jié)

以上是生活随笔為你收集整理的新手测试周报范文_作为新手自动化测试人员，我应该避免的14个错误的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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