測試分類
β測試,英文是Betatesting。又稱Beta測試,用戶驗收測試(UAT)。
β測試是軟件的多個用戶在一個或多個用戶的實際使用環境下進行的測試。開發者通常不在測試現場,Beta測試不能由程序員或測試員完成。
當開發和測試要完成所做的測試,而最終的錯誤和問題需要在最終發行前找到。這種測試一般由最終用戶或其他人員完成,不能由程序員或測試員完成。
α測試_Alpha測試
α測試,英文是Alphatesting。又稱Alpha測試.
Alpha測試是由一個用戶在開發環境下進行的測試,也可以是公司内部的用戶在模拟實際操作環境下進行的受控測試,Alpha測試不能由該系統的程序員或測試員完成。
在系統開發接近完成時對應用系統的測試;測試後,仍然會有少量的設計變更。這種測試一般由最終用戶或其他人員來完成,不能由程序員或測試員完成。
可移植性
可移植性測試,英文是Portabilitytesting。又稱兼容性測試。
可移植性測試是指測試軟件是否可以被成功移植到指定的硬件或軟件平台上。
UI測試
用戶界面測試,英文是Userinterfacetesting。又稱UI測試。
用戶界面,英文是Userinterface。是指軟件中的可見外觀及其底層與用戶交互的部分(菜單、對話框、窗口和其它控件)。
用戶界面測試是指測試用戶界面的風格是否滿足客戶要求,文字是否正确,頁面是否美觀,文字,圖片組合是否完美,操作是否友好等等。UI測試的目标是确保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或浏覽功能。确保用戶界面符合公司或行業的标準。包括用戶友好性、人性化、易操作性測試。
用戶界面測試用戶分析軟件用戶界面的設計是否合乎用戶期望或要求。它常常包括菜單,對話框及對話框上所有按鈕,文字,出錯提示,幫助信息(Menu和Helpcontent)等方面的測試。比如,測試MicrosoftExcel中插入符号功能所用的對話框的大小,所有按鈕是否對齊,字符串字體大小,出錯信息内容和字體大小,工具欄位置/圖标等等。
冒煙測試
冒煙測試,英文是Smoketesting。
冒煙測試的名稱可以理解為該種測試耗時短,僅用一袋煙功夫足夠了。也有人認為是形象地類比新電路闆基本功能檢查。任何新電路闆焊好後,先通電檢查,如果存在設計缺陷,電路闆可能會短路,闆子冒煙了。
冒煙測試的對象是新編譯的每一個需要正式測試的軟件版本,目的是确認軟件基本功能正常,可以進行後續的正式測試工作。冒煙測試的執行者是版本編譯人員。
随機測試
随機測試,英文是Adhoctesting。
随機測試沒有書面測試用例、記錄期望結果、檢查列表、腳本或指令的測試。主要是根據測試者的經驗對軟件進行功能和性能抽查。随機測試是根據測試說明書執行用例測試的重要補充手段,是保證測試複蓋完整性的有效方式和過程。
随機測試主要是對被測軟件的一些重要功能進行複測,也包括測試那些當前的測試樣例(TestCase)沒有複蓋到的部分。另外,對于軟件更新和新增加的功能要重點測試。重點對一些特殊點情況點、特殊的使用環境、并發性、進行檢查。尤其對以前測試發現的重大Bug,進行再次測試,可以結合回歸測試(Regressivetesting)一起進行。
本地化測試
本地化測試,英文是Localizationtesting。
本地化就是将軟件版本語言進行更改,比如将英文的windows改成中文的windows就是本地化。本地化測試的對象是軟件的本地化版本。本地化測試的目的是測試特定目标區域設置的軟件本地化質量。
本地化測試的環境是在本地化的操作系統上安裝本地化的軟件。從測試方法上可以分為基本功能測試,安裝/卸載測試,當地區域的軟硬件兼容性測試。測試的内容主要包括軟件本地化後的界面布局和軟件翻譯的語言質量,包含軟件、文檔和聯機幫助等部分。
基礎化
本地化能力測試,英文是Localizabilitytesting。
本地化能力測試是指不需要重新設計或修改代碼,将程序的用戶界面翻譯成任何目标語言的能力。為了降低本地化能力測試的成本,提高測試效率,本地化能力測試通常在軟件的僞本地化版本上進行。
本地化能力測試中發現的典型錯誤包括:字符的硬編碼(即軟件中需要本地化的字符寫在了代碼内部),對需要本地化的字符長度設置了固定值,在軟件運行時以控件位置定位,圖标和位圖中包含了需要本地化的文本,軟件的用戶界面與文檔術語不一緻等。
國際化
國際化測試,英文是Internationaltesting。又稱國際化支持測試。
國際化測試的目的是測試軟件的國際化支持能力,發現軟件的國際化的潛在問題,保證軟件在世界不同區域都能正常運行。國際化測試使用每種可能的國際輸入類型,針對任何區域性或區域設置檢查産品的功能是否正常,軟件國際化測試的重點在于執行國際字符串的輸入/輸出功能。國際化測試數據必須包含東亞語言、德語、複雜腳本字符和英語(可選)的混合字符。
國際化支持測試是指驗證軟件程序在不同國家或區域的平台上也能夠如預期的那樣運行,而且還可以按照原設計尊重和支持使用當地常用的日期,字體,文字表示,特殊格式等等。
比如,用英文版的WindowsXP和MicrosoftWord能否展示阿拉伯字符串?用阿拉伯版的WindowsXP和阿拉伯版的MicrosoftWord能否展示阿拉伯字符串?又比如,日文版的MicrosoftExcel對話框是否顯示正确翻譯的日語?一旦來說執行國際化支持測試的測試人員往往需要基本上了解這些國家或地區的語言要求和期望行為是什麼。
安裝測試
安裝測試,英文是Installingtesting。
安裝測試是确保軟件在正常情況和異常情況下,例如,進行首次安裝、升級、完整的或自定義的安裝都能進行安裝的測試。異常情況包括磁盤空間不足、缺少目錄創建權限等場景。核實軟件在安裝後可立即正常運行。安裝測試包括測試安裝代碼以及安裝手冊。安裝手冊提供如何進行安裝,安裝代碼提供安裝一些程序能夠運行的基礎數據。
白盒測試
白盒測試,英文是WhiteBoxTesting。又稱結構測試或者邏輯驅動測試。
白盒測試是把測試對象看作一個打開的盒子。利用白盒測試法進行動态測試時,需要測試軟件産品的内部結構和處理過程,不需測試軟件産品的功能。
白盒測試法的複蓋标準有邏輯複蓋、循環複蓋和基本路徑測試。其中邏輯複蓋包括語句複蓋、判定複蓋、條件複蓋、判定/條件複蓋、條件組合複蓋和路徑複蓋。
白盒測試是知道産品内部工作過程,可通過測試來檢測産品内部動作是否按照規格說明書的規定正常進行,按照程序内部的結構測試程序,檢驗程序中的每條通路是否都有能按預定要求正确工作,而不顧它的功能,白盒測試的主要方法有邏輯驅動、基路測試等,主要用于軟件驗證。
白盒測試常用工具有:Jtest、VcSmith、Jcontract、C++Test、CodeWizard、logiscope。
黑盒測試
黑盒測試顧名思義就是将被測系統看成一個黑盒,從外界取得輸入,然後再輸出。黑盒測試又被稱為功能測試、數據驅動測試或基于規格說明的測試,實際上是站在最終用戶的立場上,檢驗輸入輸出信息及系統性能指标是否符合規格說明書中有關功能需求及性能需求的規定。n黑盒測試的優點有:n1)比較簡單,不需要了解程序内部的代碼及實現;nn2)與軟件的内部實現無關;nn3)從用戶角度出發,能很容易的知道用戶會用到哪些功能,會遇到哪些問題;nn4)基于軟件開發文檔,所以也能知道軟件實現了文檔中的哪些功能;nn5)在做軟件自動化測試時較為方便。nn黑盒測試的缺點有:n1)不可能覆蓋所有的代碼,覆蓋率較低,大概隻能達到總代碼量的30%;nn2)自動化測試的複用性較低。
自動化
自動化測試,英文是AutomatedTesting。
使用自動化測試工具來進行測試,這類測試一般不需要人幹預,通常在GUI、性能等測試和功能測試中用得較多。通過錄制測試腳本,然後執行這個測試腳本來實現測試過程的自動化。國内領先的自動化測試服務提供商是澤衆軟件。自動化測試工具有QTP、Testcomplete、AutoRunner和TAR等。
回歸測試
回歸測試,英文是Regressiontesting。
回歸測試是指在發生修改之後重新測試先前的測試以保證修改的正确性。理論上,軟件産生新版本,都需要進行回歸測試,驗證以前發現和修複的錯誤是否在新軟件版本上再次出現。
根據修複好了的缺陷再重新進行測試。回歸測試的目的在于驗證以前出現過但已經修複好的缺陷不再重新出現。一般指對某已知修正的缺陷再次圍繞它原來出現時的步驟重新測試。
通常确定所需的再測試的範圍時是比較困難的,特别當臨近産品發布日期時。因為為了修正某缺陷時必需更改源代碼,因而就有可能影響這部分源代碼所控制的功能。所以在驗證修好的缺陷時不僅要服從缺陷原來出現時的步驟重新測試,而且還要測試有可能受影響的所有功能。因此應當鼓勵對所有回歸測試用例進行自動化測試。
驗收測試
驗收測試,英文是Acceptancetesting。
驗收測試是指系統開發生命周期方法論的一個階段,這時相關的用戶或獨立測試人員根據測試計劃和結果對系統進行測試和接收。它讓系統用戶決定是否接收系統。它是一項确定産品是否能夠滿足合同或用戶所規定需求的測試。
驗收測試一般有三種策略:正式驗收、非正式驗收或Alpha測試、Beta測試。
靜态測試
靜态測試,英文是StaticTesting。
靜态測試指測試不運行的部分,例如測試産品說明書,對此進行檢查和審閱.。靜态方法是指不運行被測程序本身,僅通過分析或檢查源程序的文法、結構、過程、接口等來檢查程序的正确性。
靜态方法通過程序靜态特性的分析,找出欠缺和可疑之處,例如不匹配的參數、不适當的循環嵌套和分支嵌套、不允許的遞歸、未使用過的變量、空指針的引用和可疑的計算等。靜态測試結果可用于進一步的查錯,并為測試用例選取提供指導。
靜态測試常用工具有:Logiscope、PRQA;
集成測試
集成測試,英文是IntegrationTesting。
集成測試是指一個應用系統的各個部件的聯合測試,以決定他們能否在一起共同工作并沒有沖突。部件可以是代碼塊、獨立的應用、網絡上的客戶端或服務器端程序。這種類型的測試尤其與客戶服務器和分布式系統有關。一般集成測試以前,單元測試需要完成。
集成測試是單元測試的邏輯擴展。它的最簡單的形式是:兩個已經測試過的單元組合成一個組件,并且測試它們之間的接口。從這一層意義上講,組件是指多個單元的集成聚合。
在現實方案中,許多單元組合成組件,而這些組件又聚合成程序的更大部分。方法是測試片段的組合,并最終擴展進程,将您的模塊與其他組的模塊一起測試。最後,将構成進程的所有模塊一起測試。此外,如果程序由多個進程組成,應該成對測試它們,而不是同時測試所有進程。
集成測試識别組合單元時出現的問題。通過使用要求在組合單元前測試每個單元,并确保每個單元的生存能力的測試計劃,可以知道在組合單元時所發現的任何錯誤很可能與單元之間的接口有關。這種方法将可能發生的情況數量減少到更簡單的分析級别
卸載測試
卸載測試,英文是UninstallTesting。
卸載測試是對軟件的全部、部分或升級卸載處理過程的測試。主要是測試軟件能否卸載,卸載是否幹淨,對系統有無更改,在系統中的殘留與後來的生成文件如何處理等。還有原來更改的系統值是否修改回去
性能測試
性能測試,英文是PerformanceTesting。
性能測試是在交替進行負荷和強迫測試時常用的術語。理想的“性能測試”(和其他類型的測試)應在需求文檔或質量保證、測試計劃中定義。性能測試一般包括負載測試和壓力測試。
通常驗證軟件的性能在正常環境和系統條件下重複使用是否還能滿足性能指标。或者執行同樣任務時新版本不比舊版本慢。一般還檢查系統記憶容量在運行程序時會不會出現内存洩露(memoryleak)。比如,驗證程序保存一個巨大的文件新版本不比舊版本慢。
健全測試
健全測試,英文是Sanitytesting。
健全測試是指一個初始化的測試工作,以決定一個新的軟件版本測試是否足以執行下一步大的測試能力。例如,如果一個新版軟件每5分鐘與系統沖突,使系統陷于泥潭,說明該軟件不夠“健全”,不具備進一步測試的條件。
衰竭測試
衰竭測試,英文是FailureTesting。
衰竭測試是指軟件或環境的修複或更正後的“再測試”。可能很難确定需要多少遍再次測試。尤其在接近開發周期結束時。自動測試工具對這類測試尤其有用。
負載測試
負載測試,英文是Loadtesting。
負載測試是測試一個應用在重負荷下的表現。例如測試一個Web站點在大量的負荷下,何時系統的響應會退化或失敗,以發現設計上的錯誤或驗證系統的負載能力。在這種測試中,将使測試對象承擔不同的工作量,以評測和評估測試對象在不同工作量條件下的性能行為,以及持續正常運行的能力。
負載測試的目标是确定并确保系統在超出最大預期工作量的情況下仍能正常運行。此外,負載測試還要評估性能特征,例如,響應時間、事務處理速率和其他與時間相關的方面。
強迫測試
強迫測試,英文是ForceTesting。
強迫測試是在交替進行負荷和性能測試時常用的術語。也用于描述對象在異乎尋常的重載下的系統功能測試之類的測試,如某個動作或輸入大量的重複,大量數據的輸入,對一個數據庫系統大量的複雜查詢等。
壓力測試
壓力測試,英文是StressTesting。和負載測試差不多。
壓力測試是一種基本的質量保證行為,它是每個重要軟件測試工作的一部分。壓力測試的基本思路很簡單:不是在常規條件下運行手動或自動測試,而是在計算機數量較少或系統資源匮乏的條件下運行測試。通常要進行壓力測試的資源包括内部内存、CPU可用性、磁盤空間和網絡帶寬等。一般用并發來做壓力測試。
恢複測試
恢複測試,英文是Recoverytesting。
恢複測試是測試一個系統從如下災難中能否很好地恢複,如遇到系統崩潰、硬件損壞或其他災難性問題。恢複測試指通過人為的讓軟件(或者硬件)出現故障來檢測系統是否能正确的恢複,通常關注恢複所需的時間以及恢複的程度。
恢複測試主要檢查系統的容錯能力。當系統出錯時,能否在指定時間間隔内修正錯誤并重新啟動系統。恢複測試首先要采用各種辦法強迫系統失敗,然後驗證系統是否能盡快恢複。
對于自動恢複需驗證重新初始化(reinitialization)、檢查點(checkpointingmechanisms)、數據恢複(datarecovery)和重新啟動(restart)等機制的正确性;對于人工幹預的恢複系統,還需估測平均修複時間,确定其是否在可接受的範圍内。
安全測試
安全測試,英文是SecurityTesting。
安全測試是測試系統在防止非授權的内部或外部用戶的訪問或故意破壞等情況時怎麼樣。這可能需要複雜的測試技術。安全測試檢查系統對非法侵入的防範能力。安全測試期間,測試人員假扮非法入侵者,采用各種辦法試圖突破防線。例如:
①想方設法截取或破譯口令;
②專門定做軟件破壞系統的保護機制;
③故意導緻系統失敗,企圖趁恢複之機非法進入;
④試圖通過浏覽非保密數據,推導所需信息,等等。理論上講,隻要有足夠的時間和資源,沒有不可進入的系統。因此系統安全設計的準則是,使非法侵入的代價超過被保護信息的價值。此時非法侵入者已無利可圖。
兼容性
兼容測試,英文是CompatibilityTesting。
兼容測試是測試軟件在一個特定的硬件/軟件/操作系統/網絡等環境下的性能如何。向上兼容向下兼容,軟件兼容硬件兼容。軟件的兼容性有很多需要考慮的地方。
可用性
可用性測試,英文是PracticalUsabilityTesting。
可用性測試是對“用戶友好性”的測試。顯然這是主觀的,且将取決于目标最終用戶或客戶。用戶面談、調查、用戶對話的錄象和其他一些技術都可使用。程序員和測試員通常都不宜作可用性測試員。
比較測試
比較測試,英文是CompareTesting。
比較測試是指與競争夥伴的産品的比較測試,如軟件的弱點、優點或實力。來取長補短,以增強産品的競争力。
強力測試
強力測試,英文是MightinessTesting。
強力測試通常驗證軟件的性能在各種極端的環境和系統條件下是否還能正常工作。或者說是驗證軟件的性能在各種極端環境和系統條件下的承受能力。比如,在最低的硬盤驅動器空間或系統記憶容量條件下,驗證程序重複執行打開和保存一個巨大的文件1000次後也不會崩潰或死機。
裝配安裝
裝配/安裝/配置測試是驗證軟件程序在不同廠家的硬件上,所支持的不同語言的新舊版本平台上,和不同方式安裝的軟件都能夠如預期的那樣正确運行。比如,把英文版的MicrosoftOffice2003安裝在韓文版的WindowsMe上,再驗證所有功能都正常運行。
隐藏數據
隐藏數據測試在軟件驗收和确認階段是十分必要和重要的一部分。程序的質量不僅僅通過用戶界面的可視化數據來驗證,而且必須包括遍曆系統的所有數據。
等價劃分
等價劃分測試的英文是equivalencepartitiontesting。
等價劃分測試是根據等價類設計測試用例的一種技術。是黑盒測試的典型方法之一,通過把被測試程序所有可能的輸入數據域劃分成若幹部分。從每一部分中選取少數有代表性的數據作為測試用例,可有效減少測試次數,極大提高軟件測試效率,縮短軟件開發周期。
等價類劃分測試的目的就是為了在有限的測試資源的情況下,用少量有代表性的數據得到比較好的測試效果。有效等價類和無效等價類。有效等價類中的數據代表的是一組符合需求文檔的正确的有意義數據。無效等價類則正相反。
判定表
判定表的英文是decisiontable,是指一個表格,用于顯示條件和條件導緻動作的集合。
定義:判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。
判定表的優點:能夠将複雜的問題按照各種可能的情況全部列舉出來,簡明并避免遺漏。因此,利用判定表能夠設計出完整的測試用例集合。
在一些數據處理問題當中,某些操作的實施依賴于多個邏輯條件的組合,即:針對不同邏輯條件的組合值,分别執行不同的操作。判定表很适合于處理這類問題
深度測試
深度測試的英文Depthtest,是指執行一個産品的一個特性的所有細節,但不測試所有特性。
當比較函數返回真的時候才顯示出效果來。必須啟用“#深度測試”,才能執行測試。不使用的時候需要關閉。
文檔測試
文檔測試的英文是documentationtesting,測試關注于文檔的正确性。
文檔測試有三大類分别是開發文件、用戶文件、管理文件。
1.開發文件:可行性研究報告、軟件需求說明書、數據要求說明書、概要設計說明書、詳細設計說明書、數據庫設計說明書、模塊開發卷宗。
2.用戶文件:用戶手冊、操作手冊。
3.管理文件:項目開發計劃、測試計劃、測試分析報告、開發進度月報、項目開發總結報告。
軟件測試中的文檔測試主要是對相關的設計報告和用戶使用說明進行測試,對于設計報告主要是測試程序與設計報告中的設計思想是否一緻;對于用戶使用說明進行測試時,主要是測試用戶使用說明書中對程序操作方法的描述是否正确,重點是用戶使用說明中提到的操作例子要進行測試,保證采用的例子能夠在程序中正确完成操作。
一般來說,文檔是軟件的重要組成部分,因此文檔測試也是軟件測試的主要内容。在軟件的整個生命周期中會出現很多文檔,通常可以把文檔粗略地分為三類:開發文檔,管理文檔和用戶文檔。
由于文檔與代碼不同,不能直接運行,對于文檔的測試通常隻能以文檔審查的方式進行。對于管理文檔和審查通常歸屬于管理範疇,而不是軟件測試範疇,因為對于管理文檔審查的目的不是為了發現和消除用戶所看到的軟件中的缺陷,而是為了更好地管理軟件開發的過程。
對于開發文檔,由于這些文檔本身體現了所在開發階段的軟件實際形态,對于這些文檔的測試實際上是早期軟件測試的主要活動。用戶文檔是那些随程序一起交付給用戶的文檔,它們實際上是交付給用戶的軟件的重要組成部分。對于這些文檔的測試是對最終軟件産品測試的一部分。
域測試
域測試的英文是domaintesting,定義參考等價劃分測試(equivalencepartitiontesting);
一般分為單域測試和多域測試,其中單域測試包括設備測試和業務測試,設備測試包括測試某個系統的軟交換設備、中繼媒體網關設備、信令網關設備、接入媒體網關和IAD等設備。
等價類劃分有兩種不同的情況:有效等價類和無效等價類。設計時要同時考慮這兩種等價類,因為軟件不僅要能接收合理的數據,也要能經受意外的考驗。
一有效等價類:是指對于程序的規格說明來說是合理的、有意義的輸入數據構成的集合。利用有效等價類可檢驗程序是否實現了規格說明中所規定的功能和性能。
二無效等價類:與有效等價類的定義恰巧相反。
接口測試
接口測試的英文是interfacetesting,接口測試測試系統組件間接口的一種測試。
接口測試的好處:
由于接口測試代碼本身就是用junit(當然接口的類型不同,不一定是Junit來實現)來實現的,是屬于自動化測試的範疇,因此必定也包含自動化測試所固有的優勢。
1)提高測試質量
軟件開發的過程是一個持續集成和改進的過程,而每一次的改進都可能引進新bug,因此當軟件的一部,或者全部修改時,都需要對軟件産品重新進行測試。其目的是要驗證修改後的産品是符合需求的,而當沒有自動化測試代碼時,往往會由于各種各樣的原因,回歸不充分,導緻bug遺漏。
2)提高測試效率
軟件系統的規模越來越大,功能點越來越多,開發人員的自測或者測試人員的人工測試非常耗時和繁瑣,勢必導緻測試效率的低下,而自動化測試正好解決這些耗時繁瑣的任務,在對外接口功能不變的情況下,達到了一次編寫,永久使用的效果。
3)提高測試複蓋
通過手工測試很難測試到一些更深層次的異常和安全的問題,通過一些輔助的一些測試工具,能分析出代碼的複蓋率,通過複蓋率的提高來提高測試的深度。
4)更好地重現軟件缺陷
由于每次執行都是相同的代碼,一旦代碼出錯,必定回歸出錯
5)更好定位錯誤
由于接口測試是一種自下向上的測試,因此一量出錯,非常容易定位出錯,不向系統測試那樣了,一旦有Bug,需要幾層驗證之後才能确定出錯位置
6)降低修改bug的成本接口測試基本和開發人員的編碼平行工作,因此發現問題會比系統測試早很多,因此減少了修改bug的成本。
7)增進測試人員和開發人員之間的合作關系,測試工程師為了更好地開展工作,需要對開發技術有深入的理解和實踐,有了與開發工程師更多的交流。
8)降低了項目不能按時發布的風險由于接口測試很早就介入,在提交給系統測試前對項目代碼的核心模塊已經做了詳盡的測試,必定加速系統測試的時間,由此來保證項目的按時發布。
9)提升測試人員的技能。做接口測試必須了解開發人員的開發流程和一些開發技能,也需要了解測試工具的一些使用方法和一些測試思想,提升了測試人員的技術附加值,提高了自身的競争力。
10)促使項目開發過程的規範化
要進行接口,需要完善的文檔進行保障,沒有測試文檔,接口測試将寸步難行,接口測試将增加開發過程規範化産出,而規範化産出也保證了項目質量。
逆向測試
逆向測試/反向測試/負面測試的英文是NegativeTesting,測試瞄準于使系統不能工作。
負面測試與正面測試的比較:
負面測試(Negativetesting)是相對于正面測試(Positivetesting)而言的。它們也是測試設計時的兩個非常重要的劃分。簡單點說,正面測試就是測試系統是否完成了它應該完成的工作;而負面測試就是測試系統是否不執行它不應該完成的操作。形象一點,正面測試就象一個畢恭畢敬的小學生,老師叫我做什麼,我就做什麼;而負面測試就象一個調皮搗蛋的孩子,你叫我這樣做,我偏不這樣做,而且和你對着幹。開發人員也是最讨厭修改此類bug的。
非功能性
非功能性需求測試的英文是non-functionalrequirementstesting,是與功能不相關的需求測試,如:性能測試、可用性測試等。
為什麼非功能性需求很重要?
在您設計解決方案的過程中滿足功能性需求當然是很重要的。但是,如果沒有考慮非功能性需求,您的解決方案則很難取得實效。
非功能性需求特點:1.不要脫離實際環境;2.可靠性;3.可用性;4.有效性;5.可維護性;6.可移植性。