信息管理系统软件测试总结.docx
《信息管理系统软件测试总结.docx》由会员分享，可在线阅读，更多相关《信息管理系统软件测试总结.docx（15页珍藏版）》请在冰豆网上搜索。
信息管理系统软件测试总结
信息管理系统测试总结
――张林2011-4-25
目录
1.编写本文档的目的2
2.OA办公系统简介2
2.1OA系统是什么2
2.2OA办公系统的特点3
3.软件测试过程3
4．OA办公系统的测试策略4
4.1功能测试4
4.1.1纯功能点性测试4
4.1.2流程测试5
4.2性能测试5
4.2.1性能测试需求调研6
4.2.2性能测试计划7
4.2.3性能测试方案7
4.2.4性能测试实施7
4.2.5性能测试结果分析8
4.2.6性能调优8
4.2.7性能测试报告8
4.3安全性、访问控制性测试9
4.3.1登入测试9
4.3.2功能权限10
4.3.3数据权限10
4.3.4特殊约束11
4.3.5管理员权限11
4.4数据准确性测试11
4.5旧系统数据测试12
4.6兼容性测试12
4.7操作易用性及界面友好性测试13
4.8故障转移和恢复测试14
1.编写本文档的目的
在最近的两三年中一直在测试信息管理系统，但很少做总结，借于jackei的提问，将零散的思维做一下整理，作为经验总结。
本文以OA为切入点，但整个信息管理系统测试也大致相同。
2.OA办公系统简介
2.1OA系统是什么
以下信息摘自于网络搜索
1）OA办公系统即OA，是OfficeAutomation的缩写，指办公室自动化或自动化办公。
A、OA办公系统不仅仅是企业办公的一种工具，更应该是一种有思想、有模式的懂管理的软件，目前市场上主流的协同OA办公系统就为现代企业发展注入了强劲的动力，协同OA办公系统是在研究现代组织实践案例和管理理论发展方向的基础上，结合神经网络的研究成果而设计的协同管理系统。
它以动态组织为行为主体，以工作流为传导模型，以任务为处理模型，将组织行为的复杂性通过三者的结合充分表现出来，从而帮助实际组织解决管理过程中的复杂课题。
B、OA办公系统将执行中的三个要点：
执行者、目标与过程管控，通过动态组织、工作流和任务三者，将执行相关的各种信息和应用紧密集成在一起，并用权变组织、网状沟通、关联结构和控制反馈四个管理模型实现各个执行体之间的融会贯通和统一管理，从而为企业提供实现人力资源、资金资源、产品资源、客户资源、知识资源的高度整合和统一的工具，帮助企业逐步走向虚拟管理、敏捷办事和互动沟通的高级形态。
C、能够将组织管理中的业务活动、管理活动及活动产生的信息在组织、部门、个人之间进行及时高效、有序可控、全程共享的沟通和处理。
D、过去在组织的信息化建设过程往往重视人、财、物这些有形的物质资产管理，忽视了知识资产的管理，需要借助知识管理工具对组织内外的知识进行有效的获取、沉淀、共享、应用、学习和创新，从而提高员工的素质和技能、执行力。
E、办公系统是组织内使用面最广泛、频率最高的信息系统，希望能够通过办公系统实时、直观地了解到组织的运营状况（如生产、营销、财务等数据），同时有效地解决组织内“信息孤岛”问题。
综合上述各种新的需求不难发现，现阶段的OA系统将以知识管理为核心、以实时协作为技术支撑手段，以统一的知识门户为展现方式。
2.2OA办公系统的特点
看了上段什么是OA办公系统，不难总结出它的特点：
1）源自于非网络时代的手工办公、纸质办公。
所以OA办公系统的原始需求源自于手工办公，其工作模式源自于原有的工作模式，结合网络特点、优势，来优化或改变原有的工作模式；
2）资源（人力、物力、财力、时间、知识等）和信息（计划、任务、进度、质量、现场监控等）的整合。
使资源和信息完整、快速的反映到相关人员面前，为决策和任务的跟踪提供支持；
3）实现跨地域合作办公，大大提高工作效率；
4）知识积累，方便检索；
5）节约纸张、绿色环保。
3.软件测试过程
鉴于本文档想作为一个完整的解决方案，所以，提到软件测试过程是必须的。
通用的软件测试过程包括：
了解系统、制定测试计划、制定测试方案（总体测试方案和测试用例）、开发、测试实施、编写测试报告
1）了解系统
原则上说，测试应该尽早的介入了解被测系统的需求。
实际上根据项目的实际情况适时介入，可以参与需求调研，也可以从需求比较稳定后开始介入。
主要目的：
了解系统。
知道系统是什么？
做什么用的？
有哪些功能？
测试难易度？
明确需求、开发等相关接口人。
2）制定测试计划
在了解系统的基础上，根据项目的总体计划，制定相应测试计划。
在测试实施过程中，根据实际情况对测试计划进行变更，以适合当前的测试工作。
主要目的：
约定、明确测试的时间、参与的人员、划分测试阶段、每个阶段的输入条件及输出物。
3）制定测试方案
包括测试环境、测试策略（测试类型、测试方法、目标等）、测试工具、制定缺陷跟踪流程、明确测试结束条件。
主要目的：
明确测试的环境，选择需要的测试类型，而不是所有测试类型，选择合适的测试工具。
4）开发
主要是测试脚本开发、测试数据准备，有时可能修改系统某些功能已方便测试。
主要目的：
为测试的实施做好必要的测试环境。
5）测试实施
根据测试计划和测试方案，对被测系统进行有序、有效的测试。
对发现的缺陷进行持续跟踪。
6）编写测试报告
根据每个版本的测试结果，编写测试报告，向项目组和相关人反馈系统质量情况，为下一阶段项目工作调整提供依据和参考。
4．OA办公系统的测试策略
在前面一段描述的测试过程当中，很大部分都是通用的，除了测试策略。
每一种系统有它自己的特点，在测试策略方面也会有所侧重。
对于OA办公系统来说，总结为如下几个：
1）功能测试
2）性能测试
3）安全性、访问控制性测试
4）数据准确性测试
5）旧系统数据测试
6）兼容性测试
7）操作易用性及界面友好性测试
8）故障转移和恢复测试
下面逐个说明为什么选择这些测试类型和每种测试类型的测试重点。
4.1功能测试
功能测试是每个系统都必须要测试的类型，用以保证确保被测系统实现了客户的基本使用要求。
如果该项测试没有通过，基本上该系统完全不符号要求。
进行测试，首先需求是必须要了解的；其次设计，数据间的关联也是要了解的；最后，数据的约束也是要了解的。
至于测试方法，简单归纳如下。
4.1.1纯功能点性测试
1）单独功能点测试，测试单独功能点实现是否正确；
2）有关联功能点之间的测试，测试两个功能点之间的影响是否正确，子系统与子系统之间的关联是否正确；
3）权限相关测试，测试对应权限的登入者操作权限及数据权限是否正确；
4）功能点附属功能的测试，比如附件增删改，表单打印等。
4.1.2流程测试
1）场景拆分，设置主场景及分支场景：
测试流程走向是否正确；考虑前面环节的数据对流程流转走向的影响是否正确。
2）测试场景各环节的测试：
a.表单字段值的延续性（变/不变）、准确性及表单读写控制是否正确；
b.当前处理人选择下一环节处理人时，选择的范围是否正确，特殊要求是否实现，比如正职必须放在副职前面等；
c.单据所处状态的准确性；
d.流程跟踪准确性，包括流程走向及历史意见记录。
3）异常场景的测试：
收回、退回、平级转他人处理、会签部分人同意部分人不同意、多人并发处理，插入流程的正常流转中，检查前面A和B中的项目是否正确。
4）权限相关测试，测试对应权限的登入者操作权限及数据权限是否正确。
如对哪些单可以看到哪些不能看到，哪些可以看到但不能操作等。
4.2性能测试
在项目紧张的开发过程中，很容易忽略性能问题，可能在设计之初就已经埋下了隐患，所以在系统试用后即使在使用人数很少、基础数据量很小的情况下也会出现性能问题。
以前我不相信，现在我相信了，目前碰到的一个案例，实际使用人数才不到50人，基础数据还不到1万条，结果发现系统登入经常很慢，查询也很慢，以至于客户相当怀疑我们系统的处理能力。
经查，结果发现登入首页显示待办、已办、办结，反复调用工作流接口，且工作流还是公司原来用.NET开发的，我们的系统全部用的是java开发，据分析反复调用可能不稳定，且为显示这些数据反复调用效率低下，后改为这些数据直接从数据库取，不经过工作流接口，效率得到了很大的提高。
所以系统上线之前对系统常用或关键业务进行性能测试还是比较重要的。
性能测试的目的：
目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。
主要包括：
包括以下几个方面
一． 评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
二． 识别体系中的弱点：
受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
三． 系统调优：
重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
检测软件中的问题：
长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
四． 验证稳定性（resilience）可靠性（reliability）：
在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
在性能测试实际开展过程中，也遵循测试过程通用规则：
性能测试需求调研、性能测试计划、性能测试方案、性能测试实施、性能测试分析、性能调优、结果评估与测试报告。
其中：
一、后面4个过程可能有一个反复的过程；
二、性能测试实施包括：
测试环境、工具、数据准备－>测试脚本录制、编辑与调试－>场景设定－>测试执行－>获取测试结果；
三、性能调优是个可选项，根据测试目的的不同，可能只要求出一个测试报告即可。
4.2.1性能测试需求调研
性能测试需求调研主要做三件事情：
1、本次性能测试的目的和目标。
是调优性质还是验证性质；
2、从整个系统无穷的业务/操作域中，找出典型业务，通常是广泛使用和关键性业务；
3、确定性能指标。
还有两件必须弄清楚的事情：
1、什么时候开始？
什么时候结束？
2、明确谁来做本次性能测试的实施人、业务支持接口人是谁、技术支持接口人是谁。
要获得上面的信息，一方面可以从系统规划和需求说明书中入手，另一方法要与项目组和客户进行充分的沟通。
最表象的方式是回答如下问题：
在什么测试环境下，在多少基础数据量的情况下，多少人并发，做什么事情，响应时间是多少。
至于：
容量测试、负载测试、疲劳测试可根据调研结果根据需要进行取舍。
具体实施可采取案卷调查的形式来进行，根据反馈的结果整理出初步的场景和性能指标，与客户确认，最终达成一致。
这里产生的成果，很大程度上影响到后续的测试执行和对性能测试工作好坏认可度。
有人和我反映说：
我做了性能测试，但项目组说做了和没做一样，得不到认可。
我们从两个方面来分析：
1、你自己做的确实好不好？
2、做的结果达到了目标没有？
其中的第二个问题就是要在这里找客观参考数据的。
说明：
《性能测试需求调研问卷－实例》见附录
二、负载压力测试需求分析原理之80～20原理
Ø80～20原理测试强度估算
基本概念：
每个工作日80％的业务在20％的时间内完成。
例如：
每天工作8个小时，那么每天80％的业务在8*20％＝1.6小时内完成。
4.2.2性能测试计划
性能测试计划主要描述：
测试目的、目标、测试范围、测试环境、测试时间、执行人、通过准则等。
4.2.3性能测试方案
性能测试方案是在确定性能测试需求的情况下，为达成性能测试目标而设计的一套方案。
主要描述：
测试目的、测试环境、测试工具、测试方法、测试场景/用例
测试方案中，测试场景/用例的设计占了很大的比例。
是“在什么测试环境下，在多少基础数据量的情况下，多少人并发，做什么事情，响应时间是多少。
”的具体实现。
实际执行性能测试时，先将多个典型业务分来进行测试，最后再将几个业务组成一个场景进行混合场景测试。
但混合场景中，各业务占的比例在需求调研中应该调研回来。
4.2.4性能测试实施
性能测试实施主要依照性能测试方案，对各种场景进行执行测试，记录有效的测试结果。
获取事务响应时间和服务器（软、硬件）和网络的性能指标。
执行过程包括：
测试环境、工具、数据准备－>测试脚本录制、编辑与调试－>场景设定－>测试执行－>获取测试结果
注意：
1、脚本编辑中调试通过后，还要用控制台进行并发执行的调试，否则可能出现编辑器中运行通过，但运行场景时失败的问题；
2、性能测试执行过程中一定要对有效的执行结果做好记录，避免发生不该被覆盖的文件被覆盖的情况。
建议目录结构如下：
01文档02测试场景03测试脚本04测试结果05其他
每种文件存放在相应的目录下面，文件命名制定简单易懂的规则，不建议设置直接覆盖结果。
录制脚本过程中要设置好事务、集合点、检查点等，还可能遇到各种各样的问题，需要做一些技术上的处理，如：
跨域、参数化、关联等，不在此详述。
4.2.5性能测试结果分析
参考《LoadRunner进行性能测试过程讲解》中相关章节。
4.2.6性能调优
经过性能测试结果分析，如发现系统性能不理想，则需要进行系统调优。
首先，明确性能调优的责任人（这里就用到前面技术接口人），再开始做下面的事情。
一、根据分析结果，找出需要重点关注的区域。
如：
web服务器、数据库服务器的相关配置、可能出问题的程序块等；
二、根据需要可能要进行额外的测试，比如在程序中加入更多的有针对性的输出，设置LR输出全部执行日志或有针对性的设置场景，以便从这些不同的场景和这些日志中发现问题的踪迹；
三、对被测系统可疑地方进行调整，然后再执行性能测试。
注意：
每次测试最好只改变一个变量，方便定位问题；
四、完整记录每一次测试结果，对比系统每次调整后的性能结果，找出真正有效的解决的方法；
五、因为有些对系统改动策略有副作用（比如去掉部分小功能），综合考虑所有因素，找出一种最优的解决方案；
六、再次测试，验证该方案对系统的性能提升是有效的。
4.2.7性能测试报告
一般是以Word/PDF格式文档或者电子邮件形式存在。
而测试报告的读者，一般是整个项目组的管理者甚至更高层面、相关同事比如开发人员等，他们并不一定具备多少测试背景知识，因此，测试报告要尽量避免测试术语，要用容易理解的话语进行叙述。
另外，它不应该是性能测试结果的简单罗列：
因为阅读对象通常而只关心报告中测试结论是否合理以及结论的内容。
所以性能测试工程师在编写测试报告时，首先要明确阅读这份报告的对象是谁，不能从自己角度出发来写报告，而是使阅读对象能看的明白，所以给不同的阅读对象，可能报告格式及内容繁简可能稍有不同。
测试报告内容一般分为测试目的、测试方法、测试环境、测试数据概括总结、测试结果分析、结论这几大部分。
在实际工作中的要求不尽相同，每个公司会有自己的模板，因此在文档结构上并无一定之规。
但内容方面大致相同。
完成一份好的性能测试报告，最好做到如下几点：
一）提交报告的时机。
做完性能测试应及时反馈给项目组相关领导和同事。
二）有效地总结概括测试数据。
不要只是简单的原始数据成列。
三）报告应该清楚易读，结合图表，但不能滥用图表。
四）报告要具备较强的逻辑性。
要具有层次感，几个部分区分明显、清楚。
五）系统问题突出标识，让人一眼就能知道问题所在。
性能测试报告模板参见附录。
4.3安全性、访问控制性测试
OA办公系统日常使用中与权限相关的操作主要包括：
1、登入；2、数据录入；3、数据审批；4、数据查看；5、管理员管控。
系统要控制不该进的系统不能进，不该做的事情不能做，不该看的数据不能看，不是管理员就不能有超大的系统控制权力。
归纳到软件系统中，为：
登入权限、功能操作权限、数据权限和管理员权限。
这些权限控制了系统使用的方方面面，以达到前面所说的控制目标。
但往往在实际测试过程当中，为测试方便起见，都赋予了测试账号极为广泛的权限，所以在测试用例设计阶段就要考虑到有安全性问题要测试，以免遗漏。
如果权限真的出了问题，某人冒充领导审批多少钱的款项，那就问题大去了。
安全性、访问控制性的测试，按照操作来分，要考虑如下方面：
1）登入测试
2）功能权限测试
3）数据权限测试
4）特殊约束
5）管理员权限
4.3.1登入测试
登入只代表你能进入这个系统，但并不表示你就能看到和操作里面的东西。
A、登入采用输入框登入模式
要保证正确的账号和密码能登入进去；账号和密码其中一项错误都不能进去。
B、登入采用key等第三方工具
这种登入模式主要要选好厂商，最好是有权威机构认证的。
而对OA协同办公的系统的测试人员来说，就没有必要对key里面东西进行详细测试了，只是测试这个工具能不能正常使用，硬件和系统里面注册的证书匹配时且在有效期内，可以正常登入；不匹配或过期均不能登入。
另外还要考虑：
1、Key拔出后，系统是否还能使用；
2、一个Key能不能同时在多台电脑上使用；
3、一台电脑上能否同时使用多个Key。
C、是否采用首页门户登入各个子系统首页
1、登入门户首页后再登入子系统首页，不需要再输入用户密码验证；
2、单独进入子系统首页需单独验证。
D、考虑有没其他办法非法入侵的（比较专业，没弄过）。
4.3.2功能权限
赋予功能操作权限，表示你可以查看或操作某些模块，某些菜单，某些按钮，但是并不表示你能看到或操作这个模块里面的所有数据，可能只能操作一部分或仅仅你自己新建的数据。
测试项目：
1、赋权了可读写权限的功能，可以查看和操作；
赋权只读权限的功能，只可以查看不能操作；
没有赋予功能权限的功能看不到；
2、更改功能权限设置，系统反应做相应的变化；取消功能权限，不可以查看/操作；
3、考虑单独账号赋权和集合方式赋权的方式，集合方式赋权如角色赋权或岗位赋权等，与单独账号赋权有同等效用。
4.3.3数据权限
赋予数据权限，表示看到哪些数据，一些敏感的数据，是要进行隔离的，比如某个单位的合同，就只有相关公司能够看到，其它公司不能看到。
测试项目：
1、默认数据权限，比如本人能看到本人添加的数据，本人能看到本部门的数据，根据业务规则来定；
2、赋权了可读写权限的数据，可以查看和操作；
赋权只读权限的数据，只可以查看不能操作；
没有赋予数据权限的数据看不到；
3、更改功能权限设置，系统反应做相应的变化；取消数据权限，不可以查看/操作；
4、考虑单独账号赋权和集合方式赋权的方式，集合方式赋权如角色赋权或岗位赋权等，与单独账号赋权有同等效用。
数据权限的测试项和功能权限测试项比较类似，并且通常配合使用。
4.3.4特殊约束
除了功能权限和数据权限外，根据业务需求有一些特殊的约束，用功能权限和数据权限均无法配置，直接在程序里面写死了，比如在什么情况下某个按钮或某些数据可以显示出来，其他情况下不显示出来等。
这种比较细节的约束比较零散，需收集整理。
根据业务和程序设计进行测试。
另外一种是常用的功能，公文审批。
公文审批过程中涉及到盖章或签名，这两种都是电子办公的重要组成部分，使用签名或盖章表示这份文的正式性和有效性。
通常OA系统都是使用的第三方成熟的控件，所以对控件本身测试相对较少，主要是对系统对它们的使用上是否达到了要求。
测试项目：
1、签名或盖章功能使用正常；
2、防伪处理。
如文件签名或盖章后再修改，要使签名和盖章作废。
4.3.5管理员权限
管理员分为系统管理员和业务管理，而系统管理员根据客户要求又有可能再细分二级管理员等。
系统管理员通常注册账户、分配操作权限等，可能看不到某些业务数据；而业务管理员通常对某一些业务的数据进行专门的授权。
如果不区分的话，系统管理员也充当业务管理员的角色。
测试项目：
1、系统管理员能够进行账号注册、维护操作；
2、系统管理员能够授权和取消授权操作，且授权和取消授权后立即生效；
3、业务管理员能够看到自己应该看到的数据，并可以授权给其他人，且可以取消授权；
4、业务管理员不能够看到不应该看到的数据。
4.4数据准确性测试
数据准确性，一方面包括数据传递的准确性，一方面包括数据报表的准确性。
通常我们专门进行数据准确性测试一般都是关注的数据报表的准确性，因为数据传递的准确性在功能测试的过程中都有测试到，而数据报表相对复杂，所以专门做为一个测试项目来单独测试，也表现了它的重要性。
按报表展现方式来分，分为：
浏览性报表和统计性报表。
浏览性报表：
报表上面展现的数据来源比较单一，比较简单，基本上是系统某一个功能数据的展现，关联性也不强，给人一种很直接的感觉；
统计性报表：
报表上面展现的数据来源比较复杂，可能来至于多个业务数据，多个报表上的数据，数据关联性比较复杂。
但这两种测试有相同的测试方法，如下：
1）了解被测报表要统计的项，了解数据来源及数据汇总公式；
2）根据业务特点、及常见单位转换准备测试数据，整理原始数据表；
a.根据业务，各种业务数据来源齐备
（如入库数量：
包括正常采购入库、盘盈入库、调拨入库等；又如合同中有申请变更，准备数据时必须准备有申请变更通过和未通过的数据）；
b.应包含在统计报表中的数据；
c.业务相关，但不应该包含在统计报表中的数据；
d.单位转换：
金额、数量、小数点四舍五入
3）权限相关测试，测试对应权限的登入者操作权限及数据权限是否正确（如报表中只统计操作者所在公司的数据，不应该统计到他同级子公司的数据）
两种报表测试不同的地方在于，统计性报表测试要花很多时间理清楚来龙去脉，要花较多的精力。
数据准确性测试通常要用到一些数据整理表格，主要包含输入数据、数据关系和输出结果，无固定格式，但做出来表格一定要思路清醒，容易理解，否则很难用。
4.5旧系统数据测试
有些项目上OA办公系统是因为原来的OA办公系统已经不能满足需要了，再用新的系统替换原来的系统，这样就存在一个原来旧系统中的数据如何处理的问题，要么旧系统中的数据在就系统中处理完，要么旧系统中的数据通过某种方式弄到新系统中继续处理。
第一种方式相对简单，不需要做多少事情。
但通常有一种要求就是把旧系统中处理完的资料导入到新系统中来，方便查看。
对于这种处理的测试，主要检查：
1）导过来的数据条数是不是和原来的一样
2）每条记录的信息是不是和原来的一样
3）旧系统和新系统中字段不一定完全对应，可能名称不一样，可能多字段或少字段，要注意检查有数据对应对不对，多出来的字段是留空还是默认填写什么值。
第二种方式相对复杂，除了检查第一种方式的几个事项外，还要检查单据在新系统中能否继续处理，处理过程中有没有反写旧系统中的数据，反写的数据是不是对的。
4.6兼容性测试
现在的OA办公系统多采用web访问方式，因为很多台不同的客户端同时在用，而每个客户端所用的操作系统、IE版本都不同，甚至电脑某些用到的控件版本不同，都有可能导致系统某些功能无法正常使用。
软件相关兼容性测试主要考虑如下几个方面：
1）操作系统的兼容性
2）浏览器的兼容性
3）OA办公系统所用到的控件的兼容性
操作系统
目前常见个人办公电脑的操作系统一办都是windows系统（常见版本有XP、2003、Windows7、简体版、繁体版等），不排除有用li
升级会员 