第三章 软件测试分类 3.1 按开发流程分03

3.1.3.1 概念

       系统测试是将已经集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。

        系统测试的目的在于通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。以验证软件系统的功能和性能等满足其规约所指定的要求。系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。

3.1.3.2 功能测试

       功能测试是系统测试中最基本的测试，它不管软件内部的实现逻辑，主要根据产品的需求规格说明书和测试需求列表，验证产品的功能实现是否符合产品的需求规格。功能测试主要是为了发现以下几类错误：

       1）是否有不正确或遗漏了的功能？

       2）功能实现是否满足用户需求和系统设计的隐藏需求？

       3）能否正确的接受输入？能否正确的输入结果？

       功能测试要求测试设计者对产品的规格说明、需求文档、产品业务功能都非常熟悉，同时对测试用例的设计方法也有一定掌握，才能设计出好的测试方案和测试用例，高效地进行功能测试。

       在进行功能测试的时候，首先需要对需求规格进行分析，因为这是功能测试的基本输入。对需求规格的分析可以分为几个步骤：

       1）对每个明确的功能需求进行标号，

       2）对每个可能隐含的功能需求进行标号。

       3）对于可能出现的功能异常进行分类分析，并标号。

       4）对于前面三个步骤获得的功能需求进行分级。由于我们不可能测试任何东西，因此我们可以根据风险来决定对每个功能投入多少关注。一般来说，我们可以把功能划分为关键功能和非关键功能。

      5）对每个功能进行测试分析，分析其是否可测，如何测试，可能的输入，可能的输出等。

      6）脚本化和自动化。

      功能测试需要注意以下几点：

      1）多考虑用户是在什么情况下如何来使用该功能的，比如网络断掉的时候访问网站，用键盘进行操作等。

      2）多考虑用户对多各功能的组合运用，比如对手机进行的功能测试，需要考虑到用户同时使用多个功能的情况。

     3）对于服务器软件多考虑用户同时访问、操作的情况，需要检查用户的同时使用是否会导致功能的失效。

3.1.3.3 性能测试

        在实时系统和嵌入系统中，提高符合功能需求但不符合性能需求的柔软剂是不能被接受的，性能测试就是用来测试软件在集成系统中的运行性能的。性能测试可以发生在测试过程的所有步骤中，即使是在单元层，一个单独模块的性能也可以使用白盒测试来进行评估，然而，只有当整个系统所有成分都集成到一起之后，才能检查一个系统的真正性能。

       性能测试的目标是度量系统相对于预定义目标的差距。需要的性能级别针对于实际的性能级别进行比较，并把其中的差距文档化下来。

       性能研究方面建议的步骤：

       1）文档化性能目标，例如，确切的性能度量标准必须被验证。

       2）定义测试驱动或者用于驱动系统的输入源。

       3）定义要使用的性能方法或者工具。

       4）定义性能研究如何被进行，例如，什么是基线，什么是变化的，当可重复的时候如何可以被验证，如何可以孩子的何时研究被完成来？

       5）定义报告过程，例如，技术和工具。

性能测试是一个较大的范畴，包括测试在各种业务场景下的性能表现，包括响应时间、资源使用情况，系统极限容量等，负载测试、压力测试和容量测试只是从不同角度来测试的一种性能测试而已。

性能测试要点

       与功能测试是验证系统实现的功能是否与功能需求完全一致不同，性能测试考虑两个方面。

       1）验证系统实现的性能是否与性能需求完全一致。

       2）检测系统实现的具体性能到底怎样。

      另外对于服务器端软件和客户端软件性能测试关注的重点也是不同的。

      1）对于服务器端软件，由于涉及到多个用户同时访问的情况，因此对资源占用的要求是非常高的。在进行性能测试时需要关注cpu的占用、吞吐量、并发用户数等等性能信息。其中cpu的占用不能太高也不能太低，一般要求最大占用率在90%，太低说明资源浪费严重，太高说明已经到了服务器的极限，性能可能会出现较大的降低。

      2）对于客户端软件，主要关注响应时间以及用户端内存的消耗，尤其要注意是否会出现内存泄露的问题。内存泄漏实际上就是指能使用的内存越来越少，产生的原因是被占用的内存没有及时的进行释放。

3.1.3.4 压力测试

       压力测试的目的是要对付非正常的情形。是调查系统在其资源超负荷的情况下的表现。尤其是压力测试对系统的处理时间有什么影响。这类测试在一种需要反常数量、频率、或资源的方式下执行系统。

       压力测试研究系统在一个短时间内活动处在峰值时的反应。压力测试应当在开发过程中尽早进行，因为它通常发现主要的设计缺陷。这些缺陷会影响很多区域。如果压力测试不尽早进行的话，一些在开发早期可能很明显的细微的缺陷可能难于被发现。

       压力测试建议的一些步骤：

       1）进行简单的多任务测试。

       2）在简单的压力缺陷被修正后。增加系统的压力直到中断。

       3）在每个版本循环中重复进行压力测试。

       4）压力测试要点：要想做到压力测试。必须将极限情况模拟出来，然后再该极限情况下进行测试。看系统性能如何。

3.1.3.5 容量测试

      容量测试的目的是使系统承受超额的数据容量来发现它是否能够处理的数据容量。

      进行容量测试一般可以通过如下步骤完成：

      1）分析系统的外部数据源，并进行分类。

      2）对每类数据源分析可能的容量限制，对于记录类型数据需要分析记录长度限制，记录中每个域长度限制，记录数量限制。

     3）对每类型数据源，构造大容量数据对系统进行测试。

     4）分析测试结果，并与期望值比较，确定目前系统的容量瓶颈。

     5）对系统进行优化并重复以上步骤，直到系统达到期望的容量处理能力。

     容量测试要点：容量测试关键是在于测试一个最大值，能打开的最大文件大小，能保存的最大数据量等等，只要是系统中对于用户而言非常重要的最大值都可以作为容量测试的对象。

3.1.3.6 安全性测试

      安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。

      安全性功能或者控制是度量针对于损失或者伤害的保护。评价的方法是列出安全性功能和任务并且关注于在特定系统功能或者过程中包含的控制。安全性功能评价针对人为错误和偶然的系统误操作。一些功能性的安全性问题包括：

     1）控制特性是否工作正确？

     2）无效的或者不可能的参数是否被检测并且适当的处理？

     3）无效的或者超出范围的指令是否被检测并且适当的处理？

     4）错误和文件访问是否适当的被记录？

     5）是否有变更安全性表格的过程？

     6）系统配置数据是否能正确保存，系统故障时是否能恢复？

     7）系统配置数据能否导出。在其他机器上进行备份？

     8）系统配置数据能否导入，导入后能否正常使用？

     9）系统配置数据保存时是否加密？

     10）没有口令是否可以登录到系统中？

     11）有效的口令是否被接受，无效的口令是否被拒绝？

     12）系统对多次无效口令是否有适当的反应？

     13）系统初始化的权限功能是否正确？

     14）各级用户权限划分是否合理？

     15）用户的生命期是否有限制？

     16）低级别的用户是否可以操作高级别用户命令？

     17）高级别的用户是否可以操作低级别用户命令？

     18）用户是否会自动超时退出，超时的时间是否设置合理，用户数据是否会丢失？

     19）登陆用户修改其他用户的参数是否立即生效？

     20）系统在最大用户数量时是否操作正常？

     21）对于远端操作是否于有安全方面的特性？

     22）防火墙是否能被激活和取消激活？

     23）防火墙功能激活后是否会引起其他问题？

     评价安全机制的性能与安全性功能本身一样重要。一些问题就集中在安全性的性能上包括如下：

    1）有效性：执行严格的安全性功能所占有的时间比例？安全性控制一般需要比系统其他部分更高的有效性。

    2）生存性：系统在抵制主要错误或者自然灾害方面的能力如何？这包括错误期间紧急操作的支持、随后的备份操作和恢复到正常操作的功能。

    3）精确性：安全性控制精确度如何？精确性围绕错误的数量、频率和严重性。

    4）反应时间：反应时间是否可接受？慢的反应时间可能导致用户绕过安全控制。当安全表格动态修改的时候，反应时间还对控制管理很关键。

    吞吐量：安全性控制是否支持需要的使用吞吐量？吞吐量包含用户和服务请求的峰值和平均值。

安全测试要点

     1）不登陆系统，直接输入登陆后的页面url是否可以访问。

     2）不登陆系统。直接输入下载文件的url是否可以下载

     3）退出登陆后按后退按钮能否访问之前的页面。

     4）ID/密码验证方式中能否使用简单密码。如密码标准为6位以上，字母和数字混合。不能包含ID，连续的字母或数字不能超过n位。

     5）重要信息在输入或查询时是否用明文显示。

     6）手动更改url中的参数值能否访问没有权限访问的页面

     7）url里不可修改的参数是否可以被修改

     8）上传与服务器端语言一样扩展名的文件或exe等可执行文件后，确认爱服务器端是否可以直接运行。

     9）注册用户时是否可以以“--”，”or 1=1” 等做为用户名。

    10）传送给服务器的参数中包含特殊字符（‘，’and 1=1’,’--’,’and 1=0’,’or 1=0 __’）时是否可以正常处理。

    11）执行新增操作时，在所有的输入框中输入脚本标签后能否保存。

    12）是否对session的有效期进行处理。

    13）错误信息中是否含有sql语句、sql错误信息以及web服务器的绝对路径等

    14）ID/密码验证方式中，同一个账号在不同的机器上不能同时登陆

    15）ID/密码验证方式中，连续数次输入错误密码后该账户是否被锁定。

    16）新增或修改重要信息时是否有自动完成功能。

3.1.3.7 GUI测试

       GUI是一个分层的图形化的软件前端，它从一个固定的事件集中接受用户产生的和系统产生的事件，并且产生确定的图形输出。一个GUI包含许多图形对象，每个图形对象有一个固定的属性集合。

       GUI测试主要包括两方面的重要内容，一方面是界面实现与界面设计的吻合情况，另一个方面是确认界面处理的正确性。GUI测试比较困难。主要有如下几个原因：

       1）一个GUI的可能接口空间是非常庞大的。每个GUI活动序列可能会导致系统处在不同的状态上。一般来说，GUI活动的结果在系统不同的状态上是不同的。这样就必须在一个庞大状态集上进行GUI测试，这个工作即使加入了自动化测试也难于完成。

       2）GUI的事件驱动特性。由于用户可能会点击屏幕上任何一个像素，因此对GUI来说可能会产生非常非常多的可能的用户输入。模拟这类输入是困难的。

       3）GUI测试的覆盖率不同于传统的结构化覆盖率，理论上不够成熟。且没有合适的自动化工具。

      4）界面的美学具有很大的主观性。界面元素的默认大小，元素间的组合及排列次序，界面元素的位置等。对于不同的用户有不同的结果。如何满足大部分客户的意见也是界面测试的一个难点。

     5）糟糕的设计使得界面与功能混杂在一起。这使得界面的修改会导致更多的错误，同时也增加来测试的难度和工作量。

     在GUI测试用例的时候。我们可以从以下几个步骤进行思考：

     1）划分界面元素。并根据界面的复杂性进行分层。

     2）在不同的界面层次确定不同的测试策略。

     3）进行测试数据分析，提取测试用例。

     4）使用自动化测试工具进行脚本化工作。

     5）GUI测试要点：

     6）界面的显示。

     7）控件的功能。

3.1.3.8 可用性测试

        可用性测试和可操作性测试有很大相似性，它们都是为了检测用户在理解和使用系统方面到底有多好。这包括系统功能、系统发布、帮助文本和过程，以保证用户能够舒适的和系统交互。在实际测试的时候，往往把这两者放到一起进行考虑，很少会去严格区别这两者之间的关系。可用性测试应当在开发期间尽可能早的进行并且应当被设计到系统中去。被延迟了的可用性测试是不可能的，因为系统已经被锁住，通常需要对系统进行大的重设计以修正严重的可用性错误。这可能旨在经济上是不适合的。

       测试中应当关注的可用性问题包括：

      1）过分复杂的功能或者指令。

      2）困难的安装过程。

      3）错误信息过于简单，例如“系统错误”。

      4）语法难于理解和使用。

      5）非标准的GUI接口。

      6）用户被迫去记住太多的信息。

      7）难以登陆。

     8）帮助文本上下文不敏感或者不够详细。

     9）和其他系统之间的连接太弱。

     10）默认不够清晰。

     11）接口太简单或太复杂。

     12）语法、格式和定义不一致。

     13）没有给用户提供所有输入的清晰的知识。

3.1.3.9 安装测试

    可安装性测试的目的就是要验证成功安装系统的能力。

    测试人员在考虑可安装性测试的时候，可以考虑下面这些关键问题：

    1）谁安装系统，例如，假设的技术能力是什么？

    2）安装过程是否被完整的文档化，并且有详细且明确的安装步骤？

    3）安装过程假定工作在哪个环境中？

    4）安装是否修改用户当前的环境设置？

    5）安装人员如何知道系统已经被正确安装了？

    安装测试要点：

    1）安装前测试：检查安装包文件是否齐全，尤其是dll文件，还要检查安装手册。

    2）安装中测试：主要是安装流程的测试以及检查安装时文件、注册表、数据库的变动。

    3）安装后测试：主要是检查安装好的软件是否能运行，基本功能能否使用。

    4）另外还要进行卸载测试及升级测试。卸载测试主要注意能否恢复到软件安装之前的状态，包括文件夹、文件、注册表等等是否能把安装时做的修改都去除掉。升级测试主要注意升级对于已有数据的影响。

3.1.3.10 异常测试

    系统异常测试又叫系统容错和可恢复性测试，它是通过人工干预手段使系统产生软、硬件异常，通过验证系统异常前后的功能和运行状态，达到检验系统的容错、排错和恢复的能力。

    一般来说。系统对容错的处理分为两种，系统自动处理和人工干预处理。系统自动处理我们主要关注系统运行的自我恢复。人工干预处理意味着系统某个部件或者全部无法自我恢复，需要人工进行强制恢复，此时人工干预时间是否在我们系统设计的容限范围内是我们测试过程中关注的重点。

    异常测试要点：要进行异常测试关键是需要构造各种系统会出现的异常，可以从以下方面考虑：

    1）系统断电。

    2）系统断网。

    3）系统死掉。

    4）系统数据丢失。

3.1.3.11 备份测试

    备份测试是恢复性测试的一个补充，并且应当是恢复性测试的一个部分。备份测试的目的是验证系统在软件或者硬件失败的事件中备份它数据的能力。

    备份测试需要从以下几个角度来进行设计：

    1）备份文件，并且比较备份文件与最初的文件的区别。

    2）存储文件和数据。

    3）完全的系统备份步骤。

    4）检查点备份。

    5）备份引起系统性能的降级。

    6）手工操作过程备份的有效性。

    7）系统备份“触发器”的检测。

    8）备份期间的安全性过程。

    9）备份过程期间的维护处理日志。

    10）备份测试要点：

    11）既然是备份，那么备份出来的数据格式如何。

    12）备份是否成功，还需要通过数据的导入来进行检查。

3.1.3.12 健壮性测试

    健壮性测试有时也叫容错性测试，主要用于测试系统在出现故障的时候，是否能够自动恢复或者忽略故障继续运行。

    测试要点：

    1）和异常测试类似，关键还是如何制造故障。

3.1.3.13 网络测试

    网络测试是在网络环境下和其他设备对接，进行系统功能、性能与指标方面的测试，保证设备对接正常。

    网络测试考察系统的处理能力、系统兼容性、系统稳定可靠性及用户使用等方面。如通信产品，主要进行协议测试：

    1）一致性测试：检测所实现的系统与协议规范符合程度。

    2）性能测试：检测协议实体或系统的性能指标。

    3）互操作性测试：检测同一协议不同实现厂商之间，同一协议不同实现版本之间、或同一类协议不同实现版本之间互通能力和互连操作能力。

    4）坚固性测试：检测协议实体或系统在各种恶劣环境下运行的能力。

3.1.3.14 稳定性测试

    系统稳定性测试目的是评价系统在一定负荷情况下、长时间的运行情况。包括系统在一定负荷下，再增加新的业务，原有的业务是否受影响，新的业务是否能正常工作，系统资源有无泄漏。数据有无不一致的情况。系统性能是否会降下来。关键点是长时间的运行后，系统的状况如何，系统平均无故障时间是否满足系统设计要求。

    在进行系统稳定性测试设计时。可以考虑从以下几个方面：

    1）相对稳定业务量。

    2）不断变化的业务量。

    稳定性测试做为系统测试的一个重要组成部分，和系统测试的其他部分有很大关系。在制定稳定性测试方案时，要考虑到稳定性测试任务安排，例如保证系统基本功能都已实现，且运转正常，才能开展稳定性测试。

    稳定性测试重点关注系统长时间运行，所以建议在稳定性测试时，一个周期最好是n*24小时，在实际测试中，各个产品根据情况增加或减少。

    稳定性测试要点：

    确定一个一般的负载，然后在该负载下长时间让系统工作，检查系统是否会出现故障。

3.1.3.15 系统测试执行

    系统测试环境分类：

    1）测试环境：为了测试搭建的服务，包含所有的软件和硬件。

    2）仿真环境：和线上的环境从软件和硬件上配置接近100%。

    3）生产环境：用户真实使用的环境。一般系统发布之后需要在线上验证最小点。

    系统测试工具介绍：

    1）测试管理工具：TD/QC等

    2）缺陷管理工具：jira、bugfree、bugzilla等

    3）性能测试工具：loadrunner、robot等

    系统测试数据：

    1）产品数据。

    2）工具生成。

    3）捕获数据。

    4）手工构造。

    5）随机数据。

    系统测试预测试：预测试实际上就是一个基本功能测试，是通过基本功能测试要检查被测系统的质量，以便查看被测系统不适合用来做系统测试执行。因此系统测试预测试的关键在于预测试项的选取。通常选取优先级较高的功能用例来执行。

    系统测试评审。

    1）预测试是否通过。

    2）系统测试用例是否评审通过。

    3）测试人员是否到位。

    4）测试工具是否到位。

    执行系统测试：执行时需要对执行结果进行记录，然后每天下班前对当天的执行情况进行汇总，编写测试日报。整个执行结束时，需要编写系统测试报告，对整个系统测试活动进行总结，并提供一些数据分析，便于将来开发和测试进行改进。系统测试报告编写完成后，需要经过评审以确定系统测试是否可以停止了。