織雀教育軟件測試畢業學員面試真題彙總(連載中)

隨著疫情的逐漸好轉,各用人單位也開始復工復產,再加上現在是招聘旺季,面試是少不了的。為了回饋粉絲,織雀教育特將目前為止已經畢業並順利通過各大公司面試的學員遇到的問題做了整理,相信會給大家帶來一定的幫助!


01測試延期怎麼辦?

首先,我們要分析出測試延期的原因,是研發沒有按時提交被測試代碼;還是由於測試任務比較重,導致沒有在規定的時間內完成。然後針對具體的情況實行相應的策略。

1.如果是研發沒按時間提交被測試代碼,為了保證測試質量,我們還是按照里程碑裡規定的測試周期進行測試,整個項目週期需要順延。(因為是研發週期變長,沒有理由縮短測試周期,我們只能保證測試周期不變,項目的整體時間順延)

2.如果是因為測試任務比較重,導致測試延期,這種情況下我們需要從所有的任務中進行優先級別的劃分,針對優先級別較高的任務優先去進行測試。(這種情況下,需要整個項目組成員開會去討論優先級別)

3.從其他項目組協調相關的測試人員,爭取在規定的時間內完成測試。


02軟件測試在整個項目中的重要性

我認為測試在整個項目中擔任很重要的角色。因為,測試是保證軟件質量的最後一關。如果公司研發的軟件沒有經過測試,用戶在使用的過程中,可能會有很多問題暴露在用戶現場。這種情況下,給用戶帶來的不僅僅是軟件不可用的問題,而是用戶對公司的認可問題,甚至嚴重的情況下會帶來更嚴重的問題,比如財產、人身安全等問題。


03Bug的管理工具,用什麼軟件管理bug?

我上家公司,用的是QC,我也用過禪道,目前禪道在國內有好多單位都在用。其他的缺陷管理工具Bugzilla、BugFree我也瞭解過。


04能夠獨自編寫測試用例嗎,用例的要素?

我自己可以獨立完成測試用例設計,我在做XXX項目時,整個項目是我自己獨立負責的,測試用例的編寫以及組織用例評審、測試的執行、問題的提交和跟蹤、最終測試報告的提交,整個項目是我自己負責的。

我在做XXX項目時,我們公司用的測試用例模板大概包括則幾個方面:測試的目的、測試的環境、測試步驟、預期結果、實際結果、測試的優先級別、執行人和測試時間。


05登錄界面的測試用例

我在做XXX項目的是,我設計用的思路是這樣的。

首先,要分析登錄界面包括的元素有哪些,我們登錄時會輸入用戶名、密碼、驗證碼等條件選項。

然後,判斷登錄後,有兩種結果,一個是成功,另一個是失敗。輸入的內容是條件,得出的是結果。所以在設計用例時可能考慮到因果關係,要用到因果圖去設計測試用例。

所有的條件都輸入正確的情況,登錄時成功的。其中一個條件或多有條件輸入錯誤的情況,登錄是失敗的。

最後,我們還要考慮,登錄失敗次數達到上限,會不會鎖定登錄;還要考慮到在鎖定時間內,重新登錄的情況;還要考慮到超過鎖定時間,重新登錄的情況。


06怎麼編寫的測試用例(針對輸入框)

針對輸入框,是有長度和輸入類型的限制。在設計測試用例時要使用等價類和邊界值結合一起進行設計測試用例,針對長度測試要考慮到邊界的左右兩組數據。針對類型的話要考慮到有效的類型和無效的類型。


07負責的項目明天上線卻發現了一個重要bug,你該怎麼辦?

1.把問題及時彙報給自己的領導,同時,把這個問題告知項目組所有參與項目的同事。

2.然後組織整個項目組的同事,討論這個問題對上線的影響。

3.最終確定如何去解決這個bug,因為出現的是嚴重的bug而不是緊急的bug,不一定影響產品上線,我們可以在發現問題後及時去解決。如果情況很緊急,則要儘快解決這個問題,不影響正常上線。


08研發如果給了未開發完成一部分的產品要怎麼測試

首先,要把完成的和未完成的功能點梳理出來。然後,針對完成的功能點進行測試。

1. 數據庫會什麼命令

我在做項目的時候,用到過,創建用戶的命令:create user 用戶名@% identified by ‘密碼’;刪除用戶的命令:drop user 用戶名@% ;創建數據庫的命令:create database 數據庫名字;

創建表的命令:create table 表名(列名1 類型1,列名2類型2);等等


09SQL修改數據、查詢命令

修改數據的命令:update user set 列名 =‘ 修改後的內容 ’ where 列名=‘ 列名所修改行數’;

常用查詢表的命令:select * from 表名where列名=‘ 需要查找的內容‘;


010刪除數據命令

刪除數據的命令:delete from 表名where 列名=‘ 需要刪除的內容‘;


011你發現了BUG,開發認為不是怎麼辦

首先,我要確定這是一個可以復現的真實bug。在bug管理工具中提交這個bug。在提交的過程中,我要保存每一步的截圖,作為證據。

然後,根據需求說明書、產品說明、設計文檔等,確認實際結果是否與計劃有不一致的地方,提供缺陷是否確認的直接依據;

如果沒有文檔依據,可以根據類似軟件的一般特性來說明是否存在不一致的地方,來確認是否是缺陷;也可以根據根據用戶的一般使用習慣,來確認是否是缺陷;

最後,組織設計人員、開發人員和客戶代表等相關人員探討,確認是否是缺陷;(在探討的過程中,合理的論述,說明自己的判斷的理由,注意客觀、嚴謹,不參雜個人情緒。)


分享到:


相關文章: