测试培训资料Word格式.docx
《测试培训资料Word格式.docx》由会员分享，可在线阅读，更多相关《测试培训资料Word格式.docx（25页珍藏版）》请在冰豆网上搜索。
遗漏的功能
引发错误
规范遗漏
功能错误等
副作用和无法预测的不得当的交互特征
√
编程错误
配置/集成错误
性能不完整、实时控制失败、同步死锁、解锁等
不合适的目标
无效的算法
√
无效的编程
不可行问题
不正确的错误
异常终止
其中：
√表示有用，阴影部分表示典型的非常有效
3软件测试的基本内容
3.1安装与测试环境
测试环境要求：
根据被测系统的需求选用专用的测试环境，或结合具体系统情况搭建测试环境，使其尽量逼近真实的系统运行环境。
3.2单元测试：
（采用白盒测试方法）单元测试的主要内容是：
系统代码走查
界面、输出报表检查
功能测试
容错测试
测试过程中静态测试的分类
静态测试可以分为代码审查、代码走查和静态分析：
1、代码审查的测试内容包括：
检查代码和设计的一致性；
检查代码对标准的遵循、可读性；
检查代码的逻辑表达的正确性；
检查代码结构的合理性。
代码审查以代码审查组的方式，使用读程序和利用代码审查单的方法进行
2、代码走查是由被指定作为测试员的小组成员提供若干测试实例（程序的输入数据和期望的输出结果），让参加会议的成员充当计算机，在会议上对每个测试实例用头脑来执行程序，也就是用测试实例沿程序逻辑走一遍，并由
测试人员讲述程序执行过程，在纸上或黑板上监视程序状态（变量的值）
3、静态分析一般需使用软件工具进行。
通常包括控制流分析、数据流分析、接口分析、表达式分析。
如logiscope,testbed都是比较好用的静态分析工具。
3.2.1代码检查
●程序单位的首部应有代码说明和修改备注，内容包括编写或更改代码的人员、时间、程序的功能及调用关系等；
●变量、过程、函数等应符合软件项目组规定的统一命名规则；
●代码中不同的功能部分应有清楚的注释，较复杂的代码段落也应有注释，一般的要求是代码注释的量是代码的1/3；
●如果是修改，在修改的代码处应有修改注释，注释说明修改的人员、时间及内容。
3.2.2界面及输出报表格式检查
●用户界面、输出报表的格式以及代码的命名应符合统一的规则；
●用户界面、输出报表的字段位置、长度、类型应与设计文档的要求一致。
界面、报表的风格一致、协调。
3.2.3功能测试
●如果有多个界面，多个界面之间切换正确；
●每一个界面的功能键、触发键、按钮、菜单、选择项功能正确；
●检查数据项的关联与限制功能是否正确；
●找出设计文档中要求的未被包含在上述几项测试中的功能，逐项测试，检查是否达到设计文档要求的功能。
3.2.4功能测试的正确性判断
●有增、删、改、刷新等功能的系统，增、删、改、刷新等操作的结果正确，测试时应手工打开数据库表，以检查写/删除的效果；
●有查询或报表操作时，检查在各种选择项的合理组合下，所产生的结果，对照数据库中的数据是否正确；
对不符合条件的，应有相应的提示及相应的保护措施。
●对照设计文档的要求，测试系统所有的功能是否正确。
3.2.5容错测试
●非法键容错测试：
在不同的界面，不同的字段处输入非法键或其它空白处任意点击，被测试系统应有非法键容错能力；
●异常数据容错测试：
在不同的界面，不同的字段输入异常数据（如：
数据类型不同、非法日期等），被测试系统应有异常数据容错能力；
（如：
相应信息提示等）
●系统负作用检查：
退出被测试系统后应恢复到进入前的系统状态，不应影响其它系统的正确运行；
●残留文件检查：
退出系统后在本地机和服务器的有关目录或TEMP目录下不应留下任何无用的文件。
否则，影响系统运行的性能。
3.3集成测试：
（采用黑盒测试方法）其主要测试内容
流程测试
SQL测试
3.3.1流程测试（也叫接口测试，包括模块之间、子系统之间、小组之间等）
根据系统的需求说明书：
以实体（即具体业务处理）为对象，主要按业务的需求测试其输入、处理、输出是否满足需求，验证每个业务既符合实际工作的需要，又验证业务的处理过程是正确的，输出的结果是正确的，这里测试的内容比较多，测试大纲的内容主要体现的是该阶段的内容，测试用例主要用在该阶段。
3.3.2SQL测试
每一个c/s系统都使用SQL来访问数据库，其中有利也有弊，SQL语句使用户用很少的几条简单语句访问和操纵大量数据。
一个单独的查询语句可以选择、揉和、编组、和总结一个数据库中上百万行的数据。
它使开发者可以快速和相对容易地开发，把数据返回并显示在窗口和报表中的语句。
一个语句也可以修改一个、大量或一个数据表中全部的数据行。
如果定义了触发器或依赖关系，一个更新语句有可能影响数据库中许多其他表。
这是它的优势。
但是、所有这些潜在力量可能会付出不被理解或确认的代价。
使用SQL语言访问关系数据库时有产生大型错误的可能性。
写的不好或未被很好测试的语句很可能使一个查询产生错误的结果。
没有被充分测试的SQL语句也可能对系统的性能产生巨大的负面影响。
一个写的不好的SQL语句可能在效率上低很多很多。
3.4确认测试：
其主要测试内容是
系统性的功能测试
性能测试
多用户测试
负载测试
配置测试
安装测试
安全性测试
长时间测试
容量测试
恢复测试
2.4.1功能测试
再次抽查性的验证被测系统的各个功能点是否正确，流程是否正确
2.4.2性能测试
包括以下几点：
●界面操作效率测试：
逐项测试每一项操作，特别是增、删、改、刷新等功能、翻页、滚屏等操作，测试每项操作的响应时间是否符合设计要求或用户要求；
●报表输出及查询效率测试：
分别选择最小范围（非空）的数据及最大范围（根据实际情况定）的数据，测试产生结果的响应时间是否符合设计要求或用户要求；
●数据库压力测试；
当被测数据库具有几万、几十万条数据时，分别操作增、删、改、刷新、翻页等功能，测试每项操作的响应时间是否符合设计要求或用户要求；
●评价系统效率是否合理。
2.4.3并发测试
●随机并发测试：
在两个或以上的客户端同时多次进入和退出被测试系统，测试系统是否正确无误；
●共享并发测试：
在两个或以上的客户端同时调用被测试系统做同样的工作，测试系统是否正确无误；
●同步并发测试：
就系统中使用到的同步机构，有针对性地组织数据进行测试，如：
有关同步的命令包括对数据库表、文件的共享，互斥操作，文件系统或记录的加锁、解锁，对公共数据区域的操作等。
如：
以下均用同一用户名USER：
AAAAAA，PASSWORD：
aaaaaa登录进行测试。
1．同时登录到同一邮箱；
2．同时给用户AAAAAA发一个邮件，邮件各不相同；
3．同时添加地址，地址各不相同；
4．同时添加签名，签名各不相同；
5．同时添加过滤规则，过滤规则各不相同；
6．同时定时发信，所定时间不同；
7．同时添加POP3服务器，服务器名相同；
8．同时更改密码，密码不同；
2.4.4多用户测试
就是大批量用户对被测系统进行使用。
1．以不同用户名登录，每人向用户AAAAAA发送20封邮件（越多越好，可以随变拷一编文章发出去）；
2．每人在AAAAAA信箱中添加20个地址；
3．每人在AAAAAA信箱中添加20个过滤规则；
4．每人在AAAAAA信箱中添加20个签名；
2.4.6兼容测试
本测试的目的主要是验证被测系统在各种运行环境中将原来系统的数据移植过来后，是否能照常运行，又叫跨平台测试。
2.4.7安装测试
本测试主要检测系统的可移植性和可用性。
在系统产品化后，将产品移植到另外的机器上，检查是否能正常运行。
2.4.8恢复测试
本测试主要目的是检查系统的可恢复性。
在系统运行过程中，突然断电。
然后重新启动，查看系统是否能正常运行。
测试结果：
断电对系统的性能并不产生影响，但是由于在往服务器写东西的时候断电，对硬盘影响较大，硬盘需恢复后系统才能运行。
2.4.9安全性测试
本测试主要包括系统级和应用级的安全性测试，应用级的测试主要是被测系统的安全登陆测试。
系统级测试的主要内容是各种licenses的测试，其中包含防止黑客攻击的测试，这种测试的手段是用一个黑客软件来攻击系统，检查系统是否能防范于未然。
黑客对邮件系统一般有三种攻击方式：
1．TCP/IP网络进行攻击。
这些攻击包括序列号欺骗，路由攻击，源地址欺骗和授权欺骗。
2．在服务器预置Internettrojanhorse，来获取管理员帐号。
3．通过EMAIL炸弹来攻击邮件系统。
对第一种情况，可以用IGMP（一个指定IP的攻击工具）,SSS（一个相当优秀的服务器漏洞扫描工具）进行测试。
对第二种情况，可以使用了BOV120进行测试。
对第三种情况，可以使用Anonymai，KaBomb!
3（两个较成熟的EMAIL炸弹），攻击成功。
这种情况下的攻击只会对用户的邮件产生不良影响，对系统无影响，而且这种主动性攻击目前尚无一个十分周全的解决办法。
4软件的测试方法
4.1设计测试用例
4.1.1设计测试用例的原则
●测试用例的代表性：
能够代表各种合理和不合理的、合法的和非法的、边界和越界的,以及极限的输入数据、操作和环境设置等；
●测试结果的可判定性：
即测试执行结果的正确性是可判定的或可评估的；
●测试结果的可再现性：
即对同样的测试用例，系统的执行结果应当是相同的。
4.1.2测试用例的组成
测试用例应该由以下两部分组成
1）输入数据
2）处理（如计算、合并等）
3）预期的输出结果
这就是说，在执行系统之前应该对期望的输出有很明确的描述，这样，测试后就可将系统的输出同它仔细对照检查。
否则，如果不是先确定输出，就可能把似乎是正确而实际是错误的结果当成是正确的结果。
4.1.3设计测试用例应注意的事项
●不仅要选用合理的输入数据作为测试用例（即肯定测试用例），还应选用不合理的输入数据作为测试用例（即否定测试用例）。
许多人往往只注意前者而忽略了后者。
为了提高系统的健壮性，输入数据不合理的各种情况是应该认真检查的（在开发过程中，正常业务处理的代码量只占有效代码量的10%，而例外处理的代码量要占有效代码量的90%），所以测试工作量也是如此，即肯定测试用例占总用例的10%，否定测试用例占总用例的90%）。
●除了检查系统是否做了它应该做的工作之外，还应检查系统是否做了它不应该做的事情。
●应该长期保留所有的测试用例，直至这个系统被废弃不用为止。
设计测试用例是很费人工的，如果将用过的测试用例丢弃了，以后一旦需要再测试这个系统（例如因为系统内部作了某些修改）就需要再花很多人工，人们往往懒得再次认真地设计测试用例，因而“再测试”很少像初次测试那样“彻底”。
如果系统的修改使得前面已测试过的部分产生了错误，“再测试”往往就不能发现这些错误。
4.1.4设计测试用例（测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
）
4.1.4.1白盒法
白盒法是以系统内部的逻辑为基础设计测试用例，所以又称为逻辑覆盖法。
白盒法考虑的是测试用例对系统内部的覆盖程度，最彻底的白盒法是覆盖系统中的每条路径，但是由于系统中一般含有循环，所以路径的数目极大，要执行每条路径是不可能的，所以只能希望覆盖的程度尽可能高些。
我们可以从以下几点考虑：
（1）语句覆盖
“语句覆盖”是一个很弱的测试覆盖，它的含义是：
选择足够的测试用例，使代码中每个有效语句（即注释语句除外）至少都能被执行一次。
顺序语句覆盖率是100%。
（2）分支覆盖
比“语句覆盖”稍强的测试覆盖是“分支覆盖”。
这个标准是执行足够的测试用例，使代码中每个分支至少都获得一次“真”值和“假”值，或者说使得代码中的每个分支至少都通过一次。
分支覆盖率是80%。
（3）循环覆盖
“循环覆盖”的含义是：
执行足够的测试用例，使得循环中的每个条件都得到验证。
循环语句覆盖率是80%。
4.1.4.2黑盒法
设计测试用例的另一种方法是黑盒法。
与白盒法不同，黑盒法不关心系统内部的逻辑，而只是根据系统的功能说明、预期结果、数据流程或业务流程等来设计测试用例。
黑盒法测试的依据是需求说明书或功能说明书。
我们常常采用的方法是：
A、划分等价类
这一步是：
先从系统的需求规格说明中找出所有的输入条件，然后为每个输入条件划分两个或多个等价类，此时可以使用下表：
输入条件
合理等价类（合理输入数据）
不合理等价类（非法输入数据）
●划分等价类在很大程度上是试探性的，下面几点可供参考：
①如果某个输入条件说明了输入的范围（如“数据值”是从1到999），则可划分一个合理等价类（大于等于1而小于等于999的数）和两个不合理等价类（小于1的数，以及大于999的数）。
②如果某个输入条件说明了输入数据的个数（如每个学生可以选修1至3门课程），则可划分一个合理等价类（选修1-3门课程）和两个不合理等价类（没选修课程，以及超过3门课程）。
③如果一个输入条件说明了一个“必须成立”的情况（如标识符的第一个字符必须是字母），则可以划分一个合理等价类（第一字符是字母），和一个不合理等价类（第一字符不是字母）。
④如果某个输入条件说明了输入数据的一组可能的值，而且认为系统是用不同的方式处理每一种值的（如职称的输入值可以是助教、讲师、副教授和教授4种），则可为每一种值划分一个合理等价类（如助教、讲师、副教授和教授4种），并划分一个不合理等价类（上述4钟职称之外的等价类）。
●设计测试用例
.设计测试用例，使它包括尽可能多的、尚未被包括的合理等价类；
重复做这一步，直至这些测试用例包括所有的合理等价类。
.设计测试用例，使它包括一个（而且仅仅一个）尚未被包括的不合理等价类；
重复做这一步，直至测试用例已包括所有的不合理等价类。
必须注意的是，这一步应使每个例子仅包括一个不合理等价类。
这样做的原因是：
系统中的某些错误检测往往会抑制其它错误检测，例如某个系统的功能说明中指出：
输入数据是书的“类型”（它可以是“精装”、“平装”和“线装”）和书的“数量”（其允许值是1-999），如果某个测试用例中，书的“类型”是“活页”，书的“数量”是0，他包括了两个不合理的条件（“类型”和“数量”都不合理），系统在发现“类型”不合理之后，可能不会再去检查“数量”是否合理，因此这一部分系统实际上并没有测试到。
这里采用等价类划分法具个例子：
1.对一个输入1-100数字的输入提交功能设计测试用例
划分等价类：
其测试用例为
a.输入数字为空；
b.输入数字为0；
c.输入数字为-1；
d.输入数字为101；
e.输入数字为1-100中间的任何数；
f.输入数字为小数；
7.输入为字母；
g.输入为控制字符。
2.免费电子邮件系统：
a）新用户注册页面
数据项取值
USERNAME：
长度为3-19；
以字母开头;
非空
姓名：
密码：
确认密码：
值和密码值相同
出生年份：
年——四位数字；
月——1-12；
日——1-31；
其余项：
不要求
等价类的划分
数据项
有效等价类
无效等价类
USERNAME
（1）长3-9；
（2）以字母开头;
（1）长度<
3；
（2）非字母开头（3）长度>
19
名
（3）非空
（4）为空
码
（5）为空
认密码
（6）值和密码值不同
生年份
（6）月—1-12；
（7）日—1-31
（4）非空
余项
（8）都填（9）都不填
（5）值和密码值相同
b）.忘记密码部分
数据项取值：
登录用户名：
已存在的用户名
用户的回答：
和注册值相同
>
=5
登录用户名
1）已存在
（1）不存在
用户的回答
（2）和注册值相同
（2）和注册值不同
密码
（3）>
（3）<
5
密码确认
（4）值和密码值相同
（4）和密码值不同
B、边界值分析法
“边界情况”是指输入等价类或输出等价类边界上的情况。
边界值分析法与等价分类法的差别在于：
①边界值分析法不是从一个等价类中任选一个例子作代表，而是选一个或几个例子，使得该等价类的边界情况成为测试的主要目标。
②边界值分析不仅注意输入条件，它还根据输出的情况（即按输出等价类）设计测试用例。
运用边界值分析法，需要有一定的创造性，以下几点供使用时参考：
①如果某个输入条件说明了值范围，则可选择一些恰好取到边界的例子，另外，再编写一些代表非法输入数据的例子，它们的值恰好越过边界。
②如果一个输入条件指出了输入数据的个数，则为最小个数、最大个数、比最小个数少1、比最大个数多1、分别设计例子。
③为每个输出条件使用上面第①点。
④为每个输出条件使用上面第②点。
⑤如果系统的输入和输出是有序集合（如顺序文件、线性表等），则应特别注意集合的第一个或最后一个元素。
C、因果图法
D、错误推测法
人们也可以通过经验或直觉推测系统中可能存在的各种错误，从而有真对性地编写检查这些错误的例子，这就是错误推测法。
错误推测法没有确定的步骤，很大程度上是凭经验进行的。
4.1.5确定和描述测试方法
测试方法是对如何实施测试的说明（陈述）。
它应该说明或指出测试对象、测试时采取的主要操作以及如何核实结果等。
说明应该为读者提供足够的信息以便他们能够理解测试的对象（尽管尚不了解测试深度），如应有以下四步陈述：
∙对于每一个用例，确定并执行测试用例，包括有效和无效的输入数据。
∙对于每一个用例都将设计和开发测试流程，也就是说：
测试具体过程的描述。
∙利用某一段时间来实施测试过程。
∙如：
测试账号管理模块，通过模拟客户账号管理来实现，测试过程包括添加、修改和删除账号以及客户。
∙比如，登录系统模块，可以这样简单的做需求：
1，检查用户名
2，检查密码
至于更加详细的测试用例简略列举如下：
1，正确的操作
1，1正确的系统可以接受的用户名
1，2正确的系统可以接受的密码
2，不正确的操作
2，1登录用户名的检查
2，1，1检查非法字符
2，1，2检查长度
2，1...
2，2登录用户的密码检查
2，2，1检查密码显示为星号
2，2，2检查长度
4.1.6确定测试标准
测试标准是关于测试的客观说明，它指明那些用于确定/识别测试完成时间的值和被测试应用程序质量。
测试标准可能包括一系列说明或对其他文档（比如方法指南或测试标准等）的引用。
测试标准应确定：
∙测试对象（具体测试目标）
∙评测方法
∙评估评测方法所采用的标准
测试标准示例：
对于每一高优先级用例：
∙所有计划好的测试用例和测试过程已被执行。
∙所有确定的缺陷已被解决。
∙所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷。
在上例中，“对于每一高优先级用例”说明测试对象。
“所有计划好的测试用例和测试过程已被执行”说明评测的方法。
评估标准包含在最后两个陈述“所有确定的缺陷已被解决”和“所有计划好的测试用例和测试过程已被重新执行并且没有发现新的缺陷”之中。
4.1.7确定测试的特殊事项说明
应列出所有关于测试或者依赖关系的特殊事项，如下所示：
∙测试数据库将由操作资源恢复。
∙测试（性能）必须在办公结束后开始（不受日常的正常操作影响）并且在凌晨5:
00以前结束。
5软件测试的基本过程
升级会员 