微软用户引子引子软件测试在整个软件开发过程中的作 395790180.docx
《微软用户引子引子软件测试在整个软件开发过程中的作 395790180.docx》由会员分享，可在线阅读，更多相关《微软用户引子引子软件测试在整个软件开发过程中的作 395790180.docx（30页珍藏版）》请在冰点文库上搜索。
微软用户引子引子软件测试在整个软件开发过程中的作395790180
引子
1.软件测试在整个软件开发过程中的作用
软件测试是对软件产品和阶段性工作成果进行质量检验，力求发现其中的各种缺陷，并督促修正缺陷，从而控制和保证软件产品的质量。
所以软件测试是软件公司致力于提高软件产品质量的重要手段之一。
软件缺陷发现越迟代价越大
缺陷发现越迟，影响范围越广
缺陷发现越迟，返工的工作量越大
缺陷发现越迟，造成的危害越大
2.V模型的理解
1）软件测试和软件开发构成一个全过程的交互、协作的关系，两者自始至终一起工作，共同致力于同一个目标——按时、高质量地完成项目。
2）在V模型中，前半部分是开发，可由需求分析定义，系统、架构设计、详细或程序设计，编码构成。
测试过程被加在开发过程的后半部分。
单元测试所检测代码的开发是否符合详细设计的要求。
集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。
系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。
而验收测试则检测产品是否符合最终用户的需求。
第1章
1.软件质量的概念，质量需求包括功能的、非功能的、用户需求和企业需求
软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括：
1）软件产品质量满足用户要求的程度
2）软件各种属性组合的程度
3）用户对软件产品的综合反映程度
4）软件在使用过程中满足用户要求的程度
质量需求：
就是通过人机交互界面来完成用户所需的各项操作，包括数据的输入和结果输出。
非功能的：
主要体现在性能，可用性，可靠性，兼容性，安全性，
用户需求：
质量的用户需求是和用户直接相关的质量需求，包含功能性需求和部分非功能需求。
企业需求:
主要是一些给功能性的需求，如软件的可维护性，兼容性，可移植性和可扩展性。
2.软件缺陷的定义
软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，不能满足或不能全部满足用户的需求。
从内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；
从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
3.软件缺陷和软件错误的区别
软件缺陷范围更广，涵盖了软件错误，还涵盖不一致性问题、功能需求定义缺陷和产品设计缺陷等。
软件错误，属于软件缺陷的一种——程序或系统的内部缺陷，往往是软件代码本身的问题。
软件错误往往会导致系统的某项功能失效或者使用的故障，即软件内部缺陷最终表现为外部缺陷。
外部缺陷主要表现为软件故障或功能失效，即软件提供给用户的功能或服务，不能达到用户的要求或没有达到事先设计的指标，如：
突然中断
4.软件测试的定义（几种不同的观点，怎样理解）
1）软件测试的狭义观点和广义观点
a.狭义观点：
程序测试是为了发现错误而执行程序的过程（瀑布模型）
b.广义观点：
将测试延伸到需求评审、设计审查活动中去。
由静态测试和动态测试构成一个全过程的、完整的软件测试。
2）软件测试的辩证观点
a.正向思维：
验证软件是“工作的”，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。
b.逆向思维：
证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。
3）软件测试的风险观点
软件测试是对软件系统中潜在的各种风险进行评估的活动
4）软件测试的经济学观点
一个好的测试用例是在于它能发现至今未发现的错误。
缺陷发现得越早，所造成得代价就越低，这就是从经济学的观点来说明测试越早越好。
5）软件测试的标准观点
软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试=V&V
5.软件测试的目标
1）直接目标——就是为了更快更早地将软件产品或软件系统中所存在的问题找出来，以促进系统分析人员、设计人员和程序员尽快地解决这些问题。
2）间接目标——软件测试的间接目标是验证了所有功能已按照事先设计或定义而实现。
但其直接目的并非验证每个功能都能实现，而是设法找到每个功能不能正常实现的地方，即尽量促使软件故障的产生。
6.测试过程和开发过程的关系（W模型，同步和依赖关系）
A．测试过程和开发过程保持同步的关系。
软件分析、设计和实现的过程，同时伴随着软件测试——验证和确认的过程
B．测试过程是对开发过程中阶段性成果和最终的产品进行验证的过程，而软件开发的进一步活动又依赖于测试的结果。
所以两者相互依赖。
前期，更多地依赖开发过程（设计和实现能力决定整个软件过程的进展状态）,后期更多地依赖测试过程（测试策略和能力，会直接影响测试效率，测试效率高就能更快地发现缺陷，缺陷就能得到更快地修正）。
C．测试工作的重点和开发工作的重点可能是不一样的，两者有各自的特点。
不论是在资源管理，还是风险管理上，两者都存在差异。
第2章
1.测试计划的目标
测试计划的目标是提供一个框架、不断收集信息，对不确定性进行分析，将不确定性的内容慢慢转化为确定性的内容，该过程最终使得项目测试负责人能够对资源、成本及进度进行越来越合理、准确的估算。
*2.需求评审的重要性
1）产品需求审查和评审是软件开发重要环节之一，也是测试活动之一，即静态测试需求验证。
通过需求审查保证系统需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。
2）软件缺陷并不只是在编程阶段才产生，需求和设计阶段同样会产生缺陷。
3）需求评审重要性表现方面
v发现需求定义中的问题，尽早发现缺陷，降低劣质成本。
v保证软件需求的可测试性。
v与市场、产品、开发等相关人员在需求理解上认识一致，以免后期的争吵。
v通过需求评审，更好的理解产品的功能性与非功能性需求，为制定测试计划打下基础。
v确定测试目标与范围。
虽然此后需求会发生变更，但能得到有效控制，降低测试风险。
*3.评审的类型
管理评审、技术评审、文档评审、流程评审
*4.需求评审的标准
正确性、完备性、一致性、可行性、易理解性、易修改性、易测试性、易追溯性
第3章
*1.为什么要进行设计验证P85-86
软件设计是把软件需求转换为软件表示的过程，也是将用户需求准确转化为软件系统的唯一途径，对软件设计进行验证，就是更好地保证这种转换的正确性和完整性，也是为了更好地设计系统测试的用例。
再者，软件设计的验证，需要在编程之前进行，这样做可避免变成误入歧途，并为软件部署的准备获得更多的时间。
这一切，都有助于缩短软件开发周期，使产品早日面向市场，提高软件企业的竞争力。
*2.验证和确认的区别P97
验证过程与确认过程（V&V）看起来类似，但是它们目标不同，处理的对象也不同，“验证”是检验软件工作产品是否符合规定的设计要求，而“确认”过程则要证明所开发的最终产品在其预定的环境中能发挥预定的作用，满足客户使用的需求。
“验证”是以产品设计规格说明书作为依据的，而“确认”是以客户需求为目标的。
第4章
1.为什么要测试用例
测试需求和范围通过测试用例体现出来，并以更为有效的方式来执行测试，以便于更快地发现程序的缺陷。
测试用例是测试脚本开发、测试执行的基础，只有设计好测试用例才能保证测试的覆盖率。
A.测试用例是测试人员测试过程中的重要参考依据。
B．测试用例可以帮助实施有效的测试。
C．良好的测试用例不断的被重复使用，使得测试事半功倍
D．测试用例是一个知识积累的过程。
E．测试用例是一个知识传递的过程
F．即使是很小的项目，也可能会哟几千甚至更多的测试用例
G．从项目管理的角度讲，测试用例的通过率检验代码质量保证效果最主要的指标之一。
H．测试用例也可以评估测试人员进度，工作量，以及跟踪或管理测试人员的工作效率的主要因素
测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
2.测试用例的元素
测试目标、测试对象、测试环境要求、测试前提、输入数据和操作步骤，概括为5W1H
a.Why——为什么而测？
b.What——测什么？
c.Where——在哪里测？
d.When——什么时候开始测？
e.Which——哪些输入数据？
f.How——如何操作软件？
3.对黑盒测试和白盒测试的理解
答：
黑盒测试方法:
是把程序看做一个不能打开的黑盒子，在完全不考虑内部结构和内部特性的情况下来考察数据的输入，条件限制和数据输出，进而完成测试。
黑河测试方法，指根据用户的需求和已经定义好的产品规格，针对程序结构和用户界面进行测试，检验程序是否能适当接受输入数据而产生正确的输出信息，并且保持外部信息的完整性。
白盒测试方法：
也称为结构测试或逻辑驱动测试，就是清除软件产品内部的逻辑结构和工作过程，针对程序语句，路径，变量状态等进行测试。
例如，检验程序的各个分支是否得到满足，检验程序是否按照事先预定的路径进行执行。
白盒测试的主要方法有逻辑覆盖，分支覆盖、条件组合覆盖，基本路径测试等。
4.黑盒和白盒的区别
1）黑盒测试的优点有：
a.比较简单，不需要了解程序内部的代码及实现；
b.与软件的内部实现无关；
c.从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；
d.基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；
e.在做软件自动化测试时较为方便。
2）黑盒测试的缺点有：
a.不可能覆盖所有的代码，覆盖率较低；
b.自动化测试的复用性较低。
3）白盒测试的优点有：
帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
4）白盒测试的缺点有：
a.程序运行会有很多不同的路径，不可能测试所有的运行路径；
b.测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；
c.系统庞大时，测试开销会非常大。
5.功能测试的内容
界面测试、数据测试、操作测试、逻辑测试、接口测试
6.功能测试的方法（等价类法、*边界值法、*因果图法、*决策表法、*错误推测法、*场景法、*状态图法、*正交实验法）
等价类法：
分为有效等价类和无效等价类
1）边界值法：
v对16-bit的整数而言32767和-32768是边界
v屏幕上光标在最左上、最右下位置
v报表的第一行和最后一行
v数组元素的第一个和最后一个
v循环的第0次、第1次和倒数第2次、最后一次
a.边界值分析法利用输入变量的最小值（min）、略大于最小值（min+）、输入值域内的任意值（nom）、略小于最大值（max-）和最大值（max）来设计测试用例
b.推论：
对于一个含有n个变量的程序，采用边界值分析法测试程序会产生4n+1个测试用例。
例：
有二元函数f（x,y），其中x∈[1,11]，y∈[1,31]。
则采用边界值分析法设计的测试用例是：
{<1,15>,<2,15>,<11,15>,<12,15>,<6,15>,<6,1>,<6,2>,<6,30>,<6,31>}
2）因果图：
3）正交实验法
a.把影响实验指标的条件称为因子，而影响实验因子的条件叫因子的状态（水平）。
b.正交实验法，比使用等价类划分、边界值分析、因果图等方法有以下优点：
节省测试工作工时；可控制生成的测试用例数量；测试用例具有一定的覆盖率。
c.正交表选择原则：
（1）每个因子水平数目相同的情况，因子数为M，水平数为N，则最佳选择一个M因子N水平的正交表，如果不存在这样的正交表，则选择K因子N水平的正交表（K>M）。
（2）如果不同因子水平数目不相同，选择出现次数最多的水平数（相同的话选择大的）。
（3）如果所选的正交表的水平数小于因子最大的水平数。
v比如：
▪a1a2
▪b1b2b3
▪c1c2
v则把b1b2放在一起，写用例的时候再分开写。
例：
假设一个WEB站点，该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器浏览：
▪WEB浏览器：
Netscape6.2、IE6.0、Opera4.0
▪插件：
无、RealPlayer、MediaPlayer
▪应用服务器：
IIS、Apche、NetscapeEnterprise
▪操作系统：
Windows2000、WindowsNT、Linux
▪提取系统功能说明中的因子：
▪1、WEB浏览器
▪2、插件
▪3、应用服务器
▪4、操作系统
▪分析各因子的水平
▪1、WEB浏览器：
1＝Netscape6.2、2=IE6.0、3=Opera4.0
▪2、插件:
1=None、2=RealPlayer、3=MediaPlayer
▪3、应用服务器:
1=IIS、2=Apche、3=NetscapeEnterprise
▪4、操作系统:
1=Windows2000、2=WindowsNT、3=Linux
3水平4因素正交表L9（34）
*7.测试用例的评审，检查表的使用P142
好的测试用例：
测试范围的覆盖率高、测试用例设计能反向思维，有效地发现缺陷、易用性、易读性、易维护性。
测试用例的评审，可以从正、反两面进行检查。
正面测试用例要求全面，反面测试用例要有创造性。
检查表是用来帮助评审员找出评审的对象中可能的缺陷。
提高可靠性、效率。
*8.对测试套件的理解
测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。
通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来
1）按程序功能模块组织
2）按测试用例的类型组织
3）按测试用例的优先级组织
第5章
1.使用测试工具的优缺点
1）优点：
a.缩短软件开发测试周期。
对上千个测试用例来说，测试工具可以在很短时间内完成测试，而且测试工具不知劳累，可24小时不停地运行同样的测试用例10遍、100遍等。
这些都说明了软件测试工具执行测试具有速度高、效率高的特点。
b.脚本可以多次重复运行，降低成本。
在回归测试中或在很多不同的测试环境（如不同的浏览器、不同的操作系统、不同的连接条件等）下，测试工具可以多次运行同样的测试用例，而测试脚本只要开发一次。
c.可增强测试的稳定性和可靠性，通过测试工具运行测试脚本，能保证百分之百被执行，所有的测试结果都能客观地记录下来。
d.可提高软件测试的准确度和精确度，软件测试自动化的结果都是数量化的，并且它能与所预期结果或规格说明书所规定的标准进行量化对比。
2）缺点
2.手工测试和自动化测试的区别
手工测试优点：
发现缺陷效率高、容易实施、创造性，灵活性、覆盖率量化困难、重复测试效率低、不一致性，可靠性低、依赖人力资源。
缺点：
无法做到覆盖所有代码路径、很难捕捉到与时序、死锁、资源冲突、多线程等有关的错误、难以实施系统负载/性能测试和可靠性测试、难以短时间完成大量的测试用例、很难面对测试条件组合爆炸。
自动化测试优点;高效率、高复用性、覆盖率容易度量、准确，可靠、不知疲劳、激励团队士气、机械，难以发现缺陷、一次性投入大。
缺点：
不现实的期望、缺乏具有良好素质，经验的测试人才、测试工具本身的问题影响测试的质量、测试脚本的质量低劣、没有考虑公司的实际情况、没有形成一个良好的使用测试工具环境。
两者相互补充：
在系统功能逻辑测试、验收测试、适用性测试、涉及交互性测试时，多采用手工测试方法；
单元测试、集成测试、系统负载或性能、可靠性测试等比较适合采用TA；
对那种不稳定、开发周期短或一次性的软件等不适合TA
工具本身缺乏想象力和创造性，自动测试只能发现15%的缺陷，而手工测试可以发现85%的缺陷；
*3.测试工具的实现原理
1）代码分析（白盒测试自动化）
2）对象识别（）
3）捕获和回放（黑盒测试自动化）
4）脚本技术（包含数据和指令）
5）自动结果比较
4.知道几种主要的功能测试工具盒性能测试工具（不考）
第6章
*1.代码审查的具体方法P197
代码审查的方法很多，如互查（Peer-to-Peer）、走查（Walk-Through）、会议评审（Inspection）等。
2.什么是单元测试
单元测试就是对已实现的软件最小单元进行测试，以保证构成软件系统的各个单元的质量。
3.单元测试的方法
单元测试主要采用白盒测试方法，辅以黑盒测试方法。
白盒测试方法应用于代码评审、单元程序检验之中，而黑盒测试方法则应用于模块、组件等大单元的功能测试之中
4.驱动程序和桩程序
1）驱动程序（driver），对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块
2）桩程序（stub），也有人称为存根程序，对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。
示例：
5.白盒测试的具体方法（逻辑覆盖[语句覆盖和判定覆盖]、基本路径测试）
●答:
基本路径测试时程序控制流程图的基础上，通过分析控制构造的环路复杂性，导出基本可执行集合，从而设计测试用例的方法。
包含5个方面：
1程序流程图2计算程序环境的复杂性3导出测试用例4准备测试用例5图形矩阵
●逻辑覆盖：
判定覆盖条件覆盖判定----条件覆盖条件组合覆盖
语句覆盖
v要实现DoWork函数的语句覆盖，只需设计一个测试用例就可以覆盖程序中的所有可执行语句。
v只要通过路径abd就可以语句覆盖。
Ø测试用例输入为：
{x=4、y=5、z=5}
Ø程序执行的路径是：
abd
判定覆盖
v要实现DoWork函数的判定覆盖，需要设计两个测试用例
Ø测试用例的输入为：
{x=4、y=5、z=5}；{x=2、y=5、z=5}
Ø程序执行的路径分别是：
abd；ace
Ø使用acd、abe两条路径的用例也满足判定覆盖
条件覆盖
测试用例
执行路径
覆盖条件
覆盖分支
X=4,y=6,z=5
abd
T1，T2，T3，T4
bd
X=2,y=5,z=15
ace
-（T1，T2，T3，T4）
ce
v分析：
上面这组测试用例不但覆盖了4个条件的全部8种情况，而且将两个判定的4个分支b、c、d、e也同时覆盖了，即同时达到了条件覆盖和判定覆盖。
路径覆盖
测试用例
执行路径
覆盖条件
X=4,y=6,z=5
abd
T1、T2、T3、T4
X=4,y=5,z=15
acd
T1、-T2、T3、-T4
X=2,y=5,z=15
ace
-T1、-T2、-T3、-T4
X=5,y=5,z=5
abe
T1、T2、-T3、-T4
6.最少测试用例的计算
对于一般的、更为复杂的问题，估算最少测试用例个数的原则也是同样的：
1）如果在N-S图中存在有并列的层次A1、A2，A1和A2的最少测试用例个数分别为a1、a2，则由A1、A2两层所组合的N-S图对应的最少测试用例数为a1×a2。
2）如果在N-S图中不存在有并列的层次，则对应的最少测试用例数由并列的操作数决定，即N-S图中除谓词之外的操作框的个数。
7.集成测试的模式
1）渐增式集成模式与非渐增式集成模式
a.非渐增式测试模式：
先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
因为所有的模块一次集成的，所以很难确定出错的真正位置，所在的模块、错误的原因，这种方法并不推荐在任何系统中使用，适合规模较小的应用系统使用。
b.渐增式测试模式：
把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。
c.自顶向下法（Top-downIntegration）有深度优先和宽度优先
d.自底向上法：
e,混合法：
对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者结合
f.三明治集成方法：
它将自顶向下和自底向上的集成方法有机结合起来，不需要写桩程序因为在测试初自底向上集成已经验证了底层模块的正确性。
缺点：
在真正集成之前每一个独立的模块没有完全测试过
g.改善的三明治集成方法：
不仅自两头向中间集成，而且保证每个模块得到单独的测试，使得测试进行比较彻底
8.Junit的基本使用，也就是怎样对一个类写Junit测试程序
Import;
PubliccalssTextSampleextendsTestCase{}
v创建，从test需要的testcase
v书写测试方法，提供类似于如下函数签名的测试方法：
publicvoidtestXXXXX（）;
v编译，书写完testcase后，编译所写的testcase类
v运行，启动junittestrunner，来运行这个testcase。
JUnit脚本示例一：
importstatic;
import;
import;
import;
import;
publicclassTestHelloWorldextendsTestCase
{@Before
PublicvoidsetUp（）throwsException{}//初始化
PublicTestHelloworld（Stringname）{super（name）;}
@Test
Publicfinalvoidtestsay（）
{hellowordhi=newhelloworld（）;
assertEquals（“helloworld!
”,hi.say（））;}
@After
PublicvoidtearDown（）throwsException{}//撤销初始化
publicstaticvoidmain（String[]args）
{;}
}
JUnit有四个重要的类：
TestSuite、TestCase、TestResult、TestRunner。
前三个类属于Framework包，后一个类在不同的环境下是不同的。
如用的是文本测试环境，则是
▪1.TestResult，负责收集TestCase所执行的结果，它将结果分为两类，客户可预测的Failure和没有预测的Error。
同时负责将测试结果转发到TestListener（该接口由TestRunner继承）处理。
▪2.TestRunner，客户对象调用的起点，负责对整个测试流程的跟踪。
能够显示返回的测试结果，且报告测试的进度。
▪3.TestSuite，负责包装和运行所有的TestCase。
▪4.TestCase，客户测试类所要继承的类，负责测试时对客户类进行初始化，以及测试方法调用。
▪JUnit共有七个包，核心的包就是junit.framework和junit.runner。
Framework包负责整个测试对象的构架，Runner负责测试驱动。
▪另有两个重要的接口：
Test和TestListener：
▪1.Test,包含两个方法：
run（）和countTestCases（），它是对测试动作特征的提取。
▪2.TestListener，包含四个方法：
addError（）、addFailure（）、start
升级会员 