測試計畫一般使用word文件編寫,測試計畫一般包括如下幾項:
1: 前言 各種描述
1.1: 編寫目的:
編寫該計畫的目的就是為了規範測試流程,以及梳理測試過程,使測試時間可控,提前預告測試風險,在規定範圍內完成專案的測試
1.2: 名詞解釋:
致命缺陷: 就是測試的時候軟體發生崩潰,以及資料丟失的bug,造成主要功能完全尚失的bug
嚴重缺陷: 主要功能沒有實現,導致嚴重的問題
一般缺陷: 不太嚴重的錯誤，這樣的缺陷雖然不影響系統的基本使用，但沒有很好的實現功能，沒有達到預期的效果。如：次要功能喪失，提示資訊不太正確，或使用者介面太差，操作時間長等。
1.3: 參考資料:
產品原型圖 張三 說明
ui效果圖: 李四
需求文件 王五
1.4:測試摘要：
說明：主要說明測試計畫中重要的和可能有爭議的問題。主要目的是將這些資訊傳遞給那些可能不會通讀整個測試計畫文件的人員（比如公司領導、專案經理、產品經理等）。可以考慮以下幾塊內容
比如：1.4.1重點事項：
web 端功能測試,效能測試,相容測試
移動端功能測試,效能測試,相容測試(android 和 ios)。
1.4.2 爭議事項：
產品沒有提供最終的原型圖,導致測試計畫可能不是特別精確,
ui沒有提供完成的ui效果圖,也會導致測試計畫不準確
在聊天使用的第三方的時候沒有確定使用環信還是融雲,所有有可能造成延期
1.4.3風險評估:
由於效果圖沒有出完,所有可能比設定原型圖難,所以有可能造成延期
1.4.4時間進度:
web: 2017-11-30 - 2017-12.1 測試時間 李四
android: 2017-11.30-2017.-12-1 張三
ios 2017-11-30 - 2017-12.1 王五
1.4.5測試目標:
致命缺陷不存在,嚴重缺陷不存在,一般缺陷基本沒有,除非有由於第三方原因造成的不可改變因素,.
2: 資源需求 做測試需要哪些東西
硬體資源需求:
1: window電腦一台和mac電腦一台或者linux系統一台
2: android
小公尺: note2,小公尺6,小公尺5,小公尺4,note3 ,紅公尺3,紅公尺note4x,紅公尺note4
三星: note8 ,note7,s8,s7,s6 主流機型
oppe: r11 r11plus r11s r11splus, r9 r9s
vivo: x20 最新手機,x20plus ,x9 去年發布的 x9 plus
華為: mate10 mate9 榮耀9 榮耀10
魅族: x6 pro6 去年 pro7 pro7plus 魅藍 note5 note 5s note6
如果有可能測試系統android 4.0 到8.0
測試這些機型遇到過什麼問題?
1: 比如 小公尺手機: 如果拍照不處理,會出現**會旋轉90度,這個問題網上有辦法,能判斷是不是旋轉90度,如果旋轉了90度,在儲存之前將旋轉過來
2: 在拍照的時候手機會幫我們儲存兩張圖,一張是點陣圖,一張是原生圖,位圖清晰度特別低,我們會重點開發載入的是不是清晰度特別低,如果是清晰度特別低,這就是位圖,讓他改掉,載入原圖,但是三星手機在拍照的時候儲存的原圖有9m 左右,一般伺服器會限制**的大小,所以我們會看看能不能上傳成功,同時取伺服器看看這張的大小,如果上傳的大於4m的圖,而且上傳成功了,這就是伺服器的bug,讓伺服器去限制上傳的大小,限制上傳大小的原因就在於節約頻寬,節省流量,等上傳介面沒問題了,我再去用三星手機拍照看看能不能上傳成功,如果失敗,讓安卓開發對進行二次取樣,把圖縮小到可接受範圍
3: 華為手機彈出dialog,手機的螢幕會有色差
4: android 6.0 以前的手機可以拍照, 6.0 以後許可權是動態註冊是,如果開發沒做適配就會出現6.0 以前的手機可以拍照,但是6.0 以後就不能拍照啦
5: 魅族有時候不會彈出輸入框
ios:
1: 從4s 測試到 8x手機
系統的話如果公司要求比較高就從 ios 6 測試到 ios 11 系統
蘋果手機相容性行問題比較少.
軟體資源:
1: bug 管理工具 禪道 , bugfree,jair ,(需要一套linux伺服器,比如阿里雲)2: web測試 瀏覽器 火狐 主流瀏覽器版本號: 最新的是55 最低一般測試到 38
ie 瀏覽器 如果要求比較高就從 6 測試到 12,ie測試有個相容測試工具ietester
谷歌瀏覽器: 從 41 測試到 62 測試幾款主流的版本號
mac 專用瀏覽器 safari 瀏覽器
效能測試: jmerer /loadrunner,一台電腦併發可以做2000,公司根據需要併發的情況配置電腦或者購買伺服器
安全測試: 使用第三方工具
,讀介面進行sql注入
自化測試工具:
web: python + selenium
介面自動化: python + 網路請求框架(request)
持續整合: jenkins,用來設定多久跑一邊自動化指令碼 :
人力需求:
1: 測試經理: 負責編寫測試計畫,負責測試用例的安排以及審核,人員的排程,以及測試環境的搭建
2: 測試人員: 張三: 負責android 登陸模組, 註冊模組 ,主頁 ,以及web端的功能
3: 測試人員: 李四: 負責ios端的: 登陸模組, 註冊模組 ,主頁
3: 測試詳述 具體測試範圍 風險與約束 測試進度
3.1:具體測試範圍
主要測試登陸模組
3.2風險與約束
可能由於技術崗畢業,技術不成熟,造成專案延期
3.3:測試進度
模組 名字 時間
登陸 張三 2017.12.1 -2017.12.1.5
3.4: 測試目標:
1: ui效果圖必須實現
2: 產品邏輯互動必須與產品原型圖保持一致
3: 登陸的使用者名稱必須加密
4:必須https請求
4: 測試策略
4.1: 採用敏捷式和瀑布式相結合,同時採用自動化測試來輔助加快進度
` 1: 在版本迭代的時候新增的功能採用手動測試
2: 在開發開始的期間我們對老版本的功能寫自動化指令碼,同時寫測試用例
3: 接了節約時間,在測試的時候自動化和功能同步進行,如果事件還不夠,自動化分為連個電腦去跑
4: 使用持續整合去介面自動化,避免介面不能使用造成上線失敗
4.2: 測試型別:
1: 做功能測試和灰盒測試 根據產品文件,ui效果圖和需求文件進行
2: 相容測試: 根據資源需求裡面的裝置進行相容測試
3: 效能測試: 等穩定以後,在上線前夕,對介面進行效能測試,模擬大併發,如果響應時間太長,做效能優化
4: 安全測試: 使用安全測試工具對介面掃瞄進行安全測試
5: 自動化測試: 使用自動化測試來輔助功能測試,來提高效率
4.3: 測試技術:
1: 灰盒測試:
2: 效能測試: jmere /loadrnnner
3:相容測試:
5: 測試提交文件
1: 測試計畫
2: 測試用例
3:測試報告
6: 質量目標
致命缺陷不存在:
嚴重缺陷不存在:
一般缺陷不存在: 除非第三方原因造成的
7: 計畫審核記錄
ceo 簽字
總監簽字:
專案經理簽字:
android效能專項測試流程和學習計畫
前陣子一直在研究效能測試，但是困難挺大的，公司也主要是功能測試為主，也沒有大神帶帶我這個小白 於是自己乙個人滾滾爬爬一直停在指標啊，工具的學習上面，網上的文章也都是介紹某個效能工具的使用，就沒有乙個介紹測試人員該怎麼去做專項測試，流程是什麼，然後突然靈感一發，就有了這篇文章 後續會逐漸豐滿這個流程的...
測試計畫編寫
1.文件的要求 好的模板是經驗和智慧型的積累，是團隊的財富。它可以將乙個團隊中最好的工作方法迅速傳播給每個成員。從而使整個團隊的戰鬥力增強。大企業不惜重金引入 模板 例如，聯想。2.微軟實踐 從做好需求開始 要像法律條文一樣。剛性不強的法律執行起來難度很大，容易偏差。3.軟體測試計畫的目標 計畫先行...
軟體測試計畫
1.測試計畫是什麼？是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源 時間 風險 測試範圍和預算等方面的綜合分析和規劃，保證有效的實時軟體測試。2.為什麼要制定測試計畫？1 對專案執行過程過程中的風險進行分析，並制定相關的應對策略 2 把知識和經驗轉化為執行任務的具體方法 3 促進團隊間關...