1．软件质量与软件测试
软件测试：在规定条件下对程序进行操作，以发现错误，对软件质量进行评估，包括对软件形成过程的文档、数据以及程序进行测试
软件质量：软件特性的总和，软件满足规定或潜在用户需求的能力
2．软件测试与质量保证
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作；
质量保证：通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产特
软件测试：通过执行软件来，对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量
3．软件测试的目的
测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于发现了至今未发现的错误；
一个成功的测试是发现了 至今未发现的错误的测试；
4．软件测试原则
所有的软件测试都应追溯到用户需求
应当把“尽早地和不断地进行软件测试”作为测试者的座右铭
完全测试是不可能的，测试需要终止
测试无法显示软件潜在的缺陷；
充分注意测试中的群集现象
程序员应避免检查自己的程序
尽量避免测试的随意性
5．软件测试对象
程序开发过程中的各个文档、源程序
6．软件测试过程模型－V模型
是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系；
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现
7．软件测试过程模型－W模型
在V模型的基础上，增加千开发阶段的同步测试，形成W模型；测试与开发同步进行，有利用尽早的发现问题
局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整
8．软件测试过程模型－H模型
在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行
9．测试模型使用
在实际工作中应灵活地运用各种模型的优点
| V模型 | 强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试 |
|---|---|
| W模型 | 补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明 |
| H模型 | 强调测试是独立的，只要测试准备完成，就可以执行测试 |
10．单元测试
| 定义 | 又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作；可以从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试 |
|---|---|
| 目的 | 发现模块内部可能存在的各种差错 |
| 内容 | 模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试 |
| 步骤 | 利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试 |
11.集成测试
| 定义 | 又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装 |
|---|---|
| 目的 | 发现模块连接中的接口可能存在的各种差错 |
| 内容 | 穿越模块之间的数据是否会丢失；一个模块组装后是否会对另一模块或其他模块存在影响；各个子功能组装在一起是否会达到预期的父功能；全局数据结构是否有问题；单个模块的错误累积起来是否会放在 |
| 组装方法 | 一次性组装方式，非增殖式方式也叫整体拼装，对模块分别测试然后将所有模块组装；第二种增殖式组装方式，可以是自顶向下或自底向上 |
| 完成标志 | 成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审 |
12．确认测试
| 目的 | 验证软件的功能和性能及其他特性是否与用户的要求一致 |
|---|---|
| 测试内容 | 有效性测试 运行黑盒测试方法验证所测软件是否满足需求规格说明书列出的需求；所有文档正确且便于使用；软件可移植性、易用性、兼容性进行测试；软件配置复查 保证软件配置的所有成分都齐全 |
13．系统测试
| 目的 | 验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试 |
|---|---|
| 测试内容 | 在真实或模拟系统运行环境下，检查完整的程序系统能否和系统（硬件设备、网络、系统软件）正确配置、连接，满足用户需求 |
14．验收测试
测试内容：根据任务书或合迥、供需双方约定的验收依据文档进行对整个系统的测试与评审，确认是否接收或拒绝系统；
15．开发方测试
通常也叫‘验收测试’或‘a测试’，在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求
16．用户测试
在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求。B测试通常被认为是用户测试，把软件有计划地免费地分发到目标市场，让用户大量使用、评价检查软件
17．第三方测试
由第三方测试机构来进行的测试，也称独立测试
18．动态测试
通过人工或使用工具运行程序进行检查，分析程序的执行状态和程序的外部表现
19．静态测试
不运行程序，能过人工对程序和文档进行分析与检查，包括走查、符号执行、需求确认等
20．白盒测试
通过对程序内部结构的分析、检测来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行
21．黑盒测试
又称功能测试，通过运行程序发现其缺陷和错误，在程序界面处进行测试
22．灰盒测试
介于白盒和黑盒测试之间，关注输出对于输入的正确性，也关注程序的内部结构，但没有白盒测试那样详细、完整
23．测试分类
| 开发过程 | 单元、集成、确认、系统、验证 |
|---|---|
| 实施组织 | 开发方、用户、第三方 |
| 测试技术 | 白盒、黑盒、灰盒或静态、动态 |
24．软件问题分类
软件错误、软件缺陷、软件故障、软件失效
软件错误：在软件生存周期内的不希望或不可接受的人为错误
软件缺陷：存在于软件（文件、程序、数据）之中的不希望或不可接受的偏差
软件故障：软件运行过程中出现的一种不希望或不可接受的内部状态。
软件失效：软件运行时产生的一种不希望或不可接受的外部行为
25．GB/T16260.1 产品质量－质量模型
质量模型：代表软件质量属性的总体
软件质量特性与度量：质量特性和子特性、外部度量、内部度量
外部、内部质量的质量模型：质量属性包括：功能性、可靠性、易用性、效率、维护性和可移植性
26．GB/T18905.1 软件工程 产品评价－概述
概述了软件产品评价的过程，提供了评价需求和指南
27．GB/T18905.5 软件工程 产品评价－评价者用的过程
28．软件测试的国内外现状
国外：软件测试已成为一个独立的产业，在软件公司占有重要的地位，软件测试理论研究蓬勃发展，软件测试市场繁荣，开发了大量的测试工具；
国内：软件测试成为一个新兴产业，测试技术贫乏，从业人员少，测试服务没有足够规模；著名的软件公司已成立了专业的测试队伍，国家在职业资格中新增了‘软件评测师’，企业资集认证时软件测试能务成为重要指标，软件产品增加了登记测试，成立第三方测试机构，软件测试成为一个独立课程
29．软件评测发展趋势
测试工作将进一步前移
软件架构师、开发工程师、QA人员、测试工程题将进行更新的融合
测试行业将得到充分的尊重
设置独立的测试部门将得到越来越多公司的软件公司的共识
测试外包服务将快速增长
30．测试过程的特性与要求
31．软件测试与配置管理
32．测试的组织与人员
33．软件测试风险分析
软件测试风险：是软件测试过程出现的或潜在的问题，造成的原因主要是测试计划的不充分、测试方法有误或测试过程的偏离，造成测试的补充以及结果不准确
软件测试风险主要是对测试计划执行的风险分析与制定要采取应急措施；重点在措施
测试计划的风险：一般指测试进度滞后或出现非计划事件；常见的有交付日期、测试需求、测试范围、测试资源、人员的能力、测试预算、测试环境、测试支持、测试工具；
34．软件测试的成本管理
| 测试实施成本 | 测试准备成本、测试执行成本、测试结束成本 |
|---|---|
| 低测试实施成本 | 测试准备环境尽可能使用软件和测试环境配置自动化；测试实施尽可能采用自动化测试工具（测试用例自动化执行），人工测试最好请初级技术人员，不使用测试工程师；测试结束编制测试报告测试结果与预期结果比较采用自动化方法（测试文档编制模板化） |
| 质量成本要素 | 质量成本＝一致性成本+非一致性成本 |
| 缺陷探测率DD P | ＝Bugs（tester）/ （Bugs（tester）+ Bugs（customer）） |
35．文档测试的范围
| 用户文档 | 用户手册、操作手册、维护修改建议 |
|---|---|
| 开发文档 | 需求说明书、概要设计、数据库设计、详细设计、可行性研究报告 |
| 管理文档 | 项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告 |
36．用户文档的内容
包装上的文字及图案；宣传材料、广告及其他插页；授权/注册登记表；最终用户许可协议；标签和不干胶条；安装和设置指导；用户手册；联机帮助；指南、向导；样例、示例和模板；错误提示信息；
37．用户文档测试的要点
明确读者群：根据读者群（如初级、中级、高级用户）的不同来检查文档内容，保证用户能够看得懂、能理解
术语：文档中术语的描述要适合定位的读者群，用法一致，标准定义与业界规范相吻合
文档内容的正确性：要保证所有信息是真实正确的
文档内容的完整性：要完全根据提示逐步操作，检查是否存在遗漏的地方
文档与程序的一致性：按照文档操作后，检查软件返回的结果与文档描述是否一致
文档的易用性：检查是否便于用户查找相应的内容
图表与界面截图：检查所有图表与界面截图与发布的程序版本一致
样例和示例：检查所有的样例和示例能够正确完成；
语言：中文文档保证无错别字和二义性
印刷与包装：印刷质量，包装质量
38．用户手册的测试
准确的按照手册的描述使用程序；尝试每一条建议；检查每条陈述；查找容易误导用户的内容；
39．在线帮助的测试
内容的准确性；帮助功能的可靠性；每一条索引和主题列表要逐条检查，是否能够由索引进入主题；帮助系统中的每一个超级链接；主题是否全部能够在索引中找到；帮助系统的风格应简洁；
40．功能易用性测试
41．用户界面测试：界面整体、界面元素测试
42．硬件兼容性测试
43．软件兼容性
44．数据兼容性测试
45．平台化软件兼容性测试
46．新旧系统数据迁移测试
47．安全测试－测试内容
48．安全测试－测试策略
49．安全性测试方法
50．软件产品安全测试
51．网络系统全生命周期测试策略
52．网络测试－网络仿真技术
53．网络性能测试
54．网络测试－网络应用测试
55．Web应用的测试策略
56．Web应用设计测试
设计测试的主要内容是对设计从全面性、适合性、标准性等方面进行检查
57．Web应用开发测试
对Web应用的源代码和组件进行测试，保证代码的正确性、组件的功能正常
58．Web应用运行测试
59．负载压力测试基本概念
60．负载压力测试解决方案
一．并发性能测试
并发压力过程与测试定位
（1）并发负载压力的实施：客户端――应用客户端的测试
（2）负载压力的传输介质：网络――应用网络上的测试
（3）压力到达：各类服务器――应用服务器端的测试
二． 并发性能测试－应用服务端测试
1． 目的：模拟大量并发用户执行不同业务操作，达到实施负载压力的目的
1．测试环境
（1）测试工具主控台（1个）：负责管理各个测试工具代理，收集各类测试数据
（2）负载生成器（多个）：即代理，模拟虚拟用户
（3）服务器
3．影响服务器的负载级别
（1）选择在方案运行过程中活动的集合点
（2）选择加入每个集合的Vuser数
4．控制服务器上的负载峰值
（1）创建Vuser脚本，插入必要的集合点（采用录制功能将操作过程录制形成脚本，插入某一项操作的集合点）
（2）创建方案（建立Vuser组，指定每组的user及数量、运行的脚本等信息）
（3）向方案中添加Vuser组，搜索设置的集合点，并将集合点名称添加到‘集合信息’列表中
（4）设置虚拟用户负载的级别
（5）通过选择加入到方案中的集合点及加入每个集合的Vuser数，可以确定负载的精确级别
（6）设置集合的属性
（7）对于每一个集合，都可以设置集合策略
（8）运行方案（在此之前，可以同时配置负载生成器和Vuser行为）
5．客户端交易处理性能指标
（1）并发用户数指标
（2）交易处理指标：平均事务响应时间、每秒事务数、每秒事务总数、事条摘要、事务性能摘要、事务响应时间（负载下、百分比、分布）
（3）Web请求指标：每秒点击次数、吞吐量、吞吐量摘要、HTTP状态代码摘要、每秒HTTP响应数、每秒下载页面数、每秒重试次数，重试次数摘要、连接数、每秒连接数、每秒SSL连接数
（4）Web页面组件指标：激活网页细分、页面组件细分（随时间变化）、页面下载时间细分（随时间变化）、第一次缓冲时间细分（随时间变化）、已下载组件大小
三．并发性能测试－应用网络上性能测试
四．并发性能测试－应用服务器端的测试
（一） 概述
1． 对应用服务器端的测试主要包括三方面：操作系统、数据库和中间件的监控
2． 监控手段：可以采用工具自动监控，也可以使用操作系统、数据库、中间件本身提供的监控工具
3． 利用工具监控的优点
（1）减少故障诊断和分析时间
（2）减少手工定位的时间和避免误诊
（3）在问题发生前定位故障
（4）验证可达到的性能水平和服务水平协议
（5）持续的服务器、数据库和应用性能和可用性监控
（6）故障诊断和恢复：自动报警、故障恢复程序、故障恢复信息
（7）服务器、应用可用性和性能报告
（二） 操作系统监控
操作系统的监控涉及后台重要服务器的操作系统监控，对于主流的操作系统，主要关注：内存、CPU、硬盘
监控建议：
1．磁盘管理
（1）采集物理读/写和逻辑读/写信息
（2）收集操作系统和其他平台上的磁盘忙信息
（3）监控I/O
2．文件系统
（1）显示每个文件系统的使用率，检测文件系统空闲空间的大小
（2）剪裁文件系统－删除指定的CORE（核心）文件和其他文件
（3）显示文件系统的mount on device、type、size
（4）可以监控特殊的文件系统，如NFS（网络文件系统），CD-ROM
（5）检测特定文件的存在及超出特定期限的文件存在
3．内存
（1）显示可用的内存数量
（2）决定当前的内存短缺量
（3）帮助分析内存问题
（4）显示内存的实存、所有虚存和kernel（核心内存）的状态等信息
4．CPU
（1）记录CPU的使用率
（2）监测CPU参数，包括CPU idle（空闲）,CPU waits,CPU system usage,CPU user usage,run queue length（运行队列长度）
（3）显示CPU context（上下关系） switches 的总数
（4）显示CPU处理系统任务和完成用户任务的时间比例
5．操作系统举例
（1）UNIX操作系统
（2）Windows操作系统
（三） 数据库监控
1．共性的指标
（1）监控数据库系统中关键的资源
（2）监测读写页面的使用情况
（3）监控超出共享内存缓冲区的操作数
（4）监测上一轮询期间作业等待缓冲区的时间
（5）跟踪共享内存中物理日志和逻辑日志的缓冲区的使用率
（6）监控磁盘的数据块使用情况以及被频繁读写的热点区域
（7）监控用户事务或者表空间监控事务日志
（8）监控数据库锁资源
（9）监测关键业务的数据表的表空间增长
（10）监控SQL执行情况
2．监控建议－针对监控内存缓冲区、会话及磁盘等方面
（1）监控超出共享内存缓冲区的操作：可以调整缓冲区大小，更好的支持系统运行
（2）扩展的会话/用户检查以及参数控制：发现不合理顺序扫描操作，从而分配附加的资源，修改应用程序，降低对系统资源的要求
（3）磁盘：监控数据块的使用情况以及被频繁读写的热点区域，可以平衡数据量的存储分配及I/O分配
3．数据库举例
（1）Oracle：内存统计、SQL分析、会话统计、事件统计
（2）Sysbase：
（3）DB2：
（4）SQL Server：
（四） 中间件监控
1．中间件分类
（1）Web服务器： Apache
（2）Web应用服务器： Websphere、WebLogic
（3）应用服务器： tuxedo
2．中间件举例
（1）TUXEDO：
（2）WebSphere：队列性能计数器、通道性能计数器
（3）WebLogic：LogBaroadcasterRuntime、ServerSecurityRuntime
五．负载压力测试解决方案－疲劳强度测试
强调长时间的考核，主要是过长时间运行系统，发现问题
1．日常强度疲劳强度测试
模拟系统的日常业务（正常情况），持续执行‘一段时间’，暴露系统的性能问题，如内存泄露、资源争用
2．高峰业务疲劳强度测试
（1） 模拟系统的高峰业务（最大业务量），持续执行‘一段时间’，暴露系统的性能问题
（2） 时间指标要满足：
（1） 这段模拟时间所处理的交易量要达到系统疲劳强度需求的业务量
（2） 在这段测试周期中必须通过加大负载，以及尽可能长的测试周期来保证疲劳强度测试
六．负载压力测试解决方案－大数据量测试
1．大数据量测试类型
（1）独立数据量测试：针对某些系统存储、传输、统计、查询等业务进行单用户大数据量测试，如大量的批处理任务
（2）综合数据量测试：采用并发测试、疲劳强度测试以及大数据量测试相结合的综合测试方案
2．自动生成大数据量
（1）借助自动化测试工具，利用数据库测试数据自动生成工具，如TESTBytes
（2）利用自动化负载压力测试工具，模拟用户业务操作，同时并发数百个或数千个用户生成相关数据
（3）自主开发数据生成工具
（4）数据库本身的辅助工具
3．大数据量管理
（1）手工管理：
（2）自动化工具管理：File-Aid/CS 数据库管理工具 ，完成比较数据和数据库结构；转换关系数据库数据成XML数据；比较XML数据与关系数据库数据；比较XML文件；数据迁移
61．负载压力测试指标分析
主要包括客户端交易处理性能指标、服务器资源监控指标、数据库资源监控指标、Web服务器监控指标、中间件监控指标
62．负载压力测试实施
63．软件自动化测试基本概念
64．选择自动化测试工具
65．功能自动化测试
66．负载压力自动化测试
