工做總結--如何定位web系統先後臺的bug，以及bug分析/測試感想

對於web項目前臺和後臺bug定位分析：
一. 系統總體瞭解
懶企鵝營銷服務平臺用的架構：
web前端: Bootstrap 3.0 組件豐富,兼容性好,界面美觀
Server端: jsp+Servlet+json 公司技術力量儲備豐富,技術成熟,有不少成熟的模塊能夠直接使用
數據庫: mySql 免費,相對成熟
前臺: 涉及到jstl，jsp，js，css，html方面比較多
後臺：servlet，jms，ejb， 還有不少框架，struts，hibernate，spring，ibatis等，咱們用的是Struts和spring框架，shrio控制權限
jsp分不清先後臺的，由於這裏涉及到一個運行時刻的問題，它們的運行時刻是不一樣。
用戶發出請求後，服務器解析用戶請求，轉至對應的jsp，這個時候能夠說是整個jsp都是後臺程序。
而Jsp作出響應後，把響應的內容返回給瀏覽器，這個時候瀏覽器就只看見html,css,javascript，這個時候全部的程序又都是前臺程序。
最近的鎖行業服務項目總結：

互聯網金融軟件：營銷服務平臺的鎖服務行業
鎖行業：
1.多用戶（對權限）
鎖匠：只能發佈產品和發貨，派單自動派本身
鎖廠：發佈和發貨，派單由派單管理員進行
派單管理員：只負責派單，可是全部權限都有
用戶：不使用系統，但只能看到拉取本身的鎖匠發佈的產品和鎖廠發佈的
2.多平臺（手機端，電腦端，各種微信公衆號）
服務號：銷售產品
企業號：提供服務，內部成員使用，搶單和派單
系統：提供產品和訂單管理的服務平臺
3.關聯性強：
類別 ---產品---產品訂單---服務訂單，刪除任一個（如產品），致使列表list加載錯誤，主外鍵約束（不能刪除），前臺刪除，查找關聯信息時爲空，可是要求不爲空，就會報錯：加載失敗！！
解決方法：
方案1：加上二次校驗，刪除時進行提示，有相關聯的數據，不能刪除:
方案2：刪除後把相關聯的改爲未分類！！
4.流程複雜：
發佈產品---權限控制
購買--付款--發貨--收貨--上門服務--服務完畢--評價--完成
購買--未付款前取消訂單，發貨後不能取消訂單
開始服務要在發貨後才能夠，評價只能在服務結束後

二.先後臺bug定位
1. 前臺的bug一般是功能、界面和兼容性等有關。後臺的bug與性能和安全性有關。
前臺bug定位：按F12在console中查看報錯信息，對於出錯的js能夠在Sources下查看對應報錯的資源文件，寫入禪道提交給開發便可

前臺bug注意如下三個方面：
 （1）網站前臺的權限控制：沒有權限的用戶是不能直接輸入url的方式來進行訪問的，必須進行登陸。之後涉及到權限的測試，必定不能漏掉url的方式也須要驗證一下。而在單個頁面進行W3C測試時則須要去掉該權限控制。
（2）網站前臺的title，對於這個也很容易忽視。進入到不一樣的功能頁面，title顯示應該是有，而且要和你進入的頁面一致。title就是在瀏覽器最左上角看到的那些文字
（3）http和https的注意點：https是一種安全連接，它是須要證書的，而http就是普通連接，因此在你的系統中客戶會要求某些關鍵的地方但願加上這種安全鏈接，那麼此時你須要注意的是，對於不須要的安全連接的地方千萬也要去重點測試，有些開發會很容易忽略這一點。
你要打開HTTPS開頭的網站，前提是該網站安裝了SSL證書，只有安裝了SSL證書的網站，而且開啓了443端口，你才能夠經過HTTPS加密協議無訪問。若是沒有則不能訪問。
你可要測試，好比在某個網站http協議後面加個s去訪問，看可否訪問成功，能成功，會顯示綠色安全小鎖，不然就不能訪問。給你舉幾個安裝了ssl證書，可要https訪問的網站，1號店，天貓，淘寶，支付寶，百度，沃通CA，工信部網站等等

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.通常的問題緣由總結：
程序：爲空判斷，增刪改查,不一樣公衆號調用的接口也不同
數據初始化：數據庫表結構和數據初始化，權限配置，

特別注意生產環境上的用戶數據修改，此時用戶在使用，很重要！！！服務號一個月4條，所有使用掉了！！

故障沒法重現時：
（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）瀏覽器的兼容性
例如：實習時測試的中國移動的CRM系統只針對IE瀏覽器，因此對瀏覽器兼容性沒有太大的要求
可是如今的系統大多基於主流的火狐，谷歌，IE6以上，放棄瀏覽器兼容就等於放棄一部分客戶。
6.測試工具和技術方面
傳統的企業花錢購買商業軟件，如QTP，loadrunner，或者本身開發的項目管理工具 DMP
大部分的互聯網公司使用開源或自主研發的，如 selenium，appium，robotium,monkeyrunner

相同點：
1.都須要很是熟悉產品和業務
2.都須要瞭解產品的技術（深度測試方面性能分析，內存泄露，web服務器，cache，代理)
3.具體的測試技術
4.測試設計的方法

因此基本的大方向是沒有變化的，仍是技術至上，附一張蟲師關於測試人員的技術體系共勉！