软件测试基础
测试定义
通过人工或自动的手段，对被测对象进行检测的活动，目的在于发现被检测对象是否实现用户的需求，或者弄清楚实际结果与预期结果之间的差异。
需要理解什么软件
源代码
用户手册
配置数据
测试目的
发现被测对象与用户需求间的差异--俗称bug
通过测试活动，发现并解决缺陷，增加人们对被测对象的质量信心
通过测试活动，获取被测对象的质量信息，为决策提供数据依据
通过测试活动，预防缺陷，从而降低项目或产品的风险
测试原则
测试证明软件存在缺陷
不可能执行穷尽测试
测试应尽早启动，尽早介入
缺陷存在群集现象
杀虫剂驳论
不同的测试活动依赖不同的测试背景
不存在缺陷的谬论
测试对象
软件源代码
与软件源代码匹配的文档
支撑软件源代码运行的配置数据
需求间段-需求文档-测试需求文档是否正确实现了用户的需求
系统设计阶段
概要设计文档
详细设计文档
是否有设计或逻辑上的错误
编码阶段-测试源代码-发现编程上的错误
系统测试阶段-被测对象是否满足用户需求
测试级别：单元测试、集成测试、系统测试、验收测试
单元测试
针对被测对象最小的组成单元实施的测试活动，
一般是类或函数，也可能是最小的功能单元。
集成测试
针对组件/单元与组件/单元之间的接口实施的测试活动，
验证接口设计是否与设计相符合。
分3种集成
函数间集成
模块间集成
子系统间集成
系统测试
将通过集成测试的软件，部署在真实的用户环境下执行测试
验收测试
以用户为主的测试，验收组应该由项目组成员、用户代表组成。
α测试：由用户在开发环境下执行的测试活动，开发者在测试人员身边，发现问题及时沟通解决。
在受控环境下执行测试。
β测试：开发者不在测试人员身边，发现问题由专人统一收集，在由研发人员进行修正。
在不受控环境下执行测试。
UAT测试：用户接受度测试，一般商业用户验证系统可用性进行的测试
系统测试类型
功能性测试
在指定的条件下，使用被测对象，验证其是否满足显性或隐性需求。
测试关注点
-是否有不正确或遗漏或多于的功能
-是否满足系统显性或隐性需求
-是否对输入输出做出了正确的响应，输出结果能否正确的显示
性能测试
通过模拟被测对象运行业务压力或者使用场景，验证被测对象是否满足预先设定的性能指标。
验证系统是否具有所宣称的能力
要求在真实环境下实施
安全性测试
测试被测对象的安全保护机制保护系统不受非法入侵，能够接受正确授权的操作。
兼容性测试
验证被测对象在不同的操作系统、硬件信息等环境下的运行情况。
软件测试的方法
黑盒测试
不关注被测对象内部结构，仅从用户需求考虑是否满足用户显性或隐性需求。
白盒测试
结构测试、逻辑驱动测试，关注源代码。
灰盒测试
既关注对象的外部特性，又关注其内部设计。
静态测试
不执行被测对象程序，不运行被测对象的测试方法。
动态测试
执行被测对象，进行的检测活动。
手工测试
通过测试工程师试用，验证被测对象是否满足用户需求。
自动化测试
通过自动化测试工具，或者脚本语言自动化完成测试过程。
软件质量
质量定义：质量是物体本身的属性，物体的质量与物体的形状、物太及其所处的空间位置无关，质量是物体的基本属性。
软件质量：软件产品满足用户或规定的显性需求和隐性需求的程度。
内部质量
过程质量
外部质量
使用质量
质量特性
功能性
-定义：软件在指定条件下使用时，满足用户显性需求和隐性需求功能的能力。
适合性：软件为指定的任务和用户目标提供一组合适功能的能力
准确性：软件能够提供具有所需精度的正确或相符的结果或效果的能力
互操作性：软件能够与一个或多个系统进行交互的能力。
保密安全性：软件保护信息和数据的能力，以及使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问。
功能性依从性：软件遵守与功能相关的标准、约定或法律以及类似规定的能力。这些标准要考虑国际标准、国际标准、行业标准、企业内部规范等。
可靠性
-定义：软件在指定条件下使用时，维持规定的性能级别的能力。
成熟性：软件为避免由软件中错误而导致失效的能力。
容错性：在软件出现故障或者违反指定接口的情况下，软件维持规定的性能级别的能力。
易恢复性：在失效发生的情况下，软件重建规定的性能级别并恢复受直接影响的数据的能力。
可靠性依从性：软件遵守与可靠性相关的标准、约定或法规的能力。
易用性
-定义：软件在指定条件下使用时，软件被理解、学习、使用和吸引用户的能力。
易理解性：软件能够使用户理解软件是否适用，以及如何能将软件用于特定的任务和使用环境的能力。
易学性：软件能够使用户可以学习其应用的能力。
易操作性：软件使用户可以操作和控制它的能力。
吸引性：软件吸引用户的能力。
易用性依从性：软件遵守与易用性相关的标准、约定、风格指南或法规的能力。这些标准要考虑国际标准、国家标准、企业内部规范等。
效率
-定义：在规定条件下，相对于所用资源的数量，软件可提供适当性能的能力。
时间特性：在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能力，即完成用户的某个功能需要的响应时间。
资源利用性：在规定条件下，软件执行其功能时，使用合适的资源数量和类别的能力。
效率依从性：软件遵循与效率相关的标准或约定的能力。
可维护性
-定义：软件可以被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应。
易分析性：软件诊断软件中的缺陷、失效原因或识别待修改部分的能力。
易改变性：软件使指定的修改可以被实现的能力。
稳定性：软件避免由修改而造成意外结果的能力。
易测试性：软件使已修改软件能被确认的能力。
维护性依从性：软件遵守与维护性相关的标准或约定的能力。
可移植性
-定义：软件从一种环境迁移到另一种环境的能力。
适应性：软件无须采用有别于为考虑该软件的目的而准备的活动或手段，就可以适应不同指定环境的能力。
易安装性：软件在指定环境中被安装的能力。
共存性：软件在公共环境中同与其分享公共资源的其他独立软件共存的能力。
易替换性：软件在同样环境下，替代另一相同用途的指定软件产品的能力。
可移植性依从性：软件遵守与可移植性相关的标准或约定的能力。
系统测试流程
测试计划设计
目标
总体概述 -项目背景 -项目范围
测试计划
应交付的测试工作产品
资源分配 -培训需要 -测试工具开发
测试计划
-测试资源需求
-组织形式
-测试对象
-需求跟踪
-测试通过/失败表准
-测试挂起/恢复条件
-测试风险及防范
-测试任务安排测试资源需求
-软件资源
-操作系统资源：Windows、Linux、Unix、MAC
-数据库资源：SQL Server、MySQL、Oracle、Sybase、DB2
-Web服务器:IIS、Tomcat、JBOSS、RESIN、Weblogic、WebSphere
-需加版本号，所有软件。
-硬件资源：硬件服务器、电脑、手机、平板、测试设备等。
-其他设备资源
-人员需求
测试需求管理
分析需求来源
-需求规格说明书
-开发需求
-继承性需求
-行业竞品分析
-经验库
需求分类
-功能需求
-性能需求
-外部接口需求 -GUI -外部应用程序接口需求
-根据软件质量特性划分需求—安全性、效率、可移植、可维护。
竞品分析
竞品分析的内容可以由两方面构成：客观和主观。
竞品分析顾名思义，是对竞争对手的产品进行比较分析。
客观即从竞争对手或市场相关产品中，圈定一些需要考察的角度，得出真实的情况；此时，不需要加入任何个人的判断，应该用事实说话。
主观是一种接近于用户流程模拟的结论，比如可以根据事实（或者个人情感），列出竞品或者自己产品的优势与不足。其实你在分析别人的产品的同时，实际上是走了一遍用户流程。
测试策略设计
测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。
测试策略的制定主要包含三个方面的内容：
（1）确定测试过程要使用的测试技术和工具；
（2）制定测试启动、停止、完成标准；
（3）进行风险分析和应对方案。例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。
测试规程设计
测试需求变更控制流程
测试用例变更控制流程
测试环境搭建流程
缺陷管理流程
测试用例设计
配置测试环境
分平台：Windows、Linux、Unix
分架构：J2EE –JAVA平台+JSP
.NET平台 -APSX
LAMP平台 -PHP
分Web服务器：IIS、apache、tomcat、resin、jboss、Weblogic、websphere
分数据库：SQL SERVER、MYSQL、ORACLE、DB2、SYBASE
测试用例执行
预测试阶段 -冒烟测试 –快速的对被测试对象实施测试活动
-验证被测试对象能否完成核心功能或高风险功能能否正常工作。
预测试结束后需要转到系统测试评审。
预测试用例来源于系统测试用例设计阶段的高级别用例。
系统测试阶段 –经过预测试后，通过系统测试评审，开展系统测试。
测试执行过程中发现缺陷，则需要及时记录缺陷，根据部门或团队的缺陷管理流程进行缺陷提交、跟踪处理。
缺陷跟踪回归
测试报告输出
测试日报
（1） 方便测试工程师掌握测试进度和测试情况，用于调整下一天的工作计划。
（2） 测试工程师对被测对象每天给出评估结果，用于调整后续工作中的测试策略。
（3） 测试经理通过测试日报了解每个测试工程师的工作进度，把握测试整体进度，发现进度上的风险从而及时调整计划。
（4） 测试经理通过测试日报，了解各模块缺陷发展趋势，判断测试是否可以退出，通常可利用缺陷管理工具的统计分析功能了解缺陷发展情况。
（5） 开发经理根据日报了解测试对象的质量情况，并可以调整缺陷修改人力资源。
（6） 如果产品有多个测试组并行测试，测试日报可以提供彼此交流的手段。
测试报告
（1） 评估软件测试工程师当前被测对象的质量情况，并对下一阶段的测试工作给出建议。
（2） 测试经理通过测试报告了解被测试产品的质量情况，和测试过程的质量。
（3） 软件开发项目经理通过软件测试报告了解开发产品的质量，并在下一阶段的开发工作中采取相应措施。
（4） 在测试报告中，测试工程师给出的产品质量评估可以作为软件产品是否商用发布的重要参考依据。
测试报告模板
测试结束活动
（1） 检查在测试过程中测试计划中定义的输出。
（2） 缺陷管理是否完成，是否已经进入缺陷管理流程。
（3） 测试实施过程中产生的风险报告需要记录。
（4） 测试报告是否给出，相关的经验教训是否总结并分享。
（5） 是否需要转移测试对象。
一：系统测试阶段
按照测试流程跟大家上课 如下：
1.需求分析
2.根据需求分析提取测试项
3.根据测试项提取测试要点 在进行1-3的工作时候可以同时进行 测试计划、方案编写
4.根据测试要点编写测试用例 环境搭建
5.评审用例
6.预测试（选取用例级别高的案例优先执行）
7.正式测试（提出缺陷并进行缺陷管理）
8.回归测试
9.缺陷报告 测试报告
10.测试总结