•  办公自动化系统的简介

办公自动化即 Office Automation ，简称 OA 。

目前流行的办公自动化系统多采用多层体系结构，其应用服务架构位于中间层之上，客户端通过常用的 IE 浏览器界面访问系统，具有接口统一、访问简单、易升级、易扩充的特点。

就以上特点来说，办公自动化系统的测试可以使用 B/S 结构的测试策略来组织。

下面我们就从软件工程过程的几个阶段 — 需求、设计、编码，分阶段地来进行分析如何针对办公自动化系统组织测试分析。

•  针对 OA 需求、设计的特点组织测试分析

办公自动化系统擅长处理类似公告、公文等流转类型的行政办公类应用需求、设计及相对独立的个人相关资料、名片、记事等个人事务类的需求、设计。

办公自动化系统软件的权限管理是其不同于其他应用软件的另外一个特点。系统需要为使用人员提供设置不同的权限和访问许可的功能，管理员可以通过调整各功能模块的访问权限，设置一般用户某些功能可以用，某些功能不允许用；并为员工创建、注销帐号及访问权限。提高了企业系统的资料的安全度，阻止非授权人的非法进入系统。

•  针对流转型的行政办公需求、设计

流转型的行政办公需求、设计通常包括有：拟稿、审核、签收、会签、拟办、签批、电子签名、交办、退稿、备查、提交归档、打印、销毁等业务处理功能。在行政办公的业务流程处理中还牵涉到复杂的用户权限和访问许可的功能。

针对这种情况，在进行测试需求分析和设计时，最好使用现成的公司体制来进行分析。这样做的好处有两个：

•  沟通方便。

现成的公司体制中的角色和人员比每个测试人员自己单独构造虚拟的用户权限和访问许可要容易理解和容易沟通的多。

对于测试执行过程中发现缺陷时，描述的缺陷让开发人员和测试人员沟通起来更加方便。

•  测试数据准备容易，且不易产生歧异。

由于 OA 系统使用的对象是整个公司所有员工或者是某部门员工，如果我们使用现成的公司体制，我们只需要统一准备一套测试数据就可以满足所有测试对象的要求。

测试人员在沟通时，不会由于构造的数据不同，而引起不必要的歧异，人为的增加测试组内部沟通的障碍。

•  针对独立型的个人事务需求和设计

独立性的个人事务通常包括有：维护并查看个人和公共的活动日程安排，并能自动提醒所有个人的待办事项，允许用户可以查询各种信息。但个人事务通常只允许用户本人维护和查看个人的事务，不允许其他用户维护和查看。目前有的 OA 系统中甚至包括管理员在内的超级用户也不能维护和查看私人的个人事务处理情况。

针对上面的特殊情况，在进行测试需求分析和设计时，首先要考虑统一给不同用户打上特殊标记。接下来在准备测试数据时，应避免不同用户具有相同的个人信息和相关资料的情况产生，以免在测试执行过程中测试人员陷入混乱状态，连测试人员自己都搞不清楚到底使用的是哪一个用户的信息。

•  针对 OA 编码的功能特点组织测试分析

常见的 OA 系统功能模块主要有：行政办公、个人事务、综合信息、基础服务四个部分。

•  行政办公

行政办公通常包括收文管理、发文管理、档案管理和会议管理等模块。有的 OA 系统还包括有接待管理、办公资源管理模块。

这四个模块是典型的流转型模块，它们都有流程定义、登记（或拟稿）、办理、拟稿、审核、签收、会签、拟办、签批、电子签名、交办、退稿、备查、提交归档、打印、销毁、归档、查询、流程跟踪、查看意见、重定位等操作过程。

以收文管理为例，主要对公文进行登记和处理，包括内部公文和外部公文。在登记收文过程中提供了多种种方式，比如文件引入、电子公文调入、扫描和直接输入，并将登记后的收文送领导批示或阅读（批示的流程完全可以根据用户的需要自己定义，也可以使用系统管理员已经定义好的公文批示流程），处理结束后将文件进行归档。管理人员可以对收文处理全过程进行监督、催办、重定位，也可以随时进行文件流程跟踪及查看其所有领导的批示意见、批示时间。

针对这些情况，在进行测试分析和设计时，首先按照上面提到的根据现成的公司体制进行分析和设计的测试数据，然后将各个领导是否兼职的情况区分开来。通常建议准备这样两套数据：

•  领导不兼职

领导不兼职的情况，相对较简单，即每个领导只负责一个批示。

在执行测试过程中，还需要重点注意批示的并行和串行的情况。

•  领导兼职

领导兼职的情况，即每个领导可能负责不同过程中多个批示，是流转型模块测试的一个难点，需要特别注意。

跟上面的情况一样，同时也要考虑批示的并行和串行的情况。在测试执行过程中，其组合方式是否能够全面覆盖，与测试人员的经验、对模块的需求和设计熟悉程度、测试数据准备是否充分以及测试人员是否考虑周到全面等因素息息相关。

•  个人事务

个人事务通常包括：待办工作、日程安排、个人资料、个人名片、个人记事本、外出声明等模块。有的 OA 系统还包括个人邮件、及时消息模块。

个人事务以其独立性，完成个人日常的办公工作，例如批阅各部门上报的各种公文，评阅同事交流的各种文件内容，回复或发送电子邮件，起草各类报告，查看个人的活动日程、外出等安排，系统能自动提醒待办事项。

以个人名片为例，用户可将名片登记并进行管理查询和打印，同时可根据需要将部分名片共享，供他人使用。每个人只能看到自己的名片集及共享的名片集，通过所有由个人收集的名片以及整个单位的名片总集，可很快找出所需要联系的名片主人，并方便地通知他们参加会议或发送邮件等等。

在进行测试分析、设计和执行中需要特别考虑：

•  新建或修改的名片时对于输入重复的名片是否给予提示警告；

•  新建或修改的名片时个人维护的私有名片是否能被其他人看到或使用；

•  个人删除私有名片时是否影响到其他用户的名片；

•  共享的名片是否可以被其他人正确查看和使用；

•  单位的名片集修改后，是否正确影响个人的单位名片集；

•  给需要联系的名片主人联系时，是否可以正确联系上，其联系内容是否显示正确；

•  综合信息

综合信息通常包括：建议管理、电子论坛、网上调查、电子贺卡、信息采集等模块。

以信息采集为例，信息采集可以通过各种渠道，从所有可利用的信息源收集办公需要的信息，从各种媒体采集各种相关信息后作为原始信息记录在案，经过筛选整理后编辑成各种主题的信息刊物。同时信息刊物也支持套红头转入行政办公的公文模块中。可以方便地查询、检索信息刊物及其所有原始信息内容。并对信息采用和阅读情况、次数进行统计。

在进行测试分析、设计和执行时要重点考虑：

•  从信息来源收集信息时，是否能正确完好的保存其原始信息的内容和格式；

•  整理后的信息是否能正确完好的保存其原始信息的内容和格式；

•  整理后的信息是否能正确转入公文流程中；

•  基础服务

基础服务包括：人员注册、部门设置、数据维护等模块。

以数据维护为例：系统为系统的管理员提供了多项数据维护的服务。可以对一些常用的数据进行设置，包括用户登录名 / 用户密码组合方式、用户登录名 / 用户密码长度、主题词、常用意见、自动编号、存储大小、存储时间和公文格式，也可以对行政办公中所要使用的各个流转模块的流程进行预定义。

在进行测试分析、设计和执行时要特别考虑：

•  用户登录名 / 用户密码组合方式设置是否正确；

•  用户登录名 / 用户密码长度设置是否正确、有效；

•  存储大小设置是否正确、有效；对于超出设定的存储大小系统是否能正确提示；

•  预定义的行政办公中各个流转模块是否能被正确应用；

•  小结

OA 系统的某些业务与其他知识管理系统相类似，但由于其鲜明的特点，目前已经自成体系。

本文介绍的测试分析主要与 OA 特有的业务处理方法紧密联系，作为测试人员介入 OA 项目时如何有重点的进行测试分析。

与其他 B/S 结构的系统所要进行的界面测试、边界测试、非法校验、字段限制等方法一样，在实际执行测试过程之前都需要一一进行分析，在此就不赘述了。