2.1.2测试目标
　　软件测试的目标是根据质量要求，逐项确定、验证软件的实际表现，提供软件产品完整的质量信息；同时，为了帮助团队向客户提供一个高质量的软件产品，软件测试的目标是更早地、尽可能地将软件产品或软件系统中所存在的各种问题找出来，并促进各类开发人员尽快地解决问题。衡量测试目标的实现，是通过测试覆盖率来衡量，通过对测试结果的分析，来明确产品质量要求、功能点或代码行（分支、条件等）的测试覆盖率。例如：
　　·需求项和功能点覆盖率；
　　·代码行覆盖率95%。
　　但针对具体项目或具体产品的测试目标，不仅根据产品质量要求进一步明确测试目标，还要根据项目背景环境（如进度、预算等）、测试团队能力和现有的技术来确定测试目标。例如，预算和进度限制测试的充分性，包括是否有足够的时间和资源去做兼容性测试、性能测试、安全性测试和可靠性测试等。即使对某项特定的测试，能够测试到什么深度和广度，都需要因地制宜地考量。因为从理论上讲，希望该有的测试都做了，每项测试都能做到，但实际项目中，进度、资源、能力等都有限制，不可能达到理想的目标，也没必要。例如单元测试，理想的目标是百分之百覆盖代码行、分支和条件，但在实际项目中，可能将单元测试的目标定为代码行的覆盖率50%、60%或80%。
　　再举一个例子。国际标准IEC 61508把系统安全完整性分为0、1、2、3.和4等5个级别，而作为《铁路应用—通信、信令和处理系统—控制和保护系统用软件》欧洲标准50128:2011，根据安全完整性，确定这一领域的软件系统的测试目标，即要所完成的测试，如表2-2所示。

　　测试的目标要有具体的指标，可以被度量，在测试执行结束之前或之后，能够判断测试目标是否被达到。对各项质量要求的验证达到什么程度，能够给出数字描述的尽量给出，从功能、性到安全性、兼容性等逐项给出明确的目标。
　　2.1.3基本的测试需求
　　先谈软件产品的功能测试需求。在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证。例如，在讨论软件测试方法时，经常谈到黑盒方法的等价类划分、边界值分析、决策表、因果分析等方法，实际上这些只是功能测试的冰山一角，不仅要对输入空间进行验证，而且还要对用户界面、业务逻辑等进行验证。总之，为了更全面地验证或评估软件功能的质量，需要在各个层次（单元、接口和系统）和各个方面（代码、文档和系统）进行测试。也是说，在功能测试中，不光要进行不同层次的测试，还要针对不同空间或领域进行相应的测试。概括起来，功能测试的需求包括下列这些内容。
　　（1）单元之间调用、函数之间调用的各种参数的数据测试。
　　（2）系统的不同输入、结果输出的数据测试。
　　（3）数据库默认值、数据备份和恢复的测试。
　　（4）系统各个界面的验证。
　　（5）用户操作的易用性、用户体验的测试。
　　（6）单元逻辑、算法的测试，如通过代码评审发现算法问题。
　　（7）系统的业务逻辑验证，如端到端的测试。
　　（8）文档的验证，包括用户手册、安装文档逐行逐字的验证。
　　（9）各类关键代码的评审。
　　（10）功能的错误操作、异常操作的测试。
　　（11）功能一致性、多功能互操作的测试。
　　如果系统只是满足了功能要求，没有满足一些非功能特性（性能、安全性等）要求，还是不能满足客户的需求，不能获得用户的信任。如某个网站功能（注册、信息查询等）齐全，也可以被访问，但是，每打开一个页面都需要两分钟。结果，用户不能忍受，再也不会访问这个网站。这种非功能性的需求满足和功能性的需求满足同样重要。
　　为了验证系统是否符合非功能特性的质量需求而进行的测试是系统非功能性测试。非功能性测试需求覆盖软件系统的所有质量属性，包括性能、安全性、可靠性、兼容性、易维护性和可移植性等，它们存在对应的关系，如图2-2所示。

　　但每一类测试可能需要单独考虑，性能测试和兼容性测试、安全性测试都不一样，考虑的着眼点不一样。例如，性能测试的目的之一是为了验证当前系统实际所具有的性能。如果实际性能达不到系统使用的需求，需要改进设计，优化算法或程序代码，直至达到要求。除了以上的目的之外，性能测试还可以进一步分为基准测试和规划测试，具体分析如下。
　　·对于新建立的系统，测试人员并不了解某些具体的性能指标，所以性能测试的首要任务是获取这些指标的标准值，然后基于由这些标准值所设定的基准，进一步制定产品性能改进计划，也是性能指标的变更需求计划。
　　·产品终要被部署到运行环境中，在部署之前要进行规划，例如，根据用户的数量或数据负载来决定服务器的选型和数量，如果10万个用户需要4台双核CPU、内存4GB的服务器，如果是100万个用户是否需要16台双核CPU、内存8GB的服务器等。这些规划的数据依赖于性能的规划测试。
　　·容量测试可以看做是性能测试的一种，或者认为系统的容量是系统的性能指标之一。如某个Web站点可以支持多少个并发用户、网络在线会议系统中与会者的人数。如果实际容量已满足要求，能帮助用户建立对产品的信心。如果不能满足要求，应该寻求新的解决方案，以提高系统的容量。若一时没有新的解决方案，有必要在产品发布说明上明确容量上的限制，避免引起软件产品使用的纠纷。
　　概念：
　　（1）负载测试（Load Test），也称压力测试（Stress test）、强度测试。负载测试通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，逐渐加载或一次性加载，长时间或超大负荷地运行软件，以测试系统的稳定性，并试图找出系统性能的瓶颈和异常的地方等。通过负载测试，也可以确定系统的正常工作条件、极限条件等，并了解系统可靠性等，从而提高软件系统的可靠性、稳定性，减少系统的宕机时间。
　　（2）性能测试（Performance test），通过测试确定系统运行特性的性能指标数据，如数据吞吐量、响应时间、CPU使用率等。性能测试可以分为3类：
　　·验证测试，针对系统验证事先（如产品规格说明书）已定义的性能指标；
　　·基准测试，是在系统标准配置下获得有关的系统指标数据，其测试结果应具有高度的一致性、标准性，可作为将来性能改进的基准线；
　　·规划测试，是为软件部署而进行的测试，即在多种特定的环境下，获得系统不同性能的指标，从而决定在系统部署时采用什么样的软、硬件配置。
　　（3）容量测试（Capacity test），预先分析出反映软件系统应用特征的某项指标的极限值，了解该软件系统的承载能力或提供服务的能力。系统在极限值状态下，主要功能还能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的大负载（数据量、事件规模等）。容量测试可以看作负载测试和性能测试的组合。
　　（4）安全性测试（Security test），检验系统权限设置的有效性，防范非法入侵的能力，数据备份和恢复的能力等。例如，测试人员可以假扮非法入侵者，试图采用各种办法突破系统防线，修改权限或存取权限之外的数据。
　　（5）容错测试（Recovery test），检查软件在异常条件下是否具有防护性的措施或者恢复某种灾难性破坏的手段或能力。容错性测试包括两个方面：
　　·输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，不会导致系统出错甚至崩溃；
　　·灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复或在指定时间间隔内恢复。
　　对于自动恢复，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。容错测试和故障转移（fail-over）、可用性测试等有直接的关系。