软件测试自学笔记整理Word文件下载.docx
《软件测试自学笔记整理Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件测试自学笔记整理Word文件下载.docx（20页珍藏版）》请在冰豆网上搜索。
集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。
它的最简单的形式是：
两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。
从这一层意义上讲，组件是指多个单元的集成聚合。
在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。
方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。
最后，将构成进程的所有模块一起测试。
系统测试是将经过测试的子系统装配成一个完整系统来测试。
它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
（常见的联调测试）
系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。
验收测试是部署软件之前的最后一个测试操作。
验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。
验收测试是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样。
1.单元测试的主要目的是针对编码过程中可能存在的各种错误，例如用户输入验证过程中的边界值的错误。
2.集成测试主要目的是针对详细设计中可能存在的问题，尤其是检查各单元与其它程序部分之间的接口上可能存在的错误。
3.系统测试主要针对概要设计，检查了系统作为一个整体是否有效地得到运行，例如在产品设置中是否达到了预期的高性能
4.验收测试通常由业务专家或用户进行，以确认产品能真正符合用户业务上的需要（需求）。
单元测试：
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。
它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。
一个软件单元的正确性是相对于该单元的规约而言的。
因此，单元测试以被测试单位的规约为基准。
单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试：
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
集成测试的策略主要有自顶向下和自底向上两种。
系统测试：
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。
软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
验收测试：
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。
它的测试数据通常是系统测试的测试数据的子集。
所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。
这是软件在投入使用之前的最后测试。
回归测试：
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。
其目的是检验对软件进行的修改是否正确。
这里，修改的正确性有两重含义：
一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；
二是不影响软件的其他功能的正确性。
什么是软件测试
为了保证软件的质量和可靠性，应力求在分析、设计等各个开发阶段结束前，对软件进行严格技术评审。
但由于人们能力的局限性，审查不能发现所有的错误。
而且在编码阶段还会引进大量的错误。
这些错误和缺陷如果遗留到软件交付投入运行之时，终将会暴露出来。
但到那时，不仅改正这些错误的代价更高，而且往往造成很恶劣的后果。
软件测试就是在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。
如果给软件测试下定义，可以这样讲：
软件测试是为了发现错误而执行程序的过程。
或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入一些数据而得到其预期的结果），并利用这些测试用例去运行程序，以发现程序错误的过程。
软件测试在软件生存期中横跨两个阶段：
通常在编写出每一个模块之后就对它做必要的测试（称为单元测试）。
编码与单元测试属于软件生存期中的同一个阶段。
在结束这个阶段之后，对软件系统还要进行各种终合测试，这是软件生存期的另一个阶段，即测试阶段，通常由专门的测试人员承担这项工作。
大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40％以上，在极端情况，测试那种关系人的生命安全的软件所花费的成本，可能相当于软件工程其他开发步骤总成本的三倍到五倍。
因此，必须高度重视软件测试工作，绝不要以为写出程序之后软件开发工作就接近完成了，实际上，大约还有同样多的开发工作量需要完成。
仅就测试而言，它的目标是发现软件中的错误，但是，发现错误并不是我们的最终目的。
软件工程的根本目标是开发出高质量的完全符合用户需要的软件。
软件测试的目的
基于不同的立场，存在着两种完全不同的测试目的。
从用户的角度出发，普遍希望通过软件测试暴露出软件中陷藏的错误和缺陷，以考虑是否可以接受该产品。
而从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程，验证该软件已正确地实现了用户的要求，确立用户对软件质量的信心。
因为在程序中往往存在着许多预料不到的问题，可能会被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。
如果不把着眼点放在尽可能查找错误这样一个基础上，这些隐藏的错误和缺陷就查不出来，会遗留到运行阶段中去。
如果站在用户的角度替他们设想，就应当把测试活动的目标对准揭露程序中存在的错误。
在选取测试用例时，考虑那些易于发现程序错误的数据。
下面这些规则也可以看作是测试的目的或定义：
1.测试是为了发现程序中的错误而执行程序的过程；
2.好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
3.成功的测试是发现了至今为止尚未发现的错误的测试。
从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。
这和某些人通常想象的“测试是为了表明程序是正确的”，“成功的测试是没有发现错误的测试”等等是完全相反的。
正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。
如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；
相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。
由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。
因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。
此外，应该认识到测试决不能证明程序是正确的。
即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。
测试只能查找出程序中的错误，不能证明程序中没有错误。
返回导航
术语、名词定义
1.黑盒测试
黑盒测试也称为功能测试,它着眼于程序的外部特征,而不考虑程序的内部逻辑结构。
测试者把被测程序看成一个黑盒,不用关心程序的内部结构。
黑盒测试是在程序接口处进行测试，它只检查程序功能是否能正常使用，程序是否能接收输入数据产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。
黑盒测试是基于用户角度进行的测试。
2.白盒测试
软件测试的主要方法之一，也称结构测试、逻辑驱动测试或基于程序本身的测试。
测试者需要了解待测试程序代码的内部结构、算法等信息，这是从程序设计者的角度对程序进行的测试。
它的优点是帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。
3.灰盒测试
可以理解为静态的白盒测试或动态的黑盒测试，灰盒就是界于黑白之间,对软件内部有所了解,但不见得到了如指掌的程度,却可以结合这些了解做些比黑盒多点的测试。
4.文档测试
文档测试涵盖面很大，在软件的各个版本中均有所使用。
随着软件版本的变化，文档测试的测试内容也有所变化。
在需求分析以及原型架构阶段，文档测试主要目标是：
Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。
文档测试主要检查文档的正确性、完整性和可理解性。
正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。
完整性是指文档不可以漏掉关键性内容。
可理解性是指在文档中描述的语言要简明易懂，不能让别的开发人员拿到文档时看不懂文档的内容。
5.命名规范测试
命名规范测试用于测试项目中的文件命名、代码以及版本号等书写是否符合规范。
文件命名规范以及版本号命名规范可以参看第四部分里软件命名规范的详细信息；
各种语言的命名规范可以参考语言自身的规范，如NoahWeb的可以参考附录中的《NoahWeb各类资源命名规范》。
6.需求完整性测试
需求完整性测试主要存在于需求探索阶段，在需求尚未完全明确之前对已收集到的需求做出整理性的、检查遗漏性的测试，确认需求是否明确。
另外，需求完整性测试也承担着一部分澄清需求的任务。
7.链接完整性测试
在原型架构阶段，链接完整性的测试是非常有必要的。
该项测试任务主要是检查假页面中各种链接是否完整，是否指向目标位置，属于检查性的测试。
8.页面完整性测试
页面完整性测试主要存在于集成测试阶段以及其后续其它阶段中，测试页面是否完整，页面质量是否达标，属于检查性测试。
9.UI合理性测试
UI合理性测试也就是人机交互界面的合理性，UI合理性测试的内容很多，具体测试内容如下：
o提示、菜单、帮助的格式是否一致；
o提示、菜单、帮助中的术语是否一致；
o各个控件之间的对齐方式是否一致；
o输入界面和输出界面在外观、布局、交互方式上是否一致；
o功能类似的相关界面在外观、布局、交互方式上是否一致；
o同一层次的文字在同一种提示场合（一般情况、特殊字体、警告等）在文字大小、字体、颜色、对齐方式方面是否一致，字体大小是否与界面的大小比例协调；
o多个连续界面依次出现的情况下，界面的外观、操作方式是否一致；
o系统是否拒绝客户的错误输入并做出提示；
o系统是否在用户完成操作时给出操作成功的提示；
o用户界面是否存在空白空间，没有空白空间的界面是杂乱无章的，易用性差；
o各个控件的间隔是否一致，垂直和水平方向上是否对齐；
o是否允许动作的可逆性，返回原有操做；
10.数据和数据库完整性测试
因为在开发阶段开发人员随时都有可能根据需要来修改数据库，所以对数据和数据库完整性测试在软件项目的任何阶段也是非常必要的。
该项测试内容主要是以数据库表为单位，检查数据库表以及表中各字段命名是否符合命名规范，表中字段是否完整，数据库表中的字段描述是否正确包括字段的类型、长度、是否为空，数据库表中的关系、索引、主键、约束是否正确。
11.功能测试
功能测试在软件项目的任何阶段中都是重要的。
实现功能，满足客户需求是软件本身最大的使命。
功能测试在任何阶段下基本上都作为测试工作的第一项出现。
该项测试任务主要为了测试已实现的功能是否满足需求，是否正确，是否有价值以及是否完整。
在黑盒和白盒测试状态下，该测试均会被使用。
功能测试中测试人员往往会忽略掉一些细节问题，比如：
一个功能的实现必须要经过6步操作才能完成，而且需要加入20条信息才能看得出测试结果，有的测试人员为了节省时间虽然做完了6步操作，但是没有加入足量的信息，,使得测试不全面,正是因为这样而导致一些隐藏的BUG没有被测试出来。
所以说在功能测试中要按部就班的把所有要进行的测试功能每一步都执行一遍，应该添加的数据都添加完整，以避免遗漏掉BUG没有测试出来。
12.压力测试
压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。
这通过改变应用程序的输入以对应用程序施加越来越大的负载并测量在这些不同的输入时性能的改变来实现的。
这种操作也称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。
对应用程序进行压力测试最简单的方法是手工改变输入（客户机数量、需求大小、请求的频率、请求的混合程度等等）并描绘性能的变化。
但是如果有许多输入，或者需要在大的范围内改变输入，那么你可以借助一个自动化的压力测试工具来完成此测试。
13.安全性测试
安全性测试主要是测试系统在没有授权的内部或者外部用户对系统进行攻击或者恶意破坏时如何进行处理，是否仍能保证数据和页面的安全。
测试人员可以学习一些黑客技术，来对系统进行攻击。
另外，对操作权限的测试也包含在安全性测试中。
具体测试内容如下：
o执行添加、删除、修改等动作中是否做过登录检测。
o退出系统之后的操作是否可以完成。
o所有插入表单操作中输入特殊字符是否可以正常输正常存储，特殊字符为：
！
?
#￥%……—*（）~——-+=[]{}、|；
：
‘”？
/《》<
>
，。
o在带有参数的回显数据的动作中更改参数，把参数改为特殊字符并加入操作语句看是否出错。
o测试表单中有没有做标签检测，标签检测是否完整。
o在插入表单中加入特殊的HTML代码，例如：
<
marquee>
表单中的字本是否移动？
/marquee>
。
14.页面脚本测试
页面中时常使用到JavaScript脚本，为了降低页面的出错率，则必须对页面脚本进行测试。
其主要内容包括：
相关页面中的脚本是否正常运行，JavaScript脚本是否有错误页面。
15.提示文本测试
提示文本测试从严格意义上来讲应该属于UI合理性测试的一部分，该项测试主要针对各个页面中使用到的大量提示文档进行测试，主要包括：
表达不明确的位置是否有提示文本、提示文本的弹出是否正常、提示信息含义是否明确易懂。
16.浏览器测试
由于B/S结构项目是基于浏览器运行的，所以需要对浏览器进行必要的测试。
该测试任务主要是软件对各种浏览器（IE5.5、IE6.0、FireFox浏览器）的支持是否正常，在IE浏览器中可以正常显示的页面在其它浏览器中是否可以正常显示。
17.安装测试
在软件项目的后期阶段，会对做好的软件进行打包把软件做成安装程序，以便用户可以正确的安装使用，所以需要对做好的安装文件进行安装功能方面的测试。
该测试的主要任务是：
检查软件是否能够正常安装使用、是否可以完全卸载此软件的所有功能和页面。
18.自定义测试
在常规测试时可能表中的测试项不能满足测试要求，如果有特殊测试项请测试人员自己定义修改测试的类型。
软件命名规范
1.软件版本阶段说明
oBase版:
此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
oAlpha版:
此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
oBeta版:
该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
oRC版:
该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
oRelease版:
该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。
一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号（Ｒ）。
2.版本命名规范
软件版本号由四部分组成，第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：
base、alpha、beta、RC、release。
例如：
1.1.1.051021_beta。
版本号定修改规则：
o主版本号
（1）：
当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
o子版本号
（1）：
当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。
o阶段版本号
（1）：
一般是Bug修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。
此版本号由项目经理决定是否修改。
o日期版本号（051021）:
用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
此版本号由开发人员决定是否修改。
o希腊字母版本号（beta）:
此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。
3.文件命名规范
文件名称由四部分组成：
第一部分为项目名称，第二部分为文件的描述，第三部分为当前软件的版本号，第四部分为文件阶段标识加文件后缀，例如：
项目外包平台测试报告1.1.1.051021_beta_b.xls，此文件为项目外包平台的测试报告文档，版本号为：
如果是同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1，项目外包平台测试报告1.1.1.051021_beta_b1.xls
当有多人同时提交同一份文件时，可以在阶段标识的后面加入人名或缩写来区别，例如：
项目外包平台测试报告1.1.1.051021_beta_b_LiuQi.xls。
当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别，例如：
项目外包平台测试报告1.1.1.051021_beta_b_LiuQi2.xls
4.版本号的阶段标识
软件的每个版本中包括11个阶段，详细阶段描述如下：
阶段名称阶段标识
需求控制a设计阶段b
编码阶段c单元测试d
单元测试修改e集成测试f
集成测试修改g系统测试h
系统测试修改I验收测试j
验收测试修改k
5.测试任务描述
在软件的开发过程中每个版本都会经历四次测试任务，分别为：
单元测试、集成测试、系统测试、验收测试，在这四次测试任务中，每次测试都有不同的测试方向和重点。
1.单元测试
单元测试是软件开发过程中要进行的最基本的测试，属于白盒测试范围，一般情况下是在开发人员完成了某个单独模块的编码之后做的测试。
它的目的是检查软件编码的正确性以及一些规范性测试，站在开发人员的角度上来查找软件所存在的BUG并记录下产生BUG的原因，以便开发人员进行修改。
这样可以在很大程度上减少集成以后而出现的BUG。
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。
这在外表上看来是一项明显的进步，而象单元测试会推迟对整个系统进行合并这种真正有意思的工作启动的时间。
这种开发步骤中，真实意义上的进步被软件合并后的外表上的进步取代了。
系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。
现实的开发中，没有单元测试的软件常常会导致这样的结果，软件甚至无法运行。
更进一步的结果是大量的时间将被花费在本应该在单元测试里就完成的简单Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会延长软件集成为一个系统的时间，而且当这个系统投入使用时也无法确保它能够可靠运行。
单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试应该是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。
因此，所有的测试都必须在整个软件系统的生命周期中进行，也就是说每个版本的开发都需要经过单元测试，这样可以在以后的开发阶段减少很多不必要的麻烦。
单元测试的重点测试内容包括：
源代码测试、命名规范测试、需求完整性测试、页面完整性测试、提示文本测试、页面脚本测试等。
2.集成测试
集成测试也属于白盒测试范围，是在单元测试的基础上将软件的多个模块或者系统前后台合并之后进行的测试，也可以算是对单元测试修改进行的复审测试。
在集成测试中可以弥补单元测试中没有测试到的BUG，也可以检查出单元测试没法测试的功能，比如前后台的集成之后的关联功能，对于这些有关联性功能的测试，单元测试中是无能为力的，必须依靠集成测试来保证功能的完整性和正确性。
和系统测试相比较集成测试从程序结构出发，目的性、针对性更强，发现问题的效率高，较容易测试特殊的处理流程中存在的BUG。
集成测试的重点测试内容包括：
链接完整性测试、页面完整性测试、数据和数据库完整性测试、功能测试、压力测试、安全性测试、页面脚本测试、提示文本测试等。
3.系统测试
系统测试属于黑盒测试范围，是在系统集成测试修改完BUG之后进行的测试。
从软件工程和测试的分类来看：
集成测试在系统测试之前就必须要进行完毕，只有集成测试完成了，才能保证相应的系统测试进行。
也就是说，集成测试是系统测试的基础。
系统测试是针对整个产品的全面测试，既包含各模块的验证性测试和功能合理性测试，又包括对整个产品的可靠性、健壮性、安全性、UI合理性及各种性能参数的测试。
系统测试的重点测试内容包括：
链接完整性测试、UI合理性测试、命名规范测试、功能测试、压力测试、页面完整性测试、安装测试、提示文本测试、游览器测试等。
4.验收测试
验收测试属于黑盒测试范围，是对系统测试修改后的复审，这方面和集成测试有些类似，首先确认系统测试中的BUG已
升级会员 