大家都日李婉姬
测试流程依次如下：
1.需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team
2.测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资源等。---testing leader or testing manager
3.用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester
4.执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员)
5.执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员)
6.defect tracking：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester
7.测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug.
8.用户体验、软件发布等……
软件测试基本理论？
软件测试概念：通过各种手段和测试工具，判断软件系统是否能够满足预期期望。
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.系统测试
E.验收测试
* 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发版测试。
* 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
* 集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
* 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
单元测试 (Unit Testing)
* 单元测试又称模块测试，是针对软件设计的最小单位 — 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1. 单元测试的内容
* 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
(1) 模块接口测试
* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：
– 调用本模块的输入参数是否正确；
– 本模块调用子模块时输入给子模块的参数是否正确；
– 全局量的定义在各模块中是否一致；
* 在做内外存交换时要考虑：
– 文件属性是否正确；
– OPEN与CLOSE语句是否正确；
– 缓冲区容量与记录长度是否匹配；
– 在进行读写操作之前是否打开了文件；
– 在结束文件处理时是否关闭了文件；
– 正文书写／输入错误，
– I／O错误是否检查并做了处理。
(2) 局部数据结构测试
* 不正确或不一致的数据类型说明
* 使用尚未赋值或尚未初始化的变量
* 错误的初始值或错误的缺省值
* 变量名拼写错或书写错
* 不一致的数据类型
* 全局数据对模块的影响
(3) 路径测试
* 选择适当的测试用例，对模块中重要的执行路径进行测试。
* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
* 对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
* 出错的描述是否难以理解
* 出错的描述是否能够对错误定位
* 显示的错误与实际的错误是否相符
* 对错误条件的处理正确与否
* 在对错误进行处理之前，错误条件是否已经引起系统的干预等
(5) 边界测试
* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。
2. 单元测试的步骤
* 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
– 驱动模块 (driver)
– 桩模块 (stub) —— 存根模块
* 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
* 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
集成测试（Integrated Testing）
* 集成测试 (集成测试、联合测试）
* 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：
– 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
– 一个模块的功能是否会对另一个模块的功能产生不利的影响；
– 各个子功能组合起来，能否达到预期要求的父功能；
– 全局数据结构是否有问题；
– 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行集成测试，
发现并排除在模块连接中可能出现
的问题，最终构成要求的软件系统。
* 子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
* 通常，把模块集成成为系统的方式有两种
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一种非增殖式组装方式。也叫做整体拼装。
* 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
2. 增殖式集成方式
* 这种集成方式又称渐增式集成
* 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
* 在集成的过程中边连接边测试，以发现连接过程中产生的问题
* 通过增殖逐步组装成为要求的软件系统。
(1) 自顶向下的增殖方式
* 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
* 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
(2) 自底向上的增殖方式
* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
* 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
* 一般来讲，一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
* 衍变的自顶向下的增殖测试
– 首先对输入／输出模块和引入新算法模块进行测试;
– 再自底向上组装成为功能相当完整且相对独立的子系统;
– 然后由主模块开始自顶向下进行增殖测试。
* 自底向上-自顶向下的增殖测试
– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试;
– 然后对含写操作的子系统做自顶向下的组装与测试。
* 回归测试
– 这种方式采取自顶向下的方式测试被修改的模块及其子模块;
– 然后将这一部分视为子系统，再自底向上测试。
关键模块问题
* 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。
* 关键模块的特征：
① 满足某些软件需求；
② 在程序的模块结构中位于较高的层次（高层控制模块）；
③ 较复杂、较易发生错误；
④ 有明确定义的性能要求。
确认测试（Validation Testing）
* 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
1. 进行有效性测试（黑盒测试）
* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
* 通过实施预定的测试计划和测试步骤，确定
– 软件的特性是否与需求相符；
– 所有的文档都是正确且便于使用；
– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试
* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
2. 软件配置复查
n 软件配置复查的目的是保证
u 软件配置的所有成分都齐全；
u 各方面的质量都符合要求；
u 具有维护阶段所必需的细节；
u 而且已经编排好分类的目录。
n 应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
验收测试（Acceptance Testing）
* 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
* 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
* 由用户参加设计测试用例，使用生产中的实际数据进行测试。
* 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
* 确认测试应交付的文档有：
– 确认测试分析报告
– 最终的用户手册和操作手册
– 项目开发总结报告。
系统测试（System Testing）
* 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
* 系统测试的目的在于通过与系统的需求定义作比较, 发现软件与系统的定义不符合或与之矛盾的地方。
软件测试的流程
一般测试流程：
1.需求分析阶段：只要就是对业务的学习，分析需求点。
2.测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。
4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。
5.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。
软件测试的测试内容
软件测试主要工作内容是验证（verification）和确认（validation），下面分别给出其概念：
验证(verification)是保证软件正确地实现了一些特定功能的一系列活动， 即保证软件以正确的方式来做了这个事件(Do it right)
1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段确立的需求的过程。
2.程序正确性的形式证明，即采用形式理论证明程序符合设计规约规定的过程。
3.评审、审查、测试、检查、审计等各类活动，或对某些项处理、服务或文件等是否和规定的需求相一致进行判断和提出报告。
确认（validation）是一系列的活动和过程，目的是想证实在一个给定的外部环境中软件的逻辑正确性。即保证软件做了你所期望的事情。（Do the right thing）
1.静态确认，不在计算机上实际执行程序，通过人工或程序分析来证明软件的正确性。
2.动态确认，通过执行程序做分析，测试程序的动态行为，以证实软件是否存在问题。
软件测试的对象不仅仅是程序测试，软件测试应该包括整个软件开发期间各个阶段所产生的文档，如需求规格说明、概要设计文档、详细设计文档，当然软件测试的主要对象还是源程序。 等价类
1.定义
是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的，常用的黑盒测试用例设计方法。
2.划分等价类
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试，因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
1)有效等价类
是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。
2)无效等价类
与有效等价类的定义恰巧相反。无效等价类指对程序的规格说明是不合理的或无意义的输入数据所构成的集合。对于具体的问题，无效等价类至少应有一个，也可能有多个。
设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。
3.划分等价类的标准
1)完备测试、避免冗余；
2)划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合；
3)并是整个集合：完备性；
4)子集互不相交：保证一种形式的无冗余性；
5)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到相同的执行路径。
4.划分等价类的方法
1)在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
如：输入值是学生成绩，范围是0～100。
2)在输入条件规定了输入值的集合或者规定了必须如何的条件的情况下，可确立一个有效等价类和一个无效等价类。
边界值
1. 定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
2. 与等价划分的区别
1) 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
2) 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。
3. 边界值分析方法的考虑：
长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
4. 常见的边界值
1) 对16-bit 的整数而言 32767 和 -32768 是边界
2) 屏幕上光标在最左上、最右下位置
3) 报表的第一行和最后一行
4) 数组元素的第一个和最后一个
5) 循环的第 0 次、第 1 次和倒数第 2 次、最后一次
5. 边界值分析
1) 边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例。
例：测试计算平方根的函数
--输入：实数
--输出：实数
--规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数时，显示错误信息平方根非法-输入值小于0并返回0；库函数Print-Line可以用来输出错误信息。 角度细分
从是否关心软件内部结构和具体实现的角度划分（按测试分类）
A.白盒测试
B.黑盒测试
C.灰盒测试
从是否执行程序的角度
A.静态测试
B.动态测试。
阶段细分
从软件开发的过程按阶段划分有
A.单元测试
B.集成测试
C.确认测试
D.系统测试
E.验收测试
F.回归测试
G.Alpha测试
H.Beta测试
* 测试过程按4个步骤进行，即单元测试、集成测试、确认测试和系统测试及发布测试。
* 开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
*集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
* 确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
* 系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
单元测试 (Unit Testing)
* 单元测试又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
* 单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
1. 单元测试的内容
* 在单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
(1) 模块接口测试
* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：
– 调用本模块的输入参数是否正确；
– 本模块调用子模块时输入给子模块的参数是否正确；
– 全局量的定义在各模块中是否一致
* 在做内外存交换时要考虑：
– 文件属性是否正确；
– OPEN与CLOSE语句是否正确；
– 缓冲区容量与记录长度是否匹配；
– 在进行读写操作之前是否打开了文件；
– 在结束文件处理时是否关闭了文件；
– 正文书写/输入错误，
– I/O错误是否检查并做了处理。
(2) 局部数据结构测试
* 不正确或不一致的数据类型说明
* 使用尚未赋值或尚未初始化的变量
* 错误的初始值或错误的缺省值
* 变量名拼写错或书写错
* 不一致的数据类型
* 全局数据对模块的影响
(3) 路径测试
* 选择适当的测试用例，对模块中重要的执行路径进行测试。
* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
* 对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
* 出错的描述是否难以理解
* 出错的描述是否能够对错误定位
* 显示的错误与实际的错误是否相符
* 对错误条件的处理正确与否
* 在对错误进行处理之前，错误条件是否已经引起系统的干预等
(5) 边界测试
* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。
2. 单元测试的步骤
* 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
– 驱动模块 (driver)
– 桩模块 (stub) ── 存根模块
* 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
* 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
集成测试（Integrated Testing）
* 集成测试 (组装测试、联合测试）
* 通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统。这时需要考虑的问题是：
– 在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
– 一个模块的功能是否会对另一个模块的功能产生不利的影响
– 各个子功能组合起来，能否达到预期要求的父功能；
– 全局数据结构是否有问题；
– 单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。
* 子系统的集成测试特别称为部件测试，它所做的工作是要找出集成后的子系统与系统需求规格说明之间的不一致。
* 通常，把模块集成成为系统的方式有两种
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一种非增殖式组装方式。也叫做整体拼装。
* 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
2. 增殖式集成方式
* 这种集成方式又称渐增式集成
* 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
* 在集成的过程中边连接边测试，以发现连接过程中产生的问题
* 通过增殖逐步组装成为要求的软件系统。
(1) 自顶向下的增殖方式
* 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
* 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
(2) 自底向上的增殖方式
* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
* 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
* 一般来讲，一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
* 衍变的自顶向下的增殖测试
– 首先对输入/输出模块和引入新算法模块进行测试；
– 再自底向上组装成为功能相当完整且相对独立的子系统；
– 然后由主模块开始自顶向下进行增殖测试。
* 自底向上-自顶向下的增殖测试
– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试；
– 然后对含写操作的子系统做自顶向下的组装与测试。
* 回归测试
– 这种方式采取自顶向下的方式测试被修改的模块及其子模块；
– 然后将这一部分视为子系统，再自底向上测试。
关键模块问题
* 在组装测试时，应当确定关键模块，对这些关键模块及早进行测试。
* 关键模块的特征：
① 满足某些软件需求
② 在程序的模块结构中位于较高的层次（高层控制模块）
③ 较复杂、较易发生错误
④ 有明确定义的性能要求。
确认测试（Validation Testing）
* 确认测试又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
* 对软件的功能和性能要求在软件需求规格说明书中已经明确规定。它包含的信息就是软件确认测试的基础。
1. 进行有效性测试（黑盒测试）
* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
* 通过实施预定的测试计划和测试步骤，确定
– 软件的特性是否与需求相符；
– 所有的文档都是正确且便于使用；
– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试
* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
2. 软件配置复查
软件配置复查的目的是保证软件配置的所有成分都齐全；
各方面的质量都符合要求；
具有维护阶段所必需的细节；
而且已经编排好分类的目录。
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
系统测试（System Testing）
* 系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
* 系统测试的目的在于通过与系统的需求定义作比较， 发现软件与系统的定义不符合或与之矛盾的地方。
验收测试（Acceptance Testing）
* 在通过了系统的有效性测试及软件配置审查之后，就应开始系统的验收测试。
* 验收测试是以用户为主的测试。软件开发人员和QA（质量保证）人员也应参加。
* 由用户参加设计测试用例，使用生产中的实际数据进行测试。
* 在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
*确认测试应交付的文档有：
– 确认测试分析报告
– 最终的用户手册和操作手册
– 项目开发总结报告。 1、制定测试计划
2、编辑测试用例
3、执行测试用例
4、发现并提交BUG
5、开发组修正BUG
6、对已修正BUG进行返测
7、修正完成的BUG将状态置为已关闭，未正确修正的BUG重新激活 单元测试
单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性，测试的对象是软件设计的最小单位：模块。
集成测试
集成测试也称联合测试，将程序模块采用适当的集成策略组装起来，对系统的接口及集成后的功能进行正确性检测的测试工作。其主要目的是检查软件单位之间的接口是否正确，集成测试的对象是已经经过单元测试的模块。
系统测试
系统测试 主要包括功能测试、界面测试、可靠性测试、易用性测试、性能测试。 功能测试主要针对包括功能可用性、功能实现程度（功能流程&业务流程、数据处理&业务数据处理）方面测试。
回归测试
回归测试指在软件维护阶段，为了检测代码修改而引入的错误所进行的测试活动。回归测试是软件维护阶段的重要工作，有研究表明，回归测试带来的耗费占软件生命周期的1/3总费用以上。
与普通的测试不同，在回归测试过程开始的时候，测试者有一个完整的测试用例集可供使用，因此，如何根据代码的修改情况对已有测试用例集进行有效的复用是回归测试研究的重要方向，此外，回归测试的研究方向还涉及自动化工具，面向对象回归测试，测试用例优先级，回归测试用例补充生成等。 V模型
测试阶段:
单元测试
集成测试
系统测试
实现意义
V模型是软件开发瀑布模型的变种，它反映了测试活动与分析和设计的关系 。
从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。
左边依次下降的是开发过程各阶段，与此相对应的是右边依次上升的部分，即各测试过程的各个阶段。
用户需求 验收测试
需求分析和系统设计 确认测试和系统测试
概要设计 集成测试
详细设计 单元测试
编码
V模型问题
1.测试是开发之后的一个阶段。
2.测试的对象就是程序本身。
3.实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
4.整个软件产品的过程质量保证完全依赖于开发人员的能力和对工作的责任心，而且上一步的结果必须是充分和正确的，如果任何一个环节出了问题，则必将严重的影响整个工程的质量和预期进度
W模型
W模型由Evolutif公司公司提出，相对于V模型，W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。 W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、设计等同样要测试，也就是说，测试与开发是同步进行的。W模型有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，这将显著减少总体测试时间，加快项目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。
H模型
H模型中， 软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行，并且可以根据被测物的不同而分层次进行。
这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程，例如设计流程或者编码流程。也就是说， 只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以进行了。
H模型揭示了一个原理：软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。H模型指出软件测试要尽早准备， 尽早执行。不同的测试活动可以是按照某个次序先后进行的，但也可能是反复的，只要某个测试达到准备就绪点，测试执行活动就可以开展。
X模型
X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。
软件测试的目标和准则是什么？有哪些测试方法？测试步骤有哪些
具体地讲，测试一般要达到下列目标：
1、确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。
产品缺少明确的书面文档，是厂商一种短期行为的表现，也是一种不负责任的表现。所谓短期行为，是指缺少明确的书面文档既不利于产品最后的顺利交付，容易与用户发生矛盾，影响厂商的声誉和将来与用户的合作关系；同时也不利于产品的后期维护，也使厂商支出超额的用户培训和技术支持费用。从长期利益看，这是很不划算的。领测认为接触过的软件产品，很少有向方正这样大大的产品、薄薄的文档。
当然，书面文档的编写和维护工作对于使用快速原型法(RAD)开发的项目是最为重要的、最为困难，也是最容易被忽略的。
最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。
2、 确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。
用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
3、 确保产品是健壮的和适应用户环境的
健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。
另外就是不能假设用户的环境(某些项目可能除外)，如：报业用户许多配置是比较低的，而且是和某些第三方产品同时使用的。
测试的原则---Good Enough
对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。
Good-enough原则就是一种权衡投入/产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的， 什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。最明显的例子就是FIT3.0中文报版的产品测试。
测试的规律----木桶原理和80-20原则
1、木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
2、 Bug的80-20原则。
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。
软件测试的方法：
1、按是否查看程序内部结构分为：
（1）黑盒测试（black-box testing）：只关心输入和输出的结果
（2）白盒测试（white-box testing）：去研究里面的源代码和程序结构
2、按是否运行程序分为：
（1）静态测试（static testing）：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档可能存在的错误的过程。
静态测试包括：
对于代码测试，主要是测试代码是否符合相应的标准和规范。
对于界面测试，主要测试软件的实际界面与需求中的说明是否相符。
对于文档测试，主要测试用户手册和需求说明是否真正符合用户的实际需求。
（5）动态测试（dynamic testing），是指实际运行被测程序，输入相应的测试数据，检查输出结果和预期结果是否相符的过程
3、按阶段划分：
（1）单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。
桩模块（stud）是指模拟被测模块所调用的模块，驱动模块（driver）是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块并输出结果。
（2）集成测试（integration testing），是单元测试的下一阶段，是指将通过测试的单元模块组装成系统或子系统，再进行测试，重点测试不同模块的接口部门。
集成测试就是用来检查各个单元模块结合到一起能否协同配合，正常运行。
（3）系统测试（system testing），指的是将整个软件系统看做一个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试的主要依据是《系统需求规格说明书》文档。
（4）验收测试（acceptance testing），指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。
验收测试又分为a测试和beta测试，其中a测试指的是由用户、 测试人员、开发人员等共同参与的内部测试，而beta测试指的是内测后的公测，即完全交给最终用户测试。
4、黑盒测试分为功能测试和性能测试：
1)功能测试（function testing），是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求。
包括逻辑功能测试（logic function testing）
界面测试（UI testing）UI=User Interface
易用性测试（usability testing）：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
兼容性测试（compatibility testing）：包括硬件兼容性测试和软件兼容性测试
2)性能测试（performance testing）
软件的性能主要有时间性能和空间性能两种
时间性能：主要指软件的一个具体事务的响应时间（respond time）。
空间性能：主要指软件运行时所消耗的系统资源。
软件性能测试分为：
一般性能测试：指的是让被测系统在正常的软硬件环境下运行，不向其施加任何压力的性能测试。
稳定性测试也叫可靠性测试（reliability testing）：是指连续运行被测系统检查系统运行时的稳定程度。
负载测试（load testing）：是指让被测系统在其能忍受的压力的极限范围之内连续运行，来测试系统的稳定性。
压力测试（stress testing）：是指持续不断的给被测系统增加压力，直到将被测系统压垮为止，用来测试系统所能承受的最大压力。(Validate the system or software can allowed the biggest stress.)
5、其他测试类型：
回归测试（regression testing）是指对软件的新的版本测试时，重复执行上一个版本测试时的用例。(When a new build or release is deployed, repeat all the test cases which has executed in the last build or release.)
冒烟测试（smoke testing），是指在对一个新版本进行大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。(validate the major function is deployed or not in software of system when a new build or release is implement.)
随机测试（random testing），是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。(means or all the test data is random, to validate the some edge bugs.)
软件测试包括的步骤：
1.制定测试计划；
2.设计测试用例、
3.实施测试（首先要搭建测试用环境）、
4.管理测试时发现的BUG、
5.测试完后（测试完，并且发现的BUG修正完）
6.要做测试报告（这样，该测试过程就算结束了，每种类型（单元测试、集成测试、系统测试、验证测试）的测试都是如此）；
软件测试的方法一共有几种
1、从是否关心内部结构来看
（1）白盒测试：又称为结构测试或逻辑驱动测试，是一种按照程序内部逻辑结构和编码结构，设计测试数据并完成测试的一种测试方法。
（2）黑盒测试：又称为数据驱动测试，把测试对象当做看不见的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性，它是站在使用软件或程序的角度，从输入数据与输出数据的对应关系出发进行的测试。
（3）灰盒测试：是一种综合测试法，它将“黑盒”测试与“白盒”测试结合在一起，是基于程序运行时的外部表现又结合内部逻辑结构来设计用例，执行程序并采集路径执行信息和外部用户接口结果的测试技术。
2、从是否执行代码看
（1）静态测试：指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。
(2)动态测试：是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率、正确性和健壮性等性能指标。
3、从开发过程级别看
（1）单元测试：又称模块测试，是针对软件设计的最小单位----程序模块或功能模块，进行正确性检验的测试工作。其目的在于检验程序各模块是否存在各种差错，是否能正确地实现了其功能，满足其性能和接口要求。
(2)集成测试：又叫组装测试或联合，是单元测试的多级扩展，是在单元测试的基础上进行的一种有序测试。旨在检验软件单元之间的接口关系，以期望通过测试发现各软件单元接口之间存在的问题，最终把经过测试的单元组成符合设计要求的软件。
（3）系统测试：是为判断系统是否符合要求而对集成的软、硬件系统进行的测试活动、它是将已经集成好的软件系统，作为基于整个计算机系统的一个元素，与计算机硬件、外设、某些支持软件、人员、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
在系统测试中，对于具体的测试类型有：
（1）功能测试：对软件需求规格说明书中的功能需求逐项进行的测试，以验证功能是否满足要求。
（2）性能测试：对软件需求规格说明书的功能需求逐项进行的测试，以验证功能是否满足要求。
（3）接口测试：对软件需求规格说明中的接口需求逐项进行的测试。
（4）人机交互界面测试：对所有人机交互界面提供的操作和显示界面进行的测试，以检验是否满足用户的需求。
（5）强度测试：强制软件运行在异常乃至发生故障的情况下（设计的极限状态到超出极限），验证软件可以运行到何种程序的测试。
（6）余量测试：对软件是否达到规格说明中要求的余量的测试。
（7）安全性测试：检验软件中已存在的安全性、安全保密性措施是否有效的测试，
（8）可靠性测试：在真实的或仿真的环境中，为做出软件可靠性估计而对软件进行的功能（其输入覆盖和环境覆盖一般大于普通的功能测试）
（9）恢复性测试：对有恢复或重置功能的软件的每一类导致恢复或重置的情况，逐一进行的测试。
（10）边界测试：对软件处在边界或端点情况下运行状态的测试。
（11）数据处理测试：对完成专门数据处理功能所进行的测试。
（12）安装性测试：对安装过程是否符合安装规程的测试，以发现安装过程中的错误。
（13）容量测试：检验软件的能力最高能达到什么程度的测试。
（14）互操作性测试：为验证不同软件之间的互操作能力而进行的测试。
（15）敏感性测试：为发现在有效输入类中可能引起某种不稳定性或不正常处理的某些数据的组合而进行的测试。
（16）标准符合性测试：验证软件与相关国家标准或规范（如军用标准、国家标准、行业标准及国际标准）一致性的测试。
（17）兼容性测试：验证软件在规定条件下与若干个实体共同使用或实现数据格式转换时能满足有关要求能力的测试。
（18）中文本地化测试：验证软件在不降低原有能力的条件下，处理中文能力的测试。
4、从执行过程是否需要人工干预来看
（1）手工测试：就是测试人员按照事先为覆盖被测软件需求而编写的测试用例，根据测试大纲中所描述的测试步骤和方法，手工地一个一个地输 入执行，包括与被测软件进行交互（如输入测试数据、记录测试结果等），然后观察测试结果，看被测程序是否存在问题，或在执行过程中是否会有一场发生，属于比较原始但是必须执行的一个步骤。
（2）自动化测试：实际上是将大量的重复性的测试工作交给计算机去完成，通常是使用自动化测试工具来模拟手动测试步骤，执行用某种程序设计语言编写的过程（全自动测试就是指在自动测试过程中，不需要人工干预，由程序自动完成测试的全过程；半自动测试就是指在自动测试过程中，需要手动输入测试用例或选择测试路径，再由自动测试程序按照人工指定的要求完成自动测试）
5、从测试实施组织看
（1）开发测试：开发人员进行的测试
（2）用户测试：用户方进行的测试
（3）第三方测试：有别于开发人员或用户进行的测试，由专业的第三方承担的测试，目的是为了保证测试工作的客观性
6、从测试所处的环境看
（1）阿尔法测试：是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的测试
（2）贝塔测试：是用户公司组织各方面的典型终端用户在日常工作中实际使用贝塔版本，并要求用户报告
扩展资料
软件测试的内容：
1 得到需求、功能设计、内部设计说书和其他必要的文档
2 得到预算和进度要求
3 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 ( 例如发行过程、变更过程、等等 )
4 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
5 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
6 确定对测试环境的要求 ( 硬件、软件、通信等 )
7 确定所需的测试用具 (testware) ，包括记录 / 回放工具、覆盖分析、测试跟踪、问题 / 错误跟踪、等等
8 确定对测试的输入数据的要求
9 分配任务和任务负责人，以及所需的劳动力
10 设立大致的时间表、期限、和里程碑
11 确定输入环境的类别、边界值分析、错误类别
12 准备测试计划文件和对计划进行必要的回顾
13 准备白盒测试案例
14 对测试案例进行必要的回顾 / 调查 / 计划
15 准备测试环境和测试用具，得到必需的用户手册 / 参考文件 / 结构指南 / 安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
16 得到并安装软件版本
17 进行测试
18 评估和报告结果
19 跟踪问题 / 错误，并解决它
20 如果有必要，重新进行测试
21 在整个生命周期里维护和修改测试计划、测试案例、测试环境、和测试用具
参考资料：百度百科-软件测试
什么是测试用例和测试规程，设计一个测试用例应当从哪几方面考虑
什么是测试用例和测试规程，设计一个测试用例应当从哪几方面考虑
测试用例的设计需要从很多角度考虑的啊，首先你的用例来源于需求分析，那么项目或者产品是否有功能性及非功能性需求呢。比如说系统可用性需求，网络带宽需求，系统响应性能需求等等。如果存在这些需求，那么用例设计时就需要考虑这些角度。
其次功能性需求在设计用例时也需要考虑诸如大用户量并发的情况之类的。
再次，测试用例包含容错用例。
最后，测试用例编写的同时，是有等级区分的，有的用例是关键流程或者功能点，那么等级就高；有的用例很少使用，就会低。这样便于你进行回归或者重复使用。
希望对你有所帮助。
软件测试规范的输入项
其实我觉得软件测试工程师是个非常有前途的职业.现在软件测试工程师的缺口非常的大. 程序员跟测试员是相互对应的.以前国内认为只要有好的程序员就行了,其实还要有好的测试员.现在国内的软件厂商越来越注重测试员. 软件测试工程师 一提到软件测试工程师，很多人就会想到那些反复使用软件，试图在频繁操作中寻找到错误发生的低层次人员或者软件用户。其实这是一种错误的概念，软件测试早已超越了用户使用来发现Bug的基本测试阶段。 陈宏刚介绍说，微软的软件测试工程师分为三种：测试执行者（Basic Software Tester）、测试工具软件开发工程师（Software Development Engineer in Test）和高级软件测试工程师（Ad_hoc Tester） 测试执行者负责理解产品的功能要求，然后根据测试规范和测试案例对其进行测试，检查软件有没有错误，决定软件是否具有稳定性，属于最低级的执行角色。 测试工具软件开发工程师负责写测试工具代码，并利用测试工具对软件进行测试；或者开发测试工具为软件测试工程师服务。产品开发后的性能测试、提交测试等过程，都有可能要用到开发的测试工具。对技术要求最强的是这些人，因为它们要具备写程序的技术。“因为不同产品的特性不一样，对测试工具要求也是不同的，就像Windows的测试工具不能用于Office，office的也不能用于SQLserver，微软很多测试工程师就是负责专门为某个产品写测试程序的。”而Ad_hoc Testet属于比较有经验，自己会找方向并做的很好的测试工程师，这要求具有很强的创造性。刚进入微软时，老板也是只给陈宏刚一个操作流程，每天就按照这个规程去做，几天下来，一个Bug都没有发现。陈宏刚也很沮丧，觉得这样挺对不起公司，后来自己问自己：为什么非要这样做！于是换了其他的方法试试，令他吃惊的是，一下就找到很多严重的Bug，当时也不敢声张。有一天，他找到10多个非常严重的Bug，开发经理一下就惊呆了，怒冲冲的跑到陈宏刚面前问：“你是不是改变了测试方式和测试步骤？”陈宏刚有些吓住，说道：“可能改变了一点。”对方说：“我非常生气，但我不是生你的气，而是因为以前测试人员水平太差，或者以前的测试方面有问题，软件中有些Bug存在了半年甚至一年，但直到现在才发现，现在修补这些错误要困难很多！”后来陈宏刚得到了老板的赞许，可以按照自己的想法去做测试。对此，陈宏刚感受颇深：“一方面我体会到了微软非常鼓励创造的文化，同时也感到只遵守教条不是好的测试人员，就和用户一样了。做软件测试工程师同样需要开拓和创造性。” 在开发管理上，测试不应该归属于项目管理，也不应该归属开发人员。这三个部门应该是并驾齐驱，相互协作，测试工程师最终决定产品是否能够发布。 软件测试工程师的素质 因为软件测试仍然处在发展阶段，还没有上升到理论层次。对人员的评测，包括微软在内，都还没有一个统一标准，因此评定软件测试工程师只能根据工作实践进行自然淘汰。 软件测试对逻辑思维、学习能力、反应要求很高，是否有严密的思维和逆向思维也非常重要。陈宏刚介绍说，在五六个人的测试小组时，一半以上的Bug都是他找到的。他认为这同自己数学专业的背景关系密切，数学中有逻辑思维的培训，要善于找出来各方面的因素。比如要证明一个定理，各个方面都考虑到，一个条件不满足就无法证明；但如果证明其不成立，最常用的就是找到一个反例，只要有一点证明不成立就可以了，软件测试也是找这一点。 做测试还要考虑到所有出错的可能性，还要做一些不是按常规做的、非常奇怪的事。除了漏洞检测，测试还应该考虑性能问题，也就是要保证软件运行得很好，没有内存泄漏，不会出现运行越来越慢的情况；在不同的使用环境下，考虑软件的兼容性同样重要。软件测试同产品的规模也有很大的关系，因为软件的bug往往出在大型软件的连接处。 做软件测试工程师需要对软件抱有怀疑态度。这是因为开发人员喜欢想当然，总是找一些有利于自己程序执行的数据，有些开发人员甚至认为不利于程序执行的数据是对代码的玷污和亵渎。而软件测试却要策略性的准备各种数据，从每个细节上设计不同的应用场景，不去想当然的假定任何一个数据是可行的。 在职业素质和交际方面方面，并不是测试工程师爱挑别人毛病才好，反而这个工作要求很强的沟通能力。经常的和开发人员进行沟通，说话办事 来源: http://www.shop991.com/
转载请注明出处51数据库 » 软件测试测试规程 软件测试的流程是什么
