軟件測試經驗

時間 2019-11-18

標籤軟件測試經驗简体版

原文原文鏈接

1、大家以往作系統測試時的測試流程是怎樣的？php

搭建參考環境　熟悉需求與業務邏輯　1天
寫測試計劃（評審）　 1天
寫測試方案１天
寫測試用例 N天
執行 N天
項目總結 1天mysql

2、測試過程當中你是否搭建過測試環境？可否描述一下搭的什麼環境？如何搭的？
１、環境：Linux(redhat4)、Apache、MySQL、PHP
步驟1：安裝linux系統
步驟2：對linux系統作一些配置：設置IP地址，建立用戶，建立文件系統
步驟3：上傳安裝源文件(ftp）
步驟4:　安裝Apache （編繹安裝）
步驟5：安裝mysql(rpm安裝）
步驟6:　安裝php（編繹安裝）
步驟7:部署sugar版本（檢查環境和權限，鏈接數據庫，安裝實例sugarCRM）linux

備註：
Linux經常使用的一些操做：
１、目錄操做(mkdir, rm -R, cd, pwd,mv,cp,ls,ls -al, ls -lrt)
２、權限操做(chmod, chgrp, chown)
３、系統管理(shutdown -r now, shutdown -h now, reboot，useradd, su - 用戶名)
４、進程與資源管理(ps -aux, free, top, vmstat, iostat)
５、文件查看和編輯（cat,vi,tail,tail -f,more,less ）
６、壓縮，安裝類（rpm -ivh, rpm -e,rpm -qa查詢已安裝的rpm包，tar xvf，tar cvf，unzip,gunzip,gzip）
７、磁盤（du -ms(ks), df, mount/umount）
８、find, grep，linux日誌結構ios

3、需求分析階段主要作什麼事情？有好的需求是否要作需求管理？如何作好需求管理？
　　需求分析階段：分析測試需求，評審需求，可測試性需求
須要作好需求管理，怎麼作：作好需求跟蹤。sql

4、若是咱們項目中沒有需求文檔，應該怎麼作好測試工做？
　　１、搭建一個歷史版本的環境，以便了解業務流程
　　２、開發的概設，詳設，與需求相似的討論（會議紀要）,用戶使用指南，產品介紹
　　３、與項目組有經驗的員工交流
　　４、參考友商的相似的項目（文檔）
　　５、項目內部組織業務培訓數據庫

5、測試計劃應該包括哪些內容？
　　描述被測對象，測試的範圍，測試組織結構，測試經過/失敗的標準，測試掛起和恢復的條件，
　　測試的任務安排，人員和時間規劃，各個任務的輸入和輸出，輸入輸出標準，風險和規避措施編程

6、測試經過的標準是什麼？
　　１、需求100%覆蓋；
　　２、測試用例100%執行並經過；
　　３、全部缺陷都修改完成並回歸測試經過windows

不嚴格：
　　１、需求100%覆蓋；
　　２、中高級用例100%測試並經過，低優先級的用例60%以上測試並經過；
　　３、遺留的缺陷密度小於0.05/KLOC瀏覽器

7、項目中主要有哪些風險？如何規避？
　　１、測試過程當中人員變更；
　　２、需求變更頻繁；
　　３、開發延遲轉測試；
　　４、版本上線日期提早；
　　５、測試人員技能；
　　６、設備或工具損壞(不能及時到位)安全

規避：加班，從其它組抽調人員，招聘補充人員;
　　　作好需求跟蹤，前期需求分析和需求評審工做作好
　　　提早作好開發進度跟蹤，改變測試策略
　　　作好技能培訓，以老帶新，作好評審
　　　提早準備好備份的方案，測試環境最好提供備份環境，環境須要專人維護，提早約定好工具到位時間

8、如何評估工做量？
　　１、從測試用例規模上評估工做量
　　２、從軟件的規模上評估工做量

9、測試方案是什麼？主要包括哪些內容？
　　測試方案描述測試對象，測試範圍，測試的軟硬件環境，測試策略，測試組網結構，測試用例設計方法和標準
　　測試工具的需求和設計，測試代碼的需求和設計；

測試方案屬於技術文檔，主要解決如何測試的問題

新增（快速，完整），修改，刪除，查找，導入，導出快速新增- 快速新增-快速新增功能

10、可否舉例說明你之前的項目是如何測試的？

新增：

快速新增，select子界面
快速新增：等價類，邊界值

查詢：

單項查詢：１、每一個單項條件能正確搜索，模糊查找，精確查找，通配符查找

組合查詢：１、正交
　　　　　２、斷定表
３、逐項條件填加查詢(１、全空 100項；２、增長一個輸入條件，使查詢結果減小 80 ３、再增長一個輸入條件，使查詢結果在原來基礎上減小一直到全部查詢條件都輸入爲止　４、最後改動查詢條件，使查詢結果爲０

修改：

等價類，邊界值

刪除：
選中一個（第一個，最後一個）
選中多個(連續的，不連續的）
不選
全選
多頁（3頁以上）
刪除時取消

導出：

導入：流程分析法,等價類，邊界值

測試用例中應該避免的問題：
１、在寫用例的輸入數據和步驟描述上，應該和業務比較接近
２、在用例細分的顆粒度上要考慮業務場景，須要把握好細分的度
３、在用例中對於一些可有可無的輸入項，能夠用一句話代替；
４、優先級須要分類，大體H級的在20%左右，L級的20%左右，大部分是M級的
５、儘可能避免用例與用例之間的依賴性，要體現低藕合度的特色

select子頁面的新增：
１、全部的項都輸入，能建立成功
２、只填必填項，非必填項爲空
３、必填項爲空
４、建立同名的

11、測試執行主要作哪些事情？

開發到轉測試時間點，把版本包（開發的安裝包，用戶安裝指南,用戶使用指南，維護指南，版本配套表
代碼規模，轉測試建議）

SVN：建立轉測試目錄　B011
　　　　　　　　　　　B012
B013
同時，開發經理會通知測試經理（轉測試版本已經放在ＳＶＮ上面，能夠取版本測試）,項目經理，ＳＱＡ都會收到相似郵件

１、測試組長：

　　　轉測試版本檢查該轉的項目版本包和文檔是否齊全？是否有問題。
　　　在測試組內分本具體的測試任務（搭環境，各個測試工程師負責測試的模塊，分配測試用例）
　　　並給出測試時間安排，交付時間，注意事項等

２、環境管理員：

　　　到ＳＶＮ上面取版本，搭建測試環境，並將測試環境連接發給全部測試人員
　　　在測試執行過程，維護環境
３、測試工程師：

　　　按照組長分配的任務，執行測試，記錄測試結果
　　　提交測試缺陷單

第一輪測試完成，提交測試小結（描述測試對象，測試時間，人力，測試用例執行狀況，缺陷狀況）

隔幾天時間轉第二輪測試B012版本測試
用例選擇策略（１、優先級高的；２、第一輪未經過，發現缺陷的；３、因爲缺陷致使第一輪沒法測試，阻塞的用例
４、因爲第一輪的缺陷，修改代碼，會影響到的模塊的用例，第一輪測試已經過的）
輸出第二輪測試小結

轉第三輪測試，測試執行後輸出測試報告(總體三輪測試的總結）

12、缺陷管理流程是怎樣的？
１、提出缺陷單（簡要描述，版本號，但願修改日期，嚴重等級，重現步驟，實際結果，環境，初步定位的結論，截圖）NEW
２、主管統一審覈缺陷（直接close，重複，非問題），肯定是問題，發給開發 assign to 開發
３、開發判斷是否缺陷置爲open　修改完成之後置爲fixed，指定給測試經理
４、測試經理分配fixed狀態的缺陷給測試工程師迴歸測試　主管分配給測試工程師
５、迴歸經過 closed，不經過 open狀態

十3、若是你提交的問題，開發不承認，你會怎麼處理？
１，本身先分析確認一下，是否問題，你的理由是什麼，嚴重級別
若是是可有可無的問題，並且開發很忙，能夠暫時掛起。
若是不是可有可無的問題，能夠和開發當在溝通（把開叫到電腦前，重現問題，說明對系統的影響）j,開發可能接受該問題
若是開發當面溝通不接受，該問題必須修改，則求助測試組長來決策（郵件形式講清楚這個問題現象，對系統的影響，發送給開發人員，抄送測試經理，開發經理）

十4、測試過程當中你有沒有發現缺陷，可否舉例說明幾個印象較深的缺陷？
１、刪除的數據，在數據庫中沒有實際刪除掉，只是將一個deleted標誌字段置爲1
２、新增一個商業機會記錄時，會增長多個一樣名稱的記錄(商業機會），記錄數與user數量一致；
３、修改客戶反饋信息時，若是把客戶反饋相關聯的客戶名稱（很重要字段）改爲不存在的客戶時，能夠修改爲功。
４、不修改信息時，能夠正常導出，但若是將要導出的信息中的assign to 的字段置空，則導出時整個記錄爲空
五、在建立系統中存在同名的客戶信息時，應該要給出提示
６、選擇不連續的幾個記錄刪除時，會將選中的第一條和最後一條之間的全部記錄都刪除

十5、迴歸測試版本的用例選取的策略是什麼？
１、未經過的，未執行，阻塞的
二、因爲開發修改了問題而影響到的模塊的相關測試用例（前面執行經過的）
３、把優先級高的H級的用例作迴歸測試

十6、測試報告主要包括哪些內容？
測試報告描述測試對象（從架構，開發語言，功能，前景等角度），測試對象的版本，測試的時間人力安排,測試軟硬件環境
測試用例狀況（測試用例數量，用例密度，穩定性，執行狀況），測試版本質量（缺陷數，嚴重程度，缺陷密度）
測試結論，遺留問題列表。

十7、大家項目當中有沒有作得好的地方？有沒有作得很差的地方？好在哪裏？很差在哪裏？

好的：
測試流程比較清晰，各個階段交付件也齊全，各個交付件會通過評審並歸檔；
分工明確，配合協調，組長寫測試計劃，作數據分析，進度，協調；老員工寫方案，寫用例；新員工寫用例，執行
相互之間溝通很順暢，開發，測試相互配合比較好

很差的：
用例數寫得太少；
開發提供的版本質量太差，低級問題不少；
用例寫得很差（數據很差構造）
需求不夠明確

十8、BS與CS架構的區別，測試的側重點分別是什麼？
BS是瀏覽器/服務器架構，CS是客戶端/服務器模式
BS：使用方便，不須要安裝客戶端，只須要有瀏覽器就可以使用；安全性較ＣＳ低（用在互聯網，客戶端與服務器端安全協做性沒有ＣＳ高
有些安全要求很高的場景須要單獨安裝插件　），性能較低
測試側重點：
瀏覽器兼容性測試，插件的測試（安裝，功能）
服務器的性能測試

CS:安全性較BS高（適用專用網，局域網範圍，客戶端和服務器端安全協做性高）
性能較BS

測試側重點：
１、客戶端的安裝測試，卸載，升級測試，升級回滾
２、客戶端的功能測試

十9、什麼是兼容性測試？兼容性測試的重點是什麼？

二10、提交缺陷單時，應包括哪些內容？

標題，缺陷編號，模塊，時間，嚴重程度，詳細描述（問題重現步驟，預期結果與實際結果），附件(截圖或日誌)，問題初步分析
做用：１、記錄缺陷，以避免遺漏
２、便於測試開發之間的缺陷管理與信息傳遞
３、缺陷統計與缺陷管理

二11、如何定義缺陷嚴重級別？
致命：直接致使軟件不能正常使用（掛起，異常退出，死機,核心功能都不能使用）
嚴重：影響範圍，主要功能受影響，（缺陷影響不嚴重，可是範圍很廣），影響範圍不廣，但影響了主要功能
通常：隻影響非核心功能的缺陷，影響範圍也不大
建議：能正常使用，提示信息，界面因素相關的問題；一些優化建議類的點，其自己不是缺陷

IEEE 國際電子電氣工程師協會　International Electronic　Electric Engneer

需求的來源：
１、市場調查（調查問卷、用戶訪談）
２、競爭對手
３、內部討論
４、技術的發展

項目級的需求：有固定客戶（顯性需求、隱性需求）

需求分析：１、經過顯性需求挖掘背後的隱性需求
　　　　　２、將顯性需求和隱性需求規格化，並記錄下來，造成SRS
規格化：１、定義它的規格和單位　　２、性能規格３、接口的定義４、可靠性（其它質量特性）

基線化：造成一個標準，給其它的工做提供參考(１、管控權限管理；２、標識　版本號）

需求分析階段（測試）：１、分析測試需求，提出可測試性需求給開發人員
２、根據質量模型、功能交互、繼承性分析等方法分析測試的測試需求
３、參與需求評審（開發、測試、SQA、配置管理員、用戶表明）

項目管理是一個模塊

項目
子項：新增，修改，刪除，導入，導出，查詢

１、新增
　　編號：
　　測試方法：
　　測試要點：
　　１、
　　２、　
修改：
　　編號
　　測試方法
　　測試要點
　　　

項目任務