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次就是无价值的。
如何“偷工减料”
•
有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分（见下表），其它次要部分可以忽略或将来再测试。
“偷工减料”方法的测试优先级：
•
哪些功能是软件的特色？
• • • • • • • • 哪些功能是用户最常用的？
如果系统可以分块卖的话，哪些功能块在销售时最昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？
哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？
在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试?
不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。
既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？
首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。 不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。
能否将系统测试和验收测试“合二为一”？
系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。 系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。
由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？
如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。
如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？
要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。
黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。
–白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。
1、 为什么选择测试这个行业 2、 性能测试的流程、具体步骤 3、 进入测试行业后的职业发展方向 4、 测试人员与开发人员的沟通方法 5、 作为测试人员如何保证测试的质量 6、 对linux的熟悉程度，一些命令 7、 为什么转行做测试
笔试题：
1、 使用过的操作系统有哪些，各有什么特点 2、 显示文件目录的DOS命令是什么 3、 简述软件测试流程
4、 如何添加字体，如果修改区域设置 面试题： 1、 自我介绍
2、 介绍自己做过的最熟悉的测试项目
3、 回答对方举例的项目的测试用例（即对具体事物设计用例）
4、 对测试行业其他企业的了解情况（如微软测试项目、测试人员与开发人员的比例等） 建议：
面试时一般会随机出一些测试题，会让你口述测试用例， 计算机基础的东西要掌握一些，
你熟悉的音视频软件都有什么，比如千千静听、暴风影音，随便找几个看看如果测试都应该注意什么
这个文档是他们产品经理总结的最近的测试经验
产品质量有两个维度：外在品质和内在品质。 外在品质关系到用户对产品的第一感，出色的外在品
质能给用户带来专业，可靠的感觉，从而提升购买率。苹果的产品就是很好的例子，它能让用户直接感受到产品的美。
仔细反思最近发布的几款产品，策划会试用的时候提出的问题以外在品质问题为多，这些问题关系到用户对我们的产品的体验，同时提高起来也相对于内在品质要容易。
自己对于产品的关注上， 在保证功能的前提下，对产品的外在品质要下更多的心思。 具体关注点包括：
1） 界面逻辑清晰，操作流畅。
2） 按钮，控件的宽度，上下，左右对齐。
3） 按钮，控件，组框的相互关系，间距等。是否压边，显示不全。 4） 边缘像素细节，是否多了或少了。色彩。 5） 英语用词正确。大小写。 6） 标点符号。
7） 常用的单击和双击操作是否能正常进行。（如修改文件名，浮动图标等） 8） 常用键的支持。如Del，Ctrl+C, Ctrl+V等。 9） 输入框，按钮等功能是否符合常用习惯。 10) 控件，按钮布局合理，位置精心设计。 11）各页面风格一致。 12）字体一致并选用大小合适。
13）设计体现品牌风格（如Xilisoft和AVCWare的风格就很不一样） 14）同样功能，使用词汇前后一致，不同菜单用词一致。 15）菜单色彩。
16）大段文字的排版和可读性。
1功能测试 2 1.1链接测试 2 1.2表单测试 2 1.3数据校验 3 1.4 cookies测试 3 1.5数据库测试 3
1.6应用程序特定的功能需求 1.7设计语言测试 4 2性能测试 4 2.1连接速度测试 4 2.2负载测试 4 2.3压力测试 5 3用户界面测试 6 3.1导航测试 6 3.2图形测试 6 3.3内容测试 7 3.4表格测试 7 3.5整体界面测试 4兼容性测试 8 4.1平台测试 8 4.2浏览器测试 8 4.3分辨率测试 8 4.4 Modem/连接速率 4.5打印机 9 4.6组合测试 9 5安全测试 9 5.1目录设置 9 5.2登录 10 5.3日志文件 10 5.4脚本语言 10 6接口测试 10 6.1服务器接口 10 6.2外部接口 11 6.3错误处理 11
4
7
9
7结论 11
在Web工程过程中，基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同，它不但需要检查和验证是否按照设计的要求运行，而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是，还要从最终用户的角度进行安全性和可用性测试。然而，Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此，我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术 本文将web测试分为6个部分： 功能测试 性能测试（包括负载/压力测试） 用户界面测试
兼容性测试 安全测试 接口测试
本文的目的是覆盖web测试的各个方面，未就某一主题进行深入说明。 1功能测试 1.1链接测试
链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。
首先，测试所有链接是否按指示的那样确实链接到了该链接的页面； 其次，测试所链接的页面是否存在；
最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。
链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。 采取措施：采用自动检测网站链接的软件来进行。 推荐软件：
Xenu Link Sleuth免费 绿色免安装软件 HTML Link Validator共享（30天试用）
1.2表单测试
表单：可以收集用户的信息和反馈意见，是网站管理者与浏览者之间沟通的桥梁。 表单包括两个部分：一部分是HTML源代码用于描述表单（例如，域，标签和用户在页面上看见的按钮），另一部分是脚本或应用程序用于处理提交的信息（如CGI脚本）。不使用处理脚本就不能搜集表单数据。
表单通常是交由CGI（公共网关接口）脚本处理。CGI是一种在服务器和处理脚本之间传送信息的标准化方式。CGI脚本比较典型的是使用Perl语言编写，当然也有其他语言如C++，Java，VBScript或JavaScript。在创建交互表单之前，接洽您的ISP或服务器管理员以确认CGI脚本可以在您的服务器上运行。
表单由文本域、复选框、单选框、菜单、文件地址域、按钮等表单对象组成，所有的部分都包含在一个由标识符标志起来的表单结构中。
表单的种类有注册表、留言薄、站点导航条、搜索引擎等。 当用户通过表单提交信息的时候，都希望表单能正常工作。
如果使用表单来进行在线注册，要确保提交按钮能正常工作，当注册完成后应返回注册成功的消息。如果使用表单收集配送信息，应确保程序能够正确处理这些数据，最后能让顾客能让客户收到包裹。要测试这些程序，需要验证服务器能正确保存这些数据，而且后台运行的程序能正确解释和使用这些信息。 当用户使用表单进行用户注册、登陆、信息提交等操作时，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。 1.3数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。 在测试表单时，该项测试和表单测试可能会有一些重复。
1.2和1.3的采取措施：第一个完整的版本采用手动检查，同时形成WinRunner（QTP）脚本；回归测试以及升级版本主要靠WinRunner（QTP）自动回放测试。 1.4 cookies测试
Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。如果在cookies中保存了注册信息，请确认该cookie能够正常工作而且已对这些信息已经加密。如果使用cookie来统计次数，需要验证次数累计正确。
采取措施：1采用黑盒测试：采用上面提到的方法进行测试 2采用查看cookies的软件进行（初步的想法）
可以选择采用的软件 IECookiesView v1.50 Cookies Manager v1.1
1.5数据库测试
在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。
在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。 采取措施：暂时没有更好的测试方法 考虑结合到1.2和1.3的测试中 1.6应用程序特定的功能需求
最重要的是，测试人员需要对应用程序特定的功能需求进行验证。尝试用户可能进行的所有操作：下订单、更改订单、取消订单、核对订单状态、在货物发送之前更改送货信息、在线支付等等。这是用户之所以使用网站的原因，一定要确认网站能像广告宣传的那样神奇。 采取措施：深刻理解需求说明文档 1.7设计语言测试
Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要进行验证。 暂时没有方法测试，可以多参考一点讨论组内的更新信息
2性能测试
2.1连接速度测试
用户连接到Web应用系统的速度根据上网方式的变化而变化，他们或许是电话拨号，或是宽带上网。当下载一个程序时，用户可以等较长的时间，但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长（例如超过5秒钟），用户就会因没有耐心等待而离开。
另外，有些页面有超时的限制，如果响应速度太慢，用户可能还没来得及浏览内容，就需要重新登陆了。而且，连接速度太慢，还可能引起数据丢失，使用户得不到真实的页面。
2.2负载测试
负载测试是为了测量Web系统在某一负载级别上的性能，以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量，也可以是在线数据处理的数量。例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？
2.3压力测试
负载测试应该安排在Web系统发布以后，在实际的网络环境中进行测试。因为一个企业内部员工，特别是项目组人员总是有限的，而一个Web系统能同时处理的请求数量将远远超出这个限度，所以，只有放在Internet上，接受负载测试，其结果才是正确可信的。
进行压力测试是指实际破坏一个Web应用系统，测试系统的反映。压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃。黑客常常提供错误的数据负载，直到Web应用系统崩溃，接着当系统重新启动时获得存取权。 压力测试的区域包括表单、登陆和其他信息传输页面等。
负载/压力测试应该关注什么
测试需要验证系统能否在同一时间响应大量的用户，在用户传送大量数据的时候能否响应，系统能否长时间运行。可访问性对用户来说是极其重要的。如果用户得到“系统忙”的信息，他们可能放弃，并转向竞争对手。系统检测不仅要使用户能够正常访问站点，在很多情况下，可能会有黑客试图通过发送大量数据包来攻击服务器。出于安全的原因，测试人员应该知道当系统过载时，需要采取哪些措施，而不是简单地提升系统性能。 瞬间访问高峰
如果您的站点用于公布彩票的抽奖结果，最好使系统在中奖号码公布后的一段时间内能够响应上百万的请求。负载测试工具能够模拟X个用户同时访问测试站点。 每个用户传送大量数据
网上书店的多数用户可能只订购1-5书，但是大学书店可能会订购5000本有关心理学介绍的课本? 或者一个祖母为她的50个儿孙购买圣诞礼物(当然每个孩子都有自己的邮件地址) 系统能处理单个用户的大量数据吗? 长时间的使用
如果站点用于处理鲜花订单，那么至少希望它在母亲节前的一周内能持续运行。如果站点提供基于web的email服务，那么点最好能持续运行几个月，甚至几年。可能需要使用自动测试工具来完成这种类型的测试，因为很难通过手工完成这些测试。你可以想象组织100个人同时点击某个站点。但是同时组织100000个人呢。通常，测试工具在第二次使用的时候，它创造的效益，就足以支付成本。而且，测试工具安装完成之后，再次使用的时候，只要点击几下。 采取措施：采用测试工具WAS、ACT协助进行测试 3用户界面测试 3.1导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。
导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。
Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。 3.2图形测试
在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： （1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。 （2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩，最好能使图片的大小减小到30k以下
（5）最后，需要验证的是文字回绕是否正确。如果说明文字指向右边的图片，应该确保该图片出现在右边。不要因为使用图片而使窗口和段落排列古怪或者出现孤行。
通常来说，使用少许或尽量不使用背景是个不错的选择。如果您想用背景，那么最好使用单色的，和导航条一起放在页面的左边。另外，图案和图片可能会转移用户的注意力。 3.3内容测试
内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的”拼音与语法检查”功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓”相关文章列表”。 对于开发人员来说，可能先有功能然后才对这个功能进行描述。大家坐在一起讨论一些新的功能，然后开始开发，在开发的时候，开发人员可能不注重文字表达，他们添加文字可能只是为了对齐页面。不幸的是，这样出来的产品可能产生严重的误解。因此测试人员和公关部门一起检查内容的文字表达是否恰当。否则，公司可能陷入麻烦之中，也可能引起法律方面的问题。测试人员应确保站点看起来更专业些。过分地使用粗体字、大字体和下划线可能会让用户感到不舒服。在进行用户可用性方面的测试时，最好先请图形设计专家对站点进行评估。你可能不希望看到一篇到处是黑体字的文章，所以相信您也希望自己的站点能更专业一些。 最后，需要确定是否列出了相关站点的链接。很多站点希望用户将邮件发到一个特定的地址，或者从某个站点下载浏览器。但是如果用户无法点击这些地址，他们可能会觉得很迷惑。
3.4表格测试
需要验证表格是否设置正确。用户是否需要向右滚动页面才能看见产品的价格？把价格放在左边，而把产品细节放在右边是否更有效? 每一栏的宽度是否足够宽，表格里的文字是否都有折行？是否有因为某一格的内容太多，而将整行的内容拉长? 3.5整体界面测试
整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 对所有的用户界面测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。
采取措施：手动测试，参与人员最好有外部人员 4兼容性测试
检查项 测试人员的类别及其评价
系统能在各种软/硬件条件下运行吗？具体有哪些呢？ 系统支持多种操作平台吗？支持多种浏览器吗？ 系统对AD/FireWall敏感吗？ 4.1平台测试
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。 4.2浏览器测试
浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，JavaScript是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。
测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。 4.3分辨率测试
页面版式在640x400、600x800或1024x768的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐? 4.4 Modem/连接速率
是否有这种情况，用户使用28.8 modem下载一个页面需要10分钟，但测试人员在测试的时候使用的是T1专线? 用户在下载文章或演示的时候，可能会等待比较长的时间，但却不会耐心等待首页的出现。最后，需要确认图片不会太大。 4.5打印机
用户可能会将网页打印下来。因此网也在设计的时候要考虑到打印问题，注意节约纸张和油墨。有不少用户喜欢阅读而不是盯着屏幕，因此需要验证网页打印是否正常。有时在屏幕上显示的图片和文本的对齐方式可能与打印出来的东西不一样。测试人员至少需要验证订单确认页面打印是正常的。 4.6组合测试
最后需要进行组合测试。600x800的分辨率在MAC机上可能不错，但是在IBM兼容机上却很难看。在IBM机器上使用Netscape能正常显示，但却无法使用Lynx来浏览。如果是内部使用的web站点，测试可能会轻松一些。如果公司指定使用某个类型的浏览器，那么只需在该浏览器上进行测试。如果所有的人都使用T1专线，可能不需要测试下载施加。(但需要注意的是，可能会有员工从家里拨号进入系统) 有些内部应用程序，开发部门可能在系统需求中声明不支持某些系统而只支持一些那些已设置的系统。但是，理想的情况是，系统能在所有机器上运行，这样就不会限制将来的发展和变动。 采取措施：根据实际情况，采取等价划分的方法，列出兼容性矩阵 B\\DS XP VISTA 5安全测试
即使站点不接受信用卡支付，安全问题也是非常重要的。Web站点收集的用户资料只能在公司内部使用。如果用户信息被黑客泄露，客户在进行交易时，就不会有安全感。 5.1目录设置
Web安全的第一步就是正确设置目录。每个目录下应该有index.html或main.html页面，这样就不会显示该目录下的所有内容。我服务的一个公司没有执行这条规则。我选中一幅图片，单击鼠标右键，找
到该图片所在的路径”…com/objects/images”。然后在浏览器地址栏中手工输入该路径，发现该站点所有图片的列表。这可能没什么关系。我进入下一级目录 “…com/objects” ，点击jackpot。在该目录下有很多资料，其中引起我注意的是已过期页面。该公司每个月都要更改产品价格，并且保存过期页面。我翻看了一下这些记录，就可以估计他们的边际利润以及他们为了争取一个合同还有多大的降价空间。如果某个客户在谈判之前查看了这些信息，他们在谈判桌上肯定处于上风。 5.2 SSL
很多站点使用SSL进行安全传送。你知道你进入一个SSL站点是因为浏览器出现了警告消息，而且在地址栏中的HTTP变成HTTPS。如果开发部门使用了SSL，测试人员需要确定是否有相应的替代页面(适用于3.0以下版本的浏览器，这些浏览器不支持SSL。当用户进入或离开安全站点的时候，请确认有相应的提示信息。是否有连接时间限制？超过限制时间后出现什么情况？
SSL的英文全称是 “Secure Sockets Layer” ，中文名为 “ 安全套接层协议层 ” ，它是网景
（ Netscape ）公司提出的基于WEB应用的安全协议。 SSL协议指定了一种在应用程序协议（如HTTP 、 Telenet 、 NMTP和FTP等）和TCP/IP协议之间提供数据安全性分层的机制，它为TCP/IP连接提供数据加密、服务器认证、消息完整性以及可选的客户机认证。
VPN SSL 200设备网关适合应用于中小企业规模，满足其企业移动用户、分支机构、供应商、合作伙伴等企业资源（如基于Web的应用、企业邮件系统、文件服务器、 C/S应用系统等）安全接入服务。企业利用自身的网络平台，创建一个增强安全性的企业私有网络。 SSL VPN客户端的应用是基于标准Web浏览器内置的加密套件与服务器协议出相应的加密方法，即经过授权用户只要能上网就能够通过浏览器接入服务器建立SSL安全隧道。 5.3登录
有些站点需要用户进行登录，以验证他们的身份。这样对用户是方便的，他们不需要每次都输入个人资料。你需要验证系统阻止非法的用户名/口令登录，而能够通过有效登录。用户登录是否有次数限制? 是否限制从某些IP地址登录? 如果允许登录失败的次数为3，你在第三次登录的时候输入正确的用户名和口令，能通过验证吗? 口令选择有规则限制吗? 是否可以不登陆而直接浏览某个页面？
Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。（超时的限制是安全性机制） 5.4日志文件
在后台，要注意验证服务器日志工作正常。日志是否记所有的事务处理? 是否记录失败的注册企图? 是否记录被盗信用卡的使用? 是否在每次事务完成的时候都进行保存? 记录IP地址吗? 记录用户名吗? 5.5脚本语言
脚本语言是常见的安全隐患。每种语言的细节有所不同。有些脚本允许访问根目录。其他只允许访问邮件服务器，但是经验丰富的黑客可以将服务器用户名和口令发送给他们自己。找出站点使用了哪些脚本语言，并研究该语言的缺陷。还要需要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。最好的办法是订阅一个讨论站点使用的脚本语言安全性的新闻组。 6接口测试
在很多情况下，web站点不是孤立。Web站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
6.1服务器接口
第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。 这种测试可以归到功能测试中的表单测试和数据校验测试中 6.2外部接口
有些web系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用web接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如
果商店只使用Visa卡和Mastercard卡， 可以尝试使用Discover卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如3表示American Express，4表示Visa，5表示Mastercard，6代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。 这种情况在远程抄表中可能会体现到 6.3错误处理
最容易被测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断web服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况 7结论
无论你在测试internet、intranet或者是extranet应用程序，web测试相对于非web测试来说都是更具挑战性的工作
alpha测试和beta测试的区别
定义：alpha测试是在用户组织模拟软件系统的运行环境下的一种验收测试，由用户或第三方测试公司进行的测试，模拟各类用户行为对即将面市的软件产品进行测试，试图发现并修改错误。
Beta测试是用户公司组织各方面的典型终端用户在日常工作中实际使用beta版本，并要求用户报告异常情况，提出批评意见。
区别：两者的主要区别是测试的场所不同。Alpha测试是指把用户请到开发方的场所来测试，beta测试是指在一个或多个用户的场所进行的测试。Alpha测试的环境是受开发方控制的，用户的数量相对比较少，时间比较集中。而beta测试的环境是不受开发方控制的，谁也不知道用户如何折磨软件，用户数量相对比较多，时间不集中。一般地，alpha测试先于beta测试执行。通用的软件产品需要较大规模的beta测试，测试周期比较长。如果产品通过了beta测试，那么就可以正式发行了。 联系 Alpha测试 Beta测试 经过Alpha测试调整的软件产品称为Beta版本。一些软件开发公司把Alpha测试是对一个早期的、不稳定的软件版本所进行的验收测试，而Beta测试看成是对一个晚期的、更加稳定的软件版本所进行的验收测试。 开发方的场所 受开发方控制 相对比较少： 用户或第三方测试公司 用户的场所（终端用户） 不受开发方控制 相对比较多：终端用户 区测试场所 别 测试环境 测试方 时间 一般
比较集中（每日提交报告，及时修改缺陷） 不集中：用户记录统一报告 Alpha测试先于Beta测试执行。通用的软件产品需要较大规模的Beta测试，测试周期比较长。如果产品通过了Beta测试，那么就可以正式发行了。 回归测试：
是指软件系统被修改或扩充（如系统功能增强或升级）后重新进行的测试，是为了保证对软件所做的修改没有引入新的错误而重新进行的测试。 回归测试过程：
1识别出软件中被修改的部分
2从原基线测试用例库T中，排除所有不再适用的测试用例，确定对新版本依然有效的测试用例，建立新的基线测试用例库TN
3依据一定的策略从TN中选择测试用例测试被修改的软件
4如果必要，生成新的测试用例集T1，用于测试TN无法充分测试的软件部分 5用T1执行修改后的软件
第2和第3步测试验证修改是否破坏了现有的功能，第4和第5步测试验证修改工作本身
回归测试的一些观念：
回归测试是指重复以前的全部或部分的相同测试。
新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。 回归测试的重心，以关键性模组为核心。
系统验收测试
1）系统验收测试是在在系统测试完成后，项目最终交付前进行。
2）系统验收测试不是对系统的全面覆盖，而是针对用户的核心业务流程进行测试。 3）验收测试的执行人员不是开发方的测试组成员，是由用户方的使用人员完成。 4）验收可以由第三方专业化全覆盖型技术测试团队测试。
系统测试定义：
系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或者模拟运行（使用）环境下，对计算机系统进行一系列测试。 系统测试包含：
功能测试、性能测试、压力测试、容量测试、安全性测试、GUI测试、可用性测试（也叫易用性测试）、安装测试、配置测试、异常测试,备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试。
非增量式集成:这种方法容易出现混乱。因为测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。 常见但不好… 增量式集成：
自顶向下:它从主控模块开始，按照软件的控制层次结构，以深度优先或广度优先的策略，逐步把各个模块集成在一起。（桩模块不好写出来）
自底向上:自底向上测试是从原子模块（即软件结构最低层的模块）开始组装测试，因测试到较高层模块时，所需的下层模块功能均已具备，所以不再需要桩模块。 （不用桩模块，驱动程序好写） 自顶向下：广度优先、深度优先 自顶向下步骤：
1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代； 2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块； 3 每集成一个模块立即测试一遍；
4 只有每组测试完成后，才着手替换下一个桩模块；
5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 自底向上步骤：
1 把低层模块组织成实现某个子功能的模块群（cluster）; 2 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出； 3 对每个模块群进行测试；
4 删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。
从第一步开始循环执行上述各步骤，直至整个程序构造完毕。
集成测试：按设计要求把通过单元测试的各个模块连接起来，组成所规定的软件系统的过程中所进行的测试为集成测试。主要任务是要求软件系统符合实际软件结构，发现与接口有关的各种错误。 1）数据经过接口可能丢失；
2）个模块对另一模块可能造成不应有的影响； 3）几个子功能组合起来不能实现主功能； 4）误差不断积累达到不可接受的程度； 5）全局数据结构出现错误
语句覆盖 程序中每个语句至少都能被执行一次。
判定覆盖 程序中的每一个分支至少都通过一次（每个判定都取过真值假值）==也叫分支覆盖。
条件覆盖 使得判定中的每个条件获得各种可能的结果（真值假值）。
判定/条件覆盖 分支中每个条件取到各种可能的值(真假值)，每个分支（判定）取到各种可能的结果（真假值）。
条件组合覆盖 使得每个判定中条件取值的各种可能组合都至少出现一次。 路径覆盖 覆盖程序中所有可能的路径。
覆盖的优缺点：
语句覆盖法：可以很直观地从源代码得到测试用例，无须细分每条判定表达式 ；该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&&错误的写成了||，则上面的测试用例仍可以覆盖所有的执行语句。 一般认为“语句覆盖”是很不充分的一种标准，是最弱的逻辑覆盖准则。
判定覆盖法： 能够满足条件覆盖的要求，但是也不能对判断条件进行检查；
“分支覆盖”比“语句覆盖”严格，因为如果每个分支都执行过了，则每个语句也就执行过了。但是，“分支覆盖”还是很不够的。
条件覆盖法：“条件覆盖”通常比“分支覆盖”强，因为它使一个判定中的每一个条件都取到了两个不同的结果，而判定覆盖则不保证这一点。
要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。
判定/条件覆盖法：分支/条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件。
条件组合覆盖法：上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe
路径覆盖法：这种测试方法可以对程序进行彻底的测试，比前面五种的覆盖面都广 ；由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长(而指数级增长通常是设计算法时要尽力避免的)
软件测试目的
1、测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行； 2、好的测试用例在于发现至今未发现的错误； 3、成功的测试是发现了至今未发现的错误的测试；
4、好的测试工程师应该做到不仅发现问题，还能够帮助开发人员分析问题； 测试人员在软件开发过程中的任务： 1、尽可能早的找出系统中的Bug； 2、避免软件开发过程中缺陷的出现； 3、衡量软件的品质，保证系统的质量；
4、关注用户的需求，并保证系统符合用户需求。 软件测试的原则：
1、应把“尽早和不断地进行软件测试”作为软件开发者的座右铭，实践证明单元测试能够尽早发现问题，减少后期测试的错误量。
2、测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。 3、应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）
4、测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题的输入条件。
5、充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。 6、严格执行测试计划，排除测试的随意性。
测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。 7、应当对每一个测试结果做全面的检查。
8、妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。
软件测试过程
开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
集成测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
1. 尽快熟悉软件的需求和业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷
2. 把自己当成用户，把自己当成是用户去使用该系统，比如在使用该系统过程中是这样操作的吗？ 3. 善于怀疑，不要开发人员的能力
4. 不要让程序开发人员的观点：“用户不会进行这样的操作”而说服自己
5. 使用完整的流程去测试软件系统，有些子流程在单独测试时没有问题，但按流程走的时候问题就可能出来了。
ISO 9241-11：产品在特定使用环境下为特定用户用于特定用途时所具有的有效性（effectiveness）、效率（efficiency）和用户主观满意度（satisfaction）。
有效性 ：用户完成特定任务和达到特定目标时所具有的正确和完整程度。 效率 ：用户完成任务的正确和完整程度与所使用资源（如时间）之间的比率。 满意度：用户在使用产品过程中所感受到的主观满意和接受程度。
可用性测试一般是在一定环境条件下（可用性实验室），让用户执行测试，观察用户的反映，找到系统的缺陷和需要改进的地方 国内现状：测试人员模拟用户
有些公司采用交换各项目组测试人员的方式组织专门的可用性测试
可用性测试可以从下面几个方面考虑 能否成功的完成一个任务
对于普通用户，完成典型任务需要多长时间 完成典型任务需要访问的的页面数
系统是否提供了层次结构明确、表达清楚的导航功能 对整个系统的感觉如何（形式） 信息是否正确、精确（内容）
帮助系统是否准确并且容易使用 系统是否提供搜索、网站地图等功能 页面下载时间用户能否接受
面向Web应用系统的测试与传统的软件测试不同，不仅需要检查和验证是否按照需求规格说明书的要求运行，而且还要测试Web应用系统在不同浏览器上显示是否符合要求，与不同的数据库连接是否有效、更重要的是在性能、安全性、可用性等方面 功能测试 性能测试 安全性测试
配置和兼容性测试 可用性测试
链接测试
链接是Web应用系统用户界面的主要特征，它指引着Web用户在页面之间切换，以完成Web应用系统的功能 测试重点 链接是否正确 链接页面是否存在
是否有孤立的页面（没有链接指向的页面）
表单测试
表单(Form)是指网页上用于输入和选择信息的文本框、列表框和其他域，实现用户和Web应用系统的交互，当用户给Web应用系统管理员提交信息时，需要使用表单操作，如用户注册、登录、信息提交、查询等 测试重点
表单控件的正确性
提交信息的完整性、正确性 是否有错误处理
Cookie测试
Cookie通常标识用户信息，记录用户状态 。
使用Cookie技术，当用户使用Web应用系统时，能够在访问者的机器上创立一个叫做Cookie的文件，把部分信息（访问过的页面、登录用户名、密码等）写进去，来标识用户状态。如果该用户下次再访问这个Web应用系统，就能够读出这个文件里面的内容，正确标识用户信息
如果Web应用系统使用了Cookie，必须检查Cookie是否能正常工作，是否按预定的时间进行保存内容
设计语言测试
在Web应用系统开发初始，根据软件工程的要求用文档的形式确定Web应用系统使用哪个版本的HTML标准，允许使用何种脚本语言及版本，允许使用何种控件，这样可以有效的避免Web应用系统开发过程中出现设计语言问题。 其他测试 数据库测试
面向任务、业务逻辑的测试 探查性测试 回归测试 速度测试：
对于最终的Web应用系统用户而言，最关心的性能问题是访问Web应用系统页面时，多长时间才能显
示出来所需要的页面
通常情况下，响应时间不超过5秒
有些Web应用系统有超时限制，如果响应时间太慢，用户可能还没来得及浏览内容，就需要重新登录了
影响响应时间的原因有很多
应用程序服务器需要从数据库的大量数据中检索信息 服务器硬件影响（CPU、内存） 所访问页面文件大小 网络连接带宽
负载测试
负载测试是为了测量Web应用系统在一定负载情况下的系统性能，通常得出的结论是Web应用系统在一定的硬件条件下可以支持的并发用户数目或者单位时间数据（或事件）的吞吐量。
在进行负载测试前，需要定义标准用户（活动用户）的概念，定义执行典型的系统流程，定义负载测试执行总时间，定义抓取哪些事务的平均响应时间，定义用户可以接受的平均响应时间（通常为5秒）
测试时，增加用户数量，平均响应时间就会增加，当达到用户可以接受的平均响应时间这个临界点，即是此系统可以支持的并发用户数
压力测试
对Web系统进行压力测试，类似于普通机械、电子产品进行的破坏性试验。方法是实际破坏Web应用系统，测试系统的反应
压力测试是测试系统的限制和故障恢复能力，也就是测试Web应用系统会不会崩溃，在什么情况下会崩溃，崩溃以后会怎么样。
在Web应用系统性能测试过程中，常常将压力测试和负载测试结合起来。在负载测试的基础上，增大负载量，直到系统崩溃 实施性能测试需要注意 测试工具灵活使用 性能测试计划的制定
由于数据库安全性导致的Web应用系统安全性问题 Access数据库文件被下载
用户重要信息没有经过加密而存于数据库中
确认操作系统安全性 ，避免因操作系统漏洞导致Web应用程序的安全性问题 Web应用系统多采用登录的方式，产品发布时提供默认的管理员用户名和密码 确保应用系统实际应用中可修改默认管理员帐号和密码 用户名和密码设置要求（长度、大小写敏感、复杂度） 允许错误登录的次数
是否可以不登录而直接浏览某个页面
保证日志文件记录了Web应用系统的主要操作过程，并可根据日志文件追查到系统使用情况；同时还需要保证日志文件本身的安全性、完整性，防止被入侵者删除、获得
当Web应用系统采用了SSL等加密技术之后，需要确认加密、解密后信息传递的正确性和完整性
需要确认Web应用系统是否有超时设置，如有，则保证在超时设置时间内，如果未操作Web应用系统，当再次访问系统，需要重新登录
了解安全漏洞信息，避免Web应用系统中出现的漏洞被入侵者利用；及时升级补丁程序，提高系统安全性
Web应用系统多采用分布式体系结构，服务器端通常包括Web服务器组件、数据库服务器组件等。服务器还可能运行在不同的操作系统上，并且这些组件、操作系统等还可以有不同的配置方法，所以针对服务器的兼容性测试往往工作量较大
针对客户端浏览器的配置和兼容性测试是必不可少的，并且占据了Web应用系统客户端配置和兼容性测试的大部分时间
典型的应用服务器： Web服务器：
通过MS IIS、BEA Weblogic、IBM Websphere、Tomcat、Sun J2EE Application、Apache等中间件、插件，提供Internet/Intranet Web服务，实现与众多客户之间的数据交换和共享
数据库服务器
主要提供数据库查询、处理的平台，通过Oracle、SQLServer、Informix、DB2、Sybase、MySQL等中大型的数据库管理系统来构建 实时通信服务器
提供数据实时通信、消息传递等服务，如MSN、Yahoo message和ICQ等专用服务器 服务器端配置和兼容性测试内容 Web服务器 数据库服务器 防火墙 操作系统 硬件兼容性
软件验收标准 1 验收内容 a) 功能项测试
对软件需求规格说明书中的所有功能项进行 测试。
b) 业务流程测试
对软件项目的典型业务流程进行测试。 c) 容错测试
容错测试的检查内容包括:
1) 软件对用户常见的误操作是否能进行提示; 2) 软件对用户的的操作错误和软件错误, 是 否有准确、清晰的提示;
3) 软件对重要数据的删除是否有警告和确认 提示;
4) 软件是否能判断数据的有效性, 屏蔽用户的错误输入, 识别非法值, 并有相应的错误提示。
d) 安全性测试
安全性测试的检查内容包括:
1) 软件中的密钥是否以密文方式存储;
2) 软件是否有留痕功能, 即是否保存有用户的操作日志; 3) 软件中各种用户的权限分配是否合理。 e) 性能测试
对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明书中的各项性能指标。 f ) 易用性测试
易用性测试的内容包括:
1) 软件的用户界面是否友好, 是否出现中英文混杂的界面;
2) 软件中的提示信息是否清楚、易理解, 是否存在原始的英文提示; 3) 软件中各个模块的界面风格是否一致; 4) 软件中的查询结果的输出方式是否比较直 观、合理。 g) 适应性测试
参照用户的软、硬件使用环境和需求规格说明书中的规定, 列出开发的软件需要满足的软、硬件环境。对每个环境进行测试。 h) 文档测试
用户文档包括: 安装手册、操作手册和维护手册。 对用户文档测试的内容包括:
1) 操作、维护文档是否齐全、是否包含产品使用所需的信息和所有的功能模块; 2) 用户文档描述的信息是否正确, 是否没有歧义和错误的表达;
3) 户文档是否容易理解, 是否通过使用适当的术语、图形表示、详细的解释来表达; 4) 用户文档对主要功能和关键操作是否提供应用实例; 5) 用户文档是否有详细的目录表和索引表。 i) 用户有特别要求的测试。 2 验收标准
1) 测试用例不通过数的比例< 3 %; 2) 不存在错误等级为1 的错误; 3) 不存在错误等级为2 的错误; 4) 错误等级为3 的错误数量≤ 10; 5) 所有提交的错误都已得到更正。
测试已经被论证是提高软件系统质量的有效方法。 •测试有自己特定的思维方式和技术、方法
•大多数的项目经理缺少测试方面的经历，无法进行合理的工作安排
•大多数的项目经理无法平衡处理质量与开发进度，所以往往导致进度优先于质量，出现这种短暂的项目管理方式。
•由于缺少有效的测试项目管理,经常导致测试人员成为了项目组中的打杂工,无法专注于专业的测试.
•经常出现测试工作目标不明确
•由于没有软件测试项目存在，所以就不会详细的质量管理计划，导致无法有计划地完成测试任务
•测试工作经常得不到有效的资源支持.
同一场景
1.小用户量的情况下测试 2.大用户量情况下的测试 分析的方法：
整个系统架构分析，系统响应时间消耗，利用图表分析
查看事务响应时间，通过事务摘要图分析事务响应时间，那个消耗最大（通过小用户量和大用户量的响应时间分析，查看那个事务响应时间最高），确定哪部分功能是性能的瓶颈，分析window resource图表，查看cpu 使用下列计数器标识cpu瓶颈 Processor\\ Interrupts/sec Processor\\ % Processor Time
Process(process)\\ % Processor Time System\\ Processor Queue Length
通过它来确定是否硬件本身出现瓶颈，或者进一步确定应该怎么去判断性能产生瓶颈的地方！
下一步去判断进程，那个进程消耗cpu最高
下边就有很多种情况需要你自己去判断，有可能是进程调用了的函数消耗了系统资源形成上边的问题，也有可能是后台数据库出现的问题（这个就要看你的系统配置是什么样的，比如你的db服务器和应用服务器都配置在一台机器上）
性能产生瓶颈有很多地方，所以需要进一判断，是否是后台数据库的问题还有待分析，是那条语句导致的问题需要进一步分析判断。 分析原则：
• 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
• 查找瓶颈时按以下顺序，由易到难。
服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。 • 分段排除法 很有效 分析的信息来源：
•1 根据场景运行过程中的错误提示信息 •2 根据测试结果收集到的监控指标数据 一．错误提示分析 分析实例：
1 •Error: Failed to connect to server “10.10.10.30:8080″: [10060] Connection •Error: timed out Error: Server “10.10.10.30″ has shut down the connection prematurely 分析：
•A、应用服务死掉。
（小用户时：程序上的问题。程序上处理数据库的问题） •B、应用服务没有死
（应用服务参数设置问题）
例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的 AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％ •C、数据库的连接 (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）) 2 Error: Page download timeout (120 seconds) has expired 分析：可能是以下原因造成
•A、应用服务参数设置太大导致服务器的瓶颈 •B、页面中图片太多
•C、在程序处理表的时候检查字段太大多 二．监控指标数据分析 1．最大并发用户数：
应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。
在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。 2．业务操作响应时间：
• 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
• 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
• 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问题
3．服务器资源监控指标： 内存： 1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。
2 Windows资源监控中，如果Process\\Private Bytes计数器和Process\\Working Set计数器的值在长时间内持续升高，同时Memory\\Available bytes计数器的值持续降低，则很可能存在内存泄漏。
内存资源成为系统性能的瓶颈的征兆: 很高的换页率(high pageout rate); 进程进入不活动状态;
交换区所有磁盘的活动次数可高; 可高的全局系统CPU利用率;
内存不够出错(out of memory errors) 处理器：
1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 合理使用的范围在60%至70%。
2 Windows资源监控中，如果System\\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。 CPU资源成为系统性能的瓶颈的征兆: 很慢的响应时间(slow response time)
CPU空闲时间为零(zero percent idle CPU)
过高的用户占用CPU时间(high percent user CPU) 过高的系统占用CPU时间(high percent system CPU)
长时间的有很长的运行进程队列(large run queue size sustained over time) 磁盘I/O：
1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。 I/O资源成为系统性能的瓶颈的征兆 :
过高的磁盘利用率(high disk utilization)
太长的磁盘等待队列(large disk queue length)
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O) 太高的物理I/O速率:large physical I/O rate(not sufficient in itself) 过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself)) 太长的运行进程队列，但CPU却空闲(large run queue with idle CPU) 4．数据库服务器：
SQL Server数据库：
1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。 2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。
Oracle数据库：
1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
快存（共享SQL区）和数据字典快存的命中率：
select(sum(pins-reloads))/sum(pins) from v$librarycache; select(sum(gets-getmisses))/sum(gets) from v$rowcache;
自由内存： select * from v$sgastat where name=’free memory’; 2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。 缓冲区高速缓存命中率：
select name,value from v$sysstat where name in (‘db block gets’, ‘consistent gets’,'physical reads’) ;
Hit Ratio = 1-(physical reads / ( db block gets + consistent gets)) 3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。 日志缓冲区的申请情况 ：
select name,value from v$sysstat where name = ‘redo log space requests’ ; 4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。 内存排序命中率 ： select round((100*b.value)/decode(.value+b.value), 0, 1, .value+b.value)), 2)from v$sysstat a, v$sysstat b where a.name=’sorts (disk
1.如果web服务器、数据库以及网络都正常，问题会出在哪里？ 这个问题可以在系统本身，还是在应用服务器中的代码。 2.如何发现web服务器的相关问题？
利用网络资源的监控，我们可以找到的Web服务器的性能。利用这些监测分析吞吐量我们可以在Web服务器上，点击数每秒
期间发生的情况下，一些HTTP响应每秒下载的人数页每秒。 3.如何发现数据库的相关问题？
运行“数据库”的监督和帮助下， “数据资源图”我们可以找到数据库有关的问题。例如您可以指定您想要的资源来衡量的，然后再运行控制器和比你可以看到数据库的有关问题 4.解释所有web录制配置？
5.解释一下覆盖图和关联图的区别？
覆盖图：它覆盖的内容，这两个图表有着共同的X轴。左Y轴的图表显示，合并后的当前图的价值和权利Y轴显示的价值， Y轴的图表是合并。
关联图：图的Y轴的两个图表互相对抗。积极图表的Y轴成为X -轴的合并图。 Y轴的图表合并成为合并后的图Y轴。
34.你如何设计负载？标准是什么？
负荷试验计划，以决定用户数量，什么样的机器，我们要使用和从那里运行。它是基于两个重要文件，工作分布图和交易资料。任务分布图给我们的信息的用户人数为特定的交易和时间上的负荷。在高峰使用和场外的使用是决定从这个图。交易的个人资料给我们提供了一个有关交易的名字和他们的优先级 6.Vuser_init中包括什么内容？
业务初始化内容Vuser_init action contains procedures to login to a server. 7. Vuser_end中包括什么内容？
业务执行场景Vuser_end section contains log off procedures 8.什么是think time？think_time有什么用？
“Think Time”顾名思义－思考时间。它效仿真实用户在实际操作过程中的等待时间。 我们做性能测试，很多时候就要模拟这种状态。例如：某系统，要求满足100用户同时在线操作，响应时间在5秒。如果不设置Think Time，我觉得，你的测试是失败的。大家想想为什么？
设置Think Time有两种方式，一种是使用Record think time在录制过程中根据实际等待时间自动的写入脚本。另一种是在脚本录制结束后手动加入到脚本中。接下来我们详细介绍。 思考时间是真实用户在action之间等待的时间。例如：当一个用户从服务器接收到数据时，用户可能需要在响应之前等待几分钟回顾数据，这种推迟被称为思考时间。 9.标准日志和扩展日志的区别是什么？
Standard Log Option：选择标准日志时，就会在脚本执行过程中，生成函数的标准日志并且输出信息，供调试用。大型负载测试场景不用启用这个选项。
扩展日志包括警告和其他信息。大型负载测试不要启用该选项。用扩展日志选项，可以指定哪些附加信息需要加到扩展日志中
简述性能测试的步骤
第一，分析产品结构，明确性能测试的需求，包括并发、极限、配置和指标等方面的性能要求，必要时基于LOAD测试的相同测略需同时考虑稳定性测试的需求。
第二，分析应用场景和用户数据，细分用户行为和相关的数据流，确定测试点或测试接口，列示系统接口的可能瓶颈，一般是先主干接口再支线接口，并完成初步的测试用例设计。
第三，依据性能测试需求和确定的测试点进行测试组网设计，并明确不同组网方案的重要程度或优先级作为取舍评估的依据，必要时在前期产品设计中提出支持性能测试的可测试性设计方案和对测试工具的需求。
第四，完成性能测试用例设计、分类选择和依据用户行为分析设计测试规程，并准备好测试用例将用到的测试数据。 第五，确定采用的测试工具。
第六，进行初验测试，以主干接口的可用性为主，根据测试结果分析性能瓶颈，通过迭代保证基本的指标等测试的环境。
第七，迭代进行全面的性能测试，完成计划中的性能测试用例的执行。 第八，完成性能测试评估报告。
在进行性能测试的时候，我们需要知道一些有效的性能指标，下面我们来列出一些主要的性能指标：
一是，通用指标（指Web应用服务器、数据库服务器必需测试项）：
*ProcessorTime：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和； *Memory Available Mbyte：可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
*Physicsdisk Time ：物理磁盘读写时间情况。 二是，Web服务器指标：
*Avg Rps：平均每秒钟响应次数＝总请求时间/秒数；
*Avg time to last byte per terstion（mstes）：平均每秒业务角本的迭代次数；*Successful Rounds：成功的请求； *Failed Rounds：失败的请求；
*Successful Hits：成功的点击次数； *Failed Hits：失败的点击次数； *Hits Per Second：每秒点击次数；
*Successful Hits Per Second：每秒成功的点击次数； *Failed Hits Per Second：每秒失败的点击次数； *Attempted Connections：尝试链接数。 三是，数据库服务器指标：
*User 0 Connections ：用户连接数，也就是数据库的连接数量； *Number of deadlocks：数据库死锁；
*Butter Cache hit：数据库Cache的命中情况。 web性能测试中，如何获得dns解析时间？ lr的help文档中提到了 ms_dns_* 的函数 Analysis中的breakdown
oa的我觉得性能不作为重点,他的访问量一般没有多大,网站的就需要做性能压力测试了,一般的关注点,论坛上都有的,你可以看一下,主要是系统的最佳并发量,最大访问量,事务的响应时间等
一般的对于web应用的规则是8秒,这是比较通用的,研究认为,一般在8秒以上的响应用户会无法接收,当然也看你的具体事务了.
think time的设置,这是性能测试的一个难点,一般如果是一个上线系统,可以通过采集用户数据来生成,对于一个待部署系统,这就要根据你的应用的了解去设置了,不同的事务会有不同的think time.对于一个填写表单提交订单的动作,你的think time可能会有30秒,这都很正常. 原则就是尽量模拟用户场景,太离谱了当然不行
性能测试包含了哪些测试（至少举出3种）
基准测试-比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。 争用测试：-核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。
性能配置-核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。
负载测试（Load Test）-是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。 强度测试Stress Testing-核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。
强度测试在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括
Spike testing：短时间的极端负载测试 Extreme testing：在过量用户下的负载测试 Hammer testing：连续执行所有能做的操作
容量测试(Volume Test)：确定系统可处理同时在线的最大用户数 关注点：how much（而不是how fast）
容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。
容量测试、负载测试、强度测试的英文解释为： Volume Testing = Large amounts of data Load Testing = Large amount of users
Stress Testing = Too many users, too much data, too little time and too little room
什么是负载测试？什么是性能测试？
性能测试（或称多用户并发性能测试）、负载测试、强度测试、容量测试是性能测试领域里的几个方面，但是概念很容易混淆。下面将几个概念进行介绍。
性能测试（Performance Test）：通常收集所有和测试有关的所有性能，通常被不同人在不同场合下进行使用。 关注点：how much和how fast
负载测试（Load Test）：负载测试是一种性能测试，指数据在超负荷环境中运行，程序是否能够承担。 关注点：how much
强度测试（Stress Test）： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况，目的是找到系统在哪里失效以及如何失效的地方。包括 Spike testing：短时间的极端负载测试 Extreme testing：在过量用户下的负载测试 Hammer testing：连续执行所有能做的操作
容量测试(Volume Test)：确定系统可处理同时在线的最大用户数
关注点：how much（而不是how fast）
容量测试，通常和数据库有关，容量和负载的区别在于：容量关注的是大容量，而不需要表现实际的使用。
其中，容量测试、负载测试、强度测试的英文解释为： Volume Testing = Large amounts of data Load Testing = Large amount of users
Stress Testing = Too many users, too much data, too little time and too little room 可能大家角色性能测试、负载测试和强度测试比较混淆。没错，这三个概念是比较容易使人糊涂。负载测试和强度测试，都属于性能测试的子集。下面举个跑步的例子进行解释。 性能测试，表示在一个给定的基准下，能执行的最好情况。例如，在没有负重的情况下，你跑100米需要花多少时间（这边，没有负重是基准）？
负载测试，也是性能测试，但是他是在不同的负载下的。对于刚才那个例子，如果扩展为：在50公斤、100公斤……等情况下，你跑100米需要花多少时间？
强度测试，是在强度情况下的性能测试。对于刚才那个例子，如果改为：在一阵强风的情况下，你在负重或没有负重的情况下，跑100米需要花多少时间？
静态方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
动态测试方法是指通过运行被测程序，检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分组成：构造测试实例、执行程序、分析程序的输出结果。
黑盒测试：从用户角度出发，根据规格说明设计测试用例，并不涉及程序的内部特性和内部结构，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。黑盒测试有两个显著特点：
（1）黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以用。 （2）黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。 黑盒测试主要是为了发现以下几类错误：
1、是否有不正确、遗漏或额外的功能实现？
2、在接口上，输入是否能正确的接受？能否输出正确的结果？ 3、是否有数据结构错误或外部信息（例如数据文件）访问错误？
4、性能上是否能够满足要求？ 5、是否有初始化或终止性错误？
白盒测试：已知程序的内部结构，检查内部操作是否按规定执行。主要对程序细节进行严密检验，针对特定条件和循环设计测试用例，对程序的逻辑路径进行测试。通过在程序的不同点检查程序状态，确定实际状态是否与预期的状态一致。
白盒测试主要是想对程序模块进行如下检查： 1、程序的所有语句至少执行一次。 2、对所有的逻辑条件都能至少执行一次。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性，等等。
从以上可以看出就算执行了完美的黑盒测试也是无法测试程序内部特定部位，另外当规格说明本身有误，也不能发现问题。而白盒测试能对程序的内部特定部位进行覆盖测试，所以黑盒和白盒测试为互补关系，结合起来进行测试用例的设计更为合理。
经验表明，通常在进行单元测试时采用白盒测试方法，集成测试采用灰盒测试方法，系统测试采用黑盒测试方法。
系统测试退出标准是什么？
1) 系统测试用例设计已经通过评审 2) 按照系统测试计划完成了系统测试 3) 系统测试的功能覆盖率达100％
4) 系统的功能和性能满足产品需求规格说明书的要求
5) 在系统测试中发现的错误已经得到修改并且各级缺陷修复率达到标准 6) 系统测试后不存在A、B、C类缺陷
7) D类缺陷允许存在，不超过总缺陷的5％ 8) E类缺陷允许存在，不超过总缺陷的10％
单元测试退出标准是什么？
1) 单元测试用例设计已经通过评审 2) 核心代码100％ 经过Code Review 3) 单元测试功能覆盖率达到100％ 4) 单元测试代码行覆盖率不低于80％
5) 所有发现缺陷至少60％都纳入缺陷追踪系统且各级缺陷修复率达到标准 6) 不存在A、B类缺陷
7) C、D、E类缺陷允许存在
8) 按照单元测试用例完成了所有规定单元的测试 9) 软件单元功能与设计一致
测试计划的目的是什么？软件测试应该划分几个阶段?简述各个阶段应重点测试的点?各个阶段的含义？
答：测试的目的是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
大体上来说可分为单元测试,集成测试,系统测试,验收测试,每个阶段又分为以下五个步骤: 测试计划，测试设计，用例设计，执行结果，测试报告
初始测试集中在每个模块上，保证源代码的正确性，，该阶段成为单元测试，主要用白盒测试方法。
接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。主要采用黑盒测试方法，辅之以白盒测试方法。
软件集成后，需要完成确认和系统测试。确认测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。 单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。 集成测试
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。 系统测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。 验收测试
验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集. 回归测试
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
针对缺陷采取怎么样的管理措施
只是对缺陷的生命周期进行管理和跟踪，Bugzilla或者TD已经足够了， 1.要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
2.根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。 3.所有发现的缺陷（不管是测试发现的还是走读代码发现的）都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
4.缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两
个：一个是让缺陷尽快解决；二是方便后面缺陷的分析（保证缺陷相关的信息准确，如龄期等），这是缺陷状态的管理。
5.为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
测试用例在软件测试中的作用是什么
1、 指导测试的实施。测试用例主要适用于集成测试、系统测试和回归测试。 2、 规划测试数据的准备
3、 编写测试脚本的”设计规格说明书”
4、 评估测试结果的度量基准。完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。 5、 分析缺陷的标准
介绍一下测试用例和如何编写测试用例
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。测试用例构成了设计和制定测试过程的基础。
编制测试用例的具体做法： 1、测试用例文档 2、测试用例的设置 3、设计测试用例
姓名：
一．简答题 （每道题10） 1. 测试的目标?
：是为了尽可能多的发现程序中的缺陷。 2. 测试的步骤？
：单元测试(模块测试) . 集成测试 . 系统测试 . 调试
. 系统的转换与交付使用
3. 您认为做好测试用例设计工作的关键是什么？
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
4．您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。 1）等价类划分 2）边界值分析法 3）错误推测法 4）因果图方法
5．测试人员的职业素质要求是什么？ 1）责任感 2）沟通能力
3）独立的判断和自学习能力 4）耐心、自我督促 5）团队精神
二．选择题（单选题）（每道题5分） 1．软件验收测试的合格通过准则是：（）
A． 软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。 B． 所有测试项没有残余一级、二级和三级错误。
C． 立项审批表、需求分析文档、设计文档和编码实现一致。 D． 验收测试工件齐全。 答：B
2．软件测试计划评审会需要哪些人员参加？（） A．项目经理 B．SQA 负责人 C．配置负责人 D．测试组 答：A
3．下列关于alpha 测试的描述中正确的是：（） A．alpha 测试需要用户代表参加 B．alpha 测试不需要用户代表参加 C．alpha 测试是系统测试的一种 D．alpha 测试是验收测试的一种 答：D
4．测试设计员的职责有：（） A．制定测试计划 B．设计测试用例
C．设计测试过程、脚本 D．评估测试活动 答：C
5．软件实施活动的进入准则是：（） A．需求工件已经被基线化 B．详细设计工件已经被基线化 C．构架工件已经被基线化 D．项目阶段成果已经被基线化 答： C
6．关于软件测试,以下()是正确的:
A 测试只能证明缺陷,不能证明缺陷不存在
B 开发人员测试自己的程序后,可作为该程序已经通过测试的依据
C 80%的缺陷聚集在20%的模块中,经常出错的模块改错后还会经常出错 答：C
三．选择题（多选题）（每道题5分） 1. 测试的依据
A. 需求说明 B. 技术规范 C. 安全规范 D. 个人能力 答： A, B, C
2. 软件缺陷都包括什么？
A. 软件未达到客户需求的功能和性能 B. 软件超出客户需求的范围
C. 软件出现客户需求不能容忍的错误
D. 软件的使用未能符合客户的习惯和工作环境 答：A,B,C,D
3. 请对以下测试计划做排序。
A. 系统测试计划 B. 验收测试计划 C. 单元测试计划 D. 回归测试策略 (适用的) E. 集成测试计划 答： C,E,A,B,D
4. 缺陷度量分析包括以下哪种？
A.缺陷分析 B.缺陷数据统计 C.缺陷预防 D.缺陷控制 答：B,C
1、 你认为测试工作在整个产品或项目研发过程中的作用是什么？ 2、 简述一个标准的缺陷(Bug)跟踪处理过程 3、 你对测试工作的职业发展有什么看法？ 4、 产品/项目需求对测试工作有什么重要的关系？ 5、 如果有一个bug，只出现一次，怎么处理？ 6、 测试工程师应该具备什么品质？
7、 下面是一个C函数，如果我调用test(5,10)，它的返回值是什么？ Int test(int i,int j) {
i = i + j; j = i – 1;
i = j – i; j = i + 1; return sizeof(i); }
8、 有一个数据库的表information的结构为： Id name age
请写出一个sql语句，查询出10个年龄小于20的人名
9、 LoadRunner中关联所用的函数？LoadRunner的日志输出函数有哪些？（回答一个就行）WR里的TSL是什么？
10、 A、B、C和D四个人是古希腊少女。她们正在接受训练以便当个预言家。（实际上，后来她们之中只有一个人成了预言家，并在特尔斐城谋得一个职位。其余三个人，一个当了职业舞蹈家、一个当了宫廷女侍、第三个当了演奏家。） 一天，她们四个人在练习讲预言。
A预言：“B无论如何也成不了职业舞蹈家”。 B预言：“C将成为特尔斐城的预言家”。 C预言：“D不会成为演奏家”。
D预言：“她自己将嫁给一个叫阿特的男人。”
可是，事实上她们四个人中，只有一个人的预言是正确的，而正是这个人当了特尔斐城的预言家。
她们四个人中谁当了什么？
软件测试电话面试经历
迈出了跳槽的第一步，在网上投了下简历。文思创新的软件自动化测试工程师（当时还不知道是做华为的外包）感觉是大公司，又是我向往的工作，岗位能力要求基本符合，于是发出了简历。
第二天下午就来电话。说今天会电话面试，不用跑滨江去，那也方便。问了下对工作岗位的具体要求，以及面试时的内容。按照她的说法，好轻松哦，感觉稍微准备下应该就没问题。
下午，找了很多内部资料，公司的项目测试用例，java版商务平台源码。
晚上翻了下那本软件测试的书，又浏览了几个电子书，记了几个关键词。第二天起来翻了一下selenium的官方文档，又看了下那个java项目的代码。接着，再把自己开发自动化测试开发的思路框架整理了一遍。
说好下午两点的，后来到4点多才来电话，一开始就开始进入问答环节，居然不解释一下迟到的原因，这鸟人什么素质。要我给别人面试，如果不能提供合理理由说明迟到原因，什么高手都不用谈。更何况是测试的岗位，对于细节必须十分重视。网上有人说文思的人素质不好，确实不好。
聊的内容先是测试理论考察，第二，使用工具情况，我说我会用qtp，但是基本不用，用开源测试框架watix，selenium。他得出的结论是我没有自动化脚本开发经验。我问他公司开发一定用qtp吗？他说不是，用其他，我就不断追问，后来告诉我说不一定听说过RFT！！！真当我白痴了，电脑上还装着呢，我还按照自带文档跑过一遍。 最后问了我一个问题：你会sql吗？
我怎么也是做过半年asp.net开发，开发个小型网站还是不成问题的。这不是侮辱我智商吗？简历上明明写着半年开发经验。
测试的话，理论水平虽然不高，但是，ui，流程，用户体验，安全性我全都测的，虽说不够严谨，但是对中小企业的项目肯定够了。不会用例设计是我的软肋，这个好难，一个人做测试，那么忙，而且这玩意，网上全说的是理论，真没办法自己一个人闭门造车。但是，会设计合格测试用例的人，肯定是大企业的，一般企业没这个条件，这样的人还会来外包吗？我后来不服，说一年经验的人，转测试的，除非有环境，有人教，基本不太可能写出来。于是让我说一些测试用例的编写理论。这个我那书上没注意这个章节，被昨天的mm说得比较轻松，也被网上的评论，说文思只要是有一定基础都要，被蒙蔽了，忘了背一下这一段了。不过话说回来，会背理论多简单，但是有几个会运用呢。会被作文写作技巧的人太多了，但是文章嘛。我只是没意识到要背一下这个。
问了下我linux经验，我说我在linux下会配置apache，mysql，php。真实情况是我按照网上教程，三个软件分开安装成功可以使用。他得出的结论是我基本不会。我不服，这种级别的测试岗位要求linux会多高，又没说要求shell编程。他说有时要远程登录进行配置服务器，很难吗？不就几个命令吗，有这么难吗？我还是单位的网管，公司电脑问题软硬件全要处理，服务器什么的都我安装配置的，几个命令能难到我吗？
当我满心期待等着问我编程技巧时，他告诉我面试结束了。。。。。我觉得我转测试最大的优势就是有开发经验，但是被直接无视了。自动化测试不就是用例设计+脚本编写吗？莫非你们不需要编写，全录制吗？rft也要会看懂录制下来的java代码呀。难道你就是在招手工测试？做人不能这么不厚道呀，欺骗我感情。
总结一下这次面试得出的结论：1。外包公司的管理人员素质基本不高。2，外包公司基本不会对员工培养，要的就是马上能上手就用的，基本不给机会。 好了，附上招聘时的要求：
1、正规院校毕业，电子/自动化/通信/计算机等相关专业，大专及以上；2、一年以上软件自动化测试工作经验，具有设计自动化测试框架以及搭建自动化测试平台的实际项目经验；3、熟悉测试用例设计方法，熟练使用QTP及TestDirector等测试工具，能独立开发QTP测试脚本；4、有实际开发经验（C或Java），愿意转行测试，且对测试有一定认知者也可；5、良好的语言表达能力和沟通能力。6、具备一定抗压能力 外包公司的测试招聘大家可以参考下我的经历。
一直在寻找测试开发或者自动化测试的岗位，无奈杭州这种岗位实在太少，除了几个大公司就是外包的。无奈呀，大公司要求达不到，挑了个外包就这样。今天实在觉得受伤害了
写的这文章，极度鄙视。不过如果复试叫我去呢？好吧，我承认我很有可能可耻得屁颠屁颠得去了。
本人对代码还是有热情的，一直不想放弃，做事也严谨，就是之前开发web时受不了客户的摧残，整天叫改这改那，当时那个项目我负责跟客户沟通，对方是客户公司的客服经理，口才了得，提出的n多修改意见没一个能拒绝掉，项目改了一遍又一遍。中小型web项目开发真要死人呀。
、您认为做好测试用例设计工作的关键是什么？为什么设计测试用例？ 2、请简单描述测试的原则？
3、您是否愿意选择从事软件测试行业，请说明理由。你觉得一个合格的软件测试人员需要具备哪些素质？
4、请简单描述缺陷处理流程
5、请简单描述一个登陆页面需要实现哪些测试？ 6、一个带图案的纸杯怎么测试？
7、请简单说明自动化测试和手工测试的区别？自动化测试是否能替代手工测试？ 8、某程序员发现按照系统设计师设计的系统要求开发出来的软件，在某个操作上挺复杂，于是他就开发了一个新的功能，让用户能够更方便地操作。请问你对他的做法有什么看法？为什么？假如你是他，你会怎么做？
9、小黄是某软件公司的测试工程师。她在星期五这天把这周测试出来的软件缺陷，写成一份报告，内容如下：“缺陷一：出货时，库存数量不会少。程序员肯定粗心大意没有把库存减去出货量；缺陷二：点击进货那个按钮两下后，还是弹出出货的界面；缺陷三：程序突然关闭，不知道为什么……”您对该测试报告有何评价？ 10、
软件测试岗位工作角色有：测试经理、测试工程师、测试员 软件测试岗位工作任务如下：
例如： 任务 ß———à 角色 监控测试进度 （ 测试经理 ） 生成测试报告 （ 测试员 ）
确保测试外部环境 （ 测试经理 ） 请填写完成该任务所对应的角色 任务 ß———à 角色 1、记录测试结果 （ ） 2、实施测试操作 （ ） 3、设计测试用例 （ ）
4、分析测试结果 （ ） 5、制定测试计划 （ ）
11（黑盒测试用例设计）、某城市的电话号码由三部分组成。这三部分的名称和内容分别是
地区码：空白或三位数字；
前 缀：非’0’或’1’开头的三位数； 后 缀：四位数字。
假定被调试的程序能接受一切符合上述规定的电话号码，拒绝所有不符合规定的号码，试用等价分类法来设计它的调试用例。
常见的软件测试工具有哪些？
常见的测试管理工具：TestDirect，Quality Center（QC） 常见的自动化测试工具：QTP,Winrunner,Selenium
常见的性能测试工具：LoadRunner、Jmeter、WebLoad、SOAPUI 常见的缺陷管理工具：Bugzilla、Mantis、QC 常见的单元测试：Nunit、Junit
软件测试工程师面试需要掌握的知识
编程语言方面：c或者c++，java，脚本语言如vbs，tcl，shell等
数据库方面：主要就是oracle, mysql, sql server, db2, 面试会涉及到sql编写等方面 操作系统：linux是必须要会的，还有unix和windows，linux操作和Shell脚本最好会写 工具方面：qc。qtp，lr，vss，svn等
测试行业的前景非常不错的，现在软件的产出非常大，软件的开发已经趋于成熟，但是测试却没有发展起来。在一些大公司，像是一些手机行业的公司，他们有自己的测试团队，但是却没有达到软件测试的标准，每年测试工程师的需求也是在不断的 加大的，证明越来越多的企业开始对软件测试重视起来，并且正在发展公司测试部门。所以在未来的几年测试行业绝对是个值得选择的行业。
进公司的测试流程，一般就是人力面试和技术面试，人力面试官主要考虑的是应聘者的综合素质是否适合一个团队发展，以及应聘者的性格品行等方面是否适合做测试这一行业。测试工程师都要求有一定的理解沟通能力。因为很多BUG都是要求和开发人员或者qa进行协商和沟通的，要求要有耐心，并且细心。技术面试就是考一些测试的基本知识。考的面很广，不过也要看你要做是具体是什么测试
因篇幅问题不能全部显示，请点此查看更多更全内容