测试重点.docx

测试重点.docx

《测试重点.docx》由会员分享，可在线阅读，更多相关《测试重点.docx（8页珍藏版）》请在冰豆网上搜索。

测试重点

☐测试显示缺陷的存在

●测试可以显示缺陷的存在，但不能证明系统不存在缺陷

●零缺陷的系统是不存在的

☐原则2.穷尽测试是不可能的

●每个测试都只是抽样测试

●根据测试的风险和优先级，控制测试工作量，在测试成本、收益和风险之间求得平衡

☐原则3.测试的尽早介入

●根据统计表明，在软件开发生命周期早期引入的错误占软件过程中出现所有错误（包括最终的缺陷）数量的50%～60%

●IBM的一份研究结果表明，缺陷存在放大趋势。

如需求阶段的一个错误可能会导致N个设计错误

☐原则4.缺陷的集群性

●80%的错误集中在20%的程序模块中

●对发现错误较多的程序段或者软件模块，应进行反复的深入的测试

☐原则5.杀虫剂悖论

●同样的测试用例被一遍一遍反复使用时，发现缺陷的能力就会越来越差

●测试用例需要经常的评审、修改和增加

☐原则6.测试活动依赖于测试内容

●对于每个软件系统，比如测试技术、测试工具、测试阶段以及测试出口准则等等的选择，都是不一样的

☐原则7.没有失效不代表系统是可用的

●在开发过程中用户的早期介入和接触原型系统就是为了避免这类问题的预防性措施（不满足客户需求）

☐原则8.测试的标准是用户的需求

●测试人员应该在不同的测试阶段站在不同用户的角度去看问题

●系统中最严重的问题是那些无法满足用户需求的错误

☐原则9.尽早定义产品的质量标准

●只有建立了质量标准，才能根据测试的结果，对产品的质量进行分析和评估

●测试用例也应该确定期望输出结果

☐原则10.测试贯穿于整个生命周期

●必须在开发过程的每个阶段都保证其过程产品的质量

●不应当把软件测试仅仅看作是软件开发完成后的一个独立阶段的工作

☐原则11.第三方或独立的测试团队

●一定程度的独立测试（可以避免开发人员对自己代码的偏爱），可以更加高效的发现软件缺陷和软件存在的失效

●但独立测试不是完全的替代物，因为开发人员也可以高效的在他们的代码中找出很多缺陷

单元测试–关注点

☐模块接口

☐局部数据

☐独立路径

☐出错处理

☐边界条件

☐压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。

☐压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

☐压力测试可以被看作是负载测试的一种，即高负载下的负载测试。

●负载测试关心的是用户规则和需求

●压力测试关心的是软件系统本身

☐易用性是指软件产品被理解、学习、使用和吸引用户的能力

☐易用性测试不仅针对应用程序，而且还包含用户手册等系列文档的测试。

☐应用程序的易用性测试包含：

●安装测试

●功能性易用性测试

●界面测试

●辅助系统测试

☐软件测试主要的输出文档

●测试计划

●测试用例

●缺陷

●测试报告

黑盒测试又称功能测试、数据驱动测试或基于规范的测试

黑盒主要是为了关注以下几个方面：

●检测软件功能能否按照需求规格说明书的规定正常工作，是否有功能遗漏

●在接口上，输入能否正确地接受？

能否输出正确的结果？

●是否有数据结构错误或外部信息访问错误？

●性能上是否能够满足要求？

●是否有初始化或终止性错误？

场景分析法：

通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。

场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。

下面是场景法的基本设计步骤 

1. 根据说明，描述出程序的基本流及各项备选流     

2. 根据基本流和各项备选流生成不同的场景     

3. 对每一个场景生成相应的测试用例 

4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值

等价类划分的办法是把程序的输入域划分成若干等价类，然后从每个部分中选取少数代表性数据当作测试用例。

等价类是指输入域的某个互不相交的子集合。

所有等价类的总和便是整个输入域。

划分等价类

有效等价类

有效等价类指的是对程序的规范是有意义的、合理的输入数据所构成的集合

在具体问题中，有效等价类可以是一个，也可以是多个

无效等价类

无效等价类指对程序的规范是不合理的或无意义的输入数据所构成的集合

对于具体的问题，无效等价类至少应有一个，也可能有多个

常用的等价类划分原则

按区间划分

按数值划分

按数值集合划分

按限制条件或规则划分

细分等价类

语句覆盖

☐主要特点：

语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。

☐优点：

可以很直观地从源代码得到测试用例，无须细分每条判定表达式。

缺点：

由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的

判定覆盖

主要特点：

判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：

程序中的每个分支至少执行一次。

每个判断的取真、取假至少执行一次。

优点：

判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。

同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。

缺点：

往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。

条件覆盖

主要特点：

条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。

优点：

条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径。

缺点：

要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。

条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

并发用户数

☐并发用户数是指在某一给定时间内，某个特定点上进行会话操作的用户数。

☐“并发用户数”、“系统用户数”和“同时在线用户数”的区别

☐

（1）计算平均的并发用户数：

C=nL/T

☐

（2）并发用户数峰值：

C’≈C+3根号C

☐公式

（1）中，C是平均的并发用户数；n是loginsession的用户数量；L是loginsession的平均时间长度；T指考察的时间段长度。

☐公式

（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式

（1）中得到的平均的并发用户数。

该公式的得出是假设用户的loginsession产生符合泊松分布而估算得到的。

性能测试过程

☐测试需求分析

☐制定测试策略

☐制定测试方案

☐执行测试方案

☐测试结果分析

☐编写测试报告

测试需求分析

测试需求分析主要有以下的几个关键点：

Ø

Ø测试的目的是什么

性能符合性验证：

验证是否满足应用的需要。

性能能力验证：

确定性能极限、是否存在性能瓶颈。

性能调优：

对系统的性能进行调试、优化。

Ø

Ø测试要素分析：

用户数量

测试执行的功能

用户分布（即执行每种功能的用户数）

硬件环境（包括网络环境）

软件环境

数据量

Ø其它分析

系统运行中所出现的问题有什么特征或规律

疲劳测试执行时间多少

性能需求的指标是什么等

制定测试方案

☐测试需求

☐测试策略

☐测试场景

☐测试环境

☐测试准备

☐人员及时间安排

☐问题与对策

测试结果分析

☐性能符合性验证：

查看测试结果是否满足要求，比如响应时间、资源利用率、吞吐量等等。

☐性能能力验证：

查看测试结果是否满足要求，记录软件系统的性能变化曲线。

对于确定是否存在性能瓶颈，首先判断是否存在硬件（包括网络）瓶颈问题，若不存在硬件瓶颈问题，则按照应用软件到系统软件（应用服务器、数据库服务器、操作系统）的顺序进行分析，确定瓶颈点。

性能调优：

同性能能力验证确定性能瓶颈分析方法

硬件瓶颈分析方法

内存分析方法

处理器分析方法

磁盘I/O分析方法

网络分析方法