1、對系統總體的瞭解javascript
Server端：jsp+Servlet+jsoncss
數據庫：sql、MySQL、oracle等html
前臺： 涉及到 jstl，jsp，js，css，htm等方面java
後臺：servlet，jms，ejb， 還有不少框架，struts，hibernate，spring，ibatislinux
Jsp：分不清先後臺的，由於這裏涉及到一個運行時刻的問題，它們的運行時刻是不一樣。web
用戶發出請求後，服務器解析用戶請求，轉至對應的jsp，這個時候能夠說是整個jsp都是後臺程序。spring
而Jsp作出響應後，把響應的內容返回給瀏覽器，這個時候瀏覽器就只看見html,css,javascript，這個時候全部的程序又都是前臺程序。sql
2、先後臺bug定位shell
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.測試人員的技術體系：
