第一篇：軟件測試外包管理之我見(轉)

我們應該如何面隊國外拋送過來的包呢？難道就就是長期以“包工制”形式一直做下去？

印度一家公司軟件工程師為軟件企業(yè)產品開發(fā)人員講授如何管理軟件測試外包項目。

我們應該如何面隊國外拋送過來的包呢？難道就是長期以“包工制”形式一直做下去？

答案是否定的。很顯然，我們的“包工制”外包項目就是靠實現(xiàn)服務賺錢，如果長此以往，那么我們做的只是低層次的IT企業(yè)或軟件企業(yè)，這種發(fā)展趨勢，決不是中國企業(yè)、中國政府所希望發(fā)展趨勢。

那么我們應該如何逐步演變“包工制”，如何借“外包”把中國的軟件企業(yè)帶到一個更高的境界？

項目外包的核心理念就是“做你最拿手的，其余的讓別人去做”。因此，我們要做好外包項目，也需要從這個理念開始。我們不是沒包接，而是沒有實力和規(guī)模接大包。所以我們要能做好外包項目，做大外包項目，首先我們要有自己最拿手最擅長的招。印度的規(guī)模編碼設計、愛爾蘭的本地化都是在IT市場競爭中獲勝了的接包的招?？墒俏覀儑鴥绕髽I(yè)，還需要磨練，還需要更強更深的技術能力和項目管理能力等招術。

軟件外包測試的興起對國內軟件本地化企業(yè)意味著什么？筆者認為，意味著更多的機會，爭取更多軟件外包國際市場份額的機會。筆者試圖通過多年來從事中高端軟件外包工作管理的經歷，以一個外包測試項目為例，總結了一些外包測試項目的經驗，與讀者共饗，以期達到拋磚引玉，共同提高外包行業(yè)管理能力的目的。限于篇幅，本文僅對測試外包中的風險管理和溝通管理做一個簡單的整理。軟件測試外包特性

與國內一直以來比較輕視軟件測試工作不同，在很多歐美軟件企業(yè)中，測試（質量控制）是一件非常重要的工程工作。國內企業(yè)一般在從事軟件項目開發(fā)的時候，更多的是由開發(fā)人員或者客戶人員在開發(fā)完成之后才進行一些簡單的功能測試工作，很少采用專業(yè)的測試團隊，開發(fā)與測試的比例在4:1以上，甚至高于10:1。因此，多數中國軟件的質量水準相對要低。

與此相反的，在歐美企業(yè)中，質量管理人員（包括事后的質量控制和事前的質量保證）的地位卻高的多。測試也作為一個非常獨立的職業(yè)。在IBM、Microsoft等開發(fā)大型系統(tǒng)軟件公司，很多重要項目的開發(fā)測試人員的比例能夠達到 1:2，甚至1:4。測試活動貫穿于整個開發(fā)生命周期，甚至會比普通開發(fā)人員更早介入項目。測試也是一門更講究科學方法的工程活動，測試的種類也包括單元測試、集成測試、功能測試、性能測試、β測試、驗收測試等等。

本文所介紹項目的客戶是美國一家知名的金融業(yè)軟件及服務供應商。由于金融業(yè)的特點，對于軟件的可靠性、穩(wěn)定性等質量要求尤其的高。該公司從2005年開始將部門開發(fā)和測試工作外包到中國地區(qū)，由筆者所在公司在北京和上海分別成立了兩個團隊，采用一種類似ODC（Offshore Development Center，離岸外包中心）的模式。筆者在過去一年半的時間內負責北京團隊的建設和管理，從最初的一個測試人員和兩個開發(fā)人員發(fā)展到現(xiàn)在的十幾人的團隊（筆者由于公司內部工作安排已經于去年下半年離開該項目）。從最初的從事簡單的軟件產品的安裝和數據移植測試，到現(xiàn)在從事其核心產品的全面功能測試和自動化測試，團隊的工作越來越受到客戶的認可，在客戶的軟件開發(fā)過程中的重要性也越來越高。按照人員數量來計算，該項目的測試與開發(fā)人員的比例略高于1:1。

軟件測試外包的風險管理

軟件外包工作由于天然存在的地理、語言文化差別，其失敗的風險幾率就大的多了。所以從事外包的管理人員在項目啟動之前尤其要對項目中可能存在的風險因素有一個比較全面地識別和分析。比較好的一種風險識別方法是結構化的頭腦風暴法，通過集思廣益找出所有可能影響到項目進度、成本、質量的因素。一個非常重要的風險因素的來源是項目計劃的假設和約束，一旦項目成功所作的假設不能達到，這些就會成為未來影響項目正常進展的問題。

一旦識別出盡可能多的風險因素之后，需要對這些因素進行評估，并不是所有的風險都需要去規(guī)避，所以必須分析哪些風險會對項目產生重大影響，哪些風險發(fā)生的可能性非常高。根據這些分析結果排出項目中優(yōu)先級比較高的風險因素（比如Top 10列表），然后針對這些風險分別找出規(guī)避的措施以及風險發(fā)生時的應對舉措。

針對本文中提到的項目，從風險識別的角度來說，自然災害和戰(zhàn)爭等也是被識別的一些因素，由于屬于不可抗力，所以一般并不列入項目風險管理計劃，但不要因此在風險識別階段就將其排除。而時差、測試人員的英語表達能力、中美的文化差異、網絡的穩(wěn)定性和速度（想想前段時間的海底光纜事故）、數據傳輸的安全性、節(jié)假日安排這些做國內項目的時候幾乎不會考慮的因素可能會是對項目的致命威脅。

對于每個風險都能找到一定的規(guī)避和減少損失的措施，筆者在項目啟動初期花費了較多時間準備金融領域的業(yè)務知識，通過夜間在家加班與客戶建立了良好的信任關系，建立了定期的會議和匯報機制，很短時間之后就確保了團隊正點上下班也不會存在時差所帶來的障礙。

軟件測試外包的溝通管理

學習過PMP/PMBOK的朋友可能都知道這么一個事實，一個項目經理85%的時間都用在各方面的溝通交流上。很多項目出現(xiàn)問題都不是在技術上碰到難題，而更多的是由于溝通不暢引發(fā)的后果。

以前做國內項目的時候一說溝通，很多人就想到要和客戶一起去吃飯喝酒。相對這種非正式的個人之間的溝通，在外包項目管理中更需要建立流暢的正式溝通渠道。這種正式的溝通渠道包括但不限于定期的電視電話會議，正式郵件往來，通過IM的工作聊天，統(tǒng)一的錯誤報告機制（Bug跟蹤系統(tǒng)及其他）等。一個非常重要但經常被忽視的溝通渠道就是文檔，尤其是項目計劃，不少項目經理都只是把項目計劃當作前期不得不完成的一個文檔，到項目執(zhí)行過程中即使再去閱讀也只是關注進度表部分。其實項目計劃包含了眾多內容，除了進度表外，還包括上面提到的風險管理計劃，以及項目的范圍界定和各種項目管理流程（包括需求變更管理流程等），它在一定意義上是合同的一部分，所以及時的更新、審核（Review）和批準（Approval）不僅僅對項目的監(jiān)控非常重要，對于開發(fā)方來說也是很好的法律上的保護。

正式的溝通還有一點非常需要注意的就是要保證良好的反饋機制。我們都知道信息在傳遞的過程中會受到噪音的干擾，尤其是在多次傳遞的情況下更容易失真。所以在建立溝通渠道的時候要建立起方便有效的反饋途徑。對于重要的文檔，一定要有合適的審核和批準機制。更為有效的一種機制還是利用類似于Mercury的Quality Center這樣的工具，由于其內置了工作流，所以任何的問題都必須按照一定的流程進行處理，避免了因為工作忙而忘記了一些重要工作的可能。

最后需要提醒的一點的是，要保留一切溝通過程的證據。美國的金融監(jiān)管部門對金融業(yè)內部的所有電子郵件要求保留至少5年以上以備檢查。在項目中證據的保留一方面是對自己權益的保護，另一方面也是保持完整的溝通記錄有利于后期出現(xiàn)問題的順利解決。

注：本文轉自網絡。

第二篇：軟件測試外包公司面試題

1、試述軟件的概念和特點?軟件復用的含義?構件包括哪些? a)軟件的概念：

軟件是程序、數據結構和相關文檔的集合，用于實現(xiàn)所需要的邏輯方法、過程或控制。軟件是把知識與技術緊密結合的智力成果，是在研制、開發(fā)中被創(chuàng)造出來的一種信息產品。

b)軟件的特點：

①抽象性軟件是一種邏輯實體，而不是具體的物理實體，因而它具有抽象性。②不會磨損在軟件的運行和使用期間，沒有硬件那樣的機械磨損、老化問題，但軟件 維護比硬件維護要負責的多。

③軟件開發(fā)工作最大、開發(fā)效率低、成本高，但復制容易、成本極低。④對計算機系統(tǒng)的依賴性

⑤軟件具有無形性，可以多次使用，但商業(yè)壽命較短。c)軟件復用(SoftWare Reuse)：

軟件復用是將已有軟件的各種有關知識用于建立新的軟件,以縮減軟件開發(fā)和維護的花費，提高軟件生產力和質量的一種重要技術。

d)構件：

構件是系統(tǒng)中實際存在的可更換部分，它實現(xiàn)特定的功能，符合一套接口標準并實現(xiàn)一組接口。構件代表系統(tǒng)中的一部分物理實施，包括軟件代碼（源代碼、二進制代碼或可執(zhí)行代碼）或其等價物（如腳本或命令文件）。

2、瀑布模型和螺旋模型的主要區(qū)別是什么？

瀑布模型強調的保證軟件的質量,忽略人力,時間,資源等成本因素,以質量為第一目標,每次需求發(fā)生變更都要從頭再來，適合于一些大型穩(wěn)定的項目。

螺旋模型是一種增量迭代開發(fā)的模型,每一次循環(huán)都是一次版本的升級，可提高軟件的適應能力。比較適合于前期需求不穩(wěn)定,后期需求新增變更較多的項目。

瀑布模型是基于質量的, 是由文檔驅動的。螺旋模型是風險驅動的，更需要經驗豐富的風險評估知識和水平。

3、軟件生存周期及其模型是什么？

a)軟件生命周期是：計劃-需求分析-軟件設計-程序編碼-軟件測試-運行維護

b)常用的模型有：瀑布模型，螺旋模型，IPD流程，RUP流程

4、什么是軟件測試？軟件測試的目的與原則？

a)軟件測試是在規(guī)定的條件下對程序進行操作，以發(fā)現(xiàn)錯誤，對軟件質量進行評估

即軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

b)軟件測試的目的是找出軟件產品中的錯誤，是軟件盡可能的符合用戶的要求。當然 軟件測試是不可能找出全部錯誤的。

軟件測試的原則： 測試顯示缺陷的存在（但不能證明系統(tǒng)不存在缺陷）窮盡測試是不可能的 測試盡早介入

缺陷集群性（80-20原則）殺蟲劑悖論

測試活動依賴于測試背景 不存在缺陷的謬論

5、凈室軟件工程的策略是什么？

a)增量計劃。開發(fā)一個采用增量策略的項目計劃，建立每個增量的功能、它的項目大小、以及凈室開發(fā)進度表。必須特別小心以保證通過認證的增量將被定時集成。

b)需求收集。使用類似于在第11 章引入的技術，為每個增量開發(fā)一個客戶級需求的更詳細的描述。

c)盒結構規(guī)約。使用一個運用盒結構的規(guī)約方法[HEV93]來描述功能規(guī)約。遵從操作分析原則，盒結構“在每一個精化級別上分離和分開行為、數據及過程的創(chuàng)造性定義”。

d)形式化設計。使用盒結構方法，凈室設計是規(guī)約的自然的無縫的擴展。雖然，在兩個活動間可進行清楚的區(qū)分，但是，規(guī)約(稱為“黑盒”)是被遞進地求精(在一個增量內)以成為類似于體系結構的和過程的設計(分別稱為“狀態(tài)盒”和“清晰盒”)。

e)正確性驗證。凈室小組對設計及代碼進行一系列嚴格的正確性驗證活動。驗證從最高層次的盒結構(規(guī)約)開始，然后移向設計細節(jié)和代碼。正確性驗證的第一層次通過應用一組“正確性問題”[LIN88]來進行，如果這沒有證明規(guī)約是正確的，則使用更形式化的(數過學的)驗證方法。

f)代碼生成、檢查和驗證。以某種專門語言表示的盒結構規(guī)約被轉換為合適的程序設計語言。然后，使用標準的走查或檢查技術來保證代碼和盒結構的語義相符性，以及代碼的語法正確性。然后，對源代碼進行正確性驗證。

g)統(tǒng)計性測試計劃。分析軟件的項目級使用情況，計劃和設計一組執(zhí)行用途的“概率分布”的測試用例。如圖25-1 所示，這個凈室活動是和規(guī)約、驗證及代碼生成并行進行的。

h)統(tǒng)計性使用測試。記住，對計算機軟件進行徹底測試是不可能的，因此，總需要設計有限數量的測試用例。統(tǒng)計性使用技術[POO88]執(zhí)行一系列由特定對象的所有用戶的所有可能的程序執(zhí)行的統(tǒng)計樣本(上面提到的概率分布)所導出的測試。認證。一旦完成驗證、檢查和使用測試(并且所有錯誤被修正)，則開始進行增量集成前的認證工作。

6、軟件配置管理的作用 軟件配置包括什么？

a)軟件配置管理作為軟件開發(fā)過程的必要環(huán)節(jié)和軟件開發(fā)管理的基礎，貫穿整個軟件生命周期，同時對軟件開發(fā)過程的宏觀管理即項目管理也有重要的支持作用。一個軟件開發(fā)組織真正有效的實施軟件配置管理，將會使軟件開發(fā)過程有更好的可預測性，使系統(tǒng)具有可重復性，大大提高軟件組織的競爭力。

b)軟件配置包括如下內容：

配置項識別

工作空間管理 版本控制 變更控制 狀態(tài)報告 配置審計

7、簡述需求分析的過程和意義？

1、明確需求以及測試范圍

了解該需求是為了解決用戶的什么問題 功能性需求：產品必須有的功能

非功能性需求：是否美觀，用戶體驗，穩(wěn)定性，易用性等

最容易忽略的一點：明確的需求背后所隱藏的需求（例如登錄，明確的需求是，正確輸入用戶名，密碼，才能登錄。隱性需求：用戶名字符類型，長度，是否可為空；密碼字符類型，長度等）將問題在需求階段暴露的成本最小

2、畫業(yè)務流程圖（流程圖）根據需求中規(guī)定的業(yè)務流程 各業(yè)務流程分支的確定

由于業(yè)務原因規(guī)定不可使用的業(yè)務流程

3、功能點整理（思維導圖）

業(yè)務功能：需求中所定義的實際業(yè)務直接相關的功能

數據約束：主要是用于控制在執(zhí)行功能時，數據的顯示范圍、數據之間的關系等。

易用性需求：便于功能操作使用的一些細節(jié)，比如快捷鍵就是典型的易用性需求。

編輯約束：在功能執(zhí)行時，對輸入數據項目的一些約束性條件，比如只能輸入數字。

權限需求：不同的權限所能操作的功能點的不同

4、提取測試點（測試需求文檔）

根據整理的思維導圖，去提取每一個功能點中的細節(jié)需求，例如新增員工，在思維導圖中，最小的顆粒度就到新增員工了，但是新增員工這個功能仍然有很多的需求點，員工姓名唯一性判定，手機號碼是否必填等，這些更細的需求點組合起來就形成了測試需求文檔

5、確定測試范圍

需求的確定，并不代表測試范圍就是該需求的范圍，很有可能一個需求分多個軟件版本來實現(xiàn)，最后確定哪些需求是需要測試的。明確哪些測試目標優(yōu)先級高，哪些目標優(yōu)先級低 要完成哪些相應的測試任務才能確保目標的實現(xiàn)

總結： 需求分析的越詳細，對業(yè)務的理解程度就越高，對設計測試用例的幫助就越大。測試的過程中就更有目的性?！澳サ恫徽`砍柴工”，需求分析花的時間越多，之后測試的時間就越少。因為測試其實已經從需求階段開始了。

8、什么是數據的對立性？有幾個層次？

數據獨立性是指：應用程序和數據庫的數據結構之間相互獨立，不受影響。分為物理獨立性和邏輯獨立性兩個層次。

物理數據獨立性：如果數據庫的內模式要進行修改，即數據庫的存儲設備和存儲方法有所變化，那么模式/內模式映象也要進行相應的修改，使概念模式盡可能保持不變。也就是對內模式的修改盡量不影響概念模式。

邏輯數據獨立性：如果數據庫的概念模式要進行修改，如增加記錄類型或增加數據項，那么外模式/模式映象也要進行相應的修改，使外模式盡可能保持不變。也就是概念模式的修改盡量不影響外模式和應用程序。

9、網狀、層次數據模型與關系數據模型的最大的區(qū)別是什么？

網狀、層次數據模型與關系數據模型的最大區(qū)別在于表示和實現(xiàn)實體之間的聯(lián)系的方法：網狀、層次數據模型是通過指針鏈，而關系數據模型是使用二維表。

10、dbms讀取一條記錄時發(fā)生哪些事件？

用戶程序A向DBMS發(fā)出讀一條記錄的指令，這時用戶程序要給出外部文件名和記錄的關鍵字值

DBCS分析所接到的指令，訪問對應的外部模式

DBCS完成外部模式到概念模式的轉換，決定訪問哪個（些）概念文件 接著由DBSS完成概念模式到存儲模式的轉換，并決定訪問哪個（些）存儲文件

DBSS調用存取方法，通過操作系統(tǒng)將讀取的記錄送到系統(tǒng)緩沖區(qū) 用戶程序從系統(tǒng)緩沖區(qū)得到所需記錄和DBMS返回的狀態(tài)信息 用戶程序在工作區(qū)中使用所得到的記錄

11、什么是軟件質量 軟件包是什么？

a)概括地說，軟件質量就是“軟件與明確地和隱含地定義的需求相一致的程度”。具體地說，軟件質量是軟件符合明確敘述的功能和性能需求、文檔中明確描述的開發(fā)標準、以及所有專業(yè)開發(fā)的軟件都應具有的隱含特征的程度。

b)軟件包(SoftWare Package)是指具有特定的功能，用來完成特定任務的一個程序或一組程序。軟件包由一個基本配置和若干可選部件構成，既可以是源代碼形式，也可以是目標碼形式。用戶手冊和指南等文檔是軟件包的重要組成部分。

12、軟件產品質量特性是什么？ 確保軟件質量優(yōu)良程度的內部因素稱為軟件質量特性。比較權威的軟件質量特性劃分應推Boehm提出的十二個基本質量特性。分別為：設備無關性、完整性、精度、一致性、設備效率、可訪問性、可通訊性、結構性、自說明性、簡明性、易讀性、可擴充性。

13、什么是軟件質量保證 其主要任務是什么？

軟件質量保證：為確保軟件開發(fā)過程和結果符合預期要求而建立的一系列規(guī)程，以及依照規(guī)程和計劃采取的一系列活動及其結果評價。

主要任務：

(1)用戶要求定義(2)力爭不重復勞動

(3)掌握開發(fā)新軟件的方法(4)組織外部力量協(xié)作(5)排除無效勞動

(6)發(fā)揮每個開發(fā)者的能力(7)提高軟件開發(fā)的工程能力(8)提高計劃和管理質量

14、軟件質量保證體系是什么？ 國家標準中與質量保證管理相關的幾個標準是什么 他們的編號和全稱是什么？

為滿足質量要求和實施質量管理，進行全部有計劃和有系統(tǒng)的活動所需的組織結構、程序、過程和資源的總稱。

GB／T 19001質量體系設計／開發(fā)、生產、安裝和服務的質量保證模式（idtISO 9001）

GB／T 19002質量體系生產和安裝的質量保證模式（idtISO 9002）

GB／T 19003質量體系最終檢驗和試驗的質量保證模式（idtISO 9003）

GB／T 19004質量管理和質量體系要素指南（idt ISO9004）

15、軟件測試的原則與策略是什么？

軟件測試原則：

1、盡早和不斷的測試。

2、程序員應該避免檢查自己的程序，軟件測試應該由第三方構造。

3、設計測試用例時應該考慮到合法的輸入和不合法的輸入以 及各種邊界條件。

4、注意測試中的錯誤集中發(fā)生現(xiàn)象。

5、對測試錯誤結果有確認過程。

6、制定嚴格的測試計劃，并把測試時間安排的盡量寬松。

7、回歸測試的關聯(lián)性，原有功能過濾

8、進行版本控制，制定變更測試文檔的流程。

測試策略，在一定的軟件測試標準、測試規(guī)范的指導下，依據測試項目的特定環(huán)境約束而規(guī)定的軟件測試的原則、方式、方法的集合，需在測試計劃文檔中體現(xiàn)。

16、什么是測試用例 什么是測試腳本 兩者的關系是什么？ 測試用例是為特定目標而開發(fā)的一組測試輸入、執(zhí)行條件和預期結果，其目標可以是測試某個程序路徑或核實是否滿足某個特定的需求。

測試用例（TESt CASe）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現(xiàn)測試方案、方法、技術和策略。內容包括測試目標、測試環(huán)境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。

測試腳本就是用戶對業(yè)務操作的記錄，將測試用例用測試腳本表述出來，那我們就不用手工執(zhí)行測試了，就可以通過執(zhí)行測試腳本來執(zhí)行測試

測試腳本是進行自動化測試時編寫的腳本程序 測試腳本中要包含測試用例中的數據

17、簡述什么是靜態(tài)測試、動態(tài)測試、黑盒測試、白盒測試、a測試 b測試？

靜態(tài)測試是指測試不運行的部分——只是檢查和審核 動態(tài)測試是指通常意義上的測試——使用和運行軟件

黑盒測試：不關心軟件內部結構，只關心輸入輸出，主要測試依據是需求文檔 白盒測試：關注軟件的內部結構和程序的設計實現(xiàn)，主要測試依據是設計文檔

α測試是軟件開發(fā)公司組織內部人員，模擬各類用戶，對即將上市的軟件產品進行測試，試圖發(fā)現(xiàn)錯誤并修復的過程。

β測試是由軟件的多個用戶在實際使用環(huán)境中進行的測試，這些用戶返回有關錯誤信息給開發(fā)者。

18、測試問題的嚴重性分為幾級 ？如何區(qū)分？

為了盡量準確的表示缺陷信息，通常將缺陷的嚴重性和優(yōu)先級分成4級。如果分級超過4級，則造成分類和判斷尺度的復雜程度，而少于4級，精確性有時不能保證。

具體的表示方法機可以使用數字表示，也可以使用文字表示，還可以數字和文字綜合表示。使用數字表示通常按照從高到底或從低到高的順序，需要軟件測試前達成一致。例如，使用數字1，2，3，4分別表示輕微、一般、較嚴重和非常嚴重的嚴重性。對于優(yōu)先級而言，1，2，3，4可以分標表示低優(yōu)先級、一般、較高優(yōu)先級和最高優(yōu)先級。

微小的（Minor）一些小問題如有個別錯別字、文字排版不整齊等，對功能幾乎沒有影響，軟件產品仍可使用。

一般的（Major）不太嚴重的錯誤，如次要功能模塊喪失、提示信息不夠準確、用戶界面差和操作時間長等。

嚴重的（Critical）嚴重錯誤，指功能模塊或特性沒有實現(xiàn)，主要功能部分喪失，次要功能全部喪失，或致命的錯誤聲明

致命的（Fatal）致命的錯誤，造成系統(tǒng)崩潰、死機，或造成數據丟失、主要功能完全喪失等。

19、測試用例設計的原則是什么 目前主要的測試用例設計方法是什么？ 測試用例設計的原則是：

代表性：能夠代表并覆蓋各種合理的和不合理、合法的和非法的、邊界的和越界的、以及極限的輸入數據、操作和環(huán)境設置等.可判定性：即測試執(zhí)行結果的正確性是可判定的，每一個測試用例都應有相應的期望結果.可再現(xiàn)性：即對同樣的測試用例，系統(tǒng)的執(zhí)行結果應當是相同的。方法有等價類、邊界值、因果圖、狀態(tài)圖、正交法、大綱法

20、結構化系統(tǒng)測試和功能性系統(tǒng)測試分別采用了哪些方法和技術？

a)結構化系統(tǒng)測試技術：

用于驗證所開發(fā)的系統(tǒng)及程序的運行情況。目標是要確保產品設計在結構上合理，功能上正確。為確定實現(xiàn)的配置及其各功能共同作用以完成特定任務提供了一種機制。

結構化測試技術由以下幾種：

壓力測試：確定系統(tǒng)以期望的容量執(zhí)行。

執(zhí)行測試：系統(tǒng)能達到期望的熟練性。

恢復測試：系統(tǒng)失效之后可以恢復到可操作狀態(tài)。操作測試：系統(tǒng)以正常操作狀態(tài)執(zhí)行。

一致性測試：系統(tǒng)的開發(fā)與標準和規(guī)程相一致。安全性測試：根據組織的重要性對系統(tǒng)進行保護。

b)功能性系統(tǒng)測試用于確保系統(tǒng)需求與定義都得到了滿足。該過程通常包含創(chuàng)建用于評價應用程序正確性的測試條件。

用于執(zhí)行功能測試的幾種測試技術包括： 需求測試：系統(tǒng)按制定方式執(zhí)行。

回歸測試：驗證系統(tǒng)中沒有改變的部分仍能正確運行。錯誤處理測試：錯誤可以得到防止或檢測，并被修復。

21、軟件測試分為幾個階段 各階段的測試策略和要求是什么？

軟件測試分為單元測試、集成測試、系統(tǒng)測試、驗收測試四個主要階段：

單元測試：單元測試是針對軟件設計的最小單位––程序模塊甚至代碼段進行正確性檢驗的測試工作，通常由開發(fā)人員進行。

集成測試：集成測試是將模塊按照設計要求組裝起來進行測試，主要目的是發(fā)現(xiàn)與接口有關的問題。由于在產品提交到測試部門前，產品開發(fā)小組都要進行聯(lián)合調試，因此在大部分企業(yè)中集成測試是由開發(fā)人員來完成的。

系統(tǒng)測試：系統(tǒng)測試是在集成測試通過后進行的，目的是充分運行系統(tǒng)，驗證各子系統(tǒng)是否都能正常工作并完成設計的要求。它主要由測試部門進行，是測試部門最大最重要的一個測試，對產品的質量有重大的影響。

驗收測試：驗收測試以需求階段的《需求規(guī)格說明書》為驗收標準，測試時要求模擬實際用戶的運行環(huán)境。對于實際項目可以和客戶共同進行，對于產品來說就是最后一次的系統(tǒng)測試。測試內容為對功能模塊的全面測試，尤其要進行文檔測試。

單元測試測試策略：

自頂向下的單元測試策略：比孤立單元測試的成本高很多，不是單元測試的一個好的選擇。

自底向上的單元測試策略：比較合理的單元測試策略，但測試周期較長。

孤立單元測試策略：最好的單元測試策略。

集成測試的測試策略：

大爆炸集成：適應于一個維護型項目或被測試系統(tǒng)較小

自頂向下集成：適應于產品控制結構比較清晰和穩(wěn)定；高層接口變化較小；底層接口未定義或經?？赡鼙恍薷?；產口控制組件具有較大的技術風險，需要盡早被驗證；希望盡早能看到產品的系統(tǒng)功能行為。

自底向上集成：適應于底層接口比較穩(wěn)定；高層接口變化比較頻繁；底層組件較早被完成。

基于進度的集成

優(yōu)點：具有較高的并行度；能夠有效縮短項目的開發(fā)進度。

缺點：樁和驅動工作量較大；有些接口測試不充分；有些測試重復和浪費。

系統(tǒng)測試的測試策略：

數據和數據庫完整性測試；功能測試；用戶界面測試；性能評測；負載測試；強度測試；容量測試；安全性和訪問控制測試；故障轉移和恢復測試；配置測試；安裝測試；加密測試；可用性測試；版本驗證測試；文檔測試

22、面向對象的測試用例設計有幾種方法 如何實現(xiàn)？

給類中的每個構造函數設計一組測試用例 組合類中的類變量、實例變量 組合類中的各種方法

根據前置條件和后置條件設計測試用例 根據代碼設計測試用例

23、在軟件測試各個階段通常完成什么工作 各個階段的結果文件是什么 包括什么內容？

單元測試階段：各獨立單元模塊在與系統(tǒng)地其他部分相隔離的情況下進行測試，單元測試針對每一個程序模塊進行正確性校驗，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。生成單元測試報告，提交缺陷報告。

集成測試階段：集成測試是在單元測試的基礎上，測試在將所有的軟件單元按照概要設計規(guī)格說明的要求組裝成模塊、子系統(tǒng)或系統(tǒng)的過程中各部分工作是否達到或實現(xiàn)相應技術指標及要求的活動。該階段生成集成測試報告，提交缺陷報告。

系統(tǒng)測試階段：將通過確認測試的軟件，作為整個給予計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數據和人員等其他系統(tǒng)元素結合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行全面的功能覆蓋。該階段需要提交測試總結和缺陷報告。

24、軟件的安全性應從哪幾個方面去測試？

用戶認證機制：如數據證書、智能卡、雙重認證、安全電子交易協(xié)議 加密機制

安全防護策略：如安全日志、入侵檢測、隔離防護、漏洞掃描

數據備份與恢復手段：存儲設備、存儲優(yōu)化、存儲保護、存儲管理 防病毒系統(tǒng)

25、LoadRunner分為哪三個模塊？請簡述各模塊的主要功能。

Virtual User Generator：用于錄制腳步

Mercury LoadRunner Controller：用于創(chuàng)建、運行和監(jiān)控場景 Mercury LoadRunner Analysis：用于分析測試結果

第三篇：軟件測試管理總結

軟件測試管理總結

軟件測試工程師管理系統(tǒng)是我接觸的測試管理項目，通過近兩個星期對軟件測試管理的學習和實踐，遇到了很多問題，覺得還是有很多經驗需要總結。

隨著軟件開發(fā)規(guī)模的增加、復雜程度的增加，以尋找軟件中的故障為目的的測試工作就

顯得更加重要。因此，為了盡可能多的找出程序中的故障，開發(fā)出高質量的軟件產品，必須

對測試工作進行組織策劃和有效管理，采取系統(tǒng)的辦法建立起來軟件測試管理系統(tǒng)。在進行

測試工作識別管理的過程中，我主要做了測試計劃，測試實施，測試總結這幾部分工作。

一、測試計劃的編寫要足夠清晰合理。

測試計劃階段的整體目標是為了確定測試范圍、測試策略和方法，以及對可能出現(xiàn)的問

題和風險，所需要的各種資源和投入等進行分析和估計，以指導測試的執(zhí)行。在計劃中要明

確測試的目的，完善對測試人員的資源分配，設置測試的標準，責任及時間都有明確的進度

安排，指出所用工具。測試計劃編寫時要對照產品需求說明書，系統(tǒng)全面的對測試工作作出

籌劃。

二、準確的填寫bug記錄單需進行充分的步驟記錄。

在測試過程中，bug記錄單不清晰，產品錯誤便不會容易再現(xiàn)。作為測試管理人員對于

問題記錄單中必須包括的要素要了解。我曾經有過造成填寫的問題記錄單過于簡練，只有結

果，沒有清晰的操作步驟，沒有描述產生錯誤的數據信息等，這些都會在測試實施過程中造

成不必要的麻煩，給開發(fā)人帶來模糊理解。認識問題才能解決問題，我在以后的工作中正盡

可能避免這些問題。

三、測試結果的分析要全面公正。

測試結束后，對測試結果進行分析，以確定軟件產品的質量，為產品的改進或發(fā)布提供

數據和支持。在管理上，應做好測試結果的審查和分析，做好測試報告的撰寫和審查工作。

對軟件測試工程師管理系統(tǒng)的管理工作中，我覺得還可以努力地還有，明確測試流程，注意測試流程中各階段的注意事項，及正確填寫問題記錄單。及時發(fā)現(xiàn)測試實施工作中的各

種問題，加強與開發(fā)人員的溝通，以便及時解決問題，保證產品測試進度。

第四篇：軟件外包合同

游戲應用外包合同

甲方：**公司

乙方：

甲方將軟件的部分外包給乙方開發(fā)，為明確雙方責任，本著相互合作、互惠互利的原則，共同協(xié)商后達成如下協(xié)議：

第一條：合同標的1、軟件項目名稱：

2、內容及要求：

根據甲方設計要求，乙方在規(guī)定時間內完成“”軟件部分的開發(fā)。

3、開發(fā)時間：以合同簽定之日起一周為限。

第二條、雙方的權利義務

1、甲方的權利義務：

（1）、甲方應當提供專人與乙方聯(lián)絡并對乙方的開發(fā)進度及質量進行監(jiān)督；

（2）、甲方應當提供軟件開發(fā)所需要的所有數據交給乙方，并保證數據的正確性；

（3）、甲方應當及時支付軟件開發(fā)費用，保證軟件開發(fā)費用及時到位；

（4）、甲方應當依合同約定，及時檢驗、測試所開發(fā)的軟件；

（5）、甲方享有本合同相關作品、程序、文件源碼的版權及所有權；

（6）、甲方在軟件符合約定時，依合同約定接受軟件。

2、乙方的權利義務：

（1）、乙方有責任按甲方的要求在規(guī)定時間內完成項目開發(fā)，完成需要開發(fā)的內容；

（2）、乙方應當與甲方討論制定軟件開發(fā)計劃，并按照約定，及時、正確的完成軟件的開發(fā)；

（3）、乙方在其開發(fā)的范圍內有為甲方提供咨詢及維修的義務；

（4）、乙方不得將本軟件委托或外包給他人完成；

（5）、乙方對本軟件的開發(fā)及在開發(fā)過程中所獲得的所有數據負有保密的義務；

（6）、乙方不得在程序中加插和軟件功能無關的程序或預留一些危害軟件安全的漏洞；

（7）、乙方在開發(fā)出符合合同約定的產品后有權要求甲方依合同約定支付報酬。

第三條、外包軟件的交付

1、乙方應當在雙方約定期限內將軟件產品交付甲方；

2、乙方交付產品時需要向甲方提交如下材料：

（1）、完成甲方功能要求的可執(zhí)行軟件；

（2）、軟件的源代碼；

（3）、軟件開發(fā)過程中產生的其他文檔。

3、開發(fā)完畢，乙方應將軟件相關的文件、源代碼移交給甲方，不得將其應用在其它用途。

第四條、驗收

1、開發(fā)階段的驗收：

甲方應當依開發(fā)計劃在每一個開發(fā)階段對乙方所開發(fā)的產品進行檢測和驗收，在不符合開發(fā)計劃時，甲方有權要求乙方修改；

2、產品交付的驗收標準：

a、程序正常運行；b、方案中提到的功能全部實現(xiàn)；c、項目按時完成；

d、文檔和源代碼齊全；e、軟件通過審核上線。

第五條、付款

本協(xié)議采用轉帳方式付款。

軟件開發(fā)總費用人民幣元。甲方按開發(fā)進度分兩個階段向乙方支付：

1、合同簽定后，個工作日內首付合同總額的30%，金額元；

2、驗收通過后，支付其余款項

3、在實施過程中，因甲方需求變更所引起的費用變更，由甲乙雙方協(xié)商解決。

第六條、保密協(xié)定

1、乙方對本協(xié)議內容、項目開發(fā)成果及開發(fā)過程中涉及的文件、資料材料負有保密義務，未經甲方書面許可，不得向任何第三方泄漏；

2、乙方對甲方提供的、對本次開發(fā)有關的資料負有保密義務，未經甲方書面許可，不得

向第三方泄漏；

3、乙方有責任對甲方所開發(fā)的軟件進行保密，在未經甲方書面許可的情況下，不得向第三方泄露；

4、本合同履行過程中乙方獲知的另一方的商業(yè)秘密或其他技術及經營信息均負有保密義

務，不得向任何其他第三方透露或泄露；

第七條、知識產權歸屬

1、因本協(xié)議產生的開發(fā)成果（含源代碼、系統(tǒng)技術文文件、軟件、數據等）由甲方享有

知識產權，未經甲方書面許可，乙方不得擅自許可任何第三方閱讀、使用或復制；

2、乙方保證其開發(fā)過程、開發(fā)完成的軟件及相關產品不侵犯任何第三方的知識產權。

第八條、違約責任

1、如果因為甲方原因使開發(fā)無法完成，乙方有權終止開發(fā)并不退回首付款。

2、如果因為乙方原因使開發(fā)無法完成，甲方有權終止開發(fā)并要求乙方退回首付款。

3、如因不可抗力或意外事幫導致本外包合同所指向軟件開發(fā)無法繼續(xù)時，該合同自動

終止，違約責任由雙方協(xié)商解決。

第九條、其他條款

1、本合同經雙方授權代表簽字，自簽訂日起生效；

2、本合同一式兩份，雙方當事人各執(zhí)一份，具有同等法律效力。

甲方：乙方：

授權人：身份證號：

年月日年月日

第五篇：軟件外包合同

甲方在此委托乙方進行xx軟件的開發(fā)，為明確雙方責任，經友好協(xié)商，雙方達成以下協(xié)議：

第一條：項目的功能、平臺架構、開發(fā)進度、交付方式等內容由載明。

第二條：甲方的權利和義務

1.提供專人與乙方聯(lián)絡。

2.提供項目所需要的所有資料交給乙方，并保證資料的正確性。

3.及時支付費用，保證項目的開發(fā)費用及時到位。

4.本合同的相關作品、程序、文件源碼的版權屬甲方所有。

第三條：乙方的權利和義務

1.提供專人與甲方聯(lián)絡。

2.按照項目進度要求及時完成系統(tǒng)的開發(fā)，同時保證項目質量。

3.協(xié)助甲方完成所開發(fā)系統(tǒng)的實施、培訓以及維護。

4.開發(fā)完畢，乙方應將系統(tǒng)的文檔、源代碼移交給甲方，不得將其應用在其他企業(yè)。

5.不得將甲方開發(fā)內容泄露給第三方。

第四條：驗收

1.驗收標準為： a.程序正常運行；b.方案中提到的功能全部實現(xiàn)；c.項目按時完成；d.文檔和源代碼齊全

2.驗收期限為2天時間。

第六條：付款方式

1.合同簽訂后1個工作日內，甲方向乙方支付合同總價30％的預付款。

2.試運行完畢，甲方向乙方支付合同總價70％的合同款；

第七條：維護

1.乙方應通過電話、email、現(xiàn)場服務等方式協(xié)助甲方的系統(tǒng)維護，乙方有義務及時響應和認真服務，努力確保甲方所委托開發(fā)系統(tǒng)的正常使用；

2.甲方需要改動或需要委托乙方進行二次開發(fā)，甲方應同乙方另訂協(xié)議，作為合同的附件，另收開發(fā)費用。

第八條 違約責任

1.任何一方有證據表明對方已經、正在或將要違約，可以中止履行本合同，但應及時通知對方。若對方繼續(xù)不履行、履行不當或者違反本合同，該方可以解除本合同并要求對方賠償損失。

2.因不可抗力而無法承擔責任的一方，應在不可抗力發(fā)生的3 天內，及時通知另一方。

3.一方因不可抗力確實無法承擔責任，而造成損失的，不付賠償責任。本合同所稱不可抗力是指不能預見、不能克服并且不能避免的客觀事件，包括但不限于自然災害如洪水、地震、火災和風暴等以及社會事件如戰(zhàn)爭、**、政府行為等。

第九條 其它

1.如果本合同任何條款根據現(xiàn)行法律被確定為無效或無法實施，本合同的其他所有條款將繼續(xù)有效。此種情況下，雙方將以有效的約定替換該約定，且該有效約定應盡可能接近原約定和本合同相應的精神和宗旨。

2.本合同經雙方授權代表簽字并蓋章，自簽訂日起生效。

3.本合同一式兩份，雙方當事人各執(zhí)一份，具有同等法律效力。

乙 方： 甲方

法人代表： 法人代表：

代 理 人： 代 理 人：

日 期： 年 月 日 日 期： 年 月 日

地 址： 地 址：

電 話： 電 話：

傳 真： 傳 真：

開戶銀行： 開戶銀行

帳 號： 帳 號：...