什么是測試？
測試就是通過人工或者自動化來驗證結果和需求是否一致的過程
軟件測試的目的與原則是什么？
目的：
????通過測試工作可以發(fā)現軟件中的缺陷
????可以降低通產品的開發(fā)遇到的風險
? ? 通過測試過程中得到的數據向策劃者提供技術支持
原則：
缺陷集成性：2/8?軟件測試中20%都是核心內容，非核心占80%，我們會集中測試20%的核心功能，發(fā)現缺陷的幾率會高于80%，因此遇到的缺陷都會集中在20%模塊中。
窮盡測試是不可能的：有些功能是無法將所有測試情況邏輯出來的，任何測試都是有結束的時間
測試需要盡早介入：為了更好發(fā)現和解決軟件中的缺陷、
殺蟲劑悖論：同樣的一個測試用例是不能重復執(zhí)行多次，不然軟件會對它產生免疫
測試顯示軟件存在的缺陷
測試活動依賴于測試內容：某些測試需要依賴于特殊的環(huán)境
沒有錯誤是好是謬論：任何軟件都不可能是完美的
測試人員在測試中的任務是什么？
盡早找出系統(tǒng)當中的Bug
避免軟件開發(fā)過程中缺陷的出現
關注用戶需求，保證系統(tǒng)符合用戶需求
請您詳細描述測試的V模型？
用戶需求--需求分析--概要設計--詳細設計--編碼，實現--單元測試--集成測試--系統(tǒng)測試--驗收測試
Bug不能復現怎么辦？
首先考慮到環(huán)境問題，看是否能夠還原原來的環(huán)境
遇到問題就要提，不能放過一個Bug，提交的Bug描述中加上一句話，那就是復現的概率，20次，出現一次或者是10次，交給開發(fā)，開發(fā)會根據Bug的復現概率，調整Bug的優(yōu)先級
注重細節(jié)，不要漏掉任何一個細節(jié)（盡量回想發(fā)生問題的復現步驟，不要漏掉任何一個細節(jié)，按照步驟的組合嘗試復現）
與開發(fā)人員配合，讓開發(fā)人員對相應的代碼檢查，看是否通過代碼層面解決問題。
B/S和C/S架構的區(qū)別是什么？
B/S：是瀏覽器和服務器
C/S：是客戶端和服務器
B/S的執(zhí)行效率要比C/S高，C/S的安全要比B/S高，B/S升級只需要在服務器端將數據進行更新，前臺只需刷新頁面就可以升級，而C/S架構必須兩端都要更新，B/S要比C/S開發(fā)成本要低；
測試流程是什么？
需求評審（開發(fā)人員，測試人員，產品經理，項目經理）需求確定（出一份確定好的需求文檔）開發(fā)設計文檔（開發(fā)人員在寫代碼之前就能夠輸出設計文檔）指定測試計劃--寫出測試用例--發(fā)給開發(fā)人員和測試經理看一下--接到測試版本--執(zhí)行測試用例--提交Bug--交給開發(fā)人員修改--回歸測試
當你參加評審時買的評審的原則是什么？?
首先要從正確性，一致性，可行性，必要性，可跟蹤性，分配優(yōu)先級，可測性，可修改性考慮；
正確性：每一條需求都必須準確的陳述其要開發(fā)的功能。
一致性：必須與其他軟件需求或高層需求不相矛盾。
可行性：其每一項需求都必須是已系統(tǒng)和環(huán)境的權能和限制范圍可以來實施的。
必要性：每項需求都是用來授權你編寫文檔的“根源”，要使每項需求都能回潮至某項客戶的輸入。
可測性：每項需求都能通過設計測試用例或其他的驗證方法來進行測試。
可修改性：每項需求只應在SRS中出現一次，這樣更改會容易保持一致性。
可跟蹤性：在每項軟件需求與它的根源與設計元素，源代碼，測試用例之間建立起鏈接，而這種可跟蹤
性要求每項需求都必須以一種結構化的，粒度好（fine-grained）的方式編寫
分配優(yōu)先級：應當對所有的需求分配優(yōu)先級，如把所有需求都看作同樣重要，那么項目管理者在開發(fā)或
節(jié)省預算或調度中喪失控制自由度
軟件測試的需求標準是什么？
文檔版本信息：包含文檔版本，作者，完成日期，修改需要加上的修訂記錄（版本號，修訂者，日期，內容）
目錄結構要清晰：不同級別的標題要區(qū)分字號
產品架構：一般只有功能以及信息架構
功能：一級，二級，三級功能都要劃分出來，以及產品特性（功能列表，原型界面，詳細設計）
請寫一下W模型圖
需求分析--概要分析--詳細分析--編碼實現--模塊集成--系統(tǒng)構建--系統(tǒng)安裝
需求測試--概要測試--詳細測試--單元測試--集成測試--系統(tǒng)測試--驗收測試
W模型圖
軟件質量的特性是什么？
功能性：軟件需求要滿足用戶顯示或者穩(wěn)式的功能
易用性：軟件易于學習和上手
可靠性：軟件必須實現需求當中指定的具體功能
效率性：類似于軟件的功能
可維護性：需求軟件具有功能將某個功能修復之后繼續(xù)使用的功能
