❶ 軟體工程 測試應考慮的問題有哪些
所有的測試都是基於需求的！因此，最主要的還是得詳細的了解需求。
當然，軟體工程測試時需要考慮的問題包括：
1、需求是否是正確的，易於理解的，確保項目所有的人員對需求有一個正確的、一致的理解。
2、軟體設計時，需要考慮到軟體、硬體的各種不同的情況。我看您這個問題是在硬體類別的，特別需要考慮到硬體的兼容性、硬體的特殊功能測試等。
3、測試時，需要考慮到功能、性能、可用性、可靠性、穩定性等多個方面。當然，這個是得分階段的，可能一開始不會考慮這么多，但是還是最好一開始就能夠全部考慮進行。從整體上著手，這樣規劃出來會比較詳細，也更能從測試方面來保證軟體的質量。
❷ 軟體工程里，軟體測試報告怎麼寫
給你一個參考
GB/T 8567 計算機軟體文檔編制規范
❸ 軟體測試報告例文
以前寫的東西 省略著寫
XX軟體測試報告 共 x 頁 擬制 年 月 日審核 年 月 日會簽 年 月 日批准 年 月 日
1 范圍本文檔適用於XX軟體的單元/集成測試。1.2 系統概述1.3 文檔概述本文檔用於對XX軟體的測試工作階段成果的描述。包括對軟體測試的整體描述，軟體測試的分類和級別，軟體測試的過程描述，軟體測試的結果等內容。2 引用文檔《XX軟體需求規格說明》《XX軟體設計說明》《XX系統介面協議》3 測試概述3.1被測軟體的基本概況使用的編程語言：XXX 匯編語言程序行數：1590子程序個數：11單行注釋行數：669注釋率：約為42%3.1.1. 測試小結本次測試對XX軟體進行了靜態分析和動態測試。測試工作分為兩個階段。第一階段進行了軟體靜態分析，軟體測試人員和開發人員分別對軟體V1.00版本的代碼進行走讀。在此基礎上軟體開發人員對代碼走查中發現的問題進行了修改，做了97處代碼變更並提交了V1.01版本進行動態測試。在測試過程中針對發現的軟體缺陷進行了初步分析，並提交程序設計人員對原軟體中可能存在的問題進行考查。在軟體測試中首先根據軟體測試的規范進行考核，將書寫規范，注釋等基礎問題首先解決，其次考核軟體測試中的問題是否存在設計上的邏輯缺陷，如果存在設計缺陷則應分析該缺陷的嚴重程度以及可能引發的故障。軟體開發人員在以上基礎上對軟體的不足做出相應的修改，同時通過軟體回歸測試驗證軟體修改後能夠得到的改善結果。 軟體代碼1.00與1.01版變更明細表： 編號 1.00版行號 1.01版行號 更改說明 1 19 22 注釋變更 2 26 29 注釋變更 3 29 32 注釋變更 4 95 98 注釋變更 5 108行後 113～116 增加新變數 6 171、172 180、181 命令字大小寫變更 7 以下略 從上表可以看出，注釋變更一共有15處，主要排除了對原程序的理解錯誤問題；根據程序的書寫規范要求，一行多條語句改為一行一條語句的更改一共有42處；命令字大小寫變更一共有7處；在代碼走查中對冗餘和無用的代碼作了更改，將這些代碼注釋掉，此類更改一共有14處。上述4類更改一共有78處，這些更改對程序本身的功能沒有任何影響，但從軟體規范的角度來看提高了程序的可讀性和規范性。其餘19處變更為代碼變更，主要是在軟體測試中發現原程序的可靠性不足，在不改變原程序功能的基礎上相應的增加了新變數、新語句、新程序以提高整個程序的可靠性。在動態測試階段進行了單元測試和集成測試。此階段發現的軟體問題經軟體測試人員修改，提交了V1.02版本，軟體測試人員對此版本的軟體代碼進行了回歸測試，確認對前階段發現的軟體問題進行了修改，消除了原有的軟體問題並且確認沒有引入新的軟體問題。認定V1.02版為可以發行的軟體版本。3.1.1.1 靜態分析小結靜態測試採用人工代碼走查的方式進行。參加代碼走查的軟體開發人員有：（略）；參加代碼走查的軟體測試人員有：（略）。代碼走查以代碼審查會議的形式進行。靜態分析過程中共進行了四次會議審查。靜態測試階段的主要工作內容是：l 根據對軟體匯編源代碼的分析繪制詳細的程序流程圖和調用關系圖（見附件1）；l 對照軟體匯編源代碼和流程圖進行程序邏輯分析、演算法分析、結構分析和介面分析；l 對軟體匯編源代碼進行編程規范化分析。通過靜態測試查找出軟體的缺陷18個，其中輕微的缺陷4個，占所有缺陷的22.2％中等的缺陷11個，占所有缺陷的61.1％嚴重的缺陷：3個，占所有缺陷的16.7％上述軟體缺陷見附件《軟體問題報告單》3.1.1.2 動態測試小結動態測試使用的測試工具為XXX軟體集成開發環境。總共的測試用例數：143個。全部由測試人員人工設計。其中單元測試用例138個，集成測試用例5個。發現的軟體缺陷有2個，都是在單元測試過程中發現的。集成測試階段未發現新的軟體缺陷。在發現的軟體缺陷中：中等的缺陷1個，占所有缺陷的50％嚴重的缺陷1個，占所有缺陷的50％上述軟體缺陷見附件《軟體問題報告單》動態測試中代碼覆蓋率：代碼行覆蓋率 100%分支覆蓋率 100%程序單元調用覆蓋率 100％3.1.1.3 回歸測試小結對軟體測試過程中發現的缺陷經軟體開發人員確認後進行了代碼更改，並對更改後的代碼進行了回歸測試。本報告中的數據是回歸測試後的測試數據。3.1.1.4 測試分析下面將對此次軟體測試中的所有缺陷以及改進設計進行分析。1． 靜態測試中的缺陷分析： 1） 4個輕微缺陷屬於代碼冗餘，由於在程序設計中加入了部分調試程序，在程序設計完成後未將這些調試代碼注釋或刪除掉而造成代碼冗餘，但對程序本身的功能並無影響。修改後程序的效率得到提高。2） 11個中等缺陷屬於注釋變更，在原程序代碼的注釋中存在注釋不準確的問題，會影響程序員對程序的理解，修改後的程序提高了程序的可讀性。3） 重點分析3個嚴重缺陷：第一個嚴重缺陷屬於XX號的無效判別和相應的處理問題，程序對XX號進行無效判別時，判別界限並不完全，在本跟蹤程序中XX號的有效數為01-10（用4位表示），而判別無效時只判了為00的情況，沒有判別大於10的情況。而且在為00時也沒有作相應的處理，修改後的程序對設計進行了改進，詳見改進設計分析3。第二個嚴重缺陷屬於程序設計中讀取地址錯誤問題，經分析在調試中讀取的數據是正確的，但是讀取的地址與設計初衷不相符，修改後問題得到了解決，詳見改進設計分析1。第三個嚴重錯誤是近區/遠區子程序判斷與進入條件反了，經分析對程序的影響不大，但與設計初衷不一致，修改後問題得到了解決，詳見改進設計5。2． 動態測試中的缺陷分析：1） 中等缺陷1個，在程序的注釋中出現錯誤，將近區注釋為遠區，修改後問題得到了解決，提高了程序的可讀性。2） 嚴重缺陷1個，在XX號無效的判別中，本應判斷大於10，但誤設計為0，修改後經回歸測試問題得到了解決。 3． 改進的設計分析：（因和產品相關，略） 3.1.2 測試記錄a 測試時間：2005年8月5日至2005年9月17日。b 地點：（略）。c 硬體配置：P4CPU/2.0G，內存256M，硬碟1Gd 軟體配置：Wondows98，e 被測軟體版本號：V1.0，V1.01，V1.02f 所有測試相關活動的日期和時間、測試操作人員等記錄見軟體測試記錄文檔。4 測試結果在兩個階段測試過程中共發現軟體缺陷20個，經軟體開發人員確認的缺陷為20個，經過改正的代碼消除了所有以確認的軟體缺陷並通過了回歸測試。因測試條件所限，未能進行軟體的確認測試和系統測試。5 評估和建議5.1 軟體評估 5.1.1 軟體編碼規范化評估經過回歸測試，未殘留的軟體編碼規范性缺陷。軟體代碼文本注釋率約為42%，代碼注釋充分，有利與代碼的理解和維護。5.1.2 軟體動態測試評估被測軟體單元的總數：11個使用的測試用例個數：143個達到軟體測試出口准則的軟體單元數為11個，通過率100％通過單元和集成測試得知：軟體代碼邏輯清晰、結構合理、程序單元間介面關系一致，運行穩定。5.2 改進建議a. 建議在軟體開發項目中全面實施軟體工程化，加強軟體開發的管理工作。b. 建議進一步加強軟體需求規格說明、軟體設計文檔編制以及編寫代碼的規范化。特別是應該將系統中的硬體研製和軟體研製分別管理，軟體文檔編制的種類和規格按照相關標准執行。c. 盡早開展軟體測試工作。在軟體研製計劃安排上給軟體測試留有必要的時間，在資源配置上給軟體測試必要的支撐。d. 建議結合系統聯試，開展軟體的確認和系統測試。附件：軟體問題報告單（略）軟體更改通知單（略）軟體測試記錄（略）
❹ 軟體測試報告怎麼寫
摘要
測試報告是把測試的過程和結果寫成文檔，並對發現的問題和缺陷進行分析，為糾正軟體的存在的質量問題提供依據，同時為軟體驗收和交付打下基礎。本文提供測試報告模板以及如何編寫的實例指南。
關鍵字
測試報告 缺陷
正文
測試報告是測試階段最後的文檔產出物，優秀的測試經理應該具備良好的文檔編寫能力，一份詳細的測試報告包含足夠的信息，包括產品質量和測試過程的評價，測試報告基於測試中的數據採集以及對最終的測試結果分析。
下面以通用的測試報告模板為例，詳細展開對測試報告編寫的具體描述。
PARTⅠ 首頁
0.1頁面內容：
密級
通常，測試報告供內部測試完畢後使用，因此密級為中，如果可供用戶和更多的人閱讀，密級為低，高密級的測試報告適合內部研發項目以及涉及保密行業和技術版權的項目。
XXXX項目/系統測試報告
報告編號
可供索引的內部編號或者用戶要求分布提交時的序列號
部門經理 ______項目經理______
開發經理______測試經理______
XXX公司 XXXX單位 （此處包含用戶單位以及研發此系統的公司）
XXXX年XX月XX日
0.2格式要求：
標題一般採用大體字（如一號），加粗，宋體，居中排列
副標題採用大體小一號字（如二號）加粗，宋體，居中排列
其他採用四號字，宋體，居中排列
0.3版本控制：
版本 作者 時間 變更摘要
新建/變更/審核
PARTⅡ 引言部分
1.1編寫目的
本測試報告的具體編寫目的，指出預期的讀者范圍。
實例：本測試報告為XXX項目的測試報告，目的在於總結測試階段的測試以及分析測試結果，描述系統是否符合需求（或達到XXX功能目標）。預期參考人員包括用戶、測試人員、、開發人員、項目管理者、其他質量管理人員和需要閱讀本報告的高層經理。
提示：通常，用戶對測試結論部分感興趣，開發人員希望從缺陷結果以及分析得到產品開發質量的信息，項目管理者對測試執行中成本、資源和時間予與重視，而高層經理希望能夠閱讀到簡單的圖表並且能夠與其他項目進行同向比較。此部分可以具體描述為什麼類型的人可參考本報告XXX頁XXX章節，你的報告讀者越多，你的工作越容易被人重視，前提是必須讓閱讀者感到你的報告是有價值而且值得浪費一點時間去關注的。
1.2項目背景
對項目目標和目的進行簡要說明。必要時包括簡史，這部分不需要腦力勞動，直接從需求或者招標文件中拷貝即可。
1.3系統簡介
如果設計說明書有此部分，照抄。注意必要的框架圖和網路拓撲圖能吸引眼球。
1.4術語和縮寫詞
列出設計本系統/項目的專用術語和縮寫語約定。對於技術相關的名詞和與多義詞一定要註明清楚，以便閱讀時不會產生歧義。
1.5參考資料
1．需求、設計、測試用例、手冊以及其他項目文檔都是范圍內可參考的東東。
2．測試使用的國家標准、行業指標、公司規范和質量手冊等等
PARTⅢ 測試概要
測試的概要介紹，包括測試的一些聲明、測試范圍、測試目的等等，主要是測試情況簡介。（其他測試經理和質量人員關注部分）
2.1測試用例設計
簡要介紹測試用例的設計方法。例如：等價類劃分、邊界值、因果圖，以及用這類方法(3-4句)。
提示：如果能夠具體對設計進行說明，在其他開發人員、測試經理閱讀的時候就容易對你的用例設計有個整體的概念，順便說一句，在這里寫上一些非常規的設計方法也是有利的，至少在沒有看到測試結論之前就可以了解到測試經理的設計技術，重點測試部分一定要保證有兩種以上不同的用例設計方法。
2.2測試環境與配置
簡要介紹測試環境及其配置。
提示：清單如下，如果系統/項目比較大，則用表格方式列出
資料庫伺服器配置
CPU：
內存：
硬碟：可用空間大小
操作系統：
應用軟體：
機器網路名：
區域網地址：
應用伺服器配置
…….
客戶端配置
…….
對於網路設備和要求也可以使用相應的表格，對於三層架構的，可以根據網路拓撲圖列出相關配置。
2.3測試方法(和工具)
簡要介紹測試中採用的方法(和工具)。
提示：主要是黑盒測試，測試方法可以寫上測試的重點和採用的測試模式，這樣可以一目瞭然的知道是否遺漏了重要的測試點和關鍵塊。工具為可選項，當使用到測試工具和相關工具時，要說明。注意要註明是自產還是廠商，版本號多少，在測試報告發布後要避免大多工具的版權問題。
❺ 對學習軟體工程的一點建議.
軟體工程跟編程軟體幾乎不相關，軟體工程只是一些理論，光看理論書是沒用的。可以通過學習IBM Rational系列的產品來學習軟體工程，比如說，學習Rational clearcase必然會涉足軟體工程中的需求管理領域，學習Rational Rose必然會涉足到UML、面向對象分析和設計、Rup領域
❻ 我在一家軟體公司做測試，轉正要寫軟工希望及建議，誰能告訴我怎麼寫急急急急.......
你在軟體公司做測試，那你應該是學這方面知識的，根據你在測試期間對這家公司的了解，結合你所學的知識，提出你的一些改進的想法和建議，這應該不是什麼困難的事情，關鍵是要做到理論聯系實際，你的建議要有獨到之處，這樣老闆才會賞識你。
❼ 請問「其實建立符合軟體工程要求的質量管理體的說明……附一個測試報告」測試報告是哪裡出具的怎麼辦理
軟體產品不是有登記證書嗎？辦理軟體產品登記證都會有一個測試報告。