小組軟件開發(fā)過程9

1、第九章第九章 集成和系統(tǒng)測試集成和系統(tǒng)測試n本章主要內(nèi)容：n測試原則n測試策略n測試計(jì)劃n測試的度量與追蹤n制作用戶文檔時(shí)要考慮的東西nTEST1和TESTn草案9.1 測試原則測試原則n在TSPi中，測試的目的是為了評(píng)估產(chǎn)品，測試的目的是為了評(píng)估產(chǎn)品，而不是為了修正它。而不是為了修正它。n在測試階段以前你應(yīng)該已經(jīng)發(fā)現(xiàn)和修正了幾乎全部的缺陷。n當(dāng)對(duì)質(zhì)量差的產(chǎn)品進(jìn)行測試時(shí)，測試時(shí)間會(huì)急劇變長，而且你可能發(fā)現(xiàn)不了大多數(shù)的剩余缺陷。9.1 測試原則測試原則靠基于測試的質(zhì)量策略讓小系統(tǒng)相當(dāng)可靠地工作要用去大量的時(shí)間。 9.1 測試原則測試原則n一個(gè)產(chǎn)品的質(zhì)量是在它被開發(fā)時(shí)決定的。有無可辯駁的證據(jù)可以證

2、明，使用標(biāo)準(zhǔn)軟件開發(fā)方法的工程師即使很有能力，也總是制作質(zhì)量差的程序。結(jié)果，當(dāng)對(duì)這些程序進(jìn)行測試時(shí)，測試就要用去大量的時(shí)間，而且沒法發(fā)現(xiàn)所有的問題。通常，當(dāng)你測試一個(gè)質(zhì)量差的產(chǎn)品時(shí)，測試之后你得到的仍是質(zhì)量差的產(chǎn)品。9.1 測試原則測試原則它的測試用了6年。最后的10個(gè)嚴(yán)重缺陷是在經(jīng)過了288個(gè)星期的測試之后才被發(fā)現(xiàn)的。這個(gè)過程比五年還要長。 9.2 TSPi測試策略測試策略n在TSPi中，目標(biāo)就是對(duì)優(yōu)質(zhì)程序進(jìn)行測試。然后，在測試中，你驗(yàn)證這個(gè)產(chǎn)品是否是高質(zhì)量的。n主要的TSPi測試活動(dòng)如下n（1）使用已開發(fā)的單元測試過的部分來建立系統(tǒng)。 建立建立n（2）集成測試這個(gè)系統(tǒng)來驗(yàn)證它是否被很適當(dāng)?shù)?/p>

3、建立起來了，所有的部分是否都存在，以及它們是否能共同工作。 集成測試集成測試n（3）系統(tǒng)測試這個(gè)產(chǎn)品來確認(rèn)它滿足了系統(tǒng)需求。 系統(tǒng)測試系統(tǒng)測試n在隨后的開發(fā)周期中，回歸測試回歸測試也是必需的。9.2 TSPi測試策略測試策略n做以上這些的同時(shí)，你應(yīng)進(jìn)行以下活動(dòng)。n（1）確認(rèn)質(zhì)量差的模塊或部件，并將它們返還給質(zhì)量/進(jìn)度監(jiān)督經(jīng)理來進(jìn)行評(píng)估和去除缺陷。n（2）確認(rèn)那些除去缺陷之后仍令人頭疼的質(zhì)量差的部件，并將它們返還給質(zhì)量/進(jìn)度監(jiān)督經(jīng)理來進(jìn)行返工或替換。9.3 建立和集成策略建立和集成策略n建立過程的目的是保證已存在所有需要的部分，裝配好了一個(gè)工作系統(tǒng)，而且為這個(gè)系統(tǒng)提供好集成測試和系統(tǒng)測試。n集成

4、測試應(yīng)該只檢查所有的部件是否存在以及它們的調(diào)用和交互是否起作用。n不應(yīng)該測試部件的功能。那些是在系統(tǒng)測試中做的。9.3 建立和集成策略建立和集成策略n9.3.1 Big-Bang策略策略n將所有的部分放在一起來觀察它們是否能工作。n需要最少的測試開發(fā)。n然而，它很少成功，特別是對(duì)質(zhì)量差的系統(tǒng)來說。n在集成測試中每KLOC發(fā)現(xiàn)10個(gè)或更多的缺陷就是不正常的，而修正在集成測試中發(fā)現(xiàn)的每個(gè)缺陷平均要花5到10小時(shí)。通常，系統(tǒng)越大、越復(fù)雜，用于診斷和修正每個(gè)缺陷的時(shí)間就越長。n除非你有非常高質(zhì)量的部分，否則Big-Bang策略不是一個(gè)好主意。9.3 建立和集成策略建立和集成策略n9.3.2 每次一個(gè)策

5、略每次一個(gè)策略n每次添加一些部分。n相當(dāng)快地讓你發(fā)現(xiàn)問題原因。這個(gè)策略的不利之處在于要求更多的測試開發(fā)工作。9.3 建立和集成策略建立和集成策略n9.3.4 平面系統(tǒng)策略平面系統(tǒng)策略n建立一個(gè)平面系統(tǒng)首先集成所有最高層次部分，然后并行的一層層向下鉆研。你可以一次測試所有的新部分或者一次加入一個(gè)部件。n這個(gè)策略的好處是你能在早期發(fā)現(xiàn)系統(tǒng)范圍的問題?？垦杆俳⑾到y(tǒng)的梗概，你能有最大程度的適應(yīng)性。n平面系統(tǒng)策略的主要問題是，它通常要求大量的存根或特殊的框架提供對(duì)所有未得到的功能的空返回。9.3 建立和集成策略建立和集成策略n沒有哪個(gè)集成策略是對(duì)所有系統(tǒng)都適用的。最好的方法是考慮所有的選擇，選擇出看來

6、最適合你的特定工程的一個(gè)。n幾乎任何邏輯集成策略都將有用。n通常來說，請(qǐng)?jiān)囍赃m當(dāng)小的增量來加入新代碼。9.4 系統(tǒng)測試策略系統(tǒng)測試策略n在系統(tǒng)測試中，你要為四個(gè)問題尋找答案。n系統(tǒng)是否展示了其被要求具有的功能？n系統(tǒng)是否達(dá)到了它的質(zhì)量目標(biāo)？n在正常情況下系統(tǒng)是否能適當(dāng)?shù)剡\(yùn)作？n在非正常情況下系統(tǒng)是否能適當(dāng)?shù)貏?dòng)作？9.4 系統(tǒng)測試策略系統(tǒng)測試策略n你可以首先測試系統(tǒng)每一個(gè)預(yù)期的功能。然后，你在重點(diǎn)條件下檢查操作，評(píng)價(jià)可用性，以及最后衡量其執(zhí)行。n這是最普通的系統(tǒng)測試策略。n用TSPi你應(yīng)該有一個(gè)高質(zhì)量的系統(tǒng)，而且應(yīng)該能夠進(jìn)行更廣泛的系統(tǒng)測試。n但對(duì)于廣泛測試，功能第一的策略可能不是有效的。用仔

7、細(xì)設(shè)計(jì)的測試計(jì)劃，你能用每個(gè)測試來評(píng)估幾個(gè)產(chǎn)品特性。9.4 系統(tǒng)測試策略系統(tǒng)測試策略n第二種策略關(guān)注選出來的功能區(qū)，在進(jìn)行到下一個(gè)功能區(qū)之前，這個(gè)功能區(qū)包含了每個(gè)區(qū)域的每個(gè)方面。n例如，你以測試正常和非正常情況下的數(shù)值運(yùn)算、可用性、執(zhí)行以及質(zhì)量為開端。這種策略很大程度上消除了測試的重復(fù)，但它沒有強(qiáng)調(diào)整體系統(tǒng)行為。僅在微觀層次上測試的話，你可能沒有充分地檢查系統(tǒng)整體的執(zhí)行情況。9.4 系統(tǒng)測試策略系統(tǒng)測試策略n第三種策略n將以上兩種策略結(jié)合了起來。n開始對(duì)正常、非正常和重點(diǎn)行為下低層次的功能進(jìn)行測試。n隨后，進(jìn)入高一點(diǎn)的層次，再測試功能結(jié)合后的情況，以保證它們能協(xié)同工作。n然后再一次在正常、非正

8、常和重點(diǎn)條件下檢查它們。持續(xù)進(jìn)行逐漸增高層次的測試，直至覆蓋整個(gè)系統(tǒng)。n這種策略對(duì)于質(zhì)量差的系統(tǒng)是必需的，因?yàn)樵S多系統(tǒng)功能最初完全不起作用。n對(duì)于大系統(tǒng)來說這種策略的不利之處在于它要花長時(shí)間來循序漸進(jìn)地測試所有的重要功能的結(jié)合。9.4 系統(tǒng)測試策略系統(tǒng)測試策略n第四種策略：n最初，你要對(duì)最高層次的功能測試，n然后逐步向下，一次次進(jìn)行正常和重點(diǎn)測試。n此處，你必須要靠一系列的操作輪廓，使用情形或測試草案來測試系統(tǒng)。盡管這種策略最快地包含了系統(tǒng)問題，但它僅對(duì)高質(zhì)量的產(chǎn)品有效。通常你能從你的部件數(shù)據(jù)和建立與集成測試數(shù)據(jù)來決定產(chǎn)品質(zhì)量。通常在集成之后，你應(yīng)盡可能快地進(jìn)入系統(tǒng)層次的測試。n如果你碰到了質(zhì)

9、量問題，把出現(xiàn)問題的部件返還給質(zhì)量經(jīng)理進(jìn)行修改或替換。9.5 測試計(jì)劃測試計(jì)劃n在TSPi過程中，有幾處制作了測試計(jì)劃。n如同在PSP中，首先制作一個(gè)概念性的測試計(jì)劃，用來估計(jì)要開發(fā)的測試材料的大小，以及測試的開發(fā)和測試工作將用多長時(shí)間。n你需要有進(jìn)行建立，集成測試和系統(tǒng)測試活動(dòng)的測試計(jì)劃。盡管建立和集成計(jì)劃應(yīng)該是簡單的，但在你做之前對(duì)測試做計(jì)劃仍是重要的。 9.5 測試計(jì)劃測試計(jì)劃n完整的測試計(jì)劃描述了:n你計(jì)劃運(yùn)行什么測試，n以什么順序運(yùn)行它們，n以及每個(gè)測試所需的測試材料。n一個(gè)完整的計(jì)劃應(yīng)能夠展示各個(gè)需求怎樣被測試以及測試草案或腳本是怎樣覆蓋需求區(qū)域的。你還應(yīng)該知道那些需求區(qū)域已被詳細(xì)

10、測試過，那些還沒有被詳細(xì)測試。9.5 測試計(jì)劃測試計(jì)劃n此外，你應(yīng)對(duì)每個(gè)預(yù)期的測試命名，定義它應(yīng)該產(chǎn)生的結(jié)果，以及預(yù)測它可能運(yùn)行多長時(shí)間。你還要估計(jì)在每個(gè)測試階段發(fā)現(xiàn)的缺陷數(shù)，總共的修改缺陷時(shí)間，以及預(yù)測它可能運(yùn)行多長時(shí)間。然后你要估計(jì)需要的測試材料的大小。除了LOC的大小估計(jì)外，你將可能需要對(duì)交互測試和測試數(shù)據(jù)的測試草案。對(duì)某些系統(tǒng)，測試數(shù)據(jù)的準(zhǔn)備可能比測試情形的開發(fā)要求更多的工作。9.5 測試計(jì)劃測試計(jì)劃n在結(jié)束測試計(jì)劃時(shí)，你應(yīng)有：在結(jié)束測試計(jì)劃時(shí)，你應(yīng)有：n所有要執(zhí)行的測試步驟清單；n每個(gè)測試所需要的支持材料；n測試產(chǎn)生的結(jié)果；n估計(jì)每個(gè)測試的無缺陷運(yùn)行時(shí)間，發(fā)現(xiàn)的缺陷數(shù)，以及總時(shí)間；n

11、估計(jì)每個(gè)測試計(jì)劃中要求開發(fā)的每個(gè)條款所需的工作的估計(jì)；9.5 測試計(jì)劃測試計(jì)劃n你還需要一個(gè)清單：你還需要一個(gè)清單：n所有需要的測試支持材料和它們支持的測試；n每個(gè)測試的目標(biāo)；n期望這些材料是多大；n它們的開發(fā)可能要用多長時(shí)間；n由誰開發(fā)每個(gè)測試的支持條款；n這些開發(fā)任務(wù)何時(shí)完成。9.5 測試計(jì)劃測試計(jì)劃n最后，開發(fā)測試材料。最后，開發(fā)測試材料。n如果你計(jì)劃一個(gè)重要的測試程序，你可能還要想自檢的測試情形。它們依據(jù)設(shè)計(jì)的程序自動(dòng)檢查實(shí)際測試結(jié)果，而且提供一個(gè)輸出，指示結(jié)果是否是正確的。對(duì)這樣的測試情形，你能運(yùn)行大量的測試，而且僅在最后看一下那些測試就能發(fā)現(xiàn)缺陷。通常，如果你缺乏一系列完整的測試工

12、具，開發(fā)自檢的測試是沒用的。9.6 跟蹤和度量測試跟蹤和度量測試n如果你預(yù)期運(yùn)行許多測試，你將要關(guān)于測試有效性的數(shù)據(jù)。即是，作為運(yùn)行時(shí)間的一個(gè)函數(shù)，每個(gè)測試揭示出多少個(gè)缺陷。n然后，你能使用這些缺陷/小時(shí)數(shù)據(jù)作為選擇測試的標(biāo)準(zhǔn)，它包含反復(fù)測試的地址。根據(jù)經(jīng)驗(yàn)包括先前已發(fā)現(xiàn)的缺陷所有測試的查復(fù)地址，以及驗(yàn)證最近開發(fā)周期內(nèi)被修改的先前測試系統(tǒng)范圍內(nèi)的所有測試。9.6 跟蹤和度量測試跟蹤和度量測試n因?yàn)樵诿總€(gè)TSPi開發(fā)周期中你將運(yùn)行一個(gè)完整的測試集，所以有一些測試的度量是有用的。除了你記錄在LOGD和LOGT中的數(shù)據(jù)外，你還需要回答下列問題。n遠(yuǎn)行這個(gè)測試要花多長時(shí)間？n它發(fā)現(xiàn)了多少個(gè)缺陷？n它是

13、否要求人工干涉，或它是否能與其它測試成批？n它是否自檢？n為回答這些問題，你應(yīng)記錄關(guān)于測試運(yùn)行時(shí)、發(fā)現(xiàn)缺陷數(shù)目和測試環(huán)境的數(shù)據(jù)。將這些數(shù)據(jù)保存在測試日志上是一種方便的方式。9.6 跟蹤和度量測試跟蹤和度量測試9.6.1 測試日志測試日志n以下是記錄在測試日志中的幾種信息。n測試運(yùn)行的日期。n進(jìn)行這個(gè)測試的人的姓名。n測試的運(yùn)行，名字和/或編號(hào)。n被測試的產(chǎn)品和配置。n每個(gè)測試開始運(yùn)行的時(shí)間。n每個(gè)測試結(jié)束運(yùn)行的時(shí)間。n發(fā)現(xiàn)缺陷的數(shù)量，使用LOGD引用和編號(hào)。n測試結(jié)果。9.6 跟蹤和度量測試跟蹤和度量測試9.6.1 測試日志測試日志9.6 跟蹤和度量測試跟蹤和度量測試9.6.1 測試日志測試日

14、志n此外，你可能想包含下列幾種信息。n被測試的系統(tǒng)配置。n任何使用了的特殊工具和設(shè)施。n操作員的干涉是否需要，需要多少。n記錄基本的信息最簡單的方式是記錄在按時(shí)間順序排列的日志中，它很時(shí)間記錄日志。9.6 跟蹤和度量測試跟蹤和度量測試9.6.2 有缺陷傾向的模塊有缺陷傾向的模塊n大的IBM產(chǎn)品的樣品質(zhì)量表示在圖9.3中。X軸表示開發(fā)測試中在每個(gè)部件上所發(fā)現(xiàn)的缺陷，y軸代表由顧客發(fā)現(xiàn)的缺陷。這意味著在測試中部件有很多缺陷時(shí)，在測試之后它可能仍有很多缺陷。換句話說，在測試中你發(fā)現(xiàn)的缺陷越多，那么你沒有發(fā)現(xiàn)的缺陷也就越多。9.6 跟蹤和度量測試跟蹤和度量測試9.6.2 有缺陷傾向的模塊有缺陷傾向的模

15、塊n這指導(dǎo)人們能使用測試數(shù)據(jù)來評(píng)估有一或更多有缺陷傾向部分的系統(tǒng)風(fēng)險(xiǎn)。n為完成這個(gè)工作，要將模塊的缺陷數(shù)據(jù)排序來發(fā)現(xiàn)每次測試中那個(gè)模塊有最多的缺陷。n典型地，有最多缺陷的模塊可能在測試之后仍有最多的缺陷。n如果一些模塊看來特別差，應(yīng)暫時(shí)停止來檢查。這樣做你常常能節(jié)約大量的測試時(shí)間，還能生產(chǎn)出高質(zhì)量的產(chǎn)品。在繼續(xù)測試以前，再檢查和修正這些有缺陷傾向部件。 9.6 跟蹤和度量測試跟蹤和度量測試9.6.3 模塊缺陷數(shù)據(jù)模塊缺陷數(shù)據(jù)nTPSi工具提供兩種方式來檢查模塊缺陷數(shù)據(jù)。nSUMDR表在左邊的欄目中列出了模塊名稱和模塊號(hào)碼，在右邊的欄目中列出了某階段排除的缺陷數(shù)量。n你能制作一個(gè)對(duì)單個(gè)模塊給出了

16、所有的質(zhì)量測試的SUMQ表。n有了這些數(shù)據(jù)，你應(yīng)該能很快確定有缺陷傾向的模塊。n但要注意，在檢查之時(shí)，你應(yīng)該看一下每個(gè)產(chǎn)品開發(fā)周期的每一個(gè)清除缺陷階段。然后你能確定一個(gè)模塊問題開始出現(xiàn)的那個(gè)階段。9.6 跟蹤和度量測試跟蹤和度量測試9.6.4 追蹤缺陷數(shù)據(jù)追蹤缺陷數(shù)據(jù) n為追蹤和分析有缺陷傾向的模塊，你需要每個(gè)測試的有關(guān)每個(gè)缺陷的數(shù)據(jù)。n在每個(gè)星期的會(huì)議上，你還要和整個(gè)小組復(fù)核在建立、集成測試和系統(tǒng)測試中發(fā)現(xiàn)的缺陷。這些缺陷逃過了整個(gè)開發(fā)過程，所以它們的數(shù)據(jù)能為將來發(fā)現(xiàn)預(yù)防近似的缺陷提供重要的線索。以下是一些你能使用這些數(shù)據(jù)回答的問題。n缺陷逃過了那個(gè)過程的步驟？n你能怎樣改變這些步驟以免缺陷

17、不再發(fā)生？n你能怎樣修改開發(fā)過程來預(yù)防將來發(fā)生這些缺陷？n在系統(tǒng)的那里能存在未發(fā)現(xiàn)的類似缺陷？n現(xiàn)在你怎樣發(fā)現(xiàn)這些缺陷并修改它們？9.6 跟蹤和度量測試跟蹤和度量測試9.6.4 追蹤缺陷數(shù)據(jù)追蹤缺陷數(shù)據(jù) n在測試之后，質(zhì)量/進(jìn)度監(jiān)督經(jīng)理應(yīng)帶領(lǐng)整個(gè)小組復(fù)核建立、集成測試和系統(tǒng)測試的所有缺陷。然后讓幾名工程師尋找并修正你認(rèn)為存在于系統(tǒng)中的未發(fā)現(xiàn)的缺陷。此外，用你確認(rèn)的變化更新這個(gè)過程。9.7 文檔文檔n當(dāng)情形牽涉了軟件過程許多其它的部分時(shí)，文檔是值得作為一門專門的課程的大標(biāo)題。n本章包含了有關(guān)于軟件文檔的一些要點(diǎn)，為本標(biāo)題的課本提供了參考。如果你學(xué)過科技寫作課程，現(xiàn)在是一個(gè)學(xué)以致用的好機(jī)會(huì)。如果你

18、還沒有學(xué)過那樣的課程，現(xiàn)在是開始考慮這個(gè)重要標(biāo)題的好機(jī)會(huì)。9.7 文檔文檔n在TSPi的測試階段，小組部分成員起草并復(fù)核用戶文檔，而另一部分成員進(jìn)行測試。盡管商業(yè)系統(tǒng)通常需要廣泛的包括安裝、維護(hù)、培訓(xùn)和市場需求的文檔，但在TSPi中我們僅強(qiáng)調(diào)基本的用戶文檔。n分配給測試和文檔的小組成員的比例根據(jù)產(chǎn)品的質(zhì)量和功能內(nèi)容變動(dòng)。在最初的開發(fā)周期中，最好多分配一些工程師來測試。在以后的周期中，增加分配給文檔的工程師數(shù)目。在以后的周期中，對(duì)測試開發(fā)的需求應(yīng)降低。而文檔工作量將可能隨著產(chǎn)品附加功能的增多而增加。9.7 文檔文檔9.7.1 文檔的重要性文檔的重要性n文檔是每個(gè)軟件產(chǎn)品的必需部分。在許多方面，文

19、檔比程序代碼更重要。n把一個(gè)功能文檔化的最佳時(shí)機(jī)是在設(shè)計(jì)完它之后。n如果你在完成設(shè)計(jì)之前制作了文檔，你可能要做出很多改變。n另一方面，如果你將文檔化工作推遲了太久，相對(duì)于設(shè)計(jì)思想在你的思想中還是新鮮時(shí)制作文檔而言，這個(gè)工作將用去更長的時(shí)間。n因此TSPi包含了測試階段的文檔開發(fā)工作。對(duì)于較大的系統(tǒng)，這項(xiàng)工作應(yīng)該開始得更早，并且持續(xù)到測試階段。實(shí)際上，將測試用戶文檔作為系統(tǒng)測試的一部分是個(gè)好主意。9.7 文檔文檔 9.7.2 文檔的設(shè)計(jì)文檔的設(shè)計(jì)n書寫有用的和有幫助的用戶手冊(cè)對(duì)軟件工程師是充滿了挑戰(zhàn)性的。n注意避免：你只寫了你做了什么，而沒有寫讀者需要的。9.7 文檔文檔 9.7.2 文檔的設(shè)計(jì)

20、文檔的設(shè)計(jì)n決定手冊(cè)質(zhì)量的有用向?qū)强磧?nèi)容表。n如果手冊(cè)是圍繞著產(chǎn)品設(shè)計(jì)而組織，這本手冊(cè)是一本差的文檔。n一本精心設(shè)計(jì)的手冊(cè)應(yīng)關(guān)注讀者的需求，而不是產(chǎn)品的結(jié)構(gòu)。n通常，第一部分應(yīng)該強(qiáng)調(diào)用戶首先需要知道的：如何啟動(dòng)。然后，你可以解釋用戶功使用這個(gè)產(chǎn)品能做什么。最后，使人們?nèi)菀撞檎宜麄兯胫赖摹?9.7 文檔文檔 9.7.2 文檔的設(shè)計(jì)文檔的設(shè)計(jì)n以下是一些建議：n使用詞匯表來定義不在標(biāo)準(zhǔn)詞典中的條款。n包含關(guān)于缺陷消息、故障檢修步驟和恢復(fù)步驟的一節(jié)。n有一個(gè)關(guān)鍵論題的索引。n提供一個(gè)內(nèi)容的細(xì)節(jié)表。9.7 文檔文檔 9.7.3 9.7.3 文檔的提綱文檔的提綱n文檔化的第一步是制作詳細(xì)提綱，從一

21、個(gè)高層提綱入手，然后進(jìn)入細(xì)節(jié)。在開始書寫文本之前，檢查提綱來確認(rèn)它包含用于建立所有關(guān)鍵的用戶腳本。唯一的例外是那些在隨后的開發(fā)周期中將要改變的腳本，現(xiàn)在描述它們可能是時(shí)間的浪費(fèi)。n當(dāng)你完成了提綱之后，和制作測試計(jì)劃的工程師一起復(fù)核它，以確信你們以同樣的方式理解同一個(gè)功能，而且沒有人漏掉重要的東西。這種簡單的檢查常能發(fā)現(xiàn)群體本身不能發(fā)現(xiàn)的系統(tǒng)缺陷。文檔和測試計(jì)劃與設(shè)計(jì)所有使用的視角是不同的。實(shí)際上，小組常在文檔和測試計(jì)劃時(shí)比測試時(shí)發(fā)現(xiàn)更多的缺陷。9.7 文檔文檔 9.7.4 9.7.4 書寫風(fēng)格書寫風(fēng)格n通常：n應(yīng)書寫短句，n使用易懂的詞和短語，n以及大量的清單和標(biāo)準(zhǔn)的條款。 9.7 文檔文檔

22、9.7.4 9.7.4 書寫風(fēng)格書寫風(fēng)格n例如，當(dāng)解釋一個(gè)類似于在TEST1草案中測試開發(fā)的一個(gè)程序時(shí)，應(yīng)如下書寫。測試開發(fā) 開發(fā)經(jīng)理或其他人領(lǐng)導(dǎo)測試開發(fā)。測試小組成員執(zhí)行他們的測試開發(fā)任務(wù)。 他們將測試開發(fā)任務(wù)分配給測試小組。 定義任何需要的建立的過程和程序。 開發(fā)集成測試程序和設(shè)施。 開發(fā)系統(tǒng)測試程序和設(shè)施。 估量每個(gè)測試的大小和運(yùn)行時(shí)間。 復(fù)核測試材料和糾正缺陷。 9.7 文檔文檔 9.7.4 9.7.4 書寫風(fēng)格書寫風(fēng)格n避免以如下的段落形式書寫清單。n開發(fā)經(jīng)理或其替代者領(lǐng)導(dǎo)測試開發(fā)。測試小組的成員進(jìn)行他們的測試開發(fā)計(jì)劃。他們將測試開發(fā)任務(wù)分配給測試小組成員，定義任何需要的建立過程和程

23、序，開發(fā)集成測試程序和設(shè)施，開發(fā)系統(tǒng)測試程序和設(shè)施，對(duì)每個(gè)測試估量大小和運(yùn)行時(shí)間，復(fù)核測試材料，還要修改缺陷。 9.7 文檔文檔 9.7.4 9.7.4 書寫風(fēng)格書寫風(fēng)格n文檔質(zhì)量文檔必須是可讀懂的文檔，能夠容易理解。若不是則必須重寫。9.7 文檔文檔 9.7.5 文檔的復(fù)核文檔的復(fù)核n在復(fù)核中應(yīng)檢查的條款如下：n文檔的組織：文檔的組織：文檔是圍繞用戶將做什么還是圍繞產(chǎn)品內(nèi)容而組織？用戶文檔強(qiáng)調(diào)用戶的需要，而不應(yīng)該是產(chǎn)品的結(jié)構(gòu)或內(nèi)容。n文檔術(shù)語：文檔術(shù)語：文檔是否假定用戶具有相關(guān)的知識(shí)？軟件工程師常使用專業(yè)術(shù)語，即便作品是面向于不懂專業(yè)術(shù)語的人。任何在數(shù)據(jù)詞典沒有的詞都應(yīng)該被定義。n文檔內(nèi)容：

24、文檔內(nèi)容：文檔是否包含了所有需要的材料？n準(zhǔn)確性：準(zhǔn)確性：方法和程序?qū)嶋H是否如所描述的那樣有用？n可讀性：可讀性：文檔是否易于閱讀？大聲地讀它，看讀所寫的內(nèi)容時(shí)是否感到舒適？n易懂性：易懂性：非專業(yè)的人是否能理解？這個(gè)問題通常是最難以回答的。最好的測試是招募一些先前不了解這個(gè)系統(tǒng)的人，要求他（或她）遵循用戶手冊(cè)來使用系統(tǒng)，然后觀察你的主題的反應(yīng)，記錄下問題，對(duì)文檔重新返工來強(qiáng)調(diào)這些問題。9.8 TSPi測試草案測試草案9.8.1 開始條件開始條件9.8 TSPi測試草案測試草案9.8.2 測試的開發(fā)測試的開發(fā)n在測試開發(fā)期間制作的幾個(gè)條款。n（1）建立完整性測試。集成測試的第一步是檢查系統(tǒng)是否

25、被建立，所有計(jì)劃的部件是否被包含。把這個(gè)測試當(dāng)作一個(gè)點(diǎn)名式的測試，測試是為了驗(yàn)證每個(gè)部件是否存在。應(yīng)把這做成一個(gè)盡可能簡單的測試包。對(duì)于小的系統(tǒng)，它甚至可能是一個(gè)人工程序。9.8 TSPi測試草案測試草案9.8.2 測試的開發(fā)測試的開發(fā)n在測試開發(fā)期間制作的幾個(gè)條款。n（2）測試在正常和錯(cuò)誤條件下的所有界面的集成程序。這些測試驗(yàn)證了建立是否產(chǎn)生了準(zhǔn)備好系統(tǒng)測試的系統(tǒng)。從建立的完整性測試中，你知道了所有的部件是否被展示了?，F(xiàn)在你要確信這個(gè)己建立的系統(tǒng)能夠啟動(dòng)、運(yùn)行，而且所有的部件能夠調(diào)用其它部件，所有的系統(tǒng)界面是適配的，起作用的。這不是一個(gè)廣泛的測試，它僅演示界面的匹配和功能的適當(dāng)。9.8 TS

26、Pi測試草案測試草案9.8.2 測試的開發(fā)測試的開發(fā)n在測試開發(fā)期間制作的幾個(gè)條款。n（3）集成測試材料。即使每一個(gè)測試都是簡單的，但界面測試要求準(zhǔn)備。因?yàn)槟悴坏貌辉趶V泛的條件和參數(shù)值下測試許多界面，因此你可能想要一個(gè)簡單的自動(dòng)程序來進(jìn)行測試，指示它們是否成功地結(jié)束。但對(duì)于小系統(tǒng)，手動(dòng)驅(qū)動(dòng)的界面測試就足夠了。9.8 TSPi測試草案測試草案9.8.2 測試的開發(fā)測試的開發(fā)n在測試開發(fā)期間制作的幾個(gè)條款。n（4）系統(tǒng)測試材料。這些材料應(yīng)該測試在正常情況和系統(tǒng)資源緊張時(shí)所有的系統(tǒng)功能。它們還應(yīng)該檢查：在安裝、升級(jí)、操作或恢復(fù)期間如何使用系統(tǒng)。系統(tǒng)測試還應(yīng)該考慮可用性，執(zhí)行，日期異常，以及數(shù)學(xué)糾正和

27、精度。因?yàn)檫@個(gè)產(chǎn)品的建立經(jīng)過了幾個(gè)周期，所以如果可能，你應(yīng)該在第一周期就指導(dǎo)可用性和性能測試。在產(chǎn)品剛被建立之后修正性能和可用性問題是困難的。如果主要的變化被需要，它們必須在下一個(gè)開發(fā)周期得到最高優(yōu)先權(quán)。9.8 TSPi測試草案測試草案9.8.2 測試的開發(fā)測試的開發(fā)n在測試開發(fā)期間制作的幾個(gè)條款。n（5）每個(gè)測試期望結(jié)果的清楚說明。如果可能，使系統(tǒng)測試材料自包含。正如以前所標(biāo)注的一樣，不管結(jié)果是否正確，一個(gè)自包含的測試事件應(yīng)列出實(shí)際結(jié)果。當(dāng)你運(yùn)行一大群測試時(shí)，這種能力允許你快速地檢查那里是否有問題。使測試自包含可能要求額外的工作，但這常是一種好的投資，特別是對(duì)于你希望使用在下一個(gè)回歸測試系統(tǒng)

28、建立中的測試。但如果你沒有一個(gè)廣泛的測試工具，提供自檢能力的額外努力可能是不值得的。9.8 TSPi測試草案測試草案9.8.3 建立建立n建立的步驟：n（1）檢查所有需要的部件以確保手邊有它們，還要滿足它們的依賴性需要。此處，部件依賴性是在基準(zhǔn)系統(tǒng)中要求有用來支持部件的功能。例如數(shù)據(jù)庫，缺陷處理能力以及設(shè)計(jì)支持在部件需要的功能得不到時(shí)，就需要專門的測試驅(qū)動(dòng)或存根：檢查它們是不是己計(jì)劃了并可獲得。這里可能也有其它的依賴性，諸如缺陷修補(bǔ)。例如因?yàn)榻缑驽e(cuò)誤，一個(gè)部件在先前的開發(fā)周期中被遺漏了。應(yīng)檢查那樣的缺陷是否己被修正。9.8 TSPi測試草案測試草案9.8.3 建立建立n建立的步驟：n（2）復(fù)核

29、用于建立和確認(rèn)遺漏部分的條款。確信系統(tǒng)在缺乏這些部分時(shí)仍能建立起來，還要確信這些需要在集成計(jì)劃和測試開發(fā)期間同樣被提出了。n（3）檢查提議的對(duì)一致性和完整性的建立。這是最后一次對(duì)每個(gè)人工作的文件檢查，以確認(rèn)所有要求的部分都被包含，以及這些部件的建立是完全適合于集成測試的。n（4）建立產(chǎn)品。對(duì)于小的產(chǎn)品，這是由編譯和鏈結(jié)系統(tǒng)部件，在測試日志（LOGTEST）中記錄時(shí)間和在產(chǎn)品所有者的LOGD表中記錄問題這些步驟構(gòu)成。9.8 TSPi測試草案測試草案9.8.3 建立建立n如果缺陷在建立期間被發(fā)現(xiàn)，要決定是繼續(xù)建立還是將一些部件返回給開發(fā)者修改。在LOGD表上報(bào)告缺陷，并要求質(zhì)量/進(jìn)度監(jiān)督經(jīng)理幫助你決定走那條路。如果修改能快速完成，你可以來重建。否則，你可能不得重新安排建立。9.8 TSPi測試草案測試草案9.8.4 集成集成n集成任務(wù)有以下幾種。n檢查已建立產(chǎn)品的完整性，對(duì)建立運(yùn)行完整性檢查，以檢驗(yàn)所有這些需要的部分是否存在于建立中。n運(yùn)行集成測試。運(yùn)行計(jì)劃的集成測試。n 對(duì)于這些測試