測試筆記

時間 2019-11-29

標籤測試筆記简体版

原文原文鏈接

　　用了一個多月的時間看完了陳能技的《軟件測試技術大全》，可謂是受益不淺，如今總結一下筆記，分享也好，複習也好html

　　全書四篇二十章，我也按照篇章來總結，方便之後查看，可是總結完第一篇就總結第四篇，爲了彌補我以爲本書不夠好的地方。不少人都以爲測試很簡單，沒前途，因此不重視，學測試的人也有部分這樣認爲。第四篇講的是軟件測試的學習環境和研究方向及我的發展，無疑是給學習測試者打上一劑強心劑，才能讓他們更加自信的學下去。java

第一篇軟件測試的基礎程序員

第1章軟件測試概述web

測試人員的能力不足的緣由：正則表達式

基礎知識不過紮實：僅浮淺地瞭解一些基本的測試設計方法，並無深刻理解
專業技術不夠精通：沒有真真正正地應用某些工具或技術
沒有創建相對完整的測試體系概念，忽視理論知識：理論知識缺少，認爲理論知識沒用而沒有深刻理解測試的基本道理

Harry Robinson提出的迎接測試將來挑戰的建議：算法

積極地不滿於現狀：不要被動接受或知足測試的現狀
拋開人與人之間的隔閡：總結、分享、學習
學習更多關於測試的知識：參加交流會、論壇、閱讀優秀資料
學習更多關於開發的東西：閱讀相關文檔、和開發人員交流

第2章軟件測試的組織數據庫

一我的的測試是不可能成功的，測試是一項須要合做進行的工做。編程

微軟的結論：不能依賴開發人員測試，也不能依賴外部公司的測試，必須本身創建一個獨立的測試部門。小程序

測試組織分類：項目型和職能型安全

項目型的測試組織：指測試人員做爲項目組成員之一，緊密地結合到項目中，與項目組其餘組員緊密協做，從頭至尾跟着項目走。
- 項目經理是負責測試資源調配和測試計劃的主要人員
- 測試人員參與的力度強，能深刻了解項目方方面面的信息，有利於穩定持續有效地測試出更多細節問題
- 測試人員對bug的處理意見上受到項目負責人約束
- 測試經驗不利於普遍傳播
- 測試人員可能會感受在團隊中被孤立
職能型的測試組織：指測試人員參與到項目中，以獨立的測試部門委派的方式進入。
- 測試人員可能同時測試多個項目
- 測試人員向所在部門的經歷報告工做
- 能節省部分測試資源，充分利用各階段之間的時間差來合理利用資源
- 測試深度不夠，對業務知識和領域知識涉及不深，致使測試的問題相對錶面化

快速融入項目團隊的技巧

儘可能瞭解每位開發人員的性格特色
對開發人員正在開發的產品功能產生興趣
將缺陷跟蹤庫中全部之前的bug都查看一遍
保持虛心學習的態度

儘快投入測試工做的技巧

閱讀需求文檔、設計文檔及用戶手冊是關鍵的第一步
若是項目處於前期階段，則應該多參與項目的各類會議，儘可能多瞭解項目的各方面知識
閱讀已有的測試用例或根據需求和設計文檔編寫測試用例
閱讀缺陷庫中的bug，並嘗試復現

測試規範：包括內部規範和全局規範

內部規範：指測試人員在測試工做過程當中須要遵循的規範
- 軟件測試方法指南：是對測試人員在進行各類類型的測試時進行規範化的要求
- 測試用例設計規範：通常包含測試用例的模板以及測試用例設計的要求
- 缺陷錄入規範：用於規範化測試人員的bug錄入過程
- 測試計劃規範：通常包含測試計劃的模板以及對測試計劃的要求
- 測試報告規範：通常包含測試報告的模板以及對測試報告的要求
- 測試工具使用規範：指測試人員在何時使用那些工具，工具的參數設置須要注意哪些方面的問題
全局規範：指測試人員與其餘項目成員之間須要共同遵循的規範
- 缺陷分類規範：指如何把bug進行歸類
- 缺陷等級劃分規範：是bug的嚴重程度標識和優先級標識的依據
- 測試提交流程規範：是開發人員提交某項完成的功能模塊給測試人員測試時應該遵循的流程
- 缺陷狀態變動規範：要求項目組不一樣角色的人對bug狀態的修改和更改權限應該遵循的流程

第3章軟件測試人員應具有的條件

測試人員應具有的基本素質：

對軟件測試感興趣:興趣是最好的老師
擁有適合作軟件測試的性格特性：懷疑思惟
好奇心：好奇心越強，越容易成爲優秀的測試人員
成就感：測試人員的成就感源於破壞和挑剔
全面的思惟能力：思惟能力強，看問題全面
責任感：對待軟件測試的態度是對軟件質量負責任的態度，對用戶負責任的態度

測試人員的技能要求：

業務知識：對業務知識瞭解的越多，測試就越貼近用戶的實際需求
產品設計知識：測試人員對與軟件產品設計、軟件架構方面的信息瞭解得越多，越有利於對測試深刻研究
瞭解UML：UML對測試人員也是很是有指導意義的
掌握測試工具：瞭解工具間的差別，及使用技巧
瞭解開發工具：使用開發工具的一些基本操做
用戶心理學：始終站在用戶的角度思考問題
界面設計3種模型
1. 設計者模型：關注的是對象、表現、交互過程
2. 用戶模型：關注目標、信心、情緒
3. 實現者模型：關注數據結構、算法、庫等界面實現實現是要考慮的問題
人機交互認知心理學：
1. 一致性原則：從任務完成、信息傳遞、界面控制和操做等方面應該與用戶理解和熟悉的模式儘可能保持一致
2. 兼容性：在用戶指望和界面設計實現之間的兼容，要基於用戶之前的經驗
3. 適應性：用戶應該處於控制地位，所以界面應該在多方面適應用戶
4. 指導性：界面設計應該經過任務提示和及時的反饋信息來指導用戶，須要作到「以用戶爲中心」
5. 結構性：界面設計應該是結構化的，以減小複雜度
6. 經濟性：界面設計要用最少的步驟來實現一個用於支持用戶業務的操做
腳本語言：理想的自動化語言
編寫文檔的能力：缺陷報告、測試報告
1. 合理組織語言，體現清晰的思惟
2. 多用短語和精煉的語言，忌長篇大論
3. 適當空行和換行
4. 每寫一段話，先本身閱讀一遍
5. 儘可能規範寫做格式

第四篇軟件測試的學習和研究

第19章軟件測試的學習環境

良好的學習環境主要依靠3個方面支撐：

書：可供學習的資料
制度：一個促使測試人員不斷學習的機制
人：可讓測試人員學習的楷模

軟件測試的交流

與管理層交流
與開發人員交流
與測試人員交流
與業界同行交流

與開發人員交流注意事項：

定義本身角色，讓開發人員感受到須要測試人員的幫助
測試人員應對那些感到疑惑的開發人員解釋本身的工做
儘可能減小會產生誤會和曲解的bug報告

第20章軟件測試的研究方向及我的發展

轉型：

轉向售前角色
- 提升業務知識
- 學習用戶思惟
- 提升表達能力
- 增強溝通能力
- 培養說服能力
轉向售後角色
- 提升軟件操做的熟練度
- 提到定位問題的能力
- 強化環境知識
轉向開發角色
- 深化程序架構思想和構成的理解
- 提升編碼能力
轉向QA
- 增強對質量的理解
- 加大對質量的宣傳
- 學會發現問題的本質

發展：關鍵是選擇本身認爲適合的持續發展路線，不要輕易動搖。

管理路線
- 初級測試工程師：要求具有基本的測試執行能力和測試理論知識，主要集中在手工測試和基本的功能驗證性測試方面
- 中級測試工程師：要求具有測試設計能力，對測試理論知識的進一步理解，主要集中在黑盒測試的執行及其測試用例的設計，及具有必定的制定測試計劃和測試報告的能力
- 高級測試工程師：要求具有較強的測試用例設計能力，能把測試理論和知識融入到測試工做實踐中，具有較好的製做測試計劃和測試報告的能力；與中級測試工程師的明顯界限是：測試經驗。
- 測試組長：具有相對較強的製做測試計劃和測試報告的能力，測試的組織能力以及溝通能力。具有必定的測試風險意識，以及與開發人員交涉的能力，須要具有Bug評審的組織和缺陷分析能力。
- 測試主管：須要管理多個測試項目的資源調度、人員招聘以及培訓、能力評估和效績考覈。
- 質量主管：主要關注測試的總體組織架構設置是否合理，測試工具的選型是否合理，測試人員與其餘人員的溝通和交流是否存在問題；還會重點關注流程的質量，負責質量管理體系的創建和維護。
技術路線
- 各測試工程師須要對相應的領域深刻而持續的研究。
- 測試設計架構師：具有多方面或多個領域的豐富經驗和知識；負責測試方面的總體設計。

第二篇軟件測試基本理論

第4章軟件工程與軟件測試

軟件的生命週期：計劃->需求分析->設計->編碼->測試->運行維護

軟件工程研究領域：人員管理、項目管理、配置管理、質量管理、可行性分析->需求分析->系統設計->編碼->測試。

軟件開發模型：

線性模型：瀑布模型...
漸進式模型：螺旋模型...
變換模型
敏捷開發模式

不一樣開發模式下的軟件測試：

CMM（承製方軟件工程能力的評估方法）分級

初始級：軟件過程缺少定義，項目的成功嚴重依賴我的，軟件質量由我的的開發經驗來保證；
可重複級：實施了基本的項目管理和過程控制，依賴以往項目的成功經驗來確保新的相似項目的成功。
已定義級：全部項目遵循必定的標準進行管理，具有可量化的、文檔化的過程管理；進一步減小了項目成功對於人的依賴性。
已管理級：加入了評估和度量機制，利用評估和度量來對軟件過程以及產品的作出合理的判斷和控制。
優化級：關注改進的持續性，融入了技術改革、缺陷預防等理念；軟件組織可從本身的過程控制和管理中獲得反饋信息，用於進一步指導過程的改進。

ISO 9000-3主要內容

合同評審
需求規格說明
開發計劃
質量計劃
設計和實現
測試和確認
驗收
複製、交付和安裝
維護

敏捷開發中的軟件測試

敏捷測試做爲團隊的「車頭燈」，幫助開發人員找到目標
敏捷測試注意內容：
- 更多地採用探索性測試方法
- 更多地採用上下文驅動的測試方法論
- 更多地採用敏捷自動化測試原則

配置管理（CM）：用於控制複雜系統發展的一門學科，確保開發活動和測試活動順利進行的工具

軟件配置管理定義（SCM）：管理計算機程序產品進展的一門學科，包括在開發的初始階段和產品的全部維護階段

SCM的基本任務：計劃、識別、控制、狀態記錄和狀態審計。

第5章軟件測試的目的與原則

軟件測試的目的：爲了發現錯誤而執行軟件程序的過程。一個成功的測試是發現迄今爲止還沒有發現的錯誤

軟件測試的兩面性：

爲了驗證程序能正常工做的測試
爲了驗證程序不能正常工做的測試

軟件測試的驗證和確認

驗證是指在軟件生命週期的各個階段，用下一個階段的產品來檢查是否知足上一個階段的規格定義
確認是指在軟件生命週期的各個階段，檢查每一個階段結束時的工做成果是否知足軟件生命週期的初期在需求文檔中定義的各項規格和要求。

軟件測試的原則：

Good enough原則
Pareto原則（8020原則）
儘量早地開展測試
在發現較多錯誤的地方投入更多的測試（Bug具備集羣性）
避免同化效應（交叉測試）

第6章軟件測試的方法論

軟件測試的學派及對軟件測試的定義

分析學派：認爲測試是嚴格的技術性的；認爲軟件測試是計算機科學和數學的分支
標準學派：認爲測試是用於衡量進度的一種方式，強調成本度量和可重複的標準；認爲軟件測試是一個管理的過程
質量學派：強調過程，測試人員負責審批開發人員，同時保證質量；認爲軟件測試是軟件質量保證的分支
上下文驅動學派：強調人的做用，尋找利益相關的Bug；認爲軟件測試是開發的一個分支
敏捷學派：使用測試來驗證開發是否完成，強調自動化測試；認爲軟件測試是顧客角色的一部分

IBM軟件測試方法：基於RUP進行的

RUP：Rational統一過程模型，是一種強調迭代開發、持續集成的軟件開發過程模型

迴歸測試：每添加新模塊，舊模塊都須要迴歸測試，最好可以自動化
測試度量：
- 測試需求的覆蓋
- 測試用例的覆蓋
- 測試執行代碼的覆蓋
用例驅動：用一個個測試用例將系統分紅多個模塊進行測試，化簡爲繁

RUP對軟件測試的分類：

可靠性：完整性測試、結構性測試
功能：配置測試、功能測試、安裝測試、安全測試、容量測試
性能：基準測試、競爭測試、負載測試、性能曲線測試、強度測試

RUP對測試階段的劃分

單元測試在迭代的早期實施，側重於覈實軟件的最小可測試元素
執行集成測試是爲了確保當把實施模型中的構件集成起來執行用例時，這些構件可以正常運行
當將軟件做爲總體運行或實施明肯定義的軟件行爲子集時，便可進行系統測試
驗收測試是部署軟件以前的最後一項測試操做

第7章軟件測試的過程管理

PDCA循環：P(Plan)，D(Do)，C(Check)，A(Action)

測試需求的分析和肯定
測試計劃
測試設計
測試執行
測試記錄和缺陷跟蹤
迴歸測試
測試總結和報告

需求說明書的檢查要點：

正確性：對照原始需求檢查需求規格說明書
必要性：不能回溯到出處的需求項多是多餘的
優先級：恰當地劃分並標識
明確性：不適用含糊的詞彙
可測性：每項需求都必須是可驗證的
完整性：不能遺漏必要和必需的信息
一致性：與原始需求一致、內容先後一致
可修改性：良好的組織結構使需求易於修改

測試計劃要點：

肯定測試範圍：明確須要測試的對象
制定測試策略
- 測試戰略：就是測試的前後次序、測試的優先級、測試的覆蓋方式、迴歸測試的原則等
- 測試戰術：也就是採用的測試方法、技巧和工具等
有效地利用測試資源
合理地安排進度：每項測試最好預留緩衝時間
評估風險：制定出相應的應對策略

測試用例設計方法

等價類劃分法
邊界值分析法
基本路徑分析法
因果圖法
場景設計法
錯誤猜想法
正交表法
均勻試驗法
組合覆蓋法：PICT工具

測試用例的選擇策略：先執行基本的測試用例，再執行復雜的測試用例；先執行優先級高的測試用例，再執行優先級低的測試用例。

BVT測試：編譯檢查測試，主要檢查源代碼是否能正確編譯成一個新的、完整可用的版本

冒煙測試：先檢查軟件的基本功能，在進行下一步測試

BVT測試和冒煙測試是全部正式測試執行以前的第一步

測試執行的結果只有兩個：測試經過和測試不經過；測試不經過，測試人員應把缺陷記錄下來，反饋給開發人員

撰寫測試報告的基本原則：客觀地陳述全部相關事實

Bug的生命週期：New->Open->Fixed->Rejected->Delay->Closed->Reopen

若是時間比較緊迫，修改後剩餘的時間不足以作一次有效的迴歸測試的話，不進行修改多是種明智的選擇

易脆（不可維護）是舊的軟件系統被替換的主要緣由之一

時間緊迫是迴歸測試的難度所在，但更難的是要克服測試人員的疲勞思惟。

測試報告綱要：

第8章軟件測試的度量

測試的度量原則

要制定明確的度量目標
度量標準的定義應該具備一致性、客觀性
度量方法應該儘量簡單、可計算
度量數據的收集應該儘量自動化

測試不能提升軟件質量，軟件的質量是固有屬性，其提升有賴於開發人員的努力

測試人員的工做成果不能從軟件的產品質量或軟件的最終結果獲得科學的評估

軟件測試的度量：

加權法度量缺陷

1. 給缺陷加權
2. 度量篩選後的Bug

定性評估：對測試人員發現的Bug的質量進行相對主觀的衡量。

1. Bug的類型分佈
2. Bug的重現率
3. Bug錄入的清晰程度、簡明程度等
4. Bug的新穎程度

測試覆蓋率統計

1. 代碼行覆蓋 = （已執行測試的代碼行 / 總的代碼行）*100%
2. 功能模塊覆蓋率 = （已執行測試的功能模塊數 / 總的功能模塊數）*100%
3. 數據庫覆蓋率 = （功能模塊訪問的數據庫表面積 / 總的數據庫面積）*100%
4. 需求覆蓋率 = （已執行的測試用例數 / 總共設計的測試用例個數）*100%

考覈測試人員的硬指標

缺陷逃逸率 = （用戶發現的缺陷個數 / 總共出現的缺陷個數）*100%
測試效率 = 執行的測試用例個數 / 測試執行的工做日

考覈測試人員的軟指標：Bug報告和測試報告

第三篇實用軟件測試技術與工具

第9章實用軟件測試技術

黑盒測試：把軟件產品當成一個黑箱進行測試，測試只須要了解軟件的輸入結果和輸出結果

白盒測試：是一種以理解軟件內部結構和程序運行方式世紀城的軟件測試技術

自動化測試：利工具進行重複性的工做，從而提升測試效率

手工測試不可替代點：

測試用例的設計：測試人員的經驗和對錯誤的判斷能力是工具不可替代的
界面和用戶體驗測試：人類的審美觀和心理體驗是工具不可模擬的
正確性的檢查：人們對是非的判斷、邏輯推理能力是工具不可替代的

探索性測試：同時設計測試和執行測試

探索性測試過程：

識別軟件系統的目的
識別軟件系統提供的功能
識別軟件系統潛在的不穩定的區域
在探索軟件系統的過程當中記錄關於軟件的信息和問題
建立一個測試綱要，使用它來執行測試

單元測試

狹義的單元測試：指編寫測試代碼來驗證被測試代碼的正確性

廣義的單元測試：指小到一行代碼的驗證，達到一個功能模塊的功能驗證，從代碼規範性的檢查到代碼性能和安全性的驗證都包括在內

單元測試進行：開發人員編寫測試代碼，測試人員執行測試代碼並收集和分析結果

單元級別的性能測試：性能的考慮應該在架構設計時就開始，對於架構原型要進行充分的評審和驗證。

單元級別的性能測試角度：

代碼效率評估
應用單元性能測試工具
數據庫優化

AQTime：可計算出每行代碼執行時間的工具

NTime：用於測試函數、方法的性能是否知足要求的工具

數據庫性能檢查

引發數據庫問題的主要緣由：數據庫的設計和SQL語句

數據庫的設計：數據庫的參數配置和邏輯結構設計

可找出有性能問題的語句的工具：SQL Best Practices Analyzer、SQLServer數據庫自帶的事件探查器和查詢分析器、LECCO SQLExpert等

壓力測試

負載測試與壓力測試區別

負載測試須要進行屢次的測試和記錄
壓力測試的目的很明確，就是要找到系統的極限點

軟件的容量測試：指軟件系統在處理大數據量的時候，或者是加載大批量數據時的性能表現

容量測試的關鍵：模擬大批量的用戶業務數據，首先要估算好用戶若干年後可能出現的最大數據量

數據生成工具：DataFactor等

安全測試

網頁安全漏洞檢測工具：Paessler Site Inspector、Web Developer、AppScan等
SQL注入檢測工具：AppScan等
緩衝區溢出檢測工具：AppVerifier

跟蹤法測試：一種介於黑盒測試和白盒測試之間的測試技術

跟蹤法技術測試關心中間的一些環節是否也是正確的

跟蹤法測試應用：

跟蹤SQL語句：SQL Server的事件探查器
跟蹤網絡Socket包：SockMon
跟蹤日誌

C/S結構軟件系統的測試

易用性測試
服務器端的測試
性能測試
安全性測試
安裝部署測試

B/S結構軟件系統測試

連接測試
Cookies測試
兼容性測試
併發訪問測試

界面測試

界面模型：設計者模型、實現者模型和用戶模型

界面測試要點：

制定界面設計規範
理解用戶的目標
對界面原型進行測試
防止界面的「審美疲勞」

數據庫測試

數據庫設計的測試
SQL代碼規範性測試
SQl語句效率測試
SQL數據庫兼容性測試

Web Services的測試

Web Services：是一種新的使用基於XML標準和協議來交換信息的Web應用程序

測試工具：

性能：LoadRunner、TestComplete
功能：WebInject、soapUI、SOAPtest和TestComplete

內存泄露測試

內存泄露緣由：

分配完內存以後忘了回收
程序寫法有問題，形成資源沒法回收
某些API函數的使用不正確，形成內存泄露
沒有及時釋放內存

檢測工具：MemProof、AQTime、Purify、BundsChecker、Perfmon的Handle Count、Virtual Bytes和Working Set計數器

可訪問性測試

工具：Rampweb_ToolBar、Watchfire WebXACT、Parasoft WebKing和QTP等

第10章實用軟件測試工具

測試管理工具：TestDirector
自動化測試工具：TestComplete、QTP
性能測試工具：LoadRunner
內存檢查工具：BoundsChecker
測試用例設計工具：CTE XL

第11章開源測試工具

使用開源工具的成本：
- 學習和培訓成本
- 安裝部署成本
- 改形成本
測試管理類：Bugzilla、Mantis、BugFree
單元測試類：
- 針對.NET
  - 單元測試框架：NUnit
  - 單元測試方法：NMock
  - 界面層代碼測試：NunitForms
性能測試類：
- Web性能測試工具：OpenSTA
- 性能測試工具：TestMaker
- 大數據生成工具：DBMonster
自動化功能測試類：
- 自動化測試框架：Abbot Java GUI Test Framework
- 功能測試工具和錄製工具：SharpRobo
- IE自動化測試工具：Samie

第12章測試工具的原理及製做

使用Windows腳本輔助測試

大部分Windows操做系統都內置了腳本宿主（WSH），用於執行Windows腳本
Windows腳本分兩類：VBScript和JScript
使用JScript可進行的測試
- GUI自動化測試
- 檢查註冊表
- 處理文件
- 操做Excel
- 運行應用程序
- 使用WMI（Windows Management Instrumentation，即Windows管理規範）
- 訪問網絡
- 使用正則表達式
- 發送郵件

猴子測試：利用測試工具隨機產生鍵盤敲擊和鼠標點擊時間。

代碼覆蓋率測試工具：DevParner、AQTime

第13章實用小工具的應用技巧

任務管理器：可用於瞭解被測程序各類信息的小工具

運行程序，查看「內存使用」和「虛擬內存大小」，當程序請求所須要的內存後，若是虛擬內存仍是持續地增加，就說明這個程序存在內存泄露。

判斷網絡鏈接速度是否存在瓶頸，能夠用字節數/間隔與目前網絡的帶寬進行比較

若是處理器時間持續超過95%，則代表CPU處理存在瓶頸

Perfmon：Windows自帶的性能監控工具

啓動：在「運行」中輸入perfmon，便可啓用
可實時或計劃監控計算機某些性能參數

NetStat:Windows自帶的一個網絡信息查詢器

啓動：在命令行中輸入netstat以及一些參數，便可啓動
可顯示當前系統的全部TCP/IP鏈接狀況，以及協議的統計信息
使用方法可在命令行中輸入「netstat -?」查詢

Visual SourceSafe的文件比較器：可用於比較兩個文件之間的差別。

第14章單元測試管理

自動化靜態檢查：主要根據代碼的語法和詞法特徵來識別潛在的錯誤

自動化動態單元測試：經過執行那些實現了測試用例的測試代碼的方式來進行測試，測試工具動態生成某些測試用例，而後自動轉換成測試代碼並執行

變量與值比較時，先寫值，在寫變量。
代碼儘可能作到「高內聚，低耦合」
單元測試須要「廣專結合」、「動靜相宜」，「廣專結合」是指廣義的單元測試與狹義的單元測試相結合
重要的、經常使用的單元模塊應投入更多的測試
單元測試可以讓開發人員交叉測試
只有投入必定量的單元測試、覆蓋足夠多的代碼區域，才能起到單元測試應有的做用

第15章自動化功能測試管理

自動化測試的實現成本和維護成本

過早進行自動化測試會帶來維護成本的增長
過多進行自動化測試不能換來持續加強的效果

適合自動化測試的用例：

容易實現自動化且重要的功能模塊
能被有效的識別出控件的界面
能比較好地插入驗證點進行結果驗證的功能

自動化功能測試腳本

線性腳本：使用簡單的錄製回放
結構化腳本：在腳本中使用結構控制，如循環結構、分支結構等
共享腳本：把表明應用程序行爲的腳本在其餘腳本之間共享
數據驅動腳本：把數據從腳本分離出來，存儲在外部的文件中，這樣腳本就只包含編程代碼，使得腳本在測試數據改變是不須要修改代碼
關鍵字驅動腳本：把檢查點和執行操做的控制都維繫在外部數據文件中，所以測試數據和測試操做序列控制都是在外部文件中設計好，除了常規的腳本外，還須要額外的庫來翻譯數據