当前位置： >>
常见的测试用例设计方法都有哪些
常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应 用。 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. 2. 3. 4. 5. 6.如何理解 TPS？ 如何理解线程调用？ 如何理解响应时间？ 如何理解性能建模？（可分类回答） 如何理解响应时间、TPS 曲线和用户之间的关系？ 在 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. 2. 3. 4. 5.如何判断 CPU、内存、磁盘的瓶颈？ 如何理解 CPU、内存、磁盘之间的关系？ 如何理解 paging in/paging out？ 如何监控操作系统的资源？（可以用一个操作系统做例子） 如何理解内存管理和线程调度？（可以用一个操作系统做例子）? ?6. 如何理解 CSwitch？（可以用一个操作系统做例子） 7. 如何理解磁盘 IO？（可以用一个操作系统做例子）网络? ?1. 如何定位数据包的传输在网络上消耗的时间？ 2. 如何理解纯路由和 NAT 的区别？性能测试工具? ? ? ? ? ?1. 2. 3. 4. 5. 6.解释 LoadRunner 的工作原理。 如何理解 LoadRunner 里的关联？ 如何理解性能压力工具？ 如何理解虚拟用户？（可以用一个工具做例子） 如果理解业务到脚本的转化？（可以用一个工具做例子） 如何做到业务统计数据到场景的转化？（可以用一个工具做例子）一般测试流程： 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 建议、优化类 建议优化类? ? ? ?性能测试即测试软件处理事务的速度， 一是为了检验性能是否符合需求， 二是为了得到某些性能 数据供人们参考（例如用于宣传）。 有时人们关心测试的“绝对值”， 如数据送输速率是每秒多少比特。 有时人们关心测试的“相对 值”，如某个软件比另一个软件快多少倍。 在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测试的影响。例如网络环境、计 算机主频，总线结构和外部设备都可能影响软件的运行速度。 性能测试的一些注意事项： C不要试图让人拿着钟表去测时间，应当编写一段程序用于计算时间以及相关数据。 C应当测试软件在标准配置和最低配置下的性能。 C为了排除干扰，应当关闭那些消耗内存、占用 CPU 的其它应用软件（如杀毒软件）。 C不同的输入情况会得到不同的性能数据，应当分档记录。例如传输文件的容量从 100K 到 1M 可以分成若干等级。 C由于环境的波动，同一种输入情况在不同的时间可能得到不同的性能数据，可以取其平均值。健壮性是指在异常情况下，软件还能正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能 力。 容错性测试通常构造一些不合理的输入来引诱软件出错，例如： （1）输入错误的数据类型。如“猴”年“马”月。 （2）输入定义域之外的数值。如上海人常说的“十三点” 粗暴一些方式俗称“大猩猩”测试法。除了不能拳打脚踢嘴咬外，什么招术都可以使出来。例如在测试 客户机－服务器模式的软件时，把网络线拔掉，造成通信异常中断。 恢复测试重点考察一下几项： （1）系统能否重新运行； （2）有无重要的数据丢失； （3）是否毁坏了其它相关的软件硬件。?数据一般通过接口输入和输出， 所以接口测试是白盒测试的第一步。 每个接口可能有多个输入参 数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不少。根?据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。 如果实际输出与期望的输出不一致， 那么说明程序有错误。 白盒方式的接口测试和黑盒方式的功 能测试，其方法十分相似。 一个函数体内的语句可能只有十几条， 但逻辑路径可能有成千上万条。 想遍历测试几乎是不可能 的，不测试或者胡乱找几条路径测试却又不行。对于非严格系统而言，在分析路径方面化费很多精力是不值得的。我认为在构造接口测试的同时 已经建立了测试路径。因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。由 于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，不用得着费煞苦心地去找测试 路径。?路径测试的检查表 数据类型、变量值、逻辑判断、循环、内存管理、文件 I/O、错误处理?由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。预防措施有：观察是否有程序语句从来没有被执行过。如果发生在这种情况，要么是程序有错误，存在无用的 代码；要么是接口测试不充分，漏掉了一些路径。 要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。减少冗余的测试? ?白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑 盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。 在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少 的冗余，应当设法剔除不必要的重复测试工作。减少无价值的测试?无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测 试一个典型的输入就行了，如果有人在此区间测试了 100 次，那么其中 99 次就是无价值的。如何“偷工减料”?有一些“短、平、 快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱， 开发方不得不采用“偷工减料”的方式来降低测试代价。 偷工减料的途径无非就是减少测试的内 容和频度。 但不能砍得太狠， 否则软件拿不出手。 基本方法是找出软件中需要优先测试的部分 （见 下表），其它次要部分可以忽略或将来再测试。“偷工减料”方法的测试优先级：?哪些功能是软件的特色？? ? ? ? ? ? ? ?哪些功能是用户最常用的？ 如果系统可以分块卖的话，哪些功能块在销售时最昂贵？ 哪些功能出错将导致用户不满或索赔？ 哪些程序是最复杂、最容易出错的？ 哪些程序是相对独立，应当提前测试的？ 哪些程序最容易扩散错误？ 哪些程序是全系统的性能瓶颈所在？ 哪些程序是开发者最没有信心的？在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相 同内容的测试? 不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常 由开发小组执行。根据测试心理学的分析，开发人员测试自己的工作成果虽然是必要的，但不能作为成 果已经通过测试的依据。 既然系统测试与验收测试的内容几乎是相同的，为什么还要验收测试？ 首先是“信任”问题。对于合同项目而言，如果测试小组是开发方的人员，客户怎么能够轻易相信“别 人”呢? 所以当项目进行系统测试之后，客户再进行验收测试是情理之中的事。否则，那是客户失职。 不论是合同项目还是非合同项目，软件的最终用户各色各样（如受教育程度不同、使用习惯不同等等）。 测试小组至多能够模仿小部分用户的行为，但并不具有普遍的代表性。 能否将系统测试和验收测试“合二为一”？ 系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织。用户还有自己的事情要做，他们为 什么要为别人测试呢？即使用户愿意做系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。 系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。如果让用户发现“内幕”，一是丢脸， 二是会吓跑买主。所以还是关起门来，先让测试小组做完系统测试的好。 由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性 地单元测试呢？ 如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代 价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单 元测试或者“偷工减料”，是“得不偿失”的做法。 如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？ 要把 N 个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通 过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误 差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。 因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能 发现真正的原因。 C白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。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 错误处理 114797 结论 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 或
的分辨率模式下是否显示正常? 字体是否太小以至于无法浏 览? 或者是太大? 文本和图片是否对齐? 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 为避免引入新错误，须不断地进行回归测试（}