針對辦公自動化系統軟件的測試分析方法

【摘要】 目前 OA 系統軟件在軟件項目中占有一定的比重，本文主要針對 OA 系統軟件需求，給出相應的軟件測試分析的基本思路。

 

　　· 辦公自動化系統的簡介

　　辦公自動化即 Office Automation ，簡稱 OA 。

　　目前流行的辦公自動化系統多采用多層體系結構，其應用服務架構位于中間層之上，客戶端通過常用的 IE 瀏覽器界面訪問系統，具有接口統一、訪問簡單、易升級、易擴充的特點。

　　就以上特點來說，辦公自動化系統的測試可以使用 B/S 結構的測試策略來組織。

　　下面我們就從軟件工程過程的幾個階段 — 需求、設計、編碼，分階段地來進行分析如何針對辦公自動化系統組織測試分析。

　　· 針對 OA 需求、設計的特點組織測試分析

　　辦公自動化系統擅長處理類似公告、公文等流轉類型的行政辦公類應用需求、設計及相對獨立的個人相關資料、名片、記事等個人事務類的需求、設計。

　　辦公自動化系統軟件的權限管理是其不同于其他應用軟件的另外一個特點。系統需要為使用人員提供設置不同的權限和訪問許可的功能，管理員可以通過調整各功能模塊的訪問權限，設置一般用戶某些功能可以用，某些功能不允許用;并為員工創建、注銷帳號及訪問權限。提高了企業系統的資料的安全度，阻止非授權人的非法進入系統。

　　· 針對流轉型的行政辦公需求、設計

　　流轉型的行政辦公需求、設計通常包括有：擬稿、審核、簽收、會簽、擬辦、簽批、電子簽名、交辦、退稿、備查、提交歸檔、打印、銷毀等業務處理功能。在行政辦公的業務流程處理中還牽涉到復雜的用戶權限和訪問許可的功能。

　　針對這種情況，在進行測試需求分析和設計時，最好使用現成的公司體制來進行分析。這樣做的好處有兩個：

　　· 溝通方便。

　　現成的公司體制中的角色和人員比每個測試人員自己單獨構造虛擬的用戶權限和訪問許可要容易理解和容易溝通的多。

　　對于測試執行過程中發現缺陷時，描述的缺陷讓開發人員和測試人員溝通起來更加方便。

　　· 測試數據準備容易，且不易產生歧異。

　　由于 OA 系統使用的對象是整個公司所有員工或者是某部門員工，如果我們使用現成的公司體制，我們只需要統一準備一套測試數據就可以滿足所有測試對象的要求。

　　測試人員在溝通時，不會由于構造的數據不同，而引起不必要的歧異，人為的增加測試組內部溝通的障礙。

　　· 針對獨立型的個人事務需求和設計

　　獨立性的個人事務通常包括有：維護并查看個人和公共的活動日程安排，并能自動提醒所有個人的待辦事項，允許用戶可以查詢各種信息。但個人事務通常只允許用戶本人維護和查看個人的事務，不允許其他用戶維護和查看。目前有的 OA 系統中甚至包括管理員在內的超級用戶也不能維護和查看私人的個人事務處理情況。

　　針對上面的特殊情況，在進行測試需求分析和設計時，首先要考慮統一給不同用戶打上特殊標記。接下來在準備測試數據時，應避免不同用戶具有相同的個人信息和相關資料的情況產生，以免在測試執行過程中測試人員陷入混亂狀態，連測試人員自己都搞不清楚到底使用的是哪一個用戶的信息。

　　· 針對 OA 編碼的功能特點組織測試分析

　　常見的 OA 系統功能模塊主要有：行政辦公、個人事務、綜合信息、基礎服務四個部分。

　　· 行政辦公

　　行政辦公通常包括收文管理、發文管理、檔案管理和會議管理等模塊。有的 OA 系統還包括有接待管理、辦公資源管理模塊。

　　這四個模塊是典型的流轉型模塊，它們都有流程定義、登記(或擬稿)、辦理、擬稿、審核、簽收、會簽、擬辦、簽批、電子簽名、交辦、退稿、備查、提交歸檔、打印、銷毀、歸檔、查詢、流程跟蹤、查看意見、重定位等操作過程。

　　以收文管理為例，主要對公文進行登記和處理，包括內部公文和外部公文。在登記收文過程中提供了多種種方式，比如文件引入、電子公文調入、掃描和直接輸入，并將登記后的收文送領導批示或閱讀(批示的流程完全可以根據用戶的需要自己定義，也可以使用系統管理員已經定義好的公文批示流程)，處理結束后將文件進行歸檔。管理人員可以對收文處理全過程進行監督、催辦、重定位，也可以隨時進行文件流程跟蹤及查看其所有領導的批示意見、批示時間。

　　針對這些情況，在進行測試分析和設計時，首先按照上面提到的根據現成的公司體制進行分析和設計的測試數據，然后將各個領導是否兼職的情況區分開來。通常建議準備這樣兩套數據：

　　· 領導不兼職

　　領導不兼職的情況，相對較簡單，即每個領導只負責一個批示。

　　在執行測試過程中，還需要重點注意批示的并行和串行的情況。

　　· 領導兼職

　　領導兼職的情況，即每個領導可能負責不同過程中多個批示，是流轉型模塊測試的一個難點，需要特別注意。

　　跟上面的情況一樣，同時也要考慮批示的并行和串行的情況。在測試執行過程中，其組合方式是否能夠全面覆蓋，與測試人員的經驗、對模塊的需求和設計熟悉程度、測試數據準備是否充分以及測試人員是否考慮周到全面等因素息息相關。

　　· 個人事務

　　個人事務通常包括：待辦工作、日程安排、個人資料、個人名片、個人記事本、外出聲明等模塊。有的 OA 系統還包括個人郵件、及時消息模塊。

　　個人事務以其獨立性，完成個人日常的辦公工作，例如批閱各部門上報的各種公文，評閱同事交流的各種文件內容，回復或發送電子郵件，起草各類報告，查看個人的活動日程、外出等安排，系統能自動提醒待辦事項。

　　以個人名片為例，用戶可將名片登記并進行管理查詢和打印，同時可根據需要將部分名片共享，供他人使用。每個人只能看到自己的名片集及共享的名片集，通過所有由個人收集的名片以及整個單位的名片總集，可很快找出所需要聯系的名片主人，并方便地通知他們參加會議或發送郵件等等。

　　在進行測試分析、設計和執行中需要特別考慮：

　　· 新建或修改的名片時對于輸入重復的名片是否給予提示警告;

　　· 新建或修改的名片時個人維護的私有名片是否能被其他人看到或使用;

　　· 個人刪除私有名片時是否影響到其他用戶的名片;

　　· 共享的名片是否可以被其他人正確查看和使用;

　　· 單位的名片集修改后，是否正確影響個人的單位名片集;

　　· 給需要聯系的名片主人聯系時，是否可以正確聯系上，其聯系內容是否顯示正確;

　　· 綜合信息

　　綜合信息通常包括：建議管理、電子論壇、網上調查、電子賀卡、信息采集等模塊。

　　以信息采集為例，信息采集可以通過各種渠道，從所有可利用的信息源收集辦公需要的信息，從各種媒體采集各種相關信息后作為原始信息記錄在案，經過篩選整理后編輯成各種主題的信息刊物。同時信息刊物也支持套紅頭轉入行政辦公的公文模塊中?？梢苑奖愕夭樵?、檢索信息刊物及其所有原始信息內容。并對信息采用和閱讀情況、次數進行統計。

　　在進行測試分析、設計和執行時要重點考慮：

　　· 從信息來源收集信息時，是否能正確完好的保存其原始信息的內容和格式;

　　· 整理后的信息是否能正確完好的保存其原始信息的內容和格式;

　　· 整理后的信息是否能正確轉入公文流程中;

　　· 基礎服務

　　基礎服務包括：人員注冊、部門設置、數據維護等模塊。

　　以數據維護為例：系統為系統的管理員提供了多項數據維護的服務?？梢詫σ恍┏Ｓ玫臄祿M行設置，包括用戶登錄名 / 用戶密碼組合方式、用戶登錄名 / 用戶密碼長度、主題詞、常用意見、自動編號、存儲大小、存儲時間和公文格式，也可以對行政辦公中所要使用的各個流轉模塊的流程進行預定義。

　　在進行測試分析、設計和執行時要特別考慮：

　　· 用戶登錄名 / 用戶密碼組合方式設置是否正確;

　　· 用戶登錄名 / 用戶密碼長度設置是否正確、有效;

　　· 存儲大小設置是否正確、有效;對于超出設定的存儲大小系統是否能正確提示;

　　· 預定義的行政辦公中各個流轉模塊是否能被正確應用;

　　· 小結

　　OA 系統的某些業務與其他知識管理系統相類似，但由于其鮮明的特點，目前已經自成體系。

　　本文介紹的測試分析主要與 OA 特有的業務處理方法緊密聯系，作為測試人員介入 OA 項目時如何有重點的進行測試分析。

　　與其他 B/S 結構的系統所要進行的界面測試、邊界測試、非法校驗、字段限制等方法一樣，在實際執行測試過程之前都需要一一進行分析，在此就不贅述了。

 

原文轉自：http://www.anti-gravitydesign.com