软件测试(Software Testing)的定义

　　官方释义：

　　a.用来促进鉴定软 件的正确性、完整性、安全性和质量的过程；

　　b.是一种实际输出与预期输出间的审核或者比较过程；

　　c.使用人工和自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别；

　　经典定义：

　　a.软件测试是为了发现错误而执行程序的过程。

　　b.软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。

　　软件测试基本流程

　　软件测试的分类

　　开发阶段

　　按来分：单元测试、集成测试、系统测试、验收测试。

　　测试的实施单位

　　按来分：开发方测试、用户测试、第三方测试。

　　测试技术

　　按来分：白盒测试、黑盒测试、灰盒测试。

　　软件测试的常用种类

　　黑盒测试：

　　把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫或

　　黑盒测试方法包括：等价类划分、边界值分析、因果图分析、错误推测法、功能图分析等。

　　白盒测试：

　　是对软件的过程性细节做细致的检查。是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为或

　　白盒测试方法包括：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖等。

　　单元测试：

　　是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约(详细设计)而言的。因此，单元测试以被测试单位的规约为基准。

　　单元测试方法包括：控制流测试、数据流测试、排错测试、分域测试等。

　　集成测试：

　　是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

　　系统测试：

　　是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等。

　　验收测试：

　　由客户或最终用户执行，旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

　　UAT测试：

　　测试

　　UAT，(User Acceptance Test),也就是用户验收，或用户可接受，系统开发生命周期方法论的一个阶段，这时相关的用户或独立人员根据计划和结果对系统进行和接收。 它让系统用户决定是否接收系统。 它是一项确定产品是否能够满足合同或用户所规定需求的。

　　功能测试：

　　对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。

　　性能测试：

　　是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　用户视角的软件性能：

　　从用户角度来说，软件性能就是软件对用户操作的响应时间。

　　系统管理员视角的软件性能：

　　系统的响应时间；

　　系统运行时服务器的状态，如CPU利用情况、内存使用情况等；

　　系统是否能够实现扩展；

　　系统支持多少用户访问；

　　系统性能可能的瓶颈在哪里；

　　系统是否支持7*24小时的业务访问。

　　软件性能指标：

　　并发用户：一给定时间内，某个时刻与服务器同时进行会话操作的用户数。

　　响应时间：客户端发出请求到得到服务器返回结果的整个过程所经历的时间。

　　吞吐量：单位时间内系统处理的客户请求的数量；一般来说，吞吐量用请求数/秒或页面数/秒来衡量；从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量；从网络的角度来说，也可以用字节数/天等单位来考察网络流量。

　　资源利用率：指系统资源的使用程度，比如服务器的CPU利用率、内存利用率、磁盘利用率、网络带宽利用率等。

　　负载测试：

　　定义

　　数据在超负荷环境下运行，测试软件系统是否能够承担。这种超负荷主要指多并发用户。

　　方法

　　人为生成大数据量，并利用工具模拟频繁并发访问

　　工具

　　一般需要使用自动化工具

　　考察指标

　　响应时间、交易容量、资源使用率等

　　压力测试：

　　定义

　　指系统不断施加越来越大的负载(并发，循环操作，多用户，网络流量)的测试。

　　目标

　　通过确定一个系统的瓶颈或者不能接收的性能点，来确定系统能提供的最大服务级别的测试。

　　恢复测试：

　　恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。如果系统恢复是自动的(即恢复由系统自身完成)，则应该检验以下内容：重新初始化、检验点设置机构、数据恢复以及重新启动是否正确。

　　可用性测试：

　　可用性测试是面向用户的系统测试。让一群有代表性的用户尝试对产品进行典型操作，- - 同时观察员和开发人员在一旁观察，聆听，做记录。

　　系统中是否存在繁琐的功能以及指令；

　　安装过程是否复杂；

　　错误信息提示内容是否详细；

　　GUI接口是否标准；

　　登录是否方便；

　　需要用户记住内容的多少；

　　帮助文本是否详细；

　　兼容性测试：

　　定义

　　测试软件在一个特定的硬件、软件、操作系统、网络等环境下系统能否正常运行。

　　目的

　　检验被测软件对其他应用软件或者其他系统的兼容性。

　　安全性测试：

　　定义

　　安全测试检测系统对非法入侵的防范能力。

　　应用程序级别的安全性测试

　　数据库安全性测试

　　系统级别的安全性测试

　　Alpha测试：

　　由用户在进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之，Alpha测试是在中进行的。

　　Beta测试：

　　由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常，因Beta测试是软件在开发者中的“真实”应用。用户Beta测试过程中遇到的一切问题(真实在或想像的)，并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。

　　冒烟测试：

　　可以根据其名称理解为该种；其实是对软件，测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本的功能正常，保证软件系统能，可以进行后续的正式测试工作。

　　回归测试：

　　是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误，回归测试的困难在于不好确定哪些内容应当被重新测试。

　　随机测试：

　　主要是根据测试者的经验对软件进行功能和性能。它是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。

　　动态测试：

　　是指通过，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：。所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态测试也是公司的测试工作的主要方式。

　　静态测试：

　　是指本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。

　　UI测试：

　　指测试用户的风格是否满足客户要求，文字是否正确，是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等；用户界面(UI)测试用于核实用户与软件之间的交互。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI测试还可确保UI中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关。

　　自动化测试：

　　利用自动实现全部或部分测试，它是软件测试的一个重要组成部分，能完成许多手工测试无法实现或难以实现的测试；正确、合理的实施自动测试，能够快速、全面的对软件进行测试，从而提高软件质量，节省经费，缩短软件发布周期。

　　桩测试：

　　桩的英文是stub；是指一个软件模块的框架或特殊目标实现，主要用于开发和测试一个组件，该组件调用或依赖这个模块。

　　桩模块：集成测试前要为被测模块编制一些模拟其下级模块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。

　　测试桩一般是 自顶向下集成时需要使用

　　驱动测试：

　　所谓驱动测试(自底向上集成时使用)，就是你负责测试模块/方法是中间的，没有main()入口，怎么编译，怎么启动呢?就需要写一个带main()的方法来调用你的模块/方法

　　桩模块的使命除了使得程序能够编译通过之外，还需要模拟返回被代替的模块的各种可能返回值(什么时候返回什么值需要根据测试用例的情况来决定)。

　　驱动模块的使命就是根据测试用例的设计去调用被测试模块，并且判断被测试模块的返回值是否与测试用例的预期结果相符