易修網怎么找回賬號和密碼(易修網怎么找回賬號和密碼蘋果手機)

前沿拓展：

---

一、 界面中的控件知識

1 文本框和密碼框

文本框

長度要求；

輸入內容限制。

密碼框

長度要求；

不允許明文顯示；

禁止復制粘貼；

輸入內容限制；

兩次密碼要一致。

2 單選按鈕、組合列表框、數碼框

單選按鈕

框架標題/提示文本不缺失且正確；

各個選項正確；

執行同一功能的多個單選按鈕只能選中一個；

要有默認選中項；

一般不能取消選中；

存入后臺的數據正確。

組合列表框/下拉列表

通常單選，條目內容要正確（沒有多余/錯放項、缺少項）；

橫向顯示要完整；

條目功能要正確實現；

組合列表框中可能允許輸入數據。

數碼框（up-down 控件）

能使用上下箭頭控制數字變動；

數字有范圍限制；

數字自動循環或者到達邊界時停止；

可以直接輸入數字。

3 復選框

復選框

選項正確；

可以不選、任意選一個、任意選多個、全選；

可以取消選中——每一個復選框功能都正確實現。

4 列表框

通常多選；條目內容要正確（多余/錯放項、缺少項）；橫向顯示完整，縱向顯示完整；條目功能要正確實現。

5 命令按鈕

實現所需的功能；出現錯誤時，給出切當明確的提示信息。

6 其他界面元素

窗口標題

不缺失；

顯示正確。

選項卡

ctrl+tab 切換

默認焦點Tab 順序快捷鍵/熱鍵

使用 ctrl 或 alt+其它字母

同一窗口、界面或菜單中不能重復

二、 大綱法分解功能

1 大綱法

大綱法主要用于對軟件進行功能拆分。

模塊

包含多個功能操作的對象或功能集合，如文件（菜單）等。

功能點/功能

能獨立完成一件事或一個業務。如新建、打開等。

業務流程

軟件為了完成業務或完成核心功能所經歷的步驟。

業務邏輯

是對業務的不同處理方式。

業務規則

如要求用戶名只能用英文，5-11 個字符等。

案例

即時貼程序部分需求說明

便簽的數量最多為 50 個

便簽標題字數最多為 40 個字節

便簽的正文文字數量最多為 200 個

年份只能設置在 1900－2100 之間

2 開始編寫測試需求分析

將功能拆分與整理的需求信息寫入測試需求分析

三、 測試需求分析與測試用例設計方法

1 場景法

1.1 測試點/檢查點

測試時應該考慮可以測試的諸多方面。

1.2 場景法概述

場景法模擬用戶操作軟件時的情景，主要用于測試系統的業務流程。當拿到一個測試任務時，我們先要關注它的主要功能和業務流程是否正確實現，這就需要使用場景法來完成測試。

1.3 場景的定義

場景用來描述軟件操作的路徑。基本流

按照正確的業務流程來實現的一條操作路徑（模擬正確的操作流程）。

備選流

導致程序出現錯誤的操作流程（模擬錯誤的操作流程）。

1.4 場景法的分析步驟

分析軟件需求從用戶使用情景角度，寫出業務流程和業務規則寫出基本流場景和備選流場景

1.5 場景法案例：ATM 機取款

步驟一：分析業務流程（可以繪制流程圖）

步驟二：描述程序的基本流及備選流

1、基本流（正確的流程）

（1）插入銀行卡：客戶將銀行卡插入 ATM 機的讀卡器

（2）驗證銀行卡：ATM 機從銀行卡的磁條中讀取賬戶代碼，并檢查它是否屬于可以接受的銀行卡

（3）輸入密碼：ATM 機要求客戶輸入密碼

（4）驗證密碼：確定該密碼是否正確

（5）進入 ATM 主界面：ATM 顯示在本機中可用的各種選項

（6）選擇取款并輸入金額：客戶選擇“取款”，并選擇取款金額

（7）ATM 機驗證：ATM 機進行驗證賬戶余額是否滿足以及總取款金額是否滿足要求，驗證 ATM 機內現金是否夠用

（8）更新賬戶余額、出鈔：驗證成功，更新賬戶余額，輸出現金，提示用戶收取現金

（9）返回主界面

2、備選流（各種錯誤情況）

（1）銀行卡無效：提示錯誤并退卡

（2）密碼錯誤：提示錯誤，并判斷是否 3 次錯誤

（3）密碼 3 次錯誤：吞卡

（4）賬戶余額不足：提示錯誤并退卡

（5）總取款金額超出當日可取限額：提示錯誤并退卡

（6）ATM 機余額不足：提示錯誤并退卡

步驟三：根據基本流和備選流生成不同的場景

1.6 場景法練習

2 等價類劃分

2.1 案例引入

測試兩位數加法器（學生思考、討論、陳述）

2.2 等價類劃分核心思想

通過需求分析，找出程序的輸入域。將輸入域劃分成若干類。每一類中選取代表性數據等價于這一類中的其他值。

2.3 等價類劃分的步驟

需求分析劃分等價類（根據需求，有效等價類、無效等價類）并細化（根據計算機知識）

2.4 等價類劃分案例

步驟 1：需求分析

閱讀文檔

借助開發知識

與開發或用戶溝通

了解用戶群及行業知識

寫出需求：-99~99 之間的整數

步驟 2：劃分等價類并細化

有效類

-99 到 99 之中的整數細化：負數 / 0 / 正數

無效類

超范圍：<-99 / >99非法類型：浮點數 / 字符（串）

2.5 等價類劃分練習

ATM 機的取款測試：取款最少 50，最多 5000，每筆 50 的倍數，測試取一筆。

2.6 等價類劃分注意事項

不但要考慮有效等價類，也要考慮無效等價類兩塊劃成一塊（等價類劃分過粗），結果？

遺漏一種測試情況

一塊劃成兩塊（等價類劃分過細），結果？

冗余測試

仔細劃分，審查劃分

過于粗略可能會漏掉軟件缺陷

積累經驗

2.7 思考題

密碼框的輸入范圍 4-10 位程序要求輸入 BOOLEAN 型數據Microsoft Office 中，選擇字體的組合框

要求用戶名由字母或數字組成，必須由字母開頭，不包含特殊字符，最大長度為12日期文本框

3 邊界值分析

3.1 一個缺陷

缺陷原因

3.2 邊界值分析的思想與步驟

分析需求，找出邊界。寫出邊界值

最小值

小于最小值

最大值

大于最大值

3.3 邊界值分析案例

兩位數加法計算器的邊界值

-99-10099100

3.4 為什么分析邊界值

看看下面的代碼有錯誤嗎？

輸入或輸出的邊界最容易產生錯誤。

3.5 邊界值分析練習

使用邊界值分析方法寫測試點

練習題講解

測試知識的儲備：了解開發原理，可能的編碼方式

if （bl >= 'A' && bl <= 'Z'）

if （bl >=65 && bl <=90）

if （bl > 64 && bl < 91）

if（bl>='0' && bl<='9'）

if（bl>=0 && bl<=9）

if （bl>= -32768 && bl <= 32767）

if （bl >= -99 && bl<= 99）

部分 ASCII

3.6 邊界值分析思考題

即時貼程序，考慮標題的測試

標題字數：1-40 字節

標題字數：0-40 字節

文本輸入域允許輸入 1-255 個字符

下拉列表

分頁

4 決策表

4.1 前面方法忽略的問題

測試兩位數加法計算器的測試沒有考慮輸入組合。

4.2 決策表的分析步驟

需求分析

分析輸入和輸出：用等價類劃分分析輸入的各種情況、輸出的各種情況

畫判定表分析與簡化判定表

4.3 決策表案例

分析輸入條件和輸出條件

輸入

輸入 1：

條件 1： 0<=X<=99

條件 2： -99<=X<0

條件 3： X<-99

條件 4： X>99

輸入 2：

條件 1： 0<=X<=99

條件 2： -99<=X<0

條件 3： X<-99

條件 4： X>99

輸出

正確計算

錯誤提示

原始決策表/判定表

優化決策表

優化策略

1、測試基本功能的保留；

2、一個輸入錯誤，另外輸入無所謂，可以整合；

3、所有輸入都要錯誤過。

最終的決策表

4.4 決策表練習

案例：某廠工資發放需求

工資分為年薪制，月薪制，兩者互斥

錯誤程度分為普通和嚴重，兩者可同時具備

年薪制員工犯普通錯誤扣工資 2％，犯嚴重錯誤扣工資 6％

月薪制員工犯普通錯誤扣工資 4％，犯嚴重錯誤扣工資 8％

4.5 決策表的適用范圍

適用于多種輸入的存在組合情況時。

4.6 決策表的局限性與優化策略

導致測試量爆炸。

決策表優化策略

5 錯誤推測

5.1 測試若干原則回顧

測試不是驗證軟件正確，而是攻擊軟件，發現錯誤。測試要時刻保持懷疑的態度，具有缺陷預防意識。測試要尋求系統設計、功能設計的弱點。設計負面的、異常的測試，如考慮錯誤的或者異常的輸入，往往可以發現更多的軟件缺陷。

5.2 什么是錯誤推測

在測試程序時，人們可以根據經驗或直覺推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的測試方法。

錯誤推測分類

輸入數據測試方面

輸出數據測試方面

數據結構測試方面

文件系統方面

5.3 輸入數據方面的錯誤推測

5.3.1 輸入非法數據

一般用于鍵盤輸入數據時。測試方法

輸入非法類型

輸入非法范圍/長度

輸入非法格式

注意

1、錯誤信息的檢查：需要額外考慮錯誤提示信息的內容

2、錯誤信息和錯誤要對應一致

3、錯誤信息不能為空

4、錯誤信息的內容不能只是錯誤代碼，不能包含開發信息

5、錯誤信息不能中英文混合

案例

5.3.2 輸入默認值

適用于有默認值的地方。測試方法

接受軟件的默認值

鍵入空值

將默認值改為另外一個值

將默認值改為另外一個值，再變為空值

5.3.3 輸入特殊字符（集）

適用于不能輸入有特殊含義的字符時。測試方法

根據被測軟件所處的操作系統、程序設計語言、后臺數據庫以及具體業務等信息列出表格，進行討論，標明哪些需要測試，哪些需要剔除。

了解具體行業知識，具體問題具體分析。

案例

文件命名以下特殊字符（33 個）：不能使用：\ / < > | “ : * ?，com0-com9，lpt0-lpt9，prn、aux、nul、con。

思考

用戶名有哪些特殊字符？

QQ 昵稱、聊天內容有哪些特殊字符？

5.3.4 輸入合法數據的非法組合

適用于輸入值之間存在依賴關系時。測試方法

輸入可能是出現問題的組合值。

案例

5.3.5 通過復制粘貼強制輸入程序不允許輸入的數據

5.4 輸出數據方面的錯誤推測

5.4.1 同一個輸入產生多種輸出

案例

輸入：一個電話打來

輸出：

狀態一：等待接聽。

狀態二：占線。

狀態三：停機。

狀態四：無法接通。

狀態五：關機。

狀態六：空號。

測試方法

詳細測試每一種輸出，不要有遺漏。

熟悉被測軟件業務知識，閱讀各種程序文檔，明確輸入可能產生的輸出，列出關于程序輸入于輸出的一個列表，然后進行測試。

思考

QQ 中有沒有類似的測試？

5.4.2 驗證輸出結果的正確性

測試方法

不僅測試輸入的正確性，還要檢查結果的正確性。

測試人員要盡可能多地學習所涉及問題的領域。

5.5 數據結構方面的錯誤推測

5.5.1 數據結構溢出

適用于程序中存在變量、數組等數據結構時。測試方法

1、變量

上溢：值太大

下溢：值太小

2、數組

上溢：數據量太多

下溢：數據量太少

思考

QQ 中有相關案例嗎？

5.5.2 計算結果溢出

案例

測試方法

輸入非法值或很大與很小數據，強制結果產生上溢或下溢。

5.5.3 操作數和操作符不符

案例

1、是否是缺陷？

如果是缺陷，開發人員修改成什么樣的結果，你作為測試人員會確認這個缺陷已經被修復？

適用于需要進行數值計算程序和圖形操作程序的測試時，如加、減、乘、除等。測試方法

找到程序中容易引起操作數和操作符不符的計算、表達式等。

5.6 文件系統方面的錯誤推測

5.6.1 使文件系統超載

適用于數據存儲到硬盤中時。案例

假設“軟件測試工程師管理系統”要保存 10000 個工程師信息，則保存時engineer.txt 文件可能會有 20M 大小，如果此時磁盤只有 10M 可用空間了，“軟件測試工程師管理系統”會如何動作呢？

測試方法

創建滿容量或近乎滿容量的文件系統，然后強制執行各種通過輸入或輸出訪問文件系統的操作。

打開足夠多的文件，文件打開時會強制創建備份副本，從而占用雙倍的存儲空間。

使用工具 Canned Heat，模擬文件系統超載。

5.6.2 更改文件訪問權限

適用于對文件進行讀寫的應用程序。測試方法

1、不同的用戶對相同文件具有不同的訪問權限，需要考慮登錄同一臺機器的多個用戶操作相同文件的權限問題。

打開一個文件，在操作系統中修改該文件的訪問權限。有些操作系統允許權限高的用戶控制一般用戶已經打開的文件。

2、兩個應用程序打開，關閉同一個文件。

如把同一應用程序的不同版本安裝在同一機器上，在不同版本的應用程序中打開和關閉同一文件；

試著在某個應用程序中打開在另一個程序中已打開的文件，這可能會導致文件訪問權限上出現沖突。

5.6.3 使介質忙或不可用

適用于應用程序的運行需要消耗大量內存或運行時需求其他相關軟件同時運行的情況。

大多數操作系統能同時運行多個應用程序，但相互切換時會有延遲，但是沒有對錯誤響應。

測試方法

通過啟動大量應用程序，強制它們都打開并保存文件來使文件系統處于忙的狀態；或者同時下載大量文件也可以使后臺擁擠。

使用一些測試工具來模擬磁盤的狀況。

5.6.4 介質損壞

使用場合

損壞的介質可能使操作系統傳回錯誤代碼，這些錯誤代碼可能沒有在應用程序中編程處理。

測試方法

損壞介質的方法使用不很多，只有少數公司采用，大多是開發操作系統、設備驅動程序以及以安全為主的應用程序的公司會采用這種測試方法。確定是否使用該方法，主要要考慮數據對用戶的重要性。

該方法可以使用實際損壞了的介質。檢查應用程序對錯誤的處理能力，應用程序可以對錯誤進行處理或者將問題告訴用戶，并且要確保用戶數據文件不丟失、不損壞。

也可以通過軟件模擬。

5.7 錯誤推測總結

輸入非法類型輸入非法范圍（數值）輸入非法長度（個數）輸入非法格式輸入默認值輸入特殊字符輸入合法數據的非法組合粘貼強制輸入一個輸入多個輸出不要遺漏輸出結果（含數據庫）要正確上溢、下溢（含結果）操作數與操作符不符文件超載文件權限不足介質忙或不可用介質損壞

6 編寫測試點

將測試點寫入測試需求分析說明書，或者 XMind 等，留存下以供將來編寫測試用例使用。

四、 需求評審

1 意義

對軟件需求進行正確性的檢查。保證軟件需求的可測試性。通過產品需求文檔的評審，與市場、產品、開發等各部門相關人員溝通，使得大家認識一致，避免在后期產生不同的理解，引起爭吵。通過產品需求文檔的評審，更好地理解產品的功能性和非功能性需求在需求文檔評審通過后，測試的目標和范圍就確定了。雖然此后會有需求的變更，但可以得到有效的控制，這樣可降低測試的風險。評審是否完成是以需求文檔獲得多方“郵件確認”或“簽字”通過為標志的。這不應該只體現在“簽字”形式上，更重要的是達到下面的結果。

所有參與方達成一致。

已發現的問題被闡述清楚、被修正。

2 需求評審的質量要求

正確性完備性易理解性一致性可行性易修改性可測試性可追溯性

3 需求評審的參加人員

用戶代表需求人員產品經理項目經理開發人員開發經理測試人員測試經理市場經理質量保證人員

4 測試人員參與評審時的注意事項

明確自己的角色和責任。熟悉評審內容，為評審做好準備，做細做到位。在評審會上，針對問題闡述觀點，而不是針對個人。可以分別討論主要的問題和次要的問題。在會議前或會議后可以就存在的問題提出自己建設性的意見。提高自己的溝通能力，采取適當的、靈活的表述方式。對發現的問題跟蹤下去。應該在需求形成的過程中進行分階段的多次評審，而不是一次評審。測試人員要善于提問，多思考

這些需求都是用戶提出來的嗎？

有沒有畫蛇添足的需求？沒有漏掉什么需求嗎？

和競爭對手的產品做過比較嗎？我們的產品優勢體現在哪里？

是否正確地描述了每個需求？這條描述是否存在二義性的問題？

我的理解和文檔作者的理解一致嗎？

拓展知識：