在一次次產品迭代中，我們都是以需求評審、迭代所需的週期、編寫測試計畫、編寫冒煙用例和全用例、評審測試用例，之後再進行介面測試、全面測試，最後測試完成，進行上線。
可能每個公司不太一樣，我目前的公司特性就是如此。
首先，從編寫用例開始。
測試用例分為：冒煙用例和全用例。
1、冒煙用例
冒煙用例就是針對研發人員，開發出來的產品，進行簡單的主流程測試，不必在意具體的細節和異常的場景。
所以在編寫冒煙用例的時候，我們應該關注的是產品的主體功能，和主線流程，不必在意具體的枝葉！所以，編寫冒煙用例不必寫太多條數，盡量做好精簡。
2、全用例
全用例，個人認為全用例就是盡可能的覆蓋產品測試的全部場景，以減少bug的產生。當然有兩種呈現方式：以數量見長、以最好的用例覆蓋最全的情況(不可太過冗雜)！
介面測試主要是對後端進行測試，在這裡以測試工具進行介紹，以postman為例：
後端介面出來之後，首先我們需要對給出的介面，進行梳理。進行簡單的介面用例整理。
根據介面用例，利用postman進行測試，首先新增乙個集合，然後再分類多個folder,在傳送介面
大致的流程就是：梳理介面業務邏輯、設計介面測試用例、利用工具或**的方式，測試介面、得出測試結果並輸出測試報告。
在介面測試中，比如像get請求，主要以查詢為主，其中查詢的資料，前端通過呼叫介面展出出來；其實想這一類問題，我們主要進行這幾方面檢查：
1、查詢的資料要求是否與需求相符合；
2、前端呼叫介面是否每個字段正確呼叫；
3、還有一種通過get請求查詢的資料，可能後面的介面會對其依賴。
而post請求，更多的是進行一些邏輯處理，主要以入參和相應資料為測試物件。入參在產品中，前端會從get請求中獲取或者從使用者操作事件中獲取；響應資料，主要是從後端邏輯計算中得出，與前端關係不大。所以主要從以下幾方面檢查：
入參：
①查詢的資料是否可以正確拿到，並做為入參；
②使用者的操作事件中是否可以正確拿到；
響應資料：
① 在入參正確情況下，響應資料是否可以正確得到；
② 通過一些異常場景的入參(有些介面入參欄位，不一定都是必填)，響應資料是否做過處理；
先到這裡，下一次分享具體的介面測試和通過抓包分析問題！
測試分析心得體會
本文出自 shaofei19820625 的51testing軟體 測試 部落格，在支付寶測試分析的角色和系統分析的角色是對應的，只不過乙個是測試類的另外乙個是開發類的。係分下面會有相應開發，測分下面會有相應的測試用例編寫和執行人員。也就是說測試分析文件是對測試執行人員的乙個指導 在我原來的理解方式...
PHP PDO 心得體會
關於pdo 我想可以不用做過多的描述，寫一寫最近的使用心得體會 首先 關於如何使用pdo 連線到資料庫 dbms mysql 使用的資料庫 host localhost 選擇的主機 dbname test 選擇的資料庫 user root 登陸的使用者名稱 password 使用者密碼 dsn dm...
銷售心得體會
銷售思維的培養 1.裝可憐讓客戶動惻隱之心是一種方法但是不適合男人 2.身處高位的銷售領導往往擁有給客戶的折扣和動用資源的優勢，不要當綠葉，要按兵不動尋找時機 3.市場上的大客戶與哪家合作就會成為標桿事件，哪家公司就會成為一線公司。4.站在客戶的角度，在業務上給予中肯的意見，得到客戶的感謝和認可。5...