軟體工程因果圖

Ⅰ 軟體工程師是干什麼的

軟體工程師是從事軟體職業的人員的一種職業能力的認證，通過它說明具備了工程師的資格。軟體工程師是從事軟體開發相關工作的人員的統稱。它是一個廣義的概念，包括軟體設計人員、軟體架構人員、軟體工程管理人員、程序員等一系列崗位，工作內容都與軟體開發生產相關。

主要有以下職責：

1、指導程序員的工作。

2、參與軟體工程系統的設計、開發、測試等過程。

3 、協助工程管理人保證項目的質量。

4 、負責工程中主要功能的代碼實現。

5 、解決工程中的關鍵問題和技術難題。

6 、協調各個程序員的工作，並能與其它軟體工程師協作工作。

7、還要編寫各種各樣的軟體說明書，如：需求說明書，概要說明書等

8、考試科目工程師是中級職稱，考試的題目包括了計算機體系結構、軟體工程、資料庫、數據結構、編譯原理等計算機學科的基礎課程。

(1)軟體工程因果圖擴展閱讀：

軟體工程師的發展前景：

當今社會不論什麼職業的都需要一個不斷學習的環節，軟體工程師也一樣。雖然軟體工程師的工作不同於程序員但是一個軟體工程師其前身必定是一個優秀的程序員，軟體的開發工具、開發技術在不斷地發展。

我國軟體出口2010年規模達到215億元，軟體從業人員達到72萬人，在中國十大IT職場人氣職位中，軟體工程師位列第一位，軟體工程人才的就業前景十分樂觀。

畢業生主要在各大軟體公司、企事業單位、高等院校、各大研究所、國防等重要部門從事軟體設計、開發、應用與研究工作。

有關數據顯示，我國對軟體人才的需求已達20萬，並且以每年20%左右的速度增長，而高校計算機畢業生中的軟體工程人才還很缺乏，尤其是高素質的軟體工程人才的極度短缺。

Ⅱ 軟體工程20題選擇題

1~~5,BACAA 6~~10,BCBAA 有事 改天我在來答後是個吧~！~

Ⅲ 軟體測試的方法一共有幾種

1、從是否關心內部結構來看

（1）白盒測試：又稱為結構測試或邏輯驅動測試，是一種按照程序內部邏輯結構和編碼結構，設計測試數據並完成測試的一種測試方法。

（2）黑盒測試：又稱為數據驅動測試，把測試對象當做看不見的黑盒，在完全不考慮程序內部結構和處理過程的情況下，測試者僅依據程序功能的需求規范考慮，確定測試用例和推斷測試結果的正確性，它是站在使用軟體或程序的角度，從輸入數據與輸出數據的對應關系出發進行的測試。

（3）灰盒測試：是一種綜合測試法，它將「黑盒」測試與「白盒」測試結合在一起，是基於程序運行時的外部表現又結合內部邏輯結構來設計用例，執行程序並採集路徑執行信息和外部用戶介面結果的測試技術。

2、從是否執行代碼看

（1）靜態測試：指不運行被測程序本身，僅通過分析或檢查源程序的語法、結構、過程、介面等來檢查程序的正確性。

(2)動態測試：是指通過運行被測程序，檢查運行結果與預期結果的差異，並分析運行效率、正確性和健壯性等性能指標。

3、從開發過程級別看

（1）單元測試：又稱模塊測試，是針對軟體設計的最小單位----程序模塊或功能模塊，進行正確性檢驗的測試工作。其目的在於檢驗程序各模塊是否存在各種差錯，是否能正確地實現了其功能，滿足其性能和介面要求。

(2)集成測試：又叫組裝測試或聯合，是單元測試的多級擴展，是在單元測試的基礎上進行的一種有序測試。旨在檢驗軟體單元之間的介面關系，以期望通過測試發現各軟體單元介面之間存在的問題，最終把經過測試的單元組成符合設計要求的軟體。

（3）系統測試：是為判斷系統是否符合要求而對集成的軟、硬體系統進行的測試活動、它是將已經集成好的軟體系統，作為基於整個計算機系統的一個元素，與計算機硬體、外設、某些支持軟體、人員、數據等其他系統元素結合在一起，在實際運行環境下，對計算機系統進行一系列的組裝測試和確認測試。

在系統測試中，對於具體的測試類型有：

（1）功能測試：對軟體需求規格說明書中的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（2）性能測試：對軟體需求規格說明書的功能需求逐項進行的測試，以驗證功能是否滿足要求。

（3）介面測試：對軟體需求規格說明中的介面需求逐項進行的測試。

（4）人機交互界面測試：對所有人機交互界面提供的操作和顯示界面進行的測試，以檢驗是否滿足用戶的需求。

（5）強度測試：強制軟體運行在異常乃至發生故障的情況下（設計的極限狀態到超出極限），驗證軟體可以運行到何種程序的測試。

（6）餘量測試：對軟體是否達到規格說明中要求的餘量的測試。

（7）安全性測試：檢驗軟體中已存在的安全性、安全保密性措施是否有效的測試，

（8）可靠性測試：在真實的或模擬的環境中，為做出軟體可靠性估計而對軟體進行的功能（其輸入覆蓋和環境覆蓋一般大於普通的功能測試）

（9）恢復性測試：對有恢復或重置功能的軟體的每一類導致恢復或重置的情況，逐一進行的測試。

（10）邊界測試：對軟體處在邊界或端點情況下運行狀態的測試。

（11）數據處理測試：對完成專門數據處理功能所進行的測試。

（12）安裝性測試：對安裝過程是否符合安裝規程的測試，以發現安裝過程中的錯誤。

（13）容量測試：檢驗軟體的能力最高能達到什麼程度的測試。

（14）互操作性測試：為驗證不同軟體之間的互操作能力而進行的測試。

（15）敏感性測試：為發現在有效輸入類中可能引起某種不穩定性或不正常處理的某些數據的組合而進行的測試。

（16）標准符合性測試：驗證軟體與相關國家標准或規范（如軍用標准、國家標准、行業標准及國際標准）一致性的測試。

（17）兼容性測試：驗證軟體在規定條件下與若干個實體共同使用或實現數據格式轉換時能滿足有關要求能力的測試。

（18）中文本地化測試：驗證軟體在不降低原有能力的條件下，處理中文能力的測試。

4、從執行過程是否需要人工干預來看

（1）手工測試：就是測試人員按照事先為覆蓋被測軟體需求而編寫的測試用例，根據測試大綱中所描述的測試步驟和方法，手工地一個一個地輸 入執行，包括與被測軟體進行交互（如輸入測試數據、記錄測試結果等），然後觀察測試結果，看被測程序是否存在問題，或在執行過程中是否會有一場發生，屬於比較原始但是必須執行的一個步驟。

（2）自動化測試：實際上是將大量的重復性的測試工作交給計算機去完成，通常是使用自動化測試工具來模擬手動測試步驟，執行用某種程序設計語言編寫的過程（全自動測試就是指在自動測試過程中，不需要人工干預，由程序自動完成測試的全過程；半自動測試就是指在自動測試過程中，需要手動輸入測試用例或選擇測試路徑，再由自動測試程序按照人工指定的要求完成自動測試）

5、從測試實施組織看

（1）開發測試：開發人員進行的測試

（2）用戶測試：用戶方進行的測試

（3）第三方測試：有別於開發人員或用戶進行的測試，由專業的第三方承擔的測試，目的是為了保證測試工作的客觀性

6、從測試所處的環境看

（1）阿爾法測試：是由一個用戶在開發環境下進行的測試，也可以是公司內部的用戶在模擬實際操作環境下進行的測試

（2）貝塔測試：是用戶公司組織各方面的典型終端用戶在日常工作中實際使用貝塔版本，並要求用戶報告

(3)軟體工程因果圖擴展閱讀

軟體測試的內容：

1 得到需求、功能設計、內部設計說書和其他必要的文檔

2 得到預算和進度要求

3 確定與項目有關的人員和他們的責任、對報告的要求、所需的標准和過程 ( 例如發行過程、變更過程、等等 )

4 確定應用軟體的高風險范圍，建立優先順序、確定測試所涉及的范圍和限制

5 確定測試的步驟和方法 ── 部件、集成、功能、系統、負載、可用性等各種測試

6 確定對測試環境的要求 ( 硬體、軟體、通信等 )

7 確定所需的測試用具 (testware) ，包括記錄 / 回放工具、覆蓋分析、測試跟蹤、問題 / 錯誤跟蹤、等等

8 確定對測試的輸入數據的要求

9 分配任務和任務負責人，以及所需的勞動力

10 設立大致的時間表、期限、和里程碑

11 確定輸入環境的類別、邊界值分析、錯誤類別

12 准備測試計劃文件和對計劃進行必要的回顧

13 准備白盒測試案例

14 對測試案例進行必要的回顧 / 調查 / 計劃

15 准備測試環境和測試用具，得到必需的用戶手冊 / 參考文件 / 結構指南 / 安裝指南，建立測試跟蹤過程，建立日誌和檔案、建立或得到測試輸入數據

16 得到並安裝軟體版本

17 進行測試

18 評估和報告結果

19 跟蹤問題 / 錯誤，並解決它

20 如果有必要，重新進行測試

21 在整個生命周期里維護和修改測試計劃、測試案例、測試環境、和測試用具

Ⅳ 軟體工程黑盒子設計，求救啊。。。。期末要考的。。。

黑盒測試（Black-box Testing，又稱為功能測試或數據驅動測試）是把測試對象看作一個黑盒子。利用黑盒測試法進行動態測試時，需要測試軟體產品的功能，不需測試軟體產品的內部結構和處理過程。

採用黑盒技術設計測試用例的方法有：等價類劃分、邊界值分析、錯誤推測、因果圖和綜合策略。

黑盒測試注重於測試軟體的功能性需求，也即黑盒測試使軟體工程師派生出執行程序所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他類型的錯誤。

黑盒測試試圖發現以下類型的錯誤：

1）功能錯誤或遺漏；
2）界面錯誤；
3）數據結構或外部資料庫訪問錯誤；
4）性能錯誤；
5）初始化和終止錯誤。

一、黑盒測試的測試用例設計方法

·等價類劃分方法
·邊界值分析方法
·錯誤推測方法
·因果圖方法
·判定表驅動分析方法
·正交實驗設計方法
·功能圖分析方法

等價類劃分:

是把所有可能的輸入數據,即程序的輸入域劃分成若幹部分（子集）,然後從每一個子集中選取少數具有代表性的數據作為測試用例.該方法是一種重要的,常用的黑盒測試用例設計方法.

1) 劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數據對於揭露程序中的錯誤都是等效的.並合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入數據合理劃分為若乾等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試數據.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.

有效等價類:是指對於程序的規格說明來說是合理的,有意義的輸入數據構成的集合.利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能.

無效等價類:與有效等價類的定義恰巧相反.

設計測試用例時,要同時考慮這兩種等價類.因為,軟體不僅要能接收合理的數據,也要能經受意外的考驗.這樣的測試才能確保軟體具有更高的可靠性.

2）劃分等價類的方法:下面給出六條確定等價類的原則.

①在輸入條件規定了取值范圍或值的個數的情況下,則可以確立一個有效等價類和兩個無效等價類.

②在輸入條件規定了輸入值的集合或者規定了「必須如何」的條件的情況下,可確立一個有效等價類和一個無效等價類.

③在輸入條件是一個布爾量的情況下,可確定一個有效等價類和一個無效等價類.

④在規定了輸入數據的一組值（假定n個）,並且程序要對每一個輸入值分別處理的情況下,可確立n個有效等價類和一個無效等價類.

⑤在規定了輸入數據必須遵守的規則的情況下,可確立一個有效等價類（符合規則）和若干個無效等價類（從不同角度違反規則）.

⑥在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下,則應再將該等價類進一步的劃分為更小的等價類.

3）設計測試用例:在確立了等價類後,可建立等價類表,列出所有劃分出的等價類:

輸入條件 有效等價類 無效等價類

... ... ...

... ... ...

然後從劃分出的等價類中按以下三個原則設計測試用例:

①為每一個等價類規定一個唯一的編號.

②設計一個新的測試用例,使其盡可能多地覆蓋尚未被覆蓋地有效等價類,重復這一步.直到所有的有效等價類都被覆蓋為止.

③設計一個新的測試用例,使其僅覆蓋一個尚未被覆蓋的無效等價類,重復這一步.直到所有的無效等價類都被覆蓋為止.

邊界值分析法

邊界值分析方法是對等價類劃分方法的補充.

（1）邊界值分析方法的考慮:

長期的測試工作經驗告訴我們,大量的錯誤是發生在輸入或輸出范圍的邊界上,而不是發生在輸入輸出范圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.

使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試數據,而不是選取等價類中的典型值或任意值作為測試數據.

（2）基於邊界值分析方法選擇測試用例的原則:

1）如果輸入條件規定了值的范圍,則應取剛達到這個范圍的邊界的值,以及剛剛超越這個范圍邊界的值作為測試輸入數據.

2）如果輸入條件規定了值的個數,則用最大個數,最小個數,比最小個數少一,比最大個數多一的數作為測試數據.

3）根據規格說明的每個輸出條件,使用前面的原則1）.

4）根據規格說明的每個輸出條件,應用前面的原則2）.

5）如果程序的規格說明給出的輸入域或輸出域是有序集合,則應選取集合的第一個元素和最後一個元素作為測試用例.

6）如果程序中使用了一個內部數據結構,則應當選擇這個內部數據結構的邊界上的值作為測試用例.

7）分析規格說明,找出其它可能的邊界條件.

錯誤推測法

錯誤推測法: 基於經驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設計測試用例的方法.

錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例. 例如, 在單元測試時曾列出的許多在模塊中常見的錯誤. 以前產品測試中曾經發現的錯誤等, 這些就是經驗的總結. 還有, 輸入數據和輸出數據為0的情況. 輸入表格為空格或輸入表格只有一行. 這些都是容易發生錯誤的情況. 可選擇這些情況下的例子作為測試用例.

因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯系, 相互組合等. 考慮輸入條件之間的相互組合,可能會產生一些新的情況. 但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多. 因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例. 這就需要利用因果圖（邏輯模型）.

因果圖方法最終生成的就是判定表. 它適合於檢查程序輸入條件的各種組合情況.

利用因果圖生成測試用例的基本步驟:

(1) 分析軟體規格說明描述中, 那些是原因(即輸入條件或輸入條件的等價類),那些是結果(即輸出條件), 並給每個原因和結果賦予一個標識符.

(2) 分析軟體規格說明描述中的語義.找出原因與結果之間, 原因與原因之間對應的關系. 根據這些關系,畫出因果圖.

(3) 由於語法或環境限制, 有些原因與原因之間,原因與結果之間的組合情況不不可能出現. 為表明這些特殊情況, 在因果圖上用一些記號表明約束或限制條件.

(4) 把因果圖轉換為判定表.

(5) 把判定表的每一列拿出來作為依據,設計測試用例.

從因果圖生成的測試用例（局部,組合關系下的）包括了所有輸入數據的取TRUE與取FALSE的情況,構成的測試用例數目達到最少,且測試用例數目隨輸入數據數目的增加而線性地增加.

前面因果圖方法中已經用到了判定表.判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期,判定表就已被當作編寫程序的輔助工具了.由於它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確.

判定表通常由四個部分組成.

條件樁（Condition Stub）:列出了問題得所有條件.通常認為列出得條件的次序無關緊要.

動作樁（Action Stub）:列出了問題規定可能採取的操作.這些操作的排列順序沒有約束.

條件項（Condition Entry）:列出針對它左列條件的取值.在所有可能情況下的真假值.

動作項（Action Entry）:列出在條件項的各種取值情況下應該採取的動作.

規則:任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然,判定表中列出多少組條件取值,也就有多少條規則,既條件項和動作項有多少列.

判定表的建立步驟:（根據軟體規格說明）

①確定規則的個數.假如有n個條件.每個條件有兩個取值（0,1）,故有 種規則.

②列出所有的條件樁和動作樁.

③填入條件項.

④填入動作項.等到初始判定表.

⑤簡化.合並相似規則（相同動作）.

B. Beizer 指出了適合使用判定表設計測試用例的條件:

①規格說明以判定表形式給出,或很容易轉換成判定表.

②條件的排列順序不會也不影響執行哪些操作.

③規則的排列順序不會也不影響執行哪些操作.

④每當某一規則的條件已經滿足,並確定要執行的操作後,不必檢驗別的規則.

⑤如果某一規則得到滿足要執行多個操作,這些操作的執行順序無關緊要.

黑盒測試的優點

1. 基本上不用人管著，如果程序停止運行了一般就是被測試程序crash了
2. 設計完測試例之後，下來的工作就是爽了，當然更苦悶的是確定crash原因

黑盒測試的缺點

1. 結果取決於測試例的設計，測試例的設計部分來勢來源於經驗，OUSPG的東西很值得借鑒
2. 沒有狀態轉換的概念，目前一些成功的例子基本上都是針對PDU來做的，還做不到針對被測試程序的狀態轉換來作
3. 就沒有狀態概念的測試來說，尋找和確定造成程序crash的測試例是個麻煩事情，必須把周圍可能的測試例單獨確認一遍。而就有狀態的測試來說，就更麻煩了，尤其不是一個單獨的testcase造成的問題。這些在堆的問題中表現的更為突出。

黑盒測試（功能測試）工具的選擇

那麼，如何高效地完成功能測試？選擇一款合適的功能測試工具並培訓一支高素質的工具使用隊伍無疑是至關重要的。盡管現階段存在少數不採用任何功能測試工具，從事功能測試外包項目的軟體服務企業。短期來看，這類企業盈利狀況尚可，但長久來看，它們極有可能被自動化程度較高的軟體服務企業取代。

目前，用於功能測試的工具軟體有很多，針對不同架構軟體的工具也不斷推陳出新。這里重點介紹的是其中一個較為典型自動化測試工具，即Mercury公司的WinRunner。

WinRunner是一種用於檢驗應用程序能否如期運行的企業級軟體功能測試工具。通過自動捕獲、檢測和模擬用戶交互操作，WinRunner能識別出絕大多數軟體功能缺陷，從而確保那些跨越了多個功能點和資料庫的應用程序在發布時盡量不出現功能性故障。

WinRunner的特點在於: 與傳統的手工測試相比，它能快速、批量地完成功能點測試; 能針對相同測試腳本，執行相同的動作，從而消除人工測試所帶來的理解上的誤差; 此外，它還能重復執行相同動作，測試工作中最枯燥的部分可交由機器完成; 它支持程序風格的測試腳本，一個高素質的測試工程師能藉助它完成流程極為復雜的測試，通過使用通配符、宏、條件語句、循環語句等，還能較好地完成測試腳本的重用; 它針對於大多數編程語言和Windows技術，提供了較好的集成、支持環境，這對基於Windows平台的應用程序實施功能測試而言帶來了極大的便利。

WinRunner的工作流程大致可以分為以下六個步驟:

1．識別應用程序的GUI

在WinRunner中，我們可以使用GUI Spy來識別各種GUI對象，識別後，WinRunner會將其存儲到GUI Map File中。它提供兩種GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大區別是後者對每個測試腳本產生一個GUI文件，它能自動建立、存儲、載入，推薦初學者選用這種模式。但是，這種模式不易於描述對象的改變，其效率比較低，因此對於一個有經驗的測試人員來說前者不失為一種更好的選擇，它只產生一個共享的GUI文件，這使得測試腳本更容易維護，且效率更高。

2．建立測試腳本

在建立測試腳本時，一般先進行錄制，然後在錄制形成的腳本中手工加入需要的TSL（與C語言類似的測試腳本語言）。錄制腳本有兩種模式: Context Sensitive和Analog，選擇依據主要在於是否對滑鼠軌跡進行模擬，在需要回放時一般選用Analog。在錄制過程中這兩種模式可以通過F2鍵相互切換。

只要看看現代軟體的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點滑鼠就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟體的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

3．對測試腳本除錯(debug)

在WinRunner中有專門一個Debug Toolbar用於測試腳本除錯。可以使用step、pause、breakpoint等來控制和跟蹤測試腳本和查看各種變數值。

4．在新版應用程序執行測試腳本

當應用程序有新版本發布時，我們會對應用程序的各種功能包括新增功能進行測試，這時當然不可能再來重新錄制和編寫所有的測試腳本。我們可以使用已有的腳本，批量運行這些測試腳本測試舊的功能點是否正常工作。可以使用一個call命令來載入各測試腳本。還可在call命令中加各種TSL腳本來增加批量能力。

5．分析測試結果

分析測試結果在整個測試過程中最重要，通過分析可以發現應用程序的各種功能性缺陷。當運行完某個測試腳本後，會產生一個測試報告，從這個測試報告中我們能發現應用程序的功能性缺陷，能看到實際結果和期望結果之間的差異，以及在測試過程中產生的各類對話框等。

6．回報缺陷（defect）

在分析完測試報告後，按照測試流程要回報應用程序的各種缺陷，然後將這些缺陷發給指定人，以便進行修改和維護。

常用的功能測試方法

功能測試就是對產品的各功能進行驗證，根據功能測試用例，逐項測試，檢查產品是否達到用戶要求的功能。常用的測試方法如下：
1. 頁面鏈接檢查：每一個鏈接是否都有對應的頁面，並且頁面之間切換正確。
2. 相關性檢查：刪除/增加一項會不會對其他項產生影響，如果產生影響，這些影響是否都正確。
3. 檢查按鈕的功能是否正確：如update, cancel, delete, save等功能是否正確。
4. 字元串長度檢查: 輸入超出需求所說明的字元串長度的內容, 看系統是否檢查字元串長度,會不會出錯.
5. 字元類型檢查: 在應該輸入指定類型的內容的地方輸入其他類型的內容(如在應該輸入整型的地方輸入其他字元類型),看系統是否檢查字元類型,會否報錯.
6. 標點符號檢查: 輸入內容包括各種標點符號,特別是空格,各種引號,回車鍵.看系統處理是否正確.
7. 中文字元處理: 在可以輸入中文的系統輸入中文,看會否出現亂碼或出錯.
8. 檢查帶出信息的完整性: 在查看信息和update信息時,查看所填寫的信息是不是全部帶出.,帶出信息和添加的是否一致
9. 信息重復: 在一些需要命名,且名字應該唯一的信息輸入重復的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的前後輸入空格,系統是否作出正確處理.
10. 檢查刪除功能:在一些可以一次刪除多個信息的地方,不選擇任何信息,按」delete」,看系統如何處理,會否出錯;然後選擇一個和多個信息,進行刪除,看是否正確處理.
11. 檢查添加和修改是否一致: 檢查添加和修改信息的要求是否一致,例如添加要求必填的項,修改也應該必填;添加規定為整型的項,修改也必須為整型.
12. 檢查修改重名:修改時把不能重名的項改為已存在的內容,看會否處理,報錯.同時,也要注意,會不會報和自己重名的錯.
13. 重復提交表單：一條已經成功提交的紀錄，back後再提交，看看系統是否做了處理。
14. 檢查多次使用back鍵的情況: 在有back的地方,back,回到原來頁面,再back,重復多次,看會否出錯.
15. search檢查: 在有search功能的地方輸入系統存在和不存在的內容,看search結果是否正確.如果可以輸入多個search條件,可以同時添加合理和不合理的條件,看系統處理是否正確.
16. 輸入信息位置: 注意在游標停留的地方輸入信息時,游標和所輸入的信息會否跳到別的地方.
17. 上傳下載文件檢查：上傳下載文件的功能是否實現，上傳文件是否能打開。對上傳文件的格式有何規定，系統是否有解釋信息，並檢查系統是否能夠做到。
18. 必填項檢查：應該填寫的項沒有填寫時系統是否都做了處理，對必填項是否有提示信息，如在必填項前加*
19. 快捷鍵檢查：是否支持常用快捷鍵，如Ctrl C Ctrl V Backspace等，對一些不允許輸入信息的欄位，如選人，選日期對快捷方式是否也做了限制。
20. 回車鍵檢查: 在輸入結束後直接按回車鍵,看系統處理如何,會否報錯.812799630您好!今後一起共勉！有時間逛逛IT實驗室,天天軟體測試網

Ⅳ 成教〈軟體工程〉復習題答案，高分求救，謝謝大家（三）

又是你，知識是別人的，還是要裝在自己腦子里才是自己的哈

Ⅵ 請問軟體工程師的面試，關於所做過項目一般會問那些方面的內容

那要看具體面試什麼職位了，初級的一般無非就是功能測試多一些，比如
1.軟體測試整個流程是什麼，
2.測試設計，測試計劃，測試用例編寫方法，用例執行
3.bug跟蹤管理，測試報告
重點還是用例的編寫，等價類，邊界值，因果圖等
如果是中高級的話，介面測試，性能測試等等部分會問到一些，包括軟體測試管理等等