软件测试工程师必看的基础知识要点Word文件下载.docx
《软件测试工程师必看的基础知识要点Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件测试工程师必看的基础知识要点Word文件下载.docx（33页珍藏版）》请在冰豆网上搜索。
主码不能为空；
外码完整性：
外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。
在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。
对于数据库管理系统（DBMS），还需要进行深入的研究，以确定可以支1持测试的工具和技术。
比如，有两张表：
部门和员工。
部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；
员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。
如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。
如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：
0：
职工，1：
职员，2：
实习生。
但数据类型为Int，我们都知道Int占有4个字节，如果定义成char
（1）.就比原来节约空间。
2.白盒测试
白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。
白盒测试分为动态白盒测试和静态白盒测试
2.1静态白盒测试
利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。
比如，代码规范中规定，函数必须为动宾结构。
而黑盒测试发现一个函数定义如下：
FunctionNameGet（）{
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if（i<
0）&
（i>
=0）
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while（I>
100）{
J=J+100;
T=J*PI;
在循环体内没有I的增加,bug产生。
2.2动态白盒测试
利用开发工具中的调式工具进行测试。
比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if（I<
0）{
P1
}else{
P2
在调试中输入I=-1,P1程序段通过，P2程序段未通过，属于动态黑盒测试的缺陷
3.功能测试
功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。
这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。
此类测试基于黑盒技术，该技术通过图形用户界面（GUI）与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。
功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。
4.UI测试
UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面（UI）测试用于核实用户与软件之间的交互。
UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。
另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。
包括用户友好性，人性化，易操作性测试。
UI测试比较主观，与测试人员的喜好有关
比如：
页面基调颜色刺眼；
用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。
5.性能测试
性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
5.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
5.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。
这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。
如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。
而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。
强度测试还可用于确定测试对象能够处理的最大工作量。
一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
5.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。
做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insertcustomer往user表中插入10000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；
如果在规定的时间内显示出来，可以将用户数分别提高到20000,50000,100000进行测试。
5.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？
以便改进自己的系统，也可为产品广告提供数据。
5.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。
比如：
一台机器上即安装您的财务系统，又安装用友财务系统。
当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？
6.安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：
在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。
例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。
如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？
7.故障转移和恢复测试
故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：
对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。
在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出（I/O）故障或无效的数据库指针和关健字）。
然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。
一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？
8.配置测试
又叫兼容性测试。
配置测试核实测试对象在不同的软件和硬件配置中的运行情况。
在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。
客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。
（如浏览器版本，操作系统版本等）
软件测试V模型
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
V模型是最具有代表意义的测试模型
V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系。
从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。
左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。
用户需求验收测试
需求分析和系统设计确认测试和系统测试
概要设计集成测试
详细设计单元测试
编码
V模型问题：
1.测试是开发之后的一个阶段。
2.测试的对象就是程序本身。
3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度
W模型
由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。
W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
W模型强调：
测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。
W模型有利于尽早地全面的发现问题。
例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。
同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。
但W模型也存在局限性。
在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。
这样就无法支持迭代的开发模型。
对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
什么是开发的缺陷管理?
软件中的缺陷（Defect或BUG）是软件开发过程中的“副产品”。
通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。
每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。
可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。
软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。
狭义地讲，BUG是写程序过程中造成的错误。
广义地讲，BUG是影响客户正常使用的任何问题。
就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。
（1）缺陷管理的目标
一般而言，缺陷的跟踪和管理需要达到以下两个目标：
一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。
在谈到缺陷管理时，一般人都会只想到如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。
其实，在一个运行良好的项目开发中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。
例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。
常见的的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。
（2）缺陷管理重在预防缺陷
正如我们所知，BUG应该尽早地在开发过程中被发现。
修正处于开发阶段的BUG的成本远远低于修正处于验收阶段的BUG，而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。
因此，越晚修正BUG，需要重做的事情就越多。
对很多人来说，零缺陷的软件产品似乎是不切实际的。
因此，我们总是听到许多软件开发人员说：
“软件永远有BUG”。
软件产品含有BUG并不奇怪，不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶，这就是一件值提深思的事情了。
事实上，每个软件开发团队都可以通过一些简单的方法，在不增加额外资源的情况下预防BUG。
为了能够预防BUG，我们首先需要了解BUG的来源。
软件BUG可以分为几个类别：
第一类BUG可能是随机的，它们通常是因为一时的疏忽造成的。
尽管这些BUG可能由于其随机性很难预防。
但是，适当的分析将有助于避免这些BUG。
另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术，这类BUG共同的特点是都来自于开发人员。
但有一个好消息是，软件中的BUG往往倾向于重复出现，即使是一个随机出现的BUG。
软件BUG的不断出现不仅表现在同一个开发人员的工作上，而且表现在同一个项目上。
这当然不是说项目中的每一个开发人员都会犯同样的错误。
但是，至少其中一些的错误足以成为经常性出现的问题。
因此，BUG的预防尤为重要。
缺陷管理的核心：
缺陷分析
缺陷预防的着眼点在于缺陷的共性原因（CommonCause）。
通过寻找、分析和处理缺陷的共性原因，实现缺陷预防。
BUG预防并不是一个不切实际的目标，但是不能期望它在一夜之间发生。
我们在开发过程中应该积极为开发小组提供缺陷分析，使BUG逐渐改善。
因此，缺陷管理的最终目标是预防BUG，不断提高整个开发团队的技能和实践经验，而不只是修正它们。
BUG预防策略非常简单和容易实现，策略是发现BUG，找出BUG的根源，然后寻找一个方法来预防类似的BUG在将来出现。
这策略并不需要昂贵的花费，但是却可带来极大的额外价值。
（1）BUG记录
BUG分析的第一步是记录BUG，值得注意的是记录BUG不应该满足于记录BUG的表面症状。
测试的一个重要职责就是试图发现BUG的根本原因，在测试时不应将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。
（2）利用BUG分析了解开发质量趋势
对于测试出来的BUG进行缺陷分类，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。
缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。
这一方法不仅涉及到开发、测试人员，还涉及到不直接负责代码编写的资深开发人员。
利用这一阶段的实践成果，开发人员可以预防BUG的发生，而不仅仅是修正这些BUG。
BUG预防分析是整个BUG分析过程的核心。
这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。
由于分析结果的广泛应用性，分析某个具体BUG的投入将很容易被收回。
在这个时候，BUG分析提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。
缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。
一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升，而发现缺陷数曲线应总体趋于下降。
同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。
项目经理可通过持续观察这张图表，确保项目开发健康发展。
同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。
实际上，BUG分析图表会告诉我们很多有价值的信息。
比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。
对于异常的波动，如本来应该越测试越收敛的，却到了某个点发现的故障数反而呈上升趋势，那么意味着往往有一些特殊事件的发生。
通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。
什么是软件测试中的缺陷度量？
-------------------------------------------------------------------
缺陷度量
缺陷度量是软件度量的一部分，其本身并不能发现缺陷、剔除缺陷，但是有助于这些问题的解决。
另外，当正确、持续地进行了缺陷度量时，产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。
数据的质量等因素，我们在本章7.4节中已经考虑了，这里仍将遵循。
什么是缺陷度量
软件产品质量度量，主要集中在软件的缺陷度量上。
缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。
一般来说，在软件质量保证过程中，需要度量的缺陷数据包括6大类缺陷发现手段发现的所有缺陷。
如测试相关的缺陷，需要度量包括测试投入的工作量和成本数据、测试任务完成情况、测试规模数据、测试结果数据（包括缺陷数据、覆盖率数据）等。
（1）组织级缺陷度量，目的是了解组织的整体缺陷情况，了解客户对组织的质量满意度，建立组织基线，确定改进活动。
（2）项目级缺陷度量，目的是了解项目实时质量情况（很多项目只在最后度量，包括那些迭代式开发的项目，实际上为时已晚），预测缺陷造成的发布后维护工作量，了解客户对项目的质量满意度。
（3）个体缺陷度量，目的是了解个体缺陷产生的详细原因，并实施行动进行改进。
前两种度量大家接触较多，但第三种度量常常被忽略。
这常常导致：
●项目反复得到关于自己的质量评价，但很难了解如何去提高；
●测试组常常能做一些改进（如增加测试覆盖、延长测试周期）来提高缺陷排除效率，但开发组没有降低缺陷产生数量的有效措施；
●软件开发遵循了编码规范，但似乎对提高质量没有太多帮助。
什么是灰盒测试？
------------------------------------------------------------------
灰盒测试，确实是介于黑盒测试和白盒测试二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。
灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。
灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
软件测试用例设计综合策略
--------------------------------------------------------------------
1.Myers提出了使用各种测试方法的综合策略：
1）在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2）必要时用等价类划分方法补充一些测试用例。
3）用错误推测法再追加一些测试用例。
4）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5）如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
2.测试用例的设计步骤
1）构造根据设计规格得出的基本功能测试用例；
2）边界值测试用例；
3）状态转换测试用例；
4）错误猜测测试用例；
5）异常测试用例；
6
升级会员 