【正文】 是個簡單圖表，但要確保針對它對程序的大量區(qū)域都進行了測試，因為許多項目經(jīng)理和程序員錯誤地宣布鍵在每處都以相同的方式工作）。 ● 打印機（及其他設(shè)備）配置測試矩陣。 α 階段的測試活動 ● 輸入邊界圖表。 想要創(chuàng)建什么樣的測試記錄？想要運行什么樣的測試或者想要找到什么樣的缺陷，與任何這些記錄都不符合的那些缺陷？用附錄作為缺陷的資料來源，來檢查覆蓋率。 大多數(shù)測試團體并不希望直到 β 測試階段程序才通過驗收測試，因此他們直到 β 階段后（或者與項目經(jīng)理協(xié)商的其他日期），才會把一個沒通過測試的程序版本踢出測試之外。把該清單映射到一個時間基線上，以顯示何時這些任務(wù)會完成。 ● 對資源需求進行評審，并公布測試?yán)锍瘫? ● 開始進行第一輪設(shè)備測試。 確定并評論沒有準(zhǔn)備好進行測試的弱區(qū)。 檢查每個事實和暗示。 測試計劃初稿或者接下來不久以后開發(fā)的草稿，都應(yīng)當(dāng)交給項目經(jīng)理進行評審。 讓勞動顯而易見，讓工作效率顯而易見，而且要讓每個人都忙著改正缺陷。 在測試的第一或第二個周期中，程序可能很不穩(wěn)定，因此無法通過手冊中的很多東西。 早期測試目標(biāo)是發(fā)現(xiàn)程序的每個區(qū)域中所有容易發(fā)現(xiàn)的問題?？梢允褂迷摦a(chǎn)品，并了解其感觀，但是還有許多特征還沒有實現(xiàn)。 ● 在 α 測試階段 ，所有功能已經(jīng)完成編碼，盡管有些代碼中可能存在嚴(yán)重的缺陷。 本章我們接著講述從 α 到發(fā)布的各個階段的測試。 軟件測試項目階段 如圖是一個項目時間基線的例子，顯示了這些里程碑。 軟件測試項目階段 當(dāng)理解了項目經(jīng)理的開發(fā)權(quán)衡、公司的質(zhì)量成本權(quán)衡以及項目經(jīng)理開發(fā)模型的約束時，就會處于最佳狀態(tài)之中?？梢圆捎靡粋€現(xiàn)有的模型（如瀑布模型或演化模型），也可采用自己的模型。 此外，即使項目經(jīng)理想要使產(chǎn)品質(zhì)量最佳，他仍然要在可靠性和特征集的豐富程度之間進行權(quán)衡。 為了使投入的資金有價值，必須要提高客戶的滿意度，并增加公司的利潤。 必須理解項目經(jīng)理的模型 — 否則就會出錯，如在程序的用戶界面確定之后就安排大量可用性測試。這種理解讓你用項目經(jīng)理及其管理層可以接受的方式來說明：在項目期間，資金應(yīng)當(dāng)花費在何種類型的測試上，必須完成多少測試，以及如果項目經(jīng)理不采納你的建議，他將面對何種類型的風(fēng)險。 軟件測試項目階段 這種基于里程碑的方法很實用。 第十三章第二節(jié) α 測試階段 α測試階段 α 的定義 非常廣泛： ● 在 α 里程碑中 ，大部分功能已經(jīng)存在，但有少數(shù)功能遺漏或者不可測試。所有類型的設(shè)備都能工作（如打印機可以工作），但是每種類型可能只有少數(shù)設(shè)備能運轉(zhuǎn)。 α 階段的測試活動 在許多公司中，測試在 α 階段開始。測試持續(xù)是廣泛的、表面的主流測試。但最終會完成所有內(nèi)容的。 ● 了解產(chǎn)品。不要被說服，把測試計劃和測試看作是各自獨立的活動。把一份做過標(biāo)記的副本返回給編寫人員。 ● 估計程序可能的可靠性。 到 α 末期，應(yīng)當(dāng)至少完成一次完全通過的設(shè)備（所有打印機、調(diào)制解調(diào)器等）測試。 仔細列出測試任務(wù)，并估計有多少人，每個人會花費多長時間。這一清單是測試人員和項目經(jīng)理用來對照測試進度對測試進展進行評審的工具?？梢栽缧┕荚摐y試，但不要早早地就執(zhí)行。這個清單可以幫助測試人員達到一個關(guān)鍵的早期目標(biāo)。 ● 輸出邊界圖表。 ● 跨測試版本并針對競爭產(chǎn)品的性能測試基準(zhǔn)。 α 階段的測試活動 ● 發(fā)現(xiàn)競爭條件以及有關(guān)消息、共享數(shù)據(jù)、中斷和其他耍點等在程序的一個簡單線性分析中不會出現(xiàn)的問題的策略。但是當(dāng)收集數(shù)據(jù)時要保留它，遲早派得上用場。 再次提醒 ，不要嘗試一次進行所有這些任務(wù)。另一方面，在進展過程中，切實對這些材料進行改進。花在重新執(zhí)行舊測試上的時間越少，就會獲得越多的時間來創(chuàng)建新的測試。不要在每次使用時，都強迫自己指出一個給定的文件包含什么內(nèi)容。 把這些可用資源分為兩組。 開始準(zhǔn)備會用來測試每臺打印機的一個標(biāo)準(zhǔn)的輸入文件組。 列出將要對程序進行測試的環(huán)境。 如果每次程序接受測試時的確想要運行一個簡短的標(biāo)準(zhǔn)測試系列，而且一旦它在該測試系列上失敗，就把這一版本踢出測試，那就要運行這些測試很多很多次。 α 階段的測試活動 自動化方面存在一個困難的權(quán)衡。 ● 應(yīng)當(dāng)較早進行自動化，因為在缺陷發(fā)現(xiàn)的巔峰時期較晚進行自動化會降低測試生產(chǎn)率。 ● 不應(yīng)該過早進行自動化，因為它會引起行政問題。 測試的深度與廣度 在每個測試周期中，了解 測試的深度和廣度之間的權(quán)衡 是至關(guān)重要的。可能會集中于 某一類問題、某個特征、某個模塊、某個功能、某個菜單或其他什么 。 例如 ，當(dāng)集中于配置問題時，嘗試設(shè)想操作軟件可能影響到的程序的每個方面。 例如 ，可以對顯示或打印圖形的例程中的每個可能故障都進行測試。 下面我們將作具體說明： 測試的深度與廣度 1． 主流測試： 相對溫和的測試 ， 它詢問程序在 “ 正常 ” 使用下進展如何 。 在每個測試周期中 對程序的每個區(qū)域 進行測試。 測試的深度與廣度 2． 突擊測試： 能快速想到的一個簡短的最嚴(yán)重的測試系列。 接著，當(dāng)了解了 邊界值 ，就可以使用它們了。嘗試找到最壞的問題，并在詳細測試開始之前引發(fā)主要的重新設(shè)計。 ● 早些開始改正問題。它們比更集中的測試要快得多，因此能在該級別測試程序的更多區(qū)域。這將會是一個逐步的過渡過程。 ● 錯誤最明顯的區(qū)域。 ● 最理解的區(qū)域。盡可能使用看起來合理的時間進行規(guī)劃、建檔以及執(zhí)行計劃好的測試。 理想的測試系列在一個最小的時間量內(nèi)檢查關(guān)注區(qū)域的每個方面 。 它還應(yīng)當(dāng)盡可能多地覆蓋該區(qū)域的許多方面（子功能、邊界條件等），使用盡可能少的測試和執(zhí)行時間。 考慮構(gòu)建自己的回歸測試系列，以便每有一個新的版本時運行一些測試；有時每隔兩到三個版本運行一些測試，有時則頻率更低。 ? 在許多公司中，程序員認為某個產(chǎn)品的一個新版本會通過一個完整測試周期，這才提交其進行測試。有些編程團隊會嘗試每天測試一個新版本，并提出論點，有些甚至拒絕閱讀在舊版本中發(fā)現(xiàn)缺陷的新報告。在最初的幾個測試周期中，這很容易，但是一旦有了一大組的回歸測試要做，就很難把 25%的時間分配給新的測試。 ? 有些公司把 α測試階段和預(yù) β測試階段按順序進行排列，并稱其為“ β提交階段 ” 。 ? 在其他公司中，預(yù) β評審沒有公開查看，不過卻是在 α測試的最后幾星期中完成的。 例 ： ● 在 β 階段，程序已經(jīng)準(zhǔn)備好交給 β 測試人員，就是那些會使用該產(chǎn)品并告之他們的經(jīng)驗的人。 要注意到， 在某些開發(fā)模型下，到 α 階段為止，所有特征代碼都已實現(xiàn)，但在其他一些開發(fā)模型下，有些特征可能仍然沒有用代碼加以實現(xiàn)。在這一定義中，許多特征已經(jīng)增加到其中，再沒什么對程序的可推銷性必不可少的其他特征，極少數(shù)其他特征可能要增加進去，而且沒有哪個特征不能被輕易收回的。項目經(jīng)理會在正確的光盤上提交所有文件及其版本信息，包括那些按照正確的格式壓縮或非壓縮的、名稱未定的空白虛擬文件。要確保在其覆蓋范圍或適當(dāng)性方面沒有任何遺留的爭議。如果是在測試一個字處理軟件或桌面排版軟件，就用它寫備忘錄，并設(shè)計報告版面。真實用途測試會揭露許多神秘逃脫了其他類型測試的錯誤，并且它還會在一個強制性環(huán)境 — 產(chǎn)品的正常使用中，揭露這些錯誤。 ● 分析、重新測試以及重新提交那些仍然沒有得到改正的、很難再現(xiàn)的缺陷。把回歸測試測試安排和文檔編制留給其他人來完成。 還要在極少時間內(nèi)努力告訴程序員，每個改正是否起作用。 ● 繼續(xù)自動化某些測試， 即使自動化可能不再節(jié)約。要確保每個測試都值得花那么多時間來處理。這個結(jié)果告訴你測試這些文件的一個周期所需的時間還必須估計重新測試修訂文件所需的時間。 不要不經(jīng)過進一步說明就宣布開放的報告以及最近報告的問題的數(shù)量多有意義而且多重要。 一個編寫了大量報告來從本質(zhì)上說明“這一 Amiga程序應(yīng)當(dāng)遵循 Macintosh用戶界面規(guī)則”的新測試人員正在浪費最后一分鐘的寶貴時間。稍后可能每隔幾天就要舉行一次。 如果不把握機會在確定之前提出問題，那么在確定之后，就無權(quán)請求對設(shè)計決議重新進行考慮了。 ● 尋找沒有進行解釋，或者解釋得不夠清楚，或者在細節(jié)上不夠清楚的特征。每周檢查進度。那么程序還沒有準(zhǔn)備好提交的部分原因就是花了太長時間來查找缺陷。如何再現(xiàn)問題時存在一個新近的延遲，那也是測試人員的錯，因此不得不拿出所有時間來改正它并重新測試。 ? 可能會在預(yù)最終測試階段發(fā)現(xiàn)少數(shù)較嚴(yán)重的缺陷。 ● 確保新的缺陷改正不會破壞任何東西。 現(xiàn)在是確保每個關(guān)鍵任務(wù)都已經(jīng)在項目的某些點上得到運行的最后機會了。相反地，除了不可暫緩的某個缺陷報告必須的變更以外，程序已經(jīng)完成。這一過程在每發(fā)現(xiàn)一個新的不可推遲的問題時就會 重復(fù)。 如果有時間，在看來可能是最后一個測試周期中，恢復(fù)某些已存檔的測試。 開發(fā)小組（或高級管理人員，或任何出席缺陷評審會議的人）以前曾對所有這些缺陷進行過評價，因而此次最后評審是形式上的，但是總得給管理人員一個最后的機會，讓他們在發(fā)布之前重新考慮產(chǎn)品的質(zhì)量。 產(chǎn)品的設(shè)計、功能、可用性及可靠性都是產(chǎn)品質(zhì)量的因素。 預(yù)最終測試階段 ?如果客戶在產(chǎn)品中一個缺陷都找不到，其可靠性就很高。 預(yù)最終測試階段 ● 低可靠性：產(chǎn)品中存在客戶可能會發(fā)現(xiàn)的嚴(yán)重缺陷。 可能遺漏了少數(shù)問題但是認為不會有很多客戶發(fā)現(xiàn)它們。 公司不會將未滿足其最低可靠性標(biāo)準(zhǔn)的產(chǎn)品發(fā)布 。 ● 手冊的最終版本已經(jīng)進行了整理。 程序與假定要一同工作的最常見的硬件和系統(tǒng)軟件一起工作。 如果說產(chǎn)品沒有達到這些標(biāo)準(zhǔn)之一，公司就不會把產(chǎn)品發(fā)布。 預(yù)最終測試階段 2． 產(chǎn)品每個區(qū)域的可靠性估計 。 ? 如果估計某個區(qū)域的可靠性低，那就列出導(dǎo)致這一結(jié)論的每個問題。給出你可能發(fā)現(xiàn)的缺陷的例子。 預(yù)最終測試階段 3． 最終決議 。對不同應(yīng)用程序和價格范圍來說，回答是不同的。他們了解項目小組的薪水。 ? 提交產(chǎn)品的最終決議屬于 管理層 ，而不是 測試人員 。 最終完整性測試 另外一些公司在制作母盤之前要進行最后一批測試。 按照典型客戶會在第一天使用該產(chǎn)品的方式來使用產(chǎn)品。 測試人員依照他認為典型購買者和評審人員（而非典型測試人員）會做的事情來進行測試。 ? 完整性測試一旦完成（如果存在完整性測試的話），就是制作母盤并對其進行檢查的時候了。每片光盤上的剩余空間數(shù)量也進行了檢查。 最終完整性測試 發(fā)布過程的 其他部分 包括： ● 光盤病毒檢查。 ● 當(dāng)前幾套光盤從復(fù)制機返回時（在大量生產(chǎn)之前會制作少數(shù)幾套光盤），把它們與送到復(fù)制機的母盤相比較。 第十三章第六節(jié) 發(fā) 布 發(fā) 布 復(fù)制機正確地復(fù)制母盤，現(xiàn)在大量對其進行復(fù)制。 公司可能計劃立刻進行一個維護版本的發(fā)行。 在測試同時，花大量時間來進行整理。 測試人員的目標(biāo)是使下個版本的測試更容易，而且要比這一版本更有效。 ?美國 Gartner Group公司在 2022年發(fā)表了有關(guān) IT項目的調(diào)查結(jié)果，該調(diào)查把項目失敗的原因總結(jié)為 四大類 。 ? ERP項目組成員一般都是 跨組織 的，項目組中既有實施