單純從功能測試層面上來講的話，APP測試、web測試在流程和功能測試上是沒有區別的
根據兩者載體不一樣，則區別如下：
1.系統結構方面
web項目：b/s架構，基于瀏覽器的；web測試只要更新來服務器端，客戶端就會同步更新
app項目：c/s架構，必須要有客戶端；app修改來服務端，則客戶端用戶所有核心版本都需要進行回歸測試一遍。
2.性能方面
web項目 需監測 響應時間，CPU、
app項目 除了監測 響應時間，CPU、外，還需監測瀏覽，電量等。
3.兼容方面
web項目
1.瀏覽器（火狐、谷歌、IE等）
2.操作系統（、、Linux等）
app項目：
1.設備系統：iOS（iPad、）、（三星、華為、聯想等）、（Win7、Win8）、OS X（Mac）
2.手機設備可根據 手機型號、分辨率不同
4. 相對于Web項目，app有專項測試
1.干擾測試：中斷，來電，短信，關機，重啟等
2.弱網絡測試（模擬2g、3g、4g,wifi網絡狀態以及丟包情況）；網絡切換測試（網絡斷開后重連，3g切換到4g/wifi等）
5. 安裝、更新、卸載
安裝：需要考慮安裝時的中斷、弱網、安裝后刪除安裝文件等情況
卸載：需考慮卸載后是否刪除app相關的文件
更新：分強制更新，非強制更新，增包更新，斷點續傳，弱網狀態下更新
6.測試工具方面
自動化工具：APP一般使用；Web一般使用
性能測試工具：APP一般使用；Web一般使用LR
7. 界面操作
關于手機端測試，需要注意手勢，橫豎屏切換，多點觸控，前后臺切換
8. 安全測試
安裝包是否可以編譯代碼，安裝包是否簽名，權限設置，例如訪問通訊錄等
9. 邊界測試
可用存儲空間少，沒有SD卡/雙SD卡，飛行模式，系統時間有誤，第三方依賴（QQ，微信登錄）等
10. 權限測試
設置某個app是否可以獲取權限，例如是否可訪問通訊錄，相冊照相機等
一、 注冊
以等價類劃分和邊界值法來分析
用戶名字和密碼都為最大長度（邊界值分析法，取上點）用戶名字和密碼都為最小長度（邊界值分析法，取上點）用戶名字和密碼長度在最大和最小長度之間（邊界值分析法，取內點）必填項分別為空注冊用戶最大長度+1（邊界值分析法，取上點）用戶最小長度-1（邊界值分析法，取上點）密碼最大長度+1（邊界值分析法，取上點）密碼最小長度-1（邊界值分析法，取上點）用戶名含有非法字符注冊（這和可以劃分幾個無效的等價類，如空格，#等，看需求是否允許）密碼含有非法字符注冊（這個可以劃分幾個無效的等價類）兩次輸入密碼不一致（如果注冊時候要輸入兩次密碼，那么必須這個是必須的）重新注冊存在的用戶以已經注冊的用戶名（改變大小寫）來注冊。（有的需求是區分大小寫，有的是不區分）看是否支持Tab和Enter鍵等；密碼是否可以復制粘貼，密碼是否以*之類的加密符號顯示郵箱地址格式不正確，正確格式—@驗證碼錯誤（大小寫，空值，錯誤輸入等） 二、 登錄 用戶名和密碼都是正確用戶名和密碼都是錯誤用戶名正確和密碼錯誤用戶名錯誤和密碼正確用戶名或密碼為空刪除的用戶名和錯誤的密碼刪除的用戶名和正確密碼未注冊用戶名和錯誤密碼用戶名或密碼中插入空格使用Tab或Enter鍵是否能登陸改變用戶名和密碼的大小寫登陸用戶名和密碼中含有全角字符登陸Web系統是否有超時的限制登陸錯誤次數是否有限制密碼的安全性是否有強中弱鑒定 三、修改密碼 不輸入酒密碼，直接改密碼輸入錯誤舊密碼不輸入確認新密碼不輸入新密碼新密碼和確認新密碼不一致新密碼中有空格新密碼為空新密碼長度為最大長度新密碼為最大長度與最小長度之間新密碼長度為最小長度新密碼為最大長度+1新密碼為最大長度-1新密碼為最小長度+1新密碼為最小長度-1新密碼為非法字符（如有的密碼要求必須是英文和數字組成，如中文漢字）檢查是否支持Tab和Enter鍵等；密碼是否可以復制粘貼；密碼是否以*之類的加密符號檢查密碼是否區分大小寫，新密碼中英文小寫，確認密碼中英文大寫新密碼與舊密碼一樣能否修改成功 四、添加 要添加的數據項均為合理，檢查數據庫中是否添加了相應的數據流出一個必填數據為空按照邊界值等價類設計測試用例的原則設計其他輸入項的測試用例不符合要求的地方要有錯誤提示是否支持table鍵按enter是否能保存若提示不能保存，也要察看數據庫里是否多了一條數據 五、刪除 刪除一個數據庫中存在的數據，然后查看數據庫中是否刪除刪除一個數據庫中并不存在的數據，看是否錯誤提示，并且數據庫中沒有數據刪除輸入一個格式錯誤的數據，看是否有錯誤提示，并且數據庫中么有數據被刪除輸入的正確數據前加空格，看是否能正確刪除數據什么不輸入是否支持table鍵是否支持enter鍵 六、 查詢
精確查詢：
輸入的查詢條件為數據庫中存在的數據，看是否能正確地查出相應的數據輸入正確的查詢條件以前加上空格，是否能正確地查出相應的數據輸入格式或范圍不符合要求的數據，看是否有錯誤提示輸入數據庫中不存在的數據不輸入任何數據是否支持table鍵是否支持enter鍵
模糊查詢：
在精確查詢的基礎上加上以下一點：
8. 輸入一些字符，看是否查出數據庫中所有相關信息
功能測試自動化 輕量接口自動化測試 UI層面的自動化 ：UI ， Junit,，UI ，iOS：基于的iOS UI自動化 性能測試 Web前端性能測試
網絡抓包工具：
網頁文件大小
test
端性能測試
內存占用分析：MAT
iOS內存問題分析：ARC模式
性能分析
iOS 性能分析后臺服務性能測試
負載，壓力，耐久性，可擴展性，基準
工具：，，專項測試
兼容性測試
手工測試：操作系統，分辨率，rom，網絡類型
云平臺：，腳本編寫，
流量測試
自帶流量管理
iOS自帶的
抓包
Wi-Fi代理抓包：
流量節省方法：壓縮數據，json優于xml;Webp優于傳統的JPG，PNG；控制訪問的頻次；只獲取必要的數據，緩存；
電量測試
基于測試設備的方法，購買電量表進行測試
GSam Pro
IOS基于 工具
弱網絡測試
手機自帶的網絡狀態模擬工具
基于代理的弱網絡的模擬
工具：； delay
Mac： link 分析
隨著手機應用不斷狀態，同一款產品的移動端應用市場占相較PC端也越來越大，那么app與pc端針對這些產品的測試有什么相同之處與不同之處呢？
總結如下：
相同之處
一、針對同一個系統功能的測試，三端所測試的業務六月初是一樣的
二、一般情況下手機端和PC端都對應一套后臺服務，比如說某公司所開發的互聯網金融平臺，整個平臺做了分布式服務架構，后臺服務包括用戶服務，交易服務，產品服務，PC和手機端測試以上三個流程時，調用的都是同一個后臺服務。
（注：也有一些功能，比如PC與手機端展示不一致，或者有什么特殊處理，這樣情況下后臺會寫兩套不同的接口來處理對應的業務需求）
不同之處
一、 測試平臺（容器）不同：
pc項目都是在電腦上進行測試的：常見的PC項目架構有BS架構和CS架構（），后臺返回的到相應內容顯示在瀏覽器上，常見BS架構的項目比如QQ，微信等，需要在電腦下載客戶端（），客戶端與后臺服務器（）進行數據傳輸交互，基于以上信息，PC端測試都是在電腦上，要么是在瀏覽器上測試要么安裝對應客戶端，平臺都是電腦
app測試平臺分為安卓和iOS端：安卓測試需要在安卓手機上安裝開發提供的apk測試包，iOS測試需要將手機UUID提供給開發安裝ipa測試包進行測試
H5測試就是測試HMTL5頁面：在PC或者手機瀏覽器都可以直接訪問H5頁面
二、兼容性測試不同
基于以上測試平臺的不同，三端的兼容性也不一樣
PC的兼容性主要包括各個瀏覽器和不同操作系統，目前筆者所經歷的公司主要測試了不同主流版本瀏覽器的兼容性，還未涉及操作系統層面
APP的兼容性包含安卓和iOS不同機型，不同版本，不同屏幕都要適配
H5的兼容性主要測試手機端的不同瀏覽器的兼容性
三、系統架構不一樣
PC和H5端項目尤其是WEB項目對應一個后臺服務，所有客戶訪問的都是同一個后臺。上線測試時，直接訪問線上地址測試即可
APP測試雖然對應一個后臺，但是不同的用戶可一下載了不同版本的客戶端，上線測試時，需要兼容每個版本的測試。
四、發布流程不同：
PC端每次更新發布，需要將測試通過的包退換線上包，重啟服務后立即生效，訪問的就是最新的環境
H5由于是一些html5網站發布上線后無需重啟即可訪問
APP端需要向應用市場發布，安卓發布的市場有很多，應用寶，豌豆莢，應用商店等每個應用都需要單獨審核；iOS端應用比較單一就是app store。從提交，審核發到發布會有幾天的時間間隔，開發的應用包不會立即發布。
五、專項測試
除以上不同外，app端還有一些專項測試
性能方面：響應時間，流量測試和耗電量測試
安裝測試（PC端web項目不用測試，CS架構的也需要考慮）
交叉測試：就是在操作某個軟件的時候，來電話，來短信，電量不足提示等外部事件
操作類型：手勢測試，橫豎屏
網絡測試：包含弱網和網絡切換測試，重點要考慮回退和刷新是否會造成二次提交，弱網絡的模擬，據說可以用360Wi-Fi實現設置。
升級測試：升級測試的提醒機制，升級取消是否影響原有功能的使用，升級后用戶數據是否被清除了
六、啟動
app端：需要制定內容，因為里面包含了設備信息等
web端：通過啟動不同的瀏覽器類，獲取，如.(),也可以模擬手機端加載wap頁面做wap頁面測試
七、關于元素的屬性
app端：查找到元素以后，查看元素對象，發現里邊基本上只有元素的text屬性，也沒有相關方法修改，這個區別還是很大的，不過有的方法，目前還沒有嘗試，用的還是().
web端：web端簡直就是人間天堂，比起修改，讀取元素屬性，比如我要獲取input標簽的name，我可以用方法，也可以自行寫js代碼改變這些屬性。
八、使用JS
app端：似乎是支持了，但是執行任何命令端都會提示404的錯誤。
web端：支持非常好，因為本身Js就是負責網頁交互的軟件測試過程分為，所以會很方便
九、關于滑動
app端：關于滑動是會用很多的，比如頁面很長，或者打開通知欄，這種需要在屏幕上滑動的，用到的還比較多。
web端：用到的比較少，之前基本上沒有用到過。
十、異常
app端：需要注意的是其他apk給你帶來的影響，目前沒有找到很好的方式去處理這些問題，因為其他apk給你做了彈窗，比如qq異地登陸，或者短信這種推送，會影響到目前的流程。辦法肯定是解決的，我個人理解，可以在出錯之后對比一下是否在當前apk，如果不再的話則進入當前apk再做一次相關操作。
web端：很少影響，可以邊跑用例邊聊QQ，當然我只是舉個例子，總之個人體會就是影響比較小，因為瀏覽器的完全只是控制瀏覽器，別的地方和它無關。
軟件測試流程
制定測試策略
首先測試策略，當用戶提出新的需求時，測試人員應該和開發人員一起做測試需求分析，一般我們都會通過會議的形式去進行討論分析，這樣測試人員會對測試需要有個大概的了解，需要是干什么的，包括哪些功能等等，而不至于什么都不清楚不了解。
制定測試計劃
大概了解需求內容之后，要對整個測試進行預期評估，包括計劃要測試哪些方面的功能，要計劃分配哪些人員參與到測試中，哪些人負責哪個模塊，以及按照交叉測試的方法，同時還要計劃要測試的開始和結束時間，便于掌握這個測試進展等等。
編寫測試用例
測試計劃規范之后，則是進行測試用例的編寫，測試用例的編寫軟件測試過程分為，主要圍繞界面模塊而展開，如界面包括哪些按鈕，按鈕操作是否可以正常進行，其次圍繞功能來設計，然后根據不同的場景來設計，對于測試過程中，出現的缺陷問題，要在將缺陷問題記錄到測試用例“測試結果”一列，便于查找測試項測試任務情況。
形成測試報告
測試用例執行之后，對于測試過程中發現的缺陷問題，要匯報自己的測試情況并且測試中的缺陷反饋到測試工具中，便于開發人員解決，對于安排的不同模塊的負責人在測試自己對應模塊任務時，也要及時匯報自己的測試工作進度，便于測試小組掌握測試的整個進度。
測試總結及文檔編寫
按照測試用例執行完所有的測試任務，且開發人員修復完來所有的bug問題（不包含一些難以修復但不緊急的問題）測試人員需要編寫針對本次項目的測試總結，要在總結中說明，測試計劃是否按照如期執行，總測試缺陷數據多少，測試覆蓋了多少等等。
同時文檔人員要針對本次項目開發新增加的功能進行項目“升級日志”和“幫助手冊”任務的編寫，便于用戶了解并能夠快速上手使用新增的功能。
web測試常見的測試場景
下面從頁面，頁面元素，功能，提示信息，容錯性，權限，鍵盤操作部分講述常見的測試點。
1. 頁面部分 頁面清單是否完整（是否已經將所需要的頁面全部列出來了）頁面是否顯示（在不同分辨率下頁面是否存在，在不同瀏覽器版本中頁面是否顯示）頁面在窗口中的顯示是否正確，美觀（在調整瀏覽器窗口大小時，屏幕刷新是否正確）頁面特殊效果（如特殊字體效果，動畫效果是否顯示）頁面特殊效果顯示是否正確 2. 頁面元素部分 頁面元素清單（為實現功能，是否將所需要的元素全部都列出來，如按鈕，單選框，復選框，列表框，輸入框等）元素是否顯示（元素是否存在）元素是否正確（針對文字，圖形，簽章等）元素的外形，擺放位置是否合理（如按鈕，單選框，復選框，列表框，輸入框等）元素基本功能是否實現（如文字特效，動畫特效，按鈕，超鏈接等）元素的容錯性列表（如輸入框，時間列表或日歷）元素的容錯性是否正確或存在 3. 功能部分 數據初始化是否執行數據初始化是否正確數據處理功能是否執行或正確數據保存是否執行或正確是否對其他功能有影響如果影響其他功能，系統能否做出正確的反應對模塊的具體功能進行測試時可以列出功能模塊所有的功能，進行排列組合，測試所有情況查詢功能分2種–驗證操作結果， 打開網頁時自動顯示結果，則不需要特別強調；需要手工操作進行查詢，則每次在其他功能完成后進行 4. 提示信息 成功，失敗提示操作結果失敗確認提示危險操作，重要操作提示返回頁面提示后顯示的頁面 5. 容錯性 為空，非空唯一性字長，格式數字，郵編編碼，電話，電子郵件，ID號，密碼日期，時間特殊字符（對于數據庫），英文單詞，單雙引號 6. 權限部分 功能：指定用戶可以使用哪些功能，不能使用哪些功能數據：指定用戶可以處理哪些數據，不可以處理哪些數據操作：在邏輯關系上，操作前后順序，數據處理情況權限變化 7. 鍵盤操作 Tab鍵上下方向鍵Enter鍵系統設定快捷鍵 問題：什么是性能測試，什么是負載測試，什么是壓力測試？
參考答案：
性能測試：性能測試是和功能測試相對應的，根據用戶場景進行的單個用戶操作，是屬于功能測試領域，主要是驗證軟件是否可以滿足用戶的功能需求，比如，單個用戶使用系統，系統各項功能是否滿足用戶的需求。
如果把這一個用戶的操作放大，變為100個，1000個，10000個用戶同時操作軟件，驗證軟件系統是否滿足用戶需求，那么這個就是軟件性能測試。通常使用性能測試工具對軟件開展并發的訪問，同時監控系統各項指標，比如CPU，內存，網絡，磁盤等關鍵部件的使用情況，性能測試是負載測試，壓力測試，并發測試的統稱。
負載測試： 通過逐步加壓的方式類確定系統的處理能力，確定系統能承受的各項閥值。
壓力測試： 逐步增加負載，使系統某些資源達到飽和、極限甚至失效的測試，目的是用來發現系統的軟件業務處理能力，系統硬件的極限處理能力等。
網站作為一款web端軟件，是測試小伙伴們測試產品的重要組成部分，拿到一個網站，不知道怎么測試？那么按照下面10大安全問題依次尋找。
性能測試這種測試方式在發生的過程中，其中一個過渡性的工作，就是對執行過程中的問題，進行定位，對功能的定位，對負載的定位，最重要的，當然是問題中說的“瓶頸”，接觸性能測試不深，更非專家，自己的理解，瓶頸產生在以下幾方面：
網絡瓶頸，如寬帶，流量等形成的網絡環境應用服務器瓶頸，如中間件的基本配置，CACHE等系統瓶頸，這個比較常用，應用服務器，數據庫服務器以及客戶機的CPU，內存，硬盤等配置數據庫瓶頸，以為例，SYS中默認的一些參數設置應用程序本身瓶頸，這個是測試過程中最需要去關注的，需要測試人員和開發人員配合執行，然后定位逐步細化分析，先可以監控一些常用衡量CPU，內存，磁盤的性能指標，進行綜合分析，然后根據所測試系統具體情況，進行初步問題定位，然后確定更詳細的監控指標來分析。
懷疑內存不足時：
方法一：
【監控指標】： , 的Pages/sec, page read/sec, Page Fault/sec
【參考值】：如果 Page Reads/Sec比率持續保持為5 ，表示可能內存不足。
Page/Sec推薦00-20（如果服務器沒有足夠的內存處理器工作負荷，此數值將一直很高，如果大于80，表示有問題）
方法二：
根據 Disk 值分析性能瓶頸
【監控指標】： ，Pages read/sec，%Disk Time 和 Avg.Disk Queue
【參考值】：%Disk Time建議閾值90%
當內存不足時，有點進程會轉移到硬盤上去運行，造成性能急劇下降，而且一個缺少內存的系統常常表現出很高的CPU利用率，因為它需要不斷的掃描內存，將內存中的頁面移到硬盤上。
懷疑內存泄漏時
【監控指標】： ，\ Bytes和\ Set，/%Disk Time
【說明】：
資源監控中，如果\ Bytes計數器和\ Set計數器的值在長時間內持續升高，同時\ bytes計數器的值持續降低，則很可能存在內存泄漏，內存泄漏應該通過一個長時間的，用來研究分析當所有內存耗盡時，應用程序反應情況的測試來檢驗。
不安全的加密存儲
常見的問題是不安全的密鑰生成和儲存、不輪換密鑰和使用弱算法。使用弱的或者不帶salt的哈希算法來保護密碼也很普遍。外部攻擊者因訪問的局限性很難探測這種漏洞，他們通常必須首先破解其他東西以獲得需要的訪問。傳輸層保護不足
在身份驗證過程中沒有用SSL/TLS，因此暴露傳輸數據和會話ID，被攻擊者截聽，或使用過期或者配置不正確的證書。登錄信息提示
用戶登錄提示信息會給攻擊者一些有用的信息，作為程序的開發人員應該做到對登錄提示信息的模糊化，以防攻擊者利用登錄得知用戶是否存在重復提交請求
程序員在代碼中沒有對重復提交請求做限制，這樣就會出現訂單被多次下單，帖子被重復發布，惡意攻擊者可能利用此漏洞對網站進行批量灌水，致使網站癱瘓網頁腳本錯誤
訪問者所使用的瀏覽器不能完全支持 頁面里的腳本，形成“腳本錯誤”，也就是網站中的腳本沒有被成功執行，遇到“腳本錯誤”時，一般會彈出一個非常難看的腳本運行錯誤警告窗口 H5如何測試？
它跟安卓APP與iOS App有什么樣的區別呢？
&我們以往的app是使用原生態系統內核的，相當于直接在系統上操作，是我們傳統意義上的軟件，更加穩定
& H5的app先得調用系統的瀏覽器內核，相當于是在網頁中進行操作，較原生app穩定性稍差，似乎還沒有百萬級用戶量的H5app
&H5最大的優點是可以跨平臺，開發容易，app的話需要用的語言和iOS的語言各自寫，H5只要開發一套
&簡單來說：H5是基于web，基于客戶端
H5測試應該從哪些方面考慮？ 業務邏輯相關
除基本的功能測試之外，H5頁面的測試，需要關注以下幾點：
1.1登陸
目前H5與各個客戶端都做來互通，所以大家在測試的時候要注意兩點：
a)若客戶端已登錄，那么進入H5后仍然是登錄狀態
b)若客戶端未登錄，進入H5，點擊對應按鈕OR鏈接
如果需要登錄，須拉起登錄；
若取消登錄，是否可再次拉起登錄，或者停留在頁面是否有對應的登錄提示。
1.2翻頁
遇到翻頁加載的頁面，需要注意內容為1頁或者多頁的情況；
a）數據分頁加載時，注意后續頁面請求數據的正確
ps:這個需要注意在快操作場景中，請求頁數是不是依次遞增，快速操作。
（如第一頁尚未出來的時候仍然繼續上拉操作）時是否發出對應的請求了。
1.3刷新與返回
A、下拉刷新是否仍然處于當前頁面
B、用戶主動點擊刷新按鈕是否仍然處于當前頁面
C、點擊返回與back鍵，回退頁面是否是期望頁面