1、什么是软件测试？
软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例去运行程序，以发现程序错误的过程。
2、软件测试的目的？
帮助开发人员，测试工程师发现问题、分析问题，减少软件的缺陷数目或者降低软件的缺陷密度，提高软件的可靠性，评估软件的性能指标，增加用户对软件的信息，测试的最终目的是为了避免错误的发生，确保应用系统能够正常高效的运作。
3、需求文档测试：
主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；
4、设计文档测试：
测试设计是否符合全部需求以及设计是否合理。
5、α测试
是指在软件开发人员缺席的情况下内部进行的模拟的或者实际的操作性测试
Alpha测试（α测试）是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册（草稿）等应该在
Alpha测试前准备好。
Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。开发者负责记录发现在错误和使用中遇到的问题。总之，Alpha测试是在受控的环境中进行的。
6、β测试
是指在软件开发人员缺席的情况下进行的操作性测试
Beta测试（β测试）是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，由用户记下遇到的所有问题，包括真实的以及主管认定的，定期向开发者报告，开发者在综合用户的报告后，做出修改，最后将软件产品交付给全体用户使用。Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力。只有当Alpha测试达到一定的可靠程度后，才能开始Beta测试。由于Beta测试的主要目标是测试可支持性，所以Beta测试应该尽可能由主持产品发行的人员来管理。
Beta测试由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
7、驱动模块:
驱动模块在大多数场合称为“主程序|”，它接收测试数据并将这些数据传递到被测试模块.单独测试一个函数单元时，被测单元本身是不能独立运行的，需要为其传送数据，为此写驱动。
驱动模块主要完成以下事情：
1、接受测试输入；
2、对输入进行判断；
3、将输入传给被测单元，驱动被测单元执行；
4、接受被测单元执行结果，并对结果进行判断；
5、将判断结果作为用例执行结果输出测试报告。
8、桩模块
比如对函数A做单元测试时，被测的函数单元下还包括了一个函数B，为了更好的定位错误，就要为函数B写桩，来模拟函数B的功能，保证其正确。
9、白盒测试
白盒测试是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件，使用程序设计的控制结构导出测试用例，是软件测试的主要方法之一。白盒测试又叫结构测试和逻辑驱动测试，它的前提是了解产品内部的工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都能按预定的要求正确的工作，而不顾及它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件的验证。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C＋＋、Visual C＋＋、Java、Visual J＋+等。
10、软件的缺陷等级应如何划分？
1．致命错误，可能导致本模块以及其他相关模块异常，死机等问题；
2．严重错误，问题局限在本模块，导致模块功能失效或异常退出
3．一般错误，模块功能部分失效；
4．建议问题，由问题提出人对测试对象的改进意见；
软件缺陷定义
A：满足下列五个规则之一才称为软件缺陷：
1）软件未达到产品说明书标明的功能。
2）软件出现了产品说明书指明不会出现的错误。
3）软件功能超出产品说明书指明的范围。
4）软件未达到产品说明书虽未指出但应该达到的目标。
5）软件测试人员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
11、白盒测试与黑盒测试的区别
任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。
黑盒测试：是指着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行的测试。
黑盒测试方法包括：等价类划分、边界值分析、因果图分析、错误推测法、功能图分析等 白盒测试：是指基于一个应用代码的内部逻辑知识，即基于覆盖全部代码、分支、路径、条件，使用程序设计的控制结构导出测试用例。
白盒测试方法包括：代码检查法、静态结构分析法、静态质量度量法、逻辑覆盖法、基本路径测试法、域测试法、符号测试法、Z路径覆盖法、程序变异测试法等，运用最广泛的就是基本路径测试法。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。
黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？
3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？
5、是否有初始化或终止性错误？
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误时，不能说明程序中没有错误。
12、软件测试阶段
软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？
软件测试策略都包含哪些？
根据软件测试工作的测试策略，一般将软件测试过程分为：单元测试、集成测试、系统
测试、验收测试四个大的阶段。
单元测试定义
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约(详细设计)而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
集成测试定义
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种
系统测试定义
统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。因此，系统测试应该按照测试计划进行，其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等
验收测试定义
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试
回归测试
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
自动化测试定义
一般我们谈到的自动化测试，其实是有两种说法的，一种是Test Automation，翻译过来叫测试自动化，侧重说明将测试用自动化设计和实现的过程；另外一种是Automated Testing/Test，翻译过来叫自动化测试，侧重说明自动的测试软件，可以是自动测试软件的功能或者性能等。
表面上看两种是有区别的，但现在我们用的多了，在提到自动化测试时，也就不区分了，基本上代表了一个意思，即：自动化测试是通过工具（程序）来对软件进行测试，一般不需要人为干预或干预很少。
13、针对缺陷采取怎样的管理措施？
1. 要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
3. 所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
14、缺陷管理工具对软件缺陷跟踪的管理的流程
1) 测试人员或开发人员发现bug后，判断属于哪个模块的问题，填写bug报告后，系统会自动通过Email通知项目组长或直接通知开发者。
2) 经验证无误后，修改状态为VERIFIED.待整个产品发布后，修改为CLOSED.
3) 还有问题，REOPENED，状态重新变为“New”，并发邮件通知。
4) 项目组长根据具体情况，重新reassigned分配给bug所属的开发者。
5) 若是，进行处理，resolved并给出解决方法。（可创建补丁附件及补充说明）
6) 开发者收到Email信息后，判断是否为自己的修改范围。
7) 若不是，重新reassigned分配给项目组长或应该分配的开发者。
8) 测试人员查询开发者已修改的bug，进行重新测试。（可创建test case附件） 回归测试的基本过程 排除所有不再使用的测试用例，确定那些对新的软件版本依然有效的测试用例，新的基线测试用例库中选择测试用例测试被修改的软件 例集，用于测试新的基线测试用例库无法充分测试的软件部分------后的软件。
15、什么是功能测试？
Functional testing (功能测试)，也称为behavioral testing（行为测试），根据产品特征、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试，用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本，以保证目标用户的体验将足够好，就像应用程序是专门为该市场开发的
一样。
功能测试也叫黑盒子测试或数据驱动测试,只需考虑各个功能，不需要考虑整个软件的内部结构及代码.一般从软件产品的界面、架构出发，按照需求编写出来的测试用例，输入数据在预期结果和实际结果之间进行评测,进而提出更加使产品达到用户使用的要求。
16、什么是性能测试？
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
16.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
16.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
16.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
16.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。
16.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？
17、什么是冒烟测试？
冒烟测试 (smoke testing)，据说是微软起的名字。在《微软项目求生法则》一书第 14 章“构建过程”关于冒烟测试，就是开发人员在个人版本的软件上执行目前的冒烟测试项目，确定新的程序代码不出故障。
冒烟测试的名称可以理解为该种测试耗时短，仅用一袋烟功夫足够了。也有人认为是形象地类比新电路板功基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟了。
冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
在一般软件公司的软件编写过程中，内部需要编译多个版本 (Build)，但是只有有限的
几个版本需要执行正式测试（根据项目开发计划），这些需要执行的中间测试版本，在刚刚编译出来后，软件编译人员需要进行基本性能确认测试，例如是否可以正确安装/卸载，主要功能是否实现，是否存在严重死机或数据严重丢失等 Bug。如果通过了该测试，则可以根据正式测试文档进行正式测试。否则，就需要重新编译版本，再次执行版本可接收确认测试，直到成功。
新版本的基本功能确认检查的测试，有的公司称为版本健康检查 (Build Sanity Check)。对于编译的本地化软件新版本，除了进行上面提到的各种测试检查，还要检查是否在新的本地化版本中正确包含了全部应该本地化的文件。可以通过采用文件和目录结构比较工具，首先比较源语言版本和本地化版本的文件和目录中的文件数目、文件名称和文件日期等，这个过程称为版本镜像检查 (Build Image Check)。其次，分别安装源语言版本和本地化版本，比较安装后的文件和目录结构中的文件数目、文件名称和文件日期等，这个过程称为版本安装检查 (Build Installing Check)。
18、什么是随机测试？
在软件测试中除了根据测试样例和测试说明书进行测试外，还需要进行随机测试 (Ad-hoc testing)，主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行样例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试样例 (TestCase) 没有覆盖到的部分。另外，对于软件更新和新增加的功能要重点测试。须注意针对一些特殊情况点、特殊的使用环境和可能并发性问题进行检查。尤其对以前测试发现的重大 Bug，进行再次测试，可以结合回归测试 (Regressive testing) 一起进行。
理论上，每一个被测软件版本都需要执行随机测试，尤其对于最后的将要发布的版本更
要重视随机测试。随机测试最好由具有丰富测试经验的熟悉被测软件的测试人员进行测试。对于被测试的软件越熟悉，执行随机测试越容易。只有不断的积累测试经验，包括具体的测试执行和对缺陷跟踪记录的分析，不断总结，才能提高。
19、什么是动态测试和静态测试？
动态方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。所谓软件的动态测试，就是通过运行软件来检验软件的动态行为和运行结果的正确性。目前，动态测试也是公司的测试工作的主要方式。
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
20、什么是测试用例？设计用例的方法、依据有那些？
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
白盒测试用例设计有如下方法:基本路径测试\等价类划分\边界值分析\覆盖测试\循环
测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构 黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。
21、测试用例通常包括那些内容？
着重阐述编制测试用例的具体做法不同结构的用例包括的不一样（版本、编号、项目、设计人员、设计日期、输入、预期输出……）
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .重要级别：定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然，测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果
在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。
22、UI测试
UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。
23、安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：应用程序级别的安全性，包括对数据或业务功能的访问，系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？
24、故障转移和恢复测试
故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？
25、配置测试
又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运
行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等） 下面列出主要配置测试
25.1浏览器兼容性
测试软件在不同产商的浏览器下是否能够正确显示与运行；
比如测试IE，Natscape浏览器下是否可以运行这套软件？
25.2操作系统兼容性
测试软件在不同操作系统下是否能够正确显示与运行；
比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？
25.3硬件兼容性
测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.
比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
这样的测试必须建立测试实验室，在各种环境下进行测试。
26、安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。
27、多语种测试
又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度 l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。
28、文字测试
文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。
比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。
29、分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分
辨率，而在其他分辨率下也都能可以运行。
30发布测试
主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试
30.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确
30.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片
30.3帮助文件测试
帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。
30.4广告用语
产品出公司前的广告材料文字，功能，图片，人性化的检查
31文档审核测试
文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：
文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。 31.1需求文档测试
主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；
31.2设计文档测试
测试设计是否符合全部需求以及设计是否合理。
总结
据美国软件质量安全中心20xx年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。
32灰盒测试
灰盒测试，确实是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
灰盒测试结合了白盒测试和黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识和与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。
33什么是测试计划？
测试计划包含项目范围内的测试目的和测试目标的有关信息。此外，测试计划确定了实施和执行测试时使用的策略，同时还确定了所需资源。定义一个测试项目的过程，以便能够正确的度量和控制测试
34软件测试V模型
35什么是开发的缺陷管理?
软件中的缺陷(Defect或BUG)是软件开发过程中的“副产品”。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。每一个软件开发团队都必须知道如何妥善处理软件中的缺陷，这关系到软件生存、发展的质量根本。可遗憾的是，并非所有的软件开发团队都知道如何有效地管理软件中的缺陷。
软件缺陷管理是在软件生命周期中为确保缺陷被跟踪和管理所进行的活动。狭义地讲，BUG是写程序过程中造成的错误。广义地讲，BUG是影响客户正常使用的任何问题。就是说，BUG不仅仅是编程中出现的问题，还包括客户需求和功能规范等方面。
(1)缺陷管理的目标
一般而言，缺陷的跟踪和管理需要达到以下两个目标：一是确保每个被发现的缺陷都能够被解决，二是收集缺陷数据并根据缺陷趋势曲线识别和预防缺陷的频繁发生。
在谈到缺陷管理时，一般人都会只想到如何修正缺陷，而对根据缺陷分析进行有效预防缺陷却很容易忽视。其实，在一个运行良好的项目开发中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。例如通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。常见的的缺陷数据统计图表包括缺陷趋势
图、缺陷分布图、缺陷及时处理情况统计表等。
(2)缺陷管理重在预防缺陷
正如我们所知，BUG应该尽早地在开发过程中被发现。修正处于开发阶段的BUG的成本远远低于修正处于验收阶段的BUG，而相对与修正已经发布给客户的产品BUG的成本更是可以忽略不计。因此，越晚修正BUG，需要重做的事情就越多。
对很多人来说，零缺陷的软件产品似乎是不切实际的。因此，我们总是听到许多软件开发人员说：“软件永远有BUG”。软件产品含有BUG并不奇怪，不幸的是发布一个包含很多BUG的产品给客户仍然不让人感到惊讶，这就是一件值得深思的事情了。
事实上，每个软件开发团队都可以通过一些简单的方法，在不增加额外资源的情况下预防BUG。为了能够预防BUG，我们首先需要了解BUG的来源。软件BUG可以分为几个类别：第一类BUG可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些BUG可能由于其随机性很难预防。但是，适当的分析将有助于避免这些BUG。另一类的BUG来自于需求误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术，这类BUG共同的特点是都来自于开发人员。
但有一个好消息是，软件中的BUG往往倾向于重复出现，即使是一个随机出现的BUG。软件BUG的不断出现不仅表现在同一个开发人员的工作上，而且表现在同一个项目上。这当然不是说项目中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。因此，BUG的预防尤为重要。
缺陷管理的核心：缺陷分析
缺陷预防的着眼点在于缺陷的共性原因(Common Cause)。通过寻找、分析和处理缺陷的共性原因，实现缺陷预防。BUG预防并不是一个不切实际的目标，但是不能期望它在一夜之间发生。我们在开发过程中应该积极为开发小组提供缺陷分析，使BUG逐渐改善。
因此，缺陷管理的最终目标是预防BUG，不断提高整个开发团队的技能和实践经验，而不只是修正它们。
BUG预防策略非常简单和容易实现，策略是发现BUG，找出BUG的根源，然后寻找一个方法来预防类似的BUG在将来出现。这策略并不需要昂贵的花费，但是却可带来极大的额外价值。
(1)BUG记录
BUG分析的第一步是记录BUG，值得注意的是记录BUG不应该满足于记录BUG的表面症状。测试的一个重要职责就是试图发现BUG的根本原因，在测试时不应将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。
(2)利用BUG分析了解开发质量趋势
对于测试出来的BUG进行缺陷分类，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。缺陷分析非常关键的一步就是寻找一个预防类似缺陷再次发生的方法。这一方法不仅涉及到开发、测试人员，还涉及到不直接负责代码编写的资深开发人员。利用这一阶段的实践成果，开发人员可以预防BUG的发生，而不仅仅是修正这些BUG。
BUG预防分析是整个BUG分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体BUG的投入将很容易被收回。在这个时候，BUG分析提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。
一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲
线会趋于上升，而发现缺陷数曲线应总体趋于下降。同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。项目经理可通过持续观察这张图表，确保项目开发健康发展。同时，通过分析预测项目测试缺陷趋于零的时间，以制定产品质量验收和发布的时间。
实际上，BUG分析图表会告诉我们很多有价值的信息。比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点发现的故障数反而呈上升趋势，那么意味着往往有一些特殊事件的发生。通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。
36、什么是软件测试中的缺陷度量？
缺陷度量
缺陷度量是软件度量的一部分，其本身并不能发现缺陷、剔除缺陷，但是有助于这些问题的解决。另外，当正确、持续地进行了缺陷度量时，产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。
数据的质量等因素，我们在本章7.4节中已经考虑了，这里仍将遵循。
什么是缺陷度量
软件产品质量度量，主要集中在软件的缺陷度量上。
缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。一般来说，在软件质量保证过程中，需要度量的缺陷数据包括6大类缺陷发现手段发现的所有缺陷。如测试相关的缺陷，需要度量
包括测试投入的工作量和成本数据、测试任务完成情况、测试规模数据、测试结果数据（包括缺陷数据、覆盖率数据）等。
（1）组织级缺陷度量，目的是了解组织的整体缺陷情况，了解客户对组织的质量满意度，建立组织基线，确定改进活动。
（2）项目级缺陷度量，目的是了解项目实时质量情况（很多项目只在最后度量，包括那些迭代式开发的项目，实际上为时已晚），预测缺陷造成的发布后维护工作量，了解客户对项目的质量满意度。
（3）个体缺陷度量，目的是了解个体缺陷产生的详细原因，并实施行动进行改进。 前两种度量大家接触较多，但第三种度量常常被忽略。这常常导致：
● 项目反复得到关于自己的质量评价，但很难了解如何去提高；
● 测试组常常能做一些改进（如增加测试覆盖、延长测试周期）来提高缺陷排除效率，但开发组没有降低缺陷产生数量的有效措施；
● 软件开发遵循了编码规范，但似乎对提高质量没有太多帮助。
37软件测试用例设计综合策略
1. Myers提出了使用各种测试方法的综合策略：
1)在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2)必要时用等价类划分方法补充一些测试用例。
3)用错误推测法再追加一些测试用例。
4)对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5)如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。
2.测试用例的设计步骤
1)构造根据设计规格得出的基本功能测试用例；
2)边界值测试用例；
3)状态转换测试用例；
4)错误猜测测试用例；
5)异常测试用例；
6)性能测试用例；
7)压力测试用例。
3.优化测试用例的方法
1)利用设计测试用例的8种方法不断的对测试用例进行分解与合并；
2)采用遗传算法理论进化测试用例；
3)在测试时利用发散思维构造测试用例。
38什么是软件测试框架
测试框架是一组自动化测试的规范、测试脚本的基础代码，以及测试思想、惯例的集合。可用于减少冗余代码、提高代码生产率、提高代码重用性和可维护性。
测试框架的好处在于：提高开发速度，提升测试代码的执行效率；提高软件代码质量，同时引入重构概念，让代码更干净和富有弹性；提升系统的可信赖度，作为回归测试的一种实现方法支持修复后“再测试”，确保代码的正确性。
常用的测试框架分类包括自动化测试框架和单元测试框架。根据所用开发平台不同，也可使用不同的测试框架展开测试。
1.软件性能的指标
（1） 响应时间
响应时间是指系统对请求做出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
（2） 系统响应时间和应用延迟时间
虽然软件性能指标本身只涉及软件性能的度量，但考虑到软件性能测试的主要目的是测试和改善所开发软件的性能，对于复杂的网络化的软件而言，简单地用响应时间进行度量就不一定合适了。
考虑一个普通的网站系统。开发该网站系统时，软件开发实际上只集中在服务器端，因为客户端的软件是标准的浏览器。虽然用户看到的响应时间时使用特定客户端计算机上的特定浏览器浏览该网站的响应时间，但是在讨论软件性能时更关心所开发网站软件本身的“响应时间”。也就是说，可以把用户感受到的响应时间划分为“呈现时间”和“系统响应
时间”，前者是指客户端的浏览器在接收到网站数据时呈现页面所需的时间，而后者是指客户端接收到用户请求到客户端接收到服务器发来的数据所需的时间。显然，软件性能测试更关心“系统响应时间”，因为“呈现时间”与客户端计算机和浏览器有关，而与所开发的网站软件没有太大的关系。
如果仔细分析这个例子，还可以把“系统响应时间”进一步分解为“网络传输时间”和“应用延迟时间”，其中前者是指数据（包括请求数据和响应数据）在客户端和服务器端进行传输的时间，而后者是指网站软件实际处理请求所需的时间。类似的，软件性能测试也更关心“应用延迟时间”。实际上，这种分解还可以继续下去，如果该网站系统使用了数据库，我们可以把“数据库延迟时间”分离出来，如果该网站系统使用了中间件，还可以把“中间件延迟时间”也分离出来。
以上的时间分解实际上有两方面的目的。首先，人们通常希望把与所开发软件直接相关的延迟时间和与所开发软件爱你不直接相关的延迟时间分离开，因为改善前者往往需要开发人员修改程序代码，而改善后者不需要开发人员修改代码，很多时候，开发人员对后者甚至是无能为力的。其次，详细的分解有助于开发人员分析哪些部分是影响软件性能的主要因素，以便于实时性能改善方案。
(3)吞吐量
吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，
在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
（4）并发用户数
并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
（5）资源利用率
资源利用率反映的是在一段时间内资源平均被占用的情况。对于数量为1的资源，资源利用率可以表示为被占用的时间与整段时间的比值；对于数量不为1的资源，资源利用
率可以表示为在该段时间内平均被占用的资源数与总资源数的比值。
2.软件性能的视角
（1）用户视角
对用和而言，性能就是响应时间。用户甚至不关心响应时间中哪些是软件造成的，哪些是硬件造成的。但用和感受到的响应时间既有客观成分，也有主观成分，甚至是心理因素 。
（2）管理员视角
管理员需要使用软件提供的管理功能等手段来方便普通用户使用。这类用户首先关注普通用户感受到的软件性能。其次，管理员需要进一步关注如何利用管理功能进行性能调优。
（3）开发人员视角
开发人员的视角与管理员的视角基本一致，但开发人员需要更深入地关注软件性能。在开发过程中，开发人员希望能够尽可能地开发出高性能的软件。
性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
·应用在客户端性能的测试
应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。
并发性能测试是重点
并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统
的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。
39什么是容量测试
通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定的程度上，就完成了负载测试和容量测试。容量还可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。
容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。
有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。
40什么是嵌入式测试
通常嵌入式系统对可靠性的要求比较高。嵌入式系统安全性的失效可能会导致灾难性的后果，即使是非安全性系统，由于大批量生产也会导致严重的经济损失。这就要求对嵌入式系统，包括嵌入式软件进行严格的测试、确认和验证。随着越来越多的领域使用软件和微处理器控制各种嵌入式设备，对门益复杂的嵌入式软件进行快速有效的测试愈加显得重要。 软件测试的目的是保证软件满足需求规格说明。系统失效是系统没有满足—个或多个正式需求规范中所要求的需求项。嵌入式软件有其特殊的失效判定准则，但是，嵌入式软件测试的日的与非嵌入式软件是相同的。在嵌入式系统设计中，软件正越来越多地取代硬件，以降低系统的成本，获得更大的灵活性，这就需要使用更好的测试方法和工具进行嵌入式和实时软件的测试。
41软件性能测试的步骤
在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。 由于工程和项目的不同，所选用的度量,评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下
1． 制定目标和分析系统
2． 选择测试度量的方法
3． 学习的相关技术和工具
4． 制定评估标准
5． 设计测试用例
6． 运行测试用例
7． 分析测试结果
·制定目标和分析系统
每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。
目标：
1． 确定客户需求和期望
2． 实际业务需求
3． 系统需求
系统组成
系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。
系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构,需要掌握 http协议，java，html等技术 。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。
系统构成：硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。
系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统工能是性能测试中要模拟的环节，了解这些是必要的。
·选择测试度量的方法
经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软件度量上，收集系统相关的数据。
度量的相关方面：
* 制定规范
* 制定相关流程, 角色，职责
* 制定改进策略
* 制定结果对比标准
·学习的相关技术和工具
性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议,cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。
开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。
·制定评估标准
任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。
通常性能测试有四种模型技术可用于评估：
*线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。
*分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来
*模仿：模仿实际用户的使用方法测试你的系统
*基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比
·设计测试用例
设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。 ·运行测试用例
通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。 ·分析测试结果
运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。
42什么是可用性测试
可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。
你能从可用性测试获得什么?在每一轮的可用性测试中，你都应该先明确具体的测试问题和目标，针对这些目标进行测试。举例来说，项目刚刚起步，你可以对定量的指标(如时间，错误率和满意度)进行测试，为日后修改网站提供参照。再例如，如果你已经设定了可测量的可用性目标，你可以看看你的产品是否切合这些目标。对于一个典型的可用性测试，你可以：找出该产品的任何的可用性问题从测试参与者的表现收集定量数据确定该产品的用户满意度
可用性测试和以用户为中心的设计的关系?可用性测试是以用户为中心的设计的一个重要组成部分。用户为本的设计过程本身就应该包括对性能和偏好进行评价的一系列测试。 什么时候该做可用性测试?尽早做，经常做。可用性测试可以让设计师和开发团队在产品成形之前尽早发现问题。 问题越早发现和弥补，所造成的损失就越低。这些问题是找到并固定好，越昂贵的补丁程序。随着项目的进展，对设计主体进行改动会变得越来越困难和昂贵。你测试的越多，并就相应测试进行改进，你就可以更加确信你的网站没有偏轨，确信它是符合您的目标和用户的需要的。迭代开发过程——开发原型，测试用户，分析结果，随之修改原型，然后再重复测试、分析、修改周期——是开发一个成功的网站或软件的最好方式。
43基准测试
基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重
新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。
44单元测试用例设计方法
测试用例的设计在单元测试中占有非常重要的地位，测试用例设计的好坏直接影响到测试的效果。确定测试用例之所以很重要，原因有以下几方面：
（1）测试用例构成了设计和制定测试过程的基础。
（2）测试的“深度”与测试用例的数量成比例。由于每个测试用例反映不同的场景、条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程也就越有信心。判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这又是以确定、实施和/或执行的测试用例的数量为依据的。
（3）测试工作量与测试用例的数量成比例。根据全面且细化的测试用例，可以更准确地估计测试周期各连续阶段的时间安排。
（4）测试设计和开发的类型以及所需的资源主要都受控于测试用例。测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应地改变。 最佳方案是为每个测试需求至少编制两个测试用例：
（1）一个测试用例用于证明该需求已经满足，通常称作正面测试用例。
（2）另一个测试用例反映某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这个测试用例称作负面测试用例。
单元测试既可以是白盒测试也可以是黑盒测试。白盒测试主要是检查程序的内部结构、逻辑、循环和路径。其常用测试用例设计方法有：逻辑覆盖和基本路径测试。根据覆盖测试的目标不同，逻辑覆盖又可分为：语句覆盖，判定覆盖，判定－条件覆盖，条件组合覆盖及路径覆盖等。白盒测试用例设计还可用到：状态转移测试、数据定义－使用测试、等价类划分、边界值分析等。黑盒测试注重对程序功能方面的要求，它只用到程序的规格说明，没有用到程序的内部结构。其常用测试用例方法有：规范（规格）导出、等价类划分、边界值分析法、错误推测法和因果图分析方法。下面将简要介绍各个方法，更详细的说明请读者自行参考相关的测试理论书籍。
1. 语句覆盖
语句覆盖就是设计若干个测试用例，运行所测程序，使得每一可执行语句至少执行一次。
2. 判定覆盖
判定覆盖就是设计若干个测试用例,运行所测程序,使得程序中每个判断的取TURE分支和取FALSE分支至少经历一次。
3. 条件覆盖
条件覆盖就是设计若干个测试用例,运行所测程序,使得程序中每个判断的每个条件的可能取值至少执行一次。
4. 判定－条件覆盖
判定－条件覆盖就是设计足够的测试用例,使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行一次。也就是说要求各个判断的所有
可能的条件取值组合至少执行一次。
5. 条件组合覆盖
条件组合覆盖就是设计足够的测试用例,运行所测程序,使得每个判断得所有可能得条件取值组合至少执行一次。
6. 路径覆盖
路径测试就是设计足够的测试用例,覆盖程序中所有可能的路径。
7. 规范（规格）导出法
规范导出法是根据相关的规范描述来设计测试用例。每一个测试用例用来测试一个或多个规范陈述语句。一个比较实际的方法是根据陈述规范所用语句的顺序来相应地为被测单元设计测试用例。
8. 状态转移测试法
对于那些以状态机作为模型或设计为状态机的软件，状态转移测试是合适的测试方法。测试用例通过能导致状态迁移的事件来测试状态之间的转换。
9. 数据定义－使用测试法
数据定义是指数据项被赋值的地方，数据使用是指数据项被读或使用的地方。目的是设计测试用例以驱动执行通过数据定义于使用之间的路径。