第一篇：代碼工作年終總結

2012年組織機構代碼工作總結

及2013年工作打算

一、2012年工作總結

（一）積極做好代碼工作

為促進代碼技術的應用，我們努力做好代碼證書的辦理和發放工作，并采取了如下三項措施促進代碼的普用。一是對辦理代碼證書的單位和人員做到熱情周到的服務。二是簡化辦事程序，提供方便快捷的辦證服務。三是積極做好代碼證書的新辦、換證和年檢工作，全年新辦證794家，換證333家，年檢332家，免費辦理微型企業324家，在規定的時間內按時上報電子檔案數據，保證電子檔案掃描工作100%完成且資料齊全，嚴格按照《貴州省組織機構代碼檔案管理辦法》，做好原始檔案的收集、存儲、管理、切實做到紙質檔案不缺失，保證紙質檔案的完整性。

（二）加強內部管理，提高辦證的服務質量

對一些填表有困難的人，我們總是熱忱服務，耐心指導，或者主動幫助填表，既方便了企業，也在辦證第一步把住數據質量關。在代碼辦理中，保證重點項目特事特辦，隨到隨辦，立等可取。

（三）加強與相關部門的協調溝通，提高代碼的應用性

與當地稅務部門聯系和溝通，采取有效措施協助當地稅務部門檢驗、核實組織機構代碼證書的真實性、有效性。

二、2013年工作打算

2013年又將是一個任務繁重年，我們會在省代碼中心及各級領導的關懷領導下，為代碼事業的持續發展更加努力的工作。

（一）拓展思路，想方設法過一步開展新辦證、換證、驗證的各項工作，以求能完成省中心下達的指標任務。

（二）繼續做好電子檔案的掃描錄入工作。

（三）對沉淀數據分類、分塊進行摸底，并對這些數據進行處理。

第二篇：銀行機構信用代碼工作總結[推薦]

XXXX銀行關于

機構信用代碼證推廣應用工作情況報告

人民銀行XX支行：

根據人民銀行XX支行關于開展機構信用代碼證推廣應用工作的要求及相關工作安排，自2012年6月1日啟動機構信用代碼證發放工作以來，我行積極組織，采取先易后難的方式，對比較容易接受的客戶先進行推廣，對一時難以配合的客戶，作為重點開展工作對象，通過本行與其他銀行之間的交流溝通，及時吸取機構信用代碼推廣應用工作中好的經驗，在人行的大力支持與幫助下，按照規定的工作目標順利完成了機構信用代碼證的推廣應用工作。現將我行工作匯報如下：

一、前期工作完成情況

（一）動員部署階段工作開展情況

1.加強組織領導，提高思想認識。本次機構信用代碼工作由總行統一部署實施，成立了XX銀行行長為組長，主管行長為副組長及各相關部門負責人為成員的機構信用代碼工作領導小組。同時各分支行也按照總行要求成立了相應的工作領導小組。全行上下聯動，扎實工作，確保“組織保障到位、溝通反饋到位、宣傳解釋到位、信息采集到位、代碼發放到位、反洗錢應用到位”等六個到位，做到高效推進，順利完成機構信用代碼推廣應用工作。

2.明確思路，落實措施。收到《中國人民銀行辦公廳關于

開展機構信用代碼推廣應用工作的通知》（銀發辦【2012】47號）和《中國人民銀行辦公廳關于應用機構信用代碼輔助開展客戶身份識別的通知》（銀辦發【2012】66號）文件后，我行與2012年4月25日召開動員會，主管行長在機構信用代碼推廣應用會議上特別強調，要求貫徹落實人民銀行《關于開展機構信用代碼推廣應用工作的通知》精神，安排部署全行機構信用代碼系統信息采集補充與代碼證發放工作，積極推動機構信用代碼在反洗錢、社會信用體系等領域中的應用。

3.加強培訓，規范操作為。嚴格執行人行規定，準確規范操作，組織業務人員進行信用代碼系統應用知識培訓，重點針對“機構信用代碼系統信息、代碼證發放工作業務流程及機構信用代碼反洗錢業務應用等內容分級分段開展業務培訓。確保在規定時間內完成對基本存款賬戶信息的核實、修改、補錄、生成代碼并進行代碼發放工作。

4.加強機構信用代碼的推廣和運用。我行積極提升機構信用代碼的應用水平，各分支機構發揮銀行柜面優勢，扎實做好機構信用代碼的推廣應用和宣傳引導工作。并在開展反洗錢等業務中，查詢、使用機構信用代碼系統信息，推動機構信用代碼在反洗錢、征信等社會信用體系及其他領域的廣泛應用。

（二）培訓準備階段工作開展情況

1.各分支機構信用代碼推廣應用工作的培訓情況。我行認真參加人民銀行關于機構信用代碼推廣應用培訓后，按照要求對

我行各分支機構相關人員2012年4月25日開展了機構信用代碼系統知識及操作流程的培訓。并要求各分支機構對本行所有參與機構信用代碼配發工作的業務人員、柜臺再培訓。

2.存量賬戶的確定以及機構信用代碼證發放情況。截止到2012年5月31日，我行將所有的有證基本戶進行了梳理，將長期聯系不到的賬戶加注了久懸標識工作。同時認真梳理、確定、篩選，最終確定我行實際辦理機構信用代碼證的基本存量賬戶共6434戶，2012年6月加注久懸標識賬戶共737戶。2012年6月6日成功導入人行機構信用代碼系統6431戶，手工完成了3戶代碼證的發放工作。

3.機構信用代碼系統用戶開通工作情況。根據人民銀行要求，我行及時完成網絡配置到各營業網點，對機構信用代碼系統聯通情況進行測試，確保6月1日前機構信用代碼系統的正常運行。我行共設人民銀行系統操作員用戶11個，各分支機構增設普通用戶46個，并將人員名單已上報人民銀行備案。

4.完善了信用代碼推廣應用工作方案及內控制度建設。

二、后期工作展開情況

為貫徹落實人民銀行西寧中心支行下發的關于機構信用代碼證推廣應用工作，我行高度重視此項工作，積極落實文件精神，由工作領導小組專門負責此項工作。在此基礎上，為了有條不紊的開展機構信用代碼系統信息補充與代碼證發放工作，我行積極開展再培訓工作，要求全體員工配合開展此項工作。一是認真組

織學習。通過組織基層員工學習有關文件內容，明確操作步驟，達到領會精神、抓住實質、全面籌劃的目的；二是制定合理方案。在認真學習文件內容的基礎上，結合本行實際情況，制定工作進度計劃，明確操作步驟。為穩步推進工作打下堅實基礎。三是積極溝通借鑒。在工作的開展過程中，我行積極與人行溝通，向其他行學習好的做法，想盡辦法克服工作中的困難，確保此次工作順利開展。

從2012年6月1日起，存量賬戶和增量賬戶的發放工作進入實施階段，為了進一步做好實施階段的各項工作，我行工作如下：

1.認真完成存量賬戶的發放工作，做到報多少戶完成多少戶。我行已將3000份空白《機構信用代碼證》發放至各分支機構，要求各分支機構爭取7月底超量完成存量賬戶6434戶的40%。要求各分支機構務必在2012年10月底前完成存量賬戶的100%發證率。我行已將辦證任務層層分解落實，擬定今后在全行范圍內開展辦證任務完成率排行榜活動，全行將掀起“比、學、趕、幫、超”的工作氛圍。

2.自2012年6月1日起，凡到我行辦理貸款卡申領、企業征信信息查詢、變更等征信業務的機構，均須向我行提供信用代碼證，以輔助核實機構身份。

3.加強宣傳推廣。機構信用代碼推廣工作涉及面廣、工作量大、時間緊，我行結合自身特點開展多方宣傳，主要做好以下兩 4

個方面的工作：一是積極聯系客戶，對存量基本存款賬戶用電話逐一通知客戶及時來我行辦理機構信用代碼手續；二是加強柜面宣傳，充分發揮大堂經理和前臺柜員的作用，在辦理業務時向客戶做好機構信用代碼推廣宣傳工作。通過機構信用代碼應用服務系統與其他代碼建立對應關系，實現機構信用代碼的身份識別和信息共享的橋梁作用，對于健全和完善身份識別機制、推動落實金融賬戶實名制、提高金融服務水平、促進信用信息共享和推動社會信用體系建設等具有重要意義。

4.在機構信用代碼實施期間，我行指定專人于每周五上午下班前將《機構信用代碼推廣應用情況統計表》，每月第二個工作日前將《機構信用代碼在反洗錢等領域運用情況統計表》定時報送人民銀行。

5.繼續加強業務培訓，提高操作技能。在機構信用代碼發放過程中，要求操作員認真核實、錄入信用代碼信息，確保錄入信息真實、準確、完整。為真正將該項工作落到實處，以機構信用代碼證推廣應用為主題，我行就開展機構信用代碼工作中遇到的問題，開展了3次培訓并及時下發通知及相關制度，并讓支行負責人一起參與學習，將機構信用代碼證工作流程層層落實到位，保證機構信用代碼推廣應用工作人員熟練業務流程和操作規程。并邀請人行相關人員下到一線進行指導，并及時解決存在的問題，提高我行相關人員的業務素質和操作技能。總行與人行同步多次下發細化的操作規程和定期通報及通知，加強此項工作的力

度，既提高了管理層面的思想認識和重視程度，又提高了員工的操作技能，為機構信用代碼發放工作的有序開展奠定了基礎。

三、我行發放機構信用代碼證工作完成情況

截止2012年5月31日，我行共有正常的機構存量客戶6434戶，截止2012年9月底，共配發信用代碼證6434戶。截止10月底人行系統中有久懸戶為1666戶，按貴部要求對其中符合要求逐一發證。

截止到10月底，全行行基本賬戶共開立8981戶，完成存量8330戶，增量完成642戶。較6月初上報人行久懸數1838差127戶，情況為：25戶激活均已發證；101戶為我行基本戶已銷及轉戶原因機構信用代碼證未銷。

四、機構信用代碼證應用情況

我行主要將機構信用代碼證用于輔助做好客戶身份識別，從而提高反洗錢工作效率，通過機構信用代碼證及時了解客戶信息，加強對高風險客戶及可以交易的甄別能力。具體措施及要求如下：

1.開立賬戶時，為不在本機構開立賬戶的機構客戶現金匯款、現鈔兌換等一次性金融服務切交易金額單筆人民幣1萬元以上或外幣等值1000美元以上的，要求①.核對機構信用代碼證；②等級機構信用代碼證；③.留存機構信用代碼證復印件或影印件。在于客戶的業務關系存續期間，我行采取持續的客戶身份識別措施，關注客戶及其日常經營活動，金融交易情況。及時提示客戶更新資料信息，要求①.確認留存的機構信用代碼信息有效；

②.及時提示客戶更新機構信用代碼證及信用代碼系統中的相應信息；③.在有效期內，未提交人民銀行分支確認效力的，要求客戶辦理相關效力確認手續。對機構信用代碼證的真實性，有效性，完整性存在疑點的，要求重新識別客戶身份，經采取措施仍無法排除疑點的，提交可疑交易報告。

2.推動在反洗錢工作中運用機構信用代碼。我行以客戶身份識別、客戶風險等級劃分、異常交易分析排查三個環節為重點，在反洗錢工作中全面運用機構信用代碼。具體方法包括查驗客戶機構信用代碼證、登錄機構信用代碼管理系統比對客戶身份信息、核實實際控制人信息等，必要時留存代碼證復印件及相關查詢記錄。

3.探索在銀行機構系統建設及有關業務中使用機構信用代碼。將機構信用代碼作為本行業務系統的索引碼，實現行內機構客戶信息的匹配、整合。并組織我行員工在有關日常業務中試用機構信用代碼，如支付結算業務、大額現金管理業務、電子銀行業務、貸款授信業務及征信等業務。

五、今后工作打算

我行將機構信用代碼的推廣應用作為一項重點工作，加大正確解釋和引導力度，嚴格按照人行文件的表述口徑，通過策略的方法和靈活的方式爭取客戶的理解、支持和配合，在我行實際業務中推廣應用。

1、繼續將機構信用代碼證推廣應用工作當作我行的一項重要工作來開展。結合實際工作，認真總結經驗，針對存在的問題，加強與總行、人行及客戶的溝通。

2、機構信用代碼證推廣應用工作將更加注重與實際相結合。繼續引導柜員在辦理過程中，重視該項工作，增強辦理過程中出現問題的解決能力。碰到特殊問題及時上報，聯系解決。

3、將機構信用代碼證廣泛應用，由其加強在反洗錢中運用機構信用代碼，強化反洗錢工作力度，提高反洗錢工作效率。簡化辦理存款、匯款、貸款等業務時機構身份的識別手續，提升服務效率，降低服務成本等方面多做工作。機構信用代碼證推廣應用工作必須結合實際，勇于創新。與時俱進，開拓創新，是保持機構信用代碼證推廣應用工作持續發展的不竭動力。

第三篇：部門代碼

部門代碼

總經理：GMD 行政人事部：AD 技術部：TD 發展部：RDD 宣傳部：PD 策劃部：SD 工程部：ED 造價部：EC 財務部：ACD 投融資部：FD 戰略計劃部：SPD 招標合約部：BCD 審計部：ADD 招商部：MD 研究院：RI 物業部:PD 后勤部：LD 資源管理部：RD

第四篇：代碼檢查

代碼檢查

摘要：代碼檢查是白盒測試的一種靜態測試方法，是眾多軟件測試方法中發現軟件缺陷最有效的方法之一。本文結合國內外學者在相關領域的研究情況，介紹代碼檢查相關的基本概念、過程和分析方法。

關鍵字：白盒測試，代碼檢查，靜態分析，檢查規則

一、引言

按照測試時源代碼是否可見，軟件測試可以分為白盒測試和黑盒測試兩類。

白盒測試（結構測試），即邏輯驅動的測試，是在了解程序內部結構的基礎上，對程序的邏輯結構進行檢查，從中獲取測試數據。白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構的程度。白盒測試一般只應用于軟件開發階段。

白盒測試，又可按照是否需要運行程序，進一步細分為了靜態測試和動態測試兩種。通常情況下是按照先靜態后動態測試順序來實施。其中，靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等測試內容。靜態測試既可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。

代碼檢查是一種對程序代碼進行靜態檢查。傳統的代碼檢查是通過人工閱讀代碼的方式，檢查軟件設計的正確性；用人腦模擬程序在計算機中的運行，仔細推敲、校驗和核實程序每一步的執行結果，進而判斷其執行邏輯、控制模型、算法和使用參數與數據的正確性。

在實踐中，代碼檢查比動態測試更有效率，能找到更多的缺陷，通常能發現30%～70%的邏輯設計和編碼缺陷。代碼檢查非常耗費時間，而且需要專業知識和經驗的積累。代碼檢查定位在編譯之后和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。

代碼檢查可以發現的軟件問題包括：聲明或引用錯誤、函數/方法參數錯誤、語句不可達錯誤、數組越界錯誤、控制流錯誤、界面錯誤和輸入/輸出錯誤等。

1、代碼檢查

代碼檢查包括桌面檢查、代碼走查和代碼審查等方式，主要檢查代碼和設計的一致性，代碼對標準地遵循、可讀性，代碼邏輯表達的正確性，代碼結構的合理性等方面；發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型檢查、程序邏輯檢查、程序語法檢查和程序結構檢查等內容。下面對代碼檢查的三種具體方式進行介紹。

桌面檢查

是一種傳統的檢查方法，由程序員檢查自己編寫的程序。程序員在程序通過編譯之后對源代碼代碼進行分析、檢驗，并補充相關的文檔，目的是發現程序中的錯誤。

代碼走查

代碼走查就是針對代碼，在假想的輸入情況下，逐行的瀏覽代碼，走查代碼中潛在的缺陷并記錄結果的過程。

代碼走查以小組會議方式進行，每小組3-5人。與代碼審查不同的是，走查要求與會者扮演計算機的角色讓測試用例沿被測程序的邏輯運行，是在模擬動態測試；而代碼審查更多的是靜態測試。

代碼審查

代碼審查是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程，以小組會的方式進行。

審查小組一般由若干程序員（包括程序代碼的設計者）和代碼檢查人員組成。會前把設計規格說明書、控制流程圖、程序文本以及要求、規范、錯誤檢查清單交給與會者，開會時程序作者朗讀解釋程序，其他人則集中精力，捕捉程序在結構、功能、編碼風格等方面的問題。

2、代碼檢查項

代碼檢查項即檢查代碼時，指定需要進行檢查的內容。具體如：檢查變量的交叉引用表；檢查標號的交叉引用表；檢查子程序、宏、函數；等價性檢查；標準檢查；風格檢查；選擇、激活路徑；對照程序的規格說明，詳細閱讀代碼，逐字逐句分析；補充文檔。

檢查項可以作為依據，用來編制代碼規則、規范和缺陷檢查表等。

3、編碼規范

編碼規范是程序編寫過程中必須遵循的一套事先約定或者已經制度化、標準化的規則集，一般會詳細的規定代碼的語法規則和語法格式。

一個良好的編碼規范能夠帶來許多好處：改善代碼質量；提高開發進度；增進團隊精神。對于軟件開發而言，采用好的編程規范，雖然不能徹底杜絕糟糕的代碼產生。但對于代碼檢查和將來的代碼維護，仍然是意義重大的。

4、缺陷檢查表

在進行人工代碼檢查時，使用代碼缺陷檢查表作為代碼檢查的參考依據。在軟件測試項目實踐中代碼缺陷檢查表又常被稱作代碼檢查清單。

代碼缺陷檢查表中一般包括開發人員容易出錯的地方和在以往的工作中遇到的典型錯誤。對應于不同的編程語言，代碼缺陷檢查表的具體內容將會有所不同。例如：對于C/C++語言代碼缺陷檢查表內容有以下幾部分：文件結構；文件的版式；命名規則；表達式與基本語句；常量；函數設計；內存管理；C++函數的高級特性；類的構造函數、析構函數和賦值函數；類的高級特性；其他的常見問題等。

5、代碼檢查規則

在代碼檢查中，需要依據被測軟件的特點，選用適當的標準與規范。在使用測試軟件進行自動化代碼檢查或輔助代碼檢查時，測試工具需要內置許多編碼規范。不同編程語言，對應的檢查規范有所不同。針對與C/C++語言的規則有以下幾類規則：通用規則、C++編碼規則、C編碼規則、Meyers-Klaus規則以及自定義規則。使用時，需要根據編程語言和被測程序的特點，選擇適當的規則進行檢查。

6、靜態分析

靜態分析是不執行程序，而分析程序代碼的過程。源代碼被靜態分析器分析之后，得到的靜態分析結果，通常可以表示成一棵靜態語法樹。其中包含了被測項目源代碼的靜態結構信息：基本代碼成分、程序結構、語句結構、類型和模板等信息。

程序代碼靜態分析的結果能夠給代碼檢查提供幫助。

三、代碼檢查過程

傳統的代碼檢查是一種靜態檢查程序的測試方法，通常以團隊的形式來進行。檢查團隊由程序作者，一個負責人，一個記錄員以及一些檢查員組成。首先需要一系列的準備工作，包括參與者的挑選和材料的準備。然后是個人準備階段，每個小組成員各自熟悉材料。個人準備階段后，就是實際的檢查會議。在會議上，檢查小組在假想的輸入下，由程序作者帶領，逐行的瀏覽代碼，評審代碼中潛在的缺陷。檢查小組根據發現缺陷的嚴重程度和類型對其進行分類，并將問題記錄下來供作者修正。會議后是作者的返工，作者匯報每個缺陷，最后確認每個缺陷已經被陳述過了。圖 11為傳統的代碼檢查過程。

圖 1 代碼檢查過程示意圖

代碼檢查過程中的兩個重要階段“個人準備”和“召開會議”階段有以下注意事項：

1、“個人準備”階段：

會前準備階段是檢查過程的一個關鍵階段，因為如果檢查者沒有為檢查做好充分的準備，檢查效果會大打折扣。如果有檢查人員沒有做好準備，主審員可取消其代碼檢查資格，甚至取消這次檢查會議。

檢查人員要熟悉檢查內容的相關文檔，了解程序背景、設計思想和編程方法，在讀懂、“吃”透代碼的基礎上，查出盡可能多的錯誤。

2、“召開會議”階段：

參與會議的檢查者應具有一定的專業技能和經驗，缺乏經驗的檢查人員必然缺乏合適的領域知識來深入理解材料；

參與會議的檢查者應做充分的個人準備，沒有做充分準備的檢查人員不能在檢查會中做出實質性的貢獻；

檢查會議的速度應進行控制，如果試圖在短時間內處理太多的材料，檢查效果也會大打折扣。現在較為常見的代碼檢查速度上的建議為：匯編代碼150行/小時，C語言150行/小時，而對于C++、Java這種面向對象語言，代碼檢查速度可以提高到200-300行/小時。

由此可見，代碼檢查適合于采用工具輔助的特性有：文檔處理，個人準備，會議支持，數據收集。

文檔處理

這是工具可支持的最明顯的領域。傳統的檢查要求分發每份文檔的復印件等，而將紙質的文檔替換成計算機式的文檔，不只是簡單的介質變更，更是提供了一種契機——提高文檔的可用性和表示性的機遇。

個人準備

首先，自動的缺陷檢測可以用來發現簡單的缺陷。如果簡單問題能被自動發現，檢查員就能專注于更加復雜/困難的缺陷，以及那些不能被自動發現的、潛在的、可能帶來更大影響的問題。另外，自動化工具應該對個人準備階段提供更多的幫助。例如，檢查員可以利用檢查表以及其它支持文檔，并能很容易地交叉引用它們；還有些代碼輔助理解工具，可為檢查員理解程序、了解程序結構提供幫助。? 會議支持

一些成員由于某些原因，可能沒有花費足夠的時間來進行準備，但他們仍然參加會議并試圖掩蓋他們的過失。項目管理人員可以使用計算機監控的個人準備時間信息，來剔除那些沒有做好個人準備的成員，或者督促他們投入更多的努力。

召開會議時，檢查員通常面對的是一堆枯燥的程序代碼，如果在代碼之外再結合一些圖、表等便于分析、理解代碼的信息，相信檢查會議可以進行得更加有序和高效。

數據收集

代碼檢查一個重要的部分就是度量信息的收集，用來提供反饋以改進檢查過程。度量信息包括會議時間、發現的缺陷、檢查花費的總時間等。根據這些數據，可以來評價每一次代碼審查的質量，進而給出關于代碼審查的改進建議。

通過對檢查過程的部分階段提供計算機支持，代碼檢查可以進行得更加有效。使用計算機來支持檢查過程，可以提高效率，并增加檢查過程的嚴格性。

四、代碼檢查歷史數據

代碼檢查中的歷史數據本質是軟件問題（缺陷）。按照不同的代碼檢查角度，存在多種對缺陷分類的方法。對過往發現的軟件問題進行分析，總結出今后對于類似的代碼需要按照某種規則來加以檢查，這種的規則就是檢查清單上的一條清單項，代碼檢查清單就是大量規則的集合。此外，由于軟件問題總是以軟件問題報告為載體形式出現，因此軟件問題報告也被通俗的理解為代碼檢查歷史數據。

下面對缺陷分類、代碼檢查清單和軟件問題報告加以研究。

1、缺陷分類

關于缺陷分類存在以下幾種常見的劃分方式：

1）按缺陷出現的區域分類

這種分類方式是最常見的缺陷分類方式。按照出現區域將代碼缺陷劃分為變量級、屬性級、函數/方法級和類級缺陷。其中，變量級、屬性級和部分函數/方法級的缺陷，與傳統的面向過程編程中的缺陷分類基本一致；而多數方法級缺陷和類級缺陷，則是針對面向對象技術編程特點提出的。

2）按檢測內容分類

分為沖突、一致性問題兩種。

沖突對應于文獻[1]中的基于確定性“信念”的判定，而一致性問題則對應于基于可能性“信念”的判定。

3）按對代碼的危害分類

按照對代碼的危害，一般分為浪費時間和空間；語義混淆；暴露封裝性，擴大使用權限；程序一致性問題；程序約束條件問題和空指針問題等。

2、代碼檢查清單（Checklist）

代碼檢查過程中，代碼檢查人員都會有一份代碼檢查清單。代碼檢查清單是一份為代碼檢查人員準備的缺陷檢查表，檢查表中開列所有可能與代碼有關的缺陷，并注明了檢查的內容、缺陷類型以及嚴重性。檢查清單是檢查代碼的依據，代碼檢查人員根據它來發現并判斷問題。代碼檢查清單中會逐條列出所有應該檢查的缺陷種類，以及每條缺陷的各種特征，并且根據缺陷的嚴重程度和類型對其進行分類。通常每一條缺陷的特征描述如下：

1）缺陷描述：該缺陷的問題描述、舉例說明，以及相應的正確形式；

2）缺陷出現的區域：分別為表達式級、語句級、聲明級、模板缺陷、預處理缺陷、類級缺陷以及性能缺陷。表達式級、語句級、聲明級以及預處理的缺陷，主要面向過程程序中的缺陷；模板缺陷、類級缺陷，則是針對面向對象軟件的特點提出的；代碼冗余等歸為性能缺陷；

3）缺陷對代碼的危害：代碼中出現某種缺陷將會造成什么樣的影響。

例如，檢查表中一條缺陷的特征描述如下：

問題描述：指針所指內存釋放后沒有將指針賦為NULL。

舉例說明：

char *p=(char *)malloc(100);strcpy(p, “hello”);free(p);//p所指的內存被釋放，但是p所指的地址還是不變 …

if(p!=NULL)//沒有起到防錯的作用 { strcpy(p, “world”);//出錯 }

正確形式：在釋放內存的同時將指針置空。

char *p=(char *)malloc(100);strcpy(p, “hello”);free(p);p=NULL;//增加指針置空語句

…

if(p!=NULL){ strcpy(p, “world”);}

出現區域：語句級。

危害：指針被free釋放后其地址并不會自動發生改變（非NULL），p成為了“野”指針，這種情況下再對p進行操作，很容易造成程序崩潰，后果非常嚴重。而代碼檢查清單正是由若干條這樣的缺陷特征描述構成的。

3、軟件問題報告（Software Problem Report）

在軟件測試過程中，對于發現的每個軟件問題（缺陷），都要進行記錄該錯誤的特征和再現步驟等信息，以便相關人員分析和處理軟件問題。為了管理測試發現的軟件問題，通常要采用軟件問題報告數據庫，將每一個發現的軟件問題輸入到軟件問題報告數據庫中，軟件問題報告數據庫的每一條記錄稱為一個軟件問題報告。

軟件問題報告包括頭信息、簡述、操作步驟和注釋。

頭信息包括：被測試軟件名稱、版本號、缺陷或錯誤類型、可重復性、測試平臺、平臺語言、缺陷或錯誤范圍。并要求填寫完整和準確。

簡述是對缺陷或錯誤特征的簡單描述，可以使用短語或短句，要求簡練和準確。

操作步驟是描述該缺陷或錯誤出現的操作順序，要求完整、簡潔和準確。對命令、系統變量、選項要用大寫字母，對控件名稱等要加雙引號。

注釋一般是對缺陷或錯誤的附加描述，一般包括缺陷或錯誤現象的圖像，包括其他建議或注釋文字。

軟件問題報告是軟件測試過程中最重要的文檔之一。它記錄了軟件問題發生的環境，軟件問題的再現步驟以及性質的說明，而且還可以跟蹤軟件問題的處理過程和狀態。軟件問題的處理進程從一定角度反映了測試的進程和被測軟件的質量狀況及改善過程。

五、代碼檢查規則管理的研究

1、潛在的編碼規則和缺陷代碼模式

潛在的編碼規則（Implicit Coding Rules）和缺陷代碼模式（Bug Code Pattern）是Tomoko MATSUMURA在文獻[3,4]中針對代碼檢查實踐，提出的兩個相關的概念。

潛在的編碼規則

潛在的編碼規則包含以下幾個特征：

1）不同于在開發啟動時明確決定的“編碼規范”的規則，這些規則在長期的測試/維護過程中是潛伏的，對這些規則的發現是不可預見的。

2）這些規則很少在設計文檔或者特定的文檔中被清楚的描述。他們通常只存在于開發人員、測試/維護人員的記憶中。換言之，是一種尚未系統化的經驗積累和總結的結果。

3）不同于使用規范庫的公用規則。對于特定的軟件有其特定的規則，這也意味著對于不同的軟件有不同的潛在的編碼規則。

4）由于違反潛在的編碼規則導致的缺陷通常情況下不是那么容易發現的。其中相當多一部分只在特定的罕見的情況下發生，所以在早期要想發現這些問題是很困難的。

5）目前，還不存在好的工具或者檢查清單來發現違反潛在的編碼規則的代碼片段，通常的檢查工具（例如PC-Lint、Purify）和通用的檢查清單只能發現常見的問題。

6）為了減少違反潛在的編碼規則的現象的發生，而進行重構通常很困難。要重構一個軟件，準確理解代碼是非常必要的，然而，老的系統太復雜，并且沒有精確的文檔和了

解系統的專業維護人員。總之，重構過期系統的代價很大，需要冒很大的風險。

缺陷代碼模式：違反潛在的編碼規則的編碼模式。

缺陷代碼模式不是肯定會導致缺陷的發生，一段符合缺陷代碼模式的代碼片段，并不意味著代碼片段一定就有缺陷，缺陷代碼模式只是疑似存在缺陷。另一方面，因為缺陷代碼模式是靜態的，沒有考慮到代碼片段之間的動態關聯。需要代碼檢查人員或者維護人員把符合缺陷代碼模式的代碼片段提出來，并判斷究竟是否存在缺陷。

在軟件開發過程中發現和建立缺陷代碼模式有三條主要途徑。其一：在進行代碼檢查過程中，代碼檢查人員發現一個軟件問題的同時，根據對該問題是否具備代表性和通用性等因素的考慮，確定是否建立一個缺陷代碼模式；其二：當軟件失效或者發生問題，檢查對應的代碼部分，發現并確定是否有潛在的編碼規范與之相關；其三：分析現存的代碼規范和積累的大量問題報告，從中提煉出潛在的編碼規則。

在文獻[3,4]中還給我們介紹了一個代碼缺陷檢測系統的大致工作流程，如2所示。

圖2 缺陷檢測模型系統的代碼檢查流程參考圖

2、C++代碼檢查規則類型

1）規則層次

在代碼檢查工作中常常可以發現這樣的現象：有些規則能在所有的項目中都能發現問題，另一些規則所能發現的問題只存在于某類項目中。

根據規則的這個特點，如圖 33中所示，參考文獻[2]中將代碼檢查規則分為兩個層次：

公共規則（General checks）：用于檢查在大多數情況都有可能發生的缺陷。

項目相關規則（Project specific checks）：用于在項目中檢查可能的缺陷。

圖 3 一個典型的代碼檢查規則清單節選圖

在項目中積累了大量軟件問題報告歷史數據的支持下，可以從中進一步細化出與項目或開發人員相關的檢查規則。

在學習任何一種計算機編程語言時，總是按照基本數據類型－>表達式－>語句－>復雜語句－>函數－>整個程序體(類)的順序逐步學習的。事實上軟件正是按照這樣的順序自下而上逐層組建起來的，代碼缺陷作為軟件編程寫時的一種異常情況，毫不例外也是按照這樣層次的構建而成。在實際測試項目的代碼檢查過程中，我們發現在每個層次上都有可能存在潛在代碼缺陷，要找到引起軟件問題的根源，要求在盡可能低的層次上找到引發缺陷的代碼。正因如此，非常有必要在C++語法的每個層次上都建立相應的檢查元規則。

圖4為一個代碼檢查規則體系模型圖[2]，圖中展示了在代碼檢查項目開始前，通過逐級組合各種元規則和規則形成新的檢查規則，最后形成了初始的檢查清單。在項目實踐中，經過對缺陷代碼模式的推導，進而得到擴展的檢查清單。初始檢查清單和擴展檢查清單本質上并沒有什么區別，只是因為形成的時間不同。

圖4 代碼檢查規則體系模型圖

在檢查代碼時我們有時會想要定義一個帶有否定意義的規則，如“在AA情況下如果沒有BB，則可能存在一個問題”。這類檢查規則采用自然語言描述比較容易，但是要用代碼實現起來往往并不簡單，并且對這類規則的定義和維護也比較麻煩。定義組合規則，是解決這類問題一種變通的方法。

下面簡單介紹一下定義組合規則的原理。如圖5中所示定義三個規則，“滿足情況AA”對應規則R1，“滿足在AA情況下出現BB”對應規則R2，將滿足R1但不滿足R2（即以！符號表示）組合則對應規則R3－“在AA情況下如果沒有BB，則可能存在一個問題”。

圖5 組合規則示例圖

根據前面討論，本文將代碼檢查的規則分類設計如下：

公共規則?

定義針對函數體（含）以上層次的檢查規則，在這些層次上出現的缺陷問題一般不容易精確到具體的代碼行。

關鍵字規則?

針對每個關鍵字定義的檢查規則。由于關鍵字是C++語法中一種最普通的元素，單獨使用關鍵字規則的意義不大，一般情況需要和語句、表達式規則或者復雜語句規則配合使用。

語句/表達式規則?

針對基本語句類型或基本表達式定義的規則，滿足對應結構的表達式，則可認為符合了相應的表達式規則。語句/表達式規則中可以包含多個關鍵字，在同一語句/表達式規則中包含的關鍵字地位是平等的，與檢查的先后次序無關。

復雜語句塊規則?

針對條件、開關選擇等多分支語句定義的規則，通常由關鍵字、語句/表達式進行組合來定義復雜語句塊，并在定義時可以進行嵌套，在定義復雜語句塊規則加入語句或表達式和復雜語句時需要考慮檢查的先后次序。

高級組合規則?

關鍵字規則、語句/表達式規則和復雜語句塊規則合稱為普通規則。

對于難以使用普通規則定義方式定義的復雜語義，需要定義高級組合規則。定義高級組合規則可以使用上面幾種規則作為基本單元，也可以嵌套使用其它組合規則。

圖6為一個由下至上、由多個缺陷代碼模式組合形成的組合規則結構圖。其中{}表示某條缺陷代碼模式對應的規則。

圖6 組合規則結構圖

六、代碼分析方法

1、靜態分析

靜態分析主要對源代碼進行詞法分析、語法分析，提取被分析程序的靜態信息，所提取的靜態信息是代碼缺陷檢測的基礎。靜態分析結果主要包括三部分信息：

程序定義信息：程序定義信息包含了程序中所有的定義和聲明信息，如類定義、方法和數據成員的定義、方法內局部變量的定義等。

程序結構信息：主要指方法內的控制流信息和方法間的調用關系。靜態分析器分析程序的語句分支、分支間的嵌套關系和方法調用，記錄方法的控制流信息和調用信息，構造語法樹。

分支內的變量操作：以方法控制流程中的分支為基本單元，記錄每一分支中各語句對各變量施加的操作和操作序列。

2、數據流分析

數據流分析也是一種靜態代碼檢查方法。它是在不通過計算機運行被測程序的條件下，利用預先進行靜態分析后獲取的信息，檢測對變量的賦值與使用操作中，是否存在不合理情況，即找出被測程序中是否存在變量在使用前未被賦值；變量在兩次賦值之間未被使用；一個變量在被賦值后是否未被使用等異常情況。

數據流分析目前的主要用途大多局限在編譯器的實現和優化技術方面，而在代碼檢查系統中實用的數據流分析技術并不多見，主要集中在某幾種缺陷檢測上，如賦值引用異常檢測以及內存錯誤檢測，使用方式主要是定義數據流操作的符號，使用該符號系統構造數據流表達式（由數據操作符號構成的符號串），再分析該符號串來確定是否存在代碼缺陷。

數據流分析包括以下兩個步驟：一是分析程序的所有邏輯路徑；二是對所有邏輯路徑上的所有變量，分析其所有操作序列，然后將得到的操作序列輸入自動機進行分析。因此數據流分析方法不可避免的存在以下缺點：

1）信息量多，上面所述的數據流分析方法是一種窮舉法。事實上一個變量在大部分路徑上存在問題的幾率并不高，因此窮舉每個變量的所有操作序列不可避免的要分析很多正確的信息，而且信息量巨大；

2）組合爆炸，當程序復雜度增長時，該分析方法的復雜度呈幾何級數增長，并且當這種組合是建立在對所有邏輯路徑、所有變量的窮舉基礎上時，如果不能找到一個非常高效的算法，數據流分析方法將是一個非常低效的方法；

3）實用性低，上述兩點導致的數據流分析的實用性降低。

為緩解這些的缺點，數據流分析過程有許多改進方法，但實現都具有一定難度。本系統中數據流分析不是重點，采取的策略是盡可能簡化數據流分析的過程，或者在可能的情況下盡量避免數據流分析。

第五篇：代碼注釋格式

////////////////////////////////////////////////////////////////////////// //函數名稱: WriteFile //函數功能: 向加密鎖創建文件,并且向文件中寫入數據,注意寫入的數據不宜過大,最好少于2k為最佳 //參數說明: fileSize: 文件的大小,以字節為單位 // fileID: 文件在加密鎖中的ID, // fileName: 文件在加密鎖中的名字 // fileContent: 文件內容

//返 回 值: 如果寫入文件成功,則返回true,如果寫入文件失敗,則返回false.//作 者: luyao ///////////////////////////////////////////////////////////////