办公自动化系统的简介

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

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

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

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

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

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

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

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

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

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

　　沟通方便。

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

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

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

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

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

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

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

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

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

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

　　行政办公

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

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

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

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

　　领导不兼职

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

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