常见的测试用例设计方法都有哪些
常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
1. 等价类划分
常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
详细的描述一个测试活动完整的过程。
1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪
2. 开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。
3. 测试人员根据修改好的需求分析文档开始写测试用例，同时开发人员完成概要设计文档，详细设计文档。此两份文档成为测试人员撰写测试用例的补充材料。
4. 测试用例完成后，测试和开发需要进行评审。
5. 测试人员搭建环境
6. 开发人员提交第一个版本，可能存在未完成功能，需要说明。测试人员进行测试，发现bug后提交给bugzilla。
7. 开发提交第二个版本，包括bug fix以及增加了部分功能，测试人员进行测试。
8. 重复上面的工作，一般是3-4个版本后bug数量减少，达到出货的要求。
9. 如果有客户反馈的问题，需要测试人员协助重现以及回归测试。
注：SQA的缩写是Software Quality Assurance(软件质量保证)
软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。
SQA素质要求有：1.过程为中心：应当站在过程的角度来考虑问题，只要保证了过程， QA就尽到了责任。2.服务精神：为项目组服务，帮助项目组确保正确执行过程。3.了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识。4.了解开发：对开发工作的基本情况了解，能够理解项目的活动。5.沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。
以往是否曾经从事过性能测试工作？请尽可能的详细描述您以往的性能测试工作的完整过程。
曾经做过一套网管系统的性能测试，主要测试该软件在同时管理大量终端的情况下，在响应时间，cpu/磁盘/内存等参数是否满足要求。
也曾经做过软交换系统的呼叫性能测试，主要是测试软交换系统在有大量呼叫的情况下，响应时间，呼叫成功率，cpu/磁盘/内存等参数是否满足设计要求。
您在从事性能测试工作时，是否使用过一些测试工具？如果有，请试述该工具的工作原理，并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
测试网管系统中，使用的mimic来模拟终端，能够大量的节省成本。
测试软交换系统的时候，使用的prolab来模拟终端并发送呼叫软交换，他完成了同时数百人才能完成的摘机拨号工作，主要工作原理是产生一些符合要求的ip包并发送给软交换系统，同时对软交换系统的回应进行处理，决定下一步动作。
您认为性能测试工作的目的是什么？做好性能测试工作的关键是什么？
主要是保障在大量用户的情况下，服务能正常使用。
在您以往的工作中，一条软件缺陷（或者叫bug）记录都包含了哪些内容？如何提交高质量的软件缺陷（bug）记录？
1. 在传统的bugzilla中，bug描述应该包括以下的信息
2. 和bug产生对应的软件版本
3. 开发的接口人员
4. bug的优先级
5. bug的严重程度
6. bug可能属于的模块，如果不能确认，可以用开发人员来判断
7. bug标题，需要清晰的描述现象
8. bug描述，需要尽量给出重新bug的步骤
9. bug附件中能给出相关的日志和截图。
高质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。
1、软件测试的原则是什么？
2、软件测试的V模型？
3、画出bug的跟踪状态图？
4、描述下oracle中得SGA是什么？
5、输入三个整数，判断他是不是有效的三角形，设计下测试用例？
6、一个查找对话框，设计下测试用例？
7、SQL语句中having的作用？
8、QQ文件传输过程，设计下测试用例？
9、黑盒测试用例的设计的方法？
10、描述下常用的测试工具？
11、描述下测试活动完整的过程？
12、描述下loadrunner和QTP的区别？
13、一个杯子，设计下测试用例？
14、描述下内连接在什么时候下应用？
15、左连接和右连接有什么区别？
16、distinct是什么意思？
17、描述下一个软件项目的流程？
18、描述下你怎么理解黑盒测试的？
19、bugfree、QC、TD你认为三者有什么区别？
20、一个网上订单提交的过程。设计下测试用例？
21、描述下功能测试、性能测试、系统测试、集成测试的区别及联系？
22、给一个C++的程序，画出它的流程图。
23、描述下软件工程中软件测试的重要性？
24、测试一个程序，并发用户为50个，在Loadrunner中怎么设置？
25、描述下Loadrunner测试过程？
26、Loadrunner在录制脚本时，对于那种加密的密码，录制完成后，会产生乱码，你在脚本增强
时，怎么样让其解码？
27、在用Loadrunner测试的时候，首先要选择的就是录制的协议，假设一个程序，既是B/S的程
序，页面中还嵌入Javalet的内容，在录制时，你选择什么协议?
28、为什么要使用存储过程？在程序中怎么调用存储过程？
29、bug的状态有哪些？
30、写一个语句，去除重复项？
31、一个bug描述都包括哪些内容？
32、怎么样提交高质量的bug？
33、把A库的数据移动B库中，怎么实现？
34、包括A表和B表中所有的行并消除重复行，应用哪个关键字？
35、.Net的程序怎么搭建？
36、会不会搭建测试bugfree、QC或者TD？怎么搭建？
37、了解中间件吗？
38、在QC或者TD中，会不会对字段进行维护？
39、Oracle中转换日期的函数是什么？
40、数据库设计三大范式？
性能测试
? 1. 如何理解TPS？
? 2. 如何理解线程调用？
? 3. 如何理解响应时间？
? 4. 如何理解性能建模？（可分类回答）
? 5. 如何理解响应时间、TPS曲线和用户之间的关系？
? 6. 在LoadRunner中为什么要设置思考时间和pacing？
应用服务器
? 1. 如何理解J2EE的系统架构？
? 2. 如何理解J2EE应用服务器的容器？
? 3. 如何理解内存泄露？如何定位JAVA类的应用的内存泄露？如何定位C语言编写的应用的内存泄露？
? 4. 如果用纯JAVA的应用调用J2EE应用服务器的容器资源会出现什么结果？需要如何维护容器资源？（说明原理即可）
? 5. 如何定位JAVA的方法调用消耗的时间？（不通过在源代码中加时间戳的方式）？
? 6. 如何定位C语言中的函数调用消耗的时间？
?7. 如何监控J2EE应用服务器？（可以用一个具体的应用服务器做例子）
数据库
? 1. 如何理解数据库架构？（可以用一个数据库做例子）
? 2. SQL语句在数据库中的执行分成几步，每一步都做什么？（可以用一个数据库做例子）
? 3. 如何跟踪SQL的执行时间和内存的消耗？（可以用一个数据库做例子）
? 4. 如何监控数据库？监控能得到什么数据？（可以用一个数据库做例子）
? 5. 如何定位死锁问题？如何定位热块问题？如何监控日志切换？（可以用一个数据库做例子）
? 6. 有几种手段可以改变执行计划？（可以用一个数据库做例子）
操作系统
? 1. 如何判断CPU、内存、磁盘的瓶颈？
? 2. 如何理解CPU、内存、磁盘之间的关系？
? 3. 如何理解paging in/paging out？
? 4. 如何监控操作系统的资源？（可以用一个操作系统做例子）
? 5. 如何理解内存管理和线程调度？（可以用一个操作系统做例子）
? 6. 如何理解CSwitch？（可以用一个操作系统做例子）
?7. 如何理解磁盘IO？（可以用一个操作系统做例子）
网络
? 1. 如何定位数据包的传输在网络上消耗的时间？
? 2. 如何理解纯路由和NAT的区别？
性能测试工具
? 1. 解释LoadRunner的工作原理。
? 2. 如何理解LoadRunner里的关联？
? 3. 如何理解性能压力工具？
? 4. 如何理解虚拟用户？（可以用一个工具做例子）
? 5. 如果理解业务到脚本的转化？（可以用一个工具做例子）
? 6. 如何做到业务统计数据到场景的转化？（可以用一个工具做例子）
一般测试流程：
1.需求分析阶段：只要就是对业务的学习，分析需求点。
2.测试计划阶段：测试组长就要根据SOW(工作说明书)开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。
3.测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。
4.测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。
5.测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档。
流程：
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.
测试工具：
C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux 甚至苹果OS等
测试环境都是必须的
常用的软件测试工具分为：
[开源测试工具]：
开源测试管理工具：Bugfree、Bugzilla、TestLink、mantis
开源功能自动化测试工具：Watir、Selenium、MaxQ、WebInject
开源性能自动化测试工具：Jmeter、OpenSTA、DBMonster、TPTEST、Web ApplicationLoadSimulator
[TestDirector]：企业级测试管理工具，也是业界第一个基于Web的测试管理系统。
[Quality Center]：基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。
[QuickTest Professional]：用于创建功能和回归测试。
[LoadRunner]：预测系统行为和性能的负载测试工具。
1. 如何判断CPU、内存、磁盘的瓶颈？
2. 如何理解CPU、内存、磁盘之间的关系？
3. 如何理解paging in/paging out？
4. 如何监控操作系统的资源？（可以用一个操作系统做例子）
5. 如何理解内存管理和线程调度？（可以用一个操作系统做例子）
6. 如何理解CSwitch？（可以用一个操作系统做例子）
7. 如何理解磁盘IO？（可以用一个操作系统做例子）
网络
1. 如何定位数据包的传输在网络上消耗的时间？
2. 如何理解纯路由和NAT的区别？
性能工具
1. 解释LoadRunner的工作原理。
2. 如何理解LoadRunner里的关联？
3. 如何理解性能压力工具？
4. 如何理解虚拟用户？（可以用一个工具做例子）
5. 如果理解业务到脚本的转化？（可以用一个工具做例子）
6. 如何做到业务统计数据到场景的转化？（可以用一个工具做例子）
如何发现客户端软件中的内存泄露？
我的看法是：检测内存泄漏的问题应该尽早进行，它绝不应该是系统测试时的主要目标。也就是说，检查是否存在内存泄漏，应该从编码时就要考虑，单元测试和集成测试时要重点检查。如果前期没有考虑，等到了系统测试才想起检查或者才发现泄漏，为时已晚，此时再去定位泄漏的位置，太难太难了，它可能会让你的交付日期delay不确定的时间。最近看了一些自动错误预防（AEP）的理论，我深受启发。作为测试人员的我们，从“发现错误”转变到“帮助开发人员预防错误”，这将是一个巨大的转变。所以说，下面我的答案中的第一点，我先说如何预防内存泄漏的问题，然后再讲如何发现。
1 如何在开发过程中有效预防内存泄漏？
第一步：遵循“好”的编程规则
“好”的编程规则是各位前辈经验和教训的集合，好的编程规则堪称开发者的“圣经”。遵循统一的编程规则，可以让开发新手少走好多弯路，可以让项目整体的质量维持一个起码的“质量底线”。
有关内存泄漏方面的规则主要是“内存管理”方面的，举几个简单的，如下
×用malloc或new申请内存之后，立即检查指针值是否为NULL（防止使用指针值为NULL的内存）
×动态内存的申请与释放是否配对（防止内存泄漏）
×malloc语句是否正确无误？例如字节数是否正确？类型转换是否正确
×是否出现野指针，例如用free或delete释放了内存之后，忘记将指针设置为NULL
第二步：积极主动检测“内存泄漏”
严格遵循好的编程规则，可以让程序员在代码中尽量少的引入bug，但一旦不小心引入了，怎么办？这就要求我们在单元测试和集成测试中严格把关。
在这个阶段，单靠程序员或者测试员通过“代码走查”的方式检查内存泄漏，客户的实践和我的经验告诉我，这将是“不切实际”的，无论效率还是时间。如果能够借助于一些专业的工具的话，情况可能就不一样了。
如果你的程序是用Visual C++ 6.0开发，那么Numega的BoundsChecker将是你检测“内存泄漏”最好的选择，如果是Visual C++.NET，可以试一下Compuware的DevPartner。
如果你的程序基于Unix或者Linux平台，使用C或者C++，可以考虑一下开源的工具valgrind，我的朋友跟我说，它在一定程度上比Rational的Purify更出色。
上面的工具都要求程序能够动态运行起来，而且测试用例需要你自己准备。
如果你正处于单元测试或集成测试阶段，程序代码量已经足够大，而且还不能够动态运行，要尽早检测代码中的“内存泄漏”问题，该怎么办？此时你可以试用一下目前最新的静态分析技术：
×它不要求代码能够动态运行
×也不需要你来编写测试用例
×只需要代码能够正常编译，就可以发现代码只有在执行过程中才出现的错误，当然也包括内存泄漏。
这方面的工具有Klocwork的K7，Coverity的SQS，以及C++test中的BugDetective，其中最“物美价廉”的就是c++test的BugDetective。
2 如何发现客户端软件的“内存泄漏”？
如果开发过程中已经按照我上面提到的去做，相信发布后的程序存在“内存泄漏”的可能性几乎为零。
如果开发过程已经到了后期，系统测试已经开始做了，还要发现内存泄漏，这个时候我希望你能够拿到源代码。如果有源代码，你还可以考虑1中的第二步，借助于专业的工具协助，虽然可能效果不一定特别理想，但总比下面我提到的方法更好一些。
当然作为测试人员，我当然也理解事情总没有想像那么完美。我们通常会碰到“需要在系统测试阶段检测是否有内存泄漏，而且没有源代码”的难题。我曾经也遇到过。
记得那还是2002年的事情了。当时我承接的项目是一个电力行业的自动化系统，分为server端和client端，典型的c/s模式，老板要求在测试功能的同时顺便检查内存泄漏的问题，因为这个client 端在客户那里可能是长时间不间断运行的，虽然客户很少操作。我当时很为难，因为没有源代码，我甚至无法做“代码走查”。在做功能测试的同时，我一直在琢磨...... 采用什么手段呢？
最后，借助于WinRunner，我出色的完成了任务，起码我的老板相信我的测试是可信的。我的方法是这样的。
×首先咨询开发方，了解到关于内存操作频繁的功能点和模块
×从我的功能测试用例中挑选出和这些功能点和模块相关的测试用例
×找到一个“纯净”的机器，上面除了操作系统和被测的client端外，没有任何其他应用，这样做是为了排除其他应用可能存在的干扰。
×借助于WinRunner，自动化这些用例，形成自动化的脚本；在脚本的最后，添加“切换到Windows任务管理器”“记录该client进程所占用内存数据到文件”的操作脚本。
×连续运行N个小时
×最后我打开这个数据文件，可以发现在该客户端运行过程中，每次执行完特定的测试用例后，记录的内存占用数据。当时我得出的结论是该client程序有“少许”的内存泄漏，因为在连续运行了72小时后，内存使用增加了近百分之十几。我会把这些数据导入到EXCEL中绘成了一个图表，这样更直观一些。经过简单的计算（内存的增量/用例循环次数），得到用例每次执行后增加的内存使用值，即泄漏的内存数量，然后把操作过程和这个结果一起交给开发方，最后开发方根据我的信息，真的找到了一处有内存泄漏的地方，虽然泄漏的数量很少。
以上就是我有过的一个类似的经历，我觉得可以提供给大家参考，同时也可以“举一反三，融会贯通”。如B/S的客户端控件，可以用QTP协助完成。
在测试的最后阶段要去发现甚至定位内存泄漏挺难的，但只要发挥我们测试人员的主观能动性，总是找到一些“旁门左道”的测试手段。
最后，我个人认为，从时间成本和各种风险考虑，要避免内存泄漏的问题，还是要回到前期的预防，即编程过程的规则检查和单元测试阶段主动的检测。
1测试的目的是什么？
2. 测试分为那几个阶段？
3. 单元测试的测试对象，目的、测试依据、测试方法？
4. 集成测试的测试对象，目的、测试依据、测试方法？
5. 系统测试的测试对象，目的、测试依据、测试方法？
6. 测试覆盖的类型？
7. 性能测试的分类？
8. 列举您熟悉的主流自动化测试工具？
9. c/s和b/s结构的软件进行测试时有何不同？
10. 页面中有一个输入日期的输入框和一个输入身份证号的输入框，如何进行用例设计?
11. 测试和质量保证有什么区别你的看法？
12. 用过什么缺陷管理工具流程是什么有什么能改进的？
13. 你有没有用过QTP做项目，QTP的工作原理？
14 有一个说谎岛，上面居住着人还有吸血鬼，有一年岛上流行瘟疫，有一半的人和吸血鬼疯了，于是岛上有神志清醒的人和
精神错乱的人，还有神志清醒的吸血鬼和精神错乱的吸血鬼，其中神志清醒的人和精神错乱的吸血鬼只说真话，而精神错
乱的人和神志清醒的吸血鬼只说假话，并且他们回答问题只说“是”或“不是”；有一天岛上来了一位“逻辑博士”在岛
上遇见了P，博士问了一个问题就分出他是人还是吸血鬼，博士又问了一个问题就分辨出他是神志清醒的还是精神错乱的。
请写出博士问得两个问题；写出你的思路。
条件是：神志清醒的人和精神错乱的吸血鬼只说真话
精神错乱的人和神志清醒的吸血鬼之说假话
15 一天有个年轻人来到王老板店里买了一件礼物,这件礼物成本18元,标价21元。结果这个年轻人掏出100元来买这件礼物,王老
板当时没有零钱,用那100元向街坊换了100元的零钱,找给年轻人79元,但是街坊后来发现那100元是假钞,王老板无奈还了街坊
100元,问题是:王老板在这次交易中到底损失了多少钱?
软件测试面试时如何清楚明了的介绍做过的项目的基本情况？做了一段时间的软件测试（主要是web 测试，B/S架构的），想换份工作，但是每次面试官让我介绍一下项目的基本情况时，总是思路不清楚，不知道从何下手，因此总是以失败告终，所以我想问一下一般情况下要从哪方面开始介绍项目情况，面试官最想得到一个怎样的答案？
答：让你介绍项目,目的是想知道你参与过该项目后,对该项目的认识程度和认识层次,从而判断你在项目中到底起多大作用.你思路不清楚,如果不是因为语言表达能力有问题,就是平时根本没对项目进行思考,项目的业务,需求,设计,过程的组织,风险,问题的解决,你都没有任何概念和控制.说明你就是个普通的执行人员.要提高,就要从根本上提高.临阵磨枪的话,你可以试试自己打个草稿组织一下语言.
可以按照时间远近顺序说项目A，然后说项目A的主要内容，目的是做什么，你负责的工作，用到哪些测试方法，用了哪些测试工具，可能的话说出项目有多少人，最后结果是什么，是否成功了。然后说项目B。
作为一名测试人员，51真的是我们的精神家园，所以在收到OFFRE后决定给同样在寻找工作的朋友们一点自己的经历，今天主要说下面试的N家单位，都是杭州的。
一、恒生电子：由于我之前做过通信类产品测试，面的是他们的WIMAX岗位，是给NOKIA外包的。过去先做一套题，英文题目，有软件测试相关知识，wimax原理图，java编程，C语言编程等等，C语言题目是写strcpy/strcmp/strlen中的一个，由于没准备，所以我只做了测试相关题目。面试上来要我做个英文自我介绍，当时闷了，没准备，答得很郁闷。后面主要问以前的测试流程、测试相关知识等，最后看我简单的C题目没写出来，被狠狠BS了，当场告诉我不适合此岗位。第一次面试结束，彻底失败告终，要好好准备C和英文介绍。
二、H3C：过去首先做一套题，主要是C的，和HW差不多的题目。由于做了相应的准备，选择和填空基本完成，编程题没做。一面是测试的项目leader，主要以前的测试流程、测试相关知识，感觉不错，二面好像是HR主管，主要非技术问题，答的一般，三四面有技术和项目相关的问题，同样关注离职原因等。总体说来面后自我感觉良好，可惜还是挂了。
三、阿里 &淘宝：两个都是电话面试，对这种面试形式不太习惯，都在下班后来的电话，主要问测试技术相关知识，两个电话面的都没结果。
四、三维通信：上市公司，新大楼不错。先是HR的面试，问的很多，聊的蛮久的，后面是技术面试，感觉他们不是做纯粹软件测试，因为他们的产品大体是基站的扩放器之类，测试侧重点主要是看仪器。所以聊的不投机，也没消息。
五、三汇数字：先HR，后技术。主要是嵌入式产品，问我有没有白盒测试经验，我想做白盒还会来你这么，国内做这个也不多。不知道他们到底要招怎么样的人，成年挂在51上。
六、淘宝：阿里的扩招是千真万确的。这次直接面试，好像是搜索部门。先做题，linux基本命令，C 的strcmp原函数，一个用例设计题，对输入年月日做最多用例考虑。面的可能是是测试项目leadre，由于测试部分答的不错，C的那题还是没搞定，不过一周后还是给了2面。二面也做的相应准备，可惜的是还让写上次的C题目，超级郁闷，而且二面官问了些非常尖锐的问题，让我无从下手回答，很正常的挂了。后来在网上好好搜索了相关面试题目，发现还是自己准备不足。
继续在51上投，投了不下200份简历……..囊括本市所以测试岗位。
七、公众信息产业：主要给电信做项目，过去先做了一套测试题，轻松。后面的技术面试谈的主要是以前的测试流程和技术，也轻松。后来某天下午3点让我5点过去二面，由于预约了另一家公司，让他们改天，至今无音讯。估计找工作的人实在太多了。
八、支付宝：还是阿里旗下，阿里的人招不完啊，几乎占据论坛3分之一版面了，呵呵。没做题，直
接聊，主要测试相关，以前项目，问题比较细，问题也叼装，感觉阿里对招人要求还是很高的，虽然招的人多。聊了大概40分钟，两天后邮件通知挂。
九、3个个给阿里做外包的，由于自己已经面过阿里那边，所以都最后都无果。还有几个小公司，时间上冲突，没有再给机会。
十、给OFFER的公司：做一套题，涉及面非常广，C语言、数据库高级查询、用例发散设计、软件工程、项目管理知识、测试技术考的很细。面试是三对一，也是第一有这样的经历，刚开始蛮紧张的，问的问题之前的面试基本上问过。我只能说上帝给予了我这个职位。
离上班还有段时间，接下来重要深入学习LR和性能测试技术，数据库，linux，C编程，测试技术，希望有很好的准备和状态投入新公司。
多谢大家光顾，以后我也会把和测试相关的工作学习生活的内容写在这里，共同学习探讨。下面言归正传，说下我在这段时间面试碰到的题目，相信对大家准备面试会有帮助，多多支持！
先说笔试：一般的公司会通过笔试淘汰一部分不符合他们公司职位要求的人员，毕竟每个公司具体岗位不一样，总希望招到能尽快上手的人，就像你做了2年多的纯功能方面的测试，而人家希望有点编程能力的做性能方面的测试，估计你会在笔试中被淘汰。所以笔试也是很重要的部分，当然你够牛就直接面吧。
1. 编程基础，我不知道有多少做测试的朋友讨厌编程或者做软件开发，我个人是比较讨厌的，虽然学校里学的是计算机，但是到毕业也没正儿八经地写过超过百行的代码，但没写过不代表读不懂。所以选择填空还是可以应付的。对于可能的编程题，我是准备了一些如冒泡，折半算法、
strcpy/strcmp/strlen 原函数等。编程的能力是需要积累的过程，所以贵在平时。对于编程能力是否有助与测试这个论坛上讨论过的问题，我的观点是第一至少你找工作时用的着，第二如果做性能测试应该也需要，第三如果有2年以上的测试经历应该也会觉得非常有必要。本人也正硬着头皮再学c，虽然学了忘忘了学。
2.数据库知识，建议准备好sql语言，装个mysql自己通过敲命令，能掌握高级查询使用基本可以应对了。
3.软件测试理论，这个大家都不陌生，也是必考的了，应该可以轻松应付。要注意准备下web测试和性能测试这块，现在做web的公司好多。
4.根据公司具体的职位要求可以准备的有linux的命令，CMMI的基础知识，TCP/IP的基础知识，通信的如3G网络类知识等。
下面说面试：通过面试真的能看出很多，技术、经验、性格人品等，当然都是通过你的答题来让人家了解的。
1.请自我介绍一下。这个必答题。对于不善于表达的朋友要准备一把，我就是这种类型，好处是起码说起话来可以比较流利。说性格时可以提对做测试有优势点。
2.说说你以前公司的测试流程。必答题。主要结合自己的项目经验相信讲一个自己做过的项目，从立项到测试结束，当然侧重测试和自己所做的内容。这里面试官一般都会根据你说的再提问。
3.你是怎样做出自己的职业选择或者自己的职业规划。这题也经常问。可以从自己的优点说如何适合做软件测试，对与职业规划，我一般说在技术上往资深测试工程师发展。
4. 你觉得自己作为测试工程的优势在哪里？/你认为自己比你的同事优秀在哪里？也经常问，可以从性格出发，讲自己优点，以及在项目中表现，领导的良好评价等，总之“恰当”地往好处说，不要言过其实，让人怀疑你的人品哦。说说自己的缺点？这个也不好回答，最好能恰当地引申回答到优点上。
5.一个测试中不堪回首，或者让你很郁闷的事情。我被问到了，当时想不起来，后来想想可以讲一个项目中的失误及后果，然后讲自己如何去成功弥补及教训经验。我如果提前想一下就不会该说什么了。
6.你的好友是如何评价你的？你的项目组长是如何评价你的？这类题也经常问。回答总要往好处说，
但是你要自信地回答。
7.在成年后，哪些成绩给你带来最大程度的满足？蛮不错的题。记得我但是答的是第一次自己带一个小项目，顺利完成测试任务。
8.列举几个可能碰到的题，大家可以想想。
测试时你提交的bug被研发拒绝或者他认为不是问题，你如何处理？
测试与开发沟通如何提高效率和改善沟通效果？测试工程师的素质和技能？
你在压力下能工作的很好嘛？测试计划包括哪些？
9.你期望的薪水？问的很多啦，根据自己能力和公司的大小，可以搜索下了解下情况。在工作难找的情况下OFFER到手实在些，骑驴找马总容易很多。
关于这些面试题，自己想不好的可以网上搜搜，51上也有很多关于答题的技巧和答案。最后要说下心态，面试的时候自信最重要，自信也来自良好的准备，所以面多了总结下，下次就更自信了。想想没被录用只能说明公司不适合你，或者人家要不起你。说的废话蛮多的，最后希望Tester在自己的职业道路上走地顺利……
一、选择：
1. 从是否需要被执行测试软件的角度，软件测试可分为哪两种？（B）
A. 黑、白盒（软件测试用例设计方法角度）
B.静、动态
C.单、集（策略和过程）
2. 下列哪一项不是白盒测试？（C）
A.单元测试
B.集成测试
C.系统测试
D.回归测试
3. 计算机环路复杂度（计算方法）（重点：选择简答）
V(G)=简单判定节点数+ 1 ; V(G) = E-N+2 ; V(G)=封闭区域数+ 1 （记住这三个公式）
4. 属于黑盒测试的方法？(C)
A.基于基本路径
B.控制流
C.基于用户需求测试
D.逻辑覆盖
(基于用户需求的测试,功能图分析方法，等价类划分方法，边界值分析方法，错误推测方法，因果图方法，判定表驱动分析方法，正交实验设计方法和功能图分析方法等。)
5. 测试的报告由五部分。
答：首页、引言部分、测试概要、测试结果及缺陷分析、测试结论与建议。
6. 单元测试环境由三部分构成？
答：所测模块和与它相关的驱动模块及桩模块共同构成了一个“测试环境”
7. 单元测试中综合测试主要是考虑哪些方式？
答：自顶向下的单元测试策略、自底向上的单元测试策略。
8. 不是软件实施活动的进入准则？ (D)
A.需求工件已经被基线化
B.详细设计工件已经被基线化
C.构架工件已经被基线化
D. 项目阶段成果及被基线化
9. 确定单元测试指导的基本方针？（）（3个，选择其中不是的）
答：能够自身编译的最小程序块，单一过程/函数(独立)，由一个人完成的小规模工作
10. 对于自动化测试成本从高到底的排序，下列描述正确的是？（A）（PPT6 七章）(进行排序)
A. GUI，编译器，用户图形
11. 软件测试是软件开发的重要环节之一。按照软件开发过程可分为：单元测试、集成测试、系统测试、域测试等。
12. 软件测试的任务发现、改正软件错误（找错，修正）
13. 下面哪一项测试步骤中需要进行局部数据结构测试？（A）
A.单元测试
B.集成测试
C.确认测试
D.系统测试
14. 白盒测试是根据程序的（C）来选设计测试用例？
A.功能
B.性能
C.内部逻辑
D.内部数据
15. 单元测试的终止的标准（3个）（PPT47 三章）
1.硬件资源不足或故障造成软件运行无法运行；
2.软件运行后无法正确显示；
3.所有功能测试均已经完成。
16. 软件测试是对系统逆向求证的过程，集成测试对应的过程中单元测试的过程
A.需求设计
B.概要设计
C.详细设计
D.编码实现
17. 单元测试主要测试技术不包括？（B）（PPT12 三章）
A.白盒
B.功能
C.静态
D.以上都不是
19. 如果一个产品中次严重缺陷基本完成修复并且通过了复测，这个阶段的产品是（B）
A.阿尔法版
B.beta版
C.正版
D.以上都不是
20. 自底向上方法需要写（Ａ）
A. 驱动程序Ｂ．桩程序Ｃ．驱动程序和桩程序Ｄ．两个都不是
21. （A）的目的是对最终软件系统进行全面的测试确保最终软件系统产品满足需求。
Ａ．系统测试Ｂ．集成测试Ｃ．单元测试Ｄ．功能测试
22. 测试用例的4个关键元素。
(1) 被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用中间状态的情况)；
(2) 被测单元的输入，包含由被测单元读入的任何外部数据值；
(3) 该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如：单元中哪一个决策条件被测试；
(4) 测试用例的期望输出结果（在测试进行之前的测试说明中定义）。
23. 目前主要的单元测试的方法（A.基本路径测试 B.等价类划分/边界值分析测试 C.覆盖测试 D.循环测试 E.数据流测试 F.程序插桩测试 G变异测试）从中选。
24. 哪个方法根据输出输入依赖关系设计的测试用例？（C）？？？
A.路径
B.等价类
C.因果图
D.归纳
25. 有一组测试用例使得每一个被测试用例的分支覆盖至少被执行一次，它满足的覆盖标准（B）。（PPT22 二章）
A. 语句覆盖
B.判定覆盖
C.条件覆盖
D.路径覆盖
二、填空：
1. 单元测试中对类进行测试有3个“定义—引用对”（方法内部定义-引用对方法间定义-引用对类内部定义-引用对）。（PPt37 三章）
2. 测试的主要目标，不再只是找出其缺陷，而是证明其（性能）。
3. 压力测试又称强度测试，是在（各种资源超负荷）情况下，观察系统的运行情况。
4. （缺陷跟踪工具）是管理工具使用最多的。
5. 集成测试划分为5个阶段（制定集成测试的计划、设计集成测试、实施集成测试、执行集成测试、评估集成测试）。
6. 根据软件生命周期中的定义，可以把自动化测试工具划分3大类（白盒测试工具、黑盒测试工具、测试管理工具）。
7. 对类进行测试时，类之间的关系6类（关联泛化实现依赖聚合组合）。每种不同符号来表
示，并分别用（私有的“-”、公有的“+”、保护的“#”）三个关键字来修饰类。
8. 白盒测试工具针对代码进行的工具，测试中发现的缺陷可以定义到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。
9. 黑盒测试工具包括（功能测试工具、性能测试工具）。
10. 软件开发的基本过程（需求分析、设计、实现、测试、维护）。
11. 单元测试的策略（自顶向下的单元测试策略、自底向上的单元测试策略和孤立的单元测试策略）。
12. 集成测试的工作开展更多站在测试工作人员的角度上；系统测试站在用户的角度上。
13. 对面向对象来说，按照集成的粒度不同，可把集成测试分为（类间集成测试、类内集成测试）。
14. 类测试用例中，基于3个标准（基于状态的覆盖率、基于限制的覆盖率和基于代码的覆盖率）。
15. 哪一个不属于增量式集成？
答案：大爆炸集成
17. 单元测试中对类进行三级测试（方法内部测试、方法间测试、类内部测试）
18. 目前单元测试主要的方法：基于路径测试，等价类划分/边界值分析测试，覆盖测试，循环测试，数据流测试，程序插桩测试，变异测试。
三、判断：
1. 发现错误是软件测试的目的。（错）发现、改正错误
2. 白盒测试可以找出软件遗漏功能和代码错误功能。（PPT47 二章）（错）
3. 在设计测试用例时，应包括合理的应用条件和不合理的应用条件。（对）
4. 软件缺陷一定是由编码引起的错误。（错）
5. Bata测试是软件多个用户在实际。。。多个测试。。。（对）
6. 系统测试属白盒测试。（错）（黑盒）
7. 手工测试可以达到好的系统化测试。（对）
8. 功能测试属于白盒测试的技术范畴。（错）（黑盒）
9. 文档测试是对系统提交给用户的文档进行验证，并不是一般性的审查活动。P35 5（对）
四、大题
1. 计算环路复杂度方法哪些？（要求写成3个公式，一个公式2分）
答：V(G)=简单判定节点数+ 1 ; V(G) = E-N+2 ; V(G)=封闭区域数+ 1
2. 基于状态测试的主要步骤？（PPT32 三章）
答：①依据设计文档，或者通过分析对象数据成员的取值空间(笛卡尔积)，得到被测试类的状态转移图；
②给被测试的类加入用于设置和检查对象状态的新方法,导出对象的逻辑状态；
③对于状态转移图中的每个状态，确定该状态是哪些方法的合法起始状态，即在该状态时，对象允许执行哪些操作；
④在每个状态，从类中方法的调用关系图最下层开始，逐一测试类中的方法；
⑤测试每个方法时，根据对象当前状态确定出对方法的执行路径有特殊影响的参数值，将各种可能组合作为参数进行测试。
3. Bug的种类有哪些？
答：需求阶段的BUG，分析设计阶段的BUG，设计阶段的BUG，实现阶段的BUG，配置阶段的BUG，短视将来的BUG，静态文档的BUG 。
4. 自动化测试的缺点？（5点）
答：1、自动化测试不能取代手工测试，测试主要还是要靠人工的。
2、新缺陷越多，自动化测试失败的几率就越大。
3、工具本身不具有想象力
4、技术问题、组织问题、脚本维护
5、测试工具与其他软件的互操作性
5. 选择手动和自动化测试，为了作出一个合理的决定，需要做哪些方面假设？（7个）
答： 1．拥有稳定的自动化测试技术支持。
2．两种极端的可能性：一种就是无需人工干预的完全自动化测试，另一种就是只运行一次就废弃的人工测试。
3．自动化测试和手工测试都可行（但事实并非如此）。
4．测试是通过外部接口完成的（黑盒测试）。
5．不要求必须进行自动化测试。
6．测试已经设计好之后，再决定是否进行自动化测试。
7．有一定的时间用于完成测试，并且在这段时间里完全有可能把测试做好。
6. 集成测试分析方法有哪些？
答：体系结构分析模块分析接口分析风险分析可测试性分析集成测试策略分析
7. 编写类测试驱动程序的方法有很多种，以Java语言为例来说明，测试驱动程序设计的结构，并简要说明其优缺点。（PPT15 六章）
答：1.在main方法中写入需要运行的测试用例，即实现main方法，然后编译、执行该类。
缺点：不利于维护和复用，交付时，逐个剔除代码
2.在类中实现一个静态测试方法，通过调用该测试方法来收集每个测试用例的执行结果。
缺点：同1.
3.实现独立的测试类，它的职责是执行并收集每个测试用例的结果。
优点：可复用，支持回归测试
缺点：必须创建新类，关注被测试类的变化
8. 增量式集成和非增量式集成的概念和举例。？？？
答：非增量式测试：就是分别对系统中每个模块进行单元测试，然后将所有模块按照层次结构组装到一起进行测试，最终得到所要求的软件。
例如：大爆炸集成
增量式集成(或组装)：先对一个个模块进行模块测试，然后在组装过程中边连接边测试，以发现连接过程中产生的问题。
例如：自顶向下集成和自底向上集成
9. 制定集成测试计划时间，一般安排在概要设计评审通过后大约一个星期的时候
一、计划阶段
制定集成测试计划时间：一般安排在概要设计评审通过后大约一个星期的时候，参考需求规格说明书、概要设计文档、产品开发计划时间表来制定。
二、设计阶段
制定集成测试设计时间：一般在详细设计开始时，就可以着手进行。可以把需要规格说明书、概要设计、集成测试计划文档作为参考依据。
10. 列举出图中三个模块，写出全部模块执行路径，最后给出其MM路径（书162页）
1. 源节点：程序中的源节点是指程序执行开始或重新开始处的语句片断。
A：1，5节点 B：1，3节点 C：1节点
2．汇节点：汇节点是程序执行结束处的语句片断。这里转移控制到其它单元的节点也是汇节点。A：4，6节点 B：2，4节点 C：5节点
3．模块执行路径
模块执行路径是以源节点开始、以汇节点结束的一系列语句，中间没有插入汇节点。
在图4-12中有七条模块执行路径：图4-12 跨三个单元的MM-路径
模块执行路径如下：
MEP（A，1）=〈1，2，3，6〉
MEP（A，2）=〈1，2，4〉
MEP（A，3）=〈5，6〉
MEP（B，1）=〈1，2〉
MEP（B，2）=〈3，4〉
MEP（C，1）=〈1，2，4，5〉
MEP（C，1）=〈1，3，4，5〉
4. 消息
消息是一种程序设计语言机制，通过这种机制可以把控制从一个单元转移到另一个单元。
5. MM-路径(Method Message Path)是穿插出现模块执行路径和消息的序列。如图4-12中的粗线所示，代表模块A调用模块B，模块B调用模块C，这就是一个MM-路径，可用图4-13表示。对于传统软件来说，MM-路径永远是从主程序开始，在主程序中结束。
MM-路径如下：
11.设一个控制图如下，请给出其环路复杂度和基本路径。
环路复杂度：5
基本路径：路径1：1—2—3—5—6—12—13—15
路径2：1—2—4—5—6—12—13—15
路径3：1—2—3—5—7—8—13—15
路径4：1—2—4—5—7—8—13—15
路径5：1—2—3—5—7—9—10—14—13—15
路径6：1—2—4—5—7—9—10—14—13—15
路径7：1—2—3—5—7—9—11—14—13—15
路径8：1—2—4—5—7—9—11—14—13—15
12.软件测试活动的生命周期
测试周期分为计划、设计、实现、执行、总结。其中：
计划：对整个测试周期中所有活动进行规划，估计工作量、风险，安排人力物力资源，安排进度等；设计：完成测试方案，从技术层面上对测试进行规划；
实现：进行测试用例和测试规程设计；
执行：根据前期完成的计划、方案、用例、规程等文档，执行测试用例。
总结：记录测试结果，进行测试分析，完成测试报告。
13. 三明治集成方法
答：1. 确定以哪一层为界来决定使用三明治集成策略（在4-7中，我们确定以B模块为界）；
2. 对模块B及其所在层下面的各层使用自底向上的集成策略；
3. 对模块B所在层上面的层次使用自顶向下的集成策略;
4. 把模块B所在层各模块同相应的下层集成；
5. 对系统进行整体测试。
14. 集成测试可看着是体系结构分析工作基础之上的细化。可从哪几个角度进行模快分析。答： 1）确定本次要测试的模块；
2）找出与该模块相关的所有模块，并且按优先级对这些模块进行排列；
3）从优先级别最高的相关模块开始，把被测模块与其集成到一起；
4）然后依次集成其他模块。
缺陷等级等级名称等级定义
P1 严重缺陷应用系统崩溃或系统资源使用严重不足：
1、系统停机（含软件、硬件）或非法退出，且无法通过重启恢复；
2、系统死循环；
3、数据库发生死锁或程序原因导致数据库断连；
4、系统关键性能不达标。
5、数据通讯错误或接口不通
6、错误操作导致程序中断
P2 较严重缺陷系统因软件严重缺陷导致下列问题：
1、重要交易无法正常使用、功能不符合用户需求；
2、重要计算错误；
3、业务流程错误或不完整；
4、使用某交易导致业务数据紊乱或丢失；
5、业务数据保存不完整或无法保存到数据库。
6、周边接口出现故障（需考虑接口时效/数量等综合情况）；
7、服务程序频繁需要重启（每天2次或以上）；
8、批处理报错中断导致业务无法正常开展。
9、前端未合理控制并发或连续点击动作，导致后台服务无法及时响应。
10、在产品声明支持的不同平台下，出现部分重要交易无法使用或错误。
P3 一般性缺陷系统因软件一般缺陷导致下列问题：
1、部分交易使用存在问题，不影响业务继续开展，但造成使用障碍。
2、初始化未满足客户要求或初始化错误
3、功能点能实现，但结果错误；
4、数据长度不一致；
5、无数据有效性检查或检查不合理；
6、数据来源不正确；
7、显示/打印的内容或格式错误；
8、删除操作不给提示；
9、个别交易系统反应时间超出正常合理时间范围
10、日志记录信息不正确或应记录而未记录
11、在产品声明支持的不同平台下，出现部分一般交易无法使用或错误。
P4 较小缺陷系统因软件操作不便方面缺陷：
1、系统某些查询、打印等实时性要求不高的辅助功能无法正常使用；
2、界面错误
3、菜单布局错误或不合理
4、焦点控制不合理或不全面；
5、光标,滚动条定位错误；
6、辅助说明描述不准确或不清楚；
7、提示窗口描述不准确或不清楚；
8、日志信息不够完整或不清晰，影响问题诊断或分析的；
P5 其他缺陷系统辅助功能缺陷：
1、缺少产品使用、帮助文档、系统安装或配置方面需要信息；
2、联机帮助、脱机手册与实际系统不匹配
3、系统版本说明不正确；
4、长时间操作未给用户进度提示；
5、提示说明未采用行业规范语言；
6、显示格式不规范
7、界面不整齐
8、软件界面、菜单位置、工具条位置、相应提示不美观，但不影响使用
P6 建议、优化类建议优化类
?性能测试即测试软件处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
?有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍。
?在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影响软件的运行速度。
?性能测试的一些注意事项：
–不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。
–应当测试软件在标准配置和最低配置下的性能。
–为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应用软件（如杀毒软件）。
–不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从100K到1M 可以分成若干等级。
–由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。
健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
容错性测试通常构造一些不合理的输入来引诱软件出错，例如：
（1）输入错误的数据类型。如“猴”年“马”月。
（2）输入定义域之外的数值。如上海人常说的“十三点”
粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。
恢复测试重点考察一下几项：
（1）系统能否重新运行；
（2）有无重要的数据丢失；
（3）是否毁坏了其它相关的软件硬件。
?数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。每个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不
少。根据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。如果实际输出与期望的输出不一致，那么说明程序有错误。白盒方式的接口测试和黑盒方式的功能测试，其方法十分相似。
?一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。
对于非严格系统而言，在分析路径方面化费很多精力是不值得的。我认为在构造接口测试的同时已经建立了测试路径。因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。
由于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，不用得着费煞苦心地去找测试路径。
?路径测试的检查表
数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理
?由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。预防措施有：
观察是否有程序语句从来没有被执行过。如果发生在这种情况，要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一些路径。
要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。
减少冗余的测试
?白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。
?在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
减少无价值的测试
?无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。
如何“偷工减料”
?有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。
“偷工减料”方法的测试优先级：
?哪些功能是软件的特色？
?哪些功能是用户最常用的？
?如果系统可以分块卖的话，哪些功能块在销售时最昂贵？
?哪些功能出错将导致用户不满或索赔？
?哪些程序是最复杂、最容易出错的？
?哪些程序是相对独立，应当提前测试的？
?哪些程序最容易扩散错误？
?哪些程序是全系统的性能瓶颈所在？
?哪些程序是开发者最没有信心的？
在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。
不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
能否将系统测试和验收测试“合二为一”？
系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。
系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。