软件测试总结.docx

软件测试总结.docx

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

软件测试总结

一、软件测试流程

Ø整体流程：

测试需求分析，测试计划编写，测试用例编写，测试执行，缺陷记录，回归测试，判断测试结束，测试报告提交。

Ø测试流程依次如下：

1.需求：

阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。

--testingteam。

一般而言，需求分析包括软件功能需求分析、测试环境需求分析等

2.测试计划:

根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。

---testingleaderortestingmanager。

测试目的、测试环境、测试方法、测试用例、测试工具

3.用例设计：

根据测试计划、任务分配、功能点划分，设计合理的测试用例。

---testingleader,seniortester

4.执行测试：

根据测试用例的详细步骤，执行测试用例。

--everytester（主要是初级测试人员）

5.执行结果记录和bug记录：

对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。

--everytester（主要是初级测试人员）

6.defecttracking（缺陷跟踪）：

追踪leader分配给你追踪的bug.直到bugfixed。

--everytester

7.测试报告：

通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.

8.用户体验、软件发布等……

Ø总结：

项目立项后，开始写测试计划，根据需求编写测试需求，根据测试需求编写测试用例，根据测试用例执行测试，把没用通过的测试用例写成测试缺陷报告，进行回归测试，直到测试的结束编写测试总结，这每个步骤都需要审核通过。

二、软件测试方法

1、黑盒测试

Ø概念：

完全不考虑程序或软件的内部逻辑结构和处理过程的情况下，根据需求分析编写并执行测试用例，在程序或软件的界面上进行测试。

Ø主要目的：

（1）是否有不正确的或者遗漏的功能。

（2）能都正确输入和输出结果。

（3）是否有数据结构错误或外部信息访问错误。

（4）性能上是否满足要求。

（5）是否有初始化或终止行错误。

Ø优点：

（1）即使程序发生变化，之前的测试用例依然可以使用；

（2）测试用例和软件开发可以同时进行，加快了测试和开发的速度。

Ø局限性：

（1）难以查找问题的原因和位置；

（2）黑盒测试的依据是需求分析，所以无法发现需求分析上的错误。

Ø测试方法：

（1）等价类划分

包括有效等价类（符合需求规格说明）和无效等价类（违反需求规格说明）。

a）确定输入取值范围：

可以确定一个有效等价类和两个无效等价类

b）确定输入某个值：

可以确定一个有效等价类和两个无效等价类

c）布尔量的情况：

可以确定一个有效等价类和一个无效等价类

d）输入数据由N个值构成：

可以确定N个有效等价类和一个无效等价类

e）必须遵守规则：

可以确定一个有效等价类和若干个无效等价类（从不同角度违反规则）

（2）边界值分析法

等于、刚好大于、刚好小于、

（3）因果图分析法

着重考虑条件组合（约束条件）

（4）错误推断法

（5）判定表驱动分析法

（6）正交试验法

2、UI测试

Ø概念：

userinterfacetesting用户界面测试。

指测试用户界面的风格是否满足用户需求，文字是否正确，页面是否美观，文字和图片的组合是否完美，操作是否友好等等。

Ø目的：

确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能；确保用户界面符合公司或行业标准。

Ø包括：

友好性、人性化、易用性等。

Ø例如：

功能按钮的大小、风格、是否对齐等，报错信息的提示。

3、冒烟测试

Ø冒烟测试的对象是新编译的每一个需要正式测试的软件版本。

主要目的确认软件功能基本正常。

4、随机测试

Ø主要是根据经验，对软件的功能和性能进行抽查。

三、软件开发的主要阶段

需求分析（确定功能需求，性能需求以及运行环境；此阶段对需求的理解不完整、不正确都会为缺陷的产生留下祸根）软件设计、软件编码、软件测试、软件运行和维护

四、软件测试的目标

尽可能多、尽早的发现有效bug、严重bug并且修改bug，以使软件满足用户的业务需求

五、软件测试的原则

（1）尽早、全面、全过程、独立开展测试活动；

（2）建立在满足用户需求的基础上；

（3）程序员避免自己检查自己的代码；

（4）测试用例要输入合法值与违法规则的值、边界值等，本着破坏的目的；

（5）充分重视回归测试

六、测试工作流程图

1、单元测试

单元测试（一般由开发人员来完成）步骤：

（1）计划单元测试：

确定单元测试内容，初步制定测试策略，确定测试所用的资源，安排测试进度。

（2）设计单元测试：

创建单元测试环境，制定测试方案，细化测试过程。

（3）实现单元测试：

编写测试用例及测试脚本。

（4）执行单元测试：

对被测单元执行测试用例和测试脚本，记录被测单元执行过程和发现的bug，定位和排除错误。

（5）单元测试结果分析并提交测试报告：

对单元测试的结果进行分析，归类，确定单元测试是否完备，并编制和提交单元测试报告。

单元测试工具：

cppunit

2、集成测试

采用的方法有：

自顶向下、自底向上、两头逼近混合方式

（1）自顶向下：

从顶层模块开始，沿被测程序结构图逐级向下测试。

（2）自底向上：

找到一个没有下级的模块，由下向上的逐步添加新模块，组成程序中的一个子系统或模块

（3）两头逼近混合方式：

对上层模块采取自顶向下测试，对关键模块或子系统采取由底向上测试

3、确认测试

判断目标软件是否满足用户的功能和性能需求，文档资料是否完整、准确

（1）黑盒测试

功能测试：

针对要求的程序功能，按照规范的流程进行测试；

性能测试：

针对要求的程序功能以外的，包括性能、安全、配置、负载等指标，按照规范的流程进行测试；

攻击测试：

针对要求的程序功能、性能、安全、配置、负载等指标，基于破坏目的，按照经验随机进行测试

（2）验收测试

进行验收测试，来保证软件满足用户的需求。

由用户完成，可以进行一周或几个月的时间，因而可以随着时间的积累发现更多的缺陷。

（3）Alpha与Beta测试

Alpha测试是在一个受控的环境下进行，由开发者“指导”用户进行测试，缺陷由开发者记录；Beta测试是由用户在自己的工作场所进行测试，并定期把缺陷提报给开发者，开发者在收到缺陷记录后，对程序进行修改，再对产品进行更新以及最终版本的发布。

4、系统测试

对系统进行更大范围的测试。

除被测程序外，系统还可能包括硬件和其他软件。

把确认测试合格的软件部署到系统之后，能正常运行，并检查是否能与其他软件协调运行，完成SRS（软件需求规格说明书）对软件的要求。

七、健壮性测试

又称为容错性测试。

用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。

测试内容：

1、对关键进程或线程杀死，观察系统行为

2、对关键进程或线程挂起，观察系统行为

3、网络有故障，观察系统行为

4、数据库有故障，观察系统行为

八、兼容性测试

也可以说是软件的可移植性，检查软件在不同的硬件平台，软件平台是否能正常运行。

细分，包括：

平台兼容，网络兼容，数据库兼容，数据库格式兼容。

兼容测试多在cleanos的环境下进行测试（配置测试不是在cleanos环境下测试）

十、测试用到的工具

（一）bug管理工具

1、bugfree（F:

\bugfree）

《操作手册》页面链接见下：

2、Bugzilla

用户组（管理用户信息，登录账号、密码等）

产品管理（管理产品信息，模块、开发者等）

权限组（管理用户访问权限、对bug的操作权限等）

Bug记录（新增、修改、删除bug，显示bug周期、指派负责人等）

3、禅道管理工具

（二）性能测试工具（压力测试）

1、LoadRunner

通过模拟真实的用户行为，通过负载、并发和负载实时监控以及完成后的测试报告，分析系统可能存在的瓶颈。

最为有效的手段是并发控制，通过控制台设置，达到同一业务同时模拟成千上万的用户同时操作。

2、Jmeter（压力测试）

E:

\TOOLS\JMeter\apache-jmeter-3.1\bin运行该目录下的jmeter.bat

（三）自动测试工具

1、QTP

（1）常用检查点：

A）标准检查点：

检查对象属性，例如检查按钮是否可用，复选框是否被选中等。

B）位图检查点：

检查位图格式的程序或者网页的某个区域。

把程序或网页的某一个区域捕获为位图的格式进行检查

C）文本检查点：

检查网页或窗口中的文字是否正确

D）文本区域检查点：

检查网页或窗口中的文字是否正确，与文本检查点不同的是文本区域检查点检查的是指定的文字是否在指定的区域正确显示

E）表检查点：

检查表格内多个单元格的内容是否正确

F）数据库检查点：

检查数据插入数据库是否成功

G）页面检查点：

检查页面的特性，例如一个页面的响应时间，页面中是否有中断的链接

H）XML检查点：

检查XML文件是否正确

I）图像检查点：

检查应用程序或网页中的图像的值，是否与预期的值一致。

例如检查图像的源文件的名称是否正确。

（四）软件测试管理工具

1、TestDirector

（1）测试管理过程

A）需求管理

●定义需求范围

●定义需求树

●描述功能点

B）测试计划

●测试目标和测试策略

●分析应用程序，建立测试计划树

●确定每个功能点的测试方法

●将每个功能点连接到需求上，使测试计划覆盖全部的测试需求

●描述手工测试的步骤

●指明需要自动化测试功能点

C）测试执行

●执行测试用例

D）缺陷跟踪

●记录缺陷

●确定需要修改的缺陷

●相关人员修改缺陷

●回归测试

2、QC（qualitycenter）

架构（站点管理、项目自定义管理、项目测试管理）

✧站点管理

（1）项目管理

a）域和项目的管理

b）域，可以包含多个项目（例如：

文件夹和文件的关系）

c）创建域、删除域；创建项目、删除项目、停止、激活项目

（2）用户管理

a）创建用户

b）用户密码设置

c）删除用户

d）把用户添加到项目

（3）站点链接管理

可以看到哪些用户登录了系统，可以断开用户登录，可以对用户进行分组管理

（4）序列号管理

管理购买的序列号，可以整个序列号购买，可以单个模块的序列号购买

（5）服务器管理（不作为重点，略）

（6）其他辅助管理（不作为重点，略）

✧项目自定义管理

每个项目都有对应的项目自定义管理，可以根据需求，为项目做个性化设置

（1）用户属性管理

用户名不可修改，当前登录用户的信息和密码可修改。

（2）项目用户管理

为项目添加用户，并为用户分配相应的权限

（3）权限组管理

设置查看权限组的权限，也可以为用户分配相应的权限

（4）模块访问权限管理

设置每个权限组是否可以访问测试管理中的某个子模块

（5）实体管理

可以设置对应的模块界面中填写项的属性（例如：

某个字段设置为必填项、界面汉化等）

（6）需求类型管理

添加需求功能、安装需求、兼容性需求、性能需求等

（7）风险管理

可以设定风险模型，并对需求中的功能模块使用设置的风险模型进行分析，从而判定每个功能模块存在的风险

（8）项目列表管理

为测试管理中某些下拉列表填写项提供备选值

（9）邮件管理

在某些特定条件下，自动向某些人发送邮件（例如：

当缺陷状态改变时，向相关的测试测试人员或者开发人员发送邮件。

）需要提前设定好邮件服务器

（10）通知规则管理

设定当某个指令想发生变化时，自动标识相关条目或向相关人员发送邮件。

十一、面试题

1、某个软件，在windows上运行很慢，通过哪些指标判断是软件的问题还是windows系统的问题

回答：

从软件方面看：

1、软件与数据库连接是否存在问题，是否存在内存溢出等现象，2、在windows系统没有其他软件负载的情况下，查看cpu监测器，确认软件是否对cpu/内存访问情况存在异常；

从windows系统方面看：

1、系统是否有病毒，2、检查软件/硬件的配置是否符合推荐标准

2、LoadRunner测试流程

a）创建模拟用户

b）运行测试场景

c）运行测试脚本

d）监视测试场景

e）分析测试结果

3、LoadRunner中的并发操作是什么？

通过控制台的设置，模拟成千上万的用户，在同一时间对同一业务进行操作。

4、软件测试5C标准

Correct（准确）：

描述准确

Clear（清晰）：

描述清晰

Consise（简洁）：

只包含必不可少的信息

Complete（完整）：

包含重现bug的完整步骤和本质信息

Consistent（一致）：

一致的格式书写缺陷报告等相关文档

5、工作版本的定义：

构造号：

build

6、桩模块：

被测模块调用模块

驱动模块：

调用被测模块

扇入：

被调次数

扇出：

调用其他模块的数目

7、做好软件测试的关键是什么

明确测试需求、测试范围、测试目的，测试环境、测试方法等方面；并且通过对时间、资源、测试范围和预算等方面的综合分析，保证有效的实施软件测试

坚持5w原则：

what做什么，why为什么做，when何时做，where，在哪里做，how如何做

8、做好软件测试用例的关键是对需求和设计文档的理解和熟悉程度

9、缺陷的生命周期：

提交——确认——分配——修复——验证——关闭

10、软件安全性的测试从哪几方面考虑

（1）用户认证机制：

数字证书、双重认证、安全电子交易

（2）加密机制

（3）安全防护策略：

安全日志、漏洞扫描等

（4）数据备份和恢复手段：

存储设备、存储优化、存储保护、存储管理

（5）防病毒

11、软件测试通过标准

是否覆盖所有的用户的所有需求，软件是否存在关键有效的bug

12、集成测试的主要内容

（1）将各个模块组合之后，在功能之间数据调用时，数据传递是否准确

（2）一个模块的功能是否会对另一个模块的功能产生不利的影响

（3）各个子功能组合，是否能达到父功能的要求

（4）单个模块的的误差累积起来，是否会放大，导致无法接受的程度。

13、集成测试和系统测试的关系：

（1）集成测试是根据软件概要设计说明书执行，是对各个模块组合之后进行测试

（2）系统测试是根据软件需求设计说明书执行，是对整个软件进行测试，包括其他软件的兼容、硬件的兼容等

14、用户文档的测试要点

（1）读者群：

文档面向的读者群要明确

（2）术语：

文档中用到的术语与读者群的定位、用法一致，符合业界标准

（3）正确性：

检查文档中所有信息是否完整准确。

是否存在不真实或夸大其词的错误。

（4）完整性：

是否有遗漏的模块

（5）一致性：

按照文档描述的步骤进行操作后，达到的效果或目的是否与文档描述一致

（6）易用性：

对关键步骤有特殊的标识，对错误的结果给予解释并提出处理办法。

（7）系统截图：

是否有正确的界面截图

15、如何理解强度测试、压力测试、负载测试、性能测试

（1）强度测试：

在非标准环境下，甚至人为降低系统工作环境所需要的资源，如网络等，测试系统在资源不足的工作环境下，确定本系统的最差的工作环境

（2）压力测试：

在标准环境下，不断增加系统负荷，对服务器稳定性及负载方面的测试，增加用户访问量或几个用户进行大量数据的操作。

（3）负载测试：

是压力相对较大的测试，主要测试系统在一种或极限条件下的响应能力。

100个用户同时操作系统半个小时可以看做是压力测试，连续操作8个小时，就可以看做是负载测试。

（4）性能测试：

性能测试是一个较大范围的测试，本身包含了性能、压力、负载、强度等多方面的测试内容。

16、测试系统瓶颈的目标：

（1）发现“表面”的系统瓶颈，通过模拟用户操作，发现用户在极限使用系统的情况下的瓶颈，然后解决瓶颈，这是性能测试的基本目标。

（2）发现潜在瓶颈并解决，保证系统的长期稳定。

主要考虑用户在将来扩展需求或者业务发生变化时，系统能够适应。

17、所有的缺陷都能修复吗？

所有的缺陷都需要修复吗？

从技术角度讲，所有的缺陷都能修复，但是没必要修复所有的缺陷。

测试人员要能够正确判断什么时候不能追求软件的完美。

对于整个项目团队，要做的是对每一个缺陷进行取舍，根据风险决定哪些缺陷需要修复。

发生这种现象的主要原因如下：

1、没有足够的时间资源。

在任何一个项目中，通常情况下开发人员和测试人员都是不够用的，而且没有足够的回归测试的时间，再加上修复缺陷的同时还可能引入新的缺陷。

2、有些缺陷只在特殊情况下出现，考虑商业利益，可以在后续升级中修复。

3、缺陷是否修复有软件测试人员、项目经理、程序员共同讨论决定是否修复，不同角色的人员从不同的角度考虑，以做出正确的决定。

18、和用户共同测试（UAT测试）的注意点有哪些？

1、和用户共同测试更趋于一种演示，演示的话，时间有限，不可能完全演示所有的功能点。

那就要演示核心的功能点或者用户最关心的功能。

要提前做好准备，保证演示的功能不会有明显bug，让用户对软件有信息，有期待。

2、如果模块bug太多，就要选择其他的模块进行演示。

必要时向用户做出合适解释，并在后期修复bug

19、bug报告流转步骤

1、我之前的公司使用bugfree管理bug，在维护一个项目信息的时候，就制定了每个模块的负责人，测试人员在提交bug后，选择功能模块，就会自动带出负责人，并且自动指派给相关负责人。

开发者修复bug之后，会在bugfree上把bug状态改为已修复，并自动指派给bug提交人员。

由bug提交人员验证并关闭或者再次激活bug。

2、正常的bug周期应该是：

提交——确认——分配——修复——验证——关闭

20、bug报告中必备的几项内容

bug版本、bug优先级、bug状态、bug编号、严重程度、提交人、处理人、从属关系、详细描述、提交日期、附件

21、以前工作的测试流程是什么

首先有了需求文档，会在一起开会讨论分析需求文档，然后编写测试计划，把测试的时间、环境、方法、工具等方面的内容考虑进去，写测试用例，我写功能性的测试用例最多，而且一直都很享受测试用例这个过程，有了测试环境和测试版本之后开始执行测试用例，并且不断完善测试用例，然后提出bug，回归测试，判断测试结束，形成测试报告。

22、当开发者说不是bug时，要怎么做

判断是不是bug要有依据，依据就是需求文档，需求不明确的情况下，可以找上级确认需求或者决定是否需要修复bug；需求明确的情况下，要告诉开发者在用户体验当中，可能会出现的用户场景，以及可能会造成的不良影响。

当然也要看bug的严重程度，如果考虑商业利益的话，不影响正常操作的情况下，可以在后续的升级中去修复。

十二、搭建测试环境

1、安装jdk（查看默认使用jdk版本：

在命令提示符中输入：

javac-version）

2、安装Tomcat

3、配置环境变量

JAVA_HOME:

jdk的安装路径

Classpath：

.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar;

Path：

.;%JAVA_HOME%\bin;在加上jdk安装路径下的bin文件

4、检测tomcat是否安装成功：

在ie地址栏中输入：

http:

//www.localhost:

8080，显示猫的界面出来就是安装成功了。

5、测试环境搭建完成后，从开发人员处得到工程包，放置到tomcat目录下的webapp文件夹中

6、启动tomcat

7、修改tomcat安装目录下，conf文件夹下context.xml文件和server.xml文件。

✧在context 元素下添加   

✧在conf/server.xml中设置字符格式

      connectionTimeout="20000" 

      redirectPort="8443" 

URIEncoding="UTF-8"/>

8、在IE浏览器中输入：

http:

//localhost:

8080/hcig（工程名称）

十三、测试文档

1、测试计划

测试目的、测试环境、测试方法，比如说白盒测试，语句覆盖，条件覆盖，条件组合等等这些方法，黑盒测试，等价类划分法，边界值，因果分析法等等，可以包含测试用例。

测试使用到的工具等等测试过程相关的一些安排

2、测试用例

（一）修改页面——工作名文本框

1、是否显示正确的数据，可修改项是否可以修改

2、输入合法的数据能否提交

3、输入￥%%……*&*（）或者特殊字符组合能否提交，如不能提交是否有正确的提示

4、输入超过合法长度的字符能否提交，如不能提交是否有正确的提示

5、空，是否可以提交，如不能提交是否有正确的提示

（二）修改页面——下拉列表

1、是否显示正确的数据，可修改项是否可以修改

2、下拉列表的按钮是否可以点击并且弹出正确的数据列表

3、选择下拉列表中的数据，是否可以提交

4、是否可以手动输入合法的数据，能否提交，如不能提交是否有正确的提示

5、是否可以手动输入不合法的数据，能否提交，如不能提交是否有正确的提示

6、是否可以为空

（三）修改页面——取消按钮

1、取消按钮是否可用

2、单击取消按钮是清空页面数据还是页面跳转，将会跳转到哪个页面

3、连续点击取消按钮会如何

（四）界面UI测试用例

1、查看页面是否有错别字

2、查看页面的文字布局是否合理、图片布局是否合理、文字和图片组合布局是否合理

3、页面风格是否与系统整体一致

4、必填项是否有标识

（五）页面——删除按钮

1、未选中数据时，单击删除按钮是否会删除数据，如不能删除数据是否有合理提示

2、选中单行数据时，单击删除按钮是否能删除数据，是否有删除成功的提示

3、选中单行数据时，连续点击删除按钮会有什么结果

4、选中多行数据时，单击删除按钮会有什么结果

5、选中“审批中”、“审批通过”状态的数据时，单击删除按钮是否能删除数据，如不能是否有合理提示

6、选中“起草”、“驳回”状态的数据时，单击删除按钮是否能删除数据，是否有合理提示

7、删除数据成功后，返回哪个页面

（六）页面分页控件

1、列表在首页位置时，首页和上一页按钮是否可用

2、列表在尾页位置时，下一页和尾页按钮是否可用

3、单击首页、上一页、下一页、尾页按钮，跳转的页面是否正确

4、列表显示总条数和页数是否正确

5、每页显示条数下拉列表是否正确

6、跳转按钮是否正确

7、对页面数据进行操作（增删改）后，条数和页数是否显示正确

（七）导航栏

1、名称是否正确

2、页面是否跳转正确

（八）审核页面——添加、修改、删除按钮

1、按钮是否可用（预期结果是不可用）

（九）登录页面（用户名、密码、验证码、登录按钮、重置按钮）

1、输入正确的用户名、密码、验证码，单击登录按钮

2、分别输入超长的用户名、超长的密码、超长的验证码，是否能登录成功，如不能成功，会有何提示

3、输入含有特殊字符以及空格的用户名、正确的密码和验证码。

单击登录按钮，能否登录成功，如不成功会有何提示

4、用户名、密码、验证码分别为空时，单击登录按钮有何提示

5、单击重置按钮，是什么结果

6、是否有登录次数的限制

7、点击验证码或验证码的刷新按钮，验证码是否会刷新