第二周-测试基础

测试基础

 

1.相关概念

软件测试：找bug，根据需求对比，发现问题，实际工作时是一套通用的规范

 

软件测试对象：程序+数据+文档

 

2.软件生命周期（software development life cycle，SDLE）

定义：软件从无到有再到消亡的过程

    需求调研 request for proposal

    需求分析阶段 requirements analysis ——生成需求文档

    设计 design 搭出框架

    开发 coding 实现功能

    测试 testing 发现问题，开发的和需求是否一致

    发布 deploy 给客户

  运维 production support 售后服务

  

 

3.环境

  开发环境：开发程序代码所使用的，代码是最新的

    测试环境：测试人员执行软件测试的，刚开始的时候两者是没有区分的

  生产环境：已经测试通过的版本发布给客户使用，最老的（每个人手机上使用的微信版本，会有更新，就是不断的在开发，测试）

 

4.测试基本原则

  测试是上下文相关的     testing is context dependent       不同项目背景的软件侧重点不一样。

  穷尽测试是不可能的     exhaustive testing is not impossible       挑选代表性数据或者场景测试。

  测试尽早介入     early testing is always preferred       有可能需求文档就有错误，减少维护成本。

  杀虫剂悖论     defects clustering       每次使用同样的测试用例无法发现新的bug。

  缺陷群集性     pesticide paradox       一个模块有bug，有可能也产生其他的bug，大部分的缺陷可能存在于少量的模块中。

  测试是为了存在缺陷     testing shows presence of defects       尽可能多的发现bug，并得到修复。

  无错谬误     absence of errors is fallacy       没有发现表示当前没有暴露，不代表不存在。（与6）

 

 

5.软件开发模型

 

  瀑布型（唯一被广泛采用的）每一个环节的开始都是基于上一个环节的完成，每个环节的文档都要详细，方便后期维护，出现问题，维护成本较高。

   

  原型反复确认需求阶段，避免问题在后期发现，每个环节输出的文档要求没有瀑布模型高。

    

以上为早期模型

敏捷模型（重点理解，现在使用较多）agile development 以人为核心、迭代、循序渐进 在原有的版本上不断迭代开发，先开发某些功能，依次实现，增量开发，尽早让客户体会到。scrum

 

其它模型（了解）：

螺旋模型：适合于大型复杂软件系统

RUP模型（Rational Unified Process）：模型过于复杂，难于掌握，耦合度高不适合

 

 

7.软件测试模型

 

测试模型和开发模型不是一一对应的关系

 

V模型

需求分析-概要设计-详细设计（一般概设、详设是放一起的，不做区分）-编码——单元测试（代码测试，对代码进行验证，比较细小）-集成测试（功能验证，单元与单元之间的验证）-系统测试（系统非功能性验证，整个软件作为计算机系统的要素，考虑到环境，包含功能性和非功能性）-验收测试（基于用户需求验证，用户发起）

测试是在编码结束后开始的

  优点：既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。

  缺点：把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段，不能体现“尽早地和不断地进行软件测试”的原则。

 

W模型（除了对软件测试还需要对过程中产生的文档进行测试，文档评审或检查）

  优点：

      如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。

      测试者可以在项目中尽可能早地面的规格说明书中的挑战。 

      测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。

  缺点：无法支持迭代、自发性以及变更调整。

 

H模型（测试与开发等其他环节是并行工作的）

  优点：

      软件测试不仅仅指测试的执行，还包括很多其他的活动。

      软件测试是一个独立的过程，贯穿产品整个生命周期，与其他流程并发地进行。

      软件测试要尽早准备，尽早执行。

      软件测试是根据被测物的不同而分层次进行的。

      不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

      软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。

X模型、前置模型等

8.软件测试阶段

    

先单元后集成，但是确认 、系统、验收没有时间先后顺序

8.回归测试：regression testing （必须清楚）

  可以发生在任何一个阶段，开发对bug修改以后进行测试，验证缺陷得到正确修复，同时对系统的变更没有影响以前的功能。

回归测试策略（重点）

1.完全重复测试

2.选择性重复测试

    2.1覆盖修改法：针对被修改的部分，范围最小

    2.2周边影响法（使用较多）：对受到修改间接影响的部分也进行测试

    2.3指标达成方法：在重新测试前，先确定一个达成的指标，如修改部分代码100%的覆盖、与修改有关的接口60%的覆盖等，基于这种要求选择一个最小的测试用例集合。基于前期的数据积累或者经验。

回归测试流程

以下流程适合于单元测试、集成测试和系统测试

1.在测试策略制定阶段，制定回归测试策略

2.确定需要回归测试的版本

3.回归测试版本发布,按照回归测试策略执行回归测试

4.回归测试通过，关闭缺陷跟踪单（问题单）

5.回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

 

回归测试自动化（重复执行的，不能替代手工测试）

  难以预料回归次数，所以采用自动化测试，对于操作相对简单的可以用“捕捉回访”工具，如selenium

冒烟测试

  为了检查软件新编译的版本基础主要功能是否实现，能不能进行后续的正式测试工作

  涉及到CS的软件才涉及到安装/卸载

 

 

9.软件测试质量

 质量属性：分为两大类“功能性”和“非功能性”，功能性是最基本的，非功能性也称能力（capability）

   功能性、可靠性、易用、效率、维护性、可移植性

 

10.软件测试流程（重点）

  •测试计划阶段 –输出– 测试计划（测试组长）

  •测试设计阶段 –输出– 测试方案（测试组长或经验丰富的）

  •测试实现阶段 –输出– 测试用例、测试规程（每个人依据需求根据自己的模块）

  •测试执行阶段 –输出– 测试报告（体现测试数据）、缺陷报告（发现问题编写测试报告单提交给开发）

11.软件测试类型

功能测试、安全性测试、性能测试、负载测试、压力测试、容量测试、定性测试、异常测试、GUI测试、可用性测试、安装/卸载测试、文档测试、网络测试（接口测试）、兼容性测试

 

12.软件测试方法

  •黑盒测试和白盒测试、灰盒测试

 •静态测试和动态测试

 •人工测试和自动化测试试方法