1.1 軟件概述

對于軟件大家應(yīng)該都不陌生，我們每天都會使用各種各樣的軟件，如Windows、Office、微信、QQ等。軟件是相對于硬件而言的，它是一系列按照特定順序組織的計算機數(shù)據(jù)和指令的集合。

軟件和其他產(chǎn)品一樣，都有一個從“出生”到“消亡”的過程，這個過程稱為軟件的生命周期。在軟件的生命周期中，軟件測試是非常重要的一個環(huán)節(jié)。學習軟件測試，必須要對軟件相關(guān)知識有一定了解，包括軟件生命周期、軟件開發(fā)模型、軟件質(zhì)量等。本節(jié)將對軟件的這些知識進行詳細講解。

1.1.1 軟件生命周期

軟件生命周期分為多個階段，每個階段有明確的任務(wù)，這樣就使得結(jié)構(gòu)復(fù)雜、管理復(fù)雜的軟件開發(fā)變得容易控制和管理。通常，可將軟件生命周期劃分為6個階段，如圖1-1所示。

圖1-1中每個階段的目標任務(wù)及含義分別介紹如下。

第1階段：問題定義，該階段由軟件開發(fā)方與需求方共同討論，主要確定軟件的開發(fā)目標及其可行性。

第2階段：需求分析，該階段對軟件需求進行更深入的分析，劃分出軟件需要實現(xiàn)的功能模塊，并制作成文檔。需求分析在軟件的整個生命周期中起著非常重要的作用，它直接關(guān)系到后期軟件開發(fā)的成功率。在后期開發(fā)中，需求可能會發(fā)生變化，因此，在進行需求分析時，應(yīng)考慮到需求的變化，以保證整個項目的順利進行。

第3階段：軟件設(shè)計，該階段在需求分析結(jié)果的基礎(chǔ)上，對整個軟件系統(tǒng)進行設(shè)計，如系統(tǒng)框架設(shè)計、數(shù)據(jù)庫設(shè)計等。

第4階段：軟件開發(fā)，該階段在軟件設(shè)計的基礎(chǔ)上，選擇一種編程語言進行開發(fā)。在開發(fā)過程中，必須要制訂統(tǒng)一的、符合標準的程序編寫規(guī)范，以保證程序的可讀性、易維護性以及可移植性。

第5階段：軟件測試，該階段是軟件開發(fā)完成后對軟件進行測試，以查找軟件設(shè)計與軟件開發(fā)過程中存在的問題并加以修正。軟件測試過程包括單元測試、集成測試、系統(tǒng)測試3個階段；測試的方法以黑盒測試、白盒測試或者兩者結(jié)合的形式進行。在測試過程中，為減少測試的隨意性，需要制訂詳細的測試計劃并嚴格遵守；測試完成之后，要對測試結(jié)果進行分析并對測試結(jié)果以文檔的形式匯總。

第6階段：軟件維護，軟件完成測試并投入使用之后，面對龐大的用戶群體，軟件可能無法滿足用戶使用需求，此時就需要對軟件進行維護升級以延續(xù)軟件的使用壽命。軟件的維護包括糾錯性維護和改進性維護兩個方面。軟件維護是軟件生命周期中持續(xù)時間最長的階段。

1.1.2 軟件開發(fā)模型

軟件測試工作與軟件開發(fā)模型息息相關(guān)，在不同的軟件開發(fā)模型中，測試的任務(wù)和作用也不相同，因此測試人員要充分了解軟件開發(fā)模型，以便找準自己在其中的定位與任務(wù)。

軟件開發(fā)模型規(guī)定了軟件開發(fā)應(yīng)遵循的步驟，是軟件開發(fā)的導(dǎo)航圖，它能夠清晰、直觀地表達軟件開發(fā)的全過程，以及每個階段要進行的活動和要完成的任務(wù)。開發(fā)人員在選擇開發(fā)模型時，要根據(jù)軟件的特點、開發(fā)人員的參與方式選擇穩(wěn)定可靠的開發(fā)模型。

自有軟件開發(fā)以來，軟件開發(fā)模型也從最初的“邊做邊改”發(fā)展出了多個模型，下面以軟件開發(fā)模型發(fā)展歷史為順序，介紹幾個典型的開發(fā)模型。

1. 瀑布模型

瀑布模型是W.W.羅伊斯（W.W.Royce）于1970年提出的軟件開發(fā)模型，由模型名稱可知該模型遵循從上至下一次性完成整個軟件產(chǎn)品的開發(fā)方式。

瀑布模型將軟件開發(fā)過程分為6個階段：計劃→需求分析→軟件設(shè)計→編碼→測試→運行維護，其開發(fā)過程如圖1-2所示。

在瀑布模型中，軟件開發(fā)的各項活動嚴格按照這條線進行，只有當一個階段任務(wù)完成之后才能開始下一個階段。軟件開發(fā)的每一個階段都要有結(jié)果產(chǎn)出，結(jié)果經(jīng)過審核驗證之后作為下一個階段的輸入，下一個階段才可以順利進行。如果結(jié)果審核驗證不通過，則需要返回修改。

瀑布模型為整個項目劃分了清晰的檢查點，當一個階段完成之后，只需要把全部精力放置在后面的開發(fā)上即可，它有利于大型軟件開發(fā)人員的組織管理及工具的使用與研究，可以提高開發(fā)的效率。

但是瀑布模型是嚴格按照線性方式進行的，無法適應(yīng)用戶需求變更，用戶只能等到最后才能看到開發(fā)成果，增加了開發(fā)風險。如果開發(fā)人員與客戶對需求理解有偏差，到最后開發(fā)完成后，最終成果與客戶需求可能會差之千里。

使用瀑布模型開發(fā)軟件時，如果早期犯的錯誤在項目完成后才發(fā)現(xiàn)，此時再修改原來的錯誤需要付出巨大的代價。瀑布模型要求每一個階段必須有結(jié)果產(chǎn)出，這就勢必增加了文檔的數(shù)量，使軟件開發(fā)的工作量變大。

除此之外，對于現(xiàn)代軟件來說，軟件開發(fā)各階段之間的關(guān)系大部分不會是線性的，很難使用瀑布模型開發(fā)軟件，因此瀑布模型不再適合現(xiàn)代軟件開發(fā)，已經(jīng)被逐漸廢棄。

2. 快速原型模型

快速原型模型與瀑布模型正好相反，它在最初確定用戶需求時快速構(gòu)造出一個可以運行的軟件原型，這個軟件原型向用戶展示待開發(fā)軟件的全部或部分功能和性能，客戶對該原型進行審核評價，然后給出更具體的需求意見，這樣逐步豐富細化需求，最后開發(fā)人員與客戶達成最終共識，確定客戶的真正需求。確定客戶的真正需求之后，開始真正的軟件開發(fā)。

快速原型模型類似于建造房子，確定客戶對房子的需求之后快速地搭建一個房子模型，由客戶對房子模型進行評價，房子的樣式、功能、布局等是否滿足需求，哪里需要改進等，一旦最后確定了客戶對房子的要求，就開始真正地建造房子。該模型的開發(fā)過程如圖1-3所示。

與瀑布模型相比，快速原型模型克服了需求不明確帶來的風險，適用于不能預(yù)先確定需求的軟件項目。但快速原型模型關(guān)鍵在于快速構(gòu)建軟件原型，準確地設(shè)計出軟件原型存在一定的難度。此外，這種開發(fā)模型也不利于開發(fā)人員對產(chǎn)品進行擴展。

3. 迭代模型

迭代模型又稱為增量模型或演化模型，它將一個完整的軟件拆分成不同的組件，然后逐個組件地開發(fā)測試，每完成一個組件就展現(xiàn)給客戶，讓客戶確認這一部件功能和性能是否達到客戶需求，最終確定無誤，將組件集成到軟件體系結(jié)構(gòu)中。整個開發(fā)工作被組織為一系列短期、簡單的小項目，稱為一系列迭代，每一個迭代都需要經(jīng)過需求分析→軟件設(shè)計→編碼→測試的過程，其開發(fā)過程如圖1-4所示。

在迭代模型中，第一個迭代（即第一個組件）往往是軟件基本需求的核心部分，第一個組件完成之后，經(jīng)過客戶審核評價形成下一個組件的開發(fā)計劃，包括對核心產(chǎn)品的修改和新功能的發(fā)布，這樣重復(fù)迭代步驟直到實現(xiàn)最終完善的產(chǎn)品。

迭代模型可以很好地適應(yīng)客戶需求變更，它逐個組件地交付產(chǎn)品，客戶可以經(jīng)?？吹疆a(chǎn)品，如果某個組件沒有滿足客戶需求，則只需要更改這一個組件，降低了軟件開發(fā)的成本與風險。但是迭代模型需要將開發(fā)完成的組件集成到軟件體系結(jié)構(gòu)中，這樣會有集成失敗的風險，因此要求軟件必須有開放式的體系結(jié)構(gòu)。此外，迭代模型逐個組件地開發(fā)修改，很容易退化為“邊做邊改”的開發(fā)形式，從而失去對軟件開發(fā)過程的整體控制。

4. 螺旋模型

螺旋模型由巴利·玻姆（Barry Boehm）于1988年提出，該模型融合了瀑布模型、快速原型模型，它最大的特點是引入了其他模型所忽略的風險分析，如果項目不能排除重大風險，就停止項目從而減小損失。這種模型比較適合開發(fā)復(fù)雜的大型軟件。

螺旋模型將整個項目開發(fā)過程劃分為幾個不同的階段，每個階段按部就班地執(zhí)行，這種劃分方式采用了瀑布模型。每個階段在開始之前都要進行風險評估，如果能消除重大風險則可以開始該階段任務(wù)。在每個階段，首先構(gòu)建軟件原型，根據(jù)快速原型模型完成這個迭代過程，產(chǎn)出最終完善的產(chǎn)品，然后進入下一個階段，同樣下一個階段開始之前也要進行風險評估，這樣循環(huán)往復(fù)直到完成所有階段的任務(wù)。螺旋模型的若干個階段是沿著螺線方式進行的，如圖1-5所示。

圖1-5有4個象限：制訂計劃、風險分析、實施工程、客戶評估，各象限含義如下。

（1）制訂計劃：確定軟件目標，制訂實施方案，并且列出項目開發(fā)的限制條件。

（2）風險分析：評價所制訂的實施方案，識別風險并消除風險。

（3）實施工程：開發(fā)產(chǎn)品并進行驗證。

（4）客戶評估：客戶對產(chǎn)品進行審核評估，提出修正建議，制訂下一步計劃。

在螺旋模型中，每一個迭代都需要經(jīng)過這4個步驟，直到最后得到完善的產(chǎn)品，可以進行提交。

螺旋模型強調(diào)了風險分析，這意味著對可選方案和限制條件都進行了評估，更有助于將軟件質(zhì)量作為特殊目標融入產(chǎn)品開發(fā)之中。它以小分段構(gòu)建大型軟件，使成本計算變得簡單容易，而且客戶始終參與每個階段的開發(fā)，保證了項目不偏離正確方向，也保證了項目的可控制性。

5. 敏捷模型

敏捷模型是20世紀90年代興起的一種軟件開發(fā)模型。在現(xiàn)代社會，技術(shù)發(fā)展非?？欤浖_發(fā)也是在快節(jié)奏的環(huán)境中進行的。在業(yè)務(wù)快速變換的環(huán)境下，往往無法在軟件開發(fā)之前收集到完整而詳盡的軟件需求。沒有完整的軟件需求，傳統(tǒng)的軟件開發(fā)模型就難以展開工作。

為了解決這個問題，人們提出了敏捷開發(fā)模型。敏捷模型以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷模型中，軟件項目在構(gòu)建初期被拆分為多個相互聯(lián)系而又獨立運行的子項目，然后迭代完成各個子項目，開發(fā)過程中，各個子項目都要經(jīng)過開發(fā)測試。當客戶有需求變更時，敏捷模型能夠迅速地對某個子項目做出修改以滿足客戶的需求。在這個過程中，軟件一直處于可使用狀態(tài)。

除了響應(yīng)需求，敏捷模型還有一個重要的概念——迭代，就是不斷對產(chǎn)品進行細微、漸進式的改進，每次改進一小部分，如果可行再逐步擴大改進范圍。在敏捷模型中，軟件開發(fā)不再是線性的，開發(fā)的同時也會進行測試工作，甚至可以提前寫好測試代碼，因此在敏捷模型中，有“開發(fā)未動，測試先行”的說法。

另外，相比于傳統(tǒng)的軟件開發(fā)模型，敏捷模型更注重“人”在軟件開發(fā)中的作用，項目的各部門應(yīng)該緊密合作、快速有效地溝通（如面對面溝通），提出需求的客戶可以全程參與到開發(fā)過程，以適應(yīng)軟件頻繁的需求變更。為此，敏捷模型描述了一套軟件開發(fā)的價值和原則，具體如下所示。

（1）個體和交互重于過程和工具。

（2）可用軟件重于完備文檔。

（3）客戶協(xié)作重于合同談判。

（4）響應(yīng)變化重于遵循計劃。

對于敏捷模型來說，并不是工具、文檔等不重要，而是更注重人與人之間的交流溝通。

敏捷模型可以及時響應(yīng)客戶需求變更，不斷適應(yīng)新的趨勢，但是在開發(fā)靈活的同時也帶來了一定程度的混亂。例如，缺乏文檔資料；軟件之前版本的可重現(xiàn)性、可回溯性較低；對于較大的項目，人員越多，面對面的有效溝通越困難。因此敏捷模型比較適用于小型項目的開發(fā)，而不太適用于大型項目。

多學一招：敏捷模型的開發(fā)方式

敏捷模型主要有2種開發(fā)方式：Scrum與Kanban，下面分別對這兩種開發(fā)方式進行簡單的介紹。

1. Scrum

在Scrum開發(fā)方式的團隊中，會選出一個Scrum Master（產(chǎn)品負責人）全面負責產(chǎn)品的開發(fā)過程。Scrum Master把團隊劃分成不同的小組，把整個項目劃分成細小的可交付成果的子項目，分別由不同的小組完成，并對各小組的工作劃分優(yōu)先級，估算每個小組的工作量。

在開發(fā)過程中，每個小組的工作都是一個固定時長的短周期迭代，開發(fā)短周期一般為1～4周。開發(fā)完成之后，經(jīng)過一系列的測試、優(yōu)化等，將產(chǎn)品集成，交付最終成果。

2. Kanban

Kanban（看板）源于豐田的生產(chǎn)模式，它將工作細分成任務(wù)，將工作流程顯示在“看板卡”上，每個人都能及時了解自己的工作任務(wù)及工作進度。這種生產(chǎn)理念后來被引入到軟件開發(fā)中，利用可視化軟件將開發(fā)的軟件項目細分成小任務(wù)，并分配給團隊成員，每個成員都可以在“看板”上了解自己的工作任務(wù)及整個團隊的工作進度。項目開始之后，從目前執(zhí)行的任務(wù)和過程開始，團隊會針對每個成員的工作做出持續(xù)、增量、漸進式的改變。

1.1.3 軟件質(zhì)量概述

軟件產(chǎn)品與其他產(chǎn)品一樣，都是有質(zhì)量要求的，軟件質(zhì)量關(guān)系著軟件使用程度與使用壽命，一款高質(zhì)量的軟件更受用戶歡迎，它除了滿足客戶的顯式需求之外，往往還滿足了客戶隱式需求。下面分別從軟件質(zhì)量的概念、軟件質(zhì)量模型、影響軟件質(zhì)量的因素這幾個方面介紹軟件質(zhì)量的相關(guān)知識。

1. 軟件質(zhì)量的概念

軟件質(zhì)量是指軟件產(chǎn)品滿足基本需求及隱式需求的程度。軟件產(chǎn)品滿足基本需求是指其能滿足軟件開發(fā)時所規(guī)定需求的特性，這是軟件產(chǎn)品最基本的質(zhì)量要求；其次是軟件產(chǎn)品滿足隱式需求的程度。例如，產(chǎn)品界面更美觀、用戶操作更簡單等。

從軟件質(zhì)量的定義，可將軟件質(zhì)量分為3個層次，具體如下。

（1）滿足需求規(guī)定：軟件產(chǎn)品符合開發(fā)者明確定義的目標，并且能可靠運行。

（2）滿足用戶需求：軟件產(chǎn)品的需求是由用戶產(chǎn)生的，軟件最終的目的就是滿足用戶需求，解決用戶的實際問題。

（3）滿足用戶隱式需求：除了滿足用戶的顯式需求，軟件產(chǎn)品如果滿足用戶的隱式需求，即潛在的可能需要在將來開發(fā)的功能，將會極大地提升用戶滿意度，這就意味著軟件質(zhì)量更高。

所謂高質(zhì)量的軟件，除了滿足上述需求之外，對于內(nèi)部人員來說，它應(yīng)該也是易于維護與升級的。軟件開發(fā)時，統(tǒng)一的符合標準的編碼規(guī)范、清晰合理的代碼注釋、形成文檔的需求分析、軟件設(shè)計等資料對于軟件后期的維護與升級都有很大的幫助，同時，這些資料也是軟件質(zhì)量的一個重要體現(xiàn)。

2. 軟件質(zhì)量模型

軟件質(zhì)量是使用者與開發(fā)者都比較關(guān)心的問題，但全面客觀地評價一個軟件產(chǎn)品的質(zhì)量并不容易，它并不像普通產(chǎn)品一樣，可以通過直觀的觀察或簡單的測量能得出其質(zhì)量是優(yōu)還是劣。那么如何評價一款軟件的質(zhì)量呢？目前，最通用的做法就是按照ISO/IEC 9126:1991國際標準來評價一款軟件的質(zhì)量。

ISO/IEC 9126:1991是最通用的一個評價軟件質(zhì)量的國際標準，它不僅對軟件質(zhì)量進行了定義，而且還制訂了軟件測試的規(guī)范流程，包括測試計劃的撰寫、測試用例的設(shè)計等。ISO/IEC 9126:1991標準由6個特性和27個子特性組成，如圖1-6所示。

ISO/IEC 9126:1991標準所包含的6大特性的具體含義如下。

（1）功能性：在指定條件下，軟件滿足用戶顯式需求和隱式需求的能力。

（2）可靠性：在指定條件下使用時，軟件產(chǎn)品維持規(guī)定的性能級別的能力。

（3）可使用性：在指定條件下，軟件產(chǎn)品被使用、理解、學習的能力。

（4）效率：在指定條件下，相對于所有資源的數(shù)量，軟件產(chǎn)品可提供適當性能的能力。

（5）可維護性：指軟件產(chǎn)品被修改的能力。修改包括修正、優(yōu)化和功能規(guī)格變更的說明。

（6）可移植性：指軟件產(chǎn)品從一個環(huán)境遷移到另一個環(huán)境的能力。

這6大特性及其子特性是軟件質(zhì)量標準的核心，軟件測試工作就從這6個特性和27個子特性去測試、評價一個軟件的。

多學一招：紙杯測試

“紙杯測試”是一個經(jīng)典的測試案例，這是微軟公司曾給軟件測試者出的一道面試題，用于考察面試者對軟件測試的理解與掌握程度。

測試項目：紙杯。

需求測試：查看紙杯說明書是否完整。

界面測試：觀察紙杯外觀，測試表面是否光滑、手感是否舒適。

功能測試：用紙杯裝水，觀察是否漏水。

安全測試：紙杯是否有毒或細菌。

可靠性測試：從不同高度摔下來，觀察紙杯的損壞程度。

易用性測試：用紙杯盛放開水是否燙手，紙杯是否易滑、是否方便飲用。

兼容性測試：用紙杯分別盛放水、酒精、飲料、汽油等，觀察是否有滲漏現(xiàn)象。

可移植性測試：將紙杯放在溫度、濕度等不同的環(huán)境中，查看紙杯是否還能正常使用。

可維護性：將紙杯揉捏變形，看其是否能恢復(fù)。

壓力測試：用一根針扎在紙杯上不斷增加力量，記錄多大壓強時針能穿透紙杯。

疲勞測試：用紙杯分別盛放水、汽油放置24小時，觀察其滲漏情況（時間和程度）。

跌落測試：紙杯（加包裝）從高處落下，查看可造成破損的高度。

震動測試：紙杯（加包裝）六面震動，評估它是否能應(yīng)對惡劣的公路/鐵路/航空運輸?shù)取?/p>

測試數(shù)據(jù)：編寫具體測試數(shù)據(jù)（略），其中可能會用到場景法、等價類劃分法、邊界值分析法等測試方法。

期望輸出：期望輸出需要查閱國際標準及用戶的使用需求。

用戶文檔：使用手冊是否對紙杯的用法、使用條件、限制條件等有詳細描述。

說明書測試：查看紙杯說明書的正確性、準確性及完整性。

3. 影響軟件質(zhì)量的因素

現(xiàn)代社會處處離不開軟件，為保證人們生活工作正常有序地進行，就要嚴格控制好軟件的質(zhì)量。由于軟件自身的特點和目前的軟件開發(fā)模式使得隱藏在軟件內(nèi)部的質(zhì)量缺陷無法完全根除，因此每一款軟件都會存在一些質(zhì)量問題。影響軟件質(zhì)量的因素有很多，下面介紹幾種比較常見的影響因素。

（1）需求模糊

在軟件開發(fā)之前，確定軟件需求是一項非常重要的工作，它是后面軟件設(shè)計與軟件開發(fā)的基礎(chǔ)，也是最后軟件驗收的標準。但是軟件需求是不可視的，往往也說不清楚，導(dǎo)致產(chǎn)品設(shè)計、開發(fā)人員與客戶存在一定的理解誤差，開發(fā)人員對軟件的真正需求不明確，結(jié)果開發(fā)出的產(chǎn)品與實際需求不符，這勢必會影響軟件的質(zhì)量。

除此之外，在開發(fā)過程中客戶往往會一而再再而三地變更需求，導(dǎo)致開發(fā)人員頻繁地修改代碼，這可能會導(dǎo)致軟件在設(shè)計時期存在不能調(diào)和的誤差，最終影響軟件的質(zhì)量。

（2）軟件開發(fā)缺乏規(guī)范性文件指導(dǎo)

現(xiàn)代軟件開發(fā)，大多數(shù)團隊都將精力放在開發(fā)成本與開發(fā)周期上，而不太重視團隊成員的工作規(guī)范，導(dǎo)致團隊成員開發(fā)“隨意性”比較大，這也會影響軟件質(zhì)量，而且一旦最后軟件出現(xiàn)質(zhì)量問題，也很難定責，導(dǎo)致后期維護困難。

（3）軟件開發(fā)人員問題

軟件是由人開發(fā)出來的，因此個人的意識對產(chǎn)品的影響非常大。除了個人技術(shù)水平限制，開發(fā)人員問題還包括人員流動，新來的成員可能會繼承上一任的產(chǎn)品接著開發(fā)下去，兩個人的思維意識、技術(shù)水平等都會不同，導(dǎo)致軟件開發(fā)前后不一致，進而影響軟件質(zhì)量。

（4）缺乏軟件質(zhì)量控制管理

在軟件開發(fā)行業(yè)，并沒有一個量化的指標去度量一款軟件的質(zhì)量，軟件開發(fā)的管理人員更關(guān)注開發(fā)成本和進度，畢竟這是顯而易見的，并且是可以度量的。但軟件質(zhì)量則不同，軟件質(zhì)量無法用具體的量化指標去度量，而且軟件開發(fā)的質(zhì)量并沒有落實到具體的責任人，因此很少有人關(guān)心軟件最終的質(zhì)量。