第一篇：項目需求分析報告

項目需求分析報告

（一）一、項目名稱

今日事

二、設計背景

隨著社會的發展，我們的生活節奏逐漸加快，與此同時，網絡的大量普及，導致大量的信息不斷的沖擊著我們。在這種生活節奏下，我們難免會出現一不小心忘掉一些重要的事情，這是讓我們產生這個想法的一個方面。

另一方面，現如今的學生總是計劃很多，卻很少付諸行動，這不僅與個人的堅持與否有關，同樣是因為步入大學時代后，大家心中充滿了迷茫所致，往往計劃趕不上變化，因此，我們決定開發這樣一款軟件，來改變這種情況。

三、項目風險

該軟件開發項目的風險承擔者有：

任務提出者：需要承擔的風險是產品是否能達到用戶的需求，該產品是否能帶來收益。

軟件開發者：需要承擔的風險是產品是否能滿足需求報告說明書里的各種功能需求等。

產品使用者：需要承擔的風險是產品是否能滿足自己所需。

四、功能需求

日歷功能，可以查詢日期

制定計劃功能，分為長期，中期，短期三個層次，短期即為今日事，中期為1周或1月，長期為數月或1年，這些可以由用戶自己設置。

完成計劃功能，可以通過勾選來標注哪些是已經完成的，哪些是還為完成的。

成就系統，通過統計各期所完成計劃數量給予用戶相應稱號，同時可以與其他用戶進行競爭。

提醒功能，手機解屏時提醒用戶今日需要做的事，而在每天結束時，匯報今日完成進度。

五、運行環境

移動端android平臺

六、性能要求

為保證軟件能夠長期，安全，穩定，高效的運行，應滿足以下性能要求：

時間特性：系統響應時間應在人的感覺和視覺范圍內（<1S），系統響應時間足夠迅速（<5s）。

適應性：在操作方式，運行環境，軟件接口或開發計劃發生變化時，應具有適應能力。

項目需求分析報告

（二）一、引言

引言是對這份軟件產品需求分析報告的概覽，是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔

1.1編寫目的：

本需求分析報告的目的是規范化本軟件的編寫，旨在于提高軟件開發過程中的能見度，便于對軟件開發過程中的控制與管理，同時提出了本學校排課系統的軟件開發過程，便于程序員與客戶之間的交流、協作，并作為工作成果的原始依據，同時也表明了本軟件的共性，以期能夠獲得更大范圍的應用，同時它也是進行項目策劃、概要設計和詳細設計的基礎，是維護人員進行內部維護，信息更新，驗收和測試的依據。

1.2背景及范圍

本項目的名稱：學校排課系統。

本項目的任務提出者及開發者是：計算機應用三班張哲，用戶是學校。

本產品是針對電腦進行排課的需求設計的，可以完成：基本數據錄入與維護、課程表編排、課表沖突分析報告、課表輸出、可以直接或導出至Excel打印總課表、教師課表、()班級課表、場地課表、系統管理。

1.3定義 縮寫詞

學校排課系統軟件：學校排課系統軟件是為了幫助學校老師對學校的排課更加方便和快速制作處課程表及其管理學校的課程的軟件。

二、項目描述：

使用改程序后，學校的排課可以很輕松的安排好，而卻可以盡量避免平時排課時出現的排課沖突，還可以臨時加補課等功能。

2.1軟件開發的目標：

改善目前有些學校人工排課是常常出現的沖突以及浪費的大量時間。同時也通過實踐來提高自己的動手能力。

2.2應用范圍：

理論上能實現中小學排課，職業中學排課。

2.3子集說明：

軟件主要分為兩個模塊，一個基本信息的錄入，一個是進行排課的管理。

2.4軟件功能描述：

外部功能：實現了可視化窗口，排課，調課。

內部功能：基本信息的錄入、固定課的設置、科目的錄入、年級的錄入、任課老師的錄入、場地限制的錄入和課表的查看；排課操作、調課操作、場地調課操作、老師課表及學生課表生成。

2.5軟件操作人員的要求

軟件的操作人員要求具有一定的電腦常識，并且具有排課的初步常識。

三、軟件結構化描述

自己添加一些

四、環境要求：

4.1數據錄入精度需求

在進行向數據庫錄入數據時，要求數據記錄準確。

4.2軟件自身時間特性需求

程序排課響應時間：由于生成課表是需要看電腦的配置，所有時間可能會不一樣，有時候需要等上幾分鐘

五、軟件屬性

5.1可用性

本軟件由于自身的能力限制，所有只限現在所有的功能。

5.2安全性

由于軟件運行數據放在數據庫中，所以參數不容易被錯改、破壞，萬一參數受到破壞，可以從新錄入信息進行更正

5.3可維護性

本軟件利用數據庫進行編程，系統結構由程序基本確定，大量的參數及文本內容全部放于數據庫中。修改、更新數據只要在數據庫進行修改添加，而不需要對系統結構進行修改，這樣系統維護性十分方便。

5.4兼容性

由于尚未測試，故無法對兼容性進行評析。

第二篇：項目需求分析報告

福州八中鰲峰初級中學項目的網絡需求分析報告

一、項目名稱：福州八中鰲峰初級中學

二、引言

該網絡是校園網站信息發布系統,學校主站，含各個學科子站點，包含德育處，團委，學生會，教務處，總務處，辦公室，工會子站。主要欄目設置：學校概況、信息中、黨群工作、校務公開、德育教育、教學管理、教學科研、學生園地、中高考專題、心靈驛站、校友之窗、友情鏈接、數字校園

三、系統目標描述和功能描述

1、信息發布系統

網站前臺模塊

首頁：學校網站的索引頁，還包括模糊搜索站內資源的功能。

一中概況：發布學校的簡介、發展狀況和學校自身的相關信息，并動態歸類。

黨團組織：發布學校黨團建設的相關資訊，并動態歸類。

學校資訊：發布學校近期活動和新聞。

學校管理：發布學校各部門的相關通知與文件，并動態歸類。

教學教研：發布學校在教學研討和課題研究方面的相關信息，并動態歸類。

教學資源：管理和發布論文、課件、教案和考卷等方面的資源。

電子像冊：１．可以上傳圖片格式，FLASH格式等（格式要求：Jpg、GIF、ＰＮＧ、ＢＭＰ、SWF、TIF等）２．實現圖片漸變編輯功能。３．新增、刪除、修改４．權限管理 新課程：發布學校在新課程方面取得的成績，并動態歸類。

班級&社團：為各班級各社團開設空間，供發布信息和照片。

教師博客管理系統：自我簡介，消息管理，空間管理，好友管理，日志管理等。

電子相冊：可包含多個相冊，數量不限；

班級&社團：可在不影響界面整體效果的基礎上讓相應班級修改部分界面元素（包括自定義班級主頁的標志性圖片、班級主頁的背景圖片和班級主頁的顏色主題），另外，該模塊還包含有班級電子相冊。

留言板：實現留言與答復的功能。

學生論壇：學習網絡上開源論壇的實現方式，實現一個學生交流活動的平臺。相對獨立于學校網站。

后臺功能模塊

權限管理使用指南權限管理下共分3個模塊：[角色管理] [給角色分配權限][給用戶分配權限]

（1）通知公告只有系統管理員ADMIN才有權發布通知公告。發布的內容將顯示在各部門首頁的公告欄里。

（2）網上調查只有系統管理員ADMIN才有權發布網上調查。發布的內容將顯示在各部門首頁的網上調查里。

（3）友情鏈接只有系統管理員ADMIN才有權編輯友情鏈接。發布的內容將顯示在各部門

首頁的友情鏈接里。

2、辦公信息化管理系統

主要功能：今日工作：是用戶進行日常辦公的主要場所，用來存放待處理的有關文件、網絡報送以及工作消息等信息。

公文系統：用于公文的登記、發布、存檔以及生成報表。

工作消息：用戶發布日常工作中的通知等信息。

網絡報送：傳遞相關工作資料。

交流登記：記錄學校大事件以及每次對外交流情況等。

教師檔案：有關教師檔案管理，全程維護每一位教師檔案的變動情況。

系統設置：系統日常運作與環境設置。

3網絡性能需求

核心交換機（機箱式）

1、背板帶寬≥640Gbps2、交換容量≥480Gbps3、包轉發率≥350Mpps4、雙電源模塊冗余5、10/100/1000Base-T口≥12個，千兆SFP光纖接口≥24個

6、萬兆XFP接口≥1個

7、支持IP ACL，支持基于源/目的IP或MAC、三層IP協議類型、TCP/UDP四層端口號、IP優先級、基于VLAN、Tag/Untag、CoS等

9、支持802.3ad(LACP)，支持負載均衡

10、支持802.1Q VLAN數量≥4K11、支持的路由協議，如RIPv1/V2,并支持MD5認證、OSPFv2、BGP4等。

12、支持MPLS、MPLS VPN、MPLS TE功能。

接入層交換機

1、固化10/100M電口≥242、固化千兆Combo(SFP/GT)接口≥

23、交換容量≥32Gbps4、包轉發速率≥6.6Mpps，全線速

5、MAC表容量≥16K6、Vlan表項≥4K7、堆疊或者集群管理數量≥248、每個端口提供4個優先級隊列，可分別設定隊列帶寬，支持WRR/SP/SWRR等調度方式。

9、內置 DHCP Server,可對用戶分配IP地址。

10、支持標準和擴展ACL，完全硬件線速實現。

11、支持防IP報文DOS攻擊。

12、支持ARP安全功能，可以防止ARP欺騙、防止ARP掃描。

13、設備與核心交換機同一品牌；

光纖模塊SFP-SX-L SFP-SX-L，1000Base-SX SFP接口卡模塊（MMF,550m），LC接口 設備與核心交換機同一品牌；按廠家規定保修.防火墻在服務器與路由器之間加個防火墻很有必要。網絡操作系統，網絡服務器軟件等可能存在一些安全漏洞，應當及時對系統進行補丁程序升級，加固系統的安全性。網絡系統遵循安全規范和達到的安全級別，采用各種殺毒軟件。

網絡管理系統

基本特性:全中文圖形化界面。支持平臺:WINDOWS平臺，系統呈現網絡的真實拓撲圖，支持三層網絡拓撲、二層物理拓撲、VLAN子網拓撲等不同的呈現方式，支持拓撲的自動發現設備，WEB拓撲視圖。能夠發現VLAN中所有終端PC設備，并計算出終端設備IP地址、MAC地址、接入交換機端口等信息，自動在拓撲圖上顯示終端設備連接和出入流量、丟包等等情況。

根據我們的預算和資源限制，完成該項目大約需要半年。客戶想重新購置設備并賣掉現存的舊設備。

第三篇：怎么做項目需求分析報告

項目需求分析，看了聽棠的“客戶需求何時休”，深有感觸，何曾自己不是被這個問題整天困擾：客戶需求，為什么總在變阿？做項目真辛苦阿！這樣的感嘆整天都掛在口上。客戶需求變動確實是一個軟件開發永遠不變的話題。為什么小的軟件企業面對經常變動的需求是如此的狼狽？到底要怎么做才能滿足客戶的需求？

聽棠的“客戶需求何時休”深刻的披露了這個問題存在的根源。

需求分析，不僅僅是拿到客戶的需求，更重要的是還需進行分析，了解細節，并就細節跟客戶咨詢，獲取最詳細的資料。客戶所能提供給你的只是他們想到的功能需求，很多問題并不在他們考慮的范圍之內，如果作為項目承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，自然需要更改，被看成了需求的更改。其實，都是缺乏分析所一手造成的。問題等到系統出來了才被發現，這樣的系統本身就是先天不足的了。

聽棠所說到的幾點，感受特別深：

“其實問題出在開頭，客戶需求只是軟件需求分析的一部分，雖然是比較重要的一部分，但也不要只是去記客戶的需求，而是要把客戶的需求進行分析”

“客戶本身是不怎么懂技術的，客戶只知道自己的業務需求，而在軟件設計時，是在把業務需求抽象到系統中實現的，把業務轉變為邏輯時，一切都應該符合邏輯的，但客戶的業務思想有時候在軟件系統實現時會有問題的，這就需要分析時分析出來的。少了分析，問題也會在后面的開發中暴露出來，到時可就更麻煩了。”

還有客戶的需求本身會有矛盾（這矛盾是指在邏輯角度來講），客戶本身是意識不到的，只有在分析設計時，才會分析出這里的矛盾，而這些問題，如果在期初時，軟件負責人不分析，而是純粹的“聽從”客戶要求去做，當暴露這些問題時，你怪客戶也沒用啊。

項目需求分析報告，在了解客戶需求時，不要不動腦子，不要一味的點頭說“I C”，其實在表面的業務里面可能包含著N多的細節，這些細節是需要你反問客戶的，只有當你提的問題越多，最終獲取的需求最具體，才能讓項目越順利。而且有很多問題，都是在你的反問中，客戶也才開始思考本來沒思考過的問題，客戶也會找到一種合理的需求給你，有人會覺得這樣了解客戶需求未免太麻煩了。至于一些在技術上會遇到問題的地方，也要告訴客戶，別以為到時候再說，客戶是不關心你的技術細節的，但你如果給他解釋的話，他也會試著理解的。

客戶的需求本身是無休止，因為他們本身也在變，但當你期初的分析合理，后面的變動也將在邏輯上變動，相信代價已經不會那么大了。這其實也體現了系統的擴展性。

需求分析，是一個項目提出方和承擔方相互溝通的過程，一方是系統的使用者，一方是系統的制造者，在系統制造過程中，只有雙方相互配合，共同對系統進行設計才能最后達到使用的要求。客戶是業務上的熟悉者，對業務流程有非常清晰的了解，但是，對于軟件需求方面的描述是不了解的，他們所能提供的只是他們最終要達到的功能，但是，這其中包含的業務流程是非常復雜的。我們拿到客戶需求后，應該根據功能、流程進行初步的設計，構造出業務流程圖，再讓客戶進行評審，提出業務流程上不對的地方進行修改。這樣來回的交流，最終才能取得較全面的需求，并減少后期的修改。

謹記一點，需求是經常變動的，只有先做好需求的分析，了解業務以后的發展趨勢，做好具有拓展性的系統設計，才會給系統更大的擴展空間，從而在需求發生變化的時候可以更從容的修改。

第四篇：需求分析報告

需求分析報告

一、所謂“需求分析”，是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什么數據，要得到什么結果，最后應輸出什么。可以說，“需求分析”就是確定要計算機“做什么”。

需求分析是一項重要的工作，也是最困難的工作。該階段工作有以下特點：

（1）用戶與開發人員很難進行交

（2）用戶的需求是動態變化的（3）系統變更的代價呈非線性增長

二、為什么要需求分析

需求分析具有決策性，方向性，策略性的作用。在軟件分開發過程中具有舉足輕重的作用，大家一定要對需求分析具有足夠重視！

三、需求分析的任務

需求分析的任務就是解決“做什么”的問題，就是要全面地理解用戶的各項要求，并準確的的表達用戶的需求。

四、需求分析的過程

需求分析的階段工作可以分為四個方面：問題識別、分析與綜合、制定規格說明、評審。

主要代碼：

using System;using System.Collections.Generic;using System.ComponentModel;using System.Data;using System.Drawing;using System.Linq;using System.Text;using System.Windows.Forms;

namespace 擲骰子

{public partial class Form1 : Form{public Form1(){InitializeComponent();}

private void btnbegin_Click(object sender, EventArgs e){if(txtname1.Text == “" || txtname2.Text == ”“){MessageBox.Show(”請輸入名字“);

return;}

Random ran1 = new Random(unchecked((int)DateTime.Now.Ticks));int i1 = ran1.Next(1, 7);txtdot1.Text = Convert.ToString(i1);Random ran2 = new Random();int i2 = ran2.Next(1, 7);txtdot2.Text = Convert.ToString(i2);if(i1 == i2){txtresult.Text = ”一樣大“;

}if(i1 > i2){txtresult.Text = txtname1.Text+”大“;

}if(i1 < i2){txtresult.Text = txtname2.Text + ”大";

}}

}

第五篇：需求分析報告

測試（驗收）大綱

目錄

1.引言....................................................................2 1.1 目的...................................................................2 1.2 術語...................................................................2 1.3 參照標準...............................................................2 2.測試日期安排............................................................3 3.測試小組及成員..........................................................3 4.測試具體內容............................................................3 4.1 合法性檢查.............................................................3 4.2 軟件文檔檢查...........................................................3 4.2.1 必須提供檢查的文檔...................................................3 4.2.2 其他可能需要檢查的文檔...............................................4 4.2.3 由業主確定必須檢查的其他文檔.........................................4 4.2.4 文檔質量的度量準則...................................................4 4.3 軟件代碼測試...........................................................4 4.3.1 源代碼一般性檢查.....................................................4 4.3.2 軟件一致性檢查.......................................................5 4.4 軟件系統測試...........................................................5 4.4.1 界面(外觀)測試.......................................................6 4.4.2 可用性測試...........................................................6 4.4.3 功能測試.............................................................6 4.4.4 穩定性(強度)測試.....................................................6 4.4.5 性能測試.............................................................6 4.4.6 強壯性(恢復)測試.....................................................6 4.4.7 邏輯性測試...........................................................6 4.4.8 破壞性測試...........................................................6 4.4.9 安全性測試...........................................................7 5.測試結果交付方式........................................................7

1.引言

1.1 目的

為了盡可能的找出軟件的不足，提高軟件的質量，促進軟件的成功驗收，專門制定了本大綱。其主要目的在于為所要進行的測試工作制定各種必要的準則和規范，以及在有關方面協議的基礎上對測試工作進行合理組織與管理。

1.2 術語

本大綱所提及的術語，其定義遵照GB/T 11457標準。

1.3 參照標準

● GB/T 11457—1995 軟件工程術語

● GB 8566—1995；

信息技術軟件生存期過程 ● OGB8567—1988* 計算機軟件產品開發文件編制指南 ● GB 9385* 計算機軟件需求說明編制指南 ● GB 9386—1988* 計算機軟件測試文件編制指南 ● GB/T 12504—1990 計算機軟件質量保證計劃規范 ● OGB/T 12505—1990 計算機軟件配置管理計劃規范 ● OGB/T 14079—1993 軟件維護指南

● OGB/T 14394—1993 計算機軟件可靠性和可維護性管理 ● GB/T 16680一1996 軟件文檔管理指南 ● 開發者企業規范

軟件開發者有關軟件工程的規范 ● 其它文件

例如：合同書等，法律文件中的有關規定。

說明：（1）應該遵循自頂而下、就嚴不就寬的原則，除非合同書等法律文件中另有規定。

（2）標記（*）號的標準為推薦標準。

2.測試日期安排

開發方如期交付軟件的基礎上，由業主審核確定具體日期安排。

3.測試小組及成員

由業主聘請具有一定的分析、設計、編程和軟件測試經驗的測試組長和其他專業人員組成。測試組設組長一名(可設有副組長)，負責整個測試的計劃、組織工作。

或委托具有國家認可測試資質的第三方進行測試。

4.測試具體內容

測試內容應該包括：合法性檢查、文檔檢查、軟件一致性檢查、軟件系統測試與測試結果評審等幾項工作。

4.1 合法性檢查

檢查開發者在開發本軟件時，使用的開發工具是否合法。對在編程中使用的一些非本單位自己開發的，也不是由開發工具提供的控件、組件、函數庫等，檢查其是否有合法的發布許可。

4.2 軟件文檔檢查

4.2.1 必須提供檢查的文檔

● 項目實施計劃； ● 詳細技術方案；

● 軟件需求規格說明書(STP)(含數據字典)； ● 概要設計說明書(PDD)；

● 詳細設計說明書(DDD)(含數據庫設計說明書)； ● 軟件測試計劃(STP)(含測試用例)； ● 軟件測試報告(STR)；

● 用戶手冊(SUM)(含操作、使用、維護、應急處理手冊)； ● 源程序(SCL)(不可修改的電子文檔)； ● 項目實施計劃(PIP)； ● 項目開發總結(PDS)；

● 軟件質量保證計劃(SQAP)；

4.2.2 其他可能需要檢查的文檔

● 軟件配置計劃(SCMPP)； ● 項目進展報表(PPR)； ● 階段評審報表(PRR)； 4.2.3 由建設方確定必須檢查的其他文檔

說明：如果建設方認為4.1.1節和4.1.2節所列文檔之外，還需要檢查其它文檔，則在此列出文檔名稱；如果業主認為不需要進行額外的文檔檢查，則本部分無內容。4.2.4 文檔質量的度量準則

文檔是軟件的重要組成都分，是軟件生存周期各個不同階段的產品描述。文檔質量的度量準則就是要評審各階段文檔的合適性。主要有以下六條：

● 完備性

開發方必須按照GB 8567(計算機軟件產品開發文件編制指南)的規定編制相應的 文檔，以保證在開發階段結束時其文檔是齊全的。● 正確性

在軟件開發各個階段所編寫的文檔的內容，必須真實的反映階段的工作且與該階 段的需求相一致。● 簡明性

在軟件開發各個階段所編寫的各種文檔的語言表達應該清晰、準確簡練，適合各 種文檔的特定讀者。● 可追蹤性

在軟件開發各個階段所編寫的各種文檔應該具有良好的可追蹤性。文檔的可追蹤 性包括橫向可追蹤性和縱向可追蹤性兩個方面。前者是指在不同的文檔的相關內 容之間相互檢索的難易程序；后者是指確定同一文檔某一內容在本文檔范圍中檢 索的難易程度。● 自說明性

在軟件開發各個階段所編寫的各種文檔應該具有較好的自說明性。文檔的自說明 性是指在軟件開發各個階段中，不同文檔能夠獨立表達，該軟件在其相應階段的 階段成果的能力。● 規范性

在軟件開發各個階段所編寫的各種文檔應該具有良好的規范性。文檔的規范性是 指文檔的封面、大綱、術語的含義以及圖示符號等符合有關規范的規定。

4.3 軟件代碼測試

4.3.1 源代碼一般性檢查

僅對系統關鍵模塊的源代碼進行抽查，檢查模塊代碼編寫的規范性，批注的準確性，是否存在潛在性錯誤，以及代碼的可維護性。

● 命名規范檢查

檢查源代碼中的變量、函數、對象、過程等的命名是否符合約定規范，該規范可 以由開發方在軟件工程文檔規范中單方面約定。

● 注釋檢查

檢查程序中的注釋是否規范，注釋量是否達到約定要求，例如：要求注釋量達到 30％左右。● 接口檢查

檢查數據庫接口等外部接口是否符合要求，各程序模塊使用的接口方式是否一 致，特定的外部接口協議是否符合。● 數據類型檢查

源代碼中涉及的金額的常量、變量及數據集和數據庫中涉及金額的數據類型是否 采用貨幣類型，以防止在特定條件下產生較大的誤差而影響統計結果。● 限制性檢查

對一些程序中使用到的、具有使用限制的命令、事件、方法、過程、函數、對象、控件等進行檢查。檢查在長時間運行時，有無可能接近或者達到限制條件，這里考慮的系統運行時間可能長達數年。

4.3.2 軟件一致性檢查

● 編譯檢查

要求提交的源代碼在其規定的編譯環境中，能夠重新編譯無錯誤，并且能夠完成 相應的功能，從而確定移交的確實是正確的源代碼。● 安裝／卸載檢查

在新系統上用交付的軟件安裝盤重新安裝各個模塊，并且通過運行這些軟件模 塊，能否完成相應的功能，從而確定移交的確實是正確的軟件安裝盤。在安裝后立即卸載所安裝的模塊，并且檢查是否能夠做到徹底卸載。● 運行模塊檢查

將新安裝的軟件模塊與現場運行模塊用軟件工具抽樣比較，確認交付的軟件安裝 盤與現場運行軟件一致。

抽查數處現場運行模塊用軟件工具比較，確認現場運行軟件一致。

4.4 軟件系統測試

軟件系統測試不僅是檢測軟件的整體行為表現，從另一個側面看，也是對軟件開發設計的再確認。

進行軟件系統測試工作時，具體的測試用例是由開發方提供，并由測試方和用戶共同補充制定的。在開發方做完功能演示后，可以進行下列測試：

● 界面(外觀)測試； ● 可用性測試； ● 功能測試；

● 穩定性(強度)測試； ● 性能測試；

● 強壯性(恢復)測試； ● 邏輯性測試； ● 破壞性測試； ● 安全性測試。說明：實際進行的測試內容有測試方法和業主根據具體情況共同確定，并非文中所列測試內容都必須進行測試。

4.4.1 界面(外觀)測試

對照界面規范(在軟件需求規格說明書中規定，或者由軟件工程規范中給出)和界面表(在概要設計中給出)，檢查各界面設計是否規范，包括：界面風格、表現形式、組件用法、字體選擇、字號選擇、色彩搭配、日期表現、計時方法、時間格式、對齊方式等等，是否符合規范、是否協調一致、是否便于操作。4.4.2 可用性測試

測試操作是否方便，用戶界面是否友好等。測試系統是否有影響操作流程的界面Bug和功能Bug，紀錄具體Bug的數量、出現頻率和嚴重程度。4.4.3 功能測試

檢查數據在流程中各個階段的準確性。對系統中每一模塊利用實際數據運行，將其結果與同樣數據環境下應該得出的結果相比較，或與軟件需求規格說明書中要求的結果進行比較，如有偏差，則功能測試不能通過。

檢查軟件需求規格說明書中描述的需求是否都得到滿足；系統是否缺乏軟件需求規格說明書中規定的重要功能；以及系統實際使用中不可缺少而軟件需求規格說明書中沒有規定的功能。

如果存在遺產數據，應該檢查遺產數據轉換是否正確。4.4.4 穩定性(強度)測試

測試系統的能力最高實際限度，即檢查軟件在一些超負荷情況下，功能實現的情況。例如：要求軟件進行某一行為的大量重復、輸入大量的數據或大數值數據、對數據庫進行大量復雜的查詢等。

利用邊界測試(最大值、最小值、N次循環)對系統進行模擬運行測試，觀察其是否處于穩定狀態。4.4.5 性能測試

根據系統設計指標，或者對被測軟件提出的性能指標，測試軟件的運行性能，例如：傳輸連接最長時限、傳輸錯誤率、計算精度、記錄精度、響應時限和恢復時限等。4.4.6 強壯性(恢復)測試

采用人工的干擾使應用軟件、平臺軟件或者系統硬件出錯，中斷正常使用，檢測系統的恢復能力。進行強壯性測試時，應該參考性能測試相關的測試指標。4.4.7 邏輯性測試

根據系統的功能邏輯圖，測試軟件是否按規定的邏輯路徑運行，選擇一些極限數據判斷軟件運行是否存在錯誤或非法路徑，從而發現系統的邏輯錯誤或非法后門。4.4.8 破壞性測試

輸入錯誤的或非法的數據(類型)，檢查系統的報錯糾錯的能力及穩定性。并測試可連續使用多長時間而系統不崩潰。

4.4.9 安全性測試

驗證安裝在系統內的保護機構確實能夠對系統進行保護，使之不受各種非常的干擾，安全測試時需要設計一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密的漏洞。

說明：進行安全測試時，必須遵循相關的安全規定，并且有業主派員參加。

5.測試結果交付方式

測試結束后，由測試組填寫軟件測試報告，并將測試報告與全部測試材料一并交給業主。具體交付方式，由業主和測試方雙方協商確定。測試報告包括下列內容：

● 軟件測試計劃 ● 軟件測試日志 ● 軟件文檔檢查報告 ● 軟件代碼測試報告 ● 軟件系統測試報告 ● 測試總結報告

● 測試人員簽字登記表