一、對系統整體的了解
Server端：jsp+Servlet+json
數據庫：sql、MySQL、oracle等
前台： 涉及到 jstl，jsp，js，css，htm等方面
后台：servlet，jms，ejb， 還有很多框架，struts，hibernate，spring，ibatis
Jsp：分不清前后台的，因為這里涉及到一個運行時刻的問題，它們的運行時刻是不同。
用戶發出請求后，服務器解析用戶請求，轉至對應的jsp，這個時候可以說是整個jsp都是后台程序。
而Jsp做出響應后，把響應的內容返回給瀏覽器，這個時候瀏覽器就只看見html,css,javascript，這個時候所有的程序又都是前台程序。
二、前后台bug定位
1. 前台的bug通常是功能、界面和兼容性等有關；后台的bug與性能和安全性有關。
前台bug定位：按F12在控制台中查看報錯信息，對於出錯的js可以在Sources下查看對應報錯的資源文件，寫入缺陷管理工具提交給開發即可（或者使用一些抓包工具，
抓取請求相應過程中的資源文件）
前台bug注意以下三個方面：
1）網站前台權限控制：沒有權限的用戶不能直接輸入url的方式來進行訪問，必須進行登錄。以后涉及到權限的測試，一定不能漏掉url的方式也需要驗證一下。
而在單個頁面進行W3C測試時則需要去掉該權限控制。
2）網站前台的title，對於這個也很容易忽視。進入到不同的功能頁面，title顯示應該是有，並且要和你進入的頁面一致。title就是在瀏覽器最左上角看到的那些文字
3）http和https的注意點：
https是一種安全鏈接，需要證書，所以在系統中客戶會要求某些關鍵的地方希望加上這種安全連接，那么此時你需要注意的是：對於不需要的安全鏈接的地方千萬也要去
重點測試，有些開發會很容易忽略這一點。
要打開HTTPS開頭的網站，前提是該網站安裝了SSL證書，只有安裝了SSL證書的網站，並且開啟了443端口，你才可以通過HTTPS加密協議無訪問；如果沒有則不能訪問。
比如在某個網站http協議后面加個s去訪問，看能否訪問成功，能成功，會顯示綠色安全小鎖，否則就不能訪問。
2.后台bug定位：根據后台日志文件
系統使用secureCRT進行日志獲取，或者服務器控制方面的操作（關閉和重啟）
重啟的一般情況：
1）熱部署 （新增部分功能，或者修改部分bug)
2）發布新版本 （整個系統）
3）內存溢出，此時重啟服務器即可
由於項目中有線程程序，./shutdown腳本關閉tomcat程序，不能把啟動的線程全部關閉，造成服務器啟動線程未關閉的錯誤。
Linux系統中重啟Tomcat的一般步驟：（一般是先關閉進程，然后進行重啟 ，如果/要刪除某個文件：rm 文件名，或者不為空的文件夾：rm -rf 文件夾名）
cd usr/local/ //測試服務器名稱/bin
ps -exf //看測試服務器下運行的項目的主進程（最前面的數字為PID進程號）
kill -9 PID //強制關閉某一項目的主進程
./startup.sh // ./**.sh 即執行重啟shell腳本文件 ，此時在測試服務器的bin下面，直接執行即可，其余的加上 chmod a+x shell腳本文件，也可用./執行
小知識：
ps aux和ps -ef命令區別
ps aux 是用BSD的格式來顯示java這個進程
顯示的項目有：USER,PID,%CPU,%MEM,VSZ,RSS,TTY,STAT,START,TIME,COMMAND
ps -ef 是用標准的格式顯示java這個進程
顯示的項目有：UID,PID,PPID,C,STIME,TTY,TIME,CMD）
3.如何查看日志？
一台服務器可以部署多個應用：
cd usr/local/測試服務器名稱/logs //查看先進入到服務器的logs目錄下
tail -f catalina.out //監視catalina.out 文件的尾部內容（默認10行）
4.日志中常見的問題
獲取日志文件中常遇到的問題：
1)編碼問題：tomcat是新的，需要改編碼 修改tomcat的server.xml文件<Connector port="8080" URIEncoding="UTF-8"/>
特別是windows下的項目重新部署到linux系統下，
2)空指針：程序問題，一般沒有考慮到為空情況，或者主外鍵約束的數據為空，或者刪除關聯數據，導致為空
3)長度過長，超過最大長度，測試環境修改數據庫字段長度后生產環境未修改，導致報錯！！
4)非法數據：
5)內存溢出：重啟
5.一般的問題原因總結：
程序：為空判斷，增刪改查,不同公眾號調用的接口也不一樣
數據初始化：數據庫表結構和數據初始化，權限配置，
特別注意生產環境上的用戶數據修改，此時用戶在使用，很重要！！！
故障無法重現時：
1）看日志，根據日志定位原因，則在測試環境中按照日志提示構造條件相同的測試案例測試，嘗試在測試環境中將問題重現。
2）測試環境和配置與實際的工程環境和配置有哪些差異等等。同時主動與開發負責人、工程實施人員以及有經驗的項目經理討論，分析可能導致的原因。
測試環境ok，生產環境新增時保存失敗，查看后台日志報長度溢出，數據庫內容字段要求和生產環境不一致！！
6.輔助工具：linux和SQL
linux查看日志
SQL用來篩選數據或直接進行數據修改狀態，多用於集成測試過程中前后流程相連接
三.瀏覽器兼容性和網頁規范標准測試
瀏覽器兼容性測試（偏主流瀏覽器，如谷歌，火狐，IE8以上）：
https://dev.windows.com/en-us/microsoft-edge/tools/staticscan/
W3C網頁驗證：（判斷網頁書寫是否符合規范，記住此處必須去掉權限控制，單個單元頁面url需要跟參數）
https://validator.w3.org/
W3C手機端頁面檢測（如手機微信菜單下的頁面）：
https://validator.w3.org/mobile-alpha/
互聯網測試與傳統測試的區別
1.最大的不同：互聯網產品需要自己部署和運營，用戶使用瘦客戶端（瀏覽器，app或一個需要安裝的client)，核心的數據和業務邏輯在互聯網公司的機房，在IDC，在雲端。
如：我們做的系統用戶只需一個瀏覽器，服務器用的阿里雲，部署和運營只需要一個運維人員即可。
考慮現網（生產環境）存在下面兩個問題：
（1）如何發布功能到現網
互聯網測試完一般可直接發布，測試周期短，有時候需要進行灰度發布，先讓部分用戶用起來，發布完做生產驗證。
（2）如何保證測試環境和生產環境同步
測試環境比較難搞，拿我們做的懶企鵝來說，牽扯的系統平台比較多，用到很多微信平台的接口，這個很難自己搭建或者用mock。
另外保證測試環境和到生產環境都是好的，需要代碼和數據庫，以及環境配置都要保持一致，這需要相應的機制和工具來驗證和同步。
2.互聯網產品節奏很快
有的軟件公司，基本是進行二次開發，周期長，每次都需要經過下面幾個完整的測試流程：
客戶提出需求--BA和客戶溝通，確定需求和解決方案--測試人員根據需求說明書和解決方案編寫測試用例、進行概要評審、進行詳細設計評審、開始測試、回歸測試、生產驗證。
現在的互聯網產品測試基本為：
產品經理確定好測試需求--開發人員寫詳設-（此階段可以進行設計bug檢查）--開發人員開發--測試人員測試，上線
來不及測試設計，來不及自動化，短時間內如何保證測試的覆蓋率和質量？--（探索式測試應勢而生）
3.更多的人參與到測試中
互聯網公司有專門的測試團隊的比較少，一般開發和測試比例： 7:1，如何保證質量？
1）開發人員的自測
開發人員進行單元測試，測試用例的通過率，同一個版本拉代碼的次數
2）產品或運營人員的體驗
在這里基本我就相當於用戶，進行產品體驗，或者根據免費試用者反饋的意見進行優化
3）發布之前的評審
注意環境，配置，數據方面的問題
4.有一些是免測試的
並不是所有發布到生產環境的東西都需要在測試環境檢驗，如：圖片樣式改動，小bug修復，但是哪些免測是個復雜的問題
5.海量用戶帶來的挑戰
1）性能方面
如何做輕量級的性能測試
2）瀏覽器的兼容性
現在的系統大多基於主流的火狐，谷歌，IE8以上，放棄瀏覽器兼容就等於放棄一部分客戶。
6.測試工具和技術方面
傳統的企業花錢購買商業軟件，如QTP，loadrunner，或者自己開發的項目管理工具
大部分的互聯網公司使用開源或自主研發的，如 selenium，appium，robotium,monkeyrunner,jmeter
相同點：
1.都需要非常熟悉產品和業務
2.都需要了解產品的技術（深度測試方面性能分析，內存泄露，web服務器，cache，代理)
3.具體的測試技術
4.測試設計的方法
5.測試人員的技術體系：