软件
系统测试意味着将软件系统或者应用程序做为一个整体进行测试。应用程序的系统测试从整体上检测软件大致的业务，操作以及最终用户需求的一致性。系统测试被归类为
黑盒测试。
这就是为什么内部设计，架构或者代码对于这种测试来说完全不重要。
当执行一个软件测试时，专业软件测试员倾向于区分是接口里面的，还是整个软件里面的错误或者缺陷。然而，当执行软件或者应用程序的内建（build-in）测试的时候，专业的软件测试员会倾向于，把已经合并起来的单独模块之间的缺陷或者错误区分开来。
系统测试过程中，主要的问题是软件的设计，行为以及客户的期望。因此软件的系统测试阶段也可以被称为软件开发生命周期的审查测试阶段。
什么时候系统测试会变得重要起来？
当软件的所有功能开发完成时，整个软件系统就应彻底的被测试，保证业务，功能和非功能的要求。系统测试基于单元测试和集成测试标准。绝大多数情况下由一个特别，独立，并且值得托付的小组来负责系统测试。系统测试在开发用服务器（staging server）上完成。
系统测试的理由
● 系统测试是把软件或者应用程序首次做为一个整体进行测试
● 执行系统测试是为了检查和改进技术，业务，功能和非功能的软件需求，审查和改进软件程序架构也是这个阶段一部分内容。
● 系统测试执行在模拟环境（staging environment）里，与最终软件安装所需的环境非常类似。（译者注：staging environment，即在软件最终发布前，开发或者设计人员对软件进行调整后可以及时预览改变的测试环境，这个环境更接近于产品最终发布后的运行环 境）
系统测试完成的标准：
● 完成单元测
● 完成集成测试
● 软件系统开发彻底完成
● 模拟产品环境的测试环境准备完成。例如，模拟环境（staging environment：同上注） 存在
系统测试7个阶段：
● 开发系统测试设计
http://wenku.baidu.com/view/f4c904da50e2524de5187edd.html
● 开发系统测试用例
http://wenku.baidu.com/view/5cfc4cf80242a8956bece4d6.html
● 选择或者开发一些用于系统测试的数据
● 必要的话，将系统测试用例自动化
● 执行测试用例
● 修复缺陷和回归测试
● 如果需要，在不同的测试环境下，再次完成一个测试周期
软件测试计划的内容可以在公司与公司，或者项目与项目之间替换使用，这取决于软件测试的策略，项目计划的建立以及理解项目测试计划的程度。软件系统测试计划的主要内容包括：
● 范围
● 目标及目的
● 主要区域/关键区域
● 可交付物
● 系统测试计划
● 进度计划
● 进入和完成标准
● 软件测试的延迟和更新标准
● 测试环境
● 可交付标准
● 人员与培训计划
● 角色与职责
● 字典
如何创建系统测试用例
系统测试用例的编写，用跟写功能测试用例一样。不过，当编写系统测试用例的时候，应该考虑2个关键点：
1、系统测试用例应该附上用例和场景
2、测试用例必须满足全部要求，例如，技术上，用户界面，功能性，非功能性你，性能和其他方面。
在维基百科上，当执行系统测试时，要考虑24中不同的测试类型，他们是：用户界面测试，可用性测试，性能测试，兼容性测试，错误处理测试，大容 量用户测试，大容量数据测试，压力测试，用户帮助测试，安全测试，可扩展性测试，容积测试，健全测试，冒烟测试，探索性测试，随机测试，回归测试，可靠性 测试，恢复性测试，安装测试，效力测试，维护测试，恢复与故障转移测试，业务功能测试。
系统测试用例计划：
● 给测试用例一个ID（唯一数字）
● 测试套件（test suit）的命名
● 测试者 – 编写测试用例的测试者名字
● 功能的简短描述或者需求环境的ID
● 测试执行时的步骤
● 测试数据-输入数据
● 预期的结果
● 肯定的结果
● 通过/失败
● 测试评审
测试类型 | 测试关注点 | 完成情况 | | 用户层 | | | | 用户支持测试 | 用户手册、使用帮助、支持客户的其他产品技术手册是否正确、是否易于理解、是否人性化。 | | | 用户界面测试 | 测试对象控件或访问入口正确，符合用户需求 | | | 界面风格统一，界面美观、直观 | | | 操作友好、人性化 | | | 易操作性 | | | 可维护性测试 | 系统软、硬件实施和维护功能的方便性 | | | 安全性测试 | 操作安全性 （注：核实只有具备系统和应用程序访问权限的主角才能访问系统和应用程序；核实主角只能访问其所属用户类型已被授权使用的那些功能操作） | | | 数据安全性 （注：关注数据访问的安全性，防止交易敏感数据不被第三方截获、窃取、篡改和伪造。测试内容为：数据加密，安全通讯，安全存储） | | | 网络安全测试 （注：该层次的测试主要是为了防止黑客的恶意攻击和破坏，如：病毒，DDOS攻击等。测试的方式主要是模拟黑客对系统进行入侵攻击，然后对攻击的结果进行分析，并逐步完善系统的安全性能） | | | 安全认证测试 （注：确保交易双方不被其他人冒名顶替。测试内容为安全认证） | | | 安全交易协议测试 （注：有效避免交易双方出现互相抵赖的情况） | | | 应用层 | | | | 性能测试 | 并发性能测试 （注：并发用户操作下，不断增加并发用户数量，分析系统性能指标、资源状况。主要关注点：交易结果、每分钟交易数、交易响应时间（最小服务器响应时间、平均服务器响应时间、最大服务器响应时间） | | | 压力测试 （注：不断对系统施压，通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试） | | | 强度测试 （注：系统在极限或异常资源情况下，即系统资源处于特别低的状况下，软件系统运行情况确定系统综合交易指标和资源监控指标，保证系统能否按规格强度下运行） | | | 负载测试 （注：关注各种工作负载情况下的性能指标，测试当负载逐渐增加到超负荷状态时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能） | | | 疲劳测试 （注：采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程） | | | 大数据量测试 （注：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试） | | | 容量测试 （注：确定系统可处理同时在线的最大用户数） | | | 破坏性测试 （注：超出系统能承受的压力点后，系统出现错误状态、出现错误比率及恢复能力；对软件进行异常的操作，如：删除配置文件） | | | 系统可靠性、稳定性测试 | 可靠性测试 （注：主要测试系统在负载压力下系统运行是否正常） | | | 稳定性测试 （注：确保系统在长期使用周期内能够在要求的性能指标下正常工作） | | | 系统兼容性测试 | 操作系统兼容性 （注：win 9x / win2k / winXP / Unix / Linux ... ...） | | | 浏览器兼容性 （注：IE4 / IE5 / IE6 / Firefox / My IE / TT ... ...） | | | 其他支持软件/平台/文件/数据/接口的兼容性 | | | 系统组网测试 | | | | 系统安装升级测试 | 初次安装 | | | 更新（注：以前安装过相同版本） | | | 升级（注：以前安装过较早版本） | | | 功能层 | | | | 功能性测试 | 初验测试 （注：系统核心功能、基本业务流程的验证） | | | 业务场景测试 （注：模拟用户实际操作的业务场景，遍历主要业务流程和业务规则） | | | 业务功能的覆盖 （注：关注需求规格定义的所有功能系统是否都已实现） | | | 业务功能的分解 （注：将每个功能分解成测试项。关注每个测试项的测试类型都被测试通过） | | | 业务功能的组合 （注：相关联的功能项的组合功能的都被正确实现） | | | 业务功能的冲突 （注：业务功能间存在的功能冲突情况，均测试通过。例如：共享资源访问等） | | | 异常处理及容错性 （输入异常数据、或执行异常操作后，系统容错性及错误处理机制的健壮性。例如：重复点击“提交”按钮，提交申请单） | | | 子系统层 | | | | | 单个子系统的性能 （注：应用层关注的是整个系统各种软、硬件、接口配合情况下的整体性能，这里关注单个系统。） | | | | 子系统间的接口瓶颈 （例如：子系统间通讯请求包的并发瓶颈） | | | | 子系统间的相互影响 （注：子系统的工作状态变化对其他子系统的影响） | | | 协议/指标层 | | | | | 协议一致性测试 | | | | 协议互通测试 | | | 其他测试类型 | | | | BVT | 构建验证测试 | | | Ad hoc Test | 随机测试 | | | Exploratory Test | 探索性测试c | | | 回归测试 | | |
|
|
|
|