上週部門主管，給我們培訓了在開發過程中關於自測的話題，自測到底怎麼去測，測試力度到底多大？下面給大家分享下培訓內容，往大家吐槽。。。
單元測試（指對軟體中的最小可測試單元進行檢查和驗證）
功能測試（對產品的各功能進行驗證，根據功能
測試用例
，逐項測試，檢查產品是否達到使用者要求的功能）
整合測試（也叫
組裝測試
或聯合測試。在
單元測試
的基礎上，將所有模組按照設計要求（如根據結構圖〕組裝成為子系統或系統，進行整合測試）
場景測試（假設的故事，用來幫助人們理解乙個複雜的問題或者系統）
系統測試（將已經確認的軟體、
計算機硬體、外設
、網路等其他元素結合在一起，進行資訊系統的各種
組裝測試
和確認測試
，系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案）
a測試 （使用者在模擬真實環境下進行測試，有測試人員參與）
β 測試（由軟體的乙個或多個使用者在實際使用環境下進行的測試）
注：按測試設計方法分類劃分為：白盒、黑盒、灰盒
1、簡介
檢查程式功能是否按照需求規格說明書的規定正常使用，程式是否能適當地接收輸入資料而產生正確的輸出資訊。
2、黑盒測試的目的
功能不正確或遺漏；
介面錯誤；
輸入和輸出錯誤；
資料庫訪問錯誤；
效能錯誤； （效能錯誤是什麼意思？）
初始化和終止錯誤等。
3、黑盒測試的方法：
等價劃分法（解決如何選擇適當的資料子集來代表整個資料集的問題，通過降低測試的數目去實現「合理的」覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷）
邊界值分析法（對輸入或輸出的邊界值進行測試的一種黑盒測試方法）
錯誤推測法（在測試程式時，人們可以根據經驗或直覺推測程式中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試用例的方法）
因果圖法（從用自然語言書寫的
程式規格說明的描述中找出因（輸入條件）和果（輸出或程式狀態的改變），可以通過因果圖轉換為
判定表）
判定表驅動法（是分析和表達多邏輯條件下執行不同操作的情況的工具）
正交試驗設計法（研究多因素多水平的又一種設計方法，它是根據正交性從全面試驗中挑選出部分有代表性的點進行試驗，這些有代表性的點具備了「均勻分散，齊整可比」的特點，正交試驗設計是分析因式設計的主要方法。是一種高效率、快速、經濟的
實驗設計
方法。）
功能圖法
場景法4、測試流程：
測試計畫
測試設計
測試開發
測試執行
測試評估（測試覆蓋域或跟蹤報告）
5、黑盒測試常用方法：
6、開發對待測試
沒有測試的概念
沒有測試的方法和經驗
認為測試是測試人員的工作
開發的時間都不夠，那有時間進行測試
認為自己開發的程式是完美的
開發人員和產品使用人員思維方式不一樣，測試的效果不好
但是我們依然需要做自我測試
出現bug時，分析的時間比修正錯誤的時間花費更多
bug過多，頻繁的打斷開發的工作節奏、影響開發的士氣
再談開發人員和測試人員的比例
人 們經常還是喜歡糾纏在一些具體的數字上，特別是西方人更是喜歡用資料說明問題，因為那樣客觀 具體，但同時也往往將人引入歧途，容易形上學，因為每個公司 公司的每個產品 產品的各個專案或各個階段都不同，沒法用一刀切的辦法。在軟體企業，面對測試經理，常常被問的問題是 你們公司的開發人員和測試人員的比例多少...
開發人員自測能力提公升扯淡筆記
一 和功能質量的保證僅僅靠測試人員的測試是不夠，自測是保證 質量最基本要求。至於測試專業術語對開發人員並不了解，不重要，筆記下日常遇到的測試技巧，僅 思路，以下名稱都是自取的。1 拆分測試，經常我們會遇到乙個功能或者乙個方法，裡面很龐大，但是我們修改bug的時候，僅僅是涉及到裡面的某個介面 或其它 ...
IT開發人員
其路五 轉行到市場 絞盡腦汁的想想，我所知道的人之中只有兩個開發人員去了市場，這兩個人都不能說是朋友，認識而已。他們都是主動要求去了市場，結果是這兩個人均在市場都是乾到一年左右，然後都自已開公司了。呵呵，很奇怪，極高的轉行成功率！不過仔細想想，我對這兩個人的思路佩服的五體投地。能下決心仍掉每月5 6...