測試筆試題

做了幾套題,個別題竟然錯了。汗顏。摘錄下:

1.有關字節換算的

字節 byte:8個二進制位爲一個字節(B),最常用的單位,字節也就是B。

1KB (Kilobyte 千字節)=1024B

1MB (Megabyte 兆字節 簡稱“兆”)=1024KBA

1GB (Gigabyte 吉字節 又稱“千兆百”)=1024MB

擴展資料:版

字節和字的換算關係:

一個字等於多少個字節,與系統硬件(總線、cpu命令字位數等)有關,不應該毫無前提地說一個字等於多少位。

正確的說法:

①:1字節(byte) = 8位(bit)

②:在16位的系權統中(比如8086微機) 1字 (word)= 2字節(byte)= 16(bit)

在32位的系統中(比如win32) 1字(word)= 4字節(byte)=32(bit)

在64位的系統中(比如win64)1字(word)= 8字節(byte)=64(bit)

2.軟件的6大質量特性:

ISO9126質量模型:軟件質量模型的6大特性和27個子特性。

ISO9126軟件質量模型是評價軟件質量的國際標準,由6個特性和27個子特性組成,建議大家深入理解各特性、子特性的含義和區別,在測試工作需要從這6個特性和27個子特性去測試、評價一個軟件。這個模型是軟件質量標準的核心,對於大部分的軟件,都可以考慮從這幾個方面着手進行測評。

 

2qw一、功能性
1、適合性:提供了相應的功能
2、準確性:正確(用戶需要的)
3、互操作性:產品與產品之間交互數據的能力
4、保密安全性:允許經過授權的用戶和系統能夠正常的訪問相應的數據和信息,禁止未授權的用戶訪問.......
5、功能性的依從性:國際/國家/行業/企業 標準規範一致性
二、可靠性:產品在規定的條件下,在規定的時間內完成規定功能的能力
1、成熟性:防止內部錯誤導致軟件失效的能力
2、容錯性:軟件出現故障,自我處理能力
3、易恢復性:失效情況下的恢復能力
4、可靠性的依從性
三、易用性:在指定使用條件下,產品被理解、 學習、使用和吸引用戶的能力
1、易理解性
2、易學性
3、易操作性
4、吸引性
5、易用性的依從性
四、效率性:在規定臺條件下,相對於所用資源的數量,軟件產品可提供適當性能的能力
1、時間特性:平均事務響應時間,吞吐率,TPS(每秒事務數)
2、資源利用性:CPU 內存 磁盤 IO 網絡帶寬 隊列 共享內存
3、效率依從性
五、軟件維護性:"四規", 在規定條件下,規定的時間內,使用規定的工具或方法修復規定功能的能力
1、易分析性:分析定位問題的難易程度
2、易改變性:軟件產品使指定的修改可以被實現的能力
3、穩定性:防止意外修改導致程序失效
4、易 測試性:使已修改軟件能被確認的能力
5、維護性的依從性
六、軟件可移植性:從一種環境遷移到另一種環境的能力
1、適應性:適應不同平臺
2、易安裝性:被安裝的能力
3、共存性
4、易替換性
5、可移植性的依從性

3.Alpha測試與beta的區別

alpha測試版,有點相當於內部測試,一般開發人員在場   ,是由用戶做測試,但開發人員在場,一般是請用戶到開發現場去測試 
beta測試版,完全交給用戶,由用戶做測試,返回測試報告,相當於發行前的一個版本   

Alpha測試 在系統開發接近完成時對應用系統的測試;測試後仍然會有少量的設計變更。這種測試一般由最終用戶或其它人員完成,不能由程序或測試員完成。 
Beta測試 當開發和測試根本完成時所做的測試,最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其它人員完成,不能由程序員或測試員完成。

1、測試時間不同:

Beta測試是百軟件產品完成了功能測試和系統測試之後,在產品發佈之前所進行的軟件測試活動,它是技術測試的最後一個階段。

alpha測試簡稱“α測試”,可以從軟件產品編碼結束之時開始,或在模塊(子系統)測試完成之後開始,也可以在確認測試過程中產品達到一定的穩定和可靠程度度之後再開始。

2、測試的目的不同:

α測試的目的是評價軟件產品的FLURPS(即功能、局域化、知可用性、可靠性、性能和支持)。尤其注重產品的界面和特色。α測試即爲非正式驗收道測試。

Beta測試是一種驗收測試,通過了驗收測試,產品就會進入發佈階段。

3、測試人員及場所不同:

α測試是由一個用戶在開發環境下進行的測試,也可以是公司內部的用戶在模擬實際操作環境下進行的受控測試,α測試不能由程序版員或測試員完成。α測試發現的錯誤,可以在測試現場立刻反饋給開發人員,由開發人員及時分析和處理。

Beta測試由軟件的最終用戶們在一個或多個客戶場所進行。開發者通常不在Beta測試的現場,因Beta測試是軟件在開發者不能控制的環境中的“真實”應用。

4.軟件缺陷等級劃分

A類—嚴重錯誤,包括以下各種錯誤: 1.由於程序所引起的死機,非法退出 2.死循環 3.數據庫發生死鎖 4.因錯誤操作導致的程序中斷 5.功能錯誤 6.與數據庫連接錯誤 7.數據通訊錯誤

B類—較嚴重錯誤,包括以下各種錯誤: 1.程序錯誤 2.程序接口錯誤 3.數據庫的表、業務規則、缺省值未加完整性等約束條件

C類—一般性錯誤,包括以下各種錯誤: 1.操作界面錯誤(包括數據窗口內列名定義、含義是否一致) 2.打印內容、格式錯誤 3.簡單的輸入限制未放在前臺進行控制 4.刪除操作未給出提示 5.數據庫表中有過多的空字段

D類—較小錯誤,包括以下各種錯誤: 1.界面不規範 2.輔助說明描述不清楚 3.輸入輸出不規範 4.長操作未給用戶提示 5.提示窗口文字未採用行業術語 6.可輸入區域和只讀區域沒有明顯的區分標誌

E類—測試建議

5.請描述TCP/IP建立連接的過程

採用三次握手,建立一個連接。

第一次握手,客戶端發送syn包(syn=j)到服務端,並進入SYN_SEND狀態,等待服務器確認;

第二次握手,服務端收到syn包,必須確認客戶的SYN(ack=j+1),同時也發送一個syn包(syn=k),即SYN+ACK包,此時服務器進入SYN_RECV狀態;

第三次握手,客戶端收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入EATABLISHED狀態,完成三次握手 

6.測試分爲那幾個階段?並對每個階段詳細說明

按照開發階段劃分,軟件測試可分爲單元測試、集成測試、系統測試和驗收測試

集成測試:針對每個單元的測試,以確保每個模塊能正常工作爲目標

集成測試:對已經測試過的模塊進行組裝,進行集成測試。目的就是在於檢驗與軟件設計相關的程序結構問題。

系統測試:檢驗軟件產品能夠與系統的其他部分(比如:硬件、數據庫及操作人員)協調工作。

驗收測試:檢驗軟件產品質量的最後一道工序,主要突出用戶的作用,同時軟件開發人員也有一定程度的參與。

7.什麼是軟件測試?軟件測試的目的與原則

在規定的條件下對程序進行操作,以發現程序錯誤,衡量軟件質量,並對其是否能滿足設計要求進行評估的過程。

軟件測試的目的:

測試是程序的執行過程,目的在於發現錯誤
一個成功的測試用例在於發現至今未發現的錯誤
一個成功的測試是發現了至今未發現的錯誤的測試
確保產品完成了它所承諾或公佈的功能,並且用戶可以訪問到的功能都有明確的書面說明。
確保產品滿足性能和效率的要求
確保產品是健壯的和適應用戶環境的

        1)軟件測試是爲了發現錯誤而執行程序的過程。

        2)測試是爲了證明程序有錯,而不是證明程序無錯。(發現錯誤不是唯一目的)

        3)一個好的測試用例在於它發現至今未發現的錯誤。

        4)一個成功的測試是發現了至今未發現的錯誤的測試。

注意:

        1、測試並不僅僅是爲了要找出錯誤。通過分析錯誤產生的原因和錯誤的分佈特徵。可以幫助項目管理者發現當前所採用的軟件過程的缺陷,以便改進。同時,通過分析也能幫助我們設計出有針對性的檢測方法,改善測試的有效性。

        2、沒有發現錯誤的測試也是有價值的,完整的測試是評定測試質量的一種方法。詳細而嚴謹的可靠性增長模型可以證明這一點。例如Bev Littlewood發現一個經過測試而正常運行了n個小時的系統有繼續正常運行n個小時的概率。

 

軟件測試的原則:

測試用例中一個必須部分是對預期輸出或接過進行定義
程序員應避免測試自己編寫的程序
編寫軟件的組織不應當測試自己編寫的軟件
應當徹底檢查每個測試的執行結果
測試用例的編寫不僅應當根據有效和預料到的輸入情況,而且也應當根據無效和未預料到的輸入情況
檢擦程序是否“未做其應該做的”僅是測試的一半,測試的另一半是檢查程序是否“做了其不應該做的”
應避免測試用例用後即棄,除非軟件本身就是個一次性的軟件
計劃測試工作時不應默許假定不會發現錯誤
程序某部分存在更多錯誤的可能性,與該部分已經發現錯誤的數量成正比
軟件測試是一項極富創造性,極具智力的挑戰性的工作

 

       1)應當把“儘早地不斷地進行軟件測試“作爲軟件開發者的座右銘。

       2)測試用例應由測試數據和與之對應的預期輸出結果這兩部分組成。

       3)程序員應避免檢查自己的程序。

       4)在設計測試用例時,應當包括合理的輸入條件和不合理的輸入條件。

       5)充分注意測試中的羣集現象。

       6)嚴格執行測試計劃,排除測試的隨意性。

       7)應當對每一個測試結果做全面的檢查。

       8)妥善保存測試計劃、測試用例、出錯統計和最終分析報告,爲維護提供方便。

一、Testing shows presence of defects
       測試顯示軟件存在缺陷
       測試只能證明軟件中存在缺陷,但並不能證明軟件中不存在缺陷。軟件測試是爲了降低存在缺陷的可能性,即便是沒有找到缺陷,也不能證明軟件是完美的。
二、Exhaustive testing is impossible
       窮盡測試是不可能的
       現在軟件的規模越來越大,複雜度越來越高,想做到完全性的測試是不可能的。在測試階段,測試人員可以根據風險和優先級來進行集中和高強度的測試,從而保證軟件的質量。
三、Testing early
       測試儘早介入
       爲什麼測試要儘早介入呢,簡單的說就是保證軟件質量,降低風險和成本。測試人員一般在需求階段就開始介入,使缺陷在需求或設計階段就被發現,缺陷發現越早,修復的成本就越小。
四、Defect clustering
       缺陷集羣性(2/8原則)
       缺陷集羣性表明小部分模塊包含大部分的缺陷。軟件測試中存在Pareto原則:80%的缺陷發現在20%的模塊中。
       一個功能模塊發現的缺陷越高,那存在的未被發現的缺陷也越高,故發現的缺陷與未發現的缺陷成正比。
五、Pesticide Paradox
      殺蟲劑悖論
      反覆使用相同的殺蟲劑會導致害蟲對殺蟲劑產生免疫而無法殺死害蟲。軟件測試也一樣。如果一直使用相同的測試方法或手段,可能無法發現新的bug。
      爲了解決這個問題,測試用例應當定期修訂和評審,增加新的或不同的測試用例幫助發現更多的缺陷。
      測試人員不能一直依賴於現有的測試技術,而要不斷的提升測試方法以提高測試效率。
六、Testing is context dependent
      測試活動依賴於測試內容
      根據業務的不同,軟件測試內部也分爲不同的行業,比如遊戲行業、電商行業、金融行業。不同的行業,測試活動的開展都有所不同,比如測試技術、測試工具的選擇,測試流程都不盡相同,所以軟件測試的活動開展依賴於所測試的內容。
七、Absence of error - fallacy
       沒有錯誤是好是謬論
      有可能99%沒有bug的軟件也是不能使用的。如果對錯誤的需求進行了徹底的測試,這種情況就發生了。軟件測試不僅是找出缺陷,同時也需要確認軟件是否滿足需求。如果開發出來的產品不滿足用戶的需求,即便找到和修復了缺陷也作用不大。

 

8.系統測試的策略有哪些?列出任意10種即可

功能測試,性能測試,可靠性測試,負載測試,易用性測試,強度測試,安全測試,配置測試,安裝測試,卸載測試,文擋測試,故障恢復測試,界面測試,容量測試,兼容性測試,分佈測試,可用性測試

9.8位ASCII字符編碼的最大值

8位ASCII字符編碼的最大值是255。 計算機中存儲數據用的是二進制。 8位二進制最高位位權爲2^7,最低位位權爲2^0(也就是1)。 最大數爲(11111111)2 = (100000000 - 1)2 = (2^8 - 1)10 = 255.

10.爲什麼說單元測試能發現約80%的軟件缺陷

這是軟件工程長期的歷史數據統計和測試zd經驗總結得來的,沒聽說過有典故或理由。當然要發現這80%的缺陷也版是要依靠設計出良好的測試用例,另外順便提下,軟件測試行業有個二八原則,就是軟件80%的缺陷權存在與20%的代碼中

因爲缺陷放大理論,在單元測試階段發現的bug會在系統測試階段被放大,放大倍數完全符合80/20理論

11.SQL語言的分類

SQL語言共分爲四大類:數據查詢語言DQL,數據操縱語言DML,數據定義語言DDL,數據控制語言DCL。

1. 數據查詢語言DQL
數據查詢語言DQL基本結構是由SELECT子句,FROM子句,WHERE
子句組成的查詢塊:
SELECT <字段名錶>
FROM <表或視圖名>
WHERE <查詢條件>

2 .數據操縱語言DML
數據操縱語言DML主要有三種形式:
1) 插入:INSERT
2) 更新:UPDATE
3) 刪除:DELETE

3. 數據定義語言DDL
數據定義語言DDL用來創建數據庫中的各種對象-----表、視圖、
索引、同義詞、聚簇等如:
CREATE TABLE/VIEW/INDEX/SYN/CLUSTER
| | | | |
表 視圖 索引 同義詞 簇

DDL操作是隱性提交的!不能rollback 

4. 數據控制語言DCL
數據控制語言DCL用來授予或回收訪問數據庫的某種特權,並控制
數據庫操縱事務發生的時間及效果,對數據庫實行監視等。如:
1) GRANT:授權。


2) ROLLBACK [WORK] TO [SAVEPOINT]:回退到某一點。
回滾---ROLLBACK
回滾命令使數據庫狀態回到上次最後提交的狀態。其格式爲:
SQL>ROLLBACK;


3) COMMIT [WORK]:提交。


    在數據庫的插入、刪除和修改操作時,只有當事務在提交到數據
庫時纔算完成。在事務提交前,只有操作數據庫的這個人纔能有權看
到所做的事情,別人只有在最後提交完成後纔可以看到。
提交數據有三種類型:顯式提交、隱式提交及自動提交。下面分
別說明這三種類型。


(1) 顯式提交
用COMMIT命令直接完成的提交爲顯式提交。其格式爲:
SQL>COMMIT;


(2) 隱式提交
用SQL命令間接完成的提交爲隱式提交。這些命令是:
ALTER,AUDIT,COMMENT,CONNECT,CREATE,DISCONNECT,DROP,
EXIT,GRANT,NOAUDIT,QUIT,REVOKE,RENAME。


(3) 自動提交
若把AUTOCOMMIT設置爲ON,則在插入、修改、刪除語句執行後,
系統將自動進行提交,這就是自動提交。其格式爲:
SQL>SET AUTOCOMMIT ON;

12.其它

單元測試一般以白盒爲主,測試的依據是模塊功能規格說明

爲保證測試活動的可控性,必須在軟件測試過程中進行軟件測試配置管理,一般來說,軟件測試配置管理中最基本的活動包括配置項標識、配置項控制、配置狀態報告、配置審計

13.怎樣進行文檔測試

  非代碼的文檔測試主要檢查文檔的正確性、完備性和可理解性。軟件驅動的文檔還得像程序一樣運行測試。

  正確性是指不要把軟件的功能和操作寫錯,也不允許文檔內容前後矛盾。

  完備性是指文檔不可以“虎頭蛇尾”,更不許漏掉關鍵內容。文檔中很多內容對開發者可能是“顯然”的,但對用戶而言不見得都是“顯然”的。

  文檔要讓大衆用戶看得懂,能理解。術語、縮寫用戶是否理解?內容和主題是否一致?

  很多程序員能編寫出好程序,卻寫不出清晰的文檔。與文檔作者密切合作,對文檔仔細閱讀,跟隨每個步驟,檢查每個圖形,嘗試每個示例是進行文檔測試的基本方法。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章