1. Web測試的主要內容和測試方法有哪些
測試分類：
1、界面測試
1）給用戶的整體感：舒適感；憑感覺能找到想要找的信息；設計風格是否一致
2）各控制項的功能
2、功能測試
1）刪除/增加某一項：是否對其他項造成影響，這些影響是否都正確
2）列表默認值檢查
3）檢查按鈕功能是否正確：新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置（常見錯誤）
4）字元串長度檢查：超出長度
5）字元類型檢查
6）標點符號檢查：空格、各種引號、Enter鍵
7）特殊字元：常見%、「、」
8）中文字元：是否亂碼
9）檢查信息完整：查看信息，查看所填信息是否完整更新；更新信息，更新信息與添加信息是否一致
10）信息重復：需唯一信息處，比如重復的名字或ID、重名是否區分大小寫、加空格
11）檢查刪除功能：不選擇任何信息，按Delete，看如何處理；選擇一個或多個進行刪除；多頁選、翻頁選刪除；刪除是否有提示
12）檢查添加和修改是否一致：添加必填項，修改也該必填；添加為什麼類型，修改也該什麼類型
13）檢查修改重名：修改時把不能重名的項改為已存在的內容
14）重復提交表單：一條已經成功提交的記錄，返回後再提交
15）檢查多次使用返回鍵：返回到原來頁面，重復多次
16）搜索檢查：存在或不存在內容，看搜索結果是否正確；多個搜索條件，同時輸入合理和不合理條件；特殊字元
17）輸入信息的位置
18）上傳下載文件檢查：功能是否實現，
上傳：上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式；
下載：下載是否能打開、保存、格式要求
19）必填項檢查：必填項未填寫；是否有提示，如加*；對必填項提示返回後，焦點是否自動定位到必填項
20）快捷鍵檢查：是否支持快捷鍵Ctrl+C、Ctrl+V、backspace；對不允許做輸入的欄位（如：下拉選項），對快捷方式是否也做了限制
21）Enter鍵檢查：輸入結束後按Enter鍵，系統如何處理
22）刷新鍵檢查：按瀏覽器刷新鍵如何處理
23）回退鍵檢查：按瀏覽器回退鍵如何處理
24）空格檢查：輸入項輸入一個或多個空格
25）輸入法半形全形檢查：比如，浮點型，輸入全形小數點「。」或「. 」，如4. 5；全形空格
26）密碼檢查：輸入加密方式的極限字元；密碼盡可能長
27）用戶檢查：不同種類管理員用戶的不同許可權，是否可以互相刪除、管理、編輯；一般用戶的許可權；注銷功能，老用戶注銷再注冊，是否為新用戶
28）系統數據檢查：數據隨業務過程、狀態的變化保持正確，不能因為某個過程出現垃圾數據，也不能因為某個過程而丟失數據。
29）系統可恢復性檢查：以各種方式把系統搞癱，測試系統是否可以迅速恢復
30）確認提示檢查：系統更新、刪除操作：是否有提示、取消操作；提示是否准確；事前、事後提示
31）數據注入檢查：對資料庫注入，特殊字元，對sql語句進行破壞
32）時間日期檢查：時間、日期、時間驗證：日期范圍是否符合實際業務；對於不符合實際業務的日期是否有限制
33）多瀏覽器驗證
3、性能測試
1）壓力測試：實際破壞一個Web應用系統，測試系統的反應，測試系統的限制和故障恢復能力
2）負載測試：在某一負載級別上的性能，包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量
3）強度測試：測試對象在性能行為異常或極端條件下（如資源減少或用戶過多）的可接受性，以此驗證系統軟硬體水平
4）資料庫容量測試：通過存儲過程往資料庫表中插入一定數量的數據，看是否能及時顯示
5）預期指標的性能測試：在需求分析和設計階段會提出一些性能指標，對於預先確定的性能要求要首先進行測試
6）獨立業務性能測試：對核心業務模塊做用戶並發測試，包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能
7）組合業務性能測試：模擬多用戶的不同操作，最接近實際用戶使用情況，按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況
8）疲勞強度性能測試：系統穩定運行情況下，以一定負載壓力來長時間運行系統的測試
9）網路性能測試：准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的
10）大數據量性能測試：實時大數據量，模擬用戶工作時的實時大數據量；極限狀態下的測試，系統使用一段時間，積累一段數據量時能否正常運行，以及對前面兩種進行結合
11）伺服器性能測試：在進行用戶並發性能測試、疲勞強度、大數據量性能測試時，完成對伺服器性能的監控，並進行評估
12）一些特殊的測試：配置測試、內存泄漏的一些特殊測試
4、可用性測試(介面測試）
1）整體界面測試
2）多媒體測試
3）導航測試
5、客戶端兼容性
平台測試：windows；unix；macintosh；linux
瀏覽器測試：不同廠商的瀏覽器對Java、Javascript、ActiveX、plug-ins或不同的HTML的規格
不同的支持；框架和層次結構在不同瀏覽器也不同的顯示
6、安全性
安全性測試要求：
1）能夠對密碼試探工具進行防範
2）能夠防範對Cookie攻擊的常用手段
3）敏感數據保證不用明文傳輸
4）能防範通過文件名猜測和查看html文件內容獲取重要信息
5）能保證在網站收到工具後在給定時間內恢復，重要數據丟失不超過1小時
web的性能測試工具：
隨著Web2.0技術的迅速發展，許多公司都開發了一些基於Web的網站服務，通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。
因此，當Web網站遇到訪問高峰時，容易發生伺服器響應速度變慢甚至服務中斷。
為了避免這種情況，需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試，來測試靜態HTML頁面的響應時間，甚至測試動態網頁（包括ASP、PHP、JSP等）的響應時間，為伺服器的性能優化和調整提供數據依據。
1、企業級自動化測試工具WinRunner
MercuryInteractive公司的WinRunner是一種企業級的功能測試工具，用於檢測應用程序是否能夠達到預期的功能及正常運行。
2、工業標准級負載測試工具Loadrunner
LoadRunner是一種預測系統行為和性能的負載測試工具
3、全球測試管理系統testdirector
TestDirector是業界第一個基於Web的測試管理系統，它可以在您公司內部或外部進行全球范圍內測試的管理。
4、功能測試工具RationalRobot
IBMRationalRobot是業界最頂尖的功能測試工具，它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。
它集成在測試人員的桌面IBMRationalTestManager上，在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動，包括手動測試報告。
這種測試和管理的雙重功能是自動化測試的理想開始。
5、單元測試工具xUnit系列
目前的最流行的單元測試工具是xUnit系列框架，常用的根據語言不同分為JUnit（java），CppUnit（C++），DUnit（Delphi），NUnit（.net），PhpUnit（Php）等等。
該測試框架的第一個和最傑出的應用就是由ErichGamma（《設計模式》的作者）和KentBeck（XP（ExtremeProgramming）的創始人）提供的開放源代碼的JUnit.
6、功能測試工具SilkTest
BorlandSilkTest2006屬於軟體功能測試工具，是Borland公司所提出軟體質量管理解決方案的套件之一。
這個工具採用精靈設定與自動化執行測試，無論是程序設計新手或資深的專家都能快速建立功能測試，並分析功能錯誤。
7、性能測試工具WAS
是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。
透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。
8、自動化白盒測試工具Jtest
Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具，它通過自動實現java的單元測試和代碼標准校驗，來提高代碼的可靠性。
parasoft同時出品的還有C++test，是一款C/C++白盒測試工具。
9、功能和性能測試的工具JMeter
JMeter是Apache組織的開放源代碼項目，它是功能和性能測試的工具，100%的用java實現。
10、性能測試和分析工具WEBLOAD
webload是RadView公司推出的一個性能測試和分析工具，它讓web應用程序開發者自動執行壓力測試；webload通過模擬真實用戶的操作，生成壓力負載來測試web的性能。
(1)web項目單元測試擴展閱讀：
漏洞測試
企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的，是通過代碼堆積起來的。如果這個代碼只供企業內部使用，那麼不會帶來多大的安全隱患。
但是如果放在互聯網上使用的話，則這些為實現特定功能的代碼就有可能成為攻擊者的目標。
天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊，來獲取管理員的密碼等等破壞性的動作。
有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時，其實就有可能在安裝一個木馬（這可能訪問者與被訪問者都沒有意識到）。
為此在為網站某個特定功能編寫代碼時，就要主動出擊。從編碼的設計到編寫、到測試，都需要認識到是否存在著安全的漏洞。
天眼在日常過程中，在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。
已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關，就可以提高代碼編寫的安全性。
2. eclipse中運行web項目中的main方法或者用junit進行單元測試，都跑不起來，也不報錯
可以試試另一個可以寫java代碼的軟體名字叫intellij idea表，比myeclipse效率高多了
3. 一個spring mvc 結構的web項目如何寫單元測試，測試層輸出的結構（各層有依賴關系）
web項目的測試一幫會測試業務部分的正確性，在junit中初始化Spring，獲取類，調用類方法進行測試
4. java web項目怎麼測試
java web項目測試用Web的測試工具，如HtmlUnit，JWebUnit等。
main()方法就可以測試，在main方法中獲得connection對象將他輸出就可以了。
如果正常輸出一大串就是對了。
例子：
public class DBConnection {
private static String url = "jdbc:sqlserver://localhost:1433;DataBaseName=HXParserDB";
private static String username = "sa";
private static String password = "123";
private DBConnection(){}
private static DBConnection dbconn = new DBConnection();
private static Connection conn = null;
// 注冊驅動
static {
try {
Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver").newInstance();
} catch (Exception e) {
throw new ExceptionInInitializerError(e);
}
}
public DBConnection getDBConn(){
if(null==dbconn){
dbconn = new DBConnection();
}
return dbconn;
}
// 返回Connection對象
public static Connection getConnection() {
try {
return DriverManager.getConnection(url, username, password);
} catch (SQLException e) {
return null;
}
}
/**
* @param args
*/
public static void main(String[] args) {
System.out.println(DBConnection.getConnection());
}
}
5. SpringBoot的RestApi介面的單元測試
記錄一下SpringBoot的RestApi介面的單元測試
1.使用的junit單元測試框架,所以需要加入依賴。
2.如果是jar項目，就在單元測試的類上標注下面兩個註解。
3.如果是web項目，則還需要添加下面這個註解。
4.因為測試的是rest介面，所以，需要引入下面的請求發送工具(其他的也可以)。
5.因為是針對本項目，所以通常還會添加一個屬性，和一個方法。
6.這樣的話，當需要編寫單元測試的時候，只要直接繼承該類即可。
6. 大家java web項目開發做單元測試嗎
單元測試的好處
跟傳統的軟體工程不同，如果把網站看作一個系統的話，跟瀏覽器牽連太多了，比如http 請求對象，cookie，header這些。導致很多人開發WEB後台必須要依賴瀏覽器，不停的修改i，重啟，刷新，還有清除cookie，這會浪費很多時間。單元測試是把從瀏覽器解放出來的利器。
單元測試有一個積少成多的過程，不說純粹的TDD開發，就算沒一次修改BUG增加一些測試用例，慢慢累積起來，將為之後的重構和新BUG修復產生巨大的作用。
未來發展
互聯網公司開發周期短，時間緊。這是大多數人放棄使用單元測試的原因。無可否認，單元測試確實會在前期給開發者帶來一些時間成本。但是這個時候必須要從長遠來看，單元測試絕對是百利而無一害的投資。
7. Go: WebSockets單元測試
WebSockets通過TCP連接提供客戶端與伺服器之間的雙向即時通信。這意味著，我們可以維護一個TCP連接，然後發送和監聽該連接上的消息，而不是不斷地通過新建TCP連接去輪詢web伺服器的更新。
在Go的生態中，WebSocket協議有幾個不同的實現。有些庫是協議的純實現。另外一些人則選擇在WebSocket協議的基礎上構建，為他們特定的用例創建更好的抽象。
下面是一個不全面的Go WebSocket協議實現列表:
在線拍賣是以實時通信為核心的行業之一。在一場拍賣中，幾秒鍾的時間就決定了你是贏了還是失去了一件你一直想要的收藏品。
讓我們以gorilla/websocket庫實現的簡單拍賣應用程序作為本文的示例。
首先，我們將定義兩個非常簡單的結構體Bid和Auction，我們將在WebSocket處理程序中使用它們。 Auction 有一個Bid方法，我們將使用該方法接收客戶端發送來的競價請求。
這兩種類型都相當簡單，包含的欄位非常少。NewAuction構造函數構建一個帶有持續時間、itemID和*Bids的Aution實例。
我們將通過 Bid 方法來實現拍賣的競標動作：
Auction的Bid方法就是物品競拍發生的地方。它接收一個 amount 和 userID 作為參數，並向 Auction 對象中添加Bid實例。而且它會檢查競拍是否結束以及的競拍價格是否大於已有的最大競價。如果這些條件中的任何一個不滿足，它將向調用者返回適當的錯誤。
有了結構體定義和Bid方法，讓我們深入到WebSockets機制。
想像一下，一個可以在拍賣中實時出價的網站。它通過WebSockets發送的每一條JSON消息都會包含用戶的標識符( UserID )和出價的金額( amount )。一旦伺服器接受了消息，它將參與競價並向客戶端返回一個競拍結果。
在伺服器端，此通信將由 net/http 處理程序完成。它將處理所有WebSocket的業務邏輯，有幾個值得注意的步驟:
1、將接收到的HTTP連接升級為WebSocket連接。
2、接收來自客戶端的消息。
3、從消息中解碼出bid對象。
4、參與競價。
5、 向客戶端發送競拍結果。
下面我們來實現這個處理程序。首先定義 inbound 和 outbound 消息類型，用於接收和發送客戶端消息。
它們都分別表示入站/出站消息，這就是在客戶端和伺服器之間的交互數據。 inbound 入站消息將表示一個出價，而 outbound 類型表示一個簡單的返回消息，其Body中包含一些文本。
接下來定義 bidsHandler ，包含ServeHTTP方法實現HTTP連接的升級：
首先定義 websocket.Upgrader ，接收處理程序的 http.ResponseWriter 和 *http.Resquest 並升級連接。 因為這只是一個應用程序示例 upgrader.CheckOrigin 方法將只返回true，而不檢查傳入請求的來源。一旦 upgrader 完成連接的升級，將返回 *websocket.Conn 對象保存在 ws 變數中。 *websocket.Conn 將接收所有客戶端發送來的消息，也是處理程序讀取請求內容的地方。同樣，處理程序將會向 *websocket.Conn 寫入消息，它將向客戶端發送響應消息。
for 循環做了幾件事：首先，使用 ws.ReadMessage() 讀取websocket消息，改函數返回消息類型(二進制或文本)和消息內容( m )以及可能發生的錯誤( err )。然後，檢查客戶端是否意外地關閉了連接。
錯誤處理完成並讀取到消息，我們將使用 json.Unmarshal 對其進行解碼。接著調Bid方法參與競拍。然後使用 json.Marshal 對返回內容進行序列化，使用 ws.WriteMessage 方法發送給客戶端。
盡管編寫WebSocket處理程序比普通HTTP處理程序要復雜得多，但測試它們很簡單。事實上，測試WebSockets處理程序就像測試HTTP處理程序一樣簡單。這是因為WebSockets是在HTTP上構建的，所以測試WebSockets使用的工具與測試HTTP伺服器相同。
首先添加測試用例：
首先，我們從定義測試用例開始。每個用例有一個 name ，這是測試用例的可讀名稱。此外，每個測試用例都有一個 bids 切片和一個ration持續時間，用於創建一個測試拍賣對象 Auction 。測試用例還有一個入站消息 inbound 和一個出站回復 outbound —這是測試用例將發送給處理程序並期望從處理程序返回的消息。
在TestBidsHandler中我們添加三種不同的測試用例——一個是客戶端發起了錯誤的報價，低於目前最大報價，另一個測試用例，客戶端添加了一個正常的報價，第三個客戶端參與的拍賣已結束。
下面完成測試函數：
我們在subtest函數體中添加了一些新函數。 newWSServe r將創建一個測試伺服器並將其升級為WebSocket連接，同時返回伺服器和WebSocket連接。然後， sendMessage 函數將通過WebSocket連接將消息從測試用例發送到測試伺服器。之後，通過 receiveWSMessage ，我們將從伺服器讀取響應，並通過將其與測試用例的進行比較來斷言其正確性。
那麼，這些新的函數的作用是什麼呢？讓我們逐一分析。
newWSServer 函數使用 httptest.NewServer 函數將處理程序掛載到測試HTTP伺服器上。通過 httpToWS ，實現了將伺服器的 URL 轉為websocket URL (它只是將URL中的 http 協議替換為 ws ，或將 https 替換為 wss 協議)。
為了建立WebSocket連接，我們使用 WebSocket.DefaultDialer ，它是一個所有欄位都設置為默認值的dialer。調用 Dial 方法通過WebSocket伺服器URL (wsURL)返回WebSocket連接。
sendMessage 函數接收一個WebSocket連接和 inbound 消息作為參數。將消息序列化成json以二進制格式在websocket連接中發送。
receiveWSMessage 函數以 ws WebSocket連接為參數，通過 ws.ReadMessage() 讀取請求消息，然後反序列化成 outbound 類型返回。
如果我們運行測試，我們將看到它們通過:
8. 用maven的web 項目單元測試找不到類
pom.xml 報錯先調試好
測試類需要繼承TestCase
編譯後 arget est-classes下面要有class和測試需要的資源文件，就需要在pom.xml中加
<build><testResources><testResource><directory> src/main/resources</directory><filtering>true</filtering></testResource></testResources></build>
9. 程序員編碼時，參照什麼文檔進行web應用程序的單元測試一般做哪些內容
Web前端開發規範文檔你需要知道的事
規范目的
為提高團隊協作效率, 便於後台人員添加功能及前端後期優化維護, 輸出高質量的文檔, 特製訂此文檔. 本規範文檔一經確認, 前端開發人員必須按本文檔規范進行前台頁面開發. 本文檔如有不對或者不合適的地方請及時提出, 經討論決定後方可更改.
基本准則
符合web標准, 語義化html, 結構表現行為分離, 兼容性優良. 頁面性能方面, 代碼要求簡潔明了有序, 盡可能的減小伺服器負載, 保證最快的解析速度.
文件規范
1. html, css, js, images文件均歸檔至<系統開發規范>約定的目錄中;
2. html文件命名: 英文命名, 後綴.htm. 同時將對應界面稿放於同目錄中, 若界面稿命名為中文, 請重命名與html文件同名, 以方便後端添加功能時查找對應頁面;
3. css文件命名: 英文命名, 後綴.css. 共用base.css, 首頁index.css, 其他頁面依實際模塊需求命名.;
4. Js文件命名: 英文命名, 後綴.js. 共用common.js, 其他依實際模塊需求命名.
HTML書寫規范
1. 文檔類型聲明及編碼: 統一為html5聲明類型; 編碼統一為, 書寫時利用IDE實現層次分明的縮進;
2. 非特殊情況下樣式文件必須外鏈至…之間;非特殊情況下JavaScript文件必須外鏈至頁面底部;
3. 引入樣式文件或JavaScript文件時, 須略去默認類型聲明.
4. 引入JS庫文件, 文件名須包含庫名稱及版本號及是否為壓縮版, 比如jquery-1.7.1.min.js; 引入插件, 文件名格式為庫名稱+插件名稱, 比如jQuery.cookie.js;
5. 所有編碼均遵循xhtml標准, 標簽 & 屬性 & 屬性命名 必須由小寫字母及下劃線數字組成, 且所有標簽必須閉合; 屬性值必須用雙引號包括;
6. 充分利用無兼容性問題的html自身標簽, 比如span, em, strong, optgroup, label,等等; 需要為html元素添加自定義屬性的時候, 首先要考慮下有沒有默認的已有的合適標簽去設置, 如果沒有, 可以使用須以」data-」為前綴來添加自定義屬性，避免使用」data:」等其他命名方式;
7. 語義化html, 如 標題根據重要性用h(同一頁面只能有一個h1), 段落標記用p, 列表用ul, 內聯元素中不可嵌套塊級元素;
8. 盡可能減少div嵌套
9. 書寫鏈接地址時, 必須避免重定向，例如：href=」http://www.example.com/」, 即須在URL地址後面加上「/」；
10. 在頁面中盡量避免使用style屬性,即style=」…」;
11. 必須為含有描述性表單元素(input, textarea)添加label
12. 能以背景形式呈現的圖片, 盡量寫入css樣式中;
13. 重要圖片必須加上alt屬性; 給重要的元素和截斷的元素加上title;
14. 給區塊代碼及重要功能(比如循環)加上注釋, 方便後台添加功能;
15. 特殊符號使用: 盡可能使用代碼替代: 比如 <(<) & >(>) & 空格( ) & »(») 等等;
16. 書寫頁面過程中, 請考慮向後擴展性;
17. class & id 參見 css書寫規范.
css書寫規范
1. 編碼統一為utf-8;
2. 協作開發及分工: i會根據各個模塊, 同時根據頁面相似程序, 事先寫好大體框架文件, 分配給前端人員實現內部結構&表現&行為; 共用css文件base.css由i書寫, 協作開發過程中, 每個頁面請務必都要引入, 此文件包含reset及頭部底部樣式, 此文件不可隨意修改;
3. class與id的使用: id是唯一的並是父級的, class是可以重復的並是子級的, 所以id僅使用在大的模塊上, class可用在重復使用率高及子級中; id原則上都是由我分發框架文件時命名的, 為JavaScript預留鉤子的除外;
4. 為JavaScript預留鉤子的命名, 請以 js_ 起始, 比如: js_hide, js_show;
5. class與id命名: 大的框架命名比如header/footer/wrapper/left/right之類的在2中由i統一命名.其他樣式名稱由 小寫英文 & 數字 & _ 來組合命名, 如i_comment, fontred, width200; 避免使用中文拼音, 盡量使用簡易的單片語合; 總之, 命名要語義化, 簡明化.
6. 規避class與id命名(此條重要, 若有不明白請及時與i溝通):
a） 通過從屬寫法規避, 示例見d;
b）取父級元素id/class命名部分命名, 示例見d;
c）重復使用率高的命名, 請以自己代號加下劃線起始, 比如i_clear;
d）a,b兩條, 適用於在2中已建好框架的頁面, 如, 要在2中已建好框架的頁面代碼中加入新的div元素
7. css屬性書寫順序, 建議遵循: 布局定位屬性–>自身屬性–>文本屬性–>其他屬性. 此條可根據自身習慣書寫, 但盡量保證同類屬性寫在一起. 屬性列舉: 布局定位屬性主要包括: display & list-style & position（相應的 top,right,bottom,left） ＆ float & clear ＆ visibility ＆ overflow； 自身屬性主要包括: width & height & margin & padding & border & background; 文本屬性主要包括：color & font & text-decoration & text-align & vertical-align & white- space & 其他 & content; 我所列出的這些屬性只是最常用到的, 並不代表全部;
8. 書寫代碼前, 考慮並提高樣式重復使用率;
9. 充分利用html自身屬性及樣式繼承原理減少代碼量, 比如:這兒是標題列表2012-04- 24
定義
ul.list li{position:relative} ul.list li span{position:absolute; right:0}
即可實現日期居右顯示
10. 樣式表中中文字體名, 請務必轉碼成unicode碼, 以避免編碼錯誤時亂碼;
11. 背景圖片請盡可能使用sprite技術, 減小http請求, 考慮到多人協作開發, sprite按模塊製作;
12. 使用table標簽時(盡量避免使用table標簽), 請不要用width/ height/cellspacing/cellpadding等table屬性直接定義表現, 應盡可能的利用table自身私有屬性分離結構與表現 , 如thead,tr,th,td,tbody,tfoot,colgroup,scope; (cellspaing及cellpadding的css控制方法:table{border:0;margin:0;border-collapse:collapse;} table th, table td{padding:0;}, base.css文件中我會初始化表格樣式)
13. 如何可以請少使用兼容;
14. 用png圖片做圖片時, 要求圖片格式為png-8格式,若png-8實在影響圖片質量或其中有半透明效果, 請為ie6單獨定義背景:
_background:none;_filter:progid:DXImageTransform.Microsoft.AlphaImageLoader (sizingMethod=crop, src=』img/bg.png』);
15. 避免兼容性屬性的使用, 比如text-shadow || css3的相關屬性;
16. 減少使用影響性能的屬性, 比如position:absolute || float ;
17. 必須為大區塊樣式添加註釋, 小區塊適量注釋;
18. 代碼縮進與格式: 建議單行書寫, 可根據自身習慣, 後期優化會統一處理;
JavaScript書寫規范
1. 文件編碼統一為utf-8, 書寫過程過, 每行代碼結束必須有分號; 原則上所有功能均根據XXX項目需求原生開發, 以避免網上down下來的代碼造成的代碼污染(沉冗代碼 || 與現有代碼沖突 || …);
2. 庫引入: 原則上僅引入jQuery庫, 若需引入第三方庫, 須與團隊其他人員討論決定;
3. 變數命名: 駝峰式命名. 原生JavaScript變數要求是純英文字母, 首字母須小寫, 如iTaoLun;
jQuery變數要求首字元為』_』, 其他與原生JavaScript 規則相同, 如: _iTaoLun;
另, 要求變數集中聲明, 避免全局變數.
4. 類命名: 首字母大寫, 駝峰式命名. 如 ITaoLun;
5. 函數命名: 首字母小寫駝峰式命名. 如iTaoLun();
6. 命名語義化, 盡可能利用英文單詞或其縮寫;
7. 盡量避免使用存在兼容性及消耗資源的方法或屬性, 比如eval_r() & innerText;
8. 後期優化中, JavaScript非注釋類中文字元須轉換成unicode編碼使用, 以避免編碼錯誤時亂碼顯示;
9. 代碼結構明了, 加適量注釋. 提高函數重用率;
10. 注重與html分離, 減小reflow, 注重性能.
圖片規范
1. 所有頁面元素類圖片均放入img文件夾, 測試用圖片放於img/demoimg文件夾;
2. 圖片格式僅限於gif || png || jpg;
3. 命名全部用小寫英文字母 || 數字 || _ 的組合，其中不得包含漢字 || 空格 || 特殊字元；盡量用易懂的詞彙, 便於團隊其他成員理解; 另, 命名分頭尾兩部分, 用下劃線隔開, 比如ad_left01.gif || btn_submit.gif;
4. 在保證視覺效果的情況下選擇最小的圖片格式與圖片質量, 以減少載入時間;
5. 盡量避免使用半透明的png圖片(若使用, 請參考css規范相關說明);
6. 運用css sprite技術集中小的背景圖或圖標, 減小頁面http請求, 但注意, 請務必在對應的sprite psd源圖中劃參考線, 並保存至img目錄下.
注釋規范
1. html注釋: 注釋格式 , 『–』只能在注釋的始末位置,不可置入注釋文字區域;
2. css注釋: 注釋格式 ;
3. JavaScript注釋, 單行注釋使用』//這兒是單行注釋』 ,多行注釋使用 ;
開發及測試工具約定
建議使用WebStorm||Aptana || Dw || Vim , 亦可根據自己喜好選擇, 但須遵循如下原則:
1. 不可利用IDE的視圖模式』畫』代碼;
2. 不可利用IDE生成相關功能代碼, 比如Dw內置的一些功能js;
3. 編碼必須格式化, 比如縮進;
測試工具: 前期開發僅測試FireFox & IE6 & IE7 & IE8 & IE9 & Opera & Chrome & Safari;
其他規范
1. 開發過程中嚴格按分工完成頁面, 以提高css復用率, 避免重復開發;
2. 減小沉冗代碼, 書寫所有人都可以看的懂的代碼. 簡潔易懂是一種美德. 為用戶著想, 為伺服器著想.
10. 徒手搭建Python單元測試框架
稍微具有一定規模的企業對於軟體開發一般都會要求寫單元測試，雖然各自標准不同，有的可能要求覆蓋率達到50即可，而像我司這種竟然要求行覆蓋率和分支覆蓋率都要到95%以上。本文會手把手教你如何在項目初期搭建單元測試框架，以便能夠指導後續開發進行單元測試編寫和測試報告生成。本文適合python項目的架構師或者核心發起者。如果是小白也可以了解下單元測試是怎麼搭建的以及一些單元測試的原則。
一般項目如果是web項目都會有配置文件，那麼啟動單元測試的應用上下文也需要測試用的配置文件。下面是一個基於flask開發的web項目的單元測試配置文件。大家可以參考下。如果項目不是web項目而是腳本倉庫也可以不需要這塊。
基礎測試類會初始化測試應用上下文以及內存資料庫初始化，以及測試完成後的數據清理
測試聚合類是用來掃描所有測試模塊並運行測試用例的
python的Coverage庫是用來生成測試報的，可以通過.coverage文件配置測試報告的內存，包括忽略項，是否包含分支覆蓋率，測試報告生成位置和形式（xml或者html）等
通過運行以下coverage 模塊生成測試報告