易於理解
易於建立
易於維護
足夠的覆蓋
足夠的效率
測試是將需求在複述一遍，一切的用例設計都要和需求保持一致，要以「測什麼」為核心，而不是可以測什麼或者怎麼測
測試集上描述需求，測試應該是自文件的
每個測試用例驗證且只驗證乙個概念（通用概念）
測試用例的名稱清晰表達其目的
測試用例之間不要相互依賴
把環境及配置從指令碼中分離出來
明確的setup（環境準備）和teardown（環境拆除）
盡可能的使用三層模型--資料驅動的測試
在業務規則層描述需求
在使用者工作流層組合技術活動以實現乙個使用者使用流程！
易於 理解，易於建立，易於維護！
在使用者工作流中使用三階段模式：given，when，then
最小化和穩定化依賴
減小關鍵字的可見範圍，以最小化依賴和影響
只把關鍵字暴露到需要使用的層次
盡量維持底層的庫的穩定
乙個反模式：任何使用者介面的改變都會影響到底層的庫
分離關注點
分離關注點這些原則背後的基本指導原則，它意味著：「業務或需求領域的乙個小的變化只對應著測試用例的乙個小的變化」
把測試當做需求的第二面
以可執行文件為目標組織測試
提前定義測試（例如：與需求分析的同時定義測試）
在定義測試的同時對需求進行概念驗證
嘗試驗收測試驅動開發（atdd）和例項化需求（sbe）等實踐
用例首先是給人閱讀的
建立可以在機器上執行的指令碼非常容易，但是用例首先應該是讓人閱讀的
用意圖來命名測試和測試步驟
清晰的層次，在每個層次上保持同樣的抽象級別
持續重構測試用例
用文件的方式來組織測試集，或者用測試集生成文件（rf）
讓業務人員一起來評審測試用例和測試指令碼
像對待**一樣對待指令碼
使用配置管理，工作在共同的分支上
加入到持續整合系統中去
關注測試的框架和設計
用更好的ide，特別是能夠支援重構的ide
建設設計和開發能力
持續重構，持續執行
管理手工和自動測試
明確自動化測試的開發者和使用者都是不可分離的
自動化測試應該是防止bug的紗窗，而不是蒼蠅拍
更早、更頻繁的測試
建立自動化測試和手動測試之間的質量迴圈：當有bug越過紗窗，應該考慮如何完善紗窗（維護指令碼）
嘗試在同乙個工具中管理手動測試和自動化測試
擁抱開源
你將得到的好處：
經過證明的設計
豐富的庫
實用的工具鏈
和業界同步的演講
社群互動和支援
節省成本
職業安全
記得反饋社群！
總結：測試即需求！
指令碼即**！
感謝何勉先生（上海貝爾公司精益和敏捷教練）的知識分享
物件導向設計所需要遵循的六個原則
在物件導向的開發中，主要遵循的有以下6個設計原則 單一職責 開放封閉 黎克特制代換，依賴倒轉，迪公尺特法則，合成 聚合復用 下面將具體介紹這些設計原則 單一職責原則 就乙個類而言，應該僅有乙個引起它發生變化的原因 如果乙個類的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會削弱這個或者抑制...
軟體測試應遵循的八條原則
軟體測試，從不同的角度出發會派生出兩種不同的測試原則。從使用者的角度出發，就是希望通過軟體測試能充分暴露軟體中存在的問題和缺陷 從開發者的角度出發，就是希望測試能表明軟體產品不存在錯誤，已經正確地實現了使用者的需求。中國軟體評測中心的測試原則，就是從使用者和開發者的角度出發進行軟體產品測試的。為了達...
web介面測試中需要測試的幾個點
web介面測試用例要包括欲測試的功能 應輸入的資料和預期的輸出結果，只有在資料能正確流入 流出模組的前提下,其他測試才有意義。下面介紹在web測試介面時一些需要注意的點 1 介面返回 資料格式是否與預期一致。例如 要求返回json格式的資料，json資料的key命名是否正確，對應的value是否與資...