第一篇：工作中常見的界面測試(UI測試)用例設(shè)計總結(jié)

大家在編寫測試用例時，往往分不清什么是UI，什么是功能。最近特意整理了工作中經(jīng)常進行的UI測試項。UI測試內(nèi)容包括以下內(nèi)容： 1.窗口測試主要測試內(nèi)容如下：

窗口與窗口之間的調(diào)用情況；

窗口尺寸變化時窗口中控件能否自適應(yīng)；

多個窗口同時打開和調(diào)用的情況；

窗口拖動是否正常；

主窗口和子窗口調(diào)用能否正常處理；

窗口能否根據(jù)瀏覽器大小進行縮放【雙擊瀏覽器、瀏覽器最大化、最小化和還原查看窗口的變化情況】；

窗口顯示標(biāo)題是否正確。

2.工具條測試主要測試內(nèi)容如下：

工具條能否正常顯示；

工具條能否隱藏；

可移動工具條在窗口中間位置其形狀是否正確；

工具欄上工具按鈕功能是否能正常實現(xiàn)；

工具按鈕顯示是否正確、友好、醒目易懂；

工具欄上的工具按鈕是否有鼠標(biāo)懸停提示；

工具欄上的工具按鈕是否可以任意定制；

是否有輸入框；

是否有個人用工具條；

是否有網(wǎng)站型工具條；

是否有專項型工具條；

是否有企業(yè)型工具條。

3.工具條測試主要測試內(nèi)容如下：

輸入正常的字母或數(shù)字；

輸入已存在的文件的名稱；

輸入超長字符，例如在“名稱”框中輸入超過允許邊界個數(shù)的字符，假設(shè)最多255個字符，嘗試輸入 256個字符，檢查程序能否正確處理；

輸入默認值，空白，空格；

若只允許輸入字母，嘗試輸入數(shù)字；反之；嘗試輸入字母；

利用復(fù)制，粘貼等操作強制輸入程序不允許的輸入數(shù)據(jù)；

輸入特殊字符集，例如，NUL及n等；

輸入特殊字符集，例如，NUL及n等；

輸入不符合格式的數(shù)據(jù)，檢查程序是否正常校驗，如，程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程序應(yīng)該給出錯誤提示；

輸入非法數(shù)據(jù)；

輸入默認值；

輸入特殊字符集；

輸入使緩沖區(qū)溢出的數(shù)據(jù)；

輸入相同的文件名；

輸入超過文本框長度的字符或文本，檢查所輸入的內(nèi)容是否正常顯示。4.菜單測試主要測試內(nèi)容如下：

菜單項是否符合需求，能否正常工作，是否與實際執(zhí)行的內(nèi)容一致；

菜單措辭是否準(zhǔn)確；

菜單位置及順序是否合理；

菜單圖形布局是否一致；

下拉菜單是否根據(jù)選項含義進行分組；

菜單的熱鍵、快捷鍵能否有效使用和重復(fù)；

幫助菜單的“關(guān)于”中應(yīng)有版權(quán)和產(chǎn)品信息；

界面菜單公司信息和產(chǎn)品信息顯示是否正確。5.頁面布局測試主要測試內(nèi)容如下：

頁面布局是否根據(jù)分辨率大小自動調(diào)整；

頁面長寬比例合理是否合適；

界面風(fēng)格要一致；

背景色彩搭配要協(xié)調(diào)。6.圖標(biāo)測試主要測試內(nèi)容如下：

是否符合表達習(xí)慣；

不同目標(biāo)是否采用不同圖標(biāo)；

圖標(biāo)尺寸是否合適；

圖標(biāo)是否有標(biāo)注，包括公司圖標(biāo)和產(chǎn)品圖標(biāo)。7.界面按鈕測試主要測試內(nèi)容如下：

按鈕位置是否合適，是否有正常響應(yīng)，是否有相應(yīng)的匹配按鈕如：按鈕；

單選框和復(fù)選框按鈕的測試；

功能按鈕圖標(biāo)上或在鼠標(biāo)經(jīng)過時是否給予正確提示信息。8.時間控件測試主要測試內(nèi)容如下：

時間年月日選擇（開始時間不可大于結(jié)束時間）；

時間有效期；

時間年月日顯示是否正確；

時間查詢。

9.界面文字測試主要測試內(nèi)容如下：

界面文字描述是否準(zhǔn)確，無異議；

文字大小是否合適（一般9-12號）；

是否出現(xiàn)中英文混合；

界面文字是否可根據(jù)瀏覽器的編碼方式自適應(yīng)。10.界面信息提示測試主要測試內(nèi)容如下：

提示信息是否具有可理解性的語言描述；

對重要、具有破壞性的操作命令是否有確認信息；

提示信息是否具有統(tǒng)一的標(biāo)記和標(biāo)準(zhǔn)；

提示信息不易過長。

11.鼠標(biāo)和快捷鍵測試主要測試內(nèi)容如下：

是否支持滑輪；

鼠標(biāo)點擊右鍵是否顯示菜單，取消右鍵是否隱藏；

無規(guī)則點動鼠標(biāo)，查看界面的響應(yīng)；

經(jīng)過鍵盤或鼠標(biāo)復(fù)制粘貼；

支持快捷鍵使用；

支持鍵盤自動瀏覽按鈕（Tab鍵、Enter鍵）。

“確定”和“取消”當(dāng)然在設(shè)計UI窗口測試用例時，要根據(jù)以上大的測試項，逐漸細分，盡可能多的設(shè)計較全面的測試用例，但是還要根據(jù)測試軟件的具體實現(xiàn)架構(gòu)進行設(shè)計用例

第二篇：常見的軟件測試用例設(shè)計方法

常見的軟件測試用例設(shè)計方法有以下幾種：

一、等價類劃分

1）確定等價類

有效等價類代表對程序的有效輸入；無效等價類代表的是其他不正確的任何輸入。如果需要，我們還可以將一個等價類劃分為更小的一些等價類。

比如，規(guī)格說明規(guī)定了“請輸入書籍的數(shù)量（1~99）以及書籍的類型（硬皮、軟皮或活頁）”。它們對應(yīng)的等價類分別如下：

書籍?dāng)?shù)量

書籍類型

2）生成測試用例

1.為每個等價類設(shè)置編號。

2.編寫測試用例，盡可能多的覆蓋尚未被覆蓋的有效等價類。直到所有的有效等價類都被測試用例覆蓋。測試用例及其覆蓋的有效等價類如下：

3.編寫測試用例，覆蓋一個且僅一個尚未被覆蓋的無效等價類。直到所有的無效等價類都被測試用例所覆蓋。測試用例及其覆蓋的無效等價類如下：

用單個的測試用例覆蓋無效等價類，是因為有些輸入的錯誤檢查可能會屏蔽或取代其他輸入的錯誤檢查。比如②⑦，也許程序提示“非法的書籍?dāng)?shù)量”后，就不會執(zhí)行對書籍類型的檢查了。

二、邊界值分析

經(jīng)驗證明，考慮了邊界條件的測試用例比其他沒有考慮邊界條件的測試用例，具有更高的測試回報率。所謂邊界條件，是指輸入和輸出等價類中恰好處在邊界、或超過邊界、或在邊界以下的狀態(tài)。

上例中的書籍?dāng)?shù)量范圍是1~99，那么應(yīng)該針對0，1和99，100的情況分別設(shè)計測試用例。

從定義可以看出，等價劃分只關(guān)注輸入空間（輸入等價類）的不同，邊界值分析還需要從輸出空間（輸出等價類）設(shè)計測試用例。

舉例來說：

某個程序按月計算個人所得稅的速算扣除數(shù)，且最小金額是0，最大金額是13,505。使用邊界值分析法，應(yīng)該設(shè)計測試用例測試速算扣除數(shù)結(jié)果為0和13505的情況。此外，還應(yīng)觀察是否可能設(shè)計出導(dǎo)致速算扣除數(shù)為負數(shù)，或者超過13505的測試用例。

邊界值分析法和等價劃分重要的區(qū)別是，等價劃分是從等價類中挑選任意一個元素作為測試數(shù)據(jù)；邊界值分析法考察正處于等價劃分邊界或在邊界附近的狀態(tài)。

三、因果圖

邊界值分析和等價劃分的缺點是，未對輸入條件的組合情況、輸入條件之間的相互制約關(guān)系進行分析。

1）因果圖的基本關(guān)系

?恒等（Identify）:若a為1，則b為1；否則b為0。

?非（NOT）:若a為1，則b為0；否則b為1。

?或（OR）:若a或b或c為1，則d為1；否則d為0。

?與（AND）:若a和b和c都為1，則d為1；否則d為0。

2）因果圖的約束條件

1、對于輸入條件的約束有E、I、O、R四種：

?異（E）:E必須總為真，而a、b最多只有一個為1。

?或（I）:I為真時，a、b和c中至少有一個必須為1。

?唯一（O）:a、b中，有且僅有一個必須為1。

?要求（R）:如果a為1，b也必須為1。

2、對于輸出結(jié)果的約束只有M一種：

屏蔽（M）:如果結(jié)果a為0，則b強制為0。

一、假設(shè)有一規(guī)格說明：

“第一列中的字符必須是‘A’或‘B’，第二列中的字符必須是一個數(shù)字。在這種情況下，對文件進行更新。如果第一個字符不正確，產(chǎn)生提示信息X12。如果第二個字符不是數(shù)字，產(chǎn)生提示信息X13?！?/p>

（1）將規(guī)格說明分解為可執(zhí)行的片段，確定“因”和“果”，為每個“因”和“果”都賦予唯一的編號?！耙颉笔菞l件，是指一個明確的輸入條件等價類?！肮笔莿幼鳎侵敢粋€輸出或系統(tǒng)轉(zhuǎn)換（輸入對程序或系統(tǒng)狀態(tài)的延續(xù)影響）。

（2）分析規(guī)格說明的語義，轉(zhuǎn)換為因果圖。原因①和原因②不可能同時成立，為因果圖添加對應(yīng)的約束條件，得到右圖。

因果圖和添加了約束條件后的因果圖

（3）將因果圖轉(zhuǎn)換為判定表，每一列代表一個測試用例。

判定表

（4）將判定表中的列轉(zhuǎn)換為測試用例。

二、將因果圖轉(zhuǎn)換為判定表的思路（以上述的例子來說明）

1.選擇一個“果”作為當(dāng)前狀態(tài)。例：71。

2.對因果圖回溯，找出導(dǎo)致該“果”為1的所有因的組合（需要考慮到約束條件）。例：001，000。

3.在判定表中為每個“因”的組合生成一列。例：（列3）和（列4）。

4.對于每種“因”的組合，判斷所有其他“果”的狀態(tài)，并放置在對應(yīng)的每一列中。例：已得在001，000兩種組合下結(jié)點71的結(jié)果為1。判斷在“因”為001的組合下，得到70和72的結(jié)果為0。判斷在“因”為000的組合下，得到70的結(jié)果為0，72的結(jié)果為1。將“果”的狀態(tài)填入其對應(yīng)的列。

對因果圖進行回溯時，需要做到以下考慮：

1.當(dāng)回溯經(jīng)過一個結(jié)果為1的OR結(jié)點時，不要將OR結(jié)點的1個以上的輸入同時設(shè)為1。

2.當(dāng)回溯經(jīng)過一個結(jié)果為0的AND結(jié)點時，應(yīng)列舉出導(dǎo)致該結(jié)果為0的所有輸入情況的組合。然而，當(dāng)該AND結(jié)點的一個輸入條件為0時，其他輸入有一個或更多的1，則不必考慮其他輸入為1的所有情況。

3.當(dāng)回溯經(jīng)過一個結(jié)果為0的AND結(jié)點時，所有輸入皆為0的這一種情況應(yīng)當(dāng)列舉出來。

找出因果圖中，所有導(dǎo)致輸出狀態(tài)為0的輸入條件

(1)根據(jù)上述第c)條思路，我們只需列出使得結(jié)點⑤和結(jié)點⑥皆為0的情況。結(jié)點①②③④的取值狀態(tài)為：

0，0，0，0（5=0，6=0）

(2)根據(jù)第b)條思路，對于結(jié)點⑤為1而結(jié)點⑥為0的情況，應(yīng)該列出導(dǎo)致⑥為0的所有輸入情況組合。同時，只需列出一種使得⑤為1的情況即可，不需要列出⑤為1時的所有輸入情況組合。又根據(jù)第a)條思路，當(dāng)結(jié)點⑤為1時，我們不應(yīng)將結(jié)點①和②同時設(shè)為1。于是，得到結(jié)點①②③④的取值狀態(tài)：

1，0，0，0（5=1，6=0）

1，0，0，1（5=1，6=0）

1，0，1，0（5=1，6=0）

同樣的，對于⑤為0而⑥為1的情況，也只需要列出⑥為1的一種情況即可（盡管在本例中也只有這一種）。

0，0，1，1（5=0，6=1）

因果圖有助于用一個系統(tǒng)的方法選擇出高效的測試用例集。它還有一個額外的好處，就是可以指出規(guī)格說明的不完整性和二義性。但通常它不能生成全部應(yīng)該被確定的有效測試用例。

注意：因果圖方法沒有充分考慮邊界條件。建議，最好是單獨考慮邊界值分析。這不意味著我們要為此增加相應(yīng)多的測試用例，而是在由因果圖生成測試用例時，可以將邊界條件分析一并考慮進去。最好的結(jié)果是既滿足了兩方面的目標(biāo)，又不需要增加新的測試用例。

四、錯誤推測

錯誤猜測是一項依賴于直覺的非正規(guī)的過程，其基本思想是人們利用直覺和經(jīng)驗猜測可能犯得錯誤或錯誤易發(fā)情況的清單，然后編寫測試用例來暴露這些錯誤。

例如，程序輸入中出現(xiàn)0這個值，就是一種錯誤易發(fā)情況。因此可以編寫測試用例檢查特定的輸入值中有0，或特定的輸出值被強制為0的情況。同樣，在出現(xiàn)輸入或輸出數(shù)目不定的地方，如，對某個列表進行搜索，結(jié)果為“空列表”或“只包含一個”條目的列表，也是錯誤容易發(fā)生的情況。

第三篇：常見的測試用例設(shè)計方法都有哪些

/ 6

（常見）測試用例-設(shè)計方法-面試題目

常見的測試用例設(shè)計方法都有哪些？請分別以具體的例子來說明這些方法在測試用例設(shè)計工作中的應(yīng)用。

1.等價類劃分

常見的軟件測試面試題劃分等價類: 等價類是指某個輸入域的子集合.在該子集合中,各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的.并合理地假定:測試某等價類的代表值就等于對這一類其它值的測試.因此,可以把全部輸入數(shù)據(jù)合理劃分為若干等價類,在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件,就可以用少量代表性的測試數(shù)據(jù).取得較好的測試結(jié)果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.2.邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。測試工作經(jīng)驗告訴我,大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上,而不是發(fā)生在輸入輸出范圍的內(nèi)部.因此針對各種邊界情況設(shè)計測試用例,可以查出更多的錯誤.使用邊界值分析方法設(shè)計測試用例,首先應(yīng)確定邊界情況.通常輸入和輸出等價類的邊界,就是應(yīng)著重測試的邊界情況.應(yīng)當(dāng)選取正好等于,剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù),而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù).3.錯誤推測法

基于經(jīng)驗和直覺推測程序中所有可能存在的各種錯誤, 從而有針對性的設(shè)計測試用例的方法.錯誤推測方法的基本思想: 列舉出程序中所有可能有的錯誤和容易發(fā)生錯誤的特殊情況,根據(jù)他們選擇測試用例.例如, 在單元測試時曾列出的許多在模塊中常見的錯誤.以前產(chǎn)品測試中曾經(jīng)發(fā)現(xiàn)的錯誤等, 這些就是經(jīng)驗的總結(jié)。還有, 輸入數(shù)據(jù)和輸出數(shù)據(jù)為0的情況。輸入表格為空格或輸入表格只有一行.這些都是容易發(fā)生錯誤的情況?？蛇x擇這些情況下的例子作為測試用例.4.因果圖方法

前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯(lián)系, 相互組合等.考慮輸入條件之間的相互組合,可能會產(chǎn)生一些新的情況.但要檢查輸入條件的組合不是一件容易的事情, 即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當(dāng)多.因此必須考慮采用一種適合于描述對于多種條件的組合,相應(yīng)產(chǎn)生多個動作的形式來考慮設(shè)計測試用例.這就需要利用因果圖（邏輯模型）.因果圖方法最終生成的就是判定表.它適合于檢查程序輸入條件的各種組合情況.5.正交表分析法

有時候，可能因為大量的參數(shù)的組合而引起測試用例數(shù)量上的激增，同時，這些測試用例并沒有明顯的優(yōu)先級上的差距，而測試人員又無法完成這么多數(shù)量的測試，就可以通過正交表來進行縮減一些用例，從而達到盡量少的用例覆蓋盡量大的范圍的可能性。

6.場景分析方法

指根據(jù)用戶場景來模擬用戶的操作步驟，這個比較類似因果圖，但是可能執(zhí)行的深度和可行性更好。

您認為做好測試用例設(shè)計工作的關(guān)鍵是什么？

白盒測試用例設(shè)計的關(guān)鍵是以較少的用例覆蓋盡可能多的內(nèi)部程序邏輯結(jié)果

黑盒法用例設(shè)計的關(guān)鍵同樣也是以較少的用例覆蓋模塊輸出和輸入接口。不可能做到完全測試，以最少的用例在合理的時間內(nèi)發(fā)現(xiàn)最多的問題

詳細的描述一個測試活動完整的過程。

1.項目經(jīng)理通過和客戶的交流，完成需求文檔，由開發(fā)人員和測試人員共同完成需求文檔的評審，評審的內(nèi)容包括：需求描述不清楚的地方和可能有明顯沖突或者無法實現(xiàn)的功

能的地方。項目經(jīng)理通過綜合開發(fā)人員，測試人員以及客戶的意見，完成項目計劃。然后sqa進入項目，開始進行統(tǒng)計和跟蹤

2.開發(fā)人員根據(jù)需求文檔完成需求分析文檔，測試人員進行評審，評審的主要內(nèi)容包括是否有遺漏或者雙方理解不同的地方。測試人員完成測試計劃文檔，測試計劃包括的內(nèi)容上面有描述。

3.測試人員根據(jù)修改好的需求分析文檔開始寫測試用例，同時開發(fā)人員完成概要設(shè)計文檔，詳細設(shè)計文檔。此兩份文檔成為測試人員撰寫測試用例的補充材料。

4.測試用例完成后，測試和開發(fā)需要進行評審。

5.測試人員搭建環(huán)境

6.開發(fā)人員提交第一個版本，可能存在未完成功能，需要說明。測試人員進行測試，發(fā)現(xiàn)bug后提交給bugzilla。

7.開發(fā)提交第二個版本，包括bug fix以及增加了部分功能，測試人員進行測試。

8.重復(fù)上面的工作，一般是3-4個版本后bug數(shù)量減少，達到出貨的要求。

9.如果有客戶反饋的問題，需要測試人員協(xié)助重現(xiàn)以及回歸測試。

以往是否曾經(jīng)從事過性能測試工作？請盡可能的詳細描述您以往的性能測試工作的完整過程。

曾經(jīng)做過一套網(wǎng)管系統(tǒng)的性能測試，主要測試該軟件在同時管理大量終端的情況下，在響應(yīng)時間，cpu/磁盤/內(nèi)存等參數(shù)是否滿足要求。

也曾經(jīng)做過軟交換系統(tǒng)的呼叫性能測試，主要是測試軟交換系統(tǒng)在有大量呼叫的情況下，響應(yīng)時間，呼叫成功率，cpu/磁盤/內(nèi)存等參數(shù)是否滿足設(shè)計要求。

您在從事性能測試工作時，是否使用過一些測試工具？如果有，請試述該工具的工作原理，并以一個具體的工作中的例子描述該工具是如何在實際工作中應(yīng)用的。

測試網(wǎng)管系統(tǒng)中，使用的mimic來模擬終端，能夠大量的節(jié)省成本。

測試軟交換系統(tǒng)的時候，使用的prolab來模擬終端并發(fā)送呼叫軟交換，他完成了同時數(shù)百人才能完成的摘機撥號工作，主要工作原理是產(chǎn)生一些符合要求的ip包并發(fā)送給軟交換系統(tǒng)，同時對軟交換系統(tǒng)的回應(yīng)進行處理，決定下一步動作。

您認為性能測試工作的目的是什么？做好性能測試工作的關(guān)鍵是什么？

主要是保障在大量用戶的情況下，服務(wù)能正常使用。

在您以往的工作中，一條軟件缺陷（或者叫bug）記錄都包含了哪些內(nèi)容？如何提交高質(zhì)量的軟件缺陷（bug）記錄？

1.在傳統(tǒng)的bugzilla中，bug描述應(yīng)該包括以下的信息

2.和bug產(chǎn)生對應(yīng)的軟件版本

3.開發(fā)的接口人員

4.bug的優(yōu)先級

5.bug的嚴(yán)重程度

6.bug可能屬于的模塊，如果不能確認，可以用開發(fā)人員來判斷

7.bug標(biāo)題，需要清晰的描述現(xiàn)象

8.bug描述，需要盡量給出重新bug的步驟

9.附件中能給出相關(guān)的日志和截圖。

高質(zhì)量的bug記錄就是指很容易理解的bug記錄，所以，對于描述的要求高，能提供的信息多且準(zhǔn)確，很好的幫助開發(fā)人員定位。

1、黑盒測試、白盒測試、單元測試、集成測試、系統(tǒng)測試、驗收測試的區(qū)別？

軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求規(guī)格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數(shù)據(jù)驅(qū)動測試。

黑盒測試主要是為了發(fā)現(xiàn)以下幾類錯誤：

1）是否有不正確或遺漏的功能？

2）在接口上，輸入是否能正確的接受？能否輸出正確的結(jié)果？

3）是否有數(shù)據(jù)結(jié)構(gòu)錯誤或外部信息（例如數(shù)據(jù)文件）訪問錯誤？

4）性能上是否能夠滿足要求？

5）是否有初始化或終止性錯誤？

白盒測試：已知產(chǎn)品的內(nèi)部工作過程，可以通過測試證明每種內(nèi)部操作是否符合設(shè)計規(guī)格要求，所有內(nèi)部成分是否以經(jīng)過檢查。

軟件的白盒測試是對軟件的過程性細節(jié)做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結(jié)構(gòu)及有關(guān)信息，設(shè)計或選擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態(tài)，確定實際狀態(tài)是否與預(yù)期的狀態(tài)一致。因此白盒測試又稱為結(jié)構(gòu)測試或邏輯驅(qū)動測試。

白盒測試主要是想對程序模塊進行如下檢查：

1）對程序模塊的所有獨立的執(zhí)行路徑至少測試一遍。

2）對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

3）在循環(huán)的邊界和運行的界限內(nèi)執(zhí)行循環(huán)體。

4）測試內(nèi)部數(shù)據(jù)結(jié)構(gòu)的有效性，等等。

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責(zé)任編寫功能代碼，同時也就有責(zé)任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

集成測試（也叫組裝測試，聯(lián)合測試）是單元測試的邏輯擴展。它的最簡單的形式是：兩個已經(jīng)測試過的單元組合成一個組件，并且測試它們之間的接口。從這一層意義上講，組件是指多個單元的集成聚合。在現(xiàn)實方案中，許多單元組合成組件，而這些組件又聚合成程序的更大部分。方法是測試片段的組合，并最終擴展進程，將您的模塊與其他組的模塊一起測試。最后，將構(gòu)成進程的所有模塊一起測試。

系統(tǒng)測試是將經(jīng)過測試的子系統(tǒng)裝配成一個完整系統(tǒng)來測試。它是檢驗系統(tǒng)是否確實能提供系統(tǒng)方案說明書中指定功能的有效方法。（常見的聯(lián)調(diào)測試）

系統(tǒng)測試的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。

驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準(zhǔn)備就緒，并且可以讓最終用戶將其用于執(zhí)行軟件的既定功能和任務(wù)。

驗收測試是向未來的用戶表明系統(tǒng)能夠像預(yù)定要求那樣工作。經(jīng)集成測試后，已經(jīng)按照設(shè)計把所有的模塊組裝成一個完整的軟件系統(tǒng)，接口錯誤也已經(jīng)基本排除了，接著就應(yīng)該進一步驗證軟件的有效性，這就是驗收測試的任務(wù)，即軟件的功能和性能如同用戶所合理期待的那樣。

● 單元測試的主要目的是針對編碼過程中可能存在的各種錯誤，例如用戶輸入驗證過程中的邊界值的錯誤。

● 集成測試主要目的是針對詳細設(shè)計中可能存在的問題，尤其是檢查各單元與其它程序部分之間的接口上可能存在的錯誤。

● 系統(tǒng)測試主要針對概要設(shè)計，檢查了系統(tǒng)作為一個整體是否有效地得到運行，例如在產(chǎn)品設(shè)置中是否達到了預(yù)期的高性能

● 驗收測試通常由業(yè)務(wù)專家或用戶進行，以確認產(chǎn)品能真正符合用戶業(yè)務(wù)上的需要(需求)。

2、您認為做好測試計劃工作的關(guān)鍵是什么？

1）明確測試的目標(biāo)，增強測試計劃的實用性

編寫軟件測試計劃得重要目的就是使測試過程能夠發(fā)現(xiàn)更多的軟件缺陷，因此軟件測試計劃的價值取決于它對幫助管理測試項目，并且找出軟件潛在的缺陷。因此，軟件測試計劃中的測試范圍必須高度覆蓋功能需求，測試方法必須切實可行，測試工具并且具有較高的實用性，便于使用，生成的測試結(jié)果直觀、準(zhǔn)確

2）堅持“5W”規(guī)則，明確內(nèi)容與過程

“5W”規(guī)則指的是“What（做什么）”、“Why（為什么做）”、“When（何時做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”規(guī)則創(chuàng)建軟件測試計劃，可以幫助測試團隊理解測試的目的（Why），明確測試的范圍和內(nèi)容（What），確定測試的開始和結(jié)束日期（When），指出測試的方法和工具（How），給出測試文檔和軟件的存放位置（Where）。

3）采用評審和更新機制，保證測試計劃滿足實際需求

測試計劃寫作完成后，如果沒有經(jīng)過評審，直接發(fā)送給測試團隊，測試計劃內(nèi)容的可能不準(zhǔn)確或遺漏測試內(nèi)容，或者軟件需求變更引起測試范圍的增減，而測試計劃的內(nèi)容沒有及時更新，誤導(dǎo)測試執(zhí)行人員。

4）分別創(chuàng)建測試計劃與測試詳細規(guī)格、測試用例

應(yīng)把詳細的測試技術(shù)指標(biāo)包含到獨立創(chuàng)建的測試詳細規(guī)格文檔，把用于指導(dǎo)測試小組執(zhí)行測試過程的測試用例放到獨立創(chuàng)建的測試用例文檔或測試用例管理數(shù)據(jù)庫中。測試計劃和測試詳細規(guī)格、測試用例之間是戰(zhàn)略和戰(zhàn)術(shù)的關(guān)系，測試計劃主要從宏觀上規(guī)劃測試活動的范圍、方法和資源配置，而測試詳細規(guī)格、測試用例是完成測試任務(wù)的具體戰(zhàn)術(shù)。

3、你認為公司的BUG測試流程是什么？

1）當(dāng)測試工程師發(fā)現(xiàn)了一個bug而且在bug tracking tool里面沒有相同的bug, 他需要填寫所有需要的bug信息并且把這個bug分配給test leader

2）如果這個bug不是一個真正的bug, test leader需要close這個bug

3）test leader需要審查bug的各種信息都完備，如果有信息不完整，他需要把狀態(tài)改成”feedback” 并重新assign給提交者

4）如果這個bug是一個真正存在的bug, test leader需要把這個bug分配給相關(guān)的開發(fā)團隊的PM, 并且把bug狀態(tài)改成Assigned

5）如果這個bug屬于另外一個開發(fā)團隊，PM需要把這個bug重新分配給那個開發(fā)團隊的PM

6）PM審查bug,并且分配給相應(yīng)的開發(fā)人員去改正。

7）開發(fā)人員收到bug以后，對相關(guān)的缺陷進行改正，并且重新分配給提交bug的測試人員并且把狀態(tài)改成”Fixed”

8）測試人員需要對這個bug進行重新測試，保證相關(guān)的缺陷已經(jīng)改正，測試人員可以reopen這個bug如果缺陷依然存在并且重新分配給相關(guān)的開發(fā)人員或者close這個bug如果缺陷已經(jīng)改正。

4、測試人員所應(yīng)具備的知識

1）基本的測試知識，測試方法，測試用例，缺陷的概念

2）測試計劃

3）數(shù)據(jù)方面(數(shù)據(jù)庫/XML/Hibernate/LDAP)

4）表現(xiàn)層知識(JSP/HTML/Struts/CSS)

5）EAI(中間件/SOA概念, 項目相關(guān)的經(jīng)驗)

6）測試自動化知識

7）設(shè)計模式知識(UML等等)

8）敏捷實踐(TDD, Refectoring, CI等等)

9）軟件生命周期經(jīng)驗(分析，設(shè)計，團隊開發(fā)，測試，部署)

10）管理經(jīng)驗(Estimation, Mentoring, 團隊組織)

11）學(xué)習(xí)能力

5、測試類型共劃分為哪些？

1）功能測試：對軟件功能進行測試，檢查軟件的各項功能是否實現(xiàn)了軟件功能說明書（軟件需求）上的要求。

2）界面測試：對用戶界面進行測試，檢查用戶界面的美觀度、統(tǒng)一性、易用性等方面的內(nèi)容。

3）流程測試：按操作流程進行測試，主要有業(yè)務(wù)流程、數(shù)據(jù)流程、邏輯流程、正反流程，檢查軟件在按照流程操作時是否能夠正確處理。

4）并發(fā)測試：在網(wǎng)絡(luò)環(huán)境、并發(fā)環(huán)境和多用戶條件下對軟件進行的測試。

5）極限測試：在軟件的極限條件下進行的測試，主要有對數(shù)據(jù)的極限值、邊界值操作，對軟件進行致命操作等。

6）數(shù)據(jù)處理測試：對軟件數(shù)據(jù)接口進行的測試，主要檢查軟件數(shù)據(jù)處理中輸入、處理、輸出數(shù)據(jù)過程。

7）安全測試：對軟件安全性方面的測試，主要檢測軟件中加密、解密、數(shù)據(jù)備份、恢復(fù)、病毒檢測等問題。

8）性能測試：對軟件整體性能的測試，測試內(nèi)容有適應(yīng)性、健壯性、可恢復(fù)性、災(zāi)難恢復(fù)能力等

9）安裝測試：在不同PC條件、操作系統(tǒng)、模擬客戶機等條件下進行軟件的安裝測試，主要檢查軟件打包或發(fā)布之后存在的問題。

10）性能測試：對軟件整體性能進行測試，測試的內(nèi)容有適應(yīng)性、健壯性、可恢復(fù)性、災(zāi)難恢復(fù)能力等

6、你是怎么看待測試的？

1）試想一下如果一個系統(tǒng)開發(fā)完畢后不能正常運行可能造成的后果，損失錢財，損失時間，損失客戶，等等

2）介紹一下軟件測試的意義

a.發(fā)現(xiàn)軟件錯誤；

b.有效定義和實現(xiàn)軟件成分由低層到高層的組裝過程；

c.驗證軟件是否滿足任務(wù)書和系統(tǒng)定義文檔所規(guī)定的技術(shù)要求；

d.為軟件質(zhì)量模型的建立提供依據(jù)。

3）介紹一下軟件測試的目的？

a.確認軟件的質(zhì)量，其一方面是確認軟件做了你所期望的事情（Do the right thing），并且確認軟件以正確的方式來做了這個事件（Do it right）。

b.提供信息，比如提供給開發(fā)人員或程序經(jīng)理的反饋信息，為風(fēng)險評估所準(zhǔn)備的信息。

c.軟件測試不僅是在測試軟件產(chǎn)品的本身，而且還包括軟件開發(fā)的過程。如果一個軟件產(chǎn)品開發(fā)完成之后發(fā)現(xiàn)了很多問題，這說明此軟件開發(fā)過程很可能是有缺陷的。因此軟件測試的第三個目的是保證整個軟件開發(fā)過程是高質(zhì)量的。

正是基于以上所述，我認為軟件測試是整個軟件質(zhì)量保證過程中重要的一部分，這也就是我選擇軟件測試這個行業(yè)的原因

7.如何撰寫集成測試計劃？

1）確定集成測試對象

2）確定集成測試策略

3）確定集成測試驗收標(biāo)準(zhǔn)

4）確定集成測試掛起和恢復(fù)條件

5）估計集成測試工作量

6）估計集成測試所需資源

7）進行集成測試任務(wù)劃分（包括任務(wù)名、責(zé)任人、輸入和輸出、風(fēng)險及應(yīng)對措施、進度安排等）

8.測試技術(shù)方面的鬼話？

1、功能測試的規(guī)范化、流程化操作；

2、利用Robot錄制和編寫自動功能測試腳本

3、利用LoadRunner進行性能測試執(zhí)行

4、主流關(guān)系型數(shù)據(jù)庫（例如Oracle、SQLServer）的優(yōu)化策略

5、非關(guān)系型數(shù)據(jù)庫（例如Trip）的配置、安裝、常用命令等

6、非Windows操作系統(tǒng)的安裝和常用命令

7、常用服務(wù)器的安裝、配置和優(yōu)化策略（Weblogic，TomCat）

8、對系統(tǒng)存在的性能問題進行定位診斷

9、對系統(tǒng)存在的性能問題提出優(yōu)化解決方案，并配合研發(fā)和集成人員進行系統(tǒng)調(diào)優(yōu)

問hr的問題：

1.貴公司近期和遠期的發(fā)展目標(biāo)是什么？

2.貴公司的主要競爭對手有哪些？

3.貴公司有多少開發(fā)人員有多少測試人員？

4.貴公司又進一步擴充測試人員的計劃嗎?

5.如果我有幸能進入貴公司的話，我有怎么樣的發(fā)展？

6.測試人員的溝通能力很重要，貴公司有規(guī)范的溝通渠道嗎？

7.請介紹一下貴公司的福利情況。

8.請問我什么時候能知道結(jié)果？

第四篇：編寫測試用例和測試計劃

第六章 編寫測試用例和測試計劃

主要內(nèi)容：軟件測試計劃；軟件測試方案；軟件風(fēng)險分析

1.軟件測試計劃

1.1 軟件測試計劃的簡介

1測試計劃概念：測試計劃在測試中處于中心位置，它闡述了測試準(zhǔn)備工作和執(zhí)行測試的必要條件，同時也形成了測試過程質(zhì)量保證的基礎(chǔ)。

2測試計劃的作用：組織和管理測試；使測試工作和整個開發(fā)工作整合起來；資源和變更事先最為一個可控制的風(fēng)險。

1.2 如何編寫軟件測試計劃

1認識測試項目不僅僅只有單一測試計劃

2避免不分析直接進行測試階段日程安排

3避免測試任務(wù)的安排超前于開發(fā)任務(wù)

4避免有些系統(tǒng)測試類型無法按期進入測試

5不正確的變更測試計劃

6測試計劃里明確更新周期和暫停測試原則

7測試計劃不是一成不變的1.3 測試計劃包括：簡介，目的，范圍，測試策略，進度，缺陷的嚴(yán)重程度的定義，風(fēng)

險分析。

2.軟件測試方案

2.1 軟件測試方案的概念

軟件測試方案描述測試的特征，測試的方法，測試環(huán)境的規(guī)劃，測試工具的設(shè)計和選擇，測試用例的設(shè)計方法，測試代碼的設(shè)計方案。即包括以下幾點：

? 明確測試策略（黑盒，白盒，灰盒等）

? 細化測試特征

? 測試用例的規(guī)劃

? 測試環(huán)境的規(guī)劃

? 自動化測試框架的設(shè)計

? 測試工具的設(shè)計和選擇

2.2 軟件測試計劃于軟件測試方案的區(qū)別

? 測試計劃是組織管理層面的文檔。測試方案是技術(shù)層面的文檔。

? 測試方案需要在測試計劃的指導(dǎo)下進行，測試計劃提出“做什么”，測試方案明確“怎么做”

? 回報的對象不同，測試計劃向領(lǐng)導(dǎo)匯報，測試方案是組員共享該文檔

3.軟件測試的風(fēng)險

? 軟件需求風(fēng)險

? 人員的風(fēng)險

? 測試環(huán)境的風(fēng)險

? 測試工程師對產(chǎn)品的業(yè)務(wù)不熟悉

補充：

回歸測試：把以前檢查過的已經(jīng)修復(fù)好的缺陷，拿來另測看有無帶來新的缺陷 反側(cè)：把開發(fā)人員已經(jīng)處理的缺陷拿來測，看是否修復(fù)

第五篇：軟件測試中報表測試用例設(shè)計方法總結(jié)

軟件測試中報表測試用例設(shè)計方法總結(jié)

報表的測試主要分為以下幾個方面:界面,安全性,準(zhǔn)確性,展示速度(性能)

數(shù)據(jù)統(tǒng)計方面

1、報表統(tǒng)計數(shù)據(jù)的正確性；

2、報表統(tǒng)計數(shù)據(jù)的完整性；

3、報表統(tǒng)計數(shù)據(jù)的合法性；比如，統(tǒng)計金額字段需求要求有“$”等；

報表格式

1、表頭字段表示的正確性；

2、表頭字段表示的完整性；

3、表頭字段表示的字體，字號，美觀程度；

4、各統(tǒng)計字段的顯示是否滿足需求；比如：數(shù)據(jù)過長時要求折行還是縮??；

5、頁眉和頁角的表示；

報表的預(yù)覽和印刷

1、預(yù)覽中的顯示完整性；

2、多頁情況下，第2頁的表頭顯示；

3、能否實現(xiàn)需求要求的特定印刷情況；（比如，印刷使用指定的模板）

4、預(yù)覽后印刷；

5、不預(yù)覽，直接印刷

6、需求規(guī)定各類打印機的測試；

數(shù)據(jù)準(zhǔn)確性測試，帶有報表測試的系統(tǒng)分為兩類，一類是業(yè)務(wù)系統(tǒng)中，帶有統(tǒng)計分析功能模塊，該模塊中包含分析報表，這個系統(tǒng)的主體是業(yè)務(wù)系統(tǒng)，報表是為辦理業(yè)務(wù)的而提供幫助的。

比如說，應(yīng)年檢統(tǒng)計報表，某月應(yīng)交罰款車輛統(tǒng)計報表，這樣的報表數(shù)據(jù)準(zhǔn)確與否，可通過增加、刪減、修改相關(guān)業(yè)務(wù)或相關(guān)業(yè)務(wù)的參數(shù)，查看統(tǒng)計報表數(shù)據(jù)變化，檢查數(shù)據(jù)準(zhǔn)確性。

另一類是系統(tǒng)只有統(tǒng)計功能，就是我說的數(shù)據(jù)倉庫展現(xiàn)這類，它與業(yè)務(wù)系統(tǒng)分離，并且經(jīng)過多層處理，比如數(shù)據(jù)倉庫的數(shù)據(jù)，經(jīng)過抽取，清洗，展現(xiàn)前會經(jīng)過數(shù)據(jù)挖掘，數(shù)據(jù)再處理，有些字段在原始數(shù)據(jù)表中根本就沒有。這樣的數(shù)據(jù)準(zhǔn)確性測試比較復(fù)雜，當(dāng)然檢查出數(shù)據(jù)錯誤，修改定位也是很不容易的。

從整個項目節(jié)約成本看，逐層測試效果是最好的。完全修改率也是最高的。

首先建立測試數(shù)據(jù)模型，模擬所有應(yīng)用表，建立簡單易跟蹤的數(shù)據(jù)用例，底層的數(shù)據(jù)表測試，方法很原始，嘿嘿，通過SQL語句和手工計算，對數(shù)據(jù)進行比對。對系統(tǒng)中的報表數(shù)據(jù)準(zhǔn)確性測試方法較為靈活，①系統(tǒng)中報表重疊的進行比對

②對子報表匯總與父報表比對，就是對月報表匯總與年報表比對，日報表匯總與月報表比對，這只是一個方面，可以從維度關(guān)系考慮，地域，行政級別、時間，個人等方面下手，進行匯總比對

③這個方法如果延伸點呢，可以將報表間的業(yè)務(wù)邏輯關(guān)系作為比對依據(jù)。呵呵，這要看測試人員的需求了解深度個人能力了。插幾句不想干的話，做測試工作總讓我保持快樂狀態(tài)，前兩天我的一個同事說，公司里一直沒有人喜歡做測試工作，這個工作太枯燥。嘿嘿，我當(dāng)時就說我做了這么多年的測試工作從來沒有感覺到枯燥。重復(fù)性工作不代表枯燥，編程其實不也是重復(fù)嘛，人每天誰不重復(fù)昨天的事啊，吃飯，吃這個動作重復(fù)一生，有誰覺得麻煩枯燥啦？

④使用SQL和手工計算進行比對。以上是差錯方式，接下來講一下查什么錯？哪些地方容易出錯

●原始表使用錯誤：因為表比較多，又加上沒有統(tǒng)一的數(shù)據(jù)關(guān)系對應(yīng)表，很容易表使用錯誤，當(dāng)然這應(yīng)該是單元測試檢查出來的錯誤。

●數(shù)據(jù)處理邏輯錯誤：這一點容易因為測試人員和開發(fā)人員對需求理解有偏差造成爭執(zhí)，所以在需求評審時，對數(shù)據(jù)處理規(guī)則用表達式或偽代碼表示清楚。還有就是程序員失誤，邏輯編寫有偏差，邊界值、特殊情況處理不當(dāng)。

●數(shù)據(jù)權(quán)限：不同用戶對數(shù)據(jù)有著不同的查看權(quán)限。這關(guān)系到數(shù)據(jù)的安全性。

●數(shù)據(jù)誤差：數(shù)據(jù)的保留位數(shù)，數(shù)據(jù)是否是處理計算是否是最后一次計算使用了位數(shù)保留和四舍五入。

●由于字典表，數(shù)據(jù)錯誤，而造成的數(shù)據(jù)錯誤，如，根據(jù)性別統(tǒng)計，購買量，表中的男女顛倒，或者沒有考慮性別缺失項，用了ifelse,這樣就是把表中缺失該項內(nèi)容的算成了else條件里?；蛘哌壿嬛袘?yīng)該考慮用戶狀態(tài)，數(shù)據(jù)狀態(tài)類似的字段，容易被忽略，測試應(yīng)該考慮到。

●最后一項，當(dāng)數(shù)據(jù)量相當(dāng)大的時候，統(tǒng)計應(yīng)該考慮，切割速度，也就是數(shù)據(jù)的完整性，由于數(shù)據(jù)切割的滯后，帶來的數(shù)據(jù)不完整，而造成統(tǒng)計結(jié)果不完整。如統(tǒng)計昨天的銷售情況，而昨天的數(shù)據(jù)并沒有完全從業(yè)務(wù)系統(tǒng)數(shù)據(jù)到數(shù)據(jù)池，再者月底數(shù)據(jù)，由于最后一天的數(shù)據(jù)切割不完整而造成的正月統(tǒng)計數(shù)量不準(zhǔn)確。

報表的界面和輸入輸出測試

界面分為輸入界面和輸出界面；統(tǒng)一的界面要求：美觀、統(tǒng)一、易操作。

輸入界面要求是：

①輸入項字段長度不允許超過字段長度；

②輸入不符合字段要求的，不允許查詢。如money類型，在輸入漢字，字母、特殊字符等不允許查詢，并有友好的操作提示。

③用戶權(quán)限范圍外的輸入，不允許查詢。如用戶輸入不是其權(quán)限范圍內(nèi)的客戶號，不允許查詢，并有友好的操作提示。

對于選項，應(yīng)不出現(xiàn)可選擇的用戶權(quán)限以外的選項。

對于漢字模糊查詢，考慮不常見字，如“?”即漢字因譯碼問題，造成的漢字存儲出現(xiàn)亂碼問題。

輸出界面要求：

①因為是報表所以應(yīng)該有打印、打印預(yù)覽、報表導(dǎo)出等功能。不能因為報表導(dǎo)出丟失數(shù)據(jù)，不能因為打印缺少了報表表格框

②報表排列方式可調(diào)，用戶可按任意列升序或降序排列，或者，按某一關(guān)鍵列的一定規(guī)則排序

③報表標(biāo)題明確，不能含糊誤導(dǎo)用戶

④報表內(nèi)可關(guān)聯(lián)查詢的項，應(yīng)能特殊顯示，如鼠標(biāo)有箭頭變?yōu)槭终?，子報表格式與父報表格式統(tǒng)一，數(shù)據(jù)統(tǒng)一。

報表測試根據(jù)項目的定義有大有小,有時只是作為軟件的一個部分進行測試,有時整個項目都是測試各種報表.但不論如何,報表的作用始終都是將系統(tǒng)中已經(jīng)存在的數(shù)據(jù)根據(jù)用戶的設(shè)置計算加工/整理匯總/最終以清晰的格式展示給用戶,以便用戶進一步做數(shù)據(jù)分析或統(tǒng)計.軟件中的報表實現(xiàn)一般分為定義報表的所需數(shù)據(jù)(一般可以通過選擇或手工輸入條件來縮小數(shù)據(jù)范圍)和定義報表格式兩個部分.報表格式除了如國家各行業(yè)標(biāo)準(zhǔn)中規(guī)定的報表使用固定格式外,大多是根據(jù)企業(yè)或用戶的需要定制報表.所以,做報表測試時要注意以下方面:

1.數(shù)據(jù)的正確

用戶使用報表就是期望通過一個簡單方便的平臺能快速的查找到他所需要的數(shù)據(jù).所以在測試報表時首先就要檢查報表中的數(shù)據(jù)是不是用戶需要的數(shù)據(jù),如果沒有加工的數(shù)據(jù),是否保持了原貌;加工過的數(shù)據(jù)查看加工的結(jié)構(gòu)是否和手工加工的結(jié)果一致.簡言之,需要測試以下內(nèi)容.數(shù)據(jù)的來源：來源于哪張表,哪個字段,數(shù)據(jù)庫中的數(shù)值與界面數(shù)據(jù)的對應(yīng).如數(shù)據(jù)庫中性別的數(shù)據(jù)可能是0或1,但界面顯示為男或女,這個對應(yīng)關(guān)系是否正確.數(shù)據(jù)的范圍：是否只顯示了報表設(shè)置的對應(yīng)范圍；特別要注意邊界數(shù)據(jù),要清楚報表的需求,是否需要過濾掉被選擇的數(shù)據(jù).如時間選擇為200627~200727,那么是否應(yīng)該包含9-27這天.數(shù)據(jù)的對應(yīng)關(guān)系：數(shù)據(jù)庫中的字段是否與報表中的信息對應(yīng)

數(shù)據(jù)的格式：小數(shù)位,千位符,四舍五入等是否與報表設(shè)置一致；單位或稅率轉(zhuǎn)換是否正確；組合顯示的數(shù)據(jù)是否合理

數(shù)據(jù)的排序：排序方式是否與報表設(shè)置一致(如果沒有設(shè)置,是否有一個清晰的默認排序方式,如按字母或數(shù)字排序)

流水號：如報表有使用流水號,流水號的生成和格式是否正確.取消操作是否會生成流水號.明細與合計的一致性：各部分明細或小節(jié)是否與最后總和一致

其他

測試這一部分內(nèi)容需要對業(yè)務(wù)邏輯相當(dāng)熟悉,對數(shù)據(jù)庫的設(shè)計也要非常了解.必要時可以通過自己寫查詢語句查看數(shù)據(jù).有些報表的條件有多有少,但測試方法都是一樣.根據(jù)條件通過等價類劃分和排列組合設(shè)置各種條件組合.千萬不要盲目的測試,否則會導(dǎo)致該測的沒測,多余的測試做了一堆..一般來說有類別劃分的(一般界面表現(xiàn)為下拉框),每個類別都要測試到,如性別中的男,女都要測試.輸入的可以用等價類來劃分要測試的數(shù)據(jù).2.格式的正確

數(shù)據(jù)驗證正確后,就需要看看報表的輸出格式是否符合要求.可以從以下幾方面來檢查.報表的整體風(fēng)格：報表是否符合規(guī)定的或用戶設(shè)置的格式

報表標(biāo)題：報表的標(biāo)題是否是正確的報表名稱；如報表中有嵌入的數(shù)據(jù)(會跟隨用戶的選擇而變化的).需要檢查數(shù)據(jù)是否正確,如XX企業(yè)9月份財務(wù)報表,這個9月就是用戶選擇的;或者XX公司200627~200727的網(wǎng)站訪問量,這個時間段也是用戶選擇的.公司的一些標(biāo)志：如logo,名稱,地址之類的是否正確

報表的頁首與頁尾：是否采用了一致的規(guī)則.分頁：當(dāng)輸出的內(nèi)容多時,分頁是否正確.翻頁功能是否正確

友好性：數(shù)據(jù)或圖表是否清晰,一目了然,數(shù)據(jù)的展示符合用戶的習(xí)慣；需要特別提醒的數(shù)據(jù)(如合計,異常數(shù)據(jù))是否突出顯示；復(fù)雜算法處,用戶不明白或容易混淆處是否有注釋；一些默認的格式是否讓人感覺舒服,如對齊,邊界,間隔等

3.權(quán)限的控制

對于有權(quán)限控制的系統(tǒng)，報表當(dāng)然也應(yīng)該和用戶所具有的權(quán)限相一致。需要從兩方面校驗權(quán)限的控制。

報表的條件定義:在條件選擇區(qū)域，有些下拉框中應(yīng)該不能顯示用戶權(quán)限范圍外的數(shù)據(jù)。如普通文員在使用報表時，報表名稱下拉框中是不可以顯示管理者才能查看的報表的。有些以輸入的文本框有級別的劃分時，都應(yīng)該要測試輸入超越權(quán)限的數(shù)據(jù)的相應(yīng)。

注意這里一定要測試每個條目。

報表內(nèi)容：報表中的內(nèi)容不能顯示用戶本沒有權(quán)限查看的數(shù)據(jù)。

4.報表的輸出

報表在電腦上生成后，并不是報表的結(jié)束。報表一般都需要打印出來他用，如開會或者提交審批之類。所以報表的打印功能也是非常重要的。測試主要分成三部分：

●打印設(shè)置

●打印預(yù)覽

●實際打印效果

除了打印之外，用戶有可能需要導(dǎo)出報表做進一步的分析或用于和其他報表的比較。所以也應(yīng)該提供導(dǎo)出報表的功能。一般可以導(dǎo)出為CSV,Excel,pdf,html,xml格式。