软件测试理论基础包括性能测试自动化测试等文档格式.docx

软件测试理论基础包括性能测试自动化测试等文档格式.docx

《软件测试理论基础包括性能测试自动化测试等文档格式.docx》由会员分享，可在线阅读，更多相关《软件测试理论基础包括性能测试自动化测试等文档格式.docx（22页珍藏版）》请在冰豆网上搜索。

综合测试给出符合要求的软件综合测试方案和结果、一致的软件配置

维护持久的满足用户需求完整地维护记录、文档、软件新版本

2、‘V’模型：

需求分析验收测试（UAT）

概要设计系统测试

详细设计单元测试

Coding

二、软件质量

1、质量与质量模型

因素（特性）：

如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等。

2、质量保证

软件测试概念

验证程序是否符合需求的一个过程

测试：

1、它能做什么2、它不应该做什么

概念;

广义：

软件生存周期中所有的检查、评审和确认工作，其中包括了对分析、设计阶段、以及完成开发后维护阶段的各类文档、代码的审查和确认。

狭义：

识别错误

测试目的：

为了度量和提高被测试软件的质量，对测试软件进行工程设计、事实和维护的整个生命周期。

测试分类：

1按阶段分：

单元测试：

集成测试：

系统测试：

验收测试：

2.按目的分

（1）功能测试

（2）非功能测试：

A.性能:

a.并发（响应时间）b.稳定性（7*245*8查找内存泄漏）c.容量测试，d.压力测试。

*测试数据的准备1.编造数据2.从项目组或生产环境中获取。

B．安全测试（复制链接，回退）

C．界面测试（布局要合理，色调风格一致）

D．易用性测试，安装/卸载测试

E．本地化测试，兼容性测试，恢复/备份测试（实时系统）

F．健壮性测试，可靠性测试（少）

3透明度分

白盒测试

黑盒测试

灰盒测试

4执行方式

静态测试

动态测试

二．测试要点

1.测试规律

BUG的80-20的原则

1.在分析，设计，实现阶段的复审和测试工作能够发现和避免80%的Bug。

2.而系统测试又找到其余Bug的80%。

3.最后的5%的Bug只可能再有用户的大范围，长时间使用后才会暴露出来。

木桶原理

软件质量不是只有软件测试一个方面决定的它是由各个方面共同决定的。

2.测试的重点

1.良好的用例设计，

2.好的测试工作管理（使工作有条不紊的进行减少风险）

3.独立的测试环境

4.软件测试的质量

可以发现以下软件缺陷：

1软件实现的功能的不正确

2.‘缺少’软件没有实现的某个功能

3.’多余”软件实现的某项功能在需求中没有定义。

软件测试本身的质量在于：

发现软件缺陷并能区分其类型，

提供关于软件质量和开发过程质量的信息。

5.软件测试度量

A测试覆盖率：

（

a有多少需求被测试用例所覆盖。

被覆盖的需求/总需求*100%

b被执行需求/总有效需求*100%需求执行率或被测率

c执行用例数/总用例数*100%用例执行率（考察测试人员工作效率）

d通过的用例/总的执行的用例*100%用例通过率（评价软件质量））

B缺陷发现率：

1.缺陷数目

（1）统计个数（按严重级别按功能分布按开发人员按缺陷状态等统计）

缺陷修复率=修复并已经通过的缺陷/发现的有效缺陷总数*100%

缺陷遗留率=上线后发现有效缺陷/测试发现的有效缺陷*100%（考核测试人员）

C测试成功率

2008-8-5笔记

一、测试分类

1、阶段分：

单元unitetest（测试单元：

把整个代码分成小的单元）最靠近编码

集成integrationtest（自上而下、自下而上、宽度、深度四种集成方式）

系统systemtest（把整个被测系统放到大的系统中测试）

验收useracceptancetest（由客户组织或委托第三方的测试，测试具有合同约定性质如果通过意味着客户接受了这个系统。

包括性能、功能的测试以及文档）

前三个是开发商主导测试只有验收是用户来执行

性能performancetest

功能functionaltest

『Weblogic中间件（Bea公司开发被Oracle收购）middlewarewebsphere（IBM公司的）OracleDB2用于大型企业SQLserver用于中小型企业Databaseadministrator数据库管理员大型企业才会有』

2、目的分：

功能：

检测功能好不好使。

非功能：

性能：

【性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。

】

性能测试涉及--测试数据的准备：

编造、从项目组或生产环境中获取

并发：

多人在线操作，响应时间，要求尽可能的短。

稳定：

7*24或5*24小时，不当机不停机，正确执行。

容量测试：

大数据的处理。

压力测试：

即负荷测试，获取系统能正常运行的极限状态。

界面测试：

网站，布局合理。

色调、风格的统一，不能出现窜行、错别字，图片不要过大等。

易用性：

用户使用着方便。

安装/卸载（uninstall）：

大部分软件都需要安装後才能使用。

安全测试：

不允许绕过登录界面，进入系统中来。

本地化：

汉化。

兼容性：

测试软件运行在不同操作系统下，硬件环境下是否正常

恢复/备份：

健壮性：

在异常情况下，软件还能正常运行的能力。

（含义：

1、容错性

可靠性测试：

一定环境下，在给定的时间内，系统不发生故障的概率。

3、按透明度分：

黑盒测试：

blackbox只注重输入输出，不管里面的实现情况，将整个系统当成一个黑盒子

常用方法：

等价类、边界值、因果图、错误推测法

白盒测试：

whitebox更注重内部的逻辑结构分支。

灰盒测试：

graybox介于二者之间，即关心输入输出，也关心内部逻辑

4、按执行方式分：

静态测试：

指不实际运行软件，主要是对软件的编程格式、结构等方面进行评估

动态测试：

运行程序，输入各种值来进行测试。

Alpha测试Beta测试

回归测试：

regressiontest关联性

冒烟测试：

在测试之前对主功能和主路径的测试

前哨测试：

确认测试：

嵌入式测试：

主要测试和硬件有直接联系的软件如路由器

二、测试的一些要点

1、测试的规律

Bug的80-20原则

（1）、在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的BUG。

（2）、而系统测试也能找出其余BUG中的80%。

（3）、最后的5%的Bug可能只有在用户的大范围、长时间使用后才会暴露出来。

80/20原则

1、80%的工程量用在20%的需求上

2、80%的开发成本花费在20%的部件上

3、80%的错误是由20%的部件引起的

4、80%的延期或返工

木桶原理

（1）软件质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会最终软件的质量

（2）

2、软件测试的重点

（1）、测试用例的良好设计：

用例覆盖是否全面用例是否有效

-测试用例的设计是整个软件工作的核心

-测试用例反映对被测对象的质量要求，决定对测试对象的质量评估

（2）、测试工作的管理：

工作有条不紊的进行减少风险

-尤其是对包含多个子系统的大型软件系统，其测试工作涉及大量人力和物力，有效的测试工作管理是保证有效测试工作的必要前提

（3）、测试环境的建立：

（或独立的测试环境）

测试环境应该与实际测试环境一致

功能测试：

中间件数据库一致

性能测试：

中间件数据库程序硬件都要一致

（4）、软件测试的质量：

软件测试可以发现以下软件缺陷

-软件实现的功能不正确

-“缺少”，软件没有实现某项功能

-“多余”，软件实现的某项功能在需求中没有定

发现第一类软件缺陷的过程---“验证validate”

发现後两类软件缺陷的过程---“确认verification”

软件测试本身的质量在于：

-发现软件缺陷并能区分其类型

-提供冠以软件质量和开发过程质量的信息

缺陷的数量+严重级别+功能分布来评判软件的质量

缺陷的数量+严重级别+功能分布+开发人员来评价开发人员的开发质量。

缺陷严重级别共分5级

（5）、软件测试度量

测试覆盖率：

-有多少需求被测试用例所覆盖，代码已经被测试了。

测试覆盖率=已被覆盖/总数（有效）×

100%

需求的执行率=已被执行的/总数*100%测试执行

用例执行率=已执行的测试用例/总数*100%工作效率

用例的通过率=已通过的/总的已执行数*100%软件质量

缺陷修复率=已修复的缺陷/发现有效的缺陷×

100%

缺陷遗留率=上线后发现的有效缺陷/测试有效缺陷×

缺陷发现率

-缺陷是何时被发现，并且有多少缺陷已经被发现。

缺陷：

按严重性来分类

-缺陷数目

-缺陷的严重性

按功能分布

按开发人员

按缺陷状态

测试成功率：

3、测试的原则

（1）、所有的测试都应追溯到用户需求

（2）、应该在测试工作真正开始前的较长时间内就进行测试计划

（3）、8/2原则应用于软件测试

（4）、测试应从“小规模”开始，逐步转向“大规模”。

（5）、穷举测试是不可能的。

（6）、为了达到最佳效果，应该有独立的第三方来构造测试。

（7）、不充分的测试是不负责任的；

过分的测试是一种资源浪费，同样也是一种不负责任的表现。

1.应当把“尽早和不断的测试”作为开发者的座右铭。

2.程序员应当避免检查自己的程序，测试工作应当由独立的专业的软件测试机构来完成。

3.设计测试用例时应当考虑到合法的输入合不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断；

电源断电情况。

4.一定要逐一测试中的错误集中发现现象，这和程序员的编程水平和习惯有很大的关系。

5.对测试错误结果一定要有一个确定的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

6.制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7.回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的情况并不少见。

8.妥善保存一切测试文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

4、测试人员的基本素质

（1）、沟通能力：

表达和获取别人表达的信息

（2）、移情能力

（3）、技术能力

（4）、自信心

（5）、外交能力

（6）、幽默感

（7）、很强的记忆力

（8）、耐心

（9）、怀疑精神

（10）、自我督促

（11）、洞察力

5、测试人员的服务对象

（1）项目经理

（2）程序员

（3）技术文档编写人员

（4）技术支持

（5）市场开发

（6）管理层和项目相关人员

（7）用户

测试人员关注失效，客户才能关注成功

6、缺陷报告BugReportFAQ常见问题解答

用途：

1、报告提示大家注意缺陷，并帮助程序员定位内部问题

2、报告提示大家注意规格说明和测试文档、用户文档或开发工具中的问题

3、为技术文档编写愿提供背景信息，编写元要编写手册或公司网站中的问题定位部分

4、报告提示需要通过客户培训解决的问题

5、报告为客户售后技术人员提供关键的信息，他们会了解到产品上线后还没有被解决或没有完全解决的问题

6、报告向管理层提供正在开发的产品的状态和质量

7、报告在开始计划产品下一个版本是，提供初始改进建议

永远不要假设明显的程序缺陷已经写入报告

明确严重等级和优先级的差别

严重级别（sevenity）表示程序错误的影响后果

优先级别（priority）

一般情况下严重级别和优先级别成正比。

1、为每一步编号

2、不要跳过重现缺陷的人和步骤

3、精简缺陷重现步骤

4、通过空行提高报告的可读性。

8.6号集成测试：

集成测试的任务：

1模块连接起来检查模块互相调用数据是否会丢失。

2组合后是否能达到预期功能。

3模块间是否相互影响。

4全局的数据结构是否会有问题会不会被一场修改。

5单个模块误差累计错误是否会放大。

集成测试方法：

1.非增量式测试方法。

一步到位进行测试。

2.增量式测试方法

（1）自顶向下增量测试

（2）自底向上增量式测试

三．系统测试

需求：

功能需求和非功能需求。

在需求分析阶段要确定软件的可测性（通过某种方式进行验证），保证有效完成系统测试工作。

需求具有准确性没有二义性。

系统测试内容：

功能测试

所有性能要求得到满足。

其它需求（）

系统测试的任务：

1.功能测试

2.性能测试

3.恢复测试

4.安全测试

5.强度测试

6.其它限制条件的测试

系统测试技术和测试数据：

完全采用黑盒测试，测试数据尽可能像真实数据一样精确和有代表性，也必须和真实数据的大小和复杂性相当。

测试用例TestCase（TC）要求复用性。

四.验收测试

一般也是黑盒测试，数据用生产环境的备份数据。

验收的四类内容：

1.功能需求

2.性能需求

3.交互质量需求

4.全面的软件质量需求

五，回归测试（R）

可以采用人工也可以使用工具（QTP）来执行。

分类：

全回归工作量大耗人力

部分回归工作量小功能肯能有遗漏

测试流程：

1.测试文档及作用

测试文档是对要执行的软件测试及测试的结果进行扫描，定义，规定和报告的任何书面或图示信息。

测试文档的作用

1促进项目组的成员的交流沟通

2便于对测试项目的管理

3决定测试的有效性

4检验测试资源

5明确任务的风险

6评价测试结果

7饭便在测试

8验证需求的正确性。

测试文档分类：

前置作业文档和后置作业文档

日常测试情况汇报包括：

周报和日报。

测试流程

测试计划*工作规划（资源使用安排进度风险预估及规避方法

测试范围）测试计划测试方案

测试设计测试需求分析测试需求文档

用例设计TC

测试准备及实现测试环境测试数据测试脚本SQL语句

模拟客户端等产生脚本（script）文件数据文件程序

测试执行执行测试用例发现缺陷产生文档：

测试日报周报

和缺陷报告

测试评估对软件进行质量评估分析报告

在以上每个阶段完成进行评审以保证质量。

测试前评审获取相关部门的认可。

2测试人员沟通使认识没有偏差3.4分析报告的评审对软件最后能否上线达成一致。

测试方案（既怎么做）

制定测试计划目的：

1.是测试工作更顺利

2.促进项目参加人员彼此沟通

3.是软件测试工作更易于管理。

制定测试计划的原则：

（时间1.5倍预测时间）

1.制定测试计划应尽早开始

2.保持测试计划的灵活性

3.保持测试计划简洁易读

4.尽量争取多渠道评审测试计划

5.计算测试计划的投入。

制定测试计划是面对的问题：

（解决办法多沟通）

1.与开发者意见不一致

2.缺乏测试工具

3.培训不够

4.管理部门缺乏对测试工作的理解和支持

5.缺乏用户的参与

6.测试时间不足

7.过分依赖测试人员

8.测试人员处于进退两难的状态

9.不得不说“不”

property属性：

作者（author）

覆盖状态（coverstatus）notcompleted（没有测试用例覆盖）NORun与用例关联但没有被执行

Passed所有测试用例都通过

failed测试用例有没有通过的

notIomplete3个用例两个测试通过一个还没有测

创建时间CreationDate修改时间modified

测试需求：

优先级priority需求IDReqID产品Product

名称Name类型Type复查Reviewed（蓝字必须有）

来源于业务需求或软件需求

测试设计：

测试用例：

一般指对一项特定的软件产品进行测试任务的描述体现测试方案，方法技术和策略。

测试用例的设计：

1.为实施一次测试而向被测系统提供的输入数据操作和各种环境设置，期望结果的一个特定的集合。

2.控制着软件测试的执行步骤

3.是对测试方案中每个测试项的进一步实例化。

测试用例属性：

创建日期描述（Description）设计者（Designer）

估计开发时间（EstimatedDevTime）执行状态（ExecutionStatus）

修改（Modified）状态（Status）步骤（Steps）主题（Subject）

模板（Template）测试名称（TestName）类型（Type）

前置条件输入数据输出数据

测试用例的编写原则

1.测试用例的代表性

2.测试结果的可判定性

3.测试结果的可再现

4.准确性

5.简洁性（3-9步之内）

6.可重用性

7.可跟踪性

8.适用性

复用的意义：

1.减少工作量2.易于维护3.易于复审。

对测试数据的要求：

1.功能测试不需要大量数据

2.功能测试需要数据覆盖率高

3.功能测试的测试数据要求尽量真实

4.性能测试需要大量的数据

5.性能测试的测试数据应尽可能的达到符合实际的数据分配。

测试执行：

是执行所有的的或选定的一些测试用例，并观察其测试结果的过程。

其过程由四部分组成

1.输入

2.执行过程

3.检查过程

4.输出

软件测试的执行内容：

-执行测试用例

-记录原始测试数据

-记录缺陷

-多所有的缺陷进行跟踪，管理和监控。

测试集testset（存在有TD工具中的再测试纯理论中不存在）

作用可以重复TC，执行结果

执行流：

executeflow.具有先后顺序的一些测试用例的组合。

执行条件状态：

Finish完成做了不管结果

Pass通过做了必须做对。

实际结果：

用来和预期结果进行对比的。

就是与需求不符的地方。

不符合下面五个规则里的一个就叫做缺陷：

1.软件未达到软件规格说明书中行规定的功能

2.软件超过软件规格说明书知名的范围

3.软件未达到软件规格说明书中指出的应达到的目标

4.软件运行出现错误

5.软件测试人员认为软件难于理解，不易使用，运行速度慢，或者最终用户认为软件使用效果不好。

软件缺陷的种类：

1.功能不正常

2.使用上不方便

3.软件的结构为做到良好的规划

4.功能不充分

5.与软件操作者的互动不良

6.使用性能不佳

7.为做好错误处理

8.边界错误

9.计算错误

10.使用一段时间所产生的错误

11.控制流程的错误

12.在大数据量压力之下所产生的错误

13.在不同硬件环境下产生的错误

14.版本控制不良所产生的错误

15.软件文档错误

缺陷分类：

操作级和结果级的

缺陷的属性：

实际修复时间

分配给

关闭日期

注释

缺陷ID

描述

检测者

检测版本

检测日期

修改日期

计划关闭版本

优先级

可重现

状态

主题

概要

8.7号缺陷的生命周期

缺陷的生命周期：

缺陷从发现到修复（关闭）的全部过程。

缺陷状态：

1.新2.打开3.修复4.重新打开5.关闭6.否决

缺陷是独立的，缺陷管理分为缺陷跟踪和缺陷管理（除了追踪还包括汇总分析缺陷种类的定义，市面上有专门的管理工具如bugziller和jira）。

TD（测试管理工具）

测试评估与报告

测试评估是在测试结束后对整个测试过程与产品进行评估的过程。

评估过程包括：

工作总结，过程评估，缺陷分析，（结论，留给上司）

测试评价主要包括覆盖评价和及质量和性能评价。

测试评估：

1.结合量化的测试覆盖率及缺陷跟踪报告

2.对软件项目的质量和开发团队的工作进度及工作效率（最好别写）进行综合评价

3.生成相应的报告或报表

评估包括：

1测试工作的评估—测试覆盖面，用力执行，工作完成情况

2软件质量的评估：

需求通过，用例通过，缺陷情况，

测试报告的意义：

1.以测试报告的形式像整个软件开发部门报告测试结果既发现的缺陷或错误。

2.撰写测试报告的目的是为了让整个软件开发部门了解软件开发的进展情况以使缺陷能够迅速得到修复；

3.测试报告的格式并无定义，要求能够完整，清楚的反应当前的测试进展情况，明白易懂，无二义性。

测试计划模板：

1.测试计划标识

2.介绍

3.测试项

4.需要测试的功能

5.不需要测试的功能

6.方法

7.测试项的通过/失败准则

8.暂停准则和恢复准则

9.测试完成所提交的材料

10.测试任务分配

11.环境需求

12.职责和分工

13.人员及培训要求

14.时间表

15.风险及规避方法（应急措施1.增加人员2.延时3.增加预算4.减少工作量）

16.审批人

17.策略两种标准一.以时间为目标二.以质量为目标

*制定策略考虑以下内容：

a要使用的测试方法

b.确定质量风险

c.测试完成和测试成功所采用的评价标准

d.有关资源要求或涉及进度的特殊考虑

e.测试类型，评估标准以及测试方法