1. 基礎(chǔ)環(huán)境搭建
2. 1.LNMP:linuc(操作系統(tǒng))，nginx,mysql,php
3. 2.WAMP:windows,apache,mysql,php

測(cè)試的目的：以最小的人力 、物力和時(shí)間找出軟件中潛在的錯(cuò)誤和缺陷

軟件測(cè)試原則：

1. 證明軟件中存在缺陷；
2. 不能窮盡測(cè)試；
3. 測(cè)試應(yīng)該盡早介入；
4. 28原則；（80%的用戶只用到20%的功能，80%的錯(cuò)誤都出現(xiàn)在20%的地方）
5. 不存在缺陷謬論；
6. 妥善保存一切文檔；

測(cè)試的基本要求：

1. 外觀界面測(cè)試；
2. 易用性測(cè)試；
3. 兼容性測(cè)試；
4. 安全性測(cè)試；
5. 性能測(cè)試；
6. 功能測(cè)試；

測(cè)試與開發(fā)模型：

1. 需求分析（閱讀需求文檔，產(chǎn)品文檔，產(chǎn)品詳細(xì)設(shè)計(jì)書，分析需求的點(diǎn)， 參與需求評(píng)審）
2. 制定測(cè)試計(jì)劃和測(cè)試方案

• 測(cè)試計(jì)劃：測(cè)試整個(gè)項(xiàng)目的總體的規(guī)劃（測(cè)試范圍，進(jìn)度的安排，人力物力的安排，整體測(cè)試策略，風(fēng)險(xiǎn)評(píng)估，風(fēng)險(xiǎn)的規(guī)避）
• 測(cè)試方案：（被測(cè)試的目標(biāo)，選取什么樣的測(cè)試工具，測(cè)試的方法，測(cè)試的重點(diǎn)）

3.設(shè)計(jì)測(cè)試用例：

4.執(zhí)行測(cè)試用例：

5.評(píng)估階段；（測(cè)試報(bào)告）

開發(fā)模型

1. 瀑布模型（ 瀑布模型是文檔驅(qū)動(dòng)的模型，遵守這個(gè)約束可使軟件維護(hù)變得比較容易一些，從而顯著降低軟件預(yù)算）
2. 增量模型（把瀑布弄下的順序特征與快速原型法的迭代特征相結(jié)合，將軟件看作一系列的增量，在開發(fā)過程的各次迭代中，每次完成其中一個(gè)增量 ）
3. 快速模型（快速建立起來的可以在計(jì)算機(jī)上運(yùn)行的程序）
4. 螺旋開發(fā)模型、迭代開發(fā)模型、敏捷開發(fā)模型；

測(cè)試模型

1. V模型（描述了基本的開發(fā)過程和測(cè)試模型）
2. W模型（測(cè)試伴隨整個(gè)軟件開發(fā)周期，而且測(cè)試的對(duì)象不僅僅是程序、需求、功能和設(shè)計(jì)同樣要測(cè)試，測(cè)試與開發(fā)是同步進(jìn)行的，從而有利于盡早的發(fā)現(xiàn)問題）

測(cè)試與開發(fā)的關(guān)系

1. 目標(biāo)相同
2. 相輔相成
3. 側(cè)重點(diǎn)不同：開發(fā)側(cè)終于從無到有，從有到優(yōu)，

軟件測(cè)試分類

1. 測(cè)試（開發(fā)）階段：

• 單元測(cè)試（編碼完成前或后；模塊 類 函數(shù) 方法；開發(fā)人員，白盒測(cè)試人員）
• 集成測(cè)試（模塊已經(jīng)完成編碼；模塊與模塊之間的內(nèi)容；開發(fā)人員和白盒測(cè)試人員）
• 系統(tǒng)測(cè)試（程序 軟件 APP 系統(tǒng) 網(wǎng)站 項(xiàng)目；集體測(cè)試；開發(fā)白盒黑盒）
• 驗(yàn)收（交付）測(cè)試（α測(cè)試 β測(cè)試；媒體用戶）

2.是否覆蓋源碼：

• 黑盒測(cè)試：不覆蓋源碼，功能測(cè)試（UI、業(yè)務(wù)功能、文檔、易用性、安裝卸載、兼容性）、性能測(cè)試（一般性測(cè)試、穩(wěn)定性、負(fù)載測(cè)試、壓力測(cè)試）
• 白盒測(cè)試：覆蓋源碼，透明的可以看到源碼 ；（語句覆蓋、判斷覆蓋、條件覆蓋、路徑覆蓋）
• 灰盒測(cè)試：關(guān)系輸入輸出、考慮程序運(yùn)行的狀態(tài)

3.是否運(yùn)行：

• 靜態(tài)測(cè)試：測(cè)試程序的結(jié)構(gòu)、接口是否正常、程序過程、代碼的風(fēng)格是否符合標(biāo)準(zhǔn)；
• 動(dòng)態(tài)測(cè)試：

4.是否自動(dòng)化：

• 手工測(cè)試：
• 自動(dòng)化測(cè)試：

5.地域測(cè)試：

• 本地化測(cè)試
• 國(guó)際化測(cè)試

6.其他測(cè)試分類：

• 回歸測(cè)試
• 冒煙測(cè)試
• 隨機(jī)測(cè)試（monkey）
• 探索測(cè)試

測(cè)試用例：

定義：測(cè)試用例又叫test csse ,是為某個(gè)特殊目標(biāo)而編制的一組測(cè)試輸入、執(zhí)行條件以及預(yù)期結(jié)果，一遍測(cè)試某個(gè)程序路勁或核實(shí)是否滿足某個(gè)特定需求。

特性：

• 有效性：測(cè)試用例的能夠被使用，且被不同的人員使用測(cè)試結(jié)果一致。
• 可復(fù)用性：良好的測(cè)試用例具有重復(fù)使用的功能，如：回歸測(cè)試；
• 易組織性：好的測(cè)試用例會(huì)分門別類地提供給測(cè)試人員參考和使用；
• 可評(píng)估性：從測(cè)試管理的角度，測(cè)試用例的通過率和軟件缺陷的數(shù)目是軟件產(chǎn)品質(zhì)量好壞的測(cè)試標(biāo)準(zhǔn)；
• 可管理性：從測(cè)試管理的角度，測(cè)試用例的通過率和軟件缺陷的數(shù)目是軟件產(chǎn)品質(zhì)量好壞的測(cè)試標(biāo)準(zhǔn)；

測(cè)試用例的要素：

1. 測(cè)試編號(hào)：編號(hào)由字符和數(shù)字組合成的字符串，用例編號(hào)具有唯一性、容易識(shí)別
2. 測(cè)試項(xiàng)目/模塊：屬于哪個(gè)項(xiàng)目或者被測(cè)試的需求、被測(cè)試的模塊、 被測(cè)試的單元等
3. 預(yù)置（前提）條件：執(zhí)行測(cè)試用例需要的前提條件，如果前提條件不滿足，則后面的測(cè)試步驟不能進(jìn)行或者得不到預(yù)期結(jié)果；
4. 測(cè)試輸入：測(cè)試用例執(zhí)行過程中需要加工的外部信息，根據(jù)測(cè)試用例的具體條件有手工輸入、數(shù)據(jù)庫(kù)等；
5. 預(yù)期輸出：測(cè)試用例的預(yù)期輸出結(jié)果，包括返回值內(nèi)容、界面響應(yīng)結(jié)果等；
6. 操作步驟：執(zhí)行當(dāng)前測(cè)試用例需要經(jīng)過的操作步驟，需要明確的給出一個(gè)步驟的描述，測(cè)試用例執(zhí)行人員可以根據(jù)該步驟完成測(cè)試用例
7. 測(cè)試用例標(biāo)題：簡(jiǎn)單描述，描述測(cè)試用例的測(cè)試點(diǎn)，每個(gè)測(cè)試用例的標(biāo)題不能重復(fù)，因?yàn)閭?cè)重點(diǎn)不一樣；
8. 級(jí)別：重要程度的區(qū)分
9. 其他要素：設(shè)計(jì)者、日期、開發(fā)人員、結(jié)果、類型；

測(cè)試用例的設(shè)計(jì)原則：明確性、代表性、間接性

測(cè)試用例設(shè)計(jì)方法總結(jié)：

測(cè)試用例的本質(zhì)（基于需求）

• 理解需求，反應(yīng)需求
• 需求會(huì)變化，則測(cè)試用例也應(yīng)該會(huì)變化
• 及時(shí)響應(yīng)變更比遵循計(jì)劃更有價(jià)值

原則

• 根據(jù)程序的重要性和一旦發(fā)生故障帶來的損失，來確定測(cè)試等級(jí)和測(cè)試重點(diǎn)
• 認(rèn)真選擇測(cè)試策略。用盡可能少的測(cè)試用例發(fā)現(xiàn)盡可能多的錯(cuò)誤。測(cè)試用例不足會(huì)導(dǎo)致風(fēng)險(xiǎn)的增大；測(cè)試過度導(dǎo)致資源的浪費(fèi)。需要找到平衡點(diǎn)

方法選取

• 先關(guān)注主要功能業(yè)務(wù)流程、業(yè)務(wù)邏輯是否正確現(xiàn)實(shí)、考慮場(chǎng)景
• 需要輸入數(shù)據(jù)的地方，考慮等價(jià)類劃分法
• 在任何情況下都使用邊界法
• 如果程序的功能中包含輸入條件的組合情況，則選取因果圖和判定表法
• 對(duì)于配置類軟件，需要考慮參數(shù)的組合情況，考慮使用正交排列法
• 對(duì)照程序邏輯，如果發(fā)現(xiàn)沒有達(dá)到要求的覆蓋標(biāo)準(zhǔn)，適當(dāng)補(bǔ)充更多的測(cè)試用例
• 采用錯(cuò)誤推斷法，追加其他測(cè)試用例

測(cè)試用例的審評(píng)

1. 同行審評(píng)：“個(gè)體和叫交互比過程和工具更有價(jià)值”由測(cè)試小組內(nèi)部進(jìn)行相互評(píng)審，達(dá)到思想的碰撞，通過探討、協(xié)作完成測(cè)試用例的設(shè)計(jì)
2. 用戶評(píng)審：顧客的協(xié)作比合同談判更有價(jià)值/·如果測(cè)試是對(duì)產(chǎn)品的批判，則顧客指最終用戶或者顧客代表/在公司內(nèi)部可以是市場(chǎng)調(diào)查人員或者相關(guān)領(lǐng)域?qū)＜?strong>/ ·如果測(cè)試是為軟件開發(fā)提供幫助和支持，那么顧客就是程序員。

缺陷的基本概念

• 定義：缺陷就是問題，最終表現(xiàn)為所需要的功能沒有完全實(shí)現(xiàn)，沒有滿足用戶的需求
• 具體包含（程序、數(shù)據(jù)、文檔）：
• 1.未達(dá)到需求規(guī)格說明書中的功能
• 2.出現(xiàn)了需求規(guī)則說明書中指名不會(huì)出現(xiàn)的錯(cuò)誤
• 3.功能超出了需求規(guī)格說明書的范圍
• 4.未達(dá)到需求說明書中雖然沒有指明，但應(yīng)該達(dá)到的目標(biāo)
• 5.測(cè)試人員或者用戶認(rèn)為軟件難以理解、不易使用、運(yùn)行速度慢或者最終用戶認(rèn)為不好

表現(xiàn)形式

• 功能、特性沒有實(shí)現(xiàn)或者部分實(shí)現(xiàn)
• 設(shè)計(jì)不合理、功能特性不明確，邏輯不清楚或者存在矛盾
• 產(chǎn)品實(shí)際結(jié)果和所期望的結(jié)果不一致
• 沒有達(dá)到需求規(guī)格說明書所規(guī)定的性能指標(biāo)
• 運(yùn)行出錯(cuò)、中斷、崩潰、界面混亂
• 數(shù)據(jù)不正確、精度不夠、不完整、格式不統(tǒng)一
• 用戶不能接受的其他問題，超時(shí)、界面丑陋
• 硬件或者系統(tǒng)軟件上存在的其他問題

缺陷產(chǎn)生的原因：

• 需求解釋或者記錄錯(cuò)誤
• 用戶需求說明存在錯(cuò)誤
• 編碼說明、程序代碼有誤
• 硬件或者系統(tǒng)存在錯(cuò)誤
• 文檔、內(nèi)存不正確、拼寫錯(cuò)誤

缺陷產(chǎn)生的根源

• 交流不充分
• 軟件的復(fù)雜性
• 開發(fā)任務(wù)的錯(cuò)誤
• 需求的變化
• 進(jìn)度壓力

缺陷的修復(fù)費(fèi)用：越到后期缺陷修復(fù)的費(fèi)用越高