软件测试Word文件下载.docx
《软件测试Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件测试Word文件下载.docx（44页珍藏版）》请在冰豆网上搜索。
三、有哪些测试
1：
黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。
2：
白盒测试——基于应用程序的内部逻辑的知识，通过语句，分支，路径和条件的覆盖率。
3：
单元测试——测试中的最小单位，测试特殊的功能或代码模块。
由于需要对内部代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。
该测试的容易程度同代码设计的好坏直接相关。
4：
增量型的集成测试——随着新功能的增加，不断的对应用程序进行测试。
在程序的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作，这类型测试可以有开发者或测试者完成。
5：
集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。
在这里‘部分’的概念可能是代码模块，独立的应用程序，在网络上的客户端和服务器断程序，这类型测试典型的是与客户/服务器和分布式系统相关。
6：
功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。
这类型测试应当有测试人员来完成。
这并不意味着开发人员在发布版本之前就不需要检查他们的代码。
7：
端到端测试——同系统测试类似，包括模拟现实世界对一个完整的应用环境进行测试。
例如同数据库进行交互、使用网络通信，或者其他的软件、硬件和系统进行交互。
8：
理智测试——这是一种典型的原始测试，其目的是要确定一个新的软件版本在一些主要的测试努力下表现的足够好并且可以接受。
例如：
如果一个新软件每五分钟当机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理智’状态，必须保证在当前状态下进行进一步测试。
9：
回归测试——在软件或环境被修改后进行的再测试。
可能很难确定我们需要进行多少的再测试，尤其接近到开发过程的末期。
自动测试工具可能会有很大的帮助。
10：
可接受性测试——基于最终用户的规格进行的最后测试。
或者基于最终用户在一定的时间范围内的测试。
11：
负荷测试——在高负荷条件下进行的测试。
12：
压力测试——该术语通常同负荷测试和性能测试是可交换的。
也可用于描述这样一些测试，如：
在不正常的负荷状态下，过分的重复某些动作或输入情况下进行的系统功能测试。
13：
性能测试——该术语通常同负荷测试和压力测试是可交换的。
理想的性能测试是定义在需求文档或QA测试计划中的。
14：
安装和反安装测试——测试完全、部分或升级的安装/反安装过程
15：
恢复测试——测试当出现崩溃，硬件错误或其他灾难性问题时，系统的表现情况
16：
安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。
可能需要复杂的测试技术。
17：
兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。
18：
ALPHA测试——在开发进行结束的时候进行的测试。
针对测试的结果可能还会进行一些小的设计更改。
这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。
19：
BETA测试——在开发和测试已经全部结束后，并且在最终版本发布之前进行的
测试。
α测试（alpha测试）：
在开发小组内部进行，测试的方法也较多，黑盒、白盒、压力、应力等等；
β 测试（beta测试）：
有选择地请一些最终用户实际使用，将发现的问题反馈回来再进行修改。
四，开发和执行软件测试需要哪些步骤
1、获取需求、功能设计、详细设计规格和其它必须文档
2、获取预算和时间安排需求
3、确定项目相关人员和他们的责任，汇报需求，必须的标准和过程（如版本过程、变更过程等）。
4、确认应用高风险的部分，设定优先级，确定测试的范围和限制
5、确定测试的方法——单元测试、集成测试、功能测试、负荷测试、可用性测试等
6、确定环境需求（软件/硬件/通信等）
7、确定测试用具环境（记录/回放工具、覆盖率分析器、测试跟踪、问题跟踪等等）
8、确定测试输入需求
9、确定任务，任务责任和相应的工作量
10、设定时间安排估计、时间表、里程碑等
11、确定输入的等价类、边界值分析、错误类
12、准备测试计划文档和需要的评审
13、写测试用例
14、对测试用例进行必须的评审
15、准备测试环境和测试用具，获取需要的用户手册/参考文档/配置指导/安装指导，建立跟踪过程，日志和存档过程，获取测试数据
16、获取和安装软件版本
17、执行测试
18、评价和汇报测试结果
19、跟踪问题和修改
20、如果需要进行再测试
21、在整个生命周期内维护和修改测试计划、测试用例、测试环境和测试用具
五、什么是测试计划
测试计划是描述软件测试努力的目标、范围、方法和焦点的文档。
准备测试计划的过程是完整考虑软件产品可接受评价努力的一个有用的方法。
完整的文档将有助于测试组之外的人理解为什么要进行软件正确性检测，并且如何进行检测。
测试计划应当足够完整但也不应当太详尽，以致在测试组之外没有人会读它。
六、什么是测试用例
1、一个测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
一个测试用例应当有完整的信息，如：
测试用例ID号，测试用例名字，测试用例的目的，测试条件、输入数据需求、步骤和期望结果。
2、注意开发测试用例的过程有助于在应用的需求和设计中发现问题。
这主要是由于是需要完整的考虑应用的整个操作。
正因为这样，需要在开发的早期准备测试用例。
七，制定测试计划的时候应该考虑哪些因素：
应明确的在测试计划中确立好“测试管理机制”的关键事件,如:
1>
.汇报机制确定好用周报制度还是日报制度，日报的反馈速度快，定位解决问题快,但信息处理工作量大;
2>
.例会制度,每周举行一次例会，根据实际情况，考虑测试计划的调整或滚动;
3>
.实施怎样的实验室管理制度，以做到责任明确;
4>
.在日报中的工作汇报：
不仅是发现的问题，还应包括在测试时新创造的测试点，这些测试点应该补充到测试计划中作为一个测试项。
5>
.人员情绪如何调整，在测试周期过长时，影响测试效率的一个重要因素是测试人员的情绪，一个人反复测试一个模块，总是会出现厌倦情绪的。
具体怎么调整？
是一个有待讨论的问题。
应明确的在测试计划中确立“数据”的管理和分析体系和办法,如:
专人对提交的过程文档,周报报告中的数据予以整理和管理，以便后期在系统测试评审时作为数据来分析。
现在往往是在系统测试结束后才来收集数据，可能会造成数据的不同程度失真或滞后。
收集的数据可以按不同种类来划分。
这可以依赖我们系统CHECKLIST。
有一种工具叫SRES（软件可靠性专家系统）还是很有用的，我们可以按照它的输入数据来收集。
应明确的在测试计划中确立“风险估计”的引入,如:
制定测试计划时,就应该考虑好对系统测试工作量的估计，测试成本的估计,版本市场定位的估计等等,并且必要时可根据实际情况进行裁剪或补充。
七、一些测试方法
1、划分等价类
把所有可能的输入数据划分成若干部分，然后从每一部分中选择少数有代表性的数据作为测试用例。
（1）有效等价类：
对于程序的规格说明来说，是合理、有意义的输入数据构成的集合。
利用这一类测试用例检验程序是否实现了规格说明预先规定的功能和性能。
（2）无效等价类：
对于程序的规格说明来说，是不合理、无意义的输入数据构成集合。
利用这一类测试用例检验程序的冗错能力。
2、边界值分析
边界值分析方法是对等价类划分方法的补充。
根据测试经验，大量的错误发生在输入
或输出范围的边界上，而不是某个范围的内部。
与等价类划分方法的区别：
边界值也可能包含在有效等价类中。
3、语句覆盖
设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次。
语句覆盖
是最弱的逻辑覆盖准则。
IF（（A>
1）AND（B=0））THEN
X=X/A
IF（（A=2）OR（X>
1）THEN
X=X+1
其中“AND”和“OR”是两个逻辑运算符。
图6给出了它的流程图。
a、b、c、d和e是控制流上的若干程序点。
语句覆盖的含意是，在测试时，首先设计若干个测试用例，然后运行被测程序，使程序中的每个可执行语句至少执行一次。
这时所谓“若干个”，自然是越少越好。
在上述程序段中，我们如果选用的测试用例是：
则程序按路径ace执行。
这样该程序段的4个语句均得到执行，从而作到了语句覆盖。
但如果选用的测试用例是：
程序按路径abe执行，便未能达到语句覆盖。
从程序中每个语句都得到执行这一点来看，语句覆盖的方法似乎能够比较全面地检验每一个语句。
但它也绝不是完美无缺的。
假如这一程序段中两个判断的逻辑运算有问题，例如，第一个判断的运算符“AND”错成运算符“OR”或是第二个判断中的运算符“OR”错成了运算符“AND”。
这时仍使用上述前一个测试用例CASE1，程序仍将按路径ace执行。
这说明虽然也作到了语句覆盖，却发现不了判断中逻辑运算的错误。
二、判定覆盖
按判定覆盖准则进行测试是指，设计若干测试用例，运行被侧程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断的真假值均曾被满足。
判定覆盖又称为分支覆盖。
仍以上述程序段为例，若选用的两组测试用例是：
我们注意到，上述两组测试用例不仅满足了判定覆盖，同时还做到语句覆盖。
从这一点看似乎判定覆盖比语句覆盖更强一些，但让我们设想，在此程序段中的第2个判断条件X>
1如果错写成X<
1，使用上述测试用例CASE5，照样能按原路径执行（abe），而不影响结果。
这个事实说明，只作到判定覆盖仍无法确定判断内部条件的错误。
因此，需要有更强的逻辑覆盖准则去检验判断内的条件。
以上仅考虑了两出口的判断，我们还应把判定覆盖准则扩充到多出口判断（如CASE语句）的情况。
三、条件覆盖
条件覆盖是指，设计若干测试用例，执行被测程序以后，要使每个判断中每个条件的可能取值至少满足一次。
在上述程序段中，第一个判断应考虑到：
A＞1，取真值，记为T1
A＞1，取假值，即A≤1，记为F1
B=0，取真值，记为T2
B=0，取假值，即B≠0，记为F2
第2个判断应考虑到：
A=2，取真值，记为T3
A=2，取假值，即A≠2，记为F3
X＞1，取真值，记为T4
X＞1，取假值，即X≤1，记为F4
我们给出3个测试用例：
CASE6，CASE7，CASE8，执行该程序段所走路径及覆盖条件是：
从这个表中可以看到，3个测试用例把4个条件的8种情况均作了覆盖。
进一步分析上表，覆盖了4个条件的8种情况的同时，把两个判断的4个分支b、c、d和e似乎也被覆盖。
这样我们是否可以说，做到了条件覆盖，也就必然实现了判定覆盖呢？
让我们来分析另一情况，假定选用两组测试用例是CASE9和CASE8，执行程序段的覆盖情况是：
这一覆盖情况表明，覆盖了条件的测试用例不一定覆盖了分支。
事实上，它只覆盖了4个分支中的两个。
为解决这一矛盾，需要对条件和分支兼顾。
四、判定-条件覆盖
判定-条件覆盖要求设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。
例中两个判断各包含两个条件，这4个条件在两个判断中可能有8种组合，它们是：
①A〉1，B＝0记为T1，T2
②A〉1，B≠0记为T1，F2
③A≤1，B＝0记为F1，T2
④A≤1，B≠0记为F1，F2
⑤A＝2，X〉1记为T3，T4
⑥A＝2，X≤1记为T3，F4
⑦A≠2，X〉1记为F3，T4
⑧A≠2，X≤1记为F3，F4
这里设计了4个测试用例，用以覆盖上述8种条件组合：
我们注意到，这一程序段共有四条路径。
以上4个测试用例固然覆盖了条件组合，同时也覆盖了4个分支，但仅覆盖了3条路径，却漏掉了路径acd。
前面讨论的多种覆盖准则，有的虽提到了所走路径问题，但尚未涉及到路径的覆盖，而路径能否全面覆盖在软件测试中是个重要问题，因为程序要取得正确的结果，就必须消除遇到的各种障碍，沿着特定的路径顺利执行。
如果程序中的每一条路径都得到考验，才能说程序受到了全面检验。
五、路径覆盖
按路径覆盖要求进行测试是指，设计足够多测试用例，要求覆盖程序中所有可能的路径。
针对例中的4条可能路径：
ace记为L1，abd记为L2，abe记为L3，acd记为L4，
我们给出4个测试用例：
CASE1，CASE7，CASE8和CASE11，使其分别覆盖这4条径：
这里所用的程序段非常简短，也只有4条路径。
但在实际问题中，一个不太复杂的程序，其路径数都是一个庞大的数字，要在测试中覆盖这样多的路径是无法实现的。
为解决这一难题只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行了一次。
其实，即使对于路径数很有限的程序已经作到了路径覆盖，仍然不能保证被测程序的正确性。
例如，在上述语句覆盖一段最后给出的程序段中出现的错误也不是路径覆盖可以发现的。
由此看出，各种结构测试方法都不能保证程序的正确性。
这一严酷的事实对热心测试的程序人员似乎是一个严重的打击。
但要记住，测试的目的并非要证明程序的正确性，而是要尽可能找出程序中的错误。
确实并不存在一种十全十美的测试方法，能够发现所有的错误。
想要撒下几网把湖中的鱼全都捕上来是作不到的，软件测试是有局限性的。
软件测试的内容：
测试贯穿于整个软件的生命周期中，在开发的不同阶段，软件测试的内容也是不同的，包过文档，源代码，数据等信息。
软件测试的目的：
是想以最少的人力，物力和时间找出软件中潜在的各种错误和缺陷。
通过修正各种错误和缺陷提高软件的质量，回避软件发布后由于潜在的软件缺陷造成的隐患和商业风险。
软件测试的分类：
按开发阶段来分：
单元测试，集成测试，系统测试，验收测试。
按测试的实施单位来分：
开发方测试，用户测试，第三方测试。
按测试技术来分：
白盒测试，黑盒测试，灰盒测试。
八、软件测试模型
V模型
W模型：
在V模型的基础上，演变出来的W模型
h型模型
X型模型
软件测试的生命周期：
一般包括7个阶段，1）计划，2）分析，3）设计，4）构建，5）测试周期，6）最后测试和实施，7）实施后。
九、白盒测试方法
白盒测试方法包括动态和静态。
静态包括：
代码检查，静态结构分析，代码质量度量等。
代码检查又包括：
代码走查，桌面检查，代码审查。
代码走查与检查都要求一个小组的人员来阅读或直观检查特定的程序。
经常采用头脑风暴.
注意一点：
头脑风暴，是测试，非调试。
头脑风暴的程序：
准备阶段
确立问题，提前一周通知给参加人员，以便有独立思考的时间。
头脑风暴
主持人简明介绍讨论问题的内容，扼要介绍各种系统的设想和方案，然后激发参加者踊跃发言，一些有价值的设想，往往可以经过“思维共振”的“头脑风暴”，通过对两个，对个设想的综合迅速发展起来。
解决问题
综合大家的意见后，进而提出最终解决问题的可行性方案。
代码走查总，3~4人一组，参加者其中之一是程序编写者，测试的工作主要是其他人。
代码走查与代码检查是对过去桌面检查过程的改进。
（桌面检查就是程序员阅读自己程序的过程）。
代码走查与检查也更高效，其优点在于一旦发现错误，就能够迅速的对其进行定位降低了调试的成本。
在于可以找到30—70%的逻辑设计与编码错误。
注意：
30~70%的错误发现率，是指已知错误的70%，而不是整体错误的70%，因为对于错误总数来说，我们永远都不知道是多少。
白盒测试的动态方法：
程序插桩测试
所谓插桩，就是借助往被测程序中插入操作，来实现测试目的的方法。
（如常常加入打印语句，看执行后的效果是否为我们希望的结果）。
白盒测试具体实施办法
代码检查：
以组为单位阅读代码，一系列规程和错误检查技术的集合。
一般这个小组成员为4个人。
其中一个人发挥着协调作用。
协调人应该是个称职的程序员，不是该程序的编码人员，不需要对程序的细节了解的很清楚。
协调人的职责包括：
Ø
为代码检查分发材料，安排进程
在代码检查中起主导作用
记录发现的所有错误
确保所有记录都得到纠正
其他成员为：
该程序的编码人员，其他的程序设计人员，一名软件测试专家（呵呵，我们的目标）
在代码检查的前几天，协调人员应该将资料下发。
所有成员应在检查前熟悉资料。
代码检查过程中进行两项活动：
有程序编码人员逐条语句讲述程序的逻辑结构（非一条条讲，主要讲逻辑结构和程序实现的方法）
对着历来的编码错误列表分析程序
代码检查的地点应该避免外部干扰，会议的时间为90~~120分钟之间。
下面给出一份代码检查中常见的错误列表：
✧数据引用错误
✧数据声明错误
✧运算错误
✧比较错误
✧控制流程错误
✧接口错误
✧输入/输出错误
✧其他检查
代码走查：
与代码检查很相似，大师规程略有不同，采用的错误检查技术也不同。
代码走查也是采用持续的不间断的会议形式。
小组成员由3-5人组成。
一个扮演协调人，一个人担当秘书（记录检查出来的错误），一名测试人员，建议其他的参加者是：
一位极富经验的程序员
一位程序设计语言专家
一位程序言新手
最终维护程序的人员
一位来自其他不同项目的成员
一位来自该软件编程小组的成员
走查的规程不用于检查。
代码的参与者“使用了计算机”，测试人员带来了测试用例来参加会议，把测试数据沿程序的逻辑结构走一遍。
人脑执行速度当然比较慢，因此，这些测试本身起不到关键的作用，作用只是提供了启动代码走查和质疑程序员逻辑思路极其设想的手段。
与代码检查相同，代码走查的参与者态度至关重要。
提出的建议应针对程序本身，而不是针对程序员。
同行评分：
一种依据程序的整体质量，可维护性，可扩展性，易用性和清晰性对匿名程序进行评价的技术。
该项技术的目的是为了程序员提供自我评价的手段。
覆盖测试：
包括语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，条件组合覆盖，路径覆盖。
十、黑盒测试具体实施办法
黑盒测试用例设计方法：
☯等价类划分方法
☯边界值分析方法
☯错误推测方法
☯因果图方法
☯判定表驱动分析法
☯正交试验设计方法
☯功能图分析方法
1等价类划分法：
等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分，然后从每一部分的子集选取少量具有代表性的数据作为测试用例。
可以划分为：
有效等价类，无效等价类。
划分的原则：
✓在输入条件规定的取值范围，确立一个有效等价和两个无效等价
✓在输入条件规定“必须如何”的条件下，确立一个有效等价和一个无效等价
✓输入布尔量的条件下，确立一个有效类和一个无效类
✓在输入条件规定输入数据的一组值，并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类。
✓在规定了输入数据必须遵守的规则情况下，可确立一个有效等价类和若干个无效等价类。
✓在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应在将该等价类进一步的划分为更小的等价类。
#include<
stdio.h>
stdlib.h>
voidmain（）
{
intn;
charstr[10];
scanf（"
%s"
str）;
n=atoi（str）;
printf（"
string=%s,integer=%d\n"
str,n）;
}
测试用例设计如下：
2边界值分析法：
是一种补充等价类划分的测试用例设计技术。
边界值是一种很实用的黑盒测试方法。
具有很强的发现错误的能力。
它的测试用例来源于等价类的边界值。
实践证明，大量的故障往往发生在输入定义域或输出值域的边界上，而非内部。
遵循的原则：
1）如果输入条件对取值范围进行了界定，则应以边界内部以及刚超出范围边界外的值作为测试用例。
若范围的下界为x,上界为y,则测试用例应当包含x,y，以及稍小于x和稍大于y的值。
2）如果对取值的个数进行了界定，则应当分别以最大、最小个数及稍小于最小，稍大于最大个数作为测试用例。
3）对于输出条件，前两条规则同样适应。
4）如果程序规格说明书中指明输入或者输出域是一个有序的集合，就应当选择集合中的第一个和最后一个元素作为测试用例。
如：
规定输入值范围为-1~+1,则测试用例设计为：
+1,-1,+1.01,-1.01
规定输入的记录可容纳1~255条，则测试用例设计为：
0,1,255,256。
3因果图法：
前面的输入法只考虑输入条件，没有考虑输入条件的联系。
因此，必须考虑一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。
因果图法最终生成的就是判定表，适合于检查程序输入
升级会员 