测试理论

一、针对具体项目或具体产品的测试目标，不仅根据产品质量要求进一步明确测试目标，还要根据项目背景环境（如进度、预算等）、测试团队能力和现有的技术来确定测试目标。

       例如，预算和进度限制测试的充分性，包括是否有足够的时间和资源区做兼容性测试、性能测试、安全性测试和可靠性测试等。即使对某项特定的测试，能够测试到什么深度和广度，都需要因地制宜地考量。因为从理论上讲，希望该有的测试都做了，每项测试都能做到100%，但实际项目中，进度、资源、能力等都有限制，不可能达到理想的目标，也没必要。例如单元测试，理想的目标是百分之百覆盖代码行、分支和条件，但在实际项目中，可能将单元测试的目标定为代码行的覆盖率50%、60%或80%。

二、测试方法
       先谈软件产品的功能测试需求。在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证。例如，在讨论软件测试方法时，经常谈到黑盒方法的等价类划分、边界值分析、决策表、因果分析等方法，实际上这些只是功能测试的冰山一角，不仅要对输入空间进行验证，而且还要对用户界面、业务逻辑等进行验证。总之，为了跟全面地验证或评估软件功能的质量，需要在各个层次（单元、接口和系统）和各个方面（代码、文档和系统）进行测试。也就是说，在功能测试中，不光要进行不同层次的测试，还要针对不同空间或领域进行相应的测试。

三、功能测试的需求包括下列这些内容。
（1）单元之间调用、函数之间调用的各种参数的数据测试。
（2）系统的不同输入、结果输出的数据测试。
（3）数据库默认值、数据备份和恢复的测试。
（4）系统各个界面的验证。
（5）用户操作的易用性、用户体验的测试。
（6）单元逻辑、算法的测试，如通过代码评审发现算法问题。
（7）系统的业务逻辑验证，如端到端的测试。
（8）文档的验证，包括用户手册、安装文档逐行逐字地验证。
（9）各类关键代码的评审。
（10）功能的错误操作、异常操作的测试。
（11）功能一致性、多功能互操作的测试。

四、为了验证系统是否符合非功能特性的质量需求而进行的测试是系统非功能性测试。非功能性测试需求覆盖软件系统的所有质量属性，包括性能、安全性、可靠性、兼容性、易维护性和可移植性等，它们存在对应的关系（下图）

 

 五、但每一类测试可能需要单独考虑，性能测试和兼容性测试、安全性测试都不一样，考虑的着眼点不一样。例如，性能测试的目的之一就是为了验证当前系统实际具有的性能。如果实际性能达不到系统使用的需求，就需要改进设计，优化算法或程序代码，直至达到要求。除了以上的目的之外，性能测试还可以进一步分为基准测试和规划测试，具体分析如下：

1.对于新建立的系统，测试人员并不了解某些具体的性能指标，所以性能测试的首要任务就是获取这些指标的标准值，然后基于由这些标准值所设定的基准，进一步制定产品性能改进计划，也就是性能指标的变更需求计划。
2.产品最终要被部署到运行环境中，在部署之前要进行规划，例如，根据用户的数量或数据负载来决定服务器的选型和数量，如果10万个用户需要4台双核CPU、内存4GB的服务器，如果是100万个用户是否需要16台双核CPU、内存8GB的服务器等。这些规划的数据依赖于性能的规划测试。
3.容量测试可以看作是性能测试的一种，或者认为系统的容量是系统的性能指标之一。如某个Web站点可以支持多少个并发用户、网络在线会议系统中与会者的人数。如果实际容量已满足要求，就能帮助用户建立对产品的信心。如果不能满足要求，就应该寻求新的解决方案，以提高系统的容量。若一时没有新的解决方案，就有必要在产品发布说明上明确容量上的限制，避免引起软件产品使用的纠纷。

概念1：
（1）负载测试（Load Test），也称压力测试（Stress Test）、强度测试。负载测试通过模拟实际应用的软硬件环境及用户使用过程的系统负荷，逐渐加载或一次性加载，长时间或超大负荷地运行软件，以测试系统的稳定性，并试图找出系统性能的瓶颈和异常的地方等。通过负载测试，也可以确定系统的正常工作条件、极限条件等，并了解系统可靠性等，从而提高软件系统的可靠性、稳定性，减少系统的宕机时间。

概念2：
（2）性能测试（Performance Test），通过测试确定系统运行特性的性能指标数据，如数据吞吐量、响应时间、CPU使用率等。性能测试可以分为3类：
验证测试，针对系统验证实现（如产品规格说明书）已定义的性能指标；
基准测试，就是在系统标准配置下获得有关的系统指标数据，其测试结果应具有高度的一致性、标准性，可作为将来性能改进的基准线；
规划测试，是为软件部署而进行的测试，即在多种特定的环境下，获得系统不同性能的指标，从而决定在系统部署时采用什么样的软、硬件配置。

概念3：
（3）容量测试（Capacity Test），预先分析出反映软件系统应用特征的某项指标的极限值，了解该软件系统的承载能力或提供服务的能力。系统在极限值状态下，主要功能还能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载（数据量、事件规模等）。容量测试可以看作负载测试和性能测试的组合。
（4）安全性测试（Security Test），检验系统权限设置的有效性，防范非法入侵的能力，数据备份和恢复的能力等。例如，测试人员可以假扮非法入侵者，试图采用各种办法突破系统防线，修改权限或存取权限之外的数据。

概念4：
（5）容错测试（Recovery Test），检查软件在异常条件下是否具有防护性的措施或者恢复某种灾难性破坏的手段或能力。容错性测试包括两个方面：
输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好，系统只给出提示或内部消化掉，不会导致系统出错甚至崩溃；
灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失，系统和数据是否能尽快恢复或在指定时间间隔内恢复。
对于自动恢复，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。容错测试和故障转移（fail-over）、可用性测试等有直接的关系。

六、其他测试要点

（1）服务级别协议（SLA）指定了最低性能要求，以及未能满足此要求时必须提供的客户支持级别和程度。与QoS要求一样，服务级别要求源自业务要求，对要求的测试条件及不符合要求的构成条件均有明确规定，并代表着对部署系统必须达到的整体系统特性的担保。服务级别协议被视为合同，所以必须明确规定服务级别要求。

 

 

1、性能测试
性能测试分为服务器端性能测试和客户端性能测试，需要考虑“哪些负载（如并发用户数200、400、1000等）、哪些基本配置（最低配置、标准配置等）需要进行性能测试”等测试需求。服务器端的性能测试还可进一步分为基准性能测试、性能验证测试、压力测试、容量测试、可伸缩性测试等。
客户端性能测试，需要对页面显示、刷新的时间进行测试获得相关性能指标数据，如在Google日历中添加大批量的待办事项，然后查看页面浏览的响应时间。客户端软件性能测试，还要考察其运行时所占有资源（如CPU、内存）情况，占有资源越少越好。

    在服务器端，通过改变网络带宽或延迟、负载模式和大小，对一些关键业务进行测试，以获取或验证系统整体的性能指标。如系统要求在正常使用情况下其响应时间为3～5秒，即使在使用高峰期（如上下班时间）系统的响应时间也不应该超过15秒，这就意味着至少要进行两种场景——平均负载和高峰负载的性能测试。在对实际系统进行性能测试时，往往会结合其关键业务考虑其关键性能测试需求。

2、可用性测试
可用性是指系统正常运行的能力或程度，在一定程度上也是系统可靠性的表现，可用性测试就基本上等同于可靠性测试。可用性一般用正常向用户提供软件服务的时间占总时间的百分比来表示，即：
可用性 = 正常运行时间 /（正常运行时间 + 非正常运行时间）×100%
系统非正常运行时间可能是由于硬件、软件、网络故障或任何其他因素（如断电）造成的，这些因素能让系统停止工作，或连接中断不能被访问，或性能急剧降低不能使用软件现有的服务等。
可用性指标一般要求达到4个或5个“9”，即99.99%或99.999%。
如果可用性达到99.99%，对于一个全年不间断（7×24的方式）运行的系统，意味着全年（525600分钟）不能正常工作的时间只有52分钟，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5分钟

3. 安全性测试
安全性是一个复杂的主题，涉及部署系统的各个级别。安全性要求分析，包括确定可能的货潜在的各类安全威胁和找到处理这些威胁的策略，即：
1. 确定关键（有形的和无形的）资产，并找到对这些资产的威胁；
2. 确定使组织暴露于可能带来风险威胁的薄弱环节；
3. 开发减轻组织风险的安全规划。

安全性测试就是全面检验软件在需求规格说明中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件，单独进行加强的测试，以确认其满足安全性需求。所以，安全性测试的需求点还是比较多的，任务还是比较重的，特别是对复杂的系统。这里举一些常见的需求点：

4. 兼容性测试
兼容性测试需求是指明确要测试的兼容环境，考虑软、硬件的兼容，就软件兼容来说，不仅要测试系统自身的版本兼容、用户已有数据的兼容，还要测试与操作系统、应用平台或浏览器、和其他第三方系统以及第三方数据的兼容性。操作系统包括Windows、Mac、Solaris、Linux等，浏览器包括IE、FireFox、Chrome和Safari。