一.定義
通過手動點擊或者工具對被測對象進行測試操作，驗證實際的結果是否和預期的結果之間存在差異

二.軟件測試的作用
1.通過測試工作可以發(fā)現(xiàn)并修復軟件當中存在的缺陷，從而提高用戶對產(chǎn)品的使用信心
2.測試可以記錄軟件運行過程中產(chǎn)生的一些數(shù)據(jù)，從而為決策提供數(shù)據(jù)支持
3.測試可以降低同類型產(chǎn)品開發(fā)遇到問題的風險

三.測試的原則 （在執(zhí)行測試的時候必須遵守的規(guī)則）
1.測試證明軟件存在缺陷
2.不能執(zhí)行窮盡測試-----有些功能是沒有辦法將所有的測試情況都邏輯出來，所有任何的測試操作都有結束的時間
3.缺陷存在群集現(xiàn)象-----核心功能占20％，非核心占80％，主要集中測試核心的功能，發(fā)現(xiàn)缺陷的幾率就會高于80％，所以遇到缺陷都會集中在20％的功能模塊里
4.某些測試需要依賴特殊的環(huán)境
5.測試在項目當中應早介入
6.殺蟲劑現(xiàn)象---同樣的一個測試用例不能重的執(zhí)行多次，否則會對它產(chǎn)生免疫
7.不會存在缺陷謬論，任何軟件都不可能是完美的

四.測試對象的介紹
        軟件不僅僅只有功能需要測試，可以將軟件分為三個部分：功能集合+使用說明書+配置數(shù)據(jù)
        1.需求分析階段：各種需求規(guī)格說明書
        2.軟件架構設計：API接口文檔（接口測試）
        3.編碼實現(xiàn)階段：源代碼--白盒測試，單元測試
        4.系統(tǒng)測試：軟件功能主題

    五.測試的級別
        軟件的開發(fā)都會依據(jù)相應的開發(fā)模式，則測試級別指的就在這個模型當中我們認為定義的開發(fā)步驟。
        1.單元測試---在軟件測試中指組成軟件最小的底層代碼結構，一般是類，函數(shù)，組成
        2.集成測試---將多個單元模塊組合在一起，驗證之間溝通的橋梁是否能正常測試
        3.系統(tǒng)測試---對軟件的功能主體進行測試
        4.驗收測試
            （1）a測試----內(nèi)側
            （2）β測試----公測
        驗收測試的核心就是讓用戶對當前軟件買單

    六.系統(tǒng)測試
            1.功能測試：驗收當前的軟件主體功能是否可用
           2，兼容性測試：驗收當前軟件在不同的環(huán)境下是否還可以使用。
            3，安全測試：驗證軟件是否是能授權用戶提供功能使用。
            4，性能測試：相對于當前軟件消耗的資源它的產(chǎn)出能力。

    七.常見的系統(tǒng)測試方法
        1.按測試對象來進行分類
            （1）.白盒測試---主要測試的是軟件的底層代碼，不在意界面，只要求底層的功能是否實現(xiàn)，邏輯是否正確
            （2）.黑盒測試---指被測軟件外在主體功能是否可用，屬于功能性測試
            （3）.灰盒測試---接口測試
        2.按測試對象是否執(zhí)行來進行分類
            （1）.靜態(tài)測試---測試執(zhí)行不執(zhí)行
            （2）.動態(tài)測試---軟件在真實的使用環(huán)境下進行測試
        3.按測試手段進行分類
                （1）.手動測試---所謂的黑盒測試，對被測對象來進行測試，使被測得對象可以靈活的改變測試操作借環(huán)境
                （2）.自動化測試---分為兩種，一種是自己寫的測試腳本，另一種是通過第三方工具對被測對象進行測試，可以高效率的去執(zhí)行一些人工無法實現(xiàn)的操作

    八.軟件的質(zhì)量特性
                是基于ISO組織制定的，分為六大特征：
                1.功能性：軟件需要滿足用戶顯示或者穩(wěn)式的功能
                2.易用性：軟件易于學習和上手使用
                3.可靠性：指軟件必須實現(xiàn)需求當中指明的具體功能
                4.效率型：軟件的性能
                5.可維護性：需求軟件具有將某個功能修復之后繼續(xù)使用的功能
                6.可移植性：從當前的一個平臺移植到另一個平臺上

    九.軟件測試流程
     流程： 
            從產(chǎn)品接到需求開需求會，確立需求文檔，測試就應該編寫測試計劃，根據(jù)需求文檔進行編寫測試用例，開發(fā)進行編碼，等編碼結束后對主要功能進行冒煙測試，測試執(zhí)行測試用例，如果發(fā)現(xiàn)bug就進行提交bug。例如禪道之類，當開發(fā)修改后對bug進行再次的回歸測試（1.bug是否已經(jīng)解決，2.解決后的bug是否對正常的功能有影響）如果bug修改完成測試必須將bug的狀態(tài)修改為關閉，如果bug沒有修改或者是修改后對其他的功能進行影響則bug必須重新打開并再次進行提交

如果公司內(nèi)部沒有需求文檔或者是API文檔你怎么做測試：
1. 根據(jù)公司的產(chǎn)品進行對同行業(yè)或是同類軟件進行分析，找到相關文檔。
2. 根據(jù)跟人經(jīng)驗對軟件進行測試
3. 先做到UI頁面和業(yè)務邏輯是否匹配 在進行功能模塊的實現(xiàn)能否正常 然后在整個軟件進行系統(tǒng)分析并實現(xiàn)，然后開展性能測試或者是接口測試
4. 沒有api文檔的時候 進行接口測試 可以通過抓包工具（charles /fiddler）來獲取接口相關信息（url 請求方式 參數(shù) 響應結果等）進行對單個接口測試或者是通過接口錄制（bodboy 對web端進行錄制 jmeter對移動端的錄制） 實現(xiàn)多接口或者一個業(yè)務場景進行接口測試
5.進行性能測試或者是自動化測試

測試計劃
測試背景，測試目的，測試需求，測試用例及評審執(zhí)行的進度，bug跟蹤，風險評估
如何做測試用例的評審？
1.是否覆蓋測試需求上的所有功能點，不違背產(chǎn)品原型和代碼設計，用例設計的結構安排是否清晰合理，有利于高效覆蓋需求
2.用例是否具有可執(zhí)行性，前提條件、執(zhí)行步驟和預期結果是否正確，有明確的驗證方法。優(yōu)先級安排是否合理
3.是否從用戶層面來設計用戶使用的場景和業(yè)務流程
4.是否包含充分的異常測試用例
5.是否簡潔，不冗余，復用性強
十.設計測試用例
用例的設計點：
1.功能上測試
2.UI頁面
3.性能測試
4.安全測試
5.弱網(wǎng)測試
6.易用性測試

十一.回歸測試及缺陷跟蹤
1. 回歸測試指的就是當我們將某個缺陷提交給開發(fā)之后，由他們進行修復，修復完成之后需要測試人員再次對其進行測試（回歸測試）
2. 缺陷跟蹤：指的就是當測試人員發(fā)現(xiàn)某個缺陷之后需要一直對其進行狀態(tài)的跟蹤
Day2筆記
測試用例定義：
要素：用例編號所屬模塊前提條件測試輸入預期結果實際結果
備注版本測試人測試日期
測試方法：等價類劃分法，因果圖法，邊界值法，場景法，正交表法，錯誤推斷測法。

測試用例的評審：
評審內(nèi)容
評審的內(nèi)容有以下幾個方面
1)用例設計的結構安排是否清晰、合理，是否利于高效對需求進行覆蓋。
2)優(yōu)先極安排是否合理。
3)是否覆蓋測試需求上的所有功能點。
4)用例是否具有很好可執(zhí)行性。例如用例的前提條件、執(zhí)行步驟、輸入數(shù)據(jù)和期待結果是否清晰、正確期待結果是否有明顯的驗證方法。
5)是否已經(jīng)刪除了冗余的用例。
6)是否包含充分的負面測試用例。充分的定義，如果在這里使用2&8法則，那就是4倍于正面用例的數(shù)量，畢竟一個健壯的軟件，其中80%的代碼都是在"保護"20%的功能實現(xiàn)。
7)是否從用戶層面來設計用戶使用場景和使用流程的測試用例。
8)是否簡潔，復用性強。例如，可將重復度高的步驟或過程抽取出來定義為一些可復用標準步驟

分為組內(nèi)和組外評審：
組內(nèi)評審的人員：測試Leader和 測試人員
組內(nèi)評審著重與1.用例的冗余性
2.用例的準確性
3.用例的覆蓋度70%-80%
4.用例滿足需求
組外評審：測試leader測試人員 項目經(jīng)理 產(chǎn)品經(jīng)理
組外評審：1.是否滿足軟件的需求
2.用例覆蓋率
3.用例的執(zhí)行性
4.用例的復用性
5.用例是否具有正反的用例
6.編寫用例的模板
7.非功能性測試用例的編寫
8.缺陷率在執(zhí)行的測試用例中的占比
開發(fā)團體人員：5：1
10人開發(fā)團隊 1 UI 5個后臺開發(fā) 2個移動端 1個測試/運維 1產(chǎn)品
項目開發(fā)周期：6個月
版本迭代：大版本1個半月 小版本 1周
測試分工：功能界面性能+接口 自動化