全国计算机技术与软件专业技术资格（水平）考试软件评测师-考试内容总结（十三）软件测试技术与应用

Posted 2020-08-21 林猪猪的部落格

13.软件测试技术与应用

13.1自动化测试工具

13.1.1白盒测试工具

13.1.1.1静态测试工具

静态测试工具指的是直接分析代码，不需要运行代码的测试工具。

常用的静态测试工具有：

(1)Telelogic公司的Logiscope软件

(2)Parasoft公司的JTest和C++Test是针对JAVA和C++代码进行检测和诊断的工具

(3)IBM Rational Software Analyzer是针对JAVA、C++等主流开发代码进行静态检查和分析，可与Rational Application Deceloper和Rational Software Architect集成使用

(4)PR公司的PRQA软件

(5)GIMPEL SOFTWARE公司的PC-LINT

 

13.1.1.2动态测试工具

动态测试工具指的是：采用“插桩”方式，在代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据的工具。

常用的动态测试工具有：

(1)Compuware公司的DevPartner系列软件，后被Micro Focus收购

(2)Parasoft Insure++是针对C和C++代码运行时检查内存和检测错误的工具

(3)IBM Rational公司的Purify系列

 

13.1.2黑盒测试工具

13.1.2.1常用的黑盒测试工具

黑盒测试工具适用于黑盒测试的场合，可以大大减轻黑盒测试的工作量，在迭代开发过程中可以很好的进行回归测试

常用的黑盒测试工具有：

(1)Mercury Interactive公司的WinRunner

(2)Rational公司的Robot

(3)Compuware公司的QARun(QACenter)

(4)Segue公司的SilkTest

(5)Empirix的E-Test Suite

 

13.1.2.2常用的性能测试工具

常用的性能测试工具有：

(1)HP Mercury Interactive公司的LoadRunner

(2)Compuware公司的QALoad

(3)Microsoft公司的WAS

(4)Radview公司的WebLoad

(5)针对数据库测试的TestBytes

(6)开源的性能测试工具JMeter

 

13.1.3测试管理工具

测试管理工具是在指在软件开发过程中，对测试需求、计划、用例和实施过程进行管理、对软件缺陷进行跟踪处理的工具。通过使用测试管理工具，测试人员或开发人员可以更方便地记录和监控每个测试活动、阶段的结果，找出软件的缺陷和错误，记录测试活动中发现的缺陷和改进建议。

目前市场上主流的软件测试管理工具有：

TestCenter(泽众软件出品)、TestDirector(MI公司TD，8.0后改成QC)，TestManager(IBM)，QADirector(Compuware)，TestLink(开源组织)，QATraq(开源组织)，oKit (统御至诚)。

 

13.1.4典型测试工具

13.1.4.1测试工具LoadRunner(LR)

LoadRunner 是一种预测系统行为和性能的工业标准级负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

LoadRunner(LR)包括如下组件：

(1)VuGen Load Generator(虚拟用户生成器)

用于捕获最终用户业务流程和创建自动性能测试脚本（也称为虚拟用户脚本）。

(2)Controller (控制器)

用于组织、驱动、管理和监控负载测试。

(3)Analysis (分析器)

有助于您查看、分析和比较性能结果。

 

13.1.4.2测试工具Quick Test Professional(QTP)

QTP是quicktest Professional的简称，是一种自动测试工具。现在已经被惠普收购，正式名字为HP QuickTest Professional software ，使用QTP的目的是想用它来执行重复的手动测试，主要是用于回归测试和测试同一软件的新版本。

 

13.1.4.3测试工具WinRunner

通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

 

13.1.4.4测试工具QALoad

QALoad是QACenter性能版的一部分，它通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能。

QALoad脚本的开发组件如下：

(1)脚本产生工具

使用QALoad Script Development Workbench来开发测试脚本，它包含捕捉Session的各种工具,并且可以将其转换成为脚本，编辑和编译脚本。一旦完成编译脚本，就可以使用QALoad Conductor and Player components 去测试系统了。

(2)记录工具

QALoad Record facility，可以通过QALoad Script Development Workbench去访问，可以记录终端，浏览器或者客户端的交易。将存储这些交易在一个capture 文件中。

(3)转换工具

在QALoad Script Development Workbench中去访问，可以将capture 文件转换成为脚本，将从最初的SESSION中产生出一一对应的交易脚本。

 

13.1.4.5测试工具WAS

WAS允许你以不同的方式创建测试脚本：你可以通过使用浏览器走一遍站点来录制脚本，可以从服务器的日志文件导入URL，或者从一个网络内容文件夹选择一个文件。当然，你也可以手工地输入URL来创建一个新的测试脚本。

 

13.1.4.6测试工具Logiscope

Logiscope是法国Telelogic公司推出的专用于软件质量保证和软件测试的产品。其主要功能是对软件做质量分析和测试以保证软件的质量，并可做认证、反向工程和维护，特别是针对要求高可靠性和高安全性的软件项目和工程。

 

13.1.4.7测试工具SmartBits

Smartbits系列用于测量网络设备性能和统计复杂的网络数据，测试能力非常灵活且强大。它最基本的功能是，它可以通过发送和接收诸如IP、ATM信元、POS等等形式的数据流，来进行分析吞吐量、延迟、包丢失率、信元丢失率，以及缓冲器容量等性能指标。

 

13.2测试中Web测试的考虑方面

13.2.1功能测试

13.2.1.1链接测试

链接是web应用系统的一个主要特征，它是页面之间切换和指导用户访问的主要手段。

链接测试分为以下3个方面：

(1)测试所有链接是否正确地链接到指定的页面

(2)测试链接的页面是否存在

(3)保证web应用系统中没有孤立的页面，孤立页面指没有链接指向该页面，只有在知道正确的URL地址才能访问

 

13.2.1.2表单测试

当用户通过表单提交信息的时候，都希望表单能正常工作。如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。

 

当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

 

13.2.1.3网页Cookies测试

网页的Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在 cookies 中保存了注册信息，请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数，需要验证次数累计正确。

 

13.2.1.4设计语言测试

Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的html等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或Perl等也要进行验证。

 

13.2.1.5数据库测试

在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

 

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

 

13.2.2性能测试

13.2.2.1连接速度测试

用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。

 

另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。

 

13.2.2.2负载测试(Load)

负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？

 

13.2.2.3压力测试(Stress)

负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。

 

进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。

 

13.2.3可用性测试

可用性测试包括如下内容：

(1)导航测试 

导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。主要测试的是应用系统的页面结构、导航、菜单、连接的风格是否一致。

(2)图形测试 

在应用系统中，一个应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： 

·要确保图形有明确的用途，以免浪费传输时间。 

·验证所有页面字体的风格是否一致。 

·背景颜色应该与字体颜色和前景颜色相搭配。 

·图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。 

(3)内容测试 

内容测试用来检验应用系统提供信息的正确性、准确性和相关性。 

(4)整体界面测试 

整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个应用系统的设计风格是否一致？ 

 

13.2.4客户端兼容性测试

客户端兼容性测试包括以下几个方面：

(1)操作系统/平台兼容性测试

市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。应用软件的最终用户究竟使用哪一种操作系统， 取决于用户系统的配置。

(2)不同浏览器之间的兼容性测试

浏览器是Web客户端最核心的构件，但来自不同厂商的浏览器对Java、 JavaScript、 ActiveX、 plug-ins或HTML规格都有不同的支持。不同的浏览器对安全性和Java的设置也不一样。所以，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性，也是软件兼 容性测试的重点之一。

 

13.2.5安全性测试

安全性测试包括以下测试内容：

(1)注册登录的方式

(2)在web应用系统中是否有超时限制

(3)相关信息是否写进了日志文件，并且是否可追踪

(4)当使用了安全套接字时还要测试加密是否正确，检查信息的完整性

(5)服务器端的脚本常常构成安全漏洞，不能在服务器端放置和编辑脚本

 

13.2.6负载压力测试中Web性能评估指标

负载压力测试中Web性能评估指标包括如下方面：

(1)点击率：指网站页面上某一内容被点击的次数与被显示的次数之比，即clicks/views，它是一个百分比。反映了网页上某一内容受关注的程度，常常用来衡量广告的吸引程度。例如：一个网页被打开1000次，某一个广告被点击了10次，那么该广告的点击率是1%

(2)点击量：用户点击页面的次数，也称“页面浏览量”

(3)交易响应时间：系统完成事务执行准备后和系统完成待执行事务后所采集的时间戳之间的时间间隔，标志着用户进行某一操作需要的大致时间

(4)吞吐量：每分钟执行的业务数，又称为“处理能力”

(5)并发用户数：同时执行某一操作的用户数量

 

13.3易用性测试相关内容

13.3.1安装测试

确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。

安装测试包括如下内容：

(1)评估安装手册

(2)测试安装的自动化程度

(3)测试安装选项和设置

(4)测试安装过程的中断

(5)测试多环境安装

(6)测试安装的正确性

(7)测试修复安装与卸载

(8)测试升级安装

 

13.3.2界面测试

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

界面测试的内容包括：

(1)易用性

(2)规范性

(3)联机帮助

(4)合理性

(5)美观与协调性

(6)菜单位置

(7)独特性

(8)快捷方式的组合

(9)安全性考虑

(10)系统资源占用

 

13.3.3帮助测试

联机帮助技术为初学者提供了一条使用新软件的捷径。借助它用户可以在上机过程中随时查询有关信息，代替了书面用户手册，提供了一个面向任务的帮助信息查询环境。

 

13.4文档测试相关内容

13.4.1文档测试

13.4.1.1文档的分类

文档分为以下3大类：用户文档、开发文档、管理文档

(1)用户文档

包括用户手册、操作手册、维护修改建议。

(2)开发文档

包括软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告。

(3)管理文档

包括项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告。

 

13.4.1.2文档测试范围

文档测试范围如下：

(1)用户文档：用户手册、操作手册、维护修改建议

·用户手册测试的内容包括：

准确地按照手册的描述使用程序。

尝试每一条建议。

检查每条陈述。

查找容易误导用户的内容。

·操作手册：

·维护修改建议：

(2)开发文档：软件需求说明书、数据库设计说明书、概要设计说明书、详细设计说明书、可行性研究报告

·软件需求说明书：

·数据库设计说明书：

·概要设计说明书：

·详细设计说明书

·可行性研究报告

(3)管理文档：项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告

·项目开发计划

·测试计划：计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。

·测试报告

·开发进度月报

·开发总结报告

 

13.4.2用户文档测试

13.4.2.1用户文档测试的内容

用户文档测试的内容如下11条内容：

(1)包装上的文字和图案

(2)宣传材料、广告及其他插页

(3)授权/注册登记表

(4)最终用户许可协议

(5)标签和不干胶条

(6)安装和设置指导

(7)用户手册

(8)联机帮助

(9)指南、向导

(10)样例、示例和模版

(11)错误提示信息

 

13.4.2.2用户文档测试的要点

用户文档测试的要点如下10条内容：

(1)文档的读者群

文档面向的读者定位要明确。对于初级用户、中级用户以及高级用户应该有不同的定位。保证用户能够看得懂并且能理解
(2)文档的术语

文档中用到的术语要适用于定位的读者群，用法一致，标准定义与业界规范相吻合。
(3)文档的正确性

测试中需检查所有信息是否真实正确。
(4)文档的完整性

对照软件界面检查是否有重要的分支没有描述到，甚至是否有整个大模块没有描述到。
(5)文档的一致性

按照文档描述的操作执行后，检查软件返回的结果是否与文档描述相同。
(6)文档的易用性

检查文档是否方便用户查找相应内容
(7)图表与界面截图

检查所有图表与界面截图是否与发行版本相同。
(8)样例和示例

像用户一样载入和使用样例，检查是否正确。

(9)语言

不出现错别字，不要出现有二义性的说法。特别要注意的是屏幕截图或绘制图形中的文字。
(10)印刷与包装

检查印刷质量；手册厚度与开本是否合适；包装盒的大小是否合适；有没有零碎易丢失的小部件等。

 

13.4.3需求说明书的评测内容

需求说明书的评测内容如下表所示：

表12-6  需求说明书的评测内容

编号	评测项	评测结果
1	系统定义的目标是否与用户的要求一致
2	系统需求分析阶段提供的文档资料是否齐全
3	文档中的所有描述是否完整、清晰、准确反映用户要求
4	与所有其它系统成分的重要接口是否都已经描述
5	被开发项目的数据流与数据结构是否足够且确定
6	所有图表是否清楚，在不补充说明时能否理解
7	主要功能是否已包括在规定的软件范围之内，是否都已充分说明
8	软件的行为和它必须处理的信息、必须完成的功能是否一致
9	设计的约束条件或限制条件是否符合实际
10	是否考虑了开发的技术风险
11	是否考虑过软件需求的其它方案
12	是否考虑过将来可能会提出的软件需求
13	是否详细制定了检验标准，它们能否对系统定义是否成功进行确认
14	有没有遗漏，重复或不一致的地方
15	用户是否审查了初步的用户手册或原型
16	软件开发计划中的估算是否受到了影响