软件测试：为了发现错误而运行程序的过程。
目的：
1.发现错误；
2.通过分析错误，发现软件过程缺陷，改进软件过程；
3.通过对测试业务的深入了解，对新产品的改进提出建议；
4.验证产品是否符合质量标准；
静态测试和动态测试
一、静态测试：不要求在计算机上实际执行程序，以模拟技术测试。（通过评审文档，阅读代码等方式测试软件，而不运行被测试程序本身。）
怎么做好文档测试：仔细阅读，跟随每个步骤，检查每个图形，尝试每个示例；检查文档的编写是否满足文档编写的目的；内容是否齐全，正确，完善；标记是否正确。
二、动态测试：输入实际数据来动态运行（路径和分支测试）。
黑盒测试和白盒测试
一、黑盒测试
指不基于内部设计和代码的任何知识，而基于需求和功能性的测试，也称功能测试或数据驱动测试。
方法：边界值法，正交试验设计法，等价类划分（程序输入分为若干部分，每部分选取代表性的输入），因果图法
二、白盒测试
基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径和条件的测试，也称结构测试或逻辑驱动测试。主要内容有语法分析、词法分析、静态错误分析和动态检测。
方法：边界值法，基本路径法，域测试，符号测试，程序变异，逻辑覆盖法，路径覆盖（实现路径覆盖则一定同时实现了判定覆盖；条件组合覆盖的测试覆盖最强。）
软件测试流程
（1）需求分析和讨论；
（2）编写测试计划：包含产品特点，主要功能模块，列出需测试功能点，标明侧重点，测试的策略和记录，测试资源分配；
（3）测试设计；
（4）测试执行；
（5）缺陷管理；
缺陷等级划分
A类：严重错误，包括由于程序所引起的死机，非法退出；死循环；数据库发生死锁；因错误操作导致的程序中断；功能错误；与数据库连接错误；数据通讯错误。
B类：较严重错误，包括程序错误；程序接口错误；数据库的表、业务规则、缺省值未加完整性等约束条件。
C类：一般性错误，包括操作界面错误(包括数据窗口内列名定义、含义是否一致)；打印内容、格式错误；简单的输入限制未放在前台进行控制；删除操作未给出提示；数据库表中有过多的空字段。
D类：较小错误，包括界面不规范；辅助说明描述不清楚；输入输出不规范；长操作未给用户提示；提示窗口文字未采用行业术语；可输入区域和只读区域没有明显的区分标志。
E类：测试建议。
缺陷管理：
1.引入缺陷管理工具（Mantis）；
2.考虑缺陷提交，状态和分析的管理；
3.所有发现的缺陷都必须全部及时准确地提交到缺陷管理工具中；（缺陷提交的管理）
4.缺陷提交后，需及时指派给相应的开发人员，密切关注状态，帮助尽快解决，解决后及时验证；（缺陷状态的管理）
5.总结如缺陷类别，龄期分布等信息；（缺陷分析的管理）
（6）测试报告。
测试用例
为实施测试而向被测试系统提供的输入数据、操作或各种环境设置以及期望结果的一个特定集合，包括测试用例编号、输入、所属类、预期输出、测试结果（通过\不通过）、缺陷编号等。
作用：
1、实施测试指导；
2、指导测试数据规划；
3、分析缺陷的基准；
4、提高功能测试覆盖率；
5、指导脚本编写；
通过画因果图来写测试用例的步骤：
(1)分析软件规格说明描述，哪些是原因（输入条件），哪些是结果（输出条件），并给每个原因和结果赋予一个标识符。
(2)分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系，根据这些关系，画出因果图。
(3)由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。
(4)把因果图转换成判定表。
(5)把判定表的每一列拿出来作为依据，设计测试用例。
软件测试按阶段划分
一、单元测试
针对程序模块进行正确性检验的测试工作。
目的：验证单元代码和详细设计文档的一致性；发现在编码过程中引入的错误；减少开发人员的调试代码时间；大幅减少后期缺陷数量。
二、集成测试
将所有模块按概要设计要求组装成子系统而进行的测试。
目的：验证各子模块组合起来能否达到预期要求的功能；验证一个模块的功能是否对另一个模块的功能产生不利的影响。
（冒烟测试：对产品版本进行最基本的测试。）
三、系统测试
将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下对计算机系统进行全面的功能覆盖。
目的：验证软件产品是否满足用户需求。包含功能、性能、安全性、易用性和兼容性测试等。（系统测试计划属于项目阶段性关键文档，因此需要同行评审。）
阶段评审与同行评审的区别
（1）同行评审目的：发现小规模工作产品的错误；
阶段评审目的：评审模块阶段作品的正确性、可行性及完整性。
（2）同行评审人数：3-7人，人员必须经过同行评审会议的培训，由SQA指导；
阶段评审人数：5人左右，评审人必须是专家，具有系统评审资格。
（3）同行评审内容：内容小，一般文档< 40页，代码< 500行；
阶段评审内容：内容多，主要看重点。
（4）同行评审时间：一小部分工作产品完成时；
阶段评审时间：通常是设置在关键路径的时间点上。
功能测试：主要是黑盒测试，由测试人员进行，主要验证产品是否符合需求设计要求；
易用性测试：主要由用户进行，主要对产品的用户界面和易用性进行测试。
性能测试：通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统各项性能指标进行测试。
负载测试：在于确定最终满足系统指标的前提下，系统所能承受的最大负载测试；
压力测试：目标则在确定什么条件下系统性能处于失效状态。
容量测试：目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值(如最大并发用户数、数据库记录数等)，系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量，是面向数据的。
可靠性测试：规定条件时间内，软件不引起系统失效概率。
吞吐量：设备接收的最大速率。
响应时间：指令发出到返回所用的时间。
四、验收测试
软件产品交付用户正式使用前的最后一道工序，以用户为主的测试，软件开发和测试人员也应参加。
α测试：内部人员参加，不能是程序员或测试员，需要用户代表参加；
β测试：公开测试，主要目标是测试可支持性。
五、回归测试
目的：在程序有修改的情况下，保证原有功能正常。
自动化测试工具
1.基于web的测试管理工具TestDirector，流程：测试计划、方案，测试用例录入，执行测试用例，记录缺陷，跟踪bug。
2.QTP：工作原理是执行重复的手动测试。（根据测试计划创建测试脚本，优化增强，运行，分析测试结果。）
3.性能测试工具loadrunner
组成部件：（1）Virtual User Generator（录制脚本）；（2）Controller（模拟多用户并发下回放脚本）；（3）Running Controller；（4）Analysis。
使用步骤：脚本录制设置→录制脚本→调试脚本→场景设置→结果分析
作用：（1）判断应用程序的问题；（2）判断CPU瓶颈；（3）判断内存泄漏问题。
4.QC
5.配置管理工具VSS等。
配置管理中最基本的活动包括配置项标识、配置项控制、配置状态报告、配置审计。
软件开发模型
瀑布模型，V模型，敏捷模型（版本更新，适合小团队）
结构化方法软件需求分析工具：
数据流图、数据字典、判定树、判定表。
