第一篇：軟件集成技術總結

軟件集成技術總結 軟件集成系統

主要功能是實現各種應用軟件在本系統中的集成及調用，由于需要集成軟件的開發軟件，運行環境各有不同，所以在系統集成時調用的相關技術也不盡相同。本系統軟件的集成主要應用了一下三種技術：Java Applet技術，Exe軟件的調用方法，Matlab軟件的調用方法。相關技術 2.1 Java Applet技術

Applet可以翻譯為小應用程序，Java Applet就是用Java語言編寫的這樣的一些小應用程序，它們可以直接嵌入到網頁或者其他特定的容器中，并能夠產生特殊的效果。

Applet必須運行于某個特定的“容器”，這個容器可以是瀏覽器本身，也可以是通過各種插件，或者包括支持Applet的移動設備在內的其他各種程序來運行。與一般的Java應用程序不同，Applet不是通過main方法來運行的。在運行時Applet通常會與用戶進行互動，顯示動態的畫面，并且還會遵循嚴格的安全檢查，阻止潛在的不安全因素（例如根據安全策略，限Applet對客戶端文件系統的訪問）。

在Java Applet中，可以實現圖形繪制，字體和顏色控制，動畫和聲音的插入，人機交互及網絡交流等功能。Applet還提供了名為抽象窗口工具箱（Abstract Window Toolkit，AWT）的窗口環境開發工具。AWT利用用戶計算機的GUI元素，可以建立標準的圖形用戶界面，如窗口、按鈕、滾動條等等。目前，在網絡上有非常多的Applet范例來生動地展現這些功能，讀者可以去調閱相應的網頁以觀看它們的效果。

在Java Applet的生命周期中，共有四種狀態（初始態、運行態、停止態和消亡態）和四個方法：init()、start()、stop()和destroy()。a init()當創建Java Applet且第一次使用支持Java的瀏覽器載入時，就會執行init()方法。在Java Applet生命周期中，該方法只執行一次，因此可以利用這一點在init()方法中進行一些只需執行一次的初始化操作，例如對變量的初始化等。b start()調用完init()方法后，系統將自動調用start()方法。當用戶離開包含Applet的主頁后又再返回時，或者當瀏覽器從圖標狀態恢復為窗口時，系統都會自動再執行一遍start()方法。

和init()方法不同，start()方法在Applet的生命周期中被多次調用，該方法是Applet的主體。在start()方法中，可以執行一些任務，或者是啟動相關的線程來執行任務，如循環播放歌曲等。c stop()和star()方法相對應，當用戶離開Applet所在頁面或者是瀏覽器變成圖標時，系統都會調用stop()方法，因此該方法也是可以被多次調用的。

stop()方法起到這樣的作用：當用戶在當前時刻并不十分關注Applet時，停止一些耗用資源的工作，這樣就可以提高系統的運行速度，而且系統會自動調用該方法，并不需要人為干預。倘若編寫的Applet中不涉及動畫等多媒體，一般不必重寫該方法。51Testing軟件測試網 d destroy()當用戶關閉瀏覽器時，系統就會調用destroy()方法，應該注意stop()方法和destroy()方法的區別。

本系統中的Applet小程序調用流程：運行時，首先從服務器下載應用程序的ZIP壓縮文件到本地，然后解壓到本地，并在在本地運行，在Applet關閉時，停止exe運行，并刪除已下載的ZIP文件和解壓后的文件夾。

2.2 EXE軟件的調用方法

使用Runtime.getRuntime().exec()方法可以在java程序里運行外部程序。

該方法有6個可訪問版本：

1.exec(String

command)

2.exec(String

command，String

envp[]，File

dir)

3.exec(String

cmd，String

envp[])

4.exec(String

cmdarray[])

5.exec(String

cmdarray[]，String

envp[])

6.exec(String

cmdarray[]，String

envp[]，File

dir)

一般的應用程序可以直接使用第一版本,當有環境變量傳遞的時候使用后面的版本。

其中2和6版本可以傳遞一個目錄,標識當前目錄,因為有些程序是使用相對目錄的,所以就要使用這個版本.當要執行批處理的時候,不能直接傳遞批處理的文件名,而要使用：

cmd.exe

/C

start

批處理文件名

使用dos命令(比如dir)時也要使用掉調用。

如果想與調用的程序進行交互,那么就要使用該方法的返回對象Process了,通過Process的getInputStream(),getOutputStream(),getErrorStream()方法可以得到輸入輸出流,然后通過InputStream可以得到程序對控制臺的輸出信息,通過OutputStream可以給程序輸入指令,這樣就達到了程序的交換功能。

使用Runtime類．

try {

Runtime rt = Runtime.getRuntime();

rt.exec(“C:WINDOWSNOTEPAD.exe”);

} catch(Throwable t){ System.out.print(t.getMessage());

} 2.3 Matlab軟件的調用方法

Matlab軟件的調用分為三個步驟：一是在java里面調用matlab，matlab2006b以后的版本中都提供了java 調用matlab的接口matlab build for java；二是將調用matlab程序的java程序轉換為exe程序；三是按照2.1所述的方法調用Matlab的exe程序。

關鍵技術是java調用matlab程序的方法，下面是一個相關的例子：(一)在MATLAB中編輯operation.m, %定義一個函數operation(a,b),求a與b的加減乘除運算，并返回結果

%函數定義function 輸出變量列表[s,m,...] 函數名（輸入變量列表）sum,sub,mul,div中

function [sum,sub,mul,div] = operation(a,b);sum = a + b;sub = a-b;mul = a * b;div = a / b;end(二)生成Java調用文件

Matlab命令中輸入deploytool,新建一個matlab builder ja文件，在operationclass中添加operation.m文件，點擊bulid the project,生成一個供java調用的文件夾結構如下：

Operation-----|----distrib |

|-----operation.jar |

|-----readme.txt

|

-------src

|

|----operation

|

|----operationclass.java

|

|----operationMCRFactory.java

|----operationclassRemote.java

|

|----classes

|

|----operation

|

|----operation.ctf

|

|----operationclass$1.class

|----operationclass.class

|----operationclassRemote.class

|----operationMCRFactory.class |-------build.log |-------operation.ctf |-------operation.jar |-------mccExcludedFiles.log |-------readme.txt(三)Java中建立一個java project工程JavaTestMatlab，導入兩個庫文件javabuilder.jar（C:ProgramFilestoolboxjavabuilderjar）和operation.jar(D:My DocumentsMATLABoperationdistrib operation.jar)，編寫java程序JavaTestMatlab.java程序如下： import operation.*;import java.util.Scanner;class JavaTestMatlab {

public static void main(String[] args)

{

Object result[] = null;

/* object是所有類的父類public Object[] operation(int nargout, Object...rhs)*/

operationclass myAdd = null;

/* Stores myadd class instance */

try

{

int a,b;

myAdd = new operationclass();

System.out.println(“從鍵盤輸入兩個操作數：”);

System.out.print(“

輸入第一個操作數：”);

Scanner scan = new Scanner(System.in);

//從控制臺讀入輸入的整數

a = scan.nextInt();

//從控制臺輸入第一個操作數

System.out.print(“

輸入第二個操作數: ”);

b = scan.nextInt();

//從控制臺輸入第二個操作數

result = myAdd.operation(4,a,b);//operation(4,a,b)中第一個參數是返回值的個數，a是第一個輸入參數,b是第二個輸入參數

System.out.print(“The sum of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[0]);

System.out.print(“The sub of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[1]);

System.out.print(“The mul of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[2]);

System.out.print(“The div of ” + Integer.toString(a)+ “ and ” + Integer.toString(b)+ “ is: ”);

System.out.println(result[3]);

}

catch(Exception e)

{

System.out.println(e);

}

} } 測試結果如下：

從鍵盤輸入兩個操作數：

輸入第一個操作數：55

輸入第二個操作數: 22 The sum of 55 and 22 is: 77 The sub of 55 and 22 is: 33 The mul of 55 and 22 is: 1210 The div of 55 and 22 is: 3(四)錯誤調試

1.安裝matlab不完整，沒有toolboxjavabuilder下的文件 2.環境變量中classpath中添加兩個jar文件的路徑 已經集成的軟件

ORDEM2000 空間碎片評估系統（DAS2.0）增阻型離軌氣動分析及優化軟件 索型離軌技術模擬軟件TetherSim 衛星壽命計算軟件 再入安全評估軟件

GEO衛星離軌燃料估算軟件

第二篇：CADCAE軟件集成心得

CAD/CAE軟件集成心得

經過一個月的努力，現在已經熟練掌握了Proe、ABAQUS、ADAMS、ANSYS（APDL）和ANSYSWorkbench封裝方法。從不熟悉ABAQUS和ADAMS的操作到基本熟悉它們的分析流程和軟件的主要文件（哪些是輸入文件，哪些是結果文件？），從不了解CAE軟件的腳本語言到上網查資料知道了如何將GUI操作錄制成腳本。經歷了不知道自己的想法是否能行的通到知道自己的想法肯定能實現但是不知道怎么去做，再到實現自己的想法。而等我把它在電腦上運行成功后的那一刻，帶給我的興奮是不言而喻的，哈哈，買瓶啤酒慶祝慶祝。但是更多的時間在查資料，不斷思考，不斷修改參數，狂點鼠標，現在右手指還有些痛。當回過頭來總結的時候，覺得這個過程是多么的值得。

也許有人會問，關于這些CAD/CAE軟件的封裝在多學科優化軟件中不是已經有相關實例了嗎？沒錯，在ModelCenter中確實有這方面的實例，我也拿它的實例練習了，但是實例中提供的封裝步驟并不能滿足目前工程師的需要。隨著現在大型商業軟件的專業化，大多企業選擇CAD軟件（UG、Proe、Solidworks等）來建模，然后導入CAE軟件（ANSYS、ABAQUS、NASTRAN等）來分析，最后利用優化軟件（Isight、ModelCenter、Optimus等）將CAD和CAE軟件集成，對現有設計方案進行優化。軟件自帶實例中提供的封裝方法可優化的幾何參數非常有限，而ModelCenter實例中所用的輸入文件是一個有限元文件，包含了節點和單元的信息，許多幾何參數無法從輸入文件中提取，除非在CAE軟件中參數化建模，當模型復雜時，在CAE中建模是非常的麻煩。我們知道實際工程結構的幾何模型往往比較復雜，所以只能走CAD/CAE集成這條路。先集成CAD軟件，把幾何模型作為輸出變量，然后利用編寫的腳本語言作為輸入文件集成CAE軟件，當幾何參數改變時，CAE軟件會重新導入更新后的幾何模型。采用這個辦法就可以改變幾何模型中的任意幾何參數。以下就來介紹在CAD/CAE封裝集成過程中我認為的關鍵中的關鍵：

1、克服對陌生事物的恐懼感。或許你跟我一樣只是以前聽說我這個軟件，沒關系，就算專業的CAE工程師也不可能熟悉所有的CAE軟件。先找個相應軟件的實例跟著操作一遍，大致熟悉分析的流程，如何導入幾何模型，如何劃分網格，如何添加邊界條件以及保存文件。就像初次碰到陌生人一樣，每個人都會緊張，但是見面次數多了，聊的多了不就成熟人了嘛。

2、編寫腳本語言文件作為輸入文件。CAE軟件的操作有GUI（圖形用戶界面）和命令行兩種方式，我們封裝CAE軟件一般采用命令流文件，但我們大多用戶對GUI比較熟悉而對命令流比較陌生。沒關系！我們每一步的GUI操作，軟件都會幫我們記錄相應的腳本，在此腳本文件的基礎上做適當修改就可以當做輸入文件了，例如，定義輸入變量，將關心的輸出變量值寫入結果文件，具體過程參考所要集成軟件的封裝教程。

3、批處理命令。批處理命令即軟件封裝時需要輸入的Run Command，起到調用軟件、執行命令的目的。每個軟件都有自己的腳本語言，所以每個軟件的批處理命令都不盡相同，把它改成自己需要的。

4、多一次嘗試，也許興奮就在下一刻來臨。每當軟件封裝測試失敗時總會感到沮喪，沒關系，把自己編寫的腳本一行一行的在軟件的Command Window中運行，檢查自己的腳本文件是否有錯誤。還需要注意的細節，封裝CAD軟件時有重寫入一項勾上或者將幾何模型IGS格式作為CAD的輸出變量，再把它當做CAE的讀入文件，要不然幾何參數再怎么變化，輸出變量也是毫無變化。

第三篇：CAD技術集成

什么是CAD？

CAD即計算機輔助設計（Computer Aided Design），是一種技術，其中人與計算機結合為一個問題求解組，緊密配合，發揮各自所長，從而使其工作優于每一方，并為應用多學科方法的綜合性協作提供了可能。CAD是工程技術人員以計算機為工具，對產品和工程進行設計、繪圖、分析和編寫技術文檔等設計活動的總稱。

根據模型的不同，CAD系統一般分為二維CAD和三維CAD系統。二維CAD系統一般將產品和工程設計圖紙看成是“點、線、圓、弧、文本、…”等幾何元素的集合，系統內表達的任何設計都變成了幾何圖形，所依賴的數學模型是幾何模型，系統記錄了這些圖素的幾何特征。二維CAD系統一般由圖形的輸入與編輯、硬件接口、數據接口和二次開發工具等幾部分組成。

三維CAD系統的核心是產品的三維模型。三維模型是在計算機中將產品的實際形狀表示成為三維的模型，模型中包括了產品幾何結構的有關點、線、面、體的各種信息。計算機三維模型的描述經歷了從線框模型、表面模型到實體模型的發展，所表達的幾何體信息越來越完整和準確，能解決“設計”的范圍越廣。由于三維CAD系統的模型包含了更多的實際結構特征，使用戶在采用三維CAD造型工具進行產品結構設計時，越能反映實際產品的構造或加工制造過程。

什么是CAPP？

CAPP（Computer Aided Process Planning）是利用計算機輔助工藝人員設計零件從毛坯到成品的制造方法，是將企業產品設計數據轉換為產品制造數據的一種技術。

什么是CAE？

CAE（Computer Aided Engineering）是用計算機輔助求解復雜工程和產品結構強度、剛度、屈曲穩定性、動力響應、熱傳導、三維多體接觸、彈塑性等力學性能的分析計算機以及結構性能的優化設計等問題的一種近似數值分析方法。

什么是CAM？

CAM(computer Aided Manufacturing)利用計算機來進行生產設備管理控制和操作的過程。它輸入信息是零件的工藝路線和工序內容，輸出信息是刀具加工時的運動軌跡(刀位文件)和數控程序。

CAD/CAE/CAPP/CAM集成的關鍵技術是什么？

CAD/CAE/CAPP/CAM集成的關鍵是CAD、CAE、CAPP和CAM之間的數據交換與共享。CAE/CAPP/CAM系統是制造業信息化的核心技術，主要支持和實現產品設計、分析、工藝規劃、數控加工及質量檢驗等工程活動的自動化處理。CAD/CAE/CAPP/CAM的集成，要求產品設計與制造緊密結合，其目的是保證產品設計、工藝分析、加工模擬，直至產品制造過程中的數據具有一致性，能夠直接在計算機間傳遞，從而克服由圖紙、語言、編碼造成的信息傳遞的局限性，減少信息傳遞誤差和編輯出錯的可能性。

由于CAD、CAE、CAPP和CAM系統是獨立發展起來的，并且各自處理的著重點不同，所以它們的數據模型彼此不相容。CAD系統采用面向拓撲學和幾何學的數學模型，主要用于完整地描述零件幾何信息，但對于非幾何信息，如精度、公差、表面粗糙度和熱處理等，則沒有在計算機內部邏輯結構中得到充分表達。而CAD/CAE/CAPP/CAM的集成，除了要求幾何信息外，更重要的是需要面向加工過程的非幾何信息，從而在CAD、CAE、CAPP和CAM之間出現了信息中斷。建立CAPP和CAM子系統時，既需要從CAD子系統中提取幾何信息，還需要補充輸入上述非幾何信息，其中包括輸入大量加工特征信息，因此，人為干預量大，數據大量重復，無法實現CAD/CAE/CAPP/CAM的完全集成。

目前，采用的關鍵技術主要有以下幾方面：

（1）特征技術。建立CAD/CAE/CAPP/CAM范圍內相對統一的、基于特征的產品定義模型，并以此模型為基礎，運用產品數據交換技術，實現CAD、CAE、CAPP和CAM間的數據交換與共享。該模型不僅要求能支持設計與制造各階段所需的產品定義信息（幾何信息、拓撲信息、工藝和加工信息），而且還應該提供符合人們思維方式的高層次工程描述語義特征，并能表達工程師的設計與制造意圖。

（2）集成數據管理。已有的CAD/CAM系統集成，主要通過文件來實現CAD與CAM之間的數據交換，不同子系統文件之間要通過數據接口轉換，傳輸效率不高。為了提高數據傳輸效率和系統的集成化程度，保證各系統之間數據的一致性、可靠性和數據共享，需要采用工程數據庫管理系統來管理集成數據，使各系統之間直接進行信息交換，真正實現CAD/CAM之間信息交換與共享。

（3）產品數據交換標準。為了提高數據交換的速度，保證數據傳輸完整、可靠和有效，必須采用通用的標準化數據交換標準。產品數據交換標準是CAD/CAE/CAPP/CAM集成的重要基礎。

（4）集成框架（或集成平臺）。數據的共享和傳送通過網絡和數據庫實現，需要解決異構網絡和不同格式數據的數據交換問題，以使多用戶并行工作共享數據。集成框架對實現并行工程協同工作是至關重要的

第四篇：軟件測試技術面試總結

軟件測試就是為了發現程序中的錯誤而分析和執行程序的過程。——概念

+基本知識+軟件開發過程-定義-計劃-實現-穩定化-部署

+軟件開發模型(四種典型的模型)

+瀑布模型

-概述：包括計劃，需求分析，設計，編碼，測試，運行維護六個階段。六個階段自上而下、相互銜接，以固定的次序進行。

-特點：1.階段的順序性和依賴性；2.文檔驅動； 3.推遲實現的觀點；4.質量保證。-缺點：不適合需求模糊的系統

+原型模型-概述：先建立一個能夠反映用戶需求的原型系統，使得用戶和開發者可以對目標系統的概貌進行評價和判斷，然后對原型系統進行反復的擴充、改進、求精，最終建立符合用戶需求的目標系統。

-特點：1.快速開發工具；2.循環； 3.低成本。

-分類：按照對原型的處理方式，可以分為漸進型和拋棄型。

+增量模型

-概述：在增量模型中每個階段都生成軟件的一個可發布版本，階段交錯進行，版本逐漸完善。

-同原型模型的最大區別在于，在原型模型中每個階段發布一個原型而在增量模型中則完成一個正式版本。+螺旋模型

-概述：適用于大型軟件的開發，它將瀑布模型和快速原型模型結合起來，并加入了風險分析。

-特點：1.每個階段都包括制定計劃，風險分析，實施工程，評審四個階段；

2.開發過程迭代進行，每迭代一次螺旋線增一周，工程前進一個層次，系統生成一個新版本，投入新的時間成本，最終得到客戶滿意的版本。

-軟件測試從需求開始：現代的軟件測試將測試滲入到軟件開發的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設計階段，測試人員便已經開始了他們的工作，如：了解軟件需求，編寫測試計劃，搭建測試環境。

-測試用例

-三要素：前提條件和操作步驟、預期結果、實際結果。

-必須以需求為依據。

-軟件測試分類

-是否關注軟件結構和算法

-黑盒測試：基于軟件需求的測試方法。

-白盒測試：基于軟件內部設計和程序實現的測試方法。

-是否執行被測試軟件

-動態測試：在測試過程中執行被測試軟件的測試方法。

-靜態測試：------------不----------------------。

-基于不同的測試階段：

-單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅動程序，采用白盒測試的方法，一般由 開發人員完成。

-集成測試：將一些“構件”集成在一起時測試他們是否能正常運行，構件可以是程序模塊，也可以是

客戶機-服務器程序等，需要編寫測試仿真程序，采用白盒和黑盒相結合的方式，通常由 開發人員承擔。

-系統測試：測試軟件系統是否符合所有的需求，包括功能性測試和非功能性測試。一般由

獨立的測試

人員完成，通常采用黑盒測試方法。

-驗收測試：(α、β)與系統測試類似，但由客戶或最終用戶執行，測試軟件是否符合需求規格說明書。

-回歸測試：指在軟件開發過程中，每次錯誤被修正后或軟件的功能、環境發生變化后進行的測試。

-軟件測試的三個步驟：

-測試計劃：測試人員首先對需求進行分析，最終定義一個測試集合，通過刻畫和定義測試發現需求中的問題，然后根據軟件需求同測試主管制定并確認“測試計劃”。

-測試設計和開發：軟件測試人員根據軟件需求和軟件設計說明書完成測試用例的設計和必要的測試驅動 程序的開發。

-執行測試：需要做的工作包括搭建測試環境、運行測試、記錄測試結果、報告軟件缺陷、跟蹤軟件缺陷、分析測試結果，必要時進行回歸測試。

-測試工程師的能力要求：

+5C

-Controlled /kEn'trEuld/ 接受管理，有條理的-Competent /'kCmpitEnt/了解正確的測試技術

-Critical /'kritikEl/專注于發現問題

-Comprehensive /.kCmpri'hensiv/ 注意細節

-Considerate /kEn'sidErit/能夠和開發人員很好的交談

+職業素質-責任心-學習能力-懷疑精神-溝通能力-專注力-洞察力-團隊精神-注重積累 +制定測試計劃的五個步驟：-分析和測試軟件需求-定義測試策略

-定義測試環境

-定義測試管理

-編寫和審核測試計劃

如果在需求分析階段發現并結果問題需要花費$1，則在設計階段解決同樣的問題需花費$5，在編碼階段需$10，交付后解決同樣的問題需花費$200。——越早測試越好-在需求分析過程中測試人員需要進行如下工作：

1)理解需求，參與審核需求文檔；

2)理解項目的目標、限制，了解用戶的應用背景；

3)編寫測試計劃；

4)準備測試資源。

+需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進行測試。

+好的需求文檔的特征-具有清晰的格式和文檔結構-需求的內容正確-需求的內容完整-需求具有可行性需求的必要性

-對不同的需求優先等級進行定義-描述明確-可證性和可測試性-可修改性-可追蹤-需求文檔被及時更新

+需求測試內容

-需求文檔是否符合公司的格式要求

-是否正確

-要保證需求文檔中所描述的內容是真實可靠的-這是“真正的”需求嗎？描述的產品是否是要開發的產品？

-需求是否完備？第一個發布的版本是否需要更多的功能？列出的需求可以減少一部分？-需求是否兼容？需求有可能是矛盾的。

-需求是否可實現？如：需求設想的設備是否比實際運行的要快？需求要求的內存、I/0設備是否太多？

需求的輸入或輸出設備要求的分辨率是否要求過高？

-需求是否合理？在開發進度、開發費用、產品性能、可靠性和內存使用之間存在著平衡關系。

-需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。+需求測試方法-復查review-走查walkthrough-審查inspection

+測試策略的內容

-確定測試范圍 軟件是無法被完全測試的-確定測試方法 不同的系統需要不同的測試方法

-定義測試標準 入口標準，暫停和繼續的標準，出口標準等

+軟件測試結束的標準

-基于測試用例的使用規則

1)構造測試用例（由相關人員進行評審）

2)執行測試用例中，當測試用例的不通過率達到20%則拒絕繼續測試，待開發人員修正軟件后再繼續。

3)當功能性測試用例通過率達到100%，非功能性測試用例通過率達到90%時，允許正常結束。

-基于“測試期缺陷密度”規則

--------------含義：對軟件測試一個CPU小時發現的缺陷數，比較適用于系統測試-基于“運行期缺陷密度”規則

--------------含義：把軟件運行一個CPU小時發現的缺陷數，比較適用于驗收測試注：一個階段的出口標準!=下一個階段的入口標準

系統測試結束的標準!=軟件的發布標準

發布標準!=軟件0缺陷

-選擇測試工具 是否需要，需要什么工具，怎么獲取

-降低軟件測試代價是企業普遍關注的問題，可通過

a.減少冗余和無價值的測試；

b.減少測試階段(萬般無奈下)

+測試環境

-基本內容：設備環境、軟件環境、數據環境

-需考慮的因素-計算機平臺-操作系統-瀏覽器-軟件支持平臺-外圍設備-網絡環境-其他專用設備

-搭建測試環境時的配置原則：-使用的頻度或范圍-實效的可能性-最大限度的模擬真實環境 +測試管理 由于測試工程中設計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進行管理

-選擇缺陷管理工具和測試管理工具

-定義工作進度

-建立風險管理計劃

+可能遇到的風險

·由于設計、編碼階段出現大量質量問題，導致測試工作量時間增加

·開始測試時所需的硬件、軟件沒有準備好

·未能完成對測試人員的技術培訓

·測試時的人力資源安排不足

·測試過程中，發生了大量的需求變更

·測試過程中，項目的開發計劃被大幅度調整

·不能及時準備好測試所需的環境

·不能及時準備好測試數據

+風險管理的過程

·識別風險

·評估風險

·制定對策

·跟蹤風險

+測試設計與開發

+總體設計

-投入產出：測試設計的輸入是測試計劃，輸出是評審過的測試用例集合-定義設計目標遵循的原則

-清楚地說明沒項測試的目標

-使每項測試的目標單一，可以對應到規格說明書中的一項需求

-只說明測試應該完成什么工作，而不說明如何完成-流程：總體設計-開發測試用例-評審測試用例

I.定義設計目標

II.定義輸入說明

III.定義測試環境和配置

IV.測試設計文檔

V.開發測試用例

+測試用例

-概念：為特定目標開發的測試輸入、執行條件和預期結果的集合。

+好的測試用例：

-容易發現軟件的錯誤

-精確的重復某測試失敗的情景，可重復性

-清晰的定義一個或多個期望的結果

-沒有冗余

+測試用例的作用

-指導測試的實施

-作為編寫測試腳本的“設計規格說明書”

-評估測試標準的度量基準

-分析缺陷的標準

+白盒測試用例設計

+設計方法

+邏輯覆蓋法

-語句覆蓋

-判定覆蓋

-條件覆蓋

-判定-條件覆蓋

-條件組合覆蓋

-路經覆蓋

-基本路經法

+輔助模塊設計

-驅動模塊：相當于被測程序的主程序。接受測試數據，把這些數據傳給被測模塊然后輸出實際測試結果。

-樁模塊：用于調用被測模塊調用的子模塊。可以做少量的數據操作，不需要把子模塊的所有功能都帶進來，但不容許什么都不做。

+黑盒測試用例設計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落里，聚集在邊界上。”

-因果圖法彌補等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實現，以保證測試是可重復的。+常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數據狀態，甚至對用戶產生誤導。

·表達不清或過于模糊的信息提示。

·要求用戶輸入多余的本來系統可以自己得到的數據。

·為了得到某個設置或對話框用戶必須做許多冗余的操作，如對話框嵌套太多。·不能記憶用戶的設置或操作習慣，使每次進入系統用戶都需重新操作一次初始環境。·不經用戶確認就對系統或數據進行了重大修改。

-形象類問題

·不符合用戶的操作習慣。如，快捷鍵定義不科學不實用，甚至無快捷鍵。

·不夠專業，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業：中英文不對應，標點的半全角問題，沒有排版準則。·界面元素參差不齊，文字不能完全顯示。

－穩定性問題

·不可重現的死機，或不斷申請但不能完全釋放資源，使系統性能越來越低。

·主系統和子系統使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數據庫字段名或登陸帳號。

·不能重現的錯誤，許多與代碼中的未初始化變量有關，有些與系統不檢查異常情況(網絡中斷、內存申請

不成功、長時間無響應等)有關。

-其他問題

·運行時不檢查內存、硬盤空間、數據庫等。

·無根據的假設用戶環境：硬件/網絡情況；有些動態庫；假設網絡隨時都是聯通的。·提供的版本帶病毒。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現場開放和修改，又沒有記錄和保留。

·版本中部分內容或接口倒退，或出現版本管理混亂。

·有些選項永遠都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗余的嗎？

-每個測試步驟都有清楚描述的預期結果嗎？

+優先級

+3級

優先級1：此測試用例必須執行-2：有時間就執行-3：可以不執行

+5級

1：此測試必須通過，否則產品發布存在危險2：在發布前必須執行3：時間允許就執行4：此測試可以在下一次發布或發布后短期內執行5：可以不測試

第五篇：軟件測試技術總結

IT公司面試手冊提供最全的IT類面試題, 包括

Java：Java面試題 J2EE面試題 Hibernate面試題 Spring面試題Struts面試題EJB面試題.NET:.net面試題 ASP.NET面試題 C#面試題

數據庫：數據庫面試題Oracle面試題 SQL Server面試題 MySql面試題

網絡：網絡技術面試題 網絡安全面試題

Web開發：PHP面試題 Web開發面試題

Linux Unix：Unix面試題Linux面試題

軟件測試： 軟件測試面試題

其他類： 英語面試 外企面試 Python面試題 程序員面試

更多面試題請訪問： http://

軟件測試技術總結

軟件測試就是為了發現程序中的錯誤而分析和執行程序的過程。——概念

+基本知識+軟件開發過程-定義-計劃-實現-穩定化-部署

一、軟件開發模型(四種典型的模型)

1、瀑布模型

概述：包括計劃，需求分析，設計，編碼，測試，運行維護六個階段。六個階段自上而下、相互銜接，以固定的次序進行。

特點：1.階段的順序性和依賴性；2.文檔驅動；3.推遲實現的觀點； 4.質量保證。

缺點：不適合需求模糊的系統

2、原型模型

概述：先建立一個能夠反映用戶需求的原型系統，使得用戶和開發者可以對目標系統的概貌進行評價和判斷，然后對原型系統進行反復的擴充、改進、求精，最終建立符合用戶需求的目標系統。

特點：1.快速開發工具；2.循環； 3.低成本。

分類：按照對原型的處理方式，可以分為漸進型和拋棄型。

3、增量模型

概述：在增量模型中每個階段都生成軟件的一個可發布版本，階段交錯進行，版本逐漸完善。同原型模型的最大區別在于，在原型模型中每個階段發布一個原型而在增量模型中則完成一個正式版本。

4、螺旋模型

概述：適用于大型軟件的開發，它將瀑布模型和快速原型模型結合起來，并加入了風險分析。特點：1.每個階段都包括制定計劃，風險分析，實施工程，評審四個階段；2.開發過程迭代進行，每迭代一次螺旋線增一周，工程前進一個層次，系統生成一個新版本，投入新的時間成本，最終得到客戶滿意的版本。-軟件測試從需求開始：現代的軟件測試將測試滲入到軟件開發的各個階段，即使瀑布模型，表面看測試工作是在測試階段開始的，事實上，在計劃、需求、設計階段，測試人員便已經開始了他們的工作，如：了解軟件需求，編寫測試計劃，搭建測試環境。

二、測試用例

1、三要素：前提條件和操作步驟、預期結果、實際結果。

2、必須以需求為依據。

三、軟件測試分類

1、是否關注軟件結構和算法

-黑盒測試：基于軟件需求的測試方法。-白盒測試：基于軟件內部設計和程序實現的測試方法。

2、是否執行被測試軟件

-動態測試：在測試過程中執行被測試軟件的測試方法。-靜態測試：------------不----------------------。

3、基于不同的測試階段：

1、單元測試：主要測試軟件的單元模塊，需要編寫額外的測試驅動程序，采用白盒測試的方法，一般由 開發人員完成。

2、集成測試：將一些“構件”集成在一起時測試他們是否能正常運行，構件可以是程序模塊，也可以是客戶機-服務器程序等，需要編寫測試仿真程序，采用白盒和黑盒相結合的方式，通常由 開發人員承擔。

3、系統測試：測試軟件系統是否符合所有的需求，包括功能性測試和非功能性測試。一般由獨立的測試人員完成，通常采用黑盒測試方法。

4、驗收測試：(α、β)與系統測試類似，但由客戶或最終用戶執行，測試軟件是否符合需求規格說明書。

5、回歸測試：指在軟件開發過程中，每次錯誤被修正后或軟件的功能、環境發生變化后進行的測試。

四、軟件測試的三個步驟：

1、測試計劃：測試人員首先對需求進行分析，最終定義一個測試集合，通過刻畫和定義測試發現需求中的問題，然后根據軟件需求同測試主管制定并確認“測試計劃”。

2、測試設計和開發：軟件測試人員根據軟件需求和軟件設計說明書完成測試用例的設計和必要的測試驅動程序的開發。

3、執行測試：需要做的工作包括搭建測試環境、運行測試、記錄測試結果、報告軟件缺陷、跟蹤軟件缺陷、分析測試結果，必要時進行回歸測試。

五、測試工程師的能力要求：

1、5C

-Controlled /kEn'trEuld/ 接受管理，有條理的-Competent /'kCmpitEnt/了解正確的測試技術

-Critical /'kritikEl/專注于發現問題

-Comprehensive /.kCmpri'hensiv/ 注意細節

-Considerate /kEn'sidErit/能夠和開發人員很好的交談

2、職業素質-責任心-學習能力-懷疑精神-溝通能力-專注力-洞察力-團隊精神-注重積累

六、制定測試計劃的五個步驟：

1、分析和測試軟件需求

2、定義測試策略

3、定義測試環境

4、定義測試管理

5、編寫和審核測試計劃

如果在需求分析階段發現并結果問題需要花費$1，則在設計階段解決同樣的問題需花費$5，在編碼階段需$10，交付后解決同樣的問題需花費$200。——越早測試越好

七、在需求分析過程中測試人員需要進行如下工作：

1)理解需求，參與審核需求文檔；2)理解項目的目標、限制，了解用戶的應用背景；

3)編寫測試計劃；4)準備測試資源。

八、需求測試

-需求測試測試的對象是主意而不是代碼，針對文檔進行測試。

九、好的需求文檔的特征

1、具有清晰的格式和文檔結構

2、需求的內容正確

3、需求的內容完整

4、需求具有可行性需求的必要性

5、對不同的需求優先等級進行定義

6、描述明確

7、可證性和可測試性

8、可修改性-可追蹤

9、需求文檔被及時更新

十、需求測試內容

1、需求文檔是否符合公司的格式要求

2、是否正確

3、要保證需求文檔中所描述的內容是真實可靠的4、這是“真正的”需求嗎？描述的產品是否是要開發的產品？

5、需求是否完備？第一個發布的版本是否需要更多的功能？列出的需求可以減少一部分？

6、需求是否兼容？需求有可能是矛盾的。

7、需求是否可實現？如：需求設想的設備是否比實際運行的要快？需求要求的內存、I/0設備是否太多？需求的輸入或輸出設備要求的分辨率是否要求過高？

8、需求是否合理？在開發進度、開發費用、產品性能、可靠性和內存使用之間存在著平衡關系。

9、需求是否可測？對于軟件測試人員來說判斷需求是否可測是這個過程中最重要的工作。

十一、需求測試方法

1、復查review2、走查walkthrough3、審查inspection

十二、測試策略的內容

1、確定測試范圍 軟件是無法被完全測試的2、確定測試方法 不同的系統需要不同的測試方法

3、定義測試標準 入口標準，暫停和繼續的標準，出口標準等

十三、軟件測試結束的標準

-基于測試用例的使用規則

1)構造測試用例（由相關人員進行評審）

2)執行測試用例中，當測試用例的不通過率達到20%則拒絕繼續測試，待開發人員修正軟件后再繼續。

3)當功能性測試用例通過率達到100%，非功能性測試用例通過率達到90%時，允許正常結束。

-基于“測試期缺陷密度”規則---------含義：對軟件測試一個CPU小時發現的缺陷數，比較適用于系統測試-基于“運行期缺陷密度”規則---------含義：把軟件運行一個CPU小時發現的缺陷數，比較適用于驗收測試注：一個階段的出口標準!=下一個階段的入口標準

系統測試結束的標準!=軟件的發布標準發布標準!=軟件0缺陷

-選擇測試工具 是否需要，需要什么工具，怎么獲取

-降低軟件測試代價是企業普遍關注的問題，可通過

a.減少冗余和無價值的測試；b.減少測試階段(萬般無奈下)

十四、測試環境

-基本內容：設備環境、軟件環境、數據環境

-需考慮的因素-計算機平臺-操作系統-瀏覽器-軟件支持平臺-外圍設備-網絡環境-其他專用設備-搭建測試環境時的配置原則：-使用的頻度或范圍-實效的可能性-最大限度的模擬真實環境

十五、測試管理

由于測試工程中設計的人員、活動、工具是很多的，在制定測試計劃時需要對這些因素進行管理-選擇缺陷管理工具和測試管理工具-定義工作進度

-建立風險管理計劃

(1)可能遇到的風險

1.由于設計、編碼階段出現大量質量問題，導致測試工作量時間增加

2.開始測試時所需的硬件、軟件沒有準備好3.未能完成對測試人員的技術培訓

4.測試時的人力資源安排不足5.測試過程中，發生了大量的需求變更

6.測試過程中，項目的開發計劃被大幅度調整7.不能及時準備好測試所需的環境

8.不能及時準備好測試數據

(2)風險管理的過程

1.識別風險2.評估風險3.制定對策4.跟蹤風險

+測試設計與開發

+總體設計

-投入產出：測試設計的輸入是測試計劃，輸出是評審過的測試用例集合-定義設計目標遵循的原則

(-清楚地說明沒項測試的目標-使每項測試的目標單一，可以對應到規格說明書中的一項需求-只說明測試應該完成什么工作，而不說明如何完成)

-流程：總體設計-開發測試用例-評審測試用例

I.定義設計目標II.定義輸入說明III.定義測試環境和配置

IV.測試設計文檔V.開發測試用例

+測試用例——概念：為特定目標開發的測試輸入、執行條件和預期結果的集合。

+好的測試用例：

1.容易發現軟件的錯誤2.精確的重復某測試失敗的情景，可重復性

3.清晰的定義一個或多個期望的結果4.沒有冗余

+測試用例的作用

-指導測試的實施-作為編寫測試腳本的“設計規格說明書”-評估測試標準的度量基準-分析缺陷的標準 +白盒測試用例設計

+設計方法

+邏輯覆蓋法

(-語句覆蓋-判定覆蓋-條件覆蓋-判定-條件覆蓋-條件組合覆蓋-路經覆蓋-基本路經法)

+輔助模塊設計

(1.驅動模塊：相當于被測程序的主程序。接受測試數據，把這些數據傳給被測模塊然后輸出實際測試結果。

2.樁模塊：用于調用被測模塊調用的子模塊。可以做少量的數據操作，不需要把子模塊的所有功能都帶進來，但不容許什么都不做。)

+黑盒測試用例設計

-等價類劃分法

-邊界值法——“缺陷遺漏在角落里，聚集在邊界上。”

-因果圖法彌補等價類和邊界值法的不足

-錯誤推測法

-測試用例的管理可以通過配置管理工具cvs,vss,ClearCase等實現，以保證測試是可重復的。

+常見錯誤分析

-用戶界面問題

·輸入無合法性檢查和值域檢查。

·界面信息不能及時更新，不能正確反映數據狀態，甚至對用戶產生誤導。

·表達不清或過于模糊的信息提示。

·要求用戶輸入多余的本來系統可以自己得到的數據。

·為了得到某個設置或對話框用戶必須做許多冗余的操作，如對話框嵌套太多。

·不能記憶用戶的設置或操作習慣，使每次進入系統用戶都需重新操作一次初始環境。

·不經用戶確認就對系統或數據進行了重大修改。

-形象類問題

·不符合用戶的操作習慣。如，快捷鍵定義不科學不實用，甚至無快捷鍵。

·不夠專業，缺乏基本知識。

·界面中英文混雜，甚至拼寫錯誤。

·說明書或幫助的排版格式不專業：中英文不對應，標點的半全角問題，沒有排版準則。

·界面元素參差不齊，文字不能完全顯示。

－穩定性問題

·不可重現的死機，或不斷申請但不能完全釋放資源，使系統性能越來越低。

·主系統和子系統使用了相同的臨界資源而相互不知道。如：使用相同的類名或臨時文件名、使用同樣的數據庫字段名或登陸帳號。

·不能重現的錯誤，許多與代碼中的未初始化變量有關，有些與系統不檢查異常情況(網絡中斷、內存申請不成功、長時間無響應等)有關。

-其他問題

·運行時不檢查內存、硬盤空間、數據庫等。

·無根據的假設用戶環境：硬件/網絡情況；有些動態庫；假設網絡隨時都是聯通的。

·提供的版本帶病毒。

·提供錯誤的版本給測試組或測試用戶，或程序員與測試組使用不同版本。

·用戶現場開放和修改，又沒有記錄和保留。

·版本中部分內容或接口倒退，或出現版本管理混亂。

·有些選項永遠都是灰的，或有些在該變灰時沒變灰。

+測試用例的評審

-測試或測試組件完全針對的是需求中列出的功能嗎？

-測試組件是否覆蓋了所有的需求？

-有冗余的嗎？

-每個測試步驟都有清楚描述的預期結果嗎？

+優先級

+3級

優先級1：此測試用例必須執行-2：有時間就執行-3：可以不執行

+5級

1：此測試必須通過，否則產品發布存在危險2：在發布前必須執行3：時間允許就執行4：此測試可以在下一次發布或發布后短期內執行5：可以不測試