分享一份完整的系统测试方案
1.1编写目的
为软件开发项目管理者、软件工程师、系统维护工程师、测试工程师提供关于项目系统整体功能和性能的测试指导，同时也是用户确定软件是否完整测试的重要依据。
1.2项目背景
XXXXX
1.3测试目标
在用户使用软件之前，尽可能的发现软件中存在的错误和不合理之处，排除软件中潜在的错误，最终把高质量的软件系统交付给用户。系统的测试覆盖范围：功能、性能、UI、安全性、兼容性、容量。
1.4测试参考文档
GBT 15532-2008 计算机软件测试规范
GBT 9386-2008 计算机软件测试文档编制规范
1.5测试提交文档
软件测试方案
软件测试用例
软件测试报告
1.6术语和缩略语
本文使用的术语、定义
2.1测试配置要求
2.2测试方法
系统的功能测试选用了手工测试，运用黑盒测试中的等价类划分、边界值分析、错误推测、因果图法。系统UI方面的测试包括：易用性测试、规范性测试、帮助设施测试、合理性测试、美观与协调性测试、独特性测试、快捷方式组合测试。系统的安全性、兼容性、安装与反安装、配置测试也是手工测试。单元测试采用的方法是白盒测试，功能测试采用黑盒测试。
2.3测试数据
测试数据主要依照《XXX》文档，参考《XXX》文档中规定的运行限制，设计测试用例，作为XX平台的测试数据。
2.4测试策略
2.4.1单元测试
首先依照系统、子系统和模块进行划分，但最终的单元必须是功能模块，或面向对象过程中的若干个类，单元测试是对功能模块进行正确性检验的测试工作，也是后续测试的基础。目的在于发现各模块内部可能存在的各种差错，因此需要从程序的内部结构出发设计测试用例，着重考虑以下五个方面：
（1） 模块接口：对所测模块的数据流进行测试；
（2） 局部数据结构：检查不正确或不一致的数据类型说明、使用尚未赋值或尚未初始化的变量、错误的初始值或缺省值。
（3） 路径：虽然不可能做到穷举测试，但要设计测试用例查找由于不正确的计算（包括算法错、表达式的符号表示不正确、运算精度不够等）、不正确的比较或不正常的控制流（包括不同数据类型量的相互比较、不适当地修改了循环变量、错误的或不可能的循环终止条件等）而导致的错误。
（4） 错误处理：检查模块有没有对于常见错误的条件设计比较完善的错误处理功能，保证其逻辑上的正确性。
（5） 边界：注意设计数据流、控制流中刚好等于、大于或小于确定的比较值的用例。
2.4.2集成测试
集成测试也叫组装测试或联合测试。通常，在单元测试的基础上需要将所有的模块按照设计要求组装成系统，这时需要考虑的问题如下：
（1） 把各个模块连接起来，模块接口的数据是否会丢失；
（2） 一个模块的功能是否会对另一个模块的功能产生不利的影响；
（3） 各个子功能组合起来，能否达到预期要求的父功能；
（4） 全局数据结构是否有问题；
（5） 单元模块的误差累积起来，是否会放大，从而达到不能接受的程度。我们在组装时可参考采用一次性组装方式或增值式组装方式；
2.4.3系统测试
系统测试目的是在于验证软件的功能和性能及其他特性是否与用户的要求一致，主要是以下类型的测试；
（1） 功能测试：验证系统功能是否符合其需求规格说明书，核实系统功能上是否完整，没有冗余和遗漏的功能。功能测试详细介绍如下表：
（2） 用户界面测试：测试用户界面是否具有导航性、美观性、行业或公司的规范性、是否满足设计中要求的执行功能、详细介绍如下表UI测试：
其中，Web测试通用方法可以参考《Web测试检查点总结》
（3） 性能测试：测试相应时间、事务处理效率和其他时间敏感的问题。性能测试介绍如下表所示：
（4）兼容性测试：测试软件在不同平台上使用的兼容性。兼容性测试详细介绍如下表所示：
（5）安全性测试：测试软件系统对非法侵入的防范能力。安全测试详细介绍如下表：
（6）配置测试：测试在不同网络、服务器、工作站的不同软硬件配置条件下，软件系统的质量，详细说明如下表所示：
（7）回归测试详细介绍如下表所示：
2.4.4验收测试
用户新增或修改内容，以及用户反馈问题确认：
2.5测试资源
2.6测试阶段及范围
2.7通过测试的标准
一般有“基于测试用例” 和 “基于缺陷密度” 两种评比准则，在这里我们采用前者。
（1） 功能性测试用例通过率达到100%
（2） 非功能性测试用例通过率达到95%
（3） 没有高于优先级3以上的问题
备选通过方法：根据实际情况由软件开发部门的经理，项目经理和测试负责人共同讨论确定本测试阶段是否结束。（详细的系统测试通过标准可参考《系统测试各阶段准入准出规则》）
3.1测试需求概述
XX平台简称XX，总共有XX大功能模块分别是：XXX 。每个模块的需求模块如下表所示：
本文档描述的数据接入需求模块，需求标识及需求描述如表：
4测试用例
测试用例文档附件粘贴即可。（也可注明测试用例访问位置）
5.1文本输入框
（1）检查空数据；
（2）检查过长数据（超出空间本身的长度和数据库中改字段所允许的长度）；
（3）检查特殊字符，尤其是数据库中不允许的字符，甚至回车字符、空格字符等；（可以参考《关于测试中的那些特殊字符们》）
（4）检查字符类型，比如应该输入数字的文本框输入英文字符；
（5）中文字符的处理；
（6）对于日期时间型数据，检查格式正确性以及时间日期的合理性。比如开始时间不能晚于结束时间等；
5.2下拉列表
（1）列表数据是否正确、完整；
（2）下拉列表与其他空间的联动关系；
（3）是否允许多选；
5.3增加数据
（1）数据个数的上限；
（2）重复数据处理，尤其是键值的重复；
（3）相关表格的更新；
（4）检查多次使用back键的情况，在有back的地方，back回到原页面，再back重复多次，看是否会出错；
5.4修改数据
（1）不能破坏数据库数据的关联和完整；
（2）重复数据处理，尤其是键值的重复；
（3）修改登录用户本身信息时对系统的影响；
（4）修改正在使用的数据；
（5）检查多次使用back键的情况，在有back的地方，back，回到原页面，再back，重复多次，看是否会出错。
5.5删除数据
（1）不能破坏数据库数据的关联和完整；
（2）删除正在使用的数据；
（3）删除登录用户本身；
5.6查询数据
（1）多条件组合查询的正确性；
（2）多次连续查询正确性；
5.7数据导入导出
（1）导入数据格式要求不应太严格，提示明确；
（2）导出数据不应乱码；
5.8数据接入与处理
（1）数据接入方式是否全部可用，数据是否能正确接入；
（2）数据处理方式是否全部可行；
（3）数据的动态监测是否正确无误；
5.9其他
（1）对网络故障的提示；
（2）同一用户多次登录；
（3）内存使用情况；
（4）压力测试，系统承受能力，多用户同时登录使用。
后记：通常来讲，每个公司有自己的文档规范以及必须遵守的行业标准规范，大体的方案架构可以按照公司内部标准，其他细节需要根据被测系统的特征来适当调整。同时如果是外包性质的项目还需要考虑到客户方的标准及交付文档规范，如相关人员与完成工作时间及范围、灰度测试环境上报、用户测试准入条件等等。另外，如果系统较为庞大 ，系统测试方案中也只体现相关整体架构 ，具体的专项测试还会以附件形式重新设计完整方案。
