各種測試用例簡要模板
0 .? 文檔介紹
提示：請用戶根據(jù)項目的實際測試狀況，裁剪本測試用例模板。
0.1?文檔目的
?
0.2?文檔范圍
?
0.3?讀者對象
?
0.4?參考文獻
提示： 列出本文檔的所有參考文獻（可以是非正式出版物），格式如下：
[ 標(biāo)識符 ]? 作者，文獻名稱，出版單位（或歸屬單位），日期
例如：
[ AAA ] ? 作者，《立項建議書》，機構(gòu)名稱，日期
?[ SPP-PROC-ST ] ? SEPG，系統(tǒng)測試規(guī)范，機構(gòu)名稱，日期
0.5?術(shù)語與縮寫解釋
縮寫、術(shù)語 解 釋
SPP精簡并行過程， Parallel Process
…
1 .? 接口－路徑測試用例
1 .1? 被測試對象（單元）的介紹
1.2 測試范圍與目的
1 . 3 測試環(huán)境與測試輔助工具的描述
1.4 測試驅(qū)動程序的設(shè)計
1.5 接口測試用例
接口A的函數(shù)原型
輸入/動作期望的輸出/相應(yīng)實際情況
典型值…
邊界值…
異常值…
接口B的函數(shù)原型
輸入/動作期望的輸出/相應(yīng)實際情況
典型值…
邊界值…
異常值…
…
1.6 路徑測試的檢查表
檢查項 結(jié)論
數(shù)據(jù)類型問題
（1）變量的數(shù)據(jù)類型有錯誤嗎？
（2）存在不同數(shù)據(jù)類型的賦值嗎？
（3）存在不同數(shù)據(jù)類型的比較嗎？
變量值問題
（1）變量的初始化或缺省值有錯誤嗎？
（2）變量發(fā)生上溢或下溢嗎？
（3）變量的精度不夠嗎？
邏輯判斷問題
（1）由于精度原因?qū)е卤容^無效嗎？
（2）表達式中的優(yōu)先級有誤嗎？
（3）邏輯判斷結(jié)果顛倒嗎？
循環(huán)問題
（1）循環(huán)終止條件不正確嗎？
（2）無法正常終止（死循環(huán)）嗎？
（3）錯誤地修改循環(huán)變量嗎？
（4）存在誤差累積嗎？
內(nèi)存問題
（1）內(nèi)存沒有被正確地初始化卻被使用嗎？
（2）內(nèi)存被釋放后卻繼續(xù)被使用嗎？
（3）內(nèi)存泄漏嗎？
（4）內(nèi)存越界嗎？
（5）出現(xiàn)野指針嗎？
文件I/O問題
（1）對不存在的或者錯誤的文件進行操作嗎？
（2）文件以不正確的方式打開嗎？
（3）文件結(jié)束判斷不正確嗎？
（4）沒有正確地關(guān)閉文件嗎？
錯誤處理問題
（1）忘記進行錯誤處理嗎？
（2）錯誤處理程序塊一直沒有機會被運行？
（3）錯誤處理程序塊本身就有毛病嗎？如報告的錯誤與實際錯誤不一致，處理方式不正確等等。
（4）錯誤處理程序塊是“馬后炮”嗎？如在被它被調(diào)用之前軟件已經(jīng)出錯。
…
2.? 功能測試用例
2 .1? 被測試對象的介紹
2 .2 測試范圍與目的
2. 3 測試環(huán)境與測試輔助工具的描述
2 .4 測試驅(qū)動程序的設(shè)計
2 .5 功能測試用例
功能A描述
用例目的
前提條件
輸入/動作期望的輸出/相應(yīng)實際情況
示例：典型值…
示例：邊界值…
示例：異常值…
功能B描述
用例目的
前提條件
輸入/動作期望的輸出/相應(yīng)實際情況
……
3.? 健壯性測試用例
3 .1? 被測試對象的介紹
3 .2 測試范圍與目的
3. 3 測試環(huán)境與測試輔助工具的描述
3 .4 測試驅(qū)動程序的設(shè)計
3 .5 容錯能力 / 恢復(fù)能力測試用例
異常輸入/動作容錯能力/恢復(fù)能力造成的危害、損失
示例：錯誤的數(shù)據(jù)類型…
示例：定義域外的值…
示例：錯誤的操作順序…
示例：異常中斷通信…
示例：異常關(guān)閉某個功能…
示例：負荷超出了極限…
4 .? 性能測試用例
4 .1? 被測試對象的介紹
4 .2 測試范圍與目的
4. 3 測試環(huán)境與測試輔助工具的描述
4 .4 測試驅(qū)動程序的設(shè)計
4 .5 性能測試用例
性能A描述
用例目的
前提條件
輸入數(shù)據(jù)期望的性能（平均值）實際性能（平均值）
性能B描述
用例目的
前提條件
輸入數(shù)據(jù)期望的性能（平均值）實際性能（平均值）
……
5 .? 圖形用戶界面測試用例
5 .1? 被測試對象的介紹
5 .2 測試范圍與目的
5. 3 測試環(huán)境與測試輔助工具的描述
5 .4 測試驅(qū)動程序的設(shè)計
5 .5 測試人員分類
類別特征
A類
B類
……
5.6? 用戶界面測試的檢查表
檢查項測試人員的類別及其評價
窗口切換、移動、改變大小時正常嗎？
各種界面元素的文字正確嗎？（如標(biāo)題、提示等）
各種界面元素的狀態(tài)正確嗎？（如有效、無效、選中等狀態(tài)）
各種界面元素支持鍵盤操作嗎？
各種界面元素支持鼠標(biāo)操作嗎？
對話框中的缺省焦點正確嗎？
數(shù)據(jù)項能正確回顯嗎？
對于常用的功能，用戶能否不必閱讀手冊就能使用？
執(zhí)行有風(fēng)險的操作時，有“確認”、“放棄”等提示嗎？
操作順序合理嗎？
有聯(lián)機幫助嗎？
各種界面元素的布局合理嗎？美觀嗎？
各種界面元素的顏色協(xié)調(diào)嗎？
各種界面元素的形狀美觀嗎？
字體美觀嗎？
圖標(biāo)直觀嗎？
…
6.? 信息安全性測試用例
6 .1? 被測試對象的介紹
6 .2 測試范圍與目的
6. 3 測試環(huán)境與測試輔助工具的描述
6 .4 測試驅(qū)動程序的設(shè)計
6 .5 信息安全性測試用例
假想目標(biāo)A
前提條件
非法入侵手段是否實現(xiàn)目標(biāo)代價－利益分析
……
假想目標(biāo)B
前提條件
非法入侵手段是否實現(xiàn)目標(biāo)代價－利益分析
……
7.? 壓力測試用例
7 .1? 被測試對象的介紹
7 .2 測試范圍與目的
7. 3 測試環(huán)境與測試輔助工具的描述
7 .4 測試驅(qū)動程序的設(shè)計
7 .5 壓力測試用例
極限名稱A 例如“*并發(fā)用戶數(shù)量”
前提條件
輸入/動作輸出/響應(yīng)是否能正常運行
例如10個用戶并發(fā)操作
例如20個用戶并發(fā)操作
…
極限名稱B
前提條件
輸入/動作輸出/響應(yīng)是否能正常運行
…
8.? 可靠性測試用例
8 .1? 被測試對象的介紹
8 .2 測試范圍與目的
8. 3 測試環(huán)境與測試輔助工具的描述
8 .4 測試驅(qū)動程序的設(shè)計
8 . 5?可靠性測試用例
任務(wù)A描述
連續(xù)運行時間
故障發(fā)生的時刻故障描述
……
統(tǒng)計分析
任務(wù)A無故障運行的平均時間間隔（CPU小時）
任務(wù)A無故障運行的最小時間間隔（CPU小時）
任務(wù)A無故障運行的*時間間隔（CPU小時）
任務(wù)B描述
連續(xù)運行時間
故障發(fā)生的時刻故障描述
……
統(tǒng)計分析
任務(wù)B無故障運行的平均時間間隔（CPU小時）
任務(wù)B無故障運行的最小時間間隔（CPU小時）
任務(wù)B無故障運行的*時間間隔（CPU小時）
9.? 安裝 / 反安裝測試用例
9 .1? 被測試對象的介紹
9 .2 測試范圍與目的
9. 3 測試環(huán)境與測試輔助工具的描述
9 .4 測試驅(qū)動程序的設(shè)計
9 . 5?安裝 / 反安裝測試用例
配置說明
安裝選項描述是否正常使用難易程度
全部
部分
升級
其它
反安裝選項描述是否正常使用難易程度
附錄：評審意見
想快速又簡單地編寫測試用例？看這里！
本文適用對象
初級軟件測試人員，或想開拓思路拓展測試范圍、提高測試覆蓋率的所有測試人員等等。
本文目的
講述如何快速、簡單、有效、有條理地編寫一條測試用例，并幫助測試人員從測試用例角度拓展測試思路。
如何簡單、快速地
描述（編寫）一個測試用例
測試用例的目的在于指導(dǎo)、幫助測試人員按照既定的計劃步驟執(zhí)行測試，并比對測試結(jié)果與預(yù)期結(jié)果是否一致。
對于中大型軟件公司而言，測試用例的管理都有既定的規(guī)范和工具，如表格管理用例、測試管理軟件管理用例（如下圖1所示為測試管理軟件用例編寫頁面）等。
但總而言之，測試用例的內(nèi)容主要不外乎3個部分：前置條件、步驟、預(yù)期結(jié)果。
那么，對于沒有明確地測試管理軟件的小型軟件公司，或者對于測試人員而言，需要暫時快速地編寫一個測試用例或記錄測試過程的時候，可以怎么做呢？
推薦一個臨時性的用例編寫模板：GIVEN...WHEN…THEN。
讓我們套用GIVEN…WHEN…THEN的模式來描述下編寫用例的大致步驟：
有沒有覺得很簡單？
讓我們再用實際案例，描述下如何用GIVEN…WHEN…THEN模板編寫真實用例。以測試訪問 鏈接這個用例為例1：
使用GIVEN…WHEN…THEN能夠簡單呈現(xiàn)用例前置條件、執(zhí)行步驟和預(yù)期結(jié)果間的邏輯關(guān)系，并能清晰地表述一個用例。
那么，什么地方可以用GIVEN…WHEN..THEN這個模板呢？這個模板較之文檔用例更為簡潔，如下圖2所示，對于測試用例提交故障，闡述引發(fā)故障的操作方法或故障復(fù)現(xiàn)方法，以及故障修復(fù)后的驗證時都可以使用。
如何使用探索式場景聯(lián)想法
衍生測試用例
探索式測試更多的是一種測試風(fēng)格和測試思想，要求測試人員在測試過程中不斷思考、發(fā)散思維，記錄、修改和更新測試方法和測試用例。
場景法則是要求測試人員認真分析測試需求，了解用戶使用場景，根據(jù)不同的場景進行測試。
而本文討論的 探索式場景聯(lián)想法，則是將探索式測試方法、場景法和聯(lián)想法相結(jié)合，在已有測試用例的基礎(chǔ)上衍生更多的測試用例。
那么，如何使用探索式場景聯(lián)想法衍生測試用例呢？
由上一節(jié)可知，測試用例是指導(dǎo)測試人員在xx預(yù)知條件（場景）下，執(zhí)行xx步驟，預(yù)期得到xx結(jié)論。
顯而可見，通過改變測試用例的預(yù)知條件和操作步驟，則可以衍生出不同的測試用例。而這些測試用例包含不同的測試場景和不同的測試步驟。
如下圖3所示，為探索式場景聯(lián)想法衍生測試用例的結(jié)構(gòu)腦圖。
改變前置條件
測試用例的前置條件基本包括：硬件資源和軟件系統(tǒng)兩個部分。
改變前置條件可以從這幾方面入手。
以上節(jié)的訪問 鏈接用例1為例，改變前置條件衍生新的測試用例。由于該用例的前置條件較簡單，改變前置條件只需改變?yōu)g覽器類型和版本即可。
由此，衍生的部分測試用例可如下所示：
改變操作步驟
改變用例操作步驟可以從以下幾方面入手：插入步驟、刪除步驟、改變步驟和重復(fù)步驟。
插入步驟
如圖3所示，插入步驟又可以分為插入相關(guān)聯(lián)步驟和不相關(guān)聯(lián)步驟。并在插入步驟中增加用戶輸入。
同樣以用例1為例，插入步驟衍生的測試用例可如下：
刪除步驟
刪除步驟可以分為刪除部分步驟或者刪除部分步驟中的部分操作。刪除部分步驟，又可以分為刪除關(guān)鍵步驟和非關(guān)鍵步驟。
例如，以例1為例，刪除關(guān)鍵步驟“點擊鍵盤回車鍵“衍生新的測試用例如下所示：
改變步驟
改變步驟主要涉及步驟順序的改變和步驟內(nèi)容的改變。當(dāng)測試用例具有多個步驟，且步驟間具有關(guān)聯(lián)性和順序性的時候，改變步驟順序則會變得很有意義。改變步驟內(nèi)容主要是改變步驟中用戶的輸入（包括數(shù)據(jù)輸入、用戶操作等）。
以用例1為例，改變步驟內(nèi)容衍生的用例如下所示：
重復(fù)步驟
對于大多測試人員來說，衍生測試用例時更多關(guān)注點在于操作步驟的變化。
但是，對于不同的測試場景，重復(fù)相同的測試步驟，仍然具有很大的測試意義。重復(fù)步驟進行測試能夠挖掘不同前置條件（場景）下的故障，亦能挖掘軟件在多個重復(fù)步驟操作下潛藏的故障。
以用例1為例，重復(fù)步驟衍生的用例如下所示：
測試結(jié)論衍生測試用例
除了通過改變前置條件和操作步驟衍生測試用例外，還可以根據(jù)測試結(jié)論中的異常信息，逆推測試場景，衍生新的測試用例。
這個部分更多的需要測試人員掌握探索式測試方法，對測試過程中的軟件資源監(jiān)控信息、錯誤日志等保持警惕性，挖掘錯誤信息中的內(nèi)容，逆推產(chǎn)生錯誤信息的原因，構(gòu)建新的測試用例。
小結(jié)
本文闡述了一種可以在提交測試故障信息和驗證測試故障時使用的快速測試用例編寫模板，快速記錄測試場景、測試步驟等關(guān)鍵信息。
并在此基礎(chǔ)上，簡單講解了基于探索式場景聯(lián)想法的測試用例衍生方法，可以幫助測試人員借助已有的測試用例拓展新的測試用例，擴大測試范圍，提高覆蓋率，挖掘更多場景下的軟件故障。
轉(zhuǎn)自公眾號投稿：
2021年Web前端工程師的學(xué)習(xí)建議
今天小編要跟大家分享的文章是關(guān)于2021年web前端工程師的學(xué)習(xí)建議。毫無疑問，前端開發(fā)將成為2021年技術(shù)領(lǐng)域最熱門的*之一。
以前，前端空間的開發(fā)人員只要了解一些HTML，CSS，也許還有jQuery來創(chuàng)建交互式網(wǎng)站，就足夠了。但是今天，他們面臨著廣泛且不斷變化的開發(fā)技能生態(tài)系統(tǒng);掌握的工具，庫和框架;并且需要不斷投資于個人教育。
最近幾年，我們使用為主要的Web應(yīng)用程序提供了強大的新庫和框架，例如ReactJS，VueJS和Svelte。想要學(xué)習(xí)web前端知識的小伙伴們來和小編一起看一看吧!
1.框架
2021年，我們可能會看到Facebook的ReactJS與社區(qū)驅(qū)動的VueJS之間的對決。目前，React在GitHub上擁有140,000星，而Vue則擁有153,000星。例如，Angular只有53,000個恒星。
在2021年，React(藍線)，Vue(紅線)，Angular(黃線)和Svelte(綠線)的搜索量支持此假設(shè)-Vue略高于React。Angular在搜索量方面無法跟上，Svelte在此比較中絕對不起作用。
因此，對于2021年，使用或希望使用框架的前端開發(fā)人員應(yīng)將React和Vue作為他們的主要選擇。如果您正在處理大型企業(yè)項目，則Angular是有效的選擇。
2.靜態(tài)網(wǎng)站生成器
靜態(tài)站點生成器結(jié)合了服務(wù)器端渲染的功能(對于SEO非常重要，而且還具有初始加載時間)和單頁應(yīng)用程序。
如今，許多項目即使不需要服務(wù)器端渲染也選擇了SSG，因為Next或Nuxt之類的解決方案具有便捷的功能，例如模塊捆綁器，集成測試運行器等。
如果您認真對待前端開發(fā)，則應(yīng)仔細研究以下項目，并嘗試獲得一些實踐經(jīng)驗：
·Next(基于React)
·Nuxt(基于Vue)
·Gatsby(基于React)
·Gridsome(基于Vue)
3.JAMstack
術(shù)語JAMstack代表(在客戶端上運行-例如，React，Vue或VanillaJS)，API(服務(wù)器端進程通過通過HTTPS抽象并訪問)和標(biāo)記(在部署時預(yù)先構(gòu)建的模板標(biāo)記)。。
這是一種構(gòu)建網(wǎng)站和應(yīng)用程序以提高性能的方法-降低擴展成本，提供更高的安全性并提供更好的開發(fā)人員體驗。
盡管這些術(shù)語本身并不是什么新鮮事物，但它們的共同點是相同的-它們并不依賴于Web服務(wù)器。因此，依賴于Ruby或Node.js后端或使用服務(wù)器端CMS(例如Drupal或WordPress)構(gòu)建的網(wǎng)站的單片應(yīng)用程序不是使用JAMstack構(gòu)建的。
如果要使用JAMstack，有一些*實踐：
整個項目都在CDN上提供服務(wù)
由于不需要服務(wù)器，因此整個項目都可以通過CDN進行服務(wù)，從而釋放出無與倫比的速度和性能。
一切都存在于在Git中
每個人都應(yīng)該能夠從Git存儲庫克隆整個項目，而無需數(shù)據(jù)庫或復(fù)雜的設(shè)置。
自動化構(gòu)建
您可以完美地自動構(gòu)建，因為所有標(biāo)記都是預(yù)先構(gòu)建的，例如使用webhooks或云服務(wù)。
原子部署
為了通過在大型項目中重新部署數(shù)百或數(shù)千個文件來避免出現(xiàn)不一致的狀態(tài)，原子部署將等待所有文件上傳，然后再進行更改。
即時緩存失效
當(dāng)站點上線時，必須確保CDN可以處理即時緩存清除，以使更改可見。
像Netlify或Zeit這樣的著名主機都支持JAMstack應(yīng)用程序，大公司使用它們?yōu)橛脩籼峁┏錾捏w驗。
4.PWA
漸進式Web應(yīng)用程序(PWA)無疑將在2021年成為現(xiàn)實。越來越多的公司選擇PWA取代本機應(yīng)用程序，以便為用戶提供豐富的移動體驗。
PWA可靠(即時加載，無需連接互聯(lián)網(wǎng)即可工作)，快速(流暢的動畫，對用戶交互的快速響應(yīng))和吸引人的體驗(本機應(yīng)用程序的感覺，出色的用戶體驗)。
他們利用服務(wù)人員提供脫機功能，并利用Web應(yīng)用清單文件提供全屏體驗。
構(gòu)建漸進式Web應(yīng)用程序的原因有：
·可以從瀏覽器添加到用戶的主屏幕
·即使沒有互聯(lián)網(wǎng)也能正常工作
·支持網(wǎng)絡(luò)推送通知以增強用戶參與度
·利用Google的功能
5.GraphQL
GraphQL是當(dāng)前最熱門的主題之一，并且絕對是您在2021年需要學(xué)習(xí)或改進的東西。
盡管REST通過提供無狀態(tài)服務(wù)器之類的出色概念一直被認為是設(shè)計WebAPI的事實上的標(biāo)準(zhǔn)，但在跟上快速變化的客戶端訪問RESTful
API時，卻越來越不靈活。
GraphQL由Facebook開發(fā)，旨在解決開發(fā)人員在處理時面臨的確切問題。
使用RESTAPI，開發(fā)人員可以通過從具有特定目的的多個端點(例如/users/端點或/tours//
location端點)中獲取數(shù)據(jù)來收集數(shù)據(jù)。
使用GraphQL，這將以不同的方式工作。開發(fā)人員會將查詢與他們的數(shù)據(jù)要求一起發(fā)送到GraphQL服務(wù)器。然后，服務(wù)器將返回帶有所有相應(yīng)數(shù)據(jù)的JSON對象。
使用GraphQL的另一個好處是它使用了強類型系統(tǒng)。GraphQL服務(wù)器上的所有內(nèi)容都是使用GraphQL模式定義語言(SDL)通過模式定義的。創(chuàng)建架構(gòu)后，前端開發(fā)人員和后端開發(fā)人員都可以彼此獨立地工作，因為他們知道已定義的數(shù)據(jù)結(jié)構(gòu)。
6.代碼編輯器/IDE
與2021年一樣，微軟的VSCode將在2021年成為大多數(shù)前端工程師的*編輯器。
它提供幾乎類似于IDE的功能，例如代碼自動完成和語法高亮顯示，并且可以通過其擴展市場進行幾乎無限的擴展。
特別是市場使VSCode如此出色。以下是您作為前端開發(fā)人員的一些出色擴展：
·(ES6)代碼段
·npm
·beautify
·CSS速覽
·ESLint
·LiveSass編譯器
·Chrome調(diào)試器
這些是很酷的例子。在VSCode中還有很多可以發(fā)現(xiàn)的地方，因此，如果您尚未使用它，我建議您嘗試一下。
7.測試
未經(jīng)測試的代碼不應(yīng)找到它的生產(chǎn)方式。
在您的個人項目中似乎沒有任何測試似乎很方便，但在商業(yè)和企業(yè)環(huán)境中工作時必須進行測試。因此，對于任何開發(fā)人員而言，*盡可能將測試集成到開發(fā)工作流程中。
可以區(qū)分以下測試用例：
單元測試
隔離測試單個組件或功能。
整合測試
測試組件之間的交互。
端到端測試
在瀏覽器中測試功能完善的用戶流。
有更多測試方法，例如手動測試，快照測試等。如果您想升任高級開發(fā)人員職位或打算在擁有某些開發(fā)標(biāo)準(zhǔn)的大型公司工作，則應(yīng)嘗試進行測試技能。
8.干凈的代碼
能夠編寫干凈的代碼是一項很棒的技能，許多組織都對此提出了很高的要求。如果您想從開發(fā)人員的位置升級為高級開發(fā)人員的位置，則應(yīng)真正學(xué)習(xí)干凈代碼的概念。
簡潔的代碼應(yīng)優(yōu)雅且易于閱讀。它應(yīng)該重點突出，您應(yīng)該注意這一點。所有測試均以純凈代碼運行。它們不應(yīng)包含重復(fù)項，應(yīng)盡量減少使用實體(例如類，方法和函數(shù))。
干凈代碼開發(fā)人員應(yīng)做的一些事情是：
·為變量，類，方法和函數(shù)創(chuàng)建有意義的名稱
·函數(shù)應(yīng)該很小并且參數(shù)應(yīng)盡可能少
·根本不需要注釋-代碼應(yīng)該說明一切
如果您想了解有關(guān)干凈代碼檢查的更多信息，請閱讀RobertC.Martin的書籍和帖子。
9.Git
毫無疑問，Git是當(dāng)今Web開發(fā)中版本控制的標(biāo)準(zhǔn)。對于每個前端工程師而言，了解基本的Git概念和工作流程以在各種規(guī)模的團隊中有效工作都是非常重要的。
這是您應(yīng)該知道的一些流行的Git命令：
gitconfig
gitinit
gitclone
gitstatus
gitadd
gitcommit
gitpush
gitpull
gitbranch
知道這些命令可以提高工作效率總是很高興的，但是前端工程師還應(yīng)該學(xué)習(xí)Git的基本概念。
10.軟技能
對于開發(fā)人員來說，經(jīng)常被忽視但確實非常重要的是獲得軟技能。
雖然有助于了解事物的技術(shù)方面，但了解如何在團隊中進行交流也同樣重要。如果您對技術(shù)職業(yè)很認真，并且/或者打算升任高級職位，則應(yīng)該從事以下軟技能方面的工作：
同情
溝通
團隊合作
平易近人和樂于助人
忍耐
開放的思想
解決問題
責(zé)任心
創(chuàng)造力
時間管理
永遠記?。洪_發(fā)人員最重要的交付物是高級開發(fā)人員。(提升你自己)
結(jié)論
在本文中，小編向您展示了前端開發(fā)人員應(yīng)在2021年嘗試學(xué)習(xí)，改進或掌握的10項重要內(nèi)容。想要了解更多web前端相關(guān)知識記得關(guān)注北大青鳥web前端培訓(xùn)官網(wǎng)，*祝愿小伙伴們工作順利，成為一名優(yōu)秀的web前端工程師。
如何設(shè)計一個完整的測試用例
測試用例的設(shè)計一般從分析需求設(shè)計說明書開始，了解開發(fā)人員設(shè)計這個項目的思路、設(shè)計的要求、實現(xiàn)的功能等（*有use case，這樣看起來更清晰）。軟件測試的W模型，就要求測試與開發(fā)同步，在開發(fā)設(shè)計需求設(shè)計說明書的時候就開始測試流程，一般情況下，討論需求設(shè)計的時候需要測試主管或者組員的參與，了解這個項目設(shè)計的總體情況。事實上，測試用例的編寫一般是在需求設(shè)計說明書定下來之后才真正的開始的。因為測試用例的內(nèi)容要以需求設(shè)計說明書為依據(jù)，設(shè)計說明書上沒體現(xiàn)的功能，不需要在測試用例中體現(xiàn)。編寫測試用例（這里指功能測試用例的編寫），首先要做的就是設(shè)計測試用例的模板。每個公司都有適合自己公司用例編寫的模板，各有各的特點。測試用例的格式包括，測試用例摘要、測試用例需求編號（一個需求設(shè)計說明書可以分好幾個用例編寫）、編寫用例的日期、編寫人員、編寫日期、前置條件、準(zhǔn)備數(shù)據(jù)等等。格式?jīng)]有固定的要求，可以根據(jù)自己測試用例設(shè)計的思路，對測試用例的格式作相應(yīng)的改變。下面以一個登陸窗口為例，說說我設(shè)計登陸界面的思路和方法。我把這個測試用例分為三層結(jié)構(gòu)，表單測試、邏輯判斷、業(yè)務(wù)流程。*層，表單測試為*層（最基礎(chǔ)的）。這部分的測試用例是對登陸窗口這個界面的輸入框、按鈕功能、界面等最基本功能的測試。一般來說登陸用戶名和登陸用戶密碼是輸入框的形式體現(xiàn)，那么，我們需要的是針對這兩個輸入框進行功能的測試。這時，我們只要考慮這個輸入框的功能，而不需要考慮業(yè)務(wù)方面的內(nèi)容。這樣，我們考慮就是這個輸入框的長度限制是多少？能否輸入特殊字符？能否輸入全角字符？當(dāng)然，登陸窗口還有其他按鈕，例如登陸按鈕、退出按鈕、界面設(shè)計等，這一層的測試用例只對他們最簡單的功能的測試。我覺得這一層的測試用例對新開發(fā)項目很重要，也必須執(zhí)行，因為這些是最基本的功能保證，當(dāng)項目進入維護階段后，如果沒有修改就不需要執(zhí)行這部分的測試了或者說把這層的用例優(yōu)先級置為*，時間不充足的情況就不用去執(zhí)行。第二層，邏輯判斷層。根據(jù)需求的設(shè)計，各功能之間的簡單邏輯聯(lián)系。以登陸窗口為例，賬號登錄，賬號和密碼必須對應(yīng)才能登錄，否則登錄失敗。根據(jù)這一點，我們就可以從這個要求設(shè)計這一層測試用例。例如，賬號和密碼不一致時；賬號為空時；密碼為空時；賬號密碼對應(yīng)時等等情況。輸入這些情況時，程序是作怎么樣的邏輯控制的？控制是否正確？是否有相應(yīng)的提示信息？我覺得，這一層的用例時最常規(guī)的一層，平時使用這個軟件用經(jīng)常碰到的一些情況，在常規(guī)測試或修改這部分的功能之后，這一部分的測試用例也必須執(zhí)行。第三層，業(yè)務(wù)流程層。這部分不關(guān)心軟件的本身的基本功能，而是關(guān)心這個軟件的業(yè)務(wù)有沒有實現(xiàn)，不同的需求就有不同的業(yè)務(wù)需求。以登陸窗口為例，就可能有不同的需求，可能用戶要求停用的賬號能夠登錄系統(tǒng)（可能要求登錄后不允許進行其他操作），也可能用戶直接要求停用的用戶賬號不準(zhǔn)登錄系統(tǒng)。根據(jù)不同的業(yè)務(wù)需求，就有不同的業(yè)務(wù)流程。這樣這層的測試用例，我們就只要考慮業(yè)務(wù)需求，仍然以登錄窗口為例，我們就只要考慮刪除的用戶能否登錄？停用的用戶能否登錄？超級用戶是如何登錄的？普通用戶是何種方式登錄的？簡單的說，這層的用例只描述業(yè)務(wù)流程，不關(guān)心具體這個業(yè)務(wù)是怎么實現(xiàn)的，執(zhí)行這部分用例時，不要考慮哪個輸入框控制了多少長度，能否輸入空格等其他功能，因為這部分的測試需要基于上面兩層的測試用例都已經(jīng)測試通過了，所以在項目維護階段或者說時間很緊迫的階段，我們只需要執(zhí)行這部分的用例，保證業(yè)務(wù)能夠通暢的完成。其實個人覺得在執(zhí)行這部分用例時，對包含了對基本功能的測試，一些明顯的問題應(yīng)該能被發(fā)現(xiàn)，雖然嚴格來說測試覆蓋率很低，但是基本能達到要求。這三層的組合起來才是一個完整的測試用例。這是我個人對測試用例設(shè)計的一個思路和方法。真正設(shè)計這個測試用例的時候，可能會使用到黑盒測試用例的方法，例如等價類劃分、邊界值分析、錯誤猜測法（主要是個人經(jīng)驗）、正交分解等方法針對具體情況設(shè)計測試用例。分層測試用例的思路主要來自對自動測試實現(xiàn)的考慮。因為我覺得，如果需要實現(xiàn)自動化測試就必須對測試用例進行細分，劃分得越細就越有利于自動化的實現(xiàn)。以上三層的劃分也并不是很全面，需要在實踐中不斷完善，例如可以增加對數(shù)據(jù)庫的部分功能的數(shù)據(jù)校驗的分析?？傊瑴y試用例寫的細致、全面、步驟清晰，那么無論是用手工測試的方法還是用自動化測試的方法實現(xiàn)，只要能完整的跑完整個測試用例，就達到了測試的目標(biāo)了。
Katalon Studio之web自動化（二）---創(chuàng)建測試用例
測試使用的用戶肯定一般不止一個，可通過參數(shù)來傳遞，方便后續(xù)可以通過輸入不同的用戶信息登錄。
在Variables頁面添加變量，選擇變量類型，并填入變量的默認值即可
點擊輸入框，跳出對話框，選擇value_type為Variable，然后在Value選擇相應(yīng)的變量即可
在測試用例中添加item時，通過add,選擇call test case
添加測試用例后，默認展示默認值
通過點擊輸入，修改變量的輸入值
當(dāng)然可以進行多次調(diào)用，例如用戶A、B有不同的操作，不同的測試用例，就可以創(chuàng)建很多公用的登錄用例login_A或login_B，引用時直接引用login_A或login_B即可，這樣方便后續(xù)修改用戶A的密碼或者切換用戶A1執(zhí)行與A相同的用例時，就可以直接修改login_A的輸入值即可，就不需要修改每個用例的用戶名和密碼了。
在調(diào)用用例后，系統(tǒng)會自動往下執(zhí)行。
當(dāng)需要在不同用例間傳參時，可以使用全局變量。
1.增加全局變量
在Profiles下的default中，添加全局變量即可。
2.引用全局變量
關(guān)鍵字可參考官方文檔： [WebUI] Accept Alert | Katalon Docs
Katalon Studio支持 控制語句 （如 If / Else ， for / while 或 Try / Catch ?…）來決定執(zhí)行的邏輯流程，具體也可以參考官方文檔： Control | Katalon Docs
斷言語句包含一個 布爾表達式 ，其中此條件必須為true才能繼續(xù)執(zhí)行測試。因此，斷言的執(zhí)行導(dǎo)致對 布爾表達式 的求 值， 并且如果表達式的求值為 false， 則會報告 錯誤 。
Assert | Katalon Docs
“? 測試偵聽器” 是根據(jù)您自己的條件創(chuàng)建的測試步驟，將在條件匹配時執(zhí)行。
Test Listeners (Test Hooks) | Katalon Docs
至此 ，可以完成基本的測試用例，其他可以繼續(xù)參考文檔學(xué)習(xí)。
