测试基础

一、测试基础

（一）软件：一系列按照特定顺序组织的计算机数据和指令的集合     （包括程序+数据（数据库保存）+文件（需求文档、设计文档、安装文档...））

（二）产品：能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品、无形的服务、组织、观念或它们的组合。

（三）项目：指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。

二、软件测试定义

使用人工和自动手段来运行或测试某个系统的过程，其目的是检验它是否满足规定的需求或是弄清预期结果和实际结果之间的差别。

三、软件生命周期

（一）软件需求调研

（二）需求分析（需求规格说明书）

（三）设计（从计算机角度实现满足这个需求的软件的开发，采用什么语言，什么框架，什么数据库、模型）

包括概设和详设

（四）开发编码

（五）测试

（六）发布上线

（七）运维

（八）下线

四、测试的基本原则

（一）测试是上下文相关的（基于软件所处的行业，所处的背景，医药、公司内部使用、淘宝...对于同一个测试点，测试强度是不同的）

（二）穷尽测试是不可能的

（三）测试尽早介入（了解需求，在前期发现错误需求也许会出现错误）

（四）杀虫剂悖论（需要变换不同的测试用例执行不同的版本才能发现新的bug）

（五）缺陷群集性（80%的缺陷有可能都在20% 的模块，当发现这个功能模块出现问题，有可能还有其他问题出现，需要注意）

（六）测试证明存在缺陷

（七）无谬错论（软件永远都有缺陷，有些问题没发现只是隐藏在软件内部，没有机会暴露出来）

五、软件开发模型

（一）瀑布型

（一）原型

原型设计出来原型图就是提前生成具体的操作流程，已经把后面实现的样子弄出来了，可以跟客户确认了。一旦开发出来，之前的原型图也就没有意义了。好处就是提前跟客户确认需求。对每个环节的输出文档的质量详情程度就没有那么高，所有精力都放在原型设计上。文档详尽程度没有瀑布模型高。

当产生人员变动时，之前的文档不太详尽，会对这个软件的了解有困难。

（一）敏捷模型

一种以人为核心、迭代、循序渐进的开发方法。

一、测试模型

（一）V模型

单元测试检查代码本身，基本是程序员自己测试的，根据详设。

集成测试依据概设，每个模块相互关联。更多关注功能测试。

系统测试依据需求规格说明书，还包含非功能性测试，比如性能，UI。

验收测试通常是客户方来验收，更多是依据用户需求。

系统和验收测试有可能都是根据需求规格说明书。

 

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

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

（一）W模型

虚线表示测试工作            左边虚线检查文档的正确性，W比V多了左边三个工作，尽早地介入了测试

优点：

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

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

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

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

一、软件测试阶段

（一）需求测试

返工：70%--85%由于需求

重点：检查需求规格说明书  SRS

1．完整性

2．正确性

3．一致性

4．可行性

5．无二义性

6．健壮性

7．必要性

8．可测试性

9．可修改性

（二）单元、集成、确认、系统、验收测试

1．单元测试

基本组成单元：函数、类

目的是检测软件模块对《详细设计说明书》LLD的符合程度。

2．集成测试

对单元之间及单元与第三方接口（支付宝从银行扣款）之间的测试

目的是检测软件模块对《概要设计说明书》的符合程度（比如测支付宝扣钱是从余额、银行卡还是余额宝）

集成策略：自底向上或自顶向上，渐增式（先测最底层代码，再慢慢加上调用底层的上一级开发），涉及驱动代码的开发（如果上一级程序没开发好，所以需要写驱动开发来运行底层代码）（自顶向下要用到桩模块指的是下一层代码没开发好，要运行上一级代码，要写桩模块来运行上一级代码）

3．系统测试

系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与其他硬件、外设、某些支持软件（相互兼容性）、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的测试工作。

通过与《需求规格说明书》作比较，发现软件与系统需求矛盾的地方。

4．确认测试

验证软件的有效性

5．验收测试

交付用户部署前，进行验收测试。让用户来组织。

以用户为主，验收组：项目组成员、用户代表或者系统的其他利益相关者。

根据合同、《需求规格说明书》或《验收测试计划》对成品进行验收测试。

6．Alpha测试和Beta测试

Alpha:内部（游戏开发商内部测试人员），模拟/真实

Beta:外部（实际使用的用户），真实

7．UAT测试：用户接受度测试 user acceptance test

验证系统的可用性

8．回归测试

验证修改后的缺陷得到了正确的修复，同时对系统的变更没有影响以前的功能。

 

转载于:https://www.cnblogs.com/jasmine1112/p/8654984.html