测试基础【第一篇】一篇文章带你完全理解测试基础

0.概念

软件：实现用户需求的源代码及与之匹配的文档和支撑其运行的配置数据。是一种逻辑存在的资产。（数据结构+算法+文档+服务）。
软件测试：以用户需求为基准，运用科学的测试方法对被测对象进行检测，发现其与需求偏离的需求实现。
软件测试：是为了尽快尽早发如今软件产品中所存在的各类软件缺陷而展开的贯穿整个软件开发生命周期、对软件产品（包括阶段性产品）进行验证和确认的活动过程。
调试：通俗的理解，对软件程序代码作出的一系列检查、改正的过程，以保证软件可以正常运行为目的。（早期软件代码少，逻辑简单，程序员彻底能够应付）
软件测试目的：
程序测试是为了发现错误而执行程序的过程；
一个好的测试用例是发现迄今为止还没有发现的错误的测试用例；
一个成功的测试执行是发现了至今为止还没有发现的错误的测试执行。
注意：软件测试的目的不只仅是为了发现错误，还有易用性等测试，这些统称为缺陷。（发现其与需求偏离的需求实现）
修改缺陷的成本随项目发展而变高；寻找缺陷的时间随项目发展而变难。

1.人们对软件测试目的的认识过程

证实（代表软件可以工做）→检测（发现错误）→预防（管理质量）。
注意：早期的结构化同行评审被用于帮助预防编码前的缺陷。

2.测试执行

单元测试执行（UT执行）：一个测试用例的测试执行；
集成测试执行（IT执行）：一个测试用例集的测试执行；
系统测试执行（ST执行）：不一样测试阶段的测试执行。

3.测试和调试的区别

4.回归测试的目的

（回归测试应用于：增量开发；版本控制；软件维护）

验证缺陷是否修复或增长的部分是否正确；

检测对代码的修改是否引入了新的错误。

5.软件测试的主要工做

检视代码，评审开发文档；
进行测试设计，写做测试文档（测试计划、测试方案、测试用例等）；
执行测试，发现软件缺陷，提交缺陷报告，并确认缺陷最终获得了修复；
经过测试度量软件的质量；
……

6.软件危机的出现主要表如今

1.因为缺少大型软件开发经验和软件开发数据积累，开发工做计划很难制定；
2.开发早期需求分析不够明确，形成开发后期矛盾集中暴露；
3.不遵循开发规范，开发文档不完善，软件难以维护；
4.缺少严密有效的软件质量检测手段，交付给用户的软件质量差。

7.软件危机的后果

1.软件质量不高，很难稳定；
2.软件项目延期，进度没法控制；
3.成本增长，没法控制预算。

8.软件危机的根源

1.根据摩尔定律，硬件发展很快，相应对软件系统的指望愈来愈高；
2.软件系统复杂性提升，需多人合做；
3.软件开发是人的智力活动，没法用已有的产业工程方法来组织管理。

9.为何会出现软件缺陷

致使软件缺陷最大的缘由是需求说明书；
软件缺陷的第二大来源是设计方案；
编写代码；
其余。

10.常见引入缺陷的缘由

1.开发过程缺少有效的沟通，或者没有进行沟通；（表达不正确、以至理解不正确、以至设计不正确）
2.软件复杂度愈来愈高；
3.编程中产生错误；（语法错误、语义错误等）
4.需求不断变动；（项目失败的最大杀手，会引发从新设计，工程从新安排等）
5.项目进度的压力；（为了抢占市场，必须比竞争对手早一步把产品提供出来，因而不合理的进度安排就产生了，不断的加班加点最终致使大量错误的产生。另外一个方面，因为软件项目的时间安排是最难的，一般是须要不少猜想的工做，所以当最后期限来临的时候，错误也就伴随发生了）
6.不重视开发文档；（当团队中一员离开，对于新进来的员工说，去读懂和维护一个没有文档的代码是很难的）
7.软件开发工具自己隐藏的问题；（尽可能选择比较成熟的产品）
8.人员自大。
……

11.缺陷的类型

遗漏：规定的或预期的需求未体如今产品中（可能未将规格说明全面实现，也可能需求分析阶段就遗漏了需求）；
错误：未将规格说明正确实现（可能设计错误、也可能编码错误）；
额外的实现：规格说明并未规定的需求被归入产品，获得实现。

12.缺陷具体表现

软件未达到产品说明书标明的功能。
软件出现了产品说明书指明不会出现的错误。
软件功能超出产品说明书指明范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为很差。 

13.常见软件生产流程

（软件的生命周期，Software Lifecycle Model，9个阶段）：市场调研→→可行性研究→→产品立项→→需求调研→→设计开发→→系统测试→→产品发布→→产品维护→→产品升级。
问题定义→可行性研究→需求分析（功能建模、数据建模）→概要设计→详细设计→编码→测试→维护
1.计划（Planning）：（1）肯定软件开发总目标；（2）给出软件的功能、性能、可靠性以及接口等方面的设想；（3）研究完成该项目的可行性，探讨问题解决方案；（4）对可供开发使用的资源、成本、可取得的效益和开发进度作出估计；（5）制定完成开发任务的实施计划。
2.需求分析（Requirement Analysis）：对开发的软件进行详细的定义，由需求分析人员和用户共同讨论决定，哪些需求是能够知足的，而且给予确切的描述，写出软件需求说明书SRS。（针对产品的软件研发，需求来源于市场调研，特色是本身想研发什么，本身就来研发；针对项目的软件研发，需求来源于客户要求，特色是别人想研发什么，咱们帮着研发。项目型软件：特定客户针对某个特定软件产品指定供应商，软件知识产权归客户全部；产品型软件：特定软件针对某个特定群体开发的通用型软件产品，软件知识产权归软件开发商全部。）
3.设计（Design，概要设计与详细设计）：是软件工程的技术核心，这个阶段须要完成设计说明书。
概要设计（HLD）：在设计阶段把各项需求转换成相应的体系结构，每一部分是功能明确的模块；
详细设计（LLD）：对每一个模块要完成的工做进行具体的描述。
4.程序编码（Coding）：把软件设计转换成计算机能够接受的程序，即写成以某个程序设计语言表示的源程序清单。
5.测试（Testing）：检验软件是否符合客户需求，达到质量要求，通常由独立的小组执行，测试工做分为：单元测试（对每个函数进行测试）、集成测试（对函数与函数的集成，即函数间、模块与模块的集成，即模块间、子系统与子系统的集成，即系统间，进行测试）、系统测试（对每个功能需求、性能需求等进行测试）。
6.运行和维护（Run and Maintenance）：将软件交付用户投入正式使用，之后便进入维护阶段，可能有多种缘由须要对它进行修改，如软件错误、系统软件升级、加强软件功能、提升性能等。

14.软件研发三要素

人员、过程、工具；
只有适合的人员借助适合的工具通过适合的过程才能研发出高质量的软件；工具是为人员和过程服务，起辅助做用，起关键做用的是人员和过程。

15.常见项目组框架（软件项目组人员组成）

1.项目经理；
2.开发组：开发经理、分析人员、设计人员、开发人员；
3.测试组：测试经理、测试人员；
4.配置管理组：配置经理、配置管理员（CMO, configuration management officer）；
5.SQA（质量保证人员）。

16.软件研发流程类型

一、瀑布模型（Waterfall Model）：线性，串行，无风险控制能力，适合需求变化较小的状况。瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协做，即采用瀑布模型结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，而且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
计划阶段：项目计划书，Project Plan
需求阶段：需求规格说明书，SRS: Software Requirement Specification
设计阶段：概要设计：High Level Design，详细设计：Low Level Design
开发阶段：代码，用例
测试阶段：测试实现和执行
维护阶段：产品维护
优势：简单高效（通常产品要求当即上线，应第一时间保证运行，其它的有时间再作）
缺点：测试介入较晚，人员闲置严重，后续工做跟不上；在项目各个阶段之间极少有反馈；只有在项目生命周期的后期才能看到结果；经过过多的强制完成日期和里程碑来跟踪各个项目阶段；瀑布模型的突出缺点是不适应用户需求的变化。
适用范围：项目开发完成后才招测试人员，那么多是瀑布模型，不适合需求频繁变动的项目。不适合于大的项目，适用于小规模传统项目业务研发。适合范围：项目小，需求明确。
按照瀑布模型的阶段划分，软件测试能够分为单元测试，集成测试，系统测试。

风险驱动的模型，迭代模型（Iteration），可在迭代模型中应用瀑布模型。每次迭代产生一个可运行的版本,同时增长更多的功能。每次迭代必须通过质量和集成测试。
增量：软件开发过程当中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品。
迭代：指增量开发过程当中，各模块的开发是反复进行的，并非完成了某个模块后就终止该模块的开发转而开发下一个模块，可能还要对以前开发的模块不断完善，增长新功能。
二、螺旋模型：基于风险管理的模型，高风险的优先考虑，对风险管理人员的要求较高。综合了基本的瀑布式模型和演化/渐增原型方法。与瀑布模型不一样点：螺旋模型有替代方案，是多个瀑布模型的并行集合。充分考虑了风险问题，故设计了替代方案。
优势：充分考虑风险，抗风险能力强；
缺点：成本过高，须要专业的风险分析专家参与；
适用范围：与生命财产相关的系统。
三、RUP（Rational Unified Process）：统一软件开发过程，是一个面向对象且基于网络的程序开发方法论。全部的工做流在各个阶段都有体现。面向对象的，通用的。特色：基于风险；用例集驱动；以架构为中心；迭代和增量。因此工做流在各个阶段都有体现。
优势：针对大型复杂的系统，进行逐步完善，下降了实施复杂度；用户可在早期提出变动并进行修复，从而有效控制变动风险及代价（每每都是局部变动）；可在早期加强用户的信心（看到了半成品）。
缺点：要有专业的架构师（架构师的职责），当功能与功能之间联系太过紧密的话，不太使用rup模型，好比登陆与注册的联系；已经肯定了的功能将不容许变动，但因为由于设计引发的内在联系引发的变动是没法控制的。
适用范围：大型复杂的项目研发，耦合度较低的系统。
四、IPD（integrated product development）：集成产品开发，IPD的思想来源于美国PRTM公司出版的《产品及生命周期优化法》（简称PACE——Product And Cycle-time Excellence）一书，该书中详细描述了这种新的产品开发模式所包含的各个方面。产品结构重整（资源重整）；公共模块共用。
从整个产品角度出发，不只仅针对研发。
优势：将软硬件研发及生产、销售等各个部门有效整合，集中在一个平台下统一管理，提升了决策的准确性及时效性；利于各部门关键数据的共享；
缺点：管理成本高；部门之间的协调关系较复杂；
适用范围：大型软硬件集成厂商。
五、敏捷开发：Scrum是一种迭代式增量软件开发过程，一般用于敏捷软件开发。
计划开发必定功能，并把一个个功能挨个快速地实现，省略文档写做（包括概要设计等），在这个基础上有可能增长功能。

17.软件研发中几个重要的过程

需求管理、配置管理、缺陷管理、同行评审。

18.其它

1.测试不是点点鼠标，敲敲键盘，而是要结合业务逻辑和用户需求，并使用各类技术。
2.一个好的软件测试人员，必定是懂开发知识的；一个好的软件开发人员，必定是懂测试的。
软件测试主要是为了发现如下几类错误：
①是否有不正确或遗漏了的功能？
②在接口上，输入可否正确地接受？可否输出正确的结果？
③是否有数据结构错误或外部信息（例如数据文件）访问错误？
④性能上是否可以知足要求？
⑤是否有初始化或终止性错误？

 

部分整理自网络，若有侵权，请联系删除。