第一篇：軟件測試需求分析與定義方法

軟件測試需求分析與定義方法

如何確定測試工作的范圍？

對于一個存在生命周期的軟件產(chǎn)品來說，它的開發(fā)和測試往往都不是一次性的，因?yàn)殡S著新的需求的出現(xiàn)，以及對原有版本的改進(jìn)，新的版本會不斷的發(fā)布（即使對于一些以客戶定制方式運(yùn)作的項(xiàng)目，在開發(fā)過程中以及發(fā)布后的維護(hù)期內(nèi)，也會產(chǎn)生眾多的內(nèi)部版本）。隨著版本的迭代，我們的測試工作也會一直繼續(xù)下去。而在每一次迭代時，可能在整個工作階段的開始就受到一些因素的影響，比如市場需求、既定的發(fā)布時間、并發(fā)的工作導(dǎo)致的資源緊張等等，使我們不得不考慮對軟件質(zhì)量要求的適度，最終使得我們在每個階段的測試工作的要求或者說所涉及到的內(nèi)容有可能是不同的。這種變化，最終將會影響到測試需求的確定。那么到底該如何確定每次迭代是測試工作的范圍呢？在筆者的實(shí)踐中，通常把測試工作范圍的確定，等價的認(rèn)為是軟件需求的確定。

不過現(xiàn)在有一個很實(shí)際的問題是這樣：軟件需求在開發(fā)過程中不斷發(fā)生變化，有時候到了后期還會有新的需求添加進(jìn)來，還有些需求在交付內(nèi)部測試版本之后又發(fā)現(xiàn)原來的需求本身就存在缺陷，之后再次返工，在軟件最終發(fā)布之前，怎么可能確定的下來呢。啊，這些都是讓我們的開發(fā)人員和測試人員極其頭痛的事情。到底應(yīng)該怎樣在頻繁變更的需求中確定哪些部分是我們在某個階段要測試的內(nèi)容呢？或者說通過什么樣的方法可以改善我們上面提到的那些問題呢？一個實(shí)際的做法就是實(shí)現(xiàn)軟件需求的版本化控制。（用軟件需求的版本化控制來解決軟件需求的頻繁變更）既然說到了這里，就不免要說些題外話。筆者一直都認(rèn)為軟件需求是開發(fā)工作和測試工作在制定計(jì)劃、開展工作時所共同參照的源頭和依據(jù)，而我們只有在源頭上控制好，才能保證下面工作的平穩(wěn)開展。如果希望某個階段工作的進(jìn)度和內(nèi)容可以明確的定義下來，就必須要考慮軟件需求的版本化控制。這里所提到的“軟件需求的版本化控制”，是指在一個軟件產(chǎn)品的生命周期中，當(dāng)要進(jìn)行一個新版本的迭代時，要盡早的確定這個版本中將要實(shí)現(xiàn)的需求，并同上個版本做出比較，哪些內(nèi)容是新增的，哪些內(nèi)容是被調(diào)整過的。在該階段工作開始之初的工作會議上，明確的向所有需要了解軟件需求的涉眾傳達(dá)這部分信息。而如果在該版本的開發(fā)過程中不斷的出現(xiàn)需求變更的情況，則應(yīng)該根據(jù)市場策略、已公布的發(fā)布時間、客戶需求、實(shí)現(xiàn)的代價、難易程度以及對現(xiàn)有工作的影響等方面，對需求進(jìn)行適度劃分，嚴(yán)格定義當(dāng)前版本中需要實(shí)現(xiàn)的需求，而其他部分，則作為未來版本的軟件需求進(jìn)行考慮。如果有的朋友認(rèn)為上面的內(nèi)容還是太理論化，需要一個更實(shí)際的、可操作的方法。那么只能說，對于需求的變更，以及因?yàn)樾枨笞兏鸬脑O(shè)計(jì)的變更，必須要早發(fā)現(xiàn)，早討論，早決定，早調(diào)整。這可能更多的要依靠一個團(tuán)隊(duì)中相關(guān)負(fù)責(zé)人員的主動工作來保證，而不是依靠一個明確的方法。注意，這里的一個關(guān)鍵是，對于軟件需求，同樣需要嚴(yán)格按照版本進(jìn)行管理，或者說使用“基線”進(jìn)行管理。如何整理測試需求？一旦當(dāng)前階段測試工作的范圍確定下來，我們就可以開始考慮測試需求的整理——也就是明確的定義現(xiàn)階段要“測什么”。測試需求的確定將為我們制定進(jìn)度時間表、分配資源以及如何確定某個階段測試工作是否完成提供一個可供衡量的標(biāo)準(zhǔn)。當(dāng)然，還有更重要的一點(diǎn)，已被確定的測試需求是我們進(jìn)行測試用例設(shè)計(jì)和考慮測試覆蓋的依據(jù)。整理測試需求的第一步，就是要“測試需求”。測試需求？對，不知道您是否想到，這里的“測試需求”中的“測試”是一個動詞，指的是對軟件需求本身的檢查。

?。窟@不是已經(jīng)超出了測試工作的范圍了嗎？測試人員不是應(yīng)該只關(guān)心軟件的實(shí)現(xiàn)同需求是否相符嗎？這樣對測試人員要求未免太高了?！@是筆者過去同一些朋友談到測試人員必須對需求進(jìn)行檢查時聽到的一些不同的聲音。在這里，首先要明確一個問題，就是軟件測試的工作到底做什么？

在《軟件測試》（Ron Patton〔美〕，中文版由機(jī)械工業(yè)出版社出版，這本書是測試新手入門的經(jīng)典教材）一書的第10頁，有一個明確而簡潔的定義：軟件測試員的目標(biāo)是找到軟件缺陷，盡可能早一些，并確保其得以修復(fù)。

瞧！這里說要“盡可能早”的“找到軟件缺陷”。那這“盡可能早”要早到什么時候呢？

不知道大家對《軟件工程》這本書還有什么印象。至少在筆者看過的多個不同版本的軟件工程方面的書中，對于軟件缺陷都會有一段類似的描述：缺陷發(fā)現(xiàn)的越早，則修復(fù)這個缺陷的代價就越小，在需求、設(shè)計(jì)、編碼、測試、發(fā)布等不同的階段，發(fā)現(xiàn)缺陷后修復(fù)的代價都會比在前一個階段修復(fù)的代價提高10倍（參見下圖）。這樣看來，上面問題的答案自然就變成了“禿子頭上的虱子”：從需求階段開始！從“測試需求”開始！

注意，筆者這里的觀點(diǎn)并不是說可以取消團(tuán)隊(duì)中的“需求評審會議”，這里并不存在沖突。筆者所希望講述的，是測試人員應(yīng)該如何看待軟件需求，而并不是把“需求評審會議”所承擔(dān)的責(zé)任攬到自己身上。?在論壇上也偶爾看到有的朋友問：如何測試需求呢？每次看到這樣的提問，筆者內(nèi)心就禁不住的一陣激動，因?yàn)橐恢币詠?，討論這方面問題的朋友的確少之又少。

在筆者的實(shí)際工作中，對軟件需求的檢查包括兩個方面的內(nèi)容。

一是對軟件需求正確性的檢查，也就是要保證需求文檔中所描述的內(nèi)容是真實(shí)可靠的。在進(jìn)行這部分工作時，不要迷信所謂的“都是用戶提出的真實(shí)的需求”，因?yàn)槲覀儽仨毧紤]，提出這些需求的涉眾，是否真的可以正確的描述自己的需求？我們的需求人員是否真的可以正確的理解用戶的需求？有沒有一些被用戶認(rèn)為在業(yè)務(wù)處理上是理所當(dāng)然、極其平常的事情，而沒有作為需求提出來？有沒有一些被用戶認(rèn)為他們過去使用的軟件已經(jīng)提供了相應(yīng)的功能，所以認(rèn)為我們也應(yīng)當(dāng)提供，而沒有提出來的？關(guān)于這個問題，也曾經(jīng)有朋友提過不同的看法，認(rèn)為這樣對測試人員的要求太高了——既要熟悉需求人員的工作，又要熟悉軟件所涉及的行業(yè)的業(yè)務(wù)。但筆者還是固執(zhí)的認(rèn)為，作為測試人員，還是需要對軟件產(chǎn)品所涉及的行業(yè)的業(yè)務(wù)有一個全面的、深入的了解——當(dāng)然，這不是對一個剛剛?cè)腴T的測試者的要求，但是如果想稱為一個優(yōu)秀的測試者，是難免要付出這部分努力的。

二是要保證軟件需求的可測試性。對于“可測試性”，筆者的概念是：對于一條軟件需求或者一個需要實(shí)現(xiàn)的特性，必須存在一個可以明確預(yù)知的結(jié)果，并且可以通過設(shè)計(jì)一個可以重復(fù)的過程來對這個明確的結(jié)果進(jìn)行驗(yàn)證。說的具體一點(diǎn)，就是要保證所有的需要實(shí)現(xiàn)的需求都是可以用某種方法來明確的判斷是否符合需求文檔中的描述。如果對于某條需求或某個特性，無法通過一個明確的方法來進(jìn)行驗(yàn)證，或者無法預(yù)知它的結(jié)果，那么就意味著這條需求的描述存在缺陷，應(yīng)該請需求人員對需求文檔進(jìn)行修改或補(bǔ)充——我們有理由相信，如果作為測試人員對需求無法產(chǎn)生準(zhǔn)確的理解，那么開發(fā)人員也同樣無法對同一條需求產(chǎn)生準(zhǔn)確的理解。對于一條確定的軟件需求理解的二義性，是在不規(guī)范的開發(fā)過程中導(dǎo)致返工的一個主要原因。如果認(rèn)為有必要，那應(yīng)該在“需求評審會議”上確認(rèn)所有涉眾對需求的理解是一致的。當(dāng)然，對于如何提高軟件需求的質(zhì)量，在網(wǎng)絡(luò)上或者已經(jīng)出版的書刊中都已經(jīng)有了很多更加具體、實(shí)用的方法，如果有興趣，大家也可以找來參考。不過，如果您是一位測試者，那么上面這部分內(nèi)容對您仍然是非常有用的。相信您只要在工作中進(jìn)行嘗試，慢慢的體會，一定會發(fā)現(xiàn)這種方法給您帶來的好處。?現(xiàn)在當(dāng)前的測試工作范圍已經(jīng)確定，相應(yīng)版本的軟件需求也通過了評審，我們就可以在這個已經(jīng)確定的范圍內(nèi)進(jìn)行測試需求的整理。我們手頭上可以參考的東西，通常會有軟件需求規(guī)約（以下簡稱SRS）和用例（以下簡稱UC）——當(dāng)然，也可能是一份包含UC的SRS。通過對SRS和UC的閱讀，我們可以從文檔對特性和業(yè)務(wù)流程的描述中獲得對軟件所涉及的業(yè)務(wù)的一個基本的認(rèn)識。比如用戶在處理實(shí)際業(yè)務(wù)時都要作些什么，多個業(yè)務(wù)之間的先后順序是怎樣的，用戶在處理業(yè)務(wù)是對于哪些地方有特別的要求，等等。這部分規(guī)則，將成為我們的測試需求中最基本的一部分。

至于測試需求的表現(xiàn)形式，筆者認(rèn)為大家都可以根據(jù)自己的需要進(jìn)行設(shè)計(jì)，而沒有必要把思路限制在到底使用表格方式還是使用文本方式，只要把握一個原則就行了：在一條測試需求中，用容易理解的自然語言，明確的描述一項(xiàng)需要測試的內(nèi)容。對于多項(xiàng)測試內(nèi)容，應(yīng)盡可能的剝離開來，保證一條測試需求只包含一項(xiàng)測試內(nèi)容。

另外，大家也可能注意到了，在軟件開發(fā)過程的這個階段，通常是沒有用戶界面（以下簡稱UI）可供參考的——雖然RUP中對于需求階段的工作描述包括了UI設(shè)計(jì)的部分，但很多時候在這個階段還是無法提供一個確定的UI的——也就是說我們這時獲得的測試需求，將是完全基于業(yè)務(wù)的，而并不包括基于UI的那部分規(guī)則，是同軟件的最終具體實(shí)現(xiàn)相獨(dú)立的。

隨著開發(fā)工作的繼續(xù)，開發(fā)部門的架構(gòu)設(shè)計(jì)文檔和詳細(xì)設(shè)計(jì)文檔也將陸續(xù)提交，這時候，我們可以根據(jù)設(shè)計(jì)文檔來對已有的測試需求進(jìn)行增補(bǔ)。注意，這里我們對于設(shè)計(jì)文檔中提到的內(nèi)容要有選擇的采用，只有同SRS或UC中已經(jīng)定義的部分相符的內(nèi)容，才可以用來調(diào)整我們的測試需求。而同軟件需求不相符的部分，則需要同設(shè)計(jì)人員和需求人員一起討論，確定下以哪一方作為基準(zhǔn)，決定是否需要調(diào)整軟件需求，然后對測試需求進(jìn)行相應(yīng)的增補(bǔ)或者調(diào)整。比如對于一些算法，需要考慮設(shè)計(jì)文檔中定義的，同系統(tǒng)實(shí)現(xiàn)相關(guān)的那些計(jì)算公式，是否同軟件需求中描述的算法表達(dá)的是否是同一個意思？而對于一些約束或者業(yè)務(wù)規(guī)則，設(shè)計(jì)文檔中描述的是否同需求中的相應(yīng)部分一致？呵呵，看完上面這部分內(nèi)容，恐怕又有一部分朋友暈倒在地了，而沒有暈倒的那部分朋友也要提出異議：??？！你這不是又包含了對開發(fā)人員所作的設(shè)計(jì)工作的檢查嗎？！剛剛讓我們檢查需求，現(xiàn)在又讓我們檢查設(shè)計(jì)，真的把我們當(dāng)成全才了！沒辦法，為了讓軟件交到我們手上的時候只包含盡量少的缺陷，大家只能再辛苦一下了。我們的工作不應(yīng)當(dāng)僅僅限制在軟件交付后盡力找到存在的缺陷，而更應(yīng)該努力及早發(fā)現(xiàn)軟件缺陷出現(xiàn)的苗頭，盡量預(yù)防缺陷的出現(xiàn)。雖然并不是說在所有的團(tuán)隊(duì)中都應(yīng)該由測試人員承擔(dān)“測試需求”和“測試設(shè)計(jì)”的工作，但是測試人員對這些工作起到的作用，是其他團(tuán)隊(duì)中的其他角色所無法替代的。開發(fā)部門完成編碼實(shí)現(xiàn)工作，提交供內(nèi)部測試的應(yīng)用程序時，測試人員手頭上應(yīng)該已經(jīng)準(zhǔn)備好了絕大部分測試用例和測試數(shù)據(jù)，測試部門將開始執(zhí)行測試。通常在我們執(zhí)行測試的過程中，即使我們已經(jīng)從“通過測試”和“失敗測試”兩個不同的角度準(zhǔn)備了非常充分的測試用例和測試數(shù)據(jù)，但總是有些缺陷的出現(xiàn)是出乎我們意料的，或者說是已有的測試需求和測試用例未能覆蓋的。那么，對于這部分缺陷，也應(yīng)當(dāng)添加到測試需求中，并設(shè)計(jì)相應(yīng)的測試用例，以便于下次版本迭代時進(jìn)行參考。OK，相信說到這里，各位看客也應(yīng)該可以理解我的觀點(diǎn)了：對于一個長期發(fā)展的團(tuán)隊(duì)或者持續(xù)開發(fā)的產(chǎn)品，它的所有東西都是要不斷積累的、不斷迭代的。無論對于軟件需求還是測試需求，不僅僅是在一個版本的開發(fā)過程中，在不同的階段進(jìn)行迭代，在產(chǎn)品的整個生命周期中的不同版本間，也是不斷迭代和積累的。

第二篇：需求分析方法探討

需求分析方法探討[1]

一、概述

據(jù)權(quán)威部門統(tǒng)計(jì)，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。作為軟件的設(shè)計(jì)和開發(fā)人員常抱怨用戶需求不明確，需求常處于變更狀態(tài)。新的需求往往在開發(fā)階段才被用戶提出。造成軟件的完成日期不斷的遲后。

一般的軟件企業(yè)，往往只口頭上注重用戶需求。但由于沒有科學(xué)的管理方法，實(shí)際上他們描述的用戶需求是雜亂無章的，只言片語的。不能有效地和系統(tǒng)設(shè)計(jì)、開發(fā)保持同步最后開發(fā)出來的軟件產(chǎn)品和實(shí)際有很大的差異。導(dǎo)致軟件的失敗。有證據(jù)表明，在需求階段修正錯誤的工作量，是在系統(tǒng)設(shè)計(jì)階段修正錯誤的1/10；是在開發(fā)階段修正錯誤的1/100，是在發(fā)布產(chǎn)品階段修正錯誤的1/1000。當(dāng)然這是對大型系統(tǒng)而言，對于不同的系統(tǒng)，隨系統(tǒng)的復(fù)雜程度這個比率會有所不同。

用戶的需求的增加具有漸進(jìn)的、增量的特點(diǎn)。隨著需求分析人員和用戶逐漸深入的交流，用戶在不斷地整理、規(guī)范自己的需求。需求分析人員須牢記的是用戶不可能一下子給出一個完整、清晰、規(guī)范的用戶需求。需求分析人員需從與用戶的交流中，不斷地挖掘，并加以整理，才能得到想要的需求。

需求分析一般來說需要有一個需求分析的團(tuán)隊(duì)，如用戶代表、系統(tǒng)分析人員、開發(fā)人員、需求管理人員等，他們的分工不同各有側(cè)重點(diǎn)。對于小型或中型項(xiàng)目人員可以兼任。

基于上述原因，需要從理論上規(guī)范用戶需求的收集和整理。本文結(jié)合系統(tǒng)建模，給出了需求分析的一般性方法。它如下的包含了兩個方面:

1、技術(shù)層面

給出需求分析的系統(tǒng)框架，它包含了需求的項(xiàng)目、參與需求分析的用戶、用戶對于需求的可操作權(quán)限（安全性）等。

2、操作層面

給出了需求收集、整理、分析的一般性方法。其中介紹了系統(tǒng)建模和需求分析間的相互關(guān)系，最后介紹了目前幾種流行的需求分析產(chǎn)品及它們的特點(diǎn)。

二、需求分析的基本概念

需求分析的目的是完整、準(zhǔn)確地描述用戶的需求，跟蹤用戶需求的變化，將用戶的需求準(zhǔn)確地反映到系統(tǒng)的分析和設(shè)計(jì)中，并使系統(tǒng)的分析、設(shè)計(jì)和用戶的需求保持一致。

第三篇：軟件測試方法總結(jié)

軟件測試方法總結(jié)

（一）發(fā)布時間: 2008-12-12 17:07作者: lxm_lxm來源: 51Testing論壇

軟件測試方法的總結(jié)，是lxm_lxm根據(jù)個人所做過的項(xiàng)目整理的，提供給新來的的朋友們。軟件測試方法總結(jié)

一、界面

● 界面測試

（1）測試界面設(shè)計(jì)是否合理、簡潔、美觀，操作是否方便

（2）功能鍵、數(shù)據(jù)項(xiàng)信息是否齊全

（3）確認(rèn)系統(tǒng)中同一功能抌名稱是否統(tǒng)一

（4）設(shè)計(jì)樣式、風(fēng)格（查詢條件樣式；輸入風(fēng)格（點(diǎn)選/手輸入）；）是否與系統(tǒng)其它模塊統(tǒng)一

（5）確認(rèn)頁面內(nèi)所有字段名稱顯示風(fēng)格是否統(tǒng)一（居中、左對齊、右對齊，一般采用居中顯示風(fēng)格）

1、新增頁面及功能測試

● 字段

在開始測試時應(yīng)該保證數(shù)據(jù)的正確性，然后再從系統(tǒng)中找出各種Bug

（1）各字段輸入正確的信息值保存，確認(rèn)系統(tǒng)是否可以正確完成新增操作。

（2）進(jìn)入添加界面不輸入任何信息值，單擊“保存”功能按鈕，系統(tǒng)應(yīng)該給出某個不允許為空字段的提示信息（屬于邊界測試）

（3）建議不允許為空的字段前面加上?*?作為標(biāo)記（統(tǒng)一性，方便性問題）

（4）編碼/編號字段不允許輸入中文及特殊字符，否則系統(tǒng)應(yīng)該給出相應(yīng)的提示信息

（5）測試編碼/編號字段不允許重復(fù)，否則系統(tǒng)應(yīng)該給出相應(yīng)的提示信息

（6）確認(rèn)字段是否已做長度限制，如果輸入值超出長度范圍，那么在保存時系統(tǒng)應(yīng)該給出提示信息

（7）非法測試，如：校驗(yàn)數(shù)值型字段輸入非數(shù)值，保存時系統(tǒng)是否給出相應(yīng)的提示信息（根據(jù)實(shí)際需要確定數(shù)值型字段是否能夠接受負(fù)數(shù)）

（8）邊界測試，如：確認(rèn)數(shù)值型字段的邊界值（如：有效值為?0-100?整數(shù)，那么輸入-1或101保存時系統(tǒng)應(yīng)該給出相應(yīng)的提示信息；輸入值為0、100系統(tǒng)應(yīng)該能正確保存信息值；輸入0到100內(nèi)的整數(shù)值系統(tǒng)應(yīng)該正確保存信息值）

（9）精確值測試，測試小數(shù)位數(shù)是否在定義的長度內(nèi)

（10）字段精確值是否正確（四舍五入否）。

（11）根據(jù)實(shí)際情況測試名稱字段是否具有唯一性，（一般情況下名稱是不允許重復(fù)的，具體問題具體分析），否則系統(tǒng)應(yīng)該給出相應(yīng)的提示信息

（12）確認(rèn)各字段名稱書寫是否正確（注意：要求編輯界面、住息列表中、錯誤提示信息、查詢條件中的字段名稱完全相同）

（13）確認(rèn)特殊格式的字段是否已做標(biāo)準(zhǔn)格式的限制（如：電子郵件、郵編等）

（14）測試上級信息字段（如：上級XXX名稱、上級XXX編號）的信息值是否根據(jù)所選擇的上級XXX名稱系統(tǒng)自動生成（注意：編號生成值一定是維護(hù)界面的編號，而不應(yīng)該是相應(yīng)表的那個主鍵編碼）

（15）測試如果某字段信息值是從另一個模塊中選擇輸入的，那么需要確認(rèn)其它相關(guān)聯(lián)字段的信息值是否也相應(yīng)的正確的自動帶入，并且這些字段應(yīng)該都是只讀的（16）創(chuàng)建人/編輯人、發(fā)布人、創(chuàng)建時間、創(chuàng)建人字段應(yīng)該設(shè)為只讀的，而且此類字段值應(yīng)該默認(rèn)當(dāng)前操作人的姓名

（17）如果某個字段可以點(diǎn)選輸入多個信息值，那么測試該字段是否接受，并保存了點(diǎn)選輸入的多個信息值

（18）對于多選字段，測試是否具有記憶上次選擇值并已驗(yàn)重

（19）測試字符型字段是否可以接受空格（統(tǒng)一性問題，建議不要接受空格）

（20）引用其它模塊的字段信息值的字段長度是否與被引用模塊相應(yīng)字段長度一致

軟件測試方法總結(jié)

（二）發(fā)布時間: 2008-12-12 17:13作者: lxm_lxm來源: 51Testing論壇

關(guān)鍵字：軟件測試方法

6、常用功能鍵的功能測試

（1）保存---所有編輯頁面如果未輸入任何信息值而單擊“保存”，系統(tǒng)應(yīng)該給出“XXX字段不允許為空”的提示信息

（2）保存---如果某字段輸入值有錯誤或超出長度范圍，那么單擊“保存”按鈕時，系統(tǒng)應(yīng)該給出相應(yīng)的提示信息

（3）保存---輸入相關(guān)信息單擊“保存”后，建議系統(tǒng)給出“保存成功”提示信息

（4）保存---測試新增/修改信息保存后，信息列表是否自動刷新

（5）下一步---單擊此按鈕，如果有非空字段為空，系統(tǒng)應(yīng)該給出相應(yīng)提示信息；如果有字段輸入非法值，單擊此按鈕系統(tǒng)應(yīng)該給出相應(yīng)提示信息；正常情況下單擊此功能按鈕，系統(tǒng)進(jìn)入到下一個編輯/操作界面

（6）上一步---單擊此功能按鈕，系統(tǒng)應(yīng)該正確返回到上一個編輯/操作界面

（7）瀏覽---測試該功能鍵功能是否已經(jīng)正確實(shí)現(xiàn)，單擊此按鈕系統(tǒng)應(yīng)該彈出文件選擇頁面，并且可以選擇輸入相關(guān)附件

（8）上傳附件---測試上傳功能已經(jīng)正確實(shí)現(xiàn)，確認(rèn)上傳的附件在界面相應(yīng)位置是否顯示

（9）下載---測試下載功能已經(jīng)正確實(shí)現(xiàn)（可以將上傳到服務(wù)器的附件下載的本地相應(yīng)位置）

（10）重新上傳---保存操作后上傳功能按鈕名稱應(yīng)該自動變?yōu)椤爸匦律蟼鳌保⑶铱梢灾匦律蟼鞲郊?/p>

（11）發(fā)布---測試該功能鍵功能已經(jīng)正確實(shí)現(xiàn)，單擊些功能按鈕系統(tǒng)完成發(fā)布操作，相應(yīng)的信息狀態(tài)變?yōu)椤耙寻l(fā)布”，發(fā)布人、發(fā)布時間系統(tǒng)自動生成或已經(jīng)正確保存（注意：已經(jīng)發(fā)布的信息是不允許再進(jìn)行修改操作的）（根據(jù)系統(tǒng)需求及設(shè)計(jì)測試，有些系統(tǒng)只有信息修改頁面才有此功能）

（12）取消發(fā)布---測試該功能鍵功能是否已經(jīng)正確實(shí)現(xiàn)，單擊此功能按鈕系統(tǒng)完成取消發(fā)布功能，相應(yīng)信息狀態(tài)變?yōu)椤拔窗l(fā)布”（根據(jù)系統(tǒng)需求及設(shè)計(jì)測試，有些系統(tǒng)只有信息修改頁面才有此功能）

（13）關(guān)閉---單擊此功能按鈕系統(tǒng)將關(guān)閉當(dāng)前頁面，建議當(dāng)單擊此功能按鈕時系統(tǒng)彈出“確認(rèn)離開此頁面提示信息”

（14）查詢---單擊查詢功能按鈕，系統(tǒng)按鈕輸入查詢條件進(jìn)行模糊查詢；查詢條件輸入非法值進(jìn)行查詢操作，系統(tǒng)應(yīng)該查詢0記錄

（15）刪除----未勾選待刪除記錄單擊此按鈕系統(tǒng)彈出相應(yīng)提示信息；正常情況下系統(tǒng)刪除所選記錄

（16）選擇---勾選待選記錄，單擊此按鈕系統(tǒng)完成選擇操作；單擊選擇超鏈接功能按鈕系統(tǒng)完成選擇操作

（17）取消選擇---單擊此功能按鈕，系統(tǒng)完成取消選擇操作（清除所有選擇信息）

軟件測試方法總結(jié)

（三）發(fā)布時間: 2008-12-12 17:14作者: lxm_lxm來源: 51Testing論壇

關(guān)鍵字：軟件測試方法

11、對用戶名、密碼的有效性測試

（1）密碼信息有效性測試：特殊字符、正常字符、空字符（不輸入）、空格

（2）登陸名是否區(qū)分大小寫

（3）登陸名是否允許重名

（4）用戶名字和密碼都為最大長度（邊界值分析，取上點(diǎn)）

（5）用戶名字和密碼都為最小長度（邊界值分析，取上點(diǎn)）

（6）用戶名字和密碼都是非最大和最小長度的數(shù)據(jù)（邊界值分析，取內(nèi)點(diǎn)）

（7）用戶名長度大于要求1位（邊界值分析，取離點(diǎn)）

（8）用戶名長度小于要求1位（邊界值分析，取離點(diǎn)）

（9）密碼長度大于要求1位（邊界值分析，取離點(diǎn)）

（10）密碼長度小于要求1位（邊界值分析，取離點(diǎn)）

（11）是否記住上次登陸名

（12）密碼信息有效性測試：字母數(shù)字混排、數(shù)字、符號數(shù)字、字母符號、數(shù)字符號、空字符（不輸入）、空格、ASCII字符、字符串在有空格、串在有半角空格

（13）口令鎖定：即輸入口令次數(shù)的限制

（14）密碼顯示是否以星號或者別的符號顯示

（15）看是否支持tap和enter鍵等

（16）密碼是否可以復(fù)制粘貼

密碼修改測試方法

（1）不輸入舊密碼，直接改密碼

（2）輸入錯誤舊密碼

（3）不輸入確認(rèn)新密碼

（4）不輸入新密碼

（5）新密碼和確認(rèn)新密碼不一致

（6）新密碼中有空格

（7）新密碼長度有效性測試方法同上

（8）新密碼為非允許字符（如有的密碼要求必須是英文和數(shù)字組成，那么要試漢字和符號等）

（9）測試密碼是否區(qū)分大小寫，新密碼中英文小寫，確認(rèn)密碼中英文大寫

（10）新密碼與舊密碼一樣能否修改成功

軟件測試方法總結(jié)

（四）發(fā)布時間: 2008-12-12 17:17作者: lxm_lxm來源: 51Testing論壇

關(guān)鍵字：軟件測試方法

四、權(quán)限測試

1、業(yè)務(wù)權(quán)限

按需求測試用戶業(yè)務(wù)權(quán)限分配是否正確，業(yè)務(wù)權(quán)限主要控制功能模塊、功能菜單的展示，沒有相應(yīng)業(yè)務(wù)權(quán)限的不展示其功能模塊能功能菜單。

2、操作權(quán)限

（1）權(quán)限組：按組用戶來分配操作權(quán)限。（組內(nèi)所有人員都具有所分配的操作權(quán)限）

（2）測試已分配操作權(quán)限的功能按鈕是可見的（3）測試已分配操作權(quán)限的功能按鈕是否可用；是否可以正確完成相應(yīng)功能操作

（4）通常不分配調(diào)看操作權(quán)限是無法進(jìn)行修改操作

五、算法

1、測試前需要充分了解算法的整個計(jì)算過程及結(jié)果值的精度

2、算法測試之前需要準(zhǔn)備充足，而且是準(zhǔn)確無誤的測試實(shí)例

3、根據(jù)輸入值確認(rèn)系統(tǒng)計(jì)算輸出結(jié)果是否與預(yù)期結(jié)果完全一致

4、如果計(jì)算公式中含有引用其它模塊的數(shù)據(jù)，需要先確認(rèn)數(shù)據(jù)提取是否對應(yīng)的正確

5、先用等價劃分法、邊界值測試方法測試輸入數(shù)據(jù)是否在需求范圍內(nèi)

6、嚴(yán)格按照測試用例執(zhí)行測試，確認(rèn)計(jì)算結(jié)果是否正確無誤，注意結(jié)果的精度。

第四篇：軟件需求-案例分析

1、問題描述

許多醫(yī)院存在高峰期掛號排隊(duì)時間長，就診等待時間長，倒號現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個網(wǎng)上預(yù)約掛號系統(tǒng)，通過推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對系統(tǒng)進(jìn)行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、該系統(tǒng)所涉及的用戶

本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類。而且該三類用戶各自的特征和所要面對的情景也是截然不同的。

對于患者來說，他們在年齡、計(jì)算機(jī)使用能力等方面存在較大差異，但面對的情景都一樣，就是要預(yù)約掛號，掛號成功過后就診。

對于醫(yī)生來說，普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識，有一定的計(jì)算機(jī)使用能力。所面對的情景有查看掛號信息，確定要就診的病人。

對于管理員來說，他們負(fù)責(zé)對出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。

不同的用戶，對系統(tǒng)的要求也不相同?；颊呦Ｍㄟ^完成注冊和登錄后能夠進(jìn)行掛號預(yù)約，查詢醫(yī)生的出診信息和個人預(yù)約信息，并且能夠在規(guī)定的時間內(nèi)完成掛號預(yù)約或者取消已有的預(yù)約；醫(yī)生則希望能夠在登錄系統(tǒng)后可以查看病人的預(yù)約情況；而管理員希望可以修改出診信息和調(diào)整預(yù)約掛號。這些都是功能性的需求。

同時對于所有用戶都希望該系統(tǒng)是易用的，而且能夠?qū)ψ约旱男畔⑵鸬奖Ｗo(hù)即系統(tǒng)安全性的要求，還有比如說系統(tǒng)的性能比較高效，能夠及時處理自己的預(yù)約申請。當(dāng)然開發(fā)系統(tǒng)的成本如果也能較低就更好了。這些都是非功能需求。

2.2、情景描述的主要成分

? 目標(biāo)和關(guān)鍵成功因素

預(yù)約掛號情景的目標(biāo)是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查詢出診信息。關(guān)鍵成功因素，要保證系統(tǒng)能夠24小時正常穩(wěn)定的運(yùn)行，系統(tǒng)里的信息要是實(shí)時變化的，即可以預(yù)約的醫(yī)生要和實(shí)際在值班的醫(yī)生要匹配，不能出現(xiàn)掛上號了卻沒有醫(yī)生就診的情況。

? 物理上下文和邏輯上下文 物理上下文：醫(yī)院用于掛號的計(jì)算機(jī)可以正常的使用，情景中的可以被預(yù)約的醫(yī)生應(yīng)該是在醫(yī)院值班的；而對于患者可以選擇在醫(yī)院進(jìn)行預(yù)約，也可選擇在家中進(jìn)行預(yù)約，只要在預(yù)約時間內(nèi)能到達(dá)醫(yī)院就可。邏輯上下文：事件發(fā)生的條件是患者在系統(tǒng)中進(jìn)行了預(yù)約，然后管理員會根據(jù)現(xiàn)有的資源（可以預(yù)約的醫(yī)生）對預(yù)約進(jìn)行處理，如果同意，下一步就是醫(yī)生就診；如果沒有可以預(yù)約的醫(yī)生或合適的時間，患者的預(yù)約就不成功，患者需要重新選擇醫(yī)生或時間進(jìn)行預(yù)約。

? 組成情景的主要事件和活動 主要事件：患者預(yù)約掛號，管理員對預(yù)約掛號的處理，醫(yī)生就診。主要活動：患者注冊、登錄系統(tǒng)，患者在系統(tǒng)中查詢可以預(yù)約的醫(yī)生和時間，患者取消已有預(yù)約，患者進(jìn)行就診；管理員接受或拒絕預(yù)約，管理員分配醫(yī)生；醫(yī)生查詢預(yù)約信息。

? 涉及的執(zhí)行者和其他參與者

執(zhí)行者：醫(yī)院的醫(yī)生，預(yù)約掛號系統(tǒng)的管理員。其他參與者：醫(yī)院的相關(guān)人員，比如患者，前臺咨詢員等。

? 要使用的信息和資源 要使用的信息和資源包括，可以預(yù)約的醫(yī)生數(shù)量，所在科室等，醫(yī)院中的設(shè)備，病房等。? 要考慮的約束條件和要使用的規(guī)則 約束條件：同一醫(yī)生同一時間段內(nèi)只能接受一名患者的預(yù)約，根據(jù)醫(yī)療設(shè)備的屬性決定是否要排他性的使用。

3、情景需求分析的步驟

需求規(guī)格說明輸入過程需求目標(biāo)列表1.目標(biāo)分析系統(tǒng)模型目標(biāo),目的使用情景用戶問題實(shí)例2.輸入事件分析初始系統(tǒng)模型用戶,環(huán)境事件情景腳本4.輸出需求分析3.刻畫系統(tǒng)輸出情景結(jié)構(gòu)模型系統(tǒng)輸出類型信息需求5.社會影響分析Agent目標(biāo)6.涉眾分析需求規(guī)格說明

3.1 目標(biāo)分析

在第2部分情景描述的主要成分中已經(jīng)對目標(biāo)進(jìn)行了分析，即：預(yù)約掛號情景的目標(biāo)是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標(biāo)包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預(yù)約記錄，患者能夠取消已有預(yù)約，患者能夠查詢出診信息。3.2 輸入事件分析

對于該系統(tǒng)的輸入事件可能會包括如下情況：初始使用該系統(tǒng)的用戶需要先注冊，而對于已經(jīng)注冊的用戶在使用系統(tǒng)預(yù)約掛號時首先要登錄系統(tǒng)。這是最基本的兩個輸入事件。3.3 刻畫系統(tǒng)輸出

對于系統(tǒng)輸出我們要考慮系統(tǒng)輸出的形式，比如消息顯示，對話框等形式。不如用戶在登錄系統(tǒng)是輸入的用戶名和密碼不匹配的時候要給出對應(yīng)的提示信息，比如用戶名未注冊或密碼不對等。在提交預(yù)約掛號申請后系統(tǒng)也應(yīng)給出預(yù)約成功與否的提示。3.4輸出需求分析

對于輸出需求要根據(jù)用戶的輸入給出對應(yīng)的輸出。比如用戶輸入查詢請求，那么系統(tǒng)應(yīng)該能夠給出詳細(xì)的信息。系統(tǒng)只給出對應(yīng)的輸出還不夠，同時要考慮輸出的信息是否合適。比如用戶要查詢眼科醫(yī)生的資料，系統(tǒng)的輸出就應(yīng)該只是眼科醫(yī)生的信息，而沒有必要把所有醫(yī)生的信息都輸出。3.5 社會影響分析

在進(jìn)行社會影響分析時要同時考慮到積極和消極兩個方面的問題。系統(tǒng)是否可以提高效率，減少人員的工作量。同時也要考慮過多的自動化是否會削弱人對整個系統(tǒng)的意識，導(dǎo)致人對意外處理的能力降低，比如系統(tǒng)臨時出現(xiàn)問題，是否有一套應(yīng)急措施使醫(yī)院日常工作能夠正常的進(jìn)行。

4、需求說明文檔

基于之前構(gòu)建的模型，并參照IEEE 830-1998標(biāo)準(zhǔn)模板，撰寫的系統(tǒng)需求說明文檔如下。

4.1 引言

引言部分將對本文檔的編寫目的、系統(tǒng)的開發(fā)目的、名詞定義以及參考資料進(jìn)行說明，并對文檔的后續(xù)內(nèi)容進(jìn)行概述。4.1.1 編寫目的

網(wǎng)上預(yù)約掛號系統(tǒng)是基于Web開發(fā)技術(shù)完成的網(wǎng)站。為了更好的設(shè)計(jì)并實(shí)現(xiàn)這一系統(tǒng)，對系統(tǒng)進(jìn)行需求建模和分析是十分必要的。因此，基于之前構(gòu)建的各類模型，撰寫系統(tǒng)的需求說明文檔，并將其作為后續(xù)項(xiàng)目設(shè)計(jì)、項(xiàng)目開發(fā)和項(xiàng)目測試的指導(dǎo)。

本文檔連同之前構(gòu)建的模型，可用來與客戶進(jìn)一步明確需求，同時可供項(xiàng)目經(jīng)理、設(shè)計(jì)人員、開發(fā)人員參考。4.1.2 系統(tǒng)目的

許多醫(yī)院存在高峰期掛號排隊(duì)時間長，就診等待時間長，倒號現(xiàn)象頻發(fā)的問題。因此，構(gòu)建一個網(wǎng)上預(yù)約掛號系統(tǒng)，通過推薦患者使用該系統(tǒng)進(jìn)行出診信息查詢和醫(yī)生預(yù)約，可以緩解就診壓力、節(jié)約患者的時間，并且可以在一定程度上保證預(yù)約者和就診者一致，有利于提高醫(yī)院的服務(wù)質(zhì)量。4.1.3 名詞定義 ? 患者預(yù)約系統(tǒng)

網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于為患者提供預(yù)約掛號、信息查詢等功能。? 醫(yī)生工作查詢系統(tǒng)

網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于為醫(yī)生提供各時段預(yù)約患者的信息。? 醫(yī)務(wù)管理系統(tǒng)

網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于為管理員提供出診信息修改、預(yù)約掛號調(diào)整等功能。? 賬號控制系統(tǒng)

網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于用戶賬號的注冊及登錄控制。? 安全保障系統(tǒng)

網(wǎng)上預(yù)約掛號系統(tǒng)的子系統(tǒng)，主要用于保障系統(tǒng)的程序、網(wǎng)絡(luò)及數(shù)據(jù)庫安全。4.1.4 參考資料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吳雙兵,劉偉.網(wǎng)上預(yù)約掛號系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].醫(yī)學(xué)信息學(xué)雜志, 2015, 36(1):36-39.4.1.5 文檔概述

需求說明文檔主要分為三個部分。本節(jié)屬于引言部分，主要用于對文檔本身進(jìn)行定義和描述。文檔的第二部分為系統(tǒng)的整體描述，包括系統(tǒng)的預(yù)期目標(biāo)、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對系統(tǒng)需求的明確定義。

4.2 整體描述

本節(jié)將對系統(tǒng)預(yù)期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進(jìn)行說明。

4.2.1 系統(tǒng)預(yù)期

為了方便用戶在不需安裝任何軟件的情況下使用系統(tǒng)，本系統(tǒng)整體采用B/S結(jié)構(gòu)，用戶可以通過瀏覽器對其進(jìn)行訪問。4.2.2 用戶需求

參照之前完成的目標(biāo)模型，對用戶的需求進(jìn)行整理和定義。由于系統(tǒng)整體較為復(fù)雜，因此本小節(jié)只包含已構(gòu)建目標(biāo)模型的功能性需求和非功能性需求。? 功能性需求

1.患者進(jìn)行預(yù)約選擇

為了實(shí)現(xiàn)患者進(jìn)行預(yù)約選擇的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕：

系統(tǒng)的預(yù)約頁面可以顯示未來1至3天的出診醫(yī)生及其所有可被預(yù)約的出診時段。其中，尚未被預(yù)約的時段擁有預(yù)約按鈕；已被預(yù)約的時段無法被其他患者預(yù)約，因此無預(yù)約按鈕。（2）系統(tǒng)接收到預(yù)約請求：

當(dāng)患者點(diǎn)擊預(yù)約按鈕，系統(tǒng)可以接收到預(yù)約請求。（3）患者被告知預(yù)約選擇結(jié)果：

系統(tǒng)可以對患者是否預(yù)約成功進(jìn)行判定，如果成功則跳轉(zhuǎn)至信息確認(rèn)頁面，否則彈出對話框給予患者相應(yīng)提示。2.患者確認(rèn)預(yù)約信息

為了實(shí)現(xiàn)患者確認(rèn)預(yù)約信息的目標(biāo)，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)擁有預(yù)約信息確認(rèn)頁面以及預(yù)約提交按鈕：

系統(tǒng)的預(yù)約信息確認(rèn)頁面會顯示預(yù)約的醫(yī)生和時段，患者的個人信息，以及預(yù)約提交按鈕，患者可以在提交預(yù)約前核對這些信息。（2）系統(tǒng)接收到預(yù)約提交請求：

當(dāng)患者點(diǎn)擊提交按鈕，系統(tǒng)可以接收到預(yù)約提交請求。（3）患者被告知預(yù)約提交結(jié)果：

系統(tǒng)可以對預(yù)約是否提交成功進(jìn)行判定，并彈出對話框給予患者相應(yīng)提示。? 非功能性需求 1.安全的系統(tǒng)

為了保證預(yù)約掛號系統(tǒng)的安全性，系統(tǒng)應(yīng)完成的需求如下。（1）用戶程序安全：

系統(tǒng)應(yīng)明確區(qū)分不同類別用戶的權(quán)限。并且在用戶登錄時，輸入的密碼不可見、不可復(fù)制。（2）系統(tǒng)網(wǎng)絡(luò)安全：

系統(tǒng)應(yīng)采取安全的網(wǎng)絡(luò)傳輸協(xié)議，網(wǎng)絡(luò)數(shù)據(jù)在被傳輸前應(yīng)進(jìn)行加密。（3）數(shù)據(jù)庫安全：

數(shù)據(jù)庫中存儲的數(shù)據(jù)應(yīng)具備完整性，且密碼應(yīng)在加密后被存儲到數(shù)據(jù)庫中。此外，數(shù)據(jù)庫中的數(shù)據(jù)應(yīng)該可以被備份和恢復(fù)。2.低成本的系統(tǒng) 為了保證預(yù)約掛號系統(tǒng)的低成本，系統(tǒng)應(yīng)完成的需求如下。（1）系統(tǒng)開發(fā)成本低：

開發(fā)團(tuán)隊(duì)?wèi)?yīng)具備合理的項(xiàng)目管理，且在開發(fā)前應(yīng)盡可能明確系統(tǒng)的需求。（2）系統(tǒng)運(yùn)營成本低：

系統(tǒng)在運(yùn)行過程中，應(yīng)該盡可能少的占用資源。（3）系統(tǒng)維護(hù)成本低：

系統(tǒng)應(yīng)該健壯可靠，出現(xiàn)問題后應(yīng)該易于修復(fù)，且系統(tǒng)的功能應(yīng)該易于擴(kuò)展。考慮到系統(tǒng)健壯可靠與系統(tǒng)開發(fā)成本低存在一定的沖突，因此需要進(jìn)行一定的權(quán)衡。4.2.3 用戶特征

本系統(tǒng)的用戶包含患者、醫(yī)生以及管理員三類，其特征如下。? 患者

個體間在年齡、計(jì)算機(jī)使用能力等方面存在較大差異。? 醫(yī)生

普遍具備較高的學(xué)歷，在醫(yī)療方面具備專業(yè)知識，有一定的計(jì)算機(jī)使用能力。? 管理員

負(fù)責(zé)對出診信息進(jìn)行管理，是醫(yī)院工作的安排者，具備較強(qiáng)的計(jì)算機(jī)使用能力。4.2.4 條件與限制

為了保證系統(tǒng)的可移植性和可擴(kuò)展性，本系統(tǒng)應(yīng)使用Java語言進(jìn)行開發(fā)。4.2.5 假定與依賴

本系統(tǒng)假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統(tǒng)的引導(dǎo)和提示下正常使用系統(tǒng)。4.2.6 需求分配

由于文檔中并未列出系統(tǒng)的全部需求，因此無法對所有需求進(jìn)行優(yōu)先級排序。但已經(jīng)列出的均為系統(tǒng)較為核心的功能性需求和非功能性需求，應(yīng)具有高優(yōu)先級。

4.3 需求說明

需求說明部分將參照之前完成的模型，對系統(tǒng)結(jié)構(gòu)、對象模型以及操作過程模型進(jìn)行詳細(xì)描述。

4.3.1 系統(tǒng)結(jié)構(gòu)

本部分將主要參照圖 3-1所示的責(zé)任模型，根據(jù)主體對需求進(jìn)行劃分。考慮到系統(tǒng)較為復(fù)雜，因此只列出主體“患者預(yù)約系統(tǒng)”的相關(guān)需求。? 患者預(yù)約系統(tǒng)

系統(tǒng)擁有患者預(yù)約頁面以及預(yù)約按鈕。

系統(tǒng)接收到預(yù)約請求。

患者被告知預(yù)約選擇結(jié)果。

系統(tǒng)擁有預(yù)約信息確認(rèn)頁面及預(yù)約提交按鈕。

系統(tǒng)接收到預(yù)約提交請求。

患者被告知預(yù)約提交的結(jié)果。4.3.2 對象模型

本部分將主要對圖 4-1所示的對象模型的結(jié)構(gòu)進(jìn)行解釋。

網(wǎng)上預(yù)約掛號系統(tǒng)可以被詳細(xì)劃分為患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)、賬號控制系統(tǒng)、安全保障系統(tǒng)等五個子系統(tǒng)。患者預(yù)約系統(tǒng)、醫(yī)生工作查詢系統(tǒng)、醫(yī)務(wù)管理系統(tǒng)的使用者分別為患者、醫(yī)生和管理員，這些用戶通過系統(tǒng)提供的頁面與系統(tǒng)進(jìn)行交互。

對象模型中所涉及的名詞在4.1.3小節(jié)中有具體解釋。4.3.3 操作過程模型

本部分將主要對圖 5-1，圖 5-3和圖 5-4所示的操作過程模型進(jìn)行說明，并以表格的形式列出各操作過程的參與主體及對應(yīng)需求。? 患者進(jìn)行預(yù)約選擇

患者點(diǎn)擊預(yù)約按鈕后，患者預(yù)約系統(tǒng)會收到患者的預(yù)約請求，并觸發(fā)預(yù)約驗(yàn)證操作，得到預(yù)約驗(yàn)證結(jié)果。接下來，患者預(yù)約系統(tǒng)會以得出的預(yù)約結(jié)果為基礎(chǔ)，進(jìn)行預(yù)約結(jié)果判定，進(jìn)而執(zhí)行頁面跳轉(zhuǎn)或消息框彈出操作。? 患者確認(rèn)預(yù)約信息

患者點(diǎn)擊提交按鈕后，患者預(yù)約系統(tǒng)會收到患者的預(yù)約提交請求，并觸發(fā)預(yù)約提交操作。接下來，患者預(yù)約系統(tǒng)會根據(jù)提交結(jié)果彈出包含相應(yīng)信息的提示框。

以上部分涉及到的操作過程及與之對應(yīng)的主體、需求如下表所示。

以上部分涉及到的操作過程及與之對應(yīng)的主體、需求如表 4-1所示。

操作 預(yù)約驗(yàn)證 參與主體

對應(yīng)需求

患者預(yù)約系統(tǒng) 系統(tǒng)接收到預(yù)約請求，患者被告知預(yù)約選擇結(jié)果

預(yù)約結(jié)果判定 患者預(yù)約系統(tǒng) 患者被告知預(yù)約選擇結(jié)果 預(yù)約提交 患者預(yù)約系統(tǒng) 系統(tǒng)接收到預(yù)約提交請求，患者被告知預(yù)約提交結(jié)果

第五篇：軟件需求分析報告

軟件需求分析

軟件需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設(shè)計(jì)的限制和軟件同其它系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其它有效性需求。進(jìn)行需求分析時，應(yīng)注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想象，并盡量將分析進(jìn)度提交給用戶。在不進(jìn)行直接指導(dǎo)的前提下，讓用戶進(jìn)行檢查與評價。從而達(dá)到需求分析的準(zhǔn)確性。分析員通過需求分析，逐步細(xì)化對軟件的要求，描述軟件要處理的數(shù)據(jù)域，并給軟件開發(fā)提供一種可轉(zhuǎn)化為數(shù)據(jù)設(shè)計(jì)、結(jié)構(gòu)設(shè)計(jì)和過程設(shè)計(jì)的數(shù)據(jù)和功能表示。在軟件完成后，制定的軟件規(guī)格說明還要為評價軟件質(zhì)量提供依據(jù)。

需求分析的任務(wù)

開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，并且以后再對它進(jìn)行修改也極為困難。目前，國內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個系統(tǒng)并立運(yùn)行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。對于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對于我們開發(fā)人員來說，并沒有編寫出客戶認(rèn)可的需求文檔，我們?nèi)绾沃理?xiàng)目于何時結(jié)束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當(dāng)然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價，這些血的教訓(xùn)正在國內(nèi)的軟件開發(fā)者身上發(fā)生。近來，我遇到一個開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計(jì)算機(jī)輔助軟件。不幸的是，當(dāng)他們開發(fā)完這個工具后，發(fā)現(xiàn)這個工具不能打印出源代碼文件，使用者當(dāng)然希望有這個功能。結(jié)果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構(gòu)思準(zhǔn)確，如果我們沒有編寫文檔，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了。相反的情況，我曾見一個要集成到“錯誤跟蹤系統(tǒng)”中的簡單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時發(fā)現(xiàn)簡單的一張需求清單竟是如此有用。他們依據(jù)需求對系統(tǒng)進(jìn)行測試時，此系統(tǒng)不僅非常清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯誤。事實(shí)上，需求文檔在開發(fā)過程中一直起指導(dǎo)作用。需求的類型

下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義。軟件需求包括三個不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。1．業(yè)務(wù)需求（business requirement）反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在項(xiàng)目視圖與范圍文檔中予以說明。2．用戶需求(user requirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例（usecase）文檔或方案腳本說明中予以說明。3．功能需求(functional requirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。在軟件需求規(guī)格說明書（SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用。對一個大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個子集，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）。作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點(diǎn)進(jìn)行描述，從而反

映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。下面以一個字處理程序?yàn)槔齺碚f明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產(chǎn)品的包裝盒封面上可能會標(biāo)明這是個滿足業(yè)務(wù)需求的拼寫檢查器。而對應(yīng)的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項(xiàng)列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實(shí)現(xiàn)整個文檔范圍的替換。從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計(jì)細(xì)節(jié)、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說明你究竟想開發(fā)什么。項(xiàng)目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。