软件测试概念

Posted 2023-04-09 sxfaidx

1.1团队构成与工作

一、项目经理

协调客户与用户之间的沟通，向各个项目组分配资源与任务

二、产品经理

根据客户产品需求进行需求设计、需求变更，并安排等工作

三、UI设计师

根据客户需求来领导和协调 Web 界面的原型设计和正式设计

四、软件开发工程师

包括：前端开发,后端开发(java,c++,php,python),服务端开发,(数据库管理 )

软件工程师负责完成设计师的设计意图， 根据设计文档编写代码； 根据设计文档编

写单元测试代码，根据测试报告 BUG 记录修改 BUG。

五、软件测试工程师

根据需求对产品设置并执行测试，根据测试提出BUG并记录。

六、实施工程师

负责软件产品安装调试和部署，完成项目相关系统工程工作，客户技术支持，编写使用手册，维护手册

七、运维工程师

负责产品上线后的运行维护工作。

1.2了解测试软件

一、什么是软件测试

使用人工操作或软件自动运行的方式来检验它是否满足规定的需求。弄清预期结果与实际结果之间差别的过程。

正确概念：

（1）测试是为了发现程序中的错误

（2）成功的测试是发现了至今为止尚未发现的错误

（3）测试并不仅仅是为了找出错误

（4） 没有发现错误的测试也是有价值的

错误概念：

（1）测试是为了证明程序没有错误

（2）软件开发完成后进行软件测试

（3）软件发布后如果发现质量问题，那是软件测试人员的错

（4）软件测试要求不高，随便找个人多都行

（5）软件测试是测试人员的事情，与程序员无关

（6）项目进度吃紧时少做些测试，时间富裕时多做测试

（7）软件测试是没有前途的工作，只有程序员才是软件高手

（8）通过测试达到零缺陷率

二、软件测试目的

把尽可能多的问题在产品交给用户之前发现并改正

确保最终交给用户的产品功能符合用户的需求

确保产品完成了所承诺或公布的功能

确保产品满足性能和效率的要求

确保产品健壮和适应用户环境

建立软件质量的信心，度量和提高被测软件的质量

三、软件测试过程

需求分析=评审=>测试计划(方案)=>测试用例=>执行测试=测试报告

四、软件测试阶段

SIT(开发阶段）内部的测试人员

UAT（验证阶段）用户验收产品-第三方测试人员

五、软件测试的原则

 

缺陷的集群性：28原则（80%的软件缺陷，聚集在20%的软件模块中）

杀虫剂悖论：相同方法重复测试，能效逐渐降低（应更换方法，使用交叉测试法）

穷尽测试是不可能的：软件的bug是无穷的，无法100%测试出来

没有失效不代表系统可用的：测试没有问题并不代表满足客户需求

六、测试人员素质具备

必备：测试计划、测试方案、编写用例、提交bug、跟踪bug，编写测试报告

测试工具的使用

操作系统

编写代码的能力

数据库知识

业务知识、网络知识

辅助：主动沟通，清晰了解掌握需求逻辑，和专业的问题反馈。

胆大心细；相信自己，自己是专业的

不被别人绑架；要有职业标准，也要有自己的态度

对一切都要有怀疑的态度

责任心；站在公司和用户的角度考虑问题。

1.3软件系统架构

一、B/S架构

（Browser/Server，浏览器/服务器模式）

Web端通过Web服物器向数据库提取数据

二、C/S架构

client/Server客户端/服务器体系结构）

客户端经过简单处理后直接向数据库提取数据

三、B/S架构和C/S架构区别

1、客户端要求： C/S客户端的计算机电脑配置要求较高。

B/S客户端的计算机电脑配置要求较低。

2、软件安装： C/S每一个客户端都必须安装和配置专用的软件。

B/S不用安装任何专门的软件，只要有一个浏览器就可以。

3、软件升级和维护 ：C/S每一个客户端都要进行升级和维护。

B/S客户端不必安装及维护。

4、安全性：C/S相比B/S较为安全

1.4软件测试分类

 

一、按是否看代码分

黑盒测试：看不见代码，不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试

白盒测试：看得见代码，知道产品内部工作过程，来测试程序结构和运行逻辑。

灰盒测试：综合测试

二、按开发阶段分

单元测试：测试组成功能的每个小模块的代码

集成测试：测试由各模块组成的功能

系统测试：对产品全面测试

验收测试：交付测试,一般由用户或第三方进行。

三、按是否运行分

静态测试：不运行软件情况下检查和审阅规范测试、软件模型测试、文档测试

动态测试：运行软件进行测试

四、按是否手动测试分

手动测试：测试过程由测试工程师人工测试完成（功能测试）

自动化测试：使用软件来控制测试执行过程（性能测试）

五、其他划分

冒烟测试：指初步地进行测试，并以此展示一些简单但足以影响软件运行的错误

随机测试：对被测软件的一些重要功能进行复测

安全测试：验证产品是否符合安全需求定义和产品质量标准的过程

探索测试：

α测试：内部人员、客户使用测试（内测）

β测试：交给最终用户测试 公司外部展开的测试（公测）

测试需求：需求分析，以软件开发为基础，形成可测试的内容。

测试计划：计划编写（人员、工具、范围的计划）。

测试设计：编写测试用例。

测试记录：对测试过程、结果和数据进行记录。

分析：风险分析。

完毕：测试完成产品交付。

测试总结：根据发现和改正BUG完成情况写出报告并提交。

1.5软件生命周期模型

一、什么是模型

模型是一种工具，它把庞大、复杂、零乱的信息通过抽象简化这样的整理，让人

更容易理解。

二、软件开发模型

1、结构化开发：通过结构化、模块化，一步一步的完成每一项开发工作的模式。

2、迭代化开发：通过对软件模块、功能的不断更新完善的迭代形式。

3、瀑布模型：类似结构化开发模式，直线式类似瀑布直流而下的逐步进行产品开发。

4、快速原型模型：根据客户需求快速实现一款样板产品供客户使用，再根据客户反馈进行完善修改。

5、螺旋模型：结合瀑布模型和快速原型模型并加入风险分析的形式。

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

6、软件开发增量模型：软件交付后逐渐增加改进功能

三。软件测试模型

1、V模型：由瀑布模型演变而来，不同阶段的测试与不同阶段的开发形成对应。

阶段步骤:需求分析、概要设计、详细设计、软件编码、单元测试、集成测试、系统测试、验收测试。

2、W模型：开发与测试同步进行，测试人员尽早进入软件测试，以减少软件开发周期并过早发现问题。

3、H模型：揭示了软件测试是一个独立的流程参与在软件开发的各个阶段。

四、敏捷开发模型

1、定义 以用户需求进化为核心、迭代、循序渐进的开发方法。

软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试。

2、原则 （1）尽早、持续交付有价值的软件来使客户满意。

（2）满足客户需求可变性。

（3）项目开发期间，业务人员和开发人员在一起工作。

（4）在团队内部，最富有效果和效率的信息传递方法是面对面交谈.

（5）团队要定期反省如何更有效地工作，并相应地调整自己的行为.

（6）好的架构、需求和设计出自于组织团队自身。

3、专有名词 （1）product Owner：简称 “PO”，产品负责人、产品经理。

职责：1、首先能够向团队清楚地传达PB的内容。

2、确保团队能够理解PB中的内容。

3、为了达到产品的目标和任务，PO对PB中的内容进行最优排序。

4、确保PB中的内容是可视化的，透明的，对任何人都是清晰的。同时要告知团 队接下来做什么。

5、优化团队工作的价值。

（2）product Backlog：简称“PB”，需求列表、待办事项。由PO管理。

（3）Scrum Master：简称“SM”，敏捷专家。

角色定义：Scrum Master是团队的导师和组织者，与Product Owner紧密合作，及时为团队成员提 供帮助。促使team按照scrum方式运行，为Scrum过程负责的人。

工作职责：1、保证团队资源合理利用；

2、保证各个角色及职责良好协作；

3、解决团队开发中的障碍；

4、作为团队和团队外部的接口，协调解决沟通中的问题；

5、保证开发过程按计划进行，组织Scrum Planning Meetings（Sprint计 划会议）

（4）Sprint（冲刺）包含计划会议、每日例会、开发工作、评审会议、回顾会议。

4、优点：（1）、迭代快，开发周期短

（2）、人与人直接交流，高效

（3）、分工详细

（4）、沟通多，容易发现问题

缺点：（1）、人与人之间的信任环节比较难完成，成员间不愿意沟通等。

（2）、团队很难持续保持激情。

5、敏捷测试：

（1）、测试人员基本素质：：代码编写（Coding）、测试 (Testing) 和分析 (Analysis)。

具有质量检测和编写代码的能力–> 测试开发

具有防止缺陷 (Quality Assurance) 和质量控制 (Quality Control) 的能力–> 质量分析员

具有开发和执行测试程序的能力 -> 软件质量工程师

（2）、测试人员主要职责：1、定义质量 (Define Quality)

2、交流缺陷（Communication）

3、及时反馈 (Feedback)

（3）、测试人员主要工作：用户故事设计和发布计划=》Sprint 周期的迭代开发和测试=》产品发布阶段。

6、 DevOPS（Development和Operations）定义：DevOps是一组过程、方法与系统的统称，用于促进开发（Development）、技术运营（Operations）和质量保障（Quality Assurance）部门之间的沟通、协作与整合。

1.6需求分析

需求分类：

1、原始需求

2、产品需求

3、软件需求 SRS（软件需求说明书）

4、测试需求

需求分析对于开发和测试的影响

1、开发：（1）如果需求不明确，系统功能研发不合理，导致软件包含大量bug

（2）大量bug修改，影响进度和团队情绪

（3）进度收到影响，可能造成公司产品失去市场先机

2、测试：（1）如果不能很好理解需求，会被开发牵着鼻子走，也会被人怀疑测试能力

（2）不能及时发现开发的bug，没法保证测试质量

1.7软件开发文档评审

1、定义：评审是对软件元素或项目状态进行评估的活动，用以确定与预期结果之间的偏差和相应的改进意见

2、测试文档评审：内部评审和现场评审

3、代码评审：（1）代码走查：是一个开发人员与架构师集中讨论代码的过程。代码走 查的目的是交换有关代码是如何书写的思路，并建立一个对代码的标准集体阐述。

（2）代码审查（Code review）：是指对计算机源代码系统化地审查。其目的是在找出及修正在软件开发初期未发现的错误，提升软 件质量及开发者的技术。

测试的基本概念

测试的基本概念
　　 测试是软件生存周期中十分重要的一个过程，是产品发布、提交给最终用户前的稳定化阶段。

 

一、 测试的分类：
　　从测试方法的角度可以分为手工测试和自动化测试。
　　手工测试：不使用任何测试工具，根据事先设计好的测试用例来运行系统，测试各功能模块。
　　自动化测试：利用测试工具，通过编写测试脚本和输入测试数据，自动运行测试程序。目前最常用的自动化测试工具是基于GUI的自动化测试工具，基本原理都是录制、回放技术。
　　从整体的角度可以分为单元测试、集成测试、系统测试、确认测试。
　　单元测试：是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。一般包括逻辑检查、结构检查、接口检查、出错处理、代码注释、输入校验、边界值检查。
　　单元测试的依据是系统的详细设计；一般由项目组开发人员自己完成。
　　集成测试：在单元测试的基础上，将所有模块按照设计要求组装进行测试。一般包括逻辑关系检查、数据关系检查、业务关系检查、模块间接口检查、外部接口检查。
　　系统测试：系统测试是在所有单元、集成测试后，对系统的功能及性能的总体测试。
　　确认测试：模拟用户运行的业务环境，运用黑盒测试方法，验证软件系统是否满足用户需求或软件需求说明书中指明的软件特性（功能、非功能）上的。
　　从测试原理上分为：白盒测试、黑盒测试和灰盒测试。
　　白盒测试：是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。
　　黑盒测试：是通过使用整个软件或某种软件功能来严格地测试, 而并没有通过检查程序的源代码或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据然后看输出的结果从而了解软件怎样工作。在测试时，把程序看作一个不能打开的黑盆子，
　　在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收和正确的输出。
　　黑盒测试方法主要有等价类划分、边界值分析、因—果图、错误推测法。
　　等价类划分：
　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
　　有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.
　　无效等价类:与有效等价类的定义恰巧相反.
　　设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.
　　边界值分析：
　　长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误。
　　错误推测法：
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例。
　　灰盒测试：
　　灰盒测试就像黑盒测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。因此测试人员可以有真对性地进行某种确定的条件/功能的测试。
　　从软件特性上分为功能测试和性能测试。
　　功能测试：是指为了确保软件系统功能实现的正确性，完整性和其他特性而进行的测试。
　　性能测试：是指为了评估软件系统的性能状况，和预测软件系统性能趋势而进行的测试和分析。

 

二、BUG的定义：
　　BUG：(小错误，缺陷，不足，过失 …) 一个计算机bug指在计算机程序中存在的一个错误（error）、缺陷（flaw）、疏忽（mistake）或者故障（fault），这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。
　　Defect：(缺陷) 在软件工程（Software Engineering）中，软件与它的需求（requirements）不一致，常常指软件无法正确完成需求所要求的功能，也称之为bug。
　　Fault：(故障)被定义为存在于组件、设备或者子系统中异常的条件或者缺陷，常常会导致系统的失败。
　　Error：(错误) 一个error是指编写错误的代码，通常是无意中造成的。一般有两类主要的错误，一是语法错误（syntax error），该类错误易于检测，因为代码在编译阶段无法解析而不能正常编译通过。另一个是逻辑错误（logical error），因为它与代码的实际执行密切相关所以不易发现。

 

三、项目测试的规划
　　项目测试内容：
　　将项目测试分为项目开发阶段测试和项目完工验收测试两个部分。
　　开发阶段测试内容主要包括：模块功能测试、集成测试和文档检查。
　　模块功能测试：确保系统各功能模块能够正常运行，数据的IPO符合系统设计的要求。单元和模块功能满足需求定义。
　　集成测试：系统各模块组装后，根据业务流程的要求，能够正确地完成各业务功能，并且数据的处理和输出正确。
　　文档检查：在项目开发阶段，按照项目进度表，根据《项目文档测试规范与标准》，对提交的项目文档和记录（技术文档和管理文档）进行检查和验证，以符合公司质量体系和项目制度的要求，对于技术类文档的关键要素，验证是否能够达到通过标准。
　　完工验收测试内容主要包括：安装测试、功能验证、性能测试、需求验证、文档测试。完工验收测试实际上是项目在结项前的一个全面的检查和验证。可以作为项目结项的依据和放行条件。
　　需求测试：检查软件产品是否满足该项目的需求说明书中规定的功能需求，检查需求的完整性、一致性、最新性，该项测试重点是需求满足的完整性。
　　安装测试：根据项目提供的安装文档中的安装步骤，搭建系统运行环境，检查系统安装过程是否正确。可能包括数据库服务器的安装与配置、应用服务器、控件注册、客户端的安装与配置、应用软件的安装。
　　功能验证：按照需求说明书和系统概要设计，逐项检查各项功能（功能单元、功能模块）的可运行性和正确性。
　　文档测试：文档测试从项目立项时就开始了，实际上就是文档检查，包括规范性检查和有效性检查。目的是使项目相关的文档和记录既规范又有意义，不是为了应付的无用文件。对于技术文档如：需求说明书、概要设计、详细设计等，在技术评审时也进行了评测。用户文档，如安装手册、用户操作手册，根据文档检查规范进行。
　　性能测试：这部分测试的来源，严格来讲，取决于用户对软件特性的一些特定要求，另外，就是公司的开发部门对产品的一些基本的性能要求。若用户从业务的角度考虑，对软件产品本身有特定的非功能要求，则必须在软件需求说明书中加以说明，使之具有可度量和可测试性。对于一些多用户环境或数据处理能力和负载方面的测试，很难通过手工搭建测试环境来测试，所以可以参考使用一些专门的性能测试工具和手工测试相结合的方式。

 

四、项目测试的基本流程：

　　项目测试启动：项目立项后，在测试配置库中创建项目。

　　测试计划：系统详细设计后，制定测试计划，准备测试资源。

　　设计测试用例，主要是与业务相关的测试用例。

　　实施功能模块测试，搭建运行或开发环境，采用功能模块测试表的方式，开发人员在功能模块测试表中更新进度状态，测试人员在该表中描述测试进度。形成测试错误列表，该表对每个错误都有相应的测试记录与之链接，在测试记录中，详细描述错误的情况。在测试记录中还要包括修正信息和验证信息。

　　错误关闭后，测试人员维护测试记录表和更新测试用例库和问题库，作为经验积累。

　　项目在结项时，测试人员进行项目完工验收测试，填写项目测试报告。该测试报告可作为用户验收的输入工件。

 

五、功能测试方法与内容
　　数据输入测试：向系统输入数据或输入数据库操作命令时，一般是测试系统对数据库中数据操作的过程。
　　数据类型测试：由于不同的数据库系统对数据类型要求的不同，在定义数据库表时，也规定了数据字段的数据类型。
　　1、测试步骤和方法：在系统的数据维护功能界面上，录入或修改数据时，特意输入非系统设计的数据类型，检查系统是否可以接受，若不能接受则检查是否满足了系统在这方面的设计要求，如即刻清除非法内容、输入焦点不能到下一输入位置、出现系统自定义的提示信息、不允许出现开发工具的报错信息等。若系统可以接受并保存，则要看数据库表的字段类型设计是否与用户或习惯上不一致，并且要注意其他模块在调取该数据时，是否有特定要求。
　　边界值测试：根据数据取值范围的要求，输入符合取值范围的数据、取值范围的上、下限和超过取值范围的数据。注意，除要测试数据库系统本身数据类型取值范围外，还要根据软件系统设计中的一些特定要求，设计测试用例来测试。
　　数据合法性测试：测试人员除了要测试输入数据是否满足所使用数据库系统本身的数据类型和取值范围的要求外，还应该根据经验和软件系统和需求的特定要求检查输入数据的合法性。比如：日期合法性（出生年月、参保日期、发生时间、根据习惯和业务逻辑顺序对日期合理性的要求等）。工资、比例、率等，都要注意输入的合理、合法性。
　　单引号和双引号：不要忽略输入单引号和双引号可能引起的错误和数据问题。在功能录入界面上，在某字段的输入框输入了包括单引号和双引号的数据，以后在通过Select 语句查询时可能会出问题。特别在基于WEB方式的系统，输入了单引号，在查询数据记录时，肯定会出现页面链接错误（页面无法链接或找不到或链接对象错误）。
　　空值测试：在测试数据录入或修改的功能界面时，若不输入任何东西，系统又没有设计成NOT NULL，则这时，要非常注意其影响。因为数据可以正常保存，但数据表该字段是空值，那么所有与该字段有关的操作，如：查询(AND)、计算（累加、连乘）等，则可能出现数据问题（计算结果为0，无记录返回）。对于测试人员首先要检查系统到底是作为空值，还是作为空串或空字符处理。另外对于允许不输入任何值的字段，在测试过程中，要检查是否在界面显示或打印报表时，这些字段作为了关键要素或标题等情况。
　　空格：在数据维护的功能界面上，输入数据时，要注意是否在输入位置有空格，首先看系统设计时，是怎么考虑的，若系统允许输入空格，则检查条件查询或作为调用参数时的数据返回情况；另外检查程序是否使用了去掉空格的函数。
　　数据校验的不一致：测试时，对于一些编号、编码、代码等主键或作为查询或调用条件的字段，要注意系统对他们的输入合法性检查与查询或调用条件的要求是否是一致的。特别是对于数据结构设计中没有特定约束，而由程序进行校验控制的情况。
　　分析：数据输入测试的主要目的是保证输入到系统中数据的合法、合理性。我觉得，数据输入过程的检查是非常重要的，若在编程过程中，不注重数据的校验功能，虽然看起来加快了开发进度，但给以后会带来一些不可预计的编程或维护工作量。
　　2、目录路径测试：测试系统中规定的路径要求，更改路径，检查系统的是否可以正确运行及系统的排错功能。测试时，根据系统设计说明书（详细设计）或通过对程序源代码的熟悉，找出系统运行过程中指定的路径或在运行过程中，需要使用者选择路径的地方。特意更改路径（选择正确的路径、选择另外的路径、输入不存在的路径）。检查系统是否具有路径上的容错性和灵活性。比如，原则上在程序中，最好不要写绝对路径，另外可以提供配置路径的对话框，若输入了非法路径，系统有无提示等。
　　3、 数据操作测试：包括数据操作测试和用户界面操作的测试。
　　修改、新增数据：对于新增和修改数据，要注重以下几个方面的测试。界面上，新增数据成功后，数据列表是否立即刷新，输入有错误时，是否清空错误的数据，输入焦点是否得以控制。在提示信息上，是否有保存成功的提示，输入有错误时，提示的错误信息是否准确，可读。数据方面，要通过SQL检查数据提交是否正确。
　　删除数据：测试删除记录时，系统是否有确认提示，能否批量删除，根据系统详细设计，检查删除主表记录时，在业务上，其他相关表是否相应更改。
　　事物的提交与回滚:熟悉C/S模式开发或数据库应用系统开发的人都知道，数据库事物的概念。对于一个比较复杂的业务逻辑或业务上有数据一致和完整性要求时，尽量使用事物对数据进行提交，这样一旦由于意外原因引起系统或硬件故障时，可以回滚。根据系统的设计要求在测试时，可人为模拟意外故障，来测试系统的数据完整性和容错能力。
　　4、工具条和快捷键测试：在功能界面测试时，对系统菜单中定义的快捷键和菜单工具条中的工具按钮要测试。主要是有效性和一致性测试。有效性：检查是否有效，界面有无反应。一致性：定义或提示的信息是否与实际完成的功能一致。
　　5、 操作顺序测试
　　按钮顺序测试：在功能界面上，不按照设计上或习惯上的操作顺序点击功能按钮，看系统有什么反应；多次、反复点击某一按钮，看系统有什么反应。主要是测试系统的控制、校验和容错能力。
　　业务逻辑顺序：不按照系统的正常业务逻辑、流程操作，来测试系统是否控制了业务流程的顺序。
　　6、按钮有效性控制测试：主要是测试当不具备条件或无实际意义的情况下，按钮的“Enabled”属性。比如：某一业务未处理，下一环节的功能按钮则应变灰（不可用）。逐条显示数据记录，当游标已经指到了最后一条时，“下一条”和“末记录”按钮则应变灰等。
　　7、同时刻操作测试：对于删除、修改、增加数据和一些业务功能，进行多客户端同时刻操作测试，看系统有什么反应。
　　8、附件压力测试：对于有发送、上传、下载、邮件等功能的系统，选取大的文件，进行测试，来检查系统的界面效果和稳定性，看是否会死机或长时间无任何反应等。
　　9、 数据输出测试：
　　数据处理输出测试：主要测试对数据的排序、条件查询是否按照输入的条件或要求输出了正确的数据。
　　打印输出：测试打印功能是否能够正常打印出报表，打印设置后，是否能按照设置的要求打印。
　　10、WEB测试：基于WEB方式的应用，对于一些提交表单的页面，通过多次点击“back”键，来测试系统的处理情况。对于有保存数据功能的页面，多次点击“保存”，来测试系统的处理情况。