七、测试计划
1．引言... 1
1.1编写目的... 1
1.2项目背景... 2
1.3定义... 2
1.4参考资料... 2
2．任务概述... 2
2.1目标... 2
2.2运行环境... 2
2.3需求概述... 2
2.4条件与限制... 2
3．计划... 3
3.1测试方案... 3
3.2测试项目... 3
3.3测试准备... 3
3.4测试机构及人员... 3
4．测试项目说明... 3
4.1测试项目名称及测试内容... 3
4.2测试用例... 3
4.3进度... 3
4.4条件... 3
4.5测试资料... 3
5．评价... 3
5.1范围... 3
5.2准则... 3
1．引言
1.1编写目的
在开发大型软件的漫长过程中，面对极其错综复杂的问题，人的主观认识不可能完全符合客观现实，与工程密切相关的各类人员之间的通信和配合也不可能完美无缺。因此，在软件生命周期的每个阶段都不可避免地会产生差错。尤其对于人事管理系统这类会影响人们生活．财产的工程软件，必须尽量减少差错，以免造成严重的损失。测试是“为了发现程序中的错误而执行程序的过程”。测试的目的就是在软件投入生产性运行之前，尽可能多的发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明．设计和编码的最后复审，也是必不可少的关键步骤。
1.2项目背景
本项目（人事管理系统）时由XXX公司委托，由<>负责开发。
1.3定义
事务流：数据进入模块后可能有多种路径进行处理。
主键：数据库表中的关键域。值互不相同。
外部主键：数据库表中与其他表主键关联的域。
ROLLBACK: 数据库的错误恢复机制。
1.4参考资料
1． 人事管理系统项目计划任务书 XXX公司
2． 人事管理系统项目开发计划 《》软件开发小组
3． 用户操作手册（初稿） 《》软件开发小组
4． 软件工程及其应用 周苏、王文等 天津科学技术出版社
5． 软件工程 张海藩 清华大学出版社
2．任务概述
2.1目标
测试是“为了尽可能的发现软件中的错误，而不是为了证明程序的正确性”, 测试的目的就是在软件投入生产性运行之前，按照测试的原则就要求，尽可能多的发现软件中的错误。
2.2运行环境
硬件要求：PI 133以上处理器，最低32M内存，300M以上硬盘剩余空
间。
运行环境：win98/winNT4.0/win2000/winxp
2.3需求概述
XX公司为方便人事管理，需开发一个人事管理系统。为便于职工信息查询以及工资情况统计，XX公司把职工的信息，包括姓名、性别、年龄，工资等信息输入机票人事管理系统的数据库，然后在管理终端可以对数据进行查询和修改操作。
要求系统能有效、快速、安全、可靠和无误的完成上述操作。并要求系统界面要简单明了，易于操作，程序利于维护。
2.4条件与限制
必须在保证各硬件设备．软件系统齐备的情况下，资金充足，人员齐备，各方面互相配合，齐心协力，共同完成。
3．计划
3.1测试方案
测试方案是测试阶段的关键技术问题。为了提高测试效率降低测试成本，本测试方案采用黑盒法设计基本的测试方案。在黑盒法测试方案中，采用等价划分技术，把所有可能的输入数据（有效的和无效的）划分成几等价类，其划分类在以下的输入中再详述。
3.2测试项目
身份认证模块
人员信息查询模块
人员信息维护模块
人员信息统计模块
工资查询模块
工资维护模块
（这里以人员信息维护为例子）
3.3测试准备
在测试前，与各模块的主要负责人共同协商讨论，以概要设计说明书.详细设计说明书作为总的提纲,选择合适的输入输出数据,并加以意义列举说明。
3.4测试机构及人员
测试机构由XXX工作组组成，人员有软件开发小组全体人员。
4．测试项目说明
人员信息维护模块见《人员信息维护模块》
4.1测试项目名称及测试内容
测试项目：
waitforsignal（）是否可以接受用户操作信息。
Add() 是否可以在数据窗口中增加新的空白行。
Delete（）是否可以删除选中行。
Modify（）是否可以将选中行变为可编辑状态。
Cancle（） 返回上一界面。
Reset（）清空可编辑行
Ok（）保存当前数据窗口的内容到数据库。
4.2测试用例
4.2.1输入
4.2.2输出
1．点击《增加》按钮，数据窗口中出现新的空白行。
输入编号为001的新的信息，将与已有信息发生冲突，系统给出提示。
点击《确定》后，输入合法数据，可以通过。
2．输入以上数据，有一项内容为空时给出提示，说明数据不完整。
3．对于非法输入情况报告错误，如上例中编号为Aaa。
4．格式错误，如最后一个用例，出生日期为19870908，不符合日期格式。
5．点击《重置》按钮，可编辑项清空。
6．点击《取消》按钮，返回上一级界面。
4.2.3步骤及操作
按照测试用例输入用户ID，操作员编码和用户口令，点击《确定》。如果打算中途退出，点击《取消》，系统将返回XXX公司微机网络管理系统主菜单。
4.2.4允许偏差
所有测试结果要按照预期输出进行，不可以有任何偏差。
4.3进度
详细设计完成之后，一天完成测试计划，第二天完成测试
4.4条件
符合系统运行条件的设备即可；
由开发者进行测试。
4.5测试资料
数据要求说明书
概要设计说明书
详细设计说明书
测试计划
5．评价
5.1范围
由于各个模块是相对独立进行测试，只能证明单独模块设计比较完善，所以需要最后进行组合测试，确保模块可以协调工作。
5.2准则
我们要知道测试是软件开发过程中一个非常重要的环节，一各好的软件必须经过无数次的测试。软件测试是保证软件质量的关键步骤。所以在测试过程中必须抱着不骄不躁．谦虚谨慎的态度，努力发现每一个出现的错误，并要仔细寻找能够发现尽可能多的错误的测试用例，不要以为你已经发现所有错误，往往没有发现的错误跟已经发现的错误是成比例的。
第二篇：软件测试计划模板
iCollege项目
测试计划
目 录
第一章 引言......................................................... 1
1.1. 编写目的............................................................ 1
1.2. 项目背景............................................................ 1
1.3. 定义............................................................... 1
1.4. 参考资料............................................................ 1
第二章 任务概述..................................................... 1
2.1. 目标............................................................... 1
2.2. 用户需求概述........................................................ 1
2.3. 关键设计和实现技术说明............................................... 1
2.4. 条件与限制.......................................................... 1
第三章 测试计划..................................................... 1
3.1. 测试方案............................................................ 1
3.2. 关联测试............................................................ 1
3.3. 系统测试............................................................ 1
3.4. 测试用例设计........................................................ 1
第四章 系统测试设计.................................................. 1
4.1. 版本兼容性测试...................................................... 1
4.2. 性能测试............................................................ 1
4.3. 恢复测试............................................................ 1
4.4. 安全性测试.......................................................... 1
4.5. 压力测试............................................................ 1
第五章 评价准则..................................................... 1
5.1. 范围............................................................... 1
5.2. 准则............................................................... 1
第一章 引言
1.1. 编写目的
本文档是关于软通动力公司iCollege项目的功能及性能的要求，重点描述了iCollege平台的设计需求。说明测试关注内容和测试方案，为测试的执行和质量评估提供依据和指导。
预期读者：管理者、用户及开发人员、测试人员。
1.2. 项目背景
针对系统包括前台修改内容、后台修改内容、积分系管理统、考试管理系统、问卷调查管理系统、新员工入职管理。本文档将对每一块功能进行详细的描述。
第二章 任务概述
2.1. 目标
各功能应用普通文字或图表描述。并同时指出功能实现与业务需求的关系，即此功能实现了哪一部份的业务需求。为测试的执行和质量评估提供依据和指导。
2.2. 用户需求概述
在这一部分应对所有的软件需求进行足够详细的描述。详尽程度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试计划和编写测试用例为准。
按系统功能的体系结构组织本章内容。
2.2.1. 系统用户
2.2.2. 主要业务需求
1.前台首页部分描述当客户登陆平台后，显示页面包括的内容如下：
（1）Logo由客户提供风格图片，增加讲师管理【讲师入口】、培训管理【管理员入口】
（2）组成：由网络课堂、学习超市、资讯中心、积分中心四部分组成
（3）原“推荐网站”位置，改为在网站最下方显示，打开方式改为弹出方式显示。
（4）原“站点统计”位置，改在网站右下角显示。
（5）主页显示：待处理任务（未完成的学习、未完成的授课）、课程宣传、讲师宣传三大部分。
（6）左侧固定显示：我的学习、我的授课。
（7）左侧个性化菜单为用户为设定。保留原始功能。
（8）只改变页面风格，原功能保持不变。
2.网络课程描述当客户点击首页网络课堂后，显示页面包括的内容如下：
（1）显示：待处理任务（未完成的学习、未完成的考试、未完成的问卷、未完成的授课）、课程宣传、讲师宣传三大部分。
（2）左侧固定显示：我的学习、我的授课、我的问卷、我的考试、我的网络课堂。
（3）左侧个性化菜单为用户人为设定。保留原始功能。
（4）只改变页面风格，原功能保持不变。
3.学习超市部分描述当客户点击首页网络课堂后，显示页面包括的内容如下，见图1-3：
（5）显示：课程信息【原我要学习内容】、讲师宣传两大部分。
（6）左侧固定显示：已报班级。
（7)左侧个性化菜单为客户人为设定。保留原始功能。
（8）只改变页面风格，原功能保持不变。
3.咨询中心描述当客户点击首页咨询中心后，显示页面包括的内容如下：
（1）显示：共享资源、课程宣传、讲师宣传三大部分。
（2）左侧固定显示：无。
（3）左侧个性化菜单为客户人为设定。保留原始功能。
（4）只改变页面风格，原功能保持不变。
4.讲师管理描述用户将可以申请讲师、课程，并且可以对自己的课程的评价进行查看【课程评价体现在每门课中，不单独显示菜单】，点击右上方讲师管理后，显示页面包括的内容如下：
（1）显示：待处理任务【我未完成的授课、我完成的授课】。
（2）左侧固定显示：讲师申请、课程申请。
（3）左侧个性化菜单为客户人为设定。保留原始功能。
（4）只改变页面风格，原功能保持不变。
2.2.3. 功能需求
1.后台首页部分描述当管理员点击首页培训管理后，显示页面包括的内容如下：
（1）“管理首页”、“前台”等横排功能键全部删除，只保留左侧竖排功能键
（2）“新员工培训”改为“新员工特训营”。功能保留原始功能。
（3）“培训需求-关注度统计” 位置该模块改置左侧竖排功能键下方。
（4）“系统设置”位置该模块改置左侧竖排功能键下方。
（5） 只改变上述的位置，上述功能保持不变。
2.讲师库管理部分描述当管理员点击讲师库管理后，页面修改的内容如下：
（1）由于有一些讲师，存在离职的可能，所以师资来源增加“离职”这个状态，可修改讲师状态为“离职”状态。
（2）讲师列表查询条件“师资来源”增加“离职”一列，并在列表显示，以便查询
（3）学员不可对离职讲师进行关注。
（4) 离职讲师不出现在讲师宣传中
3.学员管理部分描述当管理员点击学员管理后，页面修改的内容如下：
（1）学员查询列表：增加学员在职、离职状态一列。数据来自PSA系统同步。
（2）所在部门处增加放大镜（弹出公司组织结构），只弹出“组织结构”页供参考，不
做选择联动。
4.课程关注度统计管理部分描述当管理员点击课程关注度统计后，页面修改的内容如 下：
（1）修改原始功能课程关注度汇总，修改后体现历史关注度。如当某门课程开始后该关注度变为0，如查看以前关注度，则需要查看历史关注度。
（2）在列表中点击“课程名称”，只显示该课程的“讲师”，并显示该课程的N次关注度列表，并可以显示总关注度点击“详细信息”显示关注学员。
（3）点击“讲师”，显示该讲师课程的N次关注度，并可以显示总关注度。
（4）点击“详细信息”显示关注学员。
5.培训管理部分描述当管理员点击发布培训后，页面修改的内容如下：
（1）只修改发布培训的页面内容 。其它则保持不变。
（2）在现有页面功能上添加开班地址一列。选择方式【单选】，一次培训班只可选择一个开班地址。该功能的目的是：前台员工在进行该培训班报名的时候，会根据该员工的工作地点和开办地点进行比对，如不同只给与提示“您不属于当前区域，费用需自理” ，无其他业务逻辑。如相同则进行正常报名。
2.3. 关键设计和实现技术说明
1.后天功能样式备注说明，用以说明以上内容为后台在原始版本上待修改的内容，后台页面【主页面、增、删、改、查】页架构不变，只做页面色调的微调。未提及的功能均保留原始功能。保留原始模块，以上面提及的后台修改内容为准。以下为本次改版不做修改的模块。如表1-1所示。
2.考试管理系统
该功能将取代原有系统的考试管理系统。主要用于学员的考试。不与现有系统其它环节进行挂钩，只和新员工入职考试关联。可以做到管理员自定义试题，管理员自定义考卷【选择试题】，学员前台进行答卷【题目为后台自定义随机的题目】，系统自动判分，并保留考生成绩。
（1）题库管理
l 题型：包括【单选、多选、判断】三种题型。每题选择一种题型。
l 题目：试题的题干描述【唯一性】。
l 选项：单选题、多选题一般A~F六个选项，每道题最多6个选项。判断题只有“对”、“错”两个选项。无问答题。
标准答案：每道题有唯一的标准答案，符合标准答案本题才能得分，否则不得分
（2）试卷管理
该部分内容用于管理试卷，管理员可建立试卷，选择题库中的试题放入试卷，并设定出题数目。试卷满分100分，60分及格。
l 试卷标题【唯一性】
l 试卷说明，以复文本编辑器的方式输入，
l 添加试题：可添加多个试题。
l 设定随机出题数
l 设定是否为作为当前使用试卷
（3）考生答案
考生可对试题进行作答，该功能只和员工转正挂钩，可以查询考生是否通过入职考试，不和其它功能挂钩。
考试者登陆看到的内容包括两部分，以分页的形式出现：
待考试卷：未参加的考试和未及格的试卷都会显示在这里，点击试卷名称进行考试。
已答试卷：已经考及格的试卷会显示在这里，可以看到每张试卷的分数，点击试卷名称可以看到答题情况及正确答案。
l 分数计算方法：每张试卷满分100分，每道题的分数为100/随机题数，实际得分为【100/题目数目*答对的题数】，答案完全符合标准答案即为答对。
l 考试通过的考卷不可再进行答题，只可查看考卷。
3.新员工状态管理
在新员工入职考试后，如果通过学习【显示未参加考试】，考生方可参加入职答题考试，考试通过后，可以从新员工页面进行查询。
4.问卷调查管理系统
该功能取代原有系统的问卷调查管理系统。主要用于学员的问卷调查和答题。不与现有系统其它环节进行挂钩，做到用户自定义试题，用户自定义问卷【选择试题】，学员前台进行答卷。
（1）题库管理
该部分内容用于管理题库，可建立试题放入题库，可对未引用的题库进行维护操作。
l 题型：包括【单选、多选、判断】三种题型。每题选择一种题型。
l 题目：即试题的题干描述【唯一性】。
l 选项：单选题、多选题一般A~F六个选项，每道题最多6个选项。判断题只有“对”、“错”两个选项。无问答题。
l 标准答案：不设立标准答案。
（2）问卷管理
该部分内容用于管理问卷，可建立问卷，选择题库中的试题放入问卷。
l 问卷标题【唯一性】
l 问卷说明，以复文本编辑器的方式输入，
l 添加试题，
l 设定是否为当前问卷
（3）考生答问卷
考生可对试题进行作答，该功能不和其它功能挂钩。问卷调查每张问卷只可答题一次。
考试者登陆看到的内容包括两部分，以分页的形式出现：
待答问卷：未答问卷都会显示在这里，点击问卷名称进行考试。
已答问卷：已答完问卷会显示在这里。
5.新员工入职管理
该功能是实现新员工转正前的入职学习、入职考试，通过后，员工方可正常使用iCollege功能。
新员工通过账号登陆本系统后，只能对当前系统进行查看操作，可注册积分账户，不可进行网络课堂学习，不可下载共享资源，不可在线选课、不可申请讲师。
新员工登陆系统后，可以看到页面的所有功能，并且只能够学习管理员指定的网络课堂的课程。学习通过后可以进行入职考试。 新员工状态转为【未参加考试】
（1）新员工入职考试
该部分内容用于学员登录平台后已经进行过在线学习网路课堂制定课程后，进入在线考试环节。
新员工通过账号登陆本系统后，只能对当前系统进行查看操作，不可进行网络课堂学习，无可下载共享资源，不可报名课程、不可申请讲师。
新员工登陆系统后，可以看到页面的所有功能，并且只能够学习管理员指定的网络课堂的课程，也可进行在线考试。
l 在线考试通过后不能再进行入职考试，但是还可查看入职学习视频，管理员可以进行新员工确认。新员工状态转为【已通过考试】
l 考试未通过则可再次进行考试。直到考试通过为止，考试不限制次数。
（2）新员工确认
l 管理员登录系统后，可以将【已通过考试】状态的员工转为正式员工。
l 员工转正之后，可以和正式员工享有相应的权限。
l 本系统提供接口，人事系统输入员工编号，可以查询到该员工的状态，来确认员工是否具备转正的条件。
Ø 新员工状态显示【未参加学习、未参加考试、已通过考试、已确认】四种。
l 未参加学习：没有参加学习
l 未参加考试：没有参加考试
l 已通过考试：已通过考试并合格60分。该状态可以转正
l 已确认：已转正的正式员工。
6.积分管理系统
（1）“管职”升级规则管理
l 官职升降级说明：
n 官职：从九品官到正一品，共18级。
n 俸禄：每天登陆平台只可领取一次俸禄。
n 官职分类：京官、武官、地方官
u 京官优势：升级花费减少20%
u 武官优势：发帖赏金加倍
u 地方官优势：俸禄增加50%
n 升级费用：每次升级所需的银两。升级后的优点：会拿更多的俸禄。每次升级不允许跳级升级，只可按照该顺序进行升级。
l 官职升降级管理点：
n 官职升级不允许跳级升级。
n 官职首次登陆，开始选择官职类型，一旦选择后，后期不可进行官职类型修改。
n 18级官职的个数、顺序、每级的俸禄、每级升级的费用后台不允许进行维护，这是固定的值。
n 18级官职对应的图片后台不可进行维护。
n 18级官职的名字：例如(翰林院侍诏、钦天监监候)后台提供维护界面，是可以进行维护的。
（2）银两奖励/消耗规则管理
l 银两奖励/消耗管理点：
n 奖励/消耗银两的项目后台不可进行维护。
n 后台提供：奖励/消耗项目的银两数量的维护界面，故可对银两数量进行维护。
n 关于银两奖励/消耗的操作项、规则、触发事件见1-2、1-3、1-4表。
（3）用户积分管理——账号新建
该部分内容用于用户新建账号。
l 用户名：手动填写【必填项】
l 选择官职类型：下拉选择（选择项：京官、武官、地方官）【必选】，该官职一旦选中以后不可进行修改。
如果员工不进行建立账号，则进入系统后无法进行积分系统操作项的相关操作。
（4）用户积分管理——查看个人积分
l 页面功能说明：
n 个人信息：该信息来自员工基本信息，图片为该官职对应的图片。如图1-18所示。
n 领取日俸禄：每日只可领取一次，当日有效，不做累计
n 培训讲师领取月俸禄：每月只可领一次，当月有效，不做累计。
n 积分详情：该信息是用户用于查询相关积分收入查询的功能。
u 查询条件介绍
n 积分来源：选择方式下来选择【全部、收入、支出】
n 开始日期：做区间选择
n 结束日期：做区间选择
u 消费记录介绍
n ID：编号
n 操作：【如表1-2、1-3、1-4】表格的操作项。
n 积分变更：为该次操作的积分变化
n 日期：该次操作的日期
注：消费记录只显示操作的项目，不显示具体操作的那个事物。
（5）用户积分管理——后台管理员查看用户积分状况
该部分内容用于后台管理员查看员工当前积分。
显示员工信息表，可按照人员姓名作为模糊查询项，查询出相应的员工，点击某条记录“查看积分”列，可以查看到该员工的详细积分。如图1-19所示。
注：查看“详细积分”中的消费记录只显示操作的项目，不显示具体操作的那个事物。
2.4. 条件与限制
1.软件环境需求
2.硬件环境
数据库服务器
WEB应用服务器
客户端
第三章 测试计划
3.1. 测试方案
测试过程按三个步骤进行，即单元测试、组装、系统测试，根据不同阶段测试的侧重点不同，分别介绍测试策略：
3.2. 关联测试
1.单元测试
首先按照系统、子系统和模块进行划分，但最终的单元必须是功能模块，或面向对象过程中的若干个类。单元测试是对功能模块进行正确检验的测试工作，也是后续测试的基础。目的是在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发设计测试用例，着重考虑以下五个方面：
1）模块接口：对所测模块的数据流进行测试。
2）局部数据结构：检查不正确或不一致的数据类型说明、使用尚未附值或尚未初始化的变量、错误的初始值或缺省值。
3）路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。
4）错误处理：检查模块有没有对预见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。
5）边界：注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。
2.集成测试
集成测试也叫组装测试或联合测试。通常，在单元测试的基础上需要将所有的模块按照设计要求组装成系统，这时需要考虑的问题：
1）在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失。
2）一个模块的功能是否会对另一个模块的功能产生不利的影响。
3）各个子功能组合起来，能否达到预期要求的父功能。
4）全局数据结构是否有问题。
5）单元模块的误差累积起来，是否会放大，从而达到不能接受的程度。
我们在组装时可参考采用一次性组装方式或增殖方式组装方式。
3.3. 系统测试
系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一致，主要是下列类型的测试：
1）用户界面测试：测试用户界面是否具有导航性、美观性、行业或公司的规范性、是否满足设计中要求的执行功能。
2） 性能测试：测试相应时间、事务处理效率和其他时间敏感的问题。
3） 强度测试：测试资源（内存、硬盘）敏感的问题。
4） 容量测试：测试大量数据对系统的影响。
5） 容错测试：测试软件系统克服软件、硬件故障的能力。
6） 安全性测试：测试软件系统对非法侵入的防范能力。
7） 配置测试：测试在不同网络、服务器、工作站的不同软硬件配置条件下，软件系统的质量。
8） 安装测试：确保软件系统在所有可能情况下的安装效果和一旦安装之后必须保证正确运行的质量。
3.4测试用例设计
1.各个模块测试用例
2.集成测试用例
填写说明：
1）“软件项代号”是来自于软件功能结构划分中的规定，由“本系统接口软件项代号_对方接口系统软件项代号”格式确定。
2）“需求规格说明”是来自于《需求分析说明书》和《概要设计说明书》中的需求和设计要求。
3）“测试用例”是根据《需求分析说明书》和《概要设计说明书》来制定的。
4）“预期输出”是根据《需求分析说明书》和《概要设计说明书》来制定的。
3.系统内部接口测试
填写说明：
1）“软件项代号”是来自于软件功能结构划分中的规定，由“本系统接口软件项代号_对方接口系统软件项代号”格式确定。
2）“方案代号”是由测试方案编写人员根据实际情况制定的。
3）“需求规格说明”是来自于《需求分析说明书》和《概要设计说明书》中的需求和设计要求。
4）“测试用例”是根据《需求分析说明书》和《概要设计说明书》来制定的。
5）“预期输出”是根据《需求分析说明书》和《概要设计说明书》来制定的。
4.系统测试用例
（1）病毒测试
填写说明：
1）“软件项代号”是来自于软件功能结构划分中的规定。
2）“方案代号”是由测试方案编写人员根据实际情况制定的。
3）“需求规格说明”是来自于《需求分析说明书》和《概要设计说明书》中的需求和设计要求。
4）“测试用例”是根据《需求分析说明书》和《概要设计说明书》来制定的。
5）“预期输出”是根据《需求分析说明书》和《概要设计说明书》来制定的。
第四章 系统测试设计
4.1. 版本兼容性测试
1.Web兼容性测试的主要类型
Web兼容性测试主要是针对不同的操作系统平台，浏览器，以及分辨率进行的测试。
1.1 操作系统兼容性测试
常见的操作系统有Windows，Unix，Linux等，对于普通用户来讲，最常用的是Windows操作系统。Windows操作系统包括Windows XP，windows 2003，ista Win2000/NT，Windows9X等等。用户使用操作系统的类型，直接决定了我们操作系统平台兼容性测试的操作系统平台数量，进行操作系统平台的兼容性测试的主要目的就是保证我们的待测试项目在该操作系统平台下能正常使用。
对于一些特殊项目（比如定制项目），可以指定某一类型的操作系统版本，这些都应该在需求规格说明书中指明，针对这些指明的操作系统版本必须进行兼容性测试。
大部分的其他项目，是不指定操作系统版本的，针对这样的项目，我们应当针对当前主流操作系统版本进行兼容性测试，在确保主流操作系统版本兼容性测试的前提下，在对非主流操作系统版本进行测试，尽量保证项目的操作系统版本的兼容性测试的完整性。
1.2 浏览器兼容性测试
浏览器是Web系统中对核心的组成构建，来及不同厂家的浏览器对Javascript、ActiveX或不同的HTML规格有不同的支持，即使是同一厂家的浏览器、也存在不同的版本的问题。不同的浏览器对安全性和JAVA的设置也不一样。
目前最为常用的浏览器为：IE 6.0 IE 7.0，但由于操作习惯的问题，还有相当一部分用户喜欢使用腾讯TT，以及FireFox浏览器，这些浏览器同样也存在各个版本的问题，这个对于Web系统来讲是一个相当大的挑战。
对于一些特殊项目（比如定制项目），可以指定某一类型的浏览器（包括版本），这些都必须在需求规格说明书中指明，针对这些指明的浏览器必须进行兼容性测试，但大部分的项目，是不能指定浏览器的，针对这样的项目，那么我们必须针对当前的主流浏览器（含版本），在确保主流浏览器的兼容性测试通过的前提下，在对非主流浏览器（含版本）进行测试，尽量保证项目的浏览器的兼容性测试的完整性。
1.3分辨率兼容性测试
分辨率的测试是为了页面的版式在不同的分辨率模式下能正常显示，字符符合要求而进行的测试。
用户使用什么模式的分辨率，对于我们来讲是未知的，通常情况下，在我们的需求规格说明书中会建议某些分辨率。对于测试来讲，必须针对需求规格说明书中建议的分辨率进行专门的测试。现在常见的分辨率是1024*768，800*600.对于需求规格说明书中规定的分辨率，测试必须保证测试通过，但对于其他分辨率，原则上也应该尽量保证，但犹豫这个在需求规格说明书中没有加以约束，所以在一定程度上，开发往往会拒绝进行挑整。对于需求规格说明书中没有规定分辨率的项目，测试应该在完成主流分辨率的兼容性测试的前提下，尽可能进行一些非主流分辨率的兼容性测试，在一定程度上保证大部分。
4.2. 性能测试
1.网络应用性能分析
网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。
（1）利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间
（2）利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。
2.网络应用性能监控
在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。
（1）利用网络应用性能监控工具，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。
3.网络预测
考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。
从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。
应用在服务器上性能的测试
对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器 性能4.测试图像
设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。 UNIX资源监控指标和描述监控指标描述平均负载 系统正常状态下，最后60秒同步进程的平均个数 冲突率 在以太网上监测到的每秒冲突数进程/线程交换率 进程和线程之间每秒交换次数CPU利用率 CPU占用率（%）磁盘交换率 磁盘交换速率接收包错误率接收以太网数据包时每秒错误数包输入率 每秒输入的以太网数据包数目中断速率 CPU每秒处理的中断数输出包错误率 发送以太网数据包时每秒错误数包输入率 每秒输出的以太网数据包数目读入内存页速率 物理内存中每秒读入内存页的数目写出内存页速率 每秒从物理内存中写到页文件中的内存页数目或者从物理内存中删掉的内存页数目内存页交换速率 每秒写入内存页和从物理内存中读出页的个数进程入交换率 交换区输入的进程数目 进程出交换率 交换区输出的进程数目系统CPU利用率 系统的CPU占用率（%） 用户CPU利用率 用户模式下的CPU占用率（%）磁盘阻塞 磁盘每秒阻塞的字节数
4.3. 恢复测试
恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
4.4. 安全性测试
软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。
1.用户认证安全的测试要考虑问题：
（1）明确区分系统中不同用户权限
（2）.系统中会不会出现用户冲突
（3） 系统会不会因用户的权限的改变造成混乱
（4）用户登陆密码是否是可见、可复制
（5）是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）
（6）用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统
系统网络安全的测试要考虑问题：
（1）测试采取的防护措施是否正确装配好，有关系统的补丁是否打上
（2）模拟非授权攻击，看防护系统是否坚固
（3）采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是NBSI系列和IPhacker IP）
（4）采用各种木马检查工具检查系统木马情况
（5）采用各种防外挂工具检查系统各组程序的客外挂漏洞
2.数据库安全考虑问题：
（1） 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）
（2） 系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）
（3） 系统数据可管理性
（4） 系统数据的独立性
（5） 系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）
4.5. 压力测试
压力测试通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。 极限压力测试举例：
1） 接收大数据量的数据文件时间；
2） 大数据恢复时间；
3） 大数据导入导出时间；
4） 大批量录入数据时间；
5） 大数据量的计算时间；
6） 多客户机同时进行某一个提交操作；
7） 采用测试工具软件；
8） 编写测试脚本程序；
9） 大数据量的查询统计时间