獲取 access token 的地方主要取決于你的測試需求和組織方式。以下是其中幾種可能的方式： 1. **在`Background`或`Given`步驟中：**如果每個`Scenario`或者大部分`Scenario`都需要 access token， 并且 token 可以在`Scenario`的生命周期中重用，那么在`Background`或`Given`步驟中獲取 token 很有用。每個`Scenario`開始前，你都會獲得一個新的 token。 2. **在`environment.py`文件中：**如果你想在整個`Feature`開始前就獲取一次 token，并在整個`Feature`的所有`Scenario`中重用這個 token，你可以在`environment.py`文件的`before_feature`函數中獲取 token。這樣，即使你的`Scenario`數量很大，獲取 token 的步驟也只會執行一次。 3. **在單個`Given`步驟中：**還有一種情況是你可能只有一些`Scenario`需要 access token。在這種情況下，你可以創建一個單獨的`Given`步驟來獲取 token，然后在需要 token 的`Scenario`中使用這個步驟。 記住，無論哪種方式，你都可以將 token 保存到`context`對象中，然后在后續步驟中從`context`對象獲取并使用。例如： ~~~ pythonCopy codecontext.access_token = get_access_token() ~~~ 然后在后續的步驟中： ~~~ pythonCopy codeuse_token(context.access_token) ~~~ ## u @given(u'The API endpoint is "{url}"') 這里的u 代表什么意思 這里的u是一個Python的修飾符，代表“Unicode字符串”。 在Python2中，字符串默認是ASCII編碼，如果你想定義一個Unicode字符串，需要在字符串前面加上u。例如： python Copy code s = u'This is a unicode string in Python 2'. 但在Python3中，所有的字符串默認都是Unicode字符串，所以這個u前綴不是必須的。 對于Behave的裝飾器@given，@when和@then，無論在Python 2還是Python 3中都可以在字符串前面加上u，也可以不加。上述語句可以簡化寫為： python Copy code @given('The API endpoint is "{url}"') 在Python 3中這樣寫是完全一樣的結果。 ## environment.py `environment.py`是一個特殊的文件，它被 Behave 測試框架用于配置一些全局的鉤子函數。這些函數會在測試運行的特定階段自動觸發，包括測試開始和結束， feature 開始和結束，以及 scenario 開始和結束。 下面是一個基本的`environment.py`文件示例： ~~~ pythonCopy code# This function is called before all tests are run def before_all(context): print("Doing setup before all tests...") # This function is called after all tests are run def after_all(context): print("Doing teardown after all tests...") # This function is called before each feature is run def before_feature(context, feature): print(f"Running feature: {feature}") # This function is called after each feature is run def after_feature(context, feature): print(f"Finished feature: {feature}") # This function is called before each scenario is run def before_scenario(context, scenario): print(f"Running scenario: {scenario}") # This function is called after each scenario is run def after_scenario(context, scenario): print(f"Finished scenario: {scenario}") ~~~ 當你運行 Behave 測試時，以上定義的函數會在適當的時機被自動調用。 注意，`context`參數是一個特殊的對象，它用于在所有的 step definitions 和鉤子函數中共享數據。你可以把它看作一個字典，用于在測試運行期間存儲數據。 一般來說，在鉤子函數中，你可能會進行一些通用的初始化和清理工作。例如，在`before_all`函數中連接到數據庫，在`after_all`函數中關閉數據庫等 ## Scenario Outline ~~~cucumber Feature: Test multiple APIs Scenario Outline: Test API get response Given I set the API endpoint as "<endpoint>" When I send a GET request Then the response code should be <status_code> Examples: | endpoint | status_code | ~~~ `Scenario Outline`允許我們為多個API定義相同的測試步驟。然后我們在`Examples`表中為每個API定義具體的值，Behave會為表格中每一行數據生成并執行一次相應的scenario。 在 Behave 中，`Scenario Outline`是一種特殊的場景，允許對同一流程的不同參數進行測試。它以模板的方式提供一個`Scenario`，然后使用表格的形式提供參數值。每一行參數值都會被用來生成一個新的`Scenario`。 這是一個簡單的例子： ~~~ cucumberCopy codeFeature: Washing clothes Scenario Outline: Washing different types of clothes Given I have a "<type_of_clothes>" When I wash the clothes Then the "<type_of_clothes>" should be clean Examples: | type_of_clothes | | "cotton shirt" | | "wool sweater" | | "synthetic pants" | ~~~ 在這個特征中，我有一個`Scenario Outline`，它說明了一個我需要測試的高級概念：洗滌不同類型的衣物。在`Examples`下面，我列出了我要測試的具體類型的衣物。 這樣，對于每一行`Examples`表格中的數據，Behave 都會生成并運行一次`Scenario`。在這個例子中，Behave 將運行三個不同的`Scenario`，分別測試洗滌棉質襯衫、羊毛毛衣和合成纖維褲子，每個`Scenario`都用到了不同的`<type_of_clothes>`參數值。 使用`Scenario Outline`可以避免編寫重復的行為定義，特別是當你需要測試的場景只是參數不同，而步驟基本一致的時候。 ## API測試的覆蓋度 API測試的覆蓋范圍可以根據API的特性和功能以及測試需求來決定，但通常來說，至少應該包括以下幾個主要方面： 1. **請求方法**：應該測試API支持的所有HTTP方法（如GET, POST, PUT, DELETE等）。 2. **請求參數**：應該測試所有能夠接受的請求參數，包括路徑參數、查詢參數、請求體等。 3. **驗證響應**：應該驗證API響應的各個組成部分，如狀態碼、頭部信息、響應體等。并確保它們符合預期。 4. **錯誤處理**：要確保API在出現錯誤時，比如無效的請求數據或系統內部錯誤，能返回適當的錯誤信息和狀態碼。 以下是一個表格，列出了API測試的常見覆蓋度檢查項： | 測試類型 | 描述 | | --- | --- | | 功能測試 | 測試API基礎功能是否按預期工作，如正確創建、讀取、更新和刪除資源 | | 合法性測試 | 測試API是否正確處理輸入數據，如無效數據、缺失數據、不匹配的數據類型等 | | 容錯性測試 | 測試API在異常情況下的行為，如系統負載過大、網絡中斷等 | | 安全性測試 | 測試API的安全防護機制，例如權限驗證、數據加密等 | | 性能測試 | 測試API在高負載或大數據量下的性能表現 | 總的來說，API測試的覆蓋度應該全面，確保考慮到所有可能的請求類型、參數、狀態和錯誤的組合，并確保API在所有情況下都能正常工作并返回預期的結果。 ## 每個步驟都是唯一 在 Behave 中，每一個`@given`、`@when`和`@then`裝飾的函數定義了一個特定的步驟，并且步驟的文本應該是唯一的。如果在不同的步驟定義文件中有相同文本的步驟被定義多次，Behave 會拋出錯誤，指出步驟已經定義過，并且通常會指明是在哪個文件中定義的。 錯誤信息如 "`@given('...')`has already been defined in ..." 意味著你已經有一個相同的步驟文本定義在另外一個步驟文件中。 這里有一些 Behave 的規范和最佳實踐，你可以按照這些建議防止出現這類錯誤： 1. **確保步驟是獨特的**：檢查步驟的定義確保每個步驟都是唯一的。如果步驟的功能相似，考慮重構步驟以接受參數。 2. **使用描述性的文本**：給步驟賦予足夠的描述性文本，以區分其他步驟。 3. **合理組織步驟文件**：步驟定義通常按照功能組織在不同的文件中。確保相關的步驟在合理的位置，并且文件命名清晰。 4. **避免重復的步驟文本**：如果多個功能文件（\*.feature）需要相似的步驟，可以考慮使用Background來共用，或者抽象成更通用的步驟。 5. **參數化步驟**：使用參數化步驟指定可變部分，而不是為相似步驟定義全新的步驟。 6. **審查代碼**：在代碼復審過程中注意檢查是否有重復步驟的情況。 7. **使用Behave的Tags和Hooks wisely**：如果有通用代碼或設置需要在不同的 scenarios 或features之間共享，考慮使用\_behave\_提供的tags和hooks系統。 為了糾正現有的問題，找到Behave報告已經定義過的步驟文本的位置，在該位置上檢查步驟函數。如果該步驟在你的feature測試中是必須的，并且確實應該存在，那么需要找到并去掉那個重復的步驟定義。如果步驟被不同的測試文件共享，確保它們在共通的步驟定義文件中被定義，而且只定義一次。 ## 參數化步驟 在Behave中，參數化步驟允許你用不同的數據重復執行相同的測試步驟。參數化可以通過兩種方式實現：Scenario Outlines或者使用步驟函數內部的表格數據。 ### 使用Scenario Outlines `Scenario Outline`需要一個`Examples`部分來定義參數的值。下面是一個`Scenario Outline`的例子，它演示了如何用不同的參數來測試一個用戶登錄功能。 ~~~ cucumberCopy codeFeature: Login functionality Scenario Outline: Successful login with different users Given the login page is displayed When the user attempts to login with username "<username>" and password "<password>" Then the user should be redirected to the dashboard Examples: | username | password | | alice | secret | | bob | password | | charlie | pass123 | ~~~ 每組`username`和`password`的組合都會運行同一個Scenario一次。 對應的步驟函數大概會是這樣： ~~~ pythonCopy codefrom behave import given, when, then @given('the login page is displayed') def step_impl_display_login_page(context): # 實現打開登錄頁面的操作 pass @when('the user attempts to login with username "{username}" and password "{password}"') def step_impl_attempt_login(context, username, password): # 實現登錄操作 # 可能需要用到 username 和 password context.username = username context.password = password pass @then('the user should be redirected to the dashboard') def step_impl_user_redirected_to_dashboard(context): # 確認用戶被重定向到dashboard pass ~~~ ### 使用步驟函數內部的表格數據 Behave也允許在步驟中直接使用表格來實現參數化。這在`given`,`when`或`then`步驟中使用多行文本或表格數據非常有用。 例如： ~~~ cucumberCopy codeScenario: Test users with different roles Given the following users exist | name | role | | Alice | admin | | Bob | user | When the users attempt to access the admin area Then only users with admin role should succeed ~~~ 對應的步驟文件： ~~~ pythonCopy codefrom behave import given, when, then @given('the following users exist') def step_impl_users_exist(context): for row in context.table: # 根據具體實現添加用戶到你的系統或測試環境 name = row['name'] role = row['role'] # 添加用戶到系統 pass @when('the users attempt to access the admin area') def step_impl_access_admin_area(context): # 嘗試使用各種用戶角色訪問管理區域 pass @then('only users with admin role should succeed') def step_impl_only_admins_succeed(context): # 確認用戶訪問管理區域權限驗證 pass ~~~ 在步驟函數中，你可以通過`context.table`來遍歷表格中的每一行。每行數據可以當作一個字典來處理，使用列名作為鍵值來訪問數據。 ## `tags`和`hooks` 在Behave中，`tags`和`hooks`是兩個重要的功能，它們增加了測試執行的靈活性和控制力。 ### Tags `Tags`用于對 features 或 scenarios 進行分類，你可以在執行測試時使用它們來包含或排除某些測試。Tag通過在 feature 或 scenario 前加上`@`符號來定義。 以下是標簽的一些用法示例： * 標記某個特定的 Scenario： ~~~ cucumberCopy code@login Scenario: Successful login Given I have a user account And I navigate to the login page When I submit my credentials Then I am logged in to the application ~~~ * 標記整個 Feature： ~~~ cucumberCopy code@billing Feature: Billing process ... ~~~ 你可以在運行測試時包含或排除這些標簽： ~~~ bashCopy code# 只運行標記了 @billing 的測試 behave --tags=@billing # 排除所有標記了 @wip 的測試 behave --tags=-@wip # 你可以組合tags來更細膩地控制測試執行 behave --tags=@billing --tags=-@skip ~~~ ### Hooks `Hooks`允許你在測試的不同階段插入自定義代碼，如在測試開始前、結束后、場景開始前或結束后等。Hooks 是定義在特定的生命周期事件上的函數，它們在 Behave 的特定時間點被自動調用。 以下是在 Python 中使用 hooks 的一些示例： * 在所有測試開始之前運行某個操作 (`before_all`hook)： ~~~ pythonCopy codedef before_all(context): ''' Perform setup actions before all tests, like initializing the database or starting a web server. ''' pass ~~~ * 在每個 Scenario 開始之前運行某些操作 (`before_scenario`hook)： ~~~ pythonCopy codedef before_scenario(context, scenario): ''' Perform setup actions before each scenario, like resetting the database to a known state. ''' pass ~~~ * 在每個 Step 開始前后運行某些操作 (`before_step`,`after_step`hooks)： ~~~ pythonCopy codedef before_step(context, step): ''' Perform some actions before each step. ''' pass def after_step(context, step): ''' Perform some actions after each step, such as taking a screenshot if the step failed. ''' if step.status == "failed": take_screenshot(step.name) ~~~ * 在測試結束后清理資源 (`after_all`hook)： ~~~ pythonCopy codedef after_all(context): ''' Perform cleanup actions after all tests have run, like shutting down the web server or closing database connections. ''' pass ~~~ Hooks 的這些自定義函數應該放在`features`目錄下的`environment.py`文件中。此文件是 Behave 查找全局 setup 和 teardown 邏輯的地方。 結合使用 tags 和 hooks，可以根據復雜的邏輯來靈活地管理測試流程，并對測試的準備和收尾活動有更多的控制。