测试基础教案新整理Word文档格式.docx
《测试基础教案新整理Word文档格式.docx》由会员分享，可在线阅读，更多相关《测试基础教案新整理Word文档格式.docx（19页珍藏版）》请在冰豆网上搜索。
团队合作能力、良好的沟通能力、探索创新精神
技术
简单的代码走读能力
熟练掌握软件测试概念和软件测试流程
熟练掌握测试用例设计方法
熟悉数据库基础（增删改查）
熟悉环境的搭建（项目部署）
熟悉测试工具的使用：
缺陷管理工具（高阶：
自动化管理工具、性能测试工具）
白盒测试理论和技术、集成测试理论和技术（高阶）
3.项目
3.1职位架构
3.2项目的含义
在软件工程学中，实现用户所提出需求的一系列过程称为项目
3.3项目五要素
What：
项目要实现什么
When：
什么时间内完成
Where：
在哪里完成
Who：
哪些人参与
how：
怎么去完成
3.4判断题
项目不一定是产品（对，存在失败的产品）
项目是产品的过程（对，项目的含义）
产品是项目的成果（对，包含成功的产品和失败的产品）
项目可能随时停止，此时则无法得到产品（对）
可能存在失败的产品（对，Vista）
3.5项目与产品的区别
从用户角度：
项目针对的是单一用户或者是多个用户而言的；
产品针对的是市场
从技术角度：
项目的需求是可变的；
而产品的需求是固定的
从价格角度：
项目的投入费用更大；
产品的利润则大于项目
3.6项目的架构
3.6.1B/S架构（Browser/Server）
即浏览器/服务器架构，在这种架构下，用户的工作界面是通过浏览器来实现的，而主要事物逻辑是在服务端（server端）实现的
3.6.2C/S架构（Client/Server）
即客户端/服务器架构，用户的程序主要在客户端，服务器提供数据管理、数据共享以及系统维护等。
它们最主要的区别是CS架构的应用程序需要在用户的计算机上进行安装。
如我们常用的Word,Excel等应用软件属于CS架构；
而BS架构的应用程序不需要在用户的计算机上进行安装，只需要有一个浏览器就可以运行BS架构的应用程序。
如现在网上一般的电子商务网站即属于此类型。
3.6.3B/S和C/S混合架构
4.测试基础
4.1CMMI软件测试成熟度模型
用于衡量企业软件测试专业化程度，国内大部分处于第三级（大公司）
初始级：
测试过程无序的，甚至是混乱的
定义级：
已具备基本的测试技术和方法，测试与调试已被明确的区分开
集成级：
测试已经融入到软件的生命周期，遵循V模型，从需求分析开始制定测试计划
管理和度量级：
测试过程中包含评审、验证活动
优化级：
能制定缺陷预防计划，防止已识别的缺陷再次发生
4.2测试的原则
测试必须尽早地参与（立项时候就开始需求分析）
测试必须回归需求
测试无法穷举
测试可以提高软件质量，无法保证质量
测试应用用户角度去发现问题（开发人员思维存在局限性）
设计一条用例尽可能覆盖多条路径（效率）
计一条用例能发现至今从未发现的问题（高效）
4.3测试与调试的区别
按含义分：
在软件工程学中，测试是指检测被测软件或系统是否满足需求的过程；
调试是指检测代码是否达到预期值的过程。
按执行者：
测试由测试人员执行；
调试由开发人员执行。
按时间分：
测试时有计划性有目的的；
调试是随时性无计划的。
按目标分：
测试是处于用户角度尽可能地完善系统的功能；
调试是完成当前开发任务。
4.4缺陷
4.4.1缺陷的产生
缺陷产生原因：
由环境因素和人为因素导致
描述：
在系统开发过程中，如果开发人员过于自信，在开发过程中犯了一个错误-Error，那么测试结果将无法达到预期（缺陷），最后会称该开发为失败的开发-Fail
缺陷：
某一功能无法达到预期结果成为称为（即Bug）
错误：
指的是人为操作导致，功能没有实现
在IT业界中，缺陷没有准确的定义，缺陷（Defect）和错误（Error）统称为Bug
4.4.2判断题
缺陷一定是错误（错）
缺陷不一定是错误（错）
缺陷可能是错误产生的（对）
错误产生的不一定是缺陷（错）
4.4.3产生缺陷的原因
需求不明确
相关文档不齐全
开发过于自信
相关技术无法满足要求
相关人员沟通不及时
测试不完全
环境因素等
4.4.4缺陷的类型
有效缺陷：
不符合需求的，被开发人员认可的缺陷
无效缺陷：
不符合需求的，测试人员认可但开发人员不认可的缺陷（误提）
合法的无效缺陷：
不符合需求的但目前技术无法修复的
4.4.5产生无效缺陷的原因
测试任务分配不合理，同一模块重复测试
版本控制混乱
Bug管理不当
环境因素（开发环境，测试环境，用户真实环境）
4.4.6重现Bug的必要性
便于开发人员对Bug的定位（排除法）
便于对Bug的重现率进行统计（如偶然Bug，便于在缺陷报告中分析）
提高开发与测试的工作效率
偶然bug怎么重现
从环境入手分析（版本、兼容）
记录操作，让其他人来重复一遍看能否重现
改变思维测试（正向思维，逆向思维）
4.4.7Bug的管理方式
Word
Excel
缺陷管理工具（Testdirector（TD）,QC（qualitycenter）,（开源：
Jira,Bugzilla,Bugfree,禅道）Mantis已过时）
4.4.8缺陷的状态
当测试人员发现一个缺陷，在缺陷管理工具New一条记录，指派给测试经理；
测试经理验证缺陷能否重现，若未重现，则将缺陷closed掉；
反之则将缺陷设为open状态并指派至相关开发人员；
开发人员接受缺陷后验证其是否为有效缺陷，若问题确实存在，则fixed并closed；
若开发人员发现缺陷在现阶段无法修复，则通知测试人员将delay；
在下一版本回归测试过程中，测试人员将延期的缺陷重新打开指派至开发人员，待开发人员验证是否可以修复，若可修复则直接fixed并closed掉；
若开发人员验证当前缺陷为无效缺陷，则将其拒绝并通知测试人员，测试人员验证开发人员拒绝的缺陷是否可以关闭，否则将其重新打开指派至开发人员，开发人员重新验证缺陷是否有效，若有效则fixed；
经过反复多轮的回归测试，最终所有缺陷都需要closed（注：
开发人员只有拒绝权限）
4.4.9缺陷的内容
缺陷内容：
前置条件、测试环境、操作步骤、预期结果、实际结果、状态、严重级、优先级、所属模块、缺陷标题、发现人
描述缺陷：
简单明了，通俗易懂，详细准确
严重级
最高严重级：
系统崩溃、闪退、数据丢失（数据库数据丢失）、内存泄露
较高严重级：
功能未实现、数据错误、软件兼容性问题
一般严重级：
界面问题（协调、美观、布局是否合理）、显示（明文密码）、错别字
建议：
用户易用性操作（右键、tab键）
优先级
对缺陷修复的紧急程度进行定义
最高优先级、较高优先级、一般优先级、最低优先级
优先级别高的bug严重级别一定高（错）------公司logo问题
严重级别高的bug优先级别一定高（错）------合法的无效缺陷，当前技术无法达到
严重级别高的bug优先级别通常会高（对）
4.5环境
测试环境：
测试人员进行测试的环境，该环境是尽可能的去模拟用户的环境
开发环境：
开发人员进行开发所处的环境，该环境是理想环境
用户环境：
用户使用的、真实的环境
测试环境与开发环境分开
测试环境接近真实性（模拟用户环境），便于发现问题
便于版本控制
便于缺陷管理
项目流程
公司接到项目后，召开立项会议，参与需求分析；
开发经理根据需求分析的结果编写概要设计，再根据概要设计编写详细设计并分发给相关开发人员进行具体功能的编码；
测试经理根据需求分析的结果编写测试计划，再根据测试计划编写测试方案并分发给相关测试人员编写测试用例；
测试人员搭建好测试环境后，对开发人员提供的demo版本进行冒烟测试，通过后则接受此版本的测试；
执行测试用例，根据测试输出编写功能测试报告；
反复多轮回归测试后得到稳定版本，在稳定版本下进行验收测试，编写验收报告
冒烟测试
内容：
在测试用例库中选取主体业务流程的测试用例进行执行
第一次，提交Demo版本时，又称预测试；
通过率超过80%，则接受该Demo版本的测试；
第二次，在验收时，确保验收版本（给用户的版本）为准确版本
Demo版本（初始版本）
要求整个被测系统的主要功能必须全部实现
配置文档：
描述如何搭建测试环境的文档
提交Demo版本后开发人员在做什么
完善其他模块的功能
修复Bug
优化代码
参与其他项目的开发
提交缺陷报告后测试人员在做什么
整理测试输出
其他项目的测试
缺陷跟踪
维护测试用例库
5.文档编写
5.1测试计划
合理分配人力物力资源
制定时间表
测试策略（确定被测系统需要进行哪些类型的测试）
风险规避措施（时间、人员、技术、需求变更）
测试计划作用
对整个测试过程具有指导作用
便于测试工作的管理
提高测试效率
5.2测试方案
时间表
测试策略（具体类型对应的测试方法）
任务模块的具体分配
5.3功能测试报告报告
对该阶段所耗费的相关资源进行统计
分析缺陷分布情况
为下一轮测试提供建议
功能测试的作用
为下一次测试提供指导作用
为下一次测试起里程碑作用
方便验收报告的编写
验收测试
alpha测试：
先由产品部验收，再交给用户（在公司内部环境验收）
beta测试：
直接交给用户（在用户真实环境中验收，用户产生报告交给公司）
验收准则
用户需求功能全部实现
全部bug都已经修复
软件功能实现符合概要设计与详细设计
项目的输出工件齐全
评审的作用
需求明确，利于开发与测试工作的进展
及时发现并解决问题
使项目管理更规范，提高工作效率
利于归纳总结，增加测试经验
6.开发模型
6.1瀑布模型
可行性分析、需求分析、软件计划、软件设计、软件测试、软件维护
一般用于大型项目
优点
层次分明，每阶段结束都有总结
需求分析、软件测试与维护都有用户参与
需求分析与软件计划准备充分
缺点
流程不可逆
若需求更改，后期维护费用高
用户是一个不稳定因素
测试没有尽早参与
风险高
6.2快速原型
基于原型所进行的再开发
项目成本和周期减少
风险相对较低
反复修改与改进，使产品更符合需求
必须拥有一个符合用户需求的原型
原型差距越大，成本越高
开发与测试交互过多，工作量大
管理复杂
6.3螺旋模型
制定计划、风险分析、实施工程、客户评估
风险最小
后期维护成本低
每个周期结束都得到客户认可
具有灵活性
周期太长
用户必须参与
版本过多，工作量大，管理复杂
6.4敏捷开发模型
继承了快速原型和螺旋模型的综合体
优点：
灵活、敏捷
缺点：
不适用于大型项目
为什么测试需要尽早的参与？
尽早发现问题尽早解决，降低成本
需求越渐明确
减少后期维护工作量，降低后期维护难度
BVT测试（BestVersionTest）
优先级测试，在项目时间紧急则根据用例的优先级进行执行，在项目发布后，执行其余的测试用例
了解：
单元测试过程中将会发现约百分之八十的缺陷，因为单元测试是所有测试中最早开始的，并且在刚开始的版本集中发现最多bug
7.测试模型
7.1V模型
前期开发有足够的时间进行编码
开发与测试之间在项目中层次分明
测试没有尽早参与
开发与测试之间的交互甚少
测试时间不够充裕（测试不全面，质量无法提高）
项目周期较长（先开发后测试）
7.2W模型
相当于由两个V模型构成，一个V为开发过程、一个V为测试过程
测试实现了尽早的参与
开发与测试具有良好的交互（及时发现并解决问题）
具有足够的时间进行测试
开发与测试实现了并行操作
增加了开发的工作量（在开发设计阶段除了编码阶段还要修复bug）
缺陷控制困难（bug无法进行集中式处理解决）
版本控制问题（没有按阶段性提交）
7.3H模型
前期准备阶段开发与测试相互独立，后期开发与测试进行交互（交互点是在开发提交demo版本给测试部时）
开发与测试交互合理（提高工作效率）
开发与测试前期准备工作充足
开发与测试内部流程相互独立
开发与测试前期缺少交互（导致各自对需求理解存在偏差）
进度控制困难（无法确定交互点）
7.4X模型
相当于是由开发人员逐个模块进行开发，开发后交由测试人员进行测试，等所有模块全部开发完成后进行集成，然后测试人员对整个系统进行全面测试。
适合集成测试阶段使用的模型。
并且与敏捷开发模型相似
测试点细、面广（每个模块进行独立测试）
实现了多类型测试
能够尽可能多的发现问题
单元、集成测试时间耗费过多，使得系统测试不全面
集成阶段测试困难（有可能存在兼容问题）
流程复杂，测试开发工作量大
封版实现困难
9.测试分类
按结构分：
黑盒测试、白盒测试、灰盒测试
按是否执行分：
静态测试、动态测试
按阶段分：
单元测试、集成测试、系统测试、验收测试（alpha测试、beta测试）
1.黑盒测试又称为功能测试，不考虑内部逻辑运算，只考虑外部功能的实现
2.白盒测试又称为结构测试、逻辑驱动测试，不考虑外部功能，只考虑内部逻辑运算的实现（分多个单元测试）
3.灰盒测试：
白+黑同时关注外部功能的实现也关注内部逻辑运算的实现
4.静态测试：
指不运行被测对象，人工对被测对象和文档进行分析和检查，实际上是对需求分析、技术说明书、程序源代码等进行检查。
包括代码审查，代码走读，桌面检查，技术评审，静态分析。
5.动态测试：
指实际运行被测对象，检测是否符合客户需求的过程。
（软件测试的含义）
6.单元测试：
以一小段代码块为基础进行测试，比如某一属性或方法
与白盒测试的区别：
1.白盒测试按结构分，单元测试按阶段分；
分类不同，含义不同
2.白盒测试是对整个的逻辑测试，单元测试是对一小段代码块测试
3.单元测试的用例设计参照白盒测试六大法（实际执行的是单元测试，n次单元测试组合成为白盒测试）
7.集成测试：
模块与模块之间的接口测试，渐增式、非渐增式、自底向上、自顶向下（模块与模块之间要有良好的独立性，高内聚，低耦合）
8.系统测试：
指被测对象经过系统（一系列）的测试，比如：
功能测试，界面测试，性能测试，易用性测试，兼容性测试等一系列测试。
9.验收测试：
alpha测试（公司内部验收后交给用户验收），beta测试（直接给用户验收，用户真是环境）
10.性能测试：
模拟用户真实操作，分析所产生的性能指标是否满足客户需求的过程，比如：
压力测试、负载测试、并发测试、配置测试、强度测试、疲劳测试
11.压力测试：
对服务器一步一步施压，检测被测对象性能瓶颈的过程
12.负载测试：
检测服务器在一定压力下各项性能指标是否满足客户需求的过程
13.并发测试：
针对集合点的测试（分为同一操作的并发、不同操作的并发）
14.易用性测试：
检测被测对象是否符合用户操作习惯（单击，双击，快捷键）
15.兼容性测试：
硬件兼容（机器与机器之间，如：
打印机），软件兼容（支撑软件，开发软件，系统软件，应用软件）
16.安全测试：
防火墙（硬件防火墙，如路由器）、软件防火墙（如：
windows自带防火墙）、系统漏洞、远程协助、安全策略、病毒（SQL数据库注入，通过网络实现攻击）
17.可靠性测试：
指被测对象在稳定环境下运行能否正常运行一段时间（7x24或3x24）
18.异常测试：
检测被测对象的容错能力，进行特殊的操作（除数为0）
19.恢复性测试：
指被测对象异常关闭时重新启动时能否恢复到上一步的操作（word文档不定定时保存）
20.变态测试：
对被测对象进行破坏性的操作：
断电、杀进程等
21.健壮性测试：
评估被测对象承受破坏性操作的能力
22.数据库测试：
大数据容量测试（大量数据集中增加或删除或改动或查询的操作）、历史数据测试（将不经常使用的数据迁移到历史数据库中腾出空间来注入新的数据，要求准确性）
23.穿越测试：
银行、游戏、游戏行业，主要使用场景发设计用例（数据穿越后的准确性）
24.web测试：
网页、网站、cookies（缓存）
25.文档测试：
内容测试（正确准确）、语句测试（通顺无错别字）
26.回归测试：
在新版本测试之前验证上一版本的bug是否已经修复的过程，可存在多个回归测试。
27.随机测试：
执行随机抽取的测试用例
升级会员 