1.	STL類模板
標準庫中容器和算法這部分一般稱為標準模板庫
2.	為什么定義虛的析構函數？
避免內存問題，當你可能通過基類指針刪除派生類對象時。必須保證基類析構函數為虛函數。 
3.	項目管理怎么進行？
制定軟件項目計劃；
軟件項目跟蹤及監控。
軟件項目計劃（Software Project Planning）的目的是為了完成軟件工程和管理軟件項目所制定的計劃，其內容包括估計待完成的工作，建立必要的約定和完成工作的計劃。
軟件項目跟蹤和控制（Software Project Tracking and Oversighting）的目的是對實際進展建立足夠的可視性，使管理著能夠在軟件項目的執行明顯偏離軟件計劃時采取有效措施。其內容包括將實際的完成情況及結果和已文檔化的估計、約定和計劃進行對照，并且基于實際的完成情況和結果調整這些計劃
4.	單元測試如何進行？
單元測試主要編寫驅動函數和樁函數，測試的目標是完成語句覆蓋和路徑覆蓋。驅動函數用于調用被測函數，傳遞測試參數給被測函數。樁函數用于模擬被測函數調用的底層函數，需要對被測函數傳來的各種可能參數進行正確的響應。
5.	VSS的三個核心操作是什么？
Check in、check out、get latest version。
6.	USECASE圖畫到哪一級？
一般要提供用例圖、行為圖和交互圖及各角色定義。
7.	在評審過程中應該做哪些工作？
以文檔評審為例
文檔評審電子流基本流程：
文檔負責人創建文檔評審電子流，指定評審專家和評審負責人－>QA經理確認通過，通知文檔作者－>文檔作者提交文檔－>評審專家提出評審意見－>文檔作者修改文檔再次提交評審－>評審專家會簽通過（可能需要召開評審會議）－>秘書進行文檔歸檔
8.	提交配置管理前做哪些工作？
已經得到QA及配置管理委員會的確認。如果提交的是源代碼，確認包括需求、詳細設計等一系列文檔都已做了相應的修改以及確認。
9.	概要設計文檔如果到編碼時發現問題怎么處理？
先提交問題報告單，經過軟件經理審核，然后確認修改設計方案，修改代碼，測試通過后，提交到配置庫，同時更新相關的概要設計文檔和詳細設計文檔。
10.	工作計劃怎么制定？
根據項目總體計劃落實到每個具體人員身上，按照月度和周來制度工作計劃。
11.	Rose的應用情況
Rose作為一種建模語言工具可以應用于軟件的需求分析、概要設計、詳細設計和測試階段。
12.	軟件開發模式包括哪些？
公司的主要開發模式包括面向對象、面向過程的開發模式，無論哪種方式都體現模塊組裝的思想。
13.	設計的主要目標是什么？
逐步消化、細化需求，用程序的邏輯來表達文字性的描述。
14.	設計包含哪些方面？
概要設計、詳細設計、接口設計。
15.	測試在設計階段有沒有活動要做？
在設計階段要確定集成測試計劃和單元測試計劃。
16.	合作性質項目和傳統項目方式有什么區別？
傳統項目主要根據公司自己的開發流程進行項目管理，合作性項目則需要接納，有時甚至是按照合作方的開發模式進行項目管理，這主要由項目性質和項目需求決定的。
17.	在項目啟動時，如何制定項目計劃？
如果是有規定交付日期的項目，就必須根據交付日期限定、項目需求、項目組成員的素質（體現在代碼生產率）來確定項目計劃。在項目計劃的基礎上可以作出月、周計劃，計劃執行時根據實際情況在不影響開發進度的前提下調整計劃。
18.	項目管理計劃分為哪些類別？
粗的方面包括項目開發計劃、質量計劃、配置計劃、測試計劃。
19.	計劃的制定過程中，需要由哪些人參與？
項目經理、開發經理、質量經理和配置經理均要參與項目計劃的制定。
20.	月度計劃由哪些人參與？主要過程是什么？什么時候啟動月度計劃，如何確定？
月度計劃由項目經理、各小組負責人、質量經理、配置經理參與，主要是根據上月工作完成情況和項目總體計劃來確定本月度計劃。一般是在工作月的最后3天啟動，目的是給大家一個熟悉和工作安排的考慮。
21.	怎樣對計劃進行跟蹤？
每周對計劃完成情況進行審核和評估，及時進行反饋和調整。
22.	CASE管理在開發過程中的應用情況

23.	JAVA的缺陷有哪些？
代碼運行效率低。
24.	CMMⅡ的主要KPA包括哪些？
包括6個關鍵過程域：軟件配置管理、軟件質量保證、軟件子合同管理、軟件項目跟蹤和監督、軟件項目策劃、需求管理。
25.	需求管理方面需要QA做哪些工作？
需求管理（Requirement Management）的目的是在客戶和將處理客戶需求的軟件項目之間建立對客戶需求的共同理解。
    需求管理包括和客戶一起建立和維護有關軟件項目需求的協議，該協議稱作"分配給軟件的系統需求"，"客戶"可解釋為系統工程組、銷售組、另一個內部組織，或者一個外部客戶，"協議"既包括技術需求，又包括非技術需求（如交付日期），該協議形成估計，策劃和跟蹤整個軟件生命周期內項目活動的基礎。
    將系統需求分配給軟件、硬件和其它系統組成部分（如人力等）的工作可能由軟件工程組以外的組（如系統工程組）完成，軟件工程組可能對此分配無法直接控制，在項目約束范圍內，軟件工程可采取適當的步驟以確保軟件的需求已有相對應的定位，并且實現文檔化并處于受控狀態
26.	需求跟蹤方面做哪些工作？可以跟蹤到哪一步？誰來負責？

27.	在需求跟蹤中做了哪些工作？
(1)定義對其他需求的連接鏈
	(2)定義對其他系統元素的連接鏈，這些元素可能包括軟件計劃、產品和活動、需求和設計文檔、代碼。
	目的是它們與軟件需求保持一致。
28.	為需求制定CheckList的目的，如何制定？如何使用CheckList?
根據需求分析的功能模塊確定里程碑，在每個里程碑要設定檢查點和檢查方法，目的是在開發過程中及時發現和解決問題，而不是將問題遺留到后期的測試階段。可由QA執行。
29.	SEPG有多少人員？主要負責哪些方面的工作？
軟件工程過程小組包括項目經理和技術人員，主要負責推進組織所采用的軟件過程的定義、組織和改進工作。
30.	在實施QA方面遇到過哪些問題？

31.	如何理解度量機制？
軟件度量（Software Measurement）通過各種不同的量度(metric)對軟件生命周期中的各個元素進行度量(Measure)，它能夠為項目管理者提供有關項目的各種重要信息，同時也是進行大多評估活動的基礎
32.	需求度量包括哪些？
度量優秀的需求的標準為：（1）完整性（2）正確性（3）可行性（4）必要性（5）劃分優先級（6）無二義性（7）可驗證性
33.	實施QA工作，核心工作還應該包括哪些？

34.	質量特性有哪些？
用戶關注的：有效性、高效性、靈活性、完整性、互操作性、可靠性、健壯性、可用性。
開發者關注的：可維護性、可移植性、可重用性、可測試性。
35.	評審過程中，QA做哪些工作？審核包括哪些內容？
QA確保軟件過程的步驟和標準得到遵守。審核的對象包括文檔、代碼等。
36.	其他角色在評審審核中的作用？
其他角色包括評審負責人，一般是項目經理，負責使評審活動正常有序的進行，確保評審中發現的問題得到解決或者指定解決人。
包括評審專家，負責對評審對象提出問題，尋求解決的方法。
還包括講解人和作者，他們要確保評審專家對評審材料的理解，并對評審專家提出的問題進行解答。
最后還應該由會議記錄員，負責對會議的議題和提出的問題及解決方法進行記錄。
37.	評審作者是否需要參加評審？
評審作者應該參加評審，它有回答評審專家提出的問題的責任，并且負責解決這些問題。
38.	評審過程如何進行？
參見前面的文檔評審流程。
39.	評審前后的工作包括哪些？
評審準備工作包括評審作者準備充分評審材料，確保評審專家理解評審材料，此外還包括確定講解人、評審專家、填寫電子流程申請召開評審會議等。
評審完后，評審作者還要對評審專家提出的問題進行解決，如果所有問題都得到解決，評審專家和評審負責人會簽通過，則評審過程結束。
40.	如何保證專家已經很好地閱讀了文檔？
評審作者要負責準備充分的評審材料，對文檔進行詳細的說明，確保專家能夠理解文檔；同時專家要拿出專門的時間來閱讀文檔。
41.	開發工具用過哪些？
VC:		MSDev			Case:		Rational Rose
Java:	Jbuilder			Database: 	PowerDesigner
42.	描述一下Windows的線程同步對象。
臨界區、互斥、信號、事件
43.	類靜態成員變量在什么范圍內有效？
等同于全局變量
44.	面向對象的好處
繼承性、多態性、封裝性。
45.	在C++中聲明類，如何做到多個實例共享一個全局變量？
聲明一個類靜態成員變量。
46.	在編碼過程中文檔的書寫情況
簡單的是對函數的返回值、參數、用途以及關鍵技術做文檔說明。基本上向MSDN靠攏。
47.	規范在自己日常工作中如何體現？
規范體現在：編程規范、文檔模板、電子流程。
每天填寫日志、每周作計劃和總結，使用PSP工具
48.	控件編寫過沒有
主要編寫訪問數據庫的COM組件給前臺程序調用。一般的UI控件是在CWnd的基礎上編寫的。
49.	調試代碼過程中遇到困難如何解決？
多使用Watch, Variable, Breakpoint, Stack等觀察窗口發現問題；
使用聯機幫助系統；		想其它開發小組成員請教。
50.	C++構造函數，抽象類
構造函數是類初始化第一個調用的函數，如果一個類中包括抽象函數，則該類為抽象類，抽象類不能實例化，主要是作為接口定義。
51.	介紹在項目開發中的角色
開發人員角色，負責詳細設計、接口設計、單元測試計劃和代碼編寫，一般要負責自己開發模塊的單元測試。
52.	接受過CMM哪些方面的培訓？
公司內部CMM培訓，包括KPA及開發流程。
53.	評審如何進行？作為作者如何參與其中？
見前面36。
54.	文檔和代碼不一致應如何處理？
確認文檔是否存在錯誤和滯后，如果是則應該及時的更新文檔，使之與代碼保存一致；反之如果代碼沒有按照正確的文檔所描述的進行設計，則應該更正代碼，使之符合設計的要求。
55.	修改代碼或文檔后，應提交哪些信息？配置管理人員做哪些工作？
應該提交配置標識項和相關的代碼和文檔。
56.	使用過哪些配置管理工具？
Microsoft Visual SourceSafe和Rational ClearCase
57.	配置管理人員的職責和主要工作內容
軟件配置管理（Software Configuration Management）的目的是在整個項目的生命周期建立和維護軟件項目產品的完整性。　
    軟件配置管理包括在給定的時間點上標示軟件的配置（即選定的軟件工作產品及其描述），系統的控制對配置的更改，并在整個軟件生命周期中維護配置的完整性和可跟蹤性。置于軟件配置管理之下的工作產品包括需向客戶交付的軟件產品（如軟件需求文檔和代碼），以及與建立這些產品相關的項目（如編譯程序）。
58.	需求跟蹤方面所做工作的描述

59.	C++ 中常用到的this的含義
類中隱含的指向對象自身的指針，不用聲明。 
60.	用過stl模板嗎?
標準模板庫包括容器、算法和迭代子，包括向量類、鏈表類。MFC中常用的為Clist, Carray。
61.	構造函數與析構函數的功能?
構造函數用來初始化。析構函數用來做清除工作，一般包括內存釋放。
62.	缺陷跟蹤流程
問題提交人提交問題報告單－>軟件經理或組長審核問題通過－>開發人員定位問題原因－>軟件經理或組長審核通過－>配置庫管理員修改配置庫權限－>開發人員實施修改－>開發人員實施測試通過－>配置庫管理員對修改代碼實施歸檔－>測試人員實施回歸測試通過－>問題提交人關閉問題報告單
63.	QA的了解
確保軟件過程的步驟和標準得到實施。
64.	MFC的熟悉程度，說明CListView和CListCtrl有什么不同。
ClistView是從視圖派生，ClistCtrl是從控件類派生，在ClistView中通過使用GetListCtrl可以獲得ClistCtrl指針，將其作為一個ClistCtrl控件來使用。
65.	Socket通訊過程中如何保證連接正常。
一般通過握手機制來確定鏈接正常，即定時在客戶和服務器之間發送連接幀和確認幀來確定。如果是使用MFC的Csocket，通過檢測OnClose事件和錯誤處理可以確定連接是否正常。
66.	在華為工作期間有沒有編寫文檔的經驗。

67.	在開發過程中如何使用SourceSafe。
主要在版本控制和配置管理過程中使用SourceSafe。
68.	開發過程中的問題處理流程是怎樣的。
參見63。