一方面，软件测试的基本概念1 .测试是软件生存周期中非常重要的过程，是产品发布并提交给最终用户之前的稳定阶段。
2 .软件测试是运行程序以发现错误的过程。 或者，软件测试是根据软件开发各阶段的规格说明和程序内部结构精心设计的小组
二、软件测试的目的1 .基于不同的立场，存在两个截然不同的测试目的。
2 .从用户的角度来看，我们希望通过软件测试暴露软件中隐藏的错误和缺陷，并考虑是否可以接受该产品。
3 .从软件开发人员的角度来看，测试是一个展示软件产品无误的过程，希望验证该软件是否正确实现了用户的要求，树立人们对软件质量的信心。
也就是说，测试的目的是以最小的时间和精力系统地确定软件中可能存在的各种错误和缺陷。
4 .测试的目标是以最小的时间和最小的工作量发现软件系统中可能存在的各种错误和缺陷。 另外，应该认识到测试只是证明程序中错误的存在，并不能证明程序中没有错误。 即使进行了最严格的测试，程序中也可能存在尚未发现的错误和缺陷，因此测试无法证明程序没有错误，但可能会检测到程序错误。
三、软件测试原则1 .早期不断进行软件测试。
2 .程序员或编程机构不得测试自己设计的程序。
3 .测试用例不仅需要输入数据，还需要相应的预期结果。
4 .测试用例的设计不仅需要合法的输入数据，还需要非法的输入数据。
5 .修改程序后进行回归测试。
6 .程序中尚未发现的错误的数量通常与在该程序中发现的错误的数量成比例。
7 .妥善维护测试计划、所有测试用例、错误统计和最终分析报告，并将它们作为软件的组成部分之一，为维护提供便利。
8 .必须全面检查各项测试结果。
9 .严格执行测试计划，排除测试随意性。 测试计划内容包括：测量的软件功能、输入和输出、测试内容、各项测试进度安排、资源要求、测试资料、测试工具、测试用例选择、测试控制方式和过程、系统组装方式、跟踪规程、调试规程、回
三、软件测试对象1 .软件测试与程序测试不同。 软件测试必须在整个软件定义和开发期间进行。
2 .需求分析、概要设计、详细设计及程序代码等各阶段得到的文件，包括需求规格说明、概要设计规格说明、详细设计规格说明及源程序，均应为软件测试对象。
四、软件测试对象1 .从测试方法的角度可以分为手动测试和自动化测试。
1 )手工测试)不使用任何测试工具，根据预先设计的测试用例运行系统，测试各功能模块。
2 )测试自动化)利用测试工具编写测试脚本并输入测试数据，自动运行测试程序。
2.2种常用测试方法：黑盒测试、白盒测试
五、黑匣子测试1 .该方法将测试对象视为一个黑匣子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只根据程序的要求规格书，检查程序的功能是否符合其功能说明。
2 .黑盒测试法由于是基于被检查程序的功能进行测试，所以通常也被称为功能测试或数据驱动测试
3 .黑匣子测试方法是通过程序接口进行测试，主要是为了发现以下错误：
1 )是否有不正确或忽略的功能
2 )在界面上，输入是否正确接受？ 能输出正确的结果吗？
3 )是否存在数据结构错误或访问外部信息(如数据文件)的错误？
4 )性能上能满足要求吗？
5 )是否存在初始化或退出错误？
6 )黑盒测试发现程序中的错误，应在所有可能的输入条件和输出条件中确定测试数据，以检查程序能否生成正确的输出。但这是不可能的。
六、黑匣子测试测试用例设计1.等价类划分
等效分级是一种典型的黑匣子测试方法，使用该方法时，完全不考虑程序的内部结构，只根据程序的规格说明设计测试用例。
等价分类方法将所有可能的输入数据(即程序的输入字段)分成几个部分，从每个部分中选择少数代表性数据作为测试用例。
用这种方法设计测试用例，要经过划分等价类(列出等价类表)和选择测试用例两个阶段。
等价类是指输入字段的子集。 在该子集中，各输入数据对于暴露程序中的错误是等价的。 测试一个等价类的代表值等价于对其他值的测试。
等价类的划分有两种不同的情况：
有效等价类是指对程序规格说明合理、有意义的输入数据集合。
无效等价类是指对程序规格说明不合理、无意义的输入数据的集合。
设计测试用例时，要同时考虑有效等价类和无效等价类的设计。
2.边界值分析
1 .边界值分析也是黑匣子测试方法，是等价类划分方法的补充。
2 )长期测试工作经验表明，大量错误发生在输入或输出范围边界，而不是输入范围内部。 因此，针对各种边界情况设计测试用例，可以检测出更多的错误。
3 .例如，计算三角形时，输入三角形的三条边的长度。 是a、b、c。 这3个数值为a>； 0、b>； 0、c>； 0，
A＋B＞C、A＋C＞B、B＋C＞A，才能构成三角形。但如果把六个不等式中的任何一个大于号“＞”错写成大于等于号“≥”，那就不能构成 三角形。问题恰出现在容易被疏忽的边界附近。4.这里所说的边界是指，相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。
5.使用边界值分析方法设计测试用例，首先应确定边界情况。 应当大于等于最大值，小于等于最小值作为边界值进行测试。
3.错误推测法
1.人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。
2.错误推测法的基本想法是： 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
4,因果图
1.因果图的适用范围
1）如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。
2）因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
1.大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成。大型软件系统的测试步骤基本由以下四个步骤组成：单元测试、集成测试(组装测试)、确认测试和系统测试。
2.开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
组装测试把已测试过的模块组装起 ，主要对与设计相关的软件体系结构的构造进行测试。
3.确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
4.系统测试 把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
1.单元测试 (Unit Testing)
1）单元测试又称模块测试， 是针对软件设计的最小单位 ── 程序模块 ，进行正确性检验的测试工作。
2）其目的在于发现各模块内部可能存在的各种差错。
3）单元测试需要从程序的内部结构出发设计测试用例 。
4）多个模块可以平行地独立进行单元测试。
2.组装测试（ Integrated Testing）
1）组装测试(集成测试、联合测试）
2）通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是： 在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；
3）一个模块的功能是否会对另一个模块的功能产生不利的影响；
4）各个子功能组合起来，能否达到预期要求的父功能；
5）全局数据结构是否有问题；
6）单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
7）在单元测试的同时可进行组装测，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
3.确认测试（ Validation Testing）
1）确认测试又称有效性测试
2）任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
3）对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
4）主要由使用用户参加测试，检验软件规格说明的技术标准的符合程度，是保证软件质量的最后关键环节.
5)进行有效性测试（黑盒测试）
有效性测试是在模拟的环境(可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
通过实施预定的测试计划和测试步骤，确定
软件的特性是否与需求相符；
所有的文档都是正确且便于使用；
‹同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护 性等，也都要进行测试
在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
①测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
②测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
6)软件配置复查
软件配置复查的目的是保证：
1.软件配置的所有成分都齐全；
2.各方面的质量都符合要求；
具有维护阶段所必需的细节；
而且已经编排好分类的目录。
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
4.系统测试（System Testing）
1.系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起， 在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
2.系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
3.在系统测试实施之前，软件工程师应完成以下工作：
为测试软件系统的输入信息设计出错处理通路；设计测试用例，模拟错误数据和软件界面可能发生的错误，记录测试结果，为系统测试提供经验和帮助；参与系统测试的规划和设计，保证软件测试的合理性。
5.验收测试（ Acceptance Testing）
1.在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
2.验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
3.由用户参加设计测试用例，使用生产中的实际数据进行测试。
4.在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
5.确认测试应交付的文档有：确认测试分析报告、最终的用户手册和操作手册
、项目开发总结报告。
1.测试过程说明：
(1) 软件配置：指被测试软件的文件，如软件需求规格说明书、软件设计说明书和源程序清单等文档。
(2) 测试配置：指测试方案、测试计划、测试用例、测试驱动程序等文档。
(3) 测试工具：是为了提高测试效率而设计的支持软件测试的软件。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。
(4) 测试评价：由测试出的错误迹象，分析、找出错误的原因和位置，以便纠正和积累软件设计的经验。
(5) 纠错(调试)：是指找到出错的原因与位置并纠错，包括修正文件直到软件正确为止。纠错本身所具有的不确定性，常常难以准确地安排测试日程表。
(6) 可靠性模型：通过对测试出的软件出错率的分析，建立模型，得出可靠的数据，指导软件的设计与维护。
九、项目测试的基本流程1.项目测试启动：项目立项后，在测试配置库中创建项目。
2.测试计划：系统详细设计后，制定测试计划，准备测试资源。
3.设计测试用例，主要是与业务相关的测试用例。
4.实施功能模块测试，搭建运行或开发环境，采用功能模块测试表的方式，开发人员在功能模块测试表中更新进度状态，测试人员在该表中描述测试进度。形成测试错误列表，该表对每个错误都有相应的测试记录与之链接，在测试记录中，详细描述错误的情况。在测试记录中还要包括修正信息和验证信息。
5.错误关闭后，测试人员维护测试记录表和更新测试用例库和问题库，作为经验积累。
6.项目在结项时，测试人员进行项目完工验收测试，填写项目测试报告。该测试报告可作为用户验收的输入工件。
十、测试过程管理 十一、测试用例的设计1.在编写测试用例之前需要准备以下几个编写的依据：
①需求说明以及相关文档；
②相关的设计说明（概要设计，详细设计等）；
③与开发组交流对需求理解的记录（可以是开发人员的一个解释）；
④已经基本成型的UI（可以有针对性地补充一些用例）。
⑤编写测试用例文档应有文档模板，须符合内部的规范要求。
2.测试用例可以分为基本事件、备选事件和异常事件。
3.软件测试常用的设计测试用例的基本方法有：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，则要凭测试设计人员的丰富经验和精心设计。
4.测试用例的评审
由开发人员和测试人员共同进行评审，目的是审查编写的测试用例是否覆盖了整个项目的需求点。
5.测试用例的修改更新
6.测试用例的管理
测试管理软件的主要功能有三个：
①能将测试用例文档的关键内容；
②可供测试实施时及时输入测试情况；
③最终实现自动生成测试结果文档。