ST测试基础

一、软件生命周期

         1、问题的定义及规划：此阶段时软件开发方与需求方共同讨论，确定软件的开发目标及其可行性。——做与否

        2、需求分析：在确定软件开发可行的情况下，对软件需要实行的功能进行详细分析。——做什么

        3、软件设计——怎么做

        4、程序编程——做

        5、软件系统测试

        6、运行维护——持续最久的阶段

二、软件研发模型

         1、【瀑布模型】——应用最为广泛的一种模型，最容易理解掌握的模型，缺陷也是显而易见的。

        2、【大V模型】——综合了基本的瀑布式模型和演化/渐增的原型方法。

        3、【双V模型】——是开发阶段与测试设计阶段同步进行，开发保证需求被实现，测试验证是否正确。此模型不是在V模型上增加一个V模型。

        4、【敏捷模型】——代码未动，测试先行。敏捷开发中，软件项目被分成多个子项目，各子项目的成果都经过测试，具备集成和可运行的特征。（即把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。此过程中软件一直处于可用状态，项目的迭代周期快。快速开发、迭代，快速上线。）

 三、软件测试/质量

        1、质量保证（QA）：主要针对软件开发活动中的过程、步骤和产物，不是对软件进行剖析找出问题或评估。——监督过程。

        2、软件测试（QC）：关心的不是过程的活动，是对过程的产物及开发出的软件进行剖析。——监管产品。

四、软件的组成

        1、程序+文档+数据（比如：需求文档、概要设计文档、详细设计文档、操作手册、源程序）

五、软件测试分类

        1、按阶段分类

                （1）单元测试——针对软件基本组成单元（软件设计的最小单位）来进行正确性检验的测试工作,单元测试的目的是检测软件模块对《详细设计说明书》的符合程度。开发人员做单元测试。

                （2）集成测试——是在单元测试的基础上，将所有模块按照概要设计要求组装成为子系统或系统，验证组装后功能以及模块间接口是否正确的测试工作，集成测试的目的是检测软件模块对《概要设计说明书》的符合程度。

                （3）系统测试——系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作，系统测试的目的在于通过与《需求规格说明书》作比较，发现软件与系统需求定义不符或与之矛盾的地方。

                （4）验收测试——软件正式发布前还可能进行有用户参与的其他一些测试，即验收测试，验收测试开始在通过了内部系统测试及软件配置审查之后，以用户为主，验收组应该由项目组成员、用户代表等组成。验收测试原则上在用户所在地进行，但如经用户同意也可以在公司内模拟用户环境进行验收测试根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。

         2、按测试的实施组织划分

                （1）开发方测试：alpha——α测试是由用户在开发环境下进行的测试，也是开发机构内部的用户在模拟实际操作环境下进行的测试。α测试时，软件在一个自然设置状态下使用。开发者坐在用户旁，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试。α测试的目的主要是评价软件产品的FLURPS（即功能、局域化、可用性、可靠性、性能和技术支持）。

                （2）用户方测试：Beta测试——β测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。与α测试不同的是，β测试时开发者通常不在测试现场。β测试是在开发者无法控制的环境下进行的软件现场应用。

                （3）第三方测试

        2、按照测试技术划分

                （1）黑盒测试——不关注程序的内部结构，只关注输入输出。   

                （2）白盒测试——关注程序的内部逻辑

                （3）灰盒测试——关注输入输出，能根基软件的表现分析出程序的执行逻辑。

                （4）动态测试——软件运行起来进行测试

                （5）静态测试——不运行软件，检查文档和编码规范

        3、按照测试需求划分

                （1）功能测试

                （2）性能测试

                （3）安全性测试

                （4）等其他测试

        4、按照测试方式划分

                （1）手工测试

                （2）自动化测试 ——代替不了手工测试，项目不稳定时不能进行自动化测试

        5、按其他测试

                （1）冒烟测试——检查核心功能是否通过

                （2）随机测试

                （3）回归测试——软件在测试或其他活动中发现的缺陷经修改后，应进行回归测试，目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响。以前的功能回归测试可发生在任何一个阶段，包括单元测试、集成测试和系统测试。

                        回归策略：

                        1、完全重复测试——重新执行所有在前期测试阶段建立的测试用例，来确认问题修改的正确性和修改的扩散布局影响性。

                        2、选择性重复测试——有选择地重新执行部分在前期测试阶段建立的测试用来，来测试被修改的程序。（覆盖修改法、周边影响法、指标达成法）

六、测试流程

        1、参与需求评审（需求澄清会，需求是由产品经理发起的。目的：1、产品开发、测试对需求的理解统一；2、评审需求是否合理；3、评估风险和影响范围；4、评估工作量）

        2、测试计划的编写（5W1H)

        3、测试用例的设计与评审

        4、测试环境的搭建

        5、测试的执行阶段

        6、提交bug、跟踪bug、回归测试、编写测试报告

        7、测试结果的验收（1、web验收；2、产品验收）