软件测试理论知识总结
软件测试基础
软件测试流程
需求分析 测试计划 测试方案 测试用例 测试执行 测试报告
- 计划和控制
- 分析和设计
- 实现和执行
- 测试评估和测试报告
- 测试结束活动
软件测试概念以及目的
测试是为发现错误而执行程序的过程
在规定条件下运行系统或组件的过程。观察和记录结果，并对系统或组件的某些方面给出评价。
• 分析软件项目的过程。检测现有状况和所需状况之间的不同，并评估软件项目的特性。定义的出处:
测试目标
- 发现缺陷
- 增加对质量的信心
- 为决策提供信息
- 预防缺陷
软件测试原则
1) 所有的软件测试都应追溯到用户需求。
2) 应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。
3) 完全测试是不可能的，测试需要终止。
4) 测试无法显示软件潜在的缺陷。
5) 充分注意测试中的群集现象。
6) 程序员应避免检查自己的程序。
7) 尽量避免测试的随意性
- 测试只能 显示 错误的存在
- 穷尽测试( ( exhaustive testing ) ) 是不可能的
- 测试活动应尽早地介入
- 缺陷的 集群( ( defect clustering ) ) 现象
- 杀虫剂悖论
- 测试 活动依赖于 测试背景
软件测试分类
按阶段划分
1) 单元测试：是指对软件中的最小可测试单元进行检查和验证。
2) 集成测试：一种旨在暴露接口以及集成组件/系统间交互时存在的缺陷的测试，其测试的目的是发现接口的缺陷和集成后组件协同工作时的缺陷
3) 系统测试：测试已集成的系统以验证它是否满足指定需求的过程
4) 验收测试：一般由用户/客户进行的、确认是否可以接受一个系统的验证性测试。是根据用户需求，业务流程进行的正式测试以确保系统符合所有验收准则。
验收测试的形式
用户 验收测试
运行 （ 验收 ）测试
合同验收测试
法规性验收测试
Alpha测试：潜在的客户/用户在开发场地进行的测试
Beta 测试：由潜在客户/用户在他自己的环境下测试软件系统
Alpha 和 Beta测试 都可归为现场验收测试
按是否运行程序划分
1) 静态测试：不运行被测试的软件，而只是静态的检查代码、界面或者文档
2) 动态测试：实际运行被测试的软件，输入相应的测试数据，检查世界的输出结果是否和预期结果相一致的过程。
按是否查看代码划分
黑盒测试：不考虑组件或系统内部结构的功能或非功能测试。
白盒测试：基于对组件或系统的内部结构的分析而进行的测试。
灰盒测试：介于白盒和黑盒测试之间，基于程序运行时刻的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。
其他划分
冒烟测试（BVT测试（BuildVerification Test ））：冒烟测试的对象是每一个新编译需要正式测试的版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
随机测试（又名猴子测试）：测试数据是随机产生的，在测试用例之外。只能作为一个测试的补充。
敏捷测试（敏捷开发引发）：敏捷测试(Agiletesting)是测试的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。
TDD（测试驱动开发）
测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完全部功能的开发。
测试类型
- 功能测试：
- 软件非功能特征测试（非功能测试）
- 软件结构/架构测试（结构测试）
- 与变更相关的测试（确认测试和回归测试）
功能测试范围
功能测试：主要是考虑软件的外部表现行为（黑盒测试）。这可以采用基于规格说明的技术，根据软件或系统的功能来设计测试条件和测试用例。
安全性测试：可看作功能测试的一种，它会对安全性相关的功能（如用户权限设置、防火墙设置）进行测试，从而检测系统和数据是否能抵御外部恶意的威胁，如病毒等。
互操作性测试：是另一种功能性测试，评估软件产品与其他一个或多个组件或系统交互的能力。
非功能属性
负载 (load)
性能 (performance)
可用性 (usability)
可靠性 (reliability) /稳定性(stability)
可移植性 (portability)
健壮性 (robustness)
可恢复性 (recovery)
容量(volume)
兼容性 (compatibility)
可维护性 (maintainability)
非功能测试类型
负载测试 (load testing)
一种通过增加负载来测量组件或系统的测试方法。例如：通过增加并发用户数和（或）事务数量来测量组件或系统能够承受的负载。
性能 测试 (performance testing)
判断软件产品性能的测试过程：
(1) 为了确定一个软件产品的性能所进行的测试
(2) 针对特定的应用领域检查系统的性能(处理速度以及响应时间)
压力测试 (stress testing)
在规定的或超过规定的需求条件下测试组件/系统，以对其进行评估。
(1) 为了评价一个系统或一个组件达到或超过需求规定的界限时的反应的测试 [IEEE 610]
(2) 检查系统在超负荷的情况下的性能反应(例如通过在高数据量或特定的错误条件下工作). 可参看健壮性
可靠性测试 (Reliability testing) ：在长时间运行中测试（如失效的平均时间或指定用户配置的失效率）。
可用性测试 (Availability testing) ：检查客户学习系统的容易性、操作的容易性和效率、系统输出的可理解等，经常与特定用户组的需求相关。
可维护性测试 (Maintainability testing) ：评估系统文档的可维护性以及是否是最新的；例如检查系统是否是模块化的结构。
与变更相关的测试
再测试，确认测试：当修改了一个缺陷后， 重新执行上次失败的测试用例，以确认原来的缺陷已经成功的修改。确认测试只针对某一缺陷，而不会覆盖整个程序。再测试和确认测试不等于回归测试！
回归测试：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例。防止出现“以前应用没有的问题现在出问题了”。
回归测试：是对已被测过的程序在修改缺陷后进行的重复测试，以发现在这些变更后是否有新的缺陷引入。
回归测试策略
选择回归测试方法应该兼顾测试风险（覆盖面）和有效性两
个方面，根据项目实际情况，达到平衡。
基于风险选择测试
基于操作剖面选择测试。
再测试修改的部分。
维护测试：在软件生命周期中，因为软件系统及其运行环境发生了修改、移植或扩展而进行的测试就是维护测试。除了对已变更的部分进行测试外，维护测试还包括相应的回归测试。维护测试的范围取决于影响分析，可以在某一或所有的测试级别和测试类型上进行。
功能增强：发布新版本
纠正和应急变更
环境变化（操作系统、数据库升级）
操作系统漏洞补丁
软件移植（如从Windows移植到Unix）
系统退役的数据存档
维护测试需要大量的回归测试。
软件质量的属性：功能性，可靠性,易用性, 效率, 可维护性，可移植性。
| 测试项 | 分项目 | 说明 |
| 功能性 | 适合性 | 考察所实现的功能是否满足要求。 |
| 准确性 | 考察功能实现是否能够给出正确的功能实现结果，结果数据是否准确（精度是否满足要求）。 | |
| 互操作性 | 考察系统与其他系统相连接时，是否能够正常地实现互连，该特性主要考察系统之间的功能接口和数据接口。 | |
| 可靠性 | 成熟性 | 考察系统是否存在内在的缺陷，导致运行过程中出现不稳定，是否出现不正常的系统崩溃、死机、异常退出及丢失数据现象。 |
| 容错性 | 考察系统是否能够在用户发生错误的操作或数据输入（或非法的数据参数接口）时，是否能够识别并给出适当的反映（如屏蔽不正确的用户操作、给出提示等），而不会产生死机、异常退出或丢失数据现象。 | |
| 易恢复性 | 当系统出现意外时，是否能够快速响应并进行系统恢复和数据恢复，考察系统是否具有数据备份功能。 | |
| 安全性 | 用户身份识别及权限控制 | 具有不同用户的识别功能，进入系统时必须具有登录密码检验功能，不同的用户应具有不同的访问权限，密码设置需要满足常规的密码策略。 |
| 日志和审计 | 对关键数据是否具有日志功能，日志是否分类，日志管理是否具有合适的权限，对关键操作是否具有安全审计能力。 | |
| 易用性 | 易理解性 | 是否能够通过适当的术语、图形、背景信息和帮助，帮助用户理解和使用系统的各项功能，理解如何使用该系统。 |
| 易学习性 | 考察系统是否提供了适当的途径帮助用户更快地学习系统的操作方法，比如文档说明、在线帮助以及帮助的频率、使用范例、使用向导等辅助学习功能。 | |
| 易操作性 | 用户容易使用系统的程度，是否能够操作和控制软件，对具有严重后果的功能，应执行可逆或给出明显警告并要求确认，提供辅助输入手段，支持快捷键。 | |
| 效率（性能测试） | 时间效率 | 当系统处于常规负载、平均负载和极端负载情况下，考察各项业务的响应时间是否满足需求。 |
| 可维护性 | 易分析性 | 当系统出现故障时，能够被方便地定位。 |
| 易改变性 | 当系统需要进行缺陷修复、系统升级完善等修改时，是否能够支持方便的软件修改。 | |
| 可移植性 | 适应性 | 软件是否能够适应于不同的运行和操作环境，如不同硬件环境的变化，系统软件的变化，支持软件的变化等。 |
| 易安装性 | 软件是否方便进行用户安装。 | |
| 共存性 | 系统或用户试图将软件与其他的独立软件在公共环境中共享公共资源的能力。 | |
| 用户文档 | 完整性 | 用户文档完整，具有对系统中所有功能的描述。具有软件安装、软件维护等必要的信息。 |
| 正确性 | 文档中所有的信息是正确的，没有歧义和错误的描述。 | |
| 一致性 | 文档自身、文档之间或文档与产品描述之间，相互没有矛盾，且术语一致。 | |
| 易理解性 | 文档对正常使用产品的一般用户是容易理解的。 | |
| 易浏览性 | 用户文档易于浏览，相关关系明确，文档具有目录和索引。 |
| 功能测试内容 | |
| 序号 | 在界面检查中所包含的检查项有： |
| 1 | 系统菜单的功能检查。 |
| 2 | 链接测试：界面中存在的链接检查。 |
| 3 | 页面之间的流转关系。 |
| 4 | 界面中文字信息的检查，包括功能模块名称信息的一致性；提示说明信息的准确性；无错别字；信息显示完整性。 |
| 5 | 页面美观及易用性。 |
| 序号 | 窗口检查 |
| 1 | 窗口是否基于相关的输入和菜单命令适当地打开。 |
| 2 | 窗口能否改变大小、移动和滚动。 |
| 3 | 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问。 |
| 4 | 当被覆盖并重新调用后，窗口能否正确地再生。 |
| 5 | 需要时能否使用所有窗口相关的功能。 |
| 6 | 所有窗口相关的功能是否可操作。 |
| 7 | 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，并适当地显示。 |
| 8 | 显示多个窗口时，窗口的名称是否被适当地表示。 |
| 9 | 活动窗口是否被适当地加亮。 |
| 10 | 如果使用多任务，是否所有的窗口被实时更新。 |
| 11 | 多次或不正确按鼠标是否会导致无法预料的副作用。 |
| 12 | 窗口的声音和颜色提示和窗口的操作顺序是否符合需求。 |
| 13 | 窗口是否正确地被关闭 |
| 序号 | 下拉式菜单和鼠标操作检查 |
| 1 | 菜单条是否显示在合适的语境中。 |
| 2 | 应用程序的菜单条是否显示系统相关的特性（如时钟显示）。 |
| 3 | 下拉式操作是否能正确工作。 |
| 4 | 菜单、调色板和工具条是否工作正确。 |
| 5 | 是否适当地列出了所有的菜单功能和下拉式子功能。 |
| 6 | 是否可以通过鼠标访问所有的菜单功能。 |
| 7 | 文本字体、大小和格式是否正确。 |
| 8 | 是否能够用其他的文本命令激活每个菜单功能。 |
| 9 | 菜单功能是否随当前的窗口操作加亮或变灰。 |
| 10 | 菜单功能是否正确执行。 |
| 11 | 菜单功能的名字是否具有自解释性。 |
| 12 | 菜单项是否有帮助，是否语境相关。 |
| 13 | 在整个交互式语境中，是否可以识别鼠标操作。 |
| 14 | 如果要求多次点击鼠标，是否能够在语境中正确识别。 |
| 15 | 光标、处理指示器和识别指针是否随操作恰当地改变。 |
| 16 | 数据项操作检查 |
| 17 | 字母数字数据项是否能够正确回显，并输入到系统中。 |
| 18 | 图形模式的数据项（如滚动条）是否正常工作。 |
| 19 | 是否能够识别非法数据。 |
| 20 | 数据输入消息是否可理解 |
| 序号 | 输入域的检查 |
| 1 | 合法数据输入检查。（符合该输入项在系统设计的要求：字符的类型和长度、日期格式等） |
| 2 | 非法数据输入检查。（不符合该输入项在系统设计的要求：字符的类型和长度、日期格式等） |
| 3 | 特殊字符的输入检查，检查系统如何处理特殊字符。 |
| 4 | 空数据输入检查。 |
| 5 | 必添项检查。 |
| 6 | 输入域的输入极限检查。（符合该输入项在系统设计的要求） |
| 7 | 数据接口检查。（对于数据存在多模块使用的情况，检察数据是否准确，同时在数据最大时，系统不出错。） |
| 8 | 权限检查 |
| 9 | 检查现有系统的权限设置是否符合委托方的相关文件要求。 |
| 10 | 检查权限控制功能是否有效。 |
| 11 | 对一些敏感数据或重要业务流程是否提供多种信息保护机制。 |
| 12 | 检查当用户试图超越其权限范围进行访问或其他操作时，系统是否具有审计记录。 |
| 序号 | 功能检查 |
| 1 | 系统制定的功能、逻辑检查：系统涉及到的各类信息维护的功能测试。 |
| 2 | |
| 3 | 数据计算功能检查。 |
| 4 | 数据查询功能检查。 |
| 5 | 数据库测试：验证数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的。 |
| 6 | 与外部系统及外围设备的互操作性测试 |
| 7 | 数据交换的数据格式和内容。 |
| 8 | 测试接口之间的协调性。 |
| 9 | 测试软件对系统每一个真实接口的正确性。 |
| 10 | 测试软件系统从接口接收和发送数据的能力。 |
| 11 | 测试数据的约定、协议的一致性。 |
| 12 | 测试软件系统对外围设备接口特性的适应性。 |
| 序号 | 功能流程测试内容 |
| 1 | 业务流程是否与需求规格说明书中规定的流程相一致。 |
| 2 | 业务流程流转过程的功能实现。 |
| 3 | 业务流程中与其他外部系统的联动。 |
| 4 | 数据流程中所有数据计算的准确性。 |
| 5 | 数据流程是否与需求规格说明书中规定的相一致。 |
| 6 | 同一组数据在不同模块中的精度转换。 |
| 性能测试类型 | |
| 负载测试 | 检测在常规负载情况下在该系统中完成主要业务的响应时间，以及信息量收集速度、信息查询速度等性能指标，同时可通过相应的测试工具对被测服务器的CPU、内存、磁盘、网络等指标进行监控。本测试的主要目的是考察系统是否满足时间特性要求。 |
| 压力测试 | 检测在极限负载情况下在该系统中完成主要业务的响应时间，本测试将考察在逐步增加系统负载过程中，系统的性能指标，从而进一步考察系统承受能力和容量。本测试将以常规负载为起点，逐步加大并发用户量，直到系统的性能极限或预期最大负荷。本测试的目的是考察系统在极限压力情况下系统的表现。 |
| 疲劳测试 | 系统应该具有高度的可靠性以满足系统能具有对外提供7×24服务的能力。本次测试将按该运行要求，分别进行24小时的长时间测试。测试中将设置各种不同业务的混合业务场景，测试长时间运行时系统各项性能指标，考察系统性能指标的变化趋势，统计长时间运行条件下的出错概率。通过对被测性能指标的分析，对系统长时间运行能力进行评估。 |
| 性能测试方法 | |
| 1 | 通过Loadrunner工具建立虚拟用户脚本 ：将业务流程转化为测试脚本（在这个步骤里，要将各类被测业务流程从头至尾进行确认和记录，通过该过程可以帮助分析到每步操作的细节和时间，并精确地转化为脚本）。 |
| 2 | 根据用户性能指标及性能测试计划在测试工具中创建测试场景，根据真实业务场景，将单个用户的行为进行复制和控制，转化为多个用户的行为（在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到交易量，并发时序等参数的设置）。 |
| 3 | 负载压力测试运行，利用Controller控制数台向Generator Load分发任务，并由Generator Load向被测系统提交数十到数百个重复的服务请求（见图4-1），从而模拟数十到数百个用户对系统访问时系统所承受的压力，同时获取和记录系统的运行指标（响应时间，吞吐量，资源占用，出错率等）。在性能测试运行中，我们将使用逐步施压的方式来进行负载加压，直到负载能够满足测试要求中所规定的压力指标。在性能运行期间同步实时监测，让测试人员在测试过程中的任何时刻都可以了解应用程序的性能状况，便于及时更正和调整测试配置参数。在每一次性能运行结束，都由测试人员对该轮次的测试情况进行记录并保存测试结果。需要被监测的对象主要包括：客户端，网络，web应用服务器，数据库服务器。通过实时监测可以在测试执行中及早发现性能瓶颈。 |
| 4 | 通过Analysis工具采集、提取相关数据及指标，并生成和分析测试结果。结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。 |
| 5 | 故障分析和定位：分析测试过程中得到的各项指标，如果发现指标出现不正常，则通过对这些指标的分析确定故障可能的原因，同时通过改变测试范围和测试条件,借助故障定位工具来进行故障定位，确定调优策略，针对性地进行系统调优，通过重复进行压力测试，确定性能是否得到提高。从而逐步提高系统的性能。 |
| 6 | 产生测试报告（缺陷报告） |
| 安全测试 | 测评内容 | 测评方法 |
| 网络安全 | 检测系统所在局域网内的网络环境安全设置，比如系统的防护措施是否有效装配；模拟非授权攻击，系统的防护是否坚固；采用成熟的网络漏洞检查工具检测系统相关漏洞，如防JS注入；检测系统木马情况等。 | 安全配置核查与人工验证由测评人员分别针对选定的网络互联和安全设备的安全保护能力提出测评要求，配合人员通过展示具体配置参数或实际操作/演练（如用户登录）等方法来提供测评证据，并由测评人员进行记录。 |
| 主机安全 | 主机系统安全扫描策略主要包括： Ø 端口扫描； Ø 弱口令扫描； Ø 系统漏洞扫描； Ø 注册表检测； Ø 本地安全检测等。 配置检查内容主要包括： Ø 身份鉴别； Ø 访问控制； Ø 安全审计； Ø 入侵防范； Ø 恶意代码防范； Ø 资源控制。 |
测评人员根据主机系统类型配置扫描策略，通过测评工具进行主机系统安全扫描； 根据测评要求，配合人员通过展示具体配置或实际操作等方法来提供测评证据，并由测评人员进行记录。 |
| 应用安全 | 应用系统扫描策略主要包括： Ø SQL注入； Ø 表单绕过； Ø 跨站点脚本编制、跨站点请求伪造； Ø 目录遍历； Ø 信息泄露； Ø 缓冲区溢出； Ø 拒绝服务等。 |
测评人员根据应用系统类型配置扫描策略，通过测评工具进行应用系统安全扫描。 |
| 数据库安全 | 访问的可审核性； 访问的可控制性； 关键数据存储传输的保密性； 还包括了如下内容：检测在管理和维护数据库过程中，为了保障数据库安全，各项数据库访问限制是否设置合理，如是否限制访问Oracle数据库客户端，是否只有指定IP才能访问；即便有访问Oracle数据库机会，是否采用了账户的密码强口令或其它登录策略确保恶意用户也无法轻松进入；每个登录账户手否设置了合理的权限，执行改变数据库状态的权限是否进行了合理的授权设置；系统数据可管理性如何；系统数据的备份和恢复能力如何等。 |
采用安全配置核查与人工验证的方法，由测评人员针对选定的数据库系统提出测评要求，配合人员通过展示具体配置或实际操作/演练等方法来提供测评证据，并由测评人员进行记录。 |
| 一、网络安全 |
| 1、应在网络边界部署访问控制设备，启用访问控制功能； |
| 2、在各网络边界处的访问控制设备每条访问控制规则均有明确的源IP地址、目的IP地址等。位于网络边界处的网络设备应关闭不必要的服务，主要包括：CDP、TCP/UDP Small service、Finger、BOOTp、IP Source Routing、ARP-Proxy、IP Directed Broadcast、WINS和DNS |
| 3、查看是否有正确的访问控制列表（如ACL）限制拨号用户对系统资源的访问，此条适用于拨号，如ISDN、VPN等拨号方式 |
| 4、应限制具有拨号访问权限的用户数量 |
| 二、主机安全/数据库安全 |
| 身份鉴别： |
| a、应对登录操作系统和数据库系统的用户进行身份标识和鉴别（勾选了“要使用本机，用户必须输入用户名和密码”） |
| b、操作系统和数据库系统管理用户身份标识应具有不易被冒用的特点，口令应有复杂度要求并定期更换（1、密码必须符合复杂性要求；2、密码长度最小值；3、密码最长使用期限；4、密码最短使用期限；5、强制密码历史；6、密码永不过期属性。1、已启用；2、8个字符；3、42天；4、2天；5、5个记住的密码；6、未勾选“密码永不过期”） |
| c、应启用登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施（1、复位帐户锁定计数器；2、帐户锁定时间； |
| 3、帐户锁定阈值。1、30分钟之后；2、30分钟；3、5 次无效登录） |
| d、当对服务器进行远程管理时，应采取必要措施，防止鉴别信息在网络传输过程中被窃听（1、禁用telnet服务；2、采取3389远程桌面方式管理；3、采取了加密鉴别信息的方式进行远程管理。） |
| e、应为操作系统和数据库系统的不同用户分配不同的用户名，确保用户名具有唯一性 |
| 访问控制： |
| a、查看系统管理员是否能提供用户权限对照表，设置的用户权限是否与与权限表一致。 |
| b、实现操作系统和数据库系统特权用户的权限分离 |
| c、应严格限制默认帐户的访问权限，重命名系统默认帐户，修改这些帐户的默认口令 |
| d、应及时删除多余的、过期的帐户，避免共享帐户的存在 |
| 安全审计： |
| a、审计范围应覆盖到服务器上的每个操作系统用户和数据库用户； |
| b、审计记录应包括事件的日期、时间、类型、主体标识、客体标识和结果等； |
| c、应保护审计记录，避免受到未预期的删除、修改或覆盖等。（默认禁止Guest访问日志） |
| 入侵防范：（主机安全） |
| a、操作系统应遵循最小安装的原则，仅安装需要的组件和应用程序，并通过设置升级服务器等方式保持系统补丁及时得到更新（1、系统安全补丁安装；2、补丁更新方式；3、是否启用必要的端口服务；4、最小安装；5、是否关闭了默认共享。） |
| 恶意代码防范： |
| a、应安装防恶意代码软件，并及时更新防恶意代码软件版本和恶意代码库； |
| b、部署防病毒服务器对防病毒软件进行统一管理。 |
| 资源控制： |
| a、询问系统管理员，是否对登录操作系统的终端接入方式、网络地址访问等进行限制，如：1、开启了主机防火墙或设置TCP/IP筛选功能，并查看相关配置；2、在网络层面设置访问控制规则进行限制 |
| b、应根据安全策略设置登录终端的操作超时锁定；（1、启用屏保并勾选“在恢复时显示登录屏幕”。2、设置“活动但空闲的远程桌面服务会话时间的限制”（推荐值设置15分钟左右）。） |
| c、应限制单个用户对系统资源的最大或最小使用限度。（1、对主机当前的资源使用情况进行监控；2、采取措施限制单个用户对系统资源最大或最小使用限度（如：启用磁盘配额管理功能）；3、主机当前资源使用情况满足实际需要，具备冗余空间。） |
| 三、应用安全 |
| 身份鉴别： |
| a、应提供专用的登录控制模块对登录用户进行身份标识和鉴别 |
| b、应提供用户身份标识唯一和鉴别信息复杂度检查功能，保证应用系统中不存在重复用户身份标识，身份鉴别信息不易被冒用 |
| c、应提供登录失败处理功能，可采取结束会话、限制非法登录次数和自动退出等措施 |
| 访问控制： |
| a、应提供访问控制功能，依据安全策略控制用户对文件、数据库表等客体的访问（1、以不同权限用户登录应用，查看其权限是否受到应用系统的限制（用户可以使用的功能，显示的界面等），以验证系统权限分离功能是否有效；2、不登录系统，直接输入登录后的页面或需要登录后才能访问的功能页面的url，查看是否可以旁路安全策略；同样，可使用低权限用户访问高权限用户才可访问的页面查看结果；3、不登录系统，直接输入下载文件的url是否可以下载，如输入http://url/download?name=file是否可以下载文件file） |
| b、访问控制的覆盖范围应包括与资源访问相关的主体、客体及它们之间的操作（访问控制的粒度是否达到主体为用户级，客体为文件、数据库表级（如数据库表、视图、存储过程等） 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的url中的参数为l=e，高级用户对应的url中的参数为l=s，以普通用户的身份登录系统后，将url中的参数e改为s来访问本没有权限访问的页面） |
| c、应由授权主体配置访问控制策略，并严格限制默认帐户的访问权限（1、由专门的用户管理员进行用户权限管理；2、权限与设置一致，无法进行越权操作；3、默认用户的访问权限进行限制或系统不存在默认用户） |
| d、应授予不同帐户为完成各自承担任务所需的最小权限，并在它们之间形成相互制约的关系（1、查看系统中是否维护不同的管理角色 2、查看其特权用户的权限是否分离（如将系统管理员、安全员和审计员的权限分离），权限之间是否相互制约（如系统管理员、安全管理员等不能对审计日志进行管理，安全审计员不能管理审计功能的开启、关闭、删除重要事件的审计日志等）；3、特权用户和普通用户中各角色的权限分配是否合理，是否按照最小授权原则） |
| 安全审计： |
| a、检查应用系统是否有安全审计功能（专门的安全审计模块或不同模块中的审计功能），检查安全审计功能的范围是否覆盖所有用户，审计的安全事件是否合理，如是否包括应用系统重要安全事件（如帐户建立、用户权限分配、重要业务数据操作、用户身份鉴别失败等行为） |
| b、应保证无法删除、修改或覆盖审计记录 |
| c、审计记录的内容至少应包括事件日期、时间、发起者信息、类型、描述和结果等 |
| 通信完整性： |
| 应采用校验码技术保证通信过程中数据的完整性（1、采用MD5、CRC等算法校验码技术保证通信过程中数据的完整性；2、数据包中含有用于完整性保护的MAC校验信息） |
| 通信保密性 |
| a、在通信双方建立连接之前，应用系统应利用密码技术进行会话初始化验证（1、利用密码技术进行会话初始化验证，Https（SSL），SSH等方式；2、检查系统客户端与服务器端建立连接方式、采用加密方式建立连接） |
| b、应对通信过程中的敏感信息字段进行加密（1、对敏感信息字段进行加密，如用户登录时的口令、敏感的业务数据字段等；2、数据包中敏感信息为密文） |
| 软件容错 |
| a、系统在数据输入界面提供数据有效性检验功能 1、检查系统是否在数据输入界面对无效或非法数据进行检验，如注册用户时是否可以以'--,' or 1=1 --等做为用户名，传送给服务器的参数（如查询关键字、url中的参数等）中包含特殊字符（',' or '1'='1,'and 1=1 --,' and 1=0 --,'or 1=0 --）时是否可以正常处理 2、除特殊字符校验外，还应添加对数据有效性的校验，如尝试输入长度不符合要求，只允许输入数字的地方输入字母等查看系统反应 3、检查系统返回的错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等 4. 若系统有上传功能，尝试上传与服务器端语言（jsp、asp、php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行 |
| b、在故障发生时，应用系统应能够继续提供一部分功能，确保能够实施必要的措施 |
| 资源控制： |
| a、系统有超时响应检验功能（1、系统有超时响应检验功能，能够自动结束无响应的通信连接；2、能够在合理时间内结束超时的空闲会话即对session的有效期进行处理，） |
| b、系统有最大并发会话连接数限制（1、询问系统是否限制系统的最大并发会话连接数；2、检查系统最大并发会话连接数限制功能，如检查应用系统的中间件是否对最大并发会话数进行限制，重点检查最大连接数的限制。比如检查中间件或web服务器tomcat、IIS、websphere、weblogic等的参数，是否有最大连接数设置） |
| c、系统限制单个用户多重并发会话数（检查系统是否限制单个用户多重并发会话数，如是否限制单个用户下载文件的线程数或同时打开的页面数；同一个帐号能否重复登录进行操作） |
1．测试需求
什么是测试需求
测试需求主要解决“测什么”的问题 ，即指明被测对象中什么需要测试。
测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。
测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
测试需求的特征
制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求；
测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件；
测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容；
为什么要测试需求
软件测试需求是开发测试用例的依据；
有助于保证测试的质量与进度；
测试需求是衡量测试覆盖率的重要指标；
2．测试需求分析过程
需求采集
需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求；
测试需求分析
测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求；
3．测试需求评审
完整性审查：应保证测试需求能充分覆盖软件需求的各种特征，重点关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束等方面，同时还应关注是否覆盖开发人员遗漏的、系统隐含的需求；
准确性审查：应保证所描述的内容能够得到相关各方的一致理解，各项测试需求之间没有矛盾和冲突，各项测试需求在详尽程度上保持一致，每一项测试需求都可以作为测试用例设计的依据。
测试类型：
1) 功能测试
2) 界面测试
3) 安全测试
4) 本地/国际化测试
5) 数据库测试
6) 可靠性测试
7) 集成测试
8) 兼容性测试
9) 自动化测试
10) 性能测试
11) 回归测试
黑盒测试设计技术
1. 黑盒测试的概念
黑盒测试又称功能测试、数据驱动测试或基于规格说明书的测试，是一种从用户观点出发的测试。
2. 黑盒测试主要测试的错误类型有
①不正确或遗漏的功能；
②接口、界面错误；
③性能错误；
④数据结构或外部数据访问错误；
⑤初始化或终止条件错误等等。
3. 黑盒测试的实施过程
测试计划阶段
测试设计阶段
测试执行阶段
测试总结阶段
4. 黑盒用例设计技术（重点）
1）等价类划分方法（重点）
2）边界值分析方法（重点）
3）场景法 （重点）流程分析法，是业务流程
基本流（正常流）
备选流（异常流）
4）错误推测方法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。
5）因果图方法
考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多.
6）判定表驱动分析方法
判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的工具，它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
7）规则及规则合并
规则合并有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系
8）正交试验设计方法
它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，是一种高效率、快速、经济的实验设计方法。
5. 等价类划分方法
可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.
有效等价类
满足输入条件
无效等价类
不满足输入条件
超范围数值
空值
特殊字符
空格 （trim 去除空格）
6. 边界值分析方法：是对等价类划分方法的补充
7. 测试方法选择的综合策略
1) 首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效方法。
2) 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。
3) 用错误推测法再追加一些测试用例。
4) 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5) 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度
白盒测试 技术
语句覆盖
判定/ / 分支 覆盖
条件覆盖
路径覆盖
测试用例设计
1. 测试用例的主要构成要素
测试用例是一份测试文档，它描述输入、动作、和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作
2. 设计测试用例的原则
用语简洁清晰，但不能过于简单
用语无歧义，尽量少用过长的句子
用例的各个基本要素要齐备，不能缺失
用例的步骤应该足够详细，操作应该明确
容易被其它测试工程师读懂，并能顺利执行
3. 用例的粒度
1) 粒度，指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，反之同理
2) 用例的粒度大，则总的用例数就少，用例看起来也简洁
3) 用例的粒度小，则单条用例关注的测试点很集中，不容易遗漏，并且执行需要的时间比较好估计
4. 执行结果
1) 当用例还尚未被执行时，是New未执行状态
2) 当执行结果与预期结果相符时，是Pass通过状态
3) 当执行结果与预期结果不符时，是Fail失败状态
4) 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block阻碍状态。
5) 当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate观察中状态。
问题类型说明：
严重：
导致死机或误删信息或程序无法控制；
主要功能未实现或流程缺陷。
中等：
中等功能点未实现或流程缺陷；
数据结果错误或界面信息错误。
微小：不影响功能实现的其他缺陷。
建议：建议的改进。
待确认：无法进行测试，需要与客户沟通，待确认的问题。