第8章-軟件BUG和管理

第八章軟件BUG和管理[本章要點]１.軟件Bug對軟件質(zhì)量的影響；２.常見的軟件Bug類型，重現(xiàn)軟件Bug的分析技術(shù)；３.軟件Bug的描述和管理。[本章目標(biāo)]了解軟件BUG的影響和產(chǎn)生；掌握軟件開發(fā)過程中產(chǎn)生的BUG種類；掌握使BUG重現(xiàn)的技術(shù)；了解軟件BUG報告單應(yīng)該包括的主要內(nèi)容以及軟件BUG的管理流程。8.1軟件BUG概述在IEEE1983ofIEEEStandard729中對軟件缺陷下了一個標(biāo)準(zhǔn)的定義：（1）從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過程中所存在的錯誤、毛病等各種問題；（2）從外部看，軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。軟件缺陷有很多種，其中主要軟件缺陷類型有：

1.一些功能、特性沒有實現(xiàn)或只實現(xiàn)了一部分；2.軟件設(shè)計不合理，存在缺陷。實際運(yùn)行結(jié)果和預(yù)期結(jié)果不一致；3.運(yùn)行出錯，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂4.數(shù)據(jù)結(jié)果不正確、精度不夠；5.用戶不能接受的其他問題，如存取時間過長、界面不美觀。

8.1.1BUG的影響

Bug會給用戶或使用者帶來相當(dāng)大的麻煩，會給集體或者國家?guī)砗艽蟮慕?jīng)濟(jì)損失。如：千年蟲問題。8.1.2BUG的產(chǎn)生BUG的由來。對于軟件而言，BUG是程序編寫錯誤而導(dǎo)致軟件產(chǎn)生問題的缺陷。

軟件測試的目的就是找到軟件程序代碼內(nèi)的BUG，糾正它，叫做DEBUG。BUG產(chǎn)生的原因很多，具體有以下幾點。1．程序編寫錯誤

Bug的難以避免性。

2．需求變更過于頻繁

需求變更所造成的結(jié)果就是變更程序代碼，程序代碼只要稍做變更就必須經(jīng)過測試來確保運(yùn)行正常，所以這個影響是一個連鎖反應(yīng)或稱為依存問題。

3．軟件的復(fù)雜度圖形用戶界面（GUI）、B\S結(jié)構(gòu)、面向?qū)ο笤O(shè)計、分布式運(yùn)算、底層通信協(xié)議、超大型關(guān)系型數(shù)據(jù)庫以及龐大的系統(tǒng)規(guī)模，都體現(xiàn)了軟件復(fù)雜度大大高于以前，Bug出現(xiàn)可能性就更高。

4．交流不充分或者溝通出問題大部分項目人員在同客戶進(jìn)行交流時常常存在著各種各樣的問題，究其原因，還是因為項目人員、參與人員和客戶之間沒有詳細(xì)、充分、謹(jǐn)慎地進(jìn)行交流。

5．測試人員的經(jīng)驗與技巧不足6．時間過于緊迫7．缺乏文檔：貧乏或者差勁的文檔使得代碼維護(hù)和修改變得非常困難，結(jié)果會導(dǎo)致其他開發(fā)人員或客戶有許多錯誤的理解。8．管理上的缺陷8.2BUG的種類BUG是軟件“與生俱來”的特征，不同的軟件開發(fā)階段會產(chǎn)生不同的BUG，而不同的BUG又會產(chǎn)生不同的后果，因此BUG的屬性也并非相同。8.2.1需求階段的BUG

這個階段的BUG是最難發(fā)現(xiàn)、最難修復(fù)的，而且值得注意的是需求階段的BUG如果沒有及時發(fā)現(xiàn)等到實現(xiàn)階段發(fā)現(xiàn)時，那么修復(fù)它的費(fèi)用要比當(dāng)初修復(fù)它要高15~75倍。主要的原因如下：1、模糊、不清晰的需求；2、被忽略的需求；3、相互沖突的需求；

8.2.2分析設(shè)計階段的BUG

設(shè)計中的BUG比需求階段產(chǎn)生的BUG特征明顯易于捕獲，但是其維修代價很高，原因是設(shè)計BUG已經(jīng)作為一個整體影響著整個系統(tǒng)的實現(xiàn)。原因主要有3種途徑。

1、忽略設(shè)計；

2、混亂的設(shè)計；

3、模糊的設(shè)計；

8.2.3實現(xiàn)階段的BUG就是軟件系統(tǒng)中最普通、最一般的“常規(guī)BUG”?？梢詫崿F(xiàn)階段出現(xiàn)的BUG分為下面幾類：

1、消息錯誤

2、用戶界面錯誤

3、遺漏的功能

4、內(nèi)存溢出或者程序崩潰

5、其他實現(xiàn)錯誤第一類型說明了軟件系統(tǒng)向用戶發(fā)送了出錯的消息，可能消息是合理的或者表現(xiàn)為某種中斷機(jī)制，但是用戶認(rèn)為這是一個BUG。如下圖：第二類型就是用戶界面錯誤，可歸納為GUI錯誤。可能是由于GUI制作不標(biāo)準(zhǔn)而導(dǎo)致用戶不能正確地工作。第三種類型為遺漏的功能BUG(以輸入框輸入信息錯誤，程序拋出未異常為典型)第四種類型為內(nèi)存溢出或者程序崩潰BUG，表現(xiàn)為程序掛起、系統(tǒng)崩潰，屬于一種比較嚴(yán)重的軟件BUG類型。（詳見教材的藥房藥品進(jìn)存銷的軟件測試BUG）

8.2.4配置階段的BUG

配置階段的BUG出現(xiàn)的原因是復(fù)雜的，比較典型的是舊的代碼覆蓋了新的代碼，或者測試服務(wù)器上的代碼和實現(xiàn)人員本機(jī)最新代碼版本不一致?？赡苁菍崿F(xiàn)人員操作配置管理工具不正確引起的；還可能體現(xiàn)了測試人員或者最終用戶操作不正確。8.2.5短視將來的BUG

“千年蟲”問題就是當(dāng)初的設(shè)計人員為了節(jié)省一點硬件成本給全球造成了難以估量的損失。作者曾經(jīng)為一家大藥房開發(fā)了一套藥品管理的進(jìn)銷存軟件，由于最初的時候?qū)I(yè)務(wù)流程并不是很熟悉，所以在定義藥品編碼的時候把許多藥品的ID號定義為了整型變量（INT），開始作者認(rèn)為這些足以定義所有的藥品名稱了，沒想到一年以后，由于藥房的業(yè)務(wù)量急增，藥品的ID也就不夠了，由于整套系統(tǒng)是由PowerBuilder編寫，整型變量的最大值只有32767，因此程序經(jīng)常由于數(shù)據(jù)溢出而出現(xiàn)問題，所以作者被迫用了近一個星期的時間來修改原來的程序。

8.2.6靜態(tài)文檔的BUG

文檔BUG的定義很簡單，即說明模糊、描述不完整和過期的都屬于文檔BUG。說明模糊特指無充分的信息判斷如何正確地處理事情；描述不完整特指文檔信息不足以支持用戶完成某項工作；過期的文檔是沒有及時更新過的、錯誤的文檔。8.3.1BUG報告單的內(nèi)容

BUG報告單也叫缺陷報告單或者問題報告單。問題報告單所需的基本信息類型是大同小異的，不同的只是組織和標(biāo)志。介紹一下字段：（1）問題報告編號（2）程序名（3）版本標(biāo)識：發(fā)布號和版本號。是用來識別被測的代碼。例如：某個版本號可能是1.01m，發(fā)布號是1.01，“m”指1.01版本的第13稿。（4）報告類型：描述了發(fā)現(xiàn)的問題類型。包括：編碼錯誤、設(shè)計問題、建議、文檔、硬件、質(zhì)疑。（5）嚴(yán)重性：為問題嚴(yán)重程度評分。包含三個等級：三個等級：輕微的、嚴(yán)重的和致命的。（6）附件存有測試數(shù)據(jù)的軟盤、鍵盤捕獲記錄或一組可產(chǎn)生測試用例的宏、程序的打印輸出、內(nèi)存dump或一份注釋，里面詳細(xì)描述了你所做的操作，以及你認(rèn)為該問題很重要的原因。（7）問題概要：對問題進(jìn)行描述，有助于評審?fù)怀龅膯栴}，并找到相應(yīng)的問題報告。（8）問題能否重現(xiàn)。要多次測試看能否再次出現(xiàn)。（9）問題描述及如何重現(xiàn)。描述所有的步驟和現(xiàn)象，包括錯誤信息。一定要提交報告。（10）建議的改正措施（11）報告人（12）日期：指的是報告人員發(fā)現(xiàn)問題的日期。（13）功能域：對問題進(jìn)行大體分類。（14）承辦人（15）注釋：程序員在這里簡短地說明為什么要推遲處理，或說明是如何改正問題的。（16）狀態(tài)。三個狀態(tài)碼：開放、關(guān)閉和已解決。（17）優(yōu)先級。只由項目經(jīng)理設(shè)置。（18）處理狀態(tài)與處理版本處理狀態(tài)定義了問題的當(dāng)前狀態(tài)：<1>未解決：初始化狀態(tài)或仍有沖突狀態(tài)。<2>已改正<3>不能重現(xiàn)<4>暫緩：對存在的問題在下個版本改正。<5>符合設(shè)計<6>由報告人撤回<7>需要進(jìn)一步信息<8>不同意建議<9>重復(fù):關(guān)閉重復(fù)上報的缺陷。（19）簽名:簽署以表明已經(jīng)對改動進(jìn)行了測試，對結(jié)果表示滿意。（20）暫緩處理：對缺陷的推遲處理。

圖8-3、8-4整合起來即為一張完整的報告單。圖8-3報告單(part1)圖8-4報告單(part2)8.3.2BUG報告的特點

一份好的問題報告應(yīng)是書面的、已編號的、簡單的、易于理解的、可重現(xiàn)的、易讀的和不做判斷的。

1)書面的

一份書面的報告是必要的，供日后對修改后的程序進(jìn)行測試時使用；讓管理層、銷售人員和產(chǎn)品支持人員檢查。

2)已編號的依據(jù)惟一的編號跟蹤問題報告。3)簡單的一份報告應(yīng)只描述一個問題，不要在一份報告中記錄多個缺陷。

4)可重現(xiàn)的

一定要強(qiáng)調(diào)BUG的可重現(xiàn)性。

5)不做判斷的

對程序員的評價要三思而后行，本著合作的精神，作出合理的判斷。

8.3.3重現(xiàn)BUG的分析和方法

本節(jié)重點是報告編碼錯誤，而非報告設(shè)計問題。一、重現(xiàn)BUG的分析“可重現(xiàn)”隱含了下列定義：我們能夠描述如何讓程序進(jìn)入某個已知的狀態(tài)。任何熟悉程序的人都能夠依照我們的描述使程序進(jìn)入該狀態(tài)。從那個狀態(tài)出發(fā)，我們確定出精確的一組步驟來暴露出問題。為使報告更有效，我們應(yīng)該對問題進(jìn)一步分析，目的在于：1）找出問題最嚴(yán)重的后果。找出某個BUG導(dǎo)致的最嚴(yán)重的后果，這樣可以激發(fā)人們改正它的興趣。一個看來很輕微的問題往往更有可能被暫緩處理。例如：假設(shè)有個BUG在屏幕角落顯示了一個無用的字符，這個問題很輕微，但是是可以報告的。有些時候，屏幕上顯示出無用信息只是一個孤立的問題（因此對它置之不理的決定可能是明智的，尤其是程序快要交付的時候）。但是如果繼續(xù)運(yùn)行這個程序，可能會出現(xiàn)一旦顯示無用

信息之后，程序幾乎會馬上崩潰----最嚴(yán)重的后果。2）找出最簡單、最直接和最常見的BUG觸發(fā)條件。如果理解和改正問題僅需要很小的工作量，那么就會修復(fù)它。如果問題的解決需要（或看起來需要）很長的時間和精力，程序員會不太情愿改正它。如果問題會在程序日常使用的過程中發(fā)生，管理層對問題的關(guān)注會增加。如果問題的出現(xiàn)幾乎無人知曉，關(guān)注程度會很低。3）找出產(chǎn)生相同問題的其他路徑。有時不止一種方法可以觸發(fā)一個錯誤，若有兩條不同的路徑通往同一個BUG，比起僅有一條路徑來勢更有力的危險信號。即使每條路徑都包含著很復(fù)雜的步驟序列，存在兩條路徑也意味著代碼中含有嚴(yán)重的錯誤。要充分展示各條路徑的差異，不能讓程序員把多條路徑視為對同一個BUG的相似描述。4）找出相關(guān)的問題。根據(jù)積累的經(jīng)驗，仿照以前發(fā)現(xiàn)BUG的方法，查找程序中其他可能的位置，能有相當(dāng)?shù)臋C(jī)會在新的代碼中找出類似的問題。二、可重現(xiàn)BUG的分析技術(shù)

1）尋找最關(guān)鍵的步驟根據(jù)BUG查找代碼中的錯誤，不要忽略任何細(xì)微的有關(guān)錯誤的線索。應(yīng)該查找下列的問題：

1.錯誤信息；

2.處理延時；

3.屏幕閃爍；

4.光標(biāo)跳躍；

5.文本錯誤；

6.工作指示燈在設(shè)備未使用時亮起。

2）最大程度地提高程序運(yùn)行的可見性將程序運(yùn)行的越多方面變的可見，就越能看到更多的出錯情況，也就越有可能明確關(guān)鍵的步驟。用調(diào)試工具可以報告出當(dāng)前活動的進(jìn)程、程序占用的內(nèi)存或其他資源的數(shù)量、正在使用的堆棧的數(shù)量以及其他的內(nèi)部信息。

1.監(jiān)測堆棧中的遺留數(shù)據(jù)的多少

2.監(jiān)側(cè)進(jìn)程的收發(fā)消息，內(nèi)存的占用情況。另一條途徑是將屏幕顯示的所有內(nèi)容和磁盤文件的所有變更統(tǒng)統(tǒng)都打印出來，然后進(jìn)行分析。3）多嘗試一些結(jié)果將程序的事件進(jìn)行組合的執(zhí)行。4）查找后續(xù)錯誤一旦發(fā)現(xiàn)了某個錯誤，也應(yīng)該再堅持運(yùn)行程序一段時間，看看是否會有其他的錯誤出現(xiàn)。我們要認(rèn)真細(xì)致地做這件事，最初出現(xiàn)的問題可能會誘發(fā)一系列后續(xù)問題。5）漸進(jìn)地省略或改變步驟問題復(fù)雜的時候可以跳過一些步驟，但對每個要省略的步驟進(jìn)行測試，看看它是否是重現(xiàn)BUG的必要環(huán)節(jié)。

至于改變步驟，可以在每個步驟中查找是否存在邊界條件，對邊界條件的敏感程度，是一個測試人員技術(shù)成熟與否的標(biāo)志之一。

6）在程序以前的版本中查找錯誤7）查找配置依賴三、讓BUG可重現(xiàn)如何觸發(fā)BUG?將我們記得的有關(guān)第一次操作的所有事情都記下來，進(jìn)行一步一步的問題回溯。倘若沒有效果，可能是沒有滿足確切的條件，BUG沒有顯現(xiàn)出來。下面列舉了幾種應(yīng)該考慮到的情況:1）競爭條件2）被遺忘的細(xì)節(jié)3）BUG造成的影響會導(dǎo)致其無法重現(xiàn)4）BUG是依賴于內(nèi)存的5）僅會在初次運(yùn)行時出現(xiàn)的BUG6）因數(shù)據(jù)錯誤導(dǎo)致的BUG7）由于一些其他問題附帶引起的BUG8）間斷性硬件故障9）BUG依賴于時間

10）BUG依賴與資源11）BUG由長期積累形成8.3.4BUG管理流程

對BUG的跟蹤管理是測試工作的一個重要部分，測試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，因此，對BUG進(jìn)行跟蹤管理，確保每個被發(fā)現(xiàn)的缺陷都能及時得到處理。BUG管理流程是一套復(fù)雜的處理過程，涉及到測試員（復(fù)審員）、項目數(shù)據(jù)庫管理員、實施員（設(shè)計員）三方的交互，圖8-4所示的BUG管理流轉(zhuǎn)圖詳細(xì)描述了三方關(guān)聯(lián)關(guān)系（同樣適合正式技術(shù)復(fù)審問題處理流程）。圖8-4BUG管理流轉(zhuǎn)圖BUG跟蹤管理的起始動作是測試員（復(fù)審員）選擇一個測試用例開始測試，當(dāng)測試員（復(fù)審員）發(fā)現(xiàn)程序?qū)嶋H輸出值和程序期望值不符的時候，他就發(fā)現(xiàn)了一個BUG，并執(zhí)行流程第二個動作“填寫測試的實際結(jié)果”。當(dāng)測試員（復(fù)審員）向BUG跟蹤管理系統(tǒng)遞交該BUG時，系統(tǒng)將該BUG保存至“項目數(shù)據(jù)庫”中，并且同步發(fā)送一個消息至“AutoMailSend”（可以是一個程序），由它向該BUG的最終負(fù)責(zé)者實施員（設(shè)計員）發(fā)送一份“ErrorReport”。實施員（設(shè)計員）會及時接受到這樣的BUG報告，并且根據(jù)報告中包含的BUG唯一序號向“項目數(shù)據(jù)庫”查詢該BUG的詳細(xì)信息。當(dāng)實施員（設(shè)計員）對BUG跟蹤的修復(fù)動作完成后，就會在“項目數(shù)據(jù)庫”中將該BUG的狀態(tài)轉(zhuǎn)換為“Fixed”，BUG跟蹤管理系統(tǒng)接收到這樣的“UpData”動作，就會自動向BUG的測試員（復(fù)審員）發(fā)送BUG已經(jīng)修復(fù)的消息，測試員（復(fù)審員）對BUG進(jìn)行確認(rèn)測試，如果該BUG正確修復(fù)則關(guān)閉它，如果該BUG依然存在問題，整個動作回復(fù)到BUG跟蹤管理的起始處。1、如何提交系統(tǒng)中的BUG不要在同一封郵件或者同一個錯誤輸入框中報告多個（尤其在不同軟件包之中的）錯誤。2、使用自動BUG報告工具使用成熟的BUG管理工具實現(xiàn)BUG全程管理，可以有效避免被大量的測試數(shù)據(jù)所淹沒而引發(fā)一系列問題。有如下一些優(yōu)點：①BUG管理工具安裝簡單、運(yùn)行方便、管理安全。②BUG管理工具有利于BUG的清楚傳遞，由于使用了后臺數(shù)據(jù)庫進(jìn)行管理，提供全面詳盡的報告輸入項，可產(chǎn)生標(biāo)準(zhǔn)化的BUG報告。

③BUG管理工具提供大量的分析選項和強(qiáng)大的查詢匹配能力，能根據(jù)各種條件組合進(jìn)行BUG統(tǒng)計。當(dāng)BUG在它的生命周期中變化時，開發(fā)人員、測試人員、及項目管理人員將及時獲得動態(tài)的變化信息。④BUG管理人員允許你獲取BUG歷史記錄，并在檢查BUG的狀態(tài)時參考這一記錄。⑤BUG管理工具可針對軟件產(chǎn)品設(shè)定不同的模塊，并針對不同的模塊設(shè)定相關(guān)的責(zé)任人員，這樣可以實現(xiàn)提交報告時自動發(fā)給指定的責(zé)任人。⑥BUG管理工具支持權(quán)限，設(shè)定不同的用戶對BUG記錄的操作權(quán)限不同，可有效控制進(jìn)程管理。⑦BUG管理工具設(shè)定不同的BUG嚴(yán)重程度和優(yōu)先級，從最初的報告到最后的解決，確保了錯誤不會被忽略，同時可以使注意力集中在優(yōu)先級和嚴(yán)重程度高的錯誤上。⑧BUG管理工具自動發(fā)送郵件通知相關(guān)責(zé)任人員，并且根據(jù)設(shè)定的不同責(zé)任人，自動發(fā)送最新的BUG動態(tài)信息，有效地幫助測試人員和開發(fā)人員進(jìn)行溝通。3、通過電子郵件發(fā)送BUG報告描述主題是要清楚而簡潔地描述BUG。郵件內(nèi)容第一行的格式為：Package:<something>,<something>指要報告的包含錯誤的Class包名稱。郵件內(nèi)容的第二行格式為：Version:<something>，<something>指該軟件包的版本。其他內(nèi)容應(yīng)該注意以下幾點：①確切而完整的錯誤信息（這非常重要）。②您做了或輸入了些什么，以便重現(xiàn)該問題。③錯誤行為的描述：您預(yù)期應(yīng)該有什么樣的行為，而您看到的是如何。④您建議如何改正，或甚至您自己做的修補(bǔ)程序。⑤詳細(xì)解釋您如何設(shè)置該程序，包含完整的設(shè)置文件屬性。⑥任何其他依賴于這個問題軟件包的軟件包版本。4、BUG詳細(xì)內(nèi)容信息如表8-1所示。5、輕微的BUG報告輕微的BUG報告應(yīng)該和重要的BUG報告分開發(fā)送。BUG描述信息BUG類別可追蹤BUG標(biāo)志BUG基本描述BUG所屬項目\子系統(tǒng)\模塊所屬的項目\子系統(tǒng)\模塊，最好能較精確的定位至模塊BUG標(biāo)題BUG簡明描述BUG流轉(zhuǎn)狀態(tài)BUG流轉(zhuǎn)狀態(tài)，可分為Unconfirmed、New、Assigned、Reassigned、Needinfo、Reopened、Resolved、Reopen、Verified、ClosedBUG嚴(yán)重等級BUG嚴(yán)重等級,可分為Critical、Grave、Serious、Blocker、Important、Normal、Minor、TrivialBUG解決關(guān)鍵字BUG解決關(guān)鍵字,可分為Fixed、Wontfix、Later、Remind、Duplicate、Incomplete、NotaBUG、Invalid、WorksformeBUG提交人BUG提交人的名字(郵件地址)BUG提交時間BUG提交的時間，例如2003-1-2314：00表8-1Bug詳細(xì)內(nèi)容描述(part1)BUG過程描述BUG指定解決人由測試人員確定，如果該BUG的流轉(zhuǎn)狀態(tài)從Unconfirmed&New變?yōu)锳ssignedBUG指定解決時間由測試人員確定，如果該BUG超過指定修復(fù)時間而未修復(fù)，則系統(tǒng)自動發(fā)送報警郵件。BUG處理描述如果實現(xiàn)人員對代碼進(jìn)行了修改，要求在此處體現(xiàn)出修改內(nèi)容，如果代碼行數(shù)很多則縮略書寫B(tài)UG處理時間記錄BUG處理時間BUG確認(rèn)測試人員驗證該BUG被正確的修復(fù)了BUG確認(rèn)描述BUG確認(rèn)修復(fù)內(nèi)容BUG確認(rèn)時間BUG確認(rèn)修復(fù)時間BUG詳細(xì)描述對BUG的詳細(xì)描述，對BUG描述的詳細(xì)程度直接影響實現(xiàn)人員對該BUG的修復(fù)效果，描述應(yīng)該盡可能詳細(xì)BUG環(huán)境說明對測試環(huán)境的描述，避免實現(xiàn)人員和測試人員環(huán)境的不同造成BUG異議BUG附帶附件附件包括對BUG現(xiàn)場出錯快照(圖片)，錯誤輸出文件信息等，加強(qiáng)該BUG的表現(xiàn)力表8-1Bug詳細(xì)內(nèi)容描述(part2)6、不知道歸屬的BUG設(shè)置默認(rèn)的BUG修復(fù)人員，防止意外的丟失了BUG負(fù)責(zé)人的信息。7、關(guān)閉BUG報告提出的BUG被修正后，通過測試人員確認(rèn)、測試通過才可以關(guān)閉。BUG的提出和關(guān)閉都是只能由測試人員執(zhí)行。將所有不能被修復(fù)的BUG收集起來標(biāo)記為“Wontfix”，統(tǒng)一遞交給代碼評審委員會。

8、接續(xù)的討論信息BUG的管理系統(tǒng)的流轉(zhuǎn)過程中，會有針對該BUG的新的描述信息加入，例如實現(xiàn)人員或者測試人員加上的對處理BUG自己的理解和曾經(jīng)使用過的解決方案等。對于新的描述信息，請遵循以下規(guī)則：①新的描述信息和舊的描述信息之間應(yīng)該增加醒目的隔離條。②新的信息描述應(yīng)該包括提供者的名稱和電子郵件地址。③新的描述信息應(yīng)該包括信息的新增時間。

④新的描述信息如果是建議修改意見，應(yīng)該在該信息的開頭加上關(guān)鍵字“建議解決方案”。⑤新的描述信息如果是某些疑問，應(yīng)該在該信息的