3.4 測試案例
軟件測試常用白盒測試和黑盒測試，一般開發(fā)階段做白盒測試，測試階段做黑盒測試。這里的測試案例是為黑盒測試準備的，內容因各個項目而異，例如：
- 所有模塊的可見頁面是否齊全，是否《系統(tǒng)設計》、《需求說明書》（若有《產(chǎn)品規(guī)格說明書》一并參考）中列出的都有。
- 可見頁面的所有鏈接是否都工作正常。
- 可見頁面的動態(tài)數(shù)據(jù)是否符合邏輯流程和商業(yè)要求。
- 表單提交頁面是否能通過非常規(guī)測試。
- 可見頁面是否滿足美工UI頁面，如果字體顏色不對、圖標位置錯誤等等，都要予以糾正。
- ……
項目組和客戶各自寫一份《測試測試》，彼此不能交換文檔。一般項目組習慣側重于功能、技術、邏輯等，客戶側重于界面、是否符合工作流程、是否滿足需求等；如果互相交換文檔，有時受先入為主的影響而局限測試案例的設計思想，有時項目時間過于緊張，文檔編寫人員會抄襲，這是不負責任的。
文檔格式例子見表5。
唯一標識符 |
測試案例編號 |
依存關系 |
類別/模塊 |
測試區(qū)域 |
需求說明書編號 |
特征/功能 |
測試步驟 |
正確結果 |
1 |
1A |
|
登錄 |
檔案系統(tǒng) |
2.1 |
錄入員正確登錄 |
1) 打開IE窗口，訪問http://192.168.1.88/login.jsp
2) 輸入帳號ql1，密碼1234 |
1) 顯示登錄頁面
2) 進入index.jsp頁面 |
2 |
1B |
|
登錄 |
檔案系統(tǒng) |
2.1 |
錄入員錯誤登錄 |
1) 打開IE窗口，訪問http://192.168.1.88/login.jsp
2) 輸入帳號fafadf，密碼fadfadsf |
1) 顯示登錄頁面
2) 停留在登錄頁面，頁面提示帳號或密碼不正確 |
3 |
2A |
1A |
錄入員主頁 |
檔案系統(tǒng) |
2.2 |
錄入員主頁 |
1) 執(zhí)行1A
2) 點擊“檔案管理”
3) 點擊“檔案類型” |
1) 頁面顯示“檔案管理”和“檔案類型”兩個鏈接
2) 轉向3A
3) 轉向4A |
表 5
4. 開發(fā)階段
4.1 版本號列表
建議用版本控制器管理所有的文檔和代碼，這里假設組織使用SVN和有版本操作規(guī)范，規(guī)范定義了項目版本管理所需的角色、分支規(guī)定、版本號命名規(guī)定、使用者如何check in和check out文件、如何合并分支等等。
開發(fā)階段、測試階段、發(fā)布階段的版本號各不相同，項目經(jīng)理編寫《版本號列表》，提交版本服務器管理人員創(chuàng)建版本號、使用者帳號及其權限。然后發(fā)送文檔給項目人員，成員據(jù)此操作。當一個階段結束時，項目經(jīng)理把所有檢查過的、合格的文件并入主干中。
4.2 開發(fā)、測試、發(fā)布環(huán)境配置表
配置表主要列有：
- 統(tǒng)一開發(fā)人員PC的開發(fā)工具，五花八門的開發(fā)工具有時會引發(fā)五花八門的錯誤，化時間去解決這些錯誤是無益的；
- 各階段，版本服務器的訪問地址和物理路徑；
- 各階段，軟件的運行網(wǎng)址和服務器數(shù)據(jù)庫的物理路徑；
- 如果有外部設備，列出各階段這些設備的訪問地址和物理路徑。
4.3 項目經(jīng)理的代碼檢查結果表
一般項目經(jīng)理在開發(fā)中期和末期各進行一次代碼檢查，當然，如果時間充裕，檢查次數(shù)越多越好。開展這項活動前，項目經(jīng)理要肯定項目組的努力和現(xiàn)階段成果，告訴成員盡早發(fā)現(xiàn)錯誤是好事，這能避免返工、繞開錯誤、提升軟件的健壯性和穩(wěn)定性。
如果有特殊原因，項目經(jīng)理可以委托他人執(zhí)行這項活動，但必須對結果表進行復檢和評估，對重要模塊、重要SQL語句復查。代碼檢查所需的時間沒有公式可循，一般開發(fā)時間越多代碼越多，可以根據(jù)開發(fā)時間乘以某個百分率得到代碼檢查所需時間，這個百分比根據(jù)組織經(jīng)驗得出。
完成公共類、公共設置、幾個重要基礎模塊的開發(fā)后，要開展第一次代碼檢查，這能及時發(fā)現(xiàn)錯誤；檢查范圍是代碼、SQL語句、服務器配置、外掛設備配置等等。如果開發(fā)人員多為新手，檢查力度盡量細致到每個文件；如果開發(fā)人員經(jīng)驗豐富，檢查力度可以粗一些，集中在業(yè)務邏輯、數(shù)據(jù)IPO等部分，對于不正確的格式問題，是要糾正，但不是代碼檢查的核心重點。開發(fā)人員根據(jù)項目經(jīng)理的結果表修復錯誤，一般會輪循1-3次，如果超過3次以上，要引起注意和找原因。
文檔格式例子見表6，但內容不限于此：
項目名稱：…… 項目編號：…… 檢查人：……
檢查服務器
服務器配置 |
通過與否 |
備注 |
JBoss配置文件 |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
Apache配置文件 |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
數(shù)據(jù)庫配置文件 |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
檢查SVN代碼
系統(tǒng)模塊 |
子模塊 |
文件名 |
通過與否 |
備注 |
………… |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
檢查SQL語句
系統(tǒng)模塊 |
子模塊 |
SQL語句 |
通過與否 |
備注 |
………… |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
………… |
………… |
□ 是 □ 否 |
[不通過的，列出不合格的原因和修復人員] |
- |
表 6
4.4 開發(fā)人員的代碼檢查結果表
這項活動在開發(fā)快結束時進行一次，當然，如果時間充裕，檢查次數(shù)越多越好。開展活動前，依舊地，項目經(jīng)理要肯定項目組的努力和現(xiàn)階段成果云云。
開發(fā)人員交叉檢查模塊，自己開發(fā)的模塊不能自己檢查，這是原則。檢查的范圍是代碼和SQL語句。同樣，這部分工時沒有公式可循，建議寬松計算，每個開發(fā)人員的檢查和修復時間約等于項目經(jīng)理檢查時間。開發(fā)人員根據(jù)代碼結果表修復錯誤，一般會輪循1-3次，如果超過3次以上，要引起注意和找原因。
文檔格式例子見表7，但內容不限于此：
項目名稱：……
項目編號：……
檢查人：…… (一個開發(fā)人員填寫一份表格)
檢查SVN代碼
檢查SQL語句
其他檢查
(這部分的檢查可以是任意方面的，填寫格式不限，只要描述清楚) |
表 7
開發(fā)人員除了找出代碼缺陷外，還可以學習優(yōu)秀的編碼技巧。
4.5 架構客戶硬件平臺
開發(fā)中期或末期，派人員到客戶處架構運行軟件所需的硬件平臺，注意，只是硬件，開發(fā)中的軟件不包括在內。一個很有趣的現(xiàn)象——架構硬件是很簡單易見的事務，但常常被初級項目經(jīng)理忽略，在這特別列出以示提醒。
作者：林佩雯
【?發(fā)表評論?0條?】