软件测试基础知识整理.doc
(13.97 KB, 下载次数: 0, 售价: 1 威望)
软件测试基础教程
测试是软件生存周期中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。
一、测试的分类：
●从测试方法的角度分为：
（1）手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。
（2）自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。
●从整体的角度分为：
（1）单元测试：是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。单元测试的依据是系统的详细设计；一般由项目组开发人员自己
完成。
（2）集成测试：在单元测试的基础上，将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。
（3）系统测试：系统测试是在所有单元、集成测试后，对系统的功能及性能的总体测试。
（4）确认测试：模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。
●从测试原理上分为：
（1）白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。
（2）黑盒测试：是通过使用整个软件或某种软件功能来严格地测试，而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时，
把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它
只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收和正确的输出。
黑盒测试方法主要有等价类划分、边界值分析、因—果图、错误推测法。
A、等价类划分：是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子
集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试
用例设计方法。
B、边界值分析：长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是
发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错
误。
C、错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的
方法。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特
殊情况，根据他们选择测试用例。例如，在单元测试时曾列出的许多在模块中常见的
错误。以前产品测试中曾经发现的错误等，这些就是经验的总结。还有，输入数据
和输出数据为0的情况。输入表格为空格或输入表格只有一行。这些都是容易发生错
误的情况。可选择这些情况下的例子作为测试用例。
（3）灰盒测试：灰盒测试就像黑盒测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。因此测试人员可以有真对性地进行某种确定的条件/功能的测试。
●从软件特性上分为功能测试和性能测试。
（1）功能测试：是指为了确保软件系统功能实现的正确性，完整性和其他特性而进行的测试。
（2）性能测试：是指为了评估软件系统的性能状况，和预测软件系统性能趋势而进行的测试和分析。
二、项目测试的规划
●项目测试分为项目开发阶段测试和项目完工验收测试两个部分。
●开发阶段测试内容主要包括：模块功能测试、集成测试和文档检查。
（1）模块功能测试：确保系统各功能模块能够正常运行，数据的IPO符合系统设计的要求。单元和模块功能满足需求定义。
（2）集成测试：系统各模块组装后，根据业务流程的要求，能够正确地完成各业务功能，并且数据的处理和输出正确。
（3）文档检查：在项目开发阶段，按照项目进度表，根据《项目文档测试规范与标准》，对提交的项目文档和记录（技术文档和管理文档）进行检查和验证，以符合公司质量体系和项目制度的要求，对于技术类文档的关键要素，验证是否能够
达到通过标准。
●完工验收测试内容主要包括：安装测试、功能验证、性能测试、需求验证、文档测试。完工验收测试实际上是项目在结项前的一
个全面的检查和验证。可以作为项目结项的依据和放行条件。
（1）安装测试：根据项目提供的安装文档中的安装步骤，搭建系统运行环境，检查系统安装过程是否正确。可能包括数据库服务器的安装与配置、应用服务器、控件注册、客户端的安装与配置、应用软件的安装。
（2）功能验证：按照需求说明书和系统概要设计，逐项检查各项功能（功能单元、功能模块）的可运行性和正确性。
（3）性能测试：这部分测试的来源，严格来讲，取决于用户对软件特性的一些特定要求，另外，就是公司的开发部门对产品的一些基本的性能要求。若用户从业务的角度考虑，对软件产品本身有特定的非功能要求，则必须在软件需求说明书中
加以说明，使之具有可度量和可测试性。对于一些多用户环境或数据处理能力和负载方面的测试，很难通过手工搭建测
试环境来测试，所以可以参考使用一些专门的性能测试工具和手工测试相结合的方式。
（4）需求测试：检查软件产品是否满足该项目的需求说明书中规定的功能需求，检查需求的完整性、一致性、最新性，该项测试重点是需求满足的完整性。
（5）文档测试：文档测试从项目立项时就开始了，实际上就是文档检查，包括规范性检查和有效性检查。目的是使项目相关的文档和记录既规范又有意义，不是为了应付的无用文件。对于技术文档如：需求说明书、概要设计、详细设计等，在
技术评审时也进行了评测。用户文档，如安装手册、用户操作手册，根据文档检查规范进行。
●项目测试的基本流程：
（1）项目测试启动：项目立项后，在测试配置库中创建项目。
（2）测试计划：系统详细设计后，制定测试计划，准备测试资源。
（3）设计测试用例，主要是与业务相关的测试用例。
（4）实施功能模块测试，搭建运行或开发环境，采用功能模块测试表的方式，开发人员在功能模块测试表中更新进度状态，测试人员在该表中描述测试进度。形成测试错误列表，该表对每个错误都有相应的测试记录与之链接，在测试记录中，
详细描述错误的情况。在测试记录中还要包括修正信息和验证信息。
（5）错误关闭后，测试人员维护测试记录表和更新测试用例库和问题库，作为经验积累。
（6）项目在结项时，测试人员进行项目完工验收测试，填写项目测试报告。该测试报告可作为用户验收的输入工件。
三、Bug管理的流程和几个重点 .
软件测试的主要目的在于发现软件存在的错误(Bug)，对于如何处理测试中发现的错误，将直接影响到测试的效果。只有正确、迅速、准确地处理这些错误，才能消除软件错误，保证要发布的软件符合需求设计的目标。在实际软件测试过程中，对于每个Bug都要经过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
错误跟踪管理系统
为了正确跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条条记录输入制定的错误跟踪管理系统。
目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件（商业软件）、 Mozilla公司的Buzilla软件（免费软件），以及国内的微创公司的BMS软件，这些软件在功能上各有特点，可以根据实际情况选用。当然，也可以自己开发缺陷跟踪软件，例如基于Notes 或是ClearQuese开发缺陷跟踪管理软件。
作为一个缺陷跟踪管理系统，需要正确设计每个错误的包含信息的字段内容和记录错误的处理信息的全部内容。字段内容可能包括测试软件名称，测试版本号，测试人名称，测试事件，测试软件和硬件配置环境，发现软件错误的类型，错误的严重等级，详细步骤，必要的附图，测试注释。处理信息包括处理者姓名，处理时间，处理步骤，错误记录的当前状态。正确的数据库权限管理是错误跟踪管理系统的重要考虑要素，一般要保证对于添加的错误不能从数据库中删除。
●软件错误的状态
第一种：
a)新信息(New)：测试中新报告的软件缺陷；
b)打开(Open)：被确认并分配给相关开发人员处理；
c)修正(Fixed)：开发人员已完成修正，等待测试人员验证；
d)拒绝(Declined)：拒绝修改缺陷；
e)延期(Deferred)：不在当前版本修复的错误，下一版修复
f)关闭(Closed)：错误已被修复；
另一种：
a)新信息(New)：测试中新报告的软件缺陷；
b)打开(Open)：被确认并分配给相关开发人员处理；
c)处理完毕提交（Resolve）
d)Activate(激活) 或REOPEN(重新打开)：如果Tester不同意该Bug的解法，则可激活。该Bug会自动被指
派给当初解决(Resolve) 的同事，当然你在激活的时候应该写上为什么你这么做，让别人明白你激活它是
由道理的。
e)关闭(Closed)：错误已被修复；
●一个Bug有7种解法：
1.By Design - 就是这么设计的，无效的Bug
2.Duplicate - 这个问题别人已经发现了，重复的Bug
3.External - 是个外部因素(比如浏览器、操作系统、其他第3方软件)造成的问题
4.Fixed - 问题被修理掉了。Tester要尽可能找到这种Bug
5.Not Repro - 无法复现你这个问题，无效的Bug
6.Postponed - 是个问题，但是目前不必修理了，推迟到以后再解
7.Won't Fix - 是个问题，但是不值得修理了，不管它吧
●Bug管理的一般流程
1.测试人员提交新的Bug入库，错误状态为New。
2.高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为
Declined状态。
3.开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解
4.对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。
5.测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为 Closed，如没有解决置状态为Reopen。
●流程虽然简单，但是在实际使用中还是发现一些问题：
1.bug信息不全：有的信息，比如项目，模块，指定处理人（也就是指派给谁处理）等，这些信息会用来作统计分析，哪个项
目，哪个模块，谁的bug多，谁发现的bug多，谁改的bug多等，根据这些信息可以大致看出一个人的工作量和工作质
量。所以不要嫌麻烦，把bug的信息写全些。
2.所提供的信息不准确：有的bug描述一带而过，表述含糊不清，只是说出现了错误，但是错误的现象是什么，提示信息是什
么，怎么操作才出现的，都不清楚，这样的bug交给开发人员，只会给开发人员增加负担，因为他自己还要再作测试，
以发现更多的信息，去排除bug，或者他会到测试那边其讨论，询问详情，有时要多次反馈才能确定到底是什么问题。
3.开发人员关闭bug：只有bug的提交人（也就是发现人）才能去关闭该bug，开发人员只能使用两个状态：“处理中”和“已
修正”
4.bug的可重现性：这个重要的属性是在bug管理软件中无法体现和度量的，这个任务主要都在测试这边，如果你发现了一
个bug，赶紧把开发人员叫过来，人家来了，你要给他看看这个bug，可是却怎么也不出现了，连自己都不知道这个bug
是怎样操作后才出现的。这样不能重现的bug几乎就不能算作bug，也是最让人头疼的问题。那么作为测试人员，你的
任务就是要尽可能的找到bug出现的规律，尝试各种可能，即使不能重现，起码也要让开发人员知道你已经作了哪些尝
试，而他不必再去走弯路。
●软件错误流程管理要点
1.为了保证错误的正确性，需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误，书写的测试步骤是否准确，
可以重复。
2.每次对错误的处理都要保留处理信息，包括处理姓名，时间，处理方法，处理意见，Bug 状态。
3.拒绝或延期错误不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
4.错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
5.加强测试人员与程序员的交流，对于某些不能重复的错误，可以请测试人员补充详细的测试步骤和方法，以及必要的测
试用例。 |
中发现Ni：
中发现Ni：
中发现Ni：
中发现Ni：
中发现Ni：
中发现Ni：
