测试学习及面试参考文档.doc

*ERP项目需求规格说明书1. 自我介绍2* Bug管理2.1 一个bug包括哪些内容？答：摘要，检测日期，严重程度，检测版本，项目，主题，描述，可重现，优先级，状态，检测者，分配给2.2 bug级别划分？严重-严重花屏，内存泄露，用户数据丢失或破坏，系统崩溃/死机/冻结，模块无法启动或异常退出，严重的数值计算错误，功能设计与需求严重不符，导致其他功能无法测试的错误主要，主要功能存在缺陷，但不会影响到系统稳定性。功能未实现，功能错误，系统刷新错误，语言或数据通讯错误，轻微的数值计算错误，系统所提供的功能或服务受到明显的影响次要，操作界面错误，边界条件显示错误，提示信息错误，长时间操作无进度提示，系统未优化，光标跳转设置不会，光标定位错误轻微：界面格式等不规范，辅助说明描述不清楚，操作时未给用户提示，可输入区和只读区没有明显的区分标志，个别不影响产品理解的错别字，文字排列不整齐等一些小问题，建议2.3 bug生命周期？从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)下面就对这几种状态进行以下解释：New:（新的）当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为NewAssigned（已指派的）当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”Open（打开的）一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”Fixed（已修复的）当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组Pending Reset（待在测试的）当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”Reset(再测试)测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset” Closed（已关闭的）如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”Reopen（再次打开的）如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”Pending Reject（拒绝中）如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”Rejected(被拒绝的)测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”Postponed（延期）有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”Deferred（延期的）有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”2.4一个bug都包括了那些内容，如何提交高质量的bug记录？答：一条软件缺陷记录一般包括bug名称 ，编号，所在模块，发现日期，发现人，软件版本号，严重等级，状态，指定修改人，优先级别以及bug描述,相关的截图。 我们一班用缺陷管理工具TD或QC提交。2.5 在测试时，开发人员会说：“我们不需要懂那么多，我们不需要了解那么细，只需要从用户角度来测量就可以了”如何面对这种情况：答从目前情况来看，开发普遍存在着对测试的误解，误认为测试是对项目工时的一个附加，做测试不仅仅要测试自己看到的，也要测试自己看不到的冰山之下，比如判断是否有内存泄露，是否有死锁，是否有不良SQl，是否满足性能需求，是否满足安全需求，等，这些纯用户角度无法度量、2.6 bug有哪些类型？类型 描述功能类1，功能未实现2，功能错误 3 功能设计与需求规格说明书不一致，4 出现多余功能 5 正常操作，但存储内容不正确 6 功能未完全但不影响系统正常运行数据类1，数据丢失 2 数据来源不符合要求但操作成功3 边界值超出正常范围导致出现1级bug现象4 数据处理结果不正确 性能类1 软件运行过程中死机2 内存泄露 3 系统崩溃，导致系统变慢4 长时间事务处理，无提示界面类1 UI与原型不一致2 文字，颜色，图片错误等3 界面设计不规范，没有考虑易用性问题信息类1 系统报非友好错误信息2 必填项无提示3 提示信息问题安全类1 安全性漏洞 2 系统漏洞建议类偶然类 3. 测试计划3.1测试计划工作的目的是什么？测试计划工作的内容都包括什么？其中哪些是最重要的？答：测试计划的目的是为了开展测试工作更加顺利，使其工作保质保量的按时完成。 测试计划一班包括1，项目简介，测试目的，参与者 2）测试所需的软硬件配置 3）测试人员分工 4） 测试内容及步骤5测试进度 6 测试风险分析 ，测试进行的策略和方法是最重要的。3.2 做好测试计划工作的关键是什么？1. . 明确测试的目标，增强测试计划的实用性编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷，因此软件测试计划的价值取决于它对帮助管理测试项目，并且找出软件潜在的缺陷。因此，软件测试计划中的测试范围必须高度覆盖功能需求，测试方法必须切实可行，测试工具并且具有较高的实用性，便于使用，生成的测试结果直观、准确2.坚持“5W”规则，明确内容与过程“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。利用“5W”规则创建软件测试计划，可以帮助测试团队理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）3. 采用评审和更新机制，保证测试计划满足实际需求测试计划写作完成后，如果没有经过评审，直接发送给测试团队，测试计划内容的可能不准确或遗漏测试内容，或者软件需求变更引起测试范围的增减，而测试计划的内容没有及时更新，误导测试执行人员4. 分别创建测试计划与测试详细规格、测试用例应把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术3.2 如何制定测试过程中的时间进度表的答案:根据项目的需求、开发周期、开发人员的开发进度等时间安排来制定一个测试时间进度初 稿，并将测试时间进度表交与整个项目团队成员大家一起讨论和分析，最终和所有人达成共识制定出一个大家都可以执行的测试时间进度表。时间表中包括了开发人员提交功能或功能模块的时间，以及为了更好的执行测试，配合测试人员进行功能培训的时间，以及测试执行时间等，都详细的写到WBS中，并按照这个时间进度表来执行项目的测试任务。4. 测试分析4.1 圆珠笔测试分析 功能测试： 圆珠笔按下是否能正常写字，写字太重会不回缩回去，继续按会不会弹回去 性能测试：圆珠心弹出弹回的快慢 负载测试：一直按，弹簧能接受多少次的升缩 兼容性测试：换其他的笔芯能不能行 强度测试：用力过度会怎样 可恢复性测试：如果弹簧压久了，是否可恢复等等 GUI测试：笔的外观，拿笔的舒适性 安全性：考虑对笔芯的保护，是否对使用者造成危害等等4.2 水杯测试分析一、GUI测试：1 看其形状、大小设计是否适合人方便拿起；2 外观是否吸引人（广告嘛），赏心悦目；3 带广告的图案沾水后是否掉色、模糊。二、功能、压力测试：A 考量其装载能力：在杯子内分别装入少量的、半杯的、满杯的：1 热水；2 冷水；3 冰水；4 咖啡；看其装载量和装载时间以及纸杯拿在手中的硬度是否达到设计标准B 装入热水后，纸杯是否有异味。三、24*7测试：装入液体后记录其多久以后漏水4.3 有一个加减计算器，有09的数字键、符号（有图），问你如何进行测试4.4 在三角形计算中 a b c 当三条边不可能构成三角形时提示错误，构成三角形时计算周长，如是等腰三角形 打印等腰三角形，如是等边三角形打印等边三角形，画出程序流程图，控制流程图，计算全复杂度5. 测试用例5.1测试用例的对应生命周期，一个测试用例一般包括那些部分一个测试用例要经历制定测试计划、设计测试用例、执行测试用例、撰写测试报告、消除软件缺陷等5个步骤。其中一个测试用例大致由用例编号、用例名称、测试目的、测试级别、参考信息、测试环境、前置条件、测试步骤、预期结果、设计人员等元素构成。5.2 以往的工作是否开展过测试用例评审，描绘出评审过程和内容 答： 是的，我们评审测试用例有测试经理和测试成员一起参加，首先是每个测试成员介绍自己的测试用例，主要是对那些方面进行测试，进行覆盖，然后测试经理点评，成员共同讨论。评审内容主要是对测试用例的覆盖面，用例的语言表达通俗易懂方面，结构简洁方面考虑。5.3 以往的工作是否开展过测试用例评审1、 添加数据2. 能够正常录入，并添加成功3. 输入特殊字符或超长字符，负数，必填项不填等是否有提示信息4. 点击保存数据是否真的保存到数据库，可以通过软件查询功能验证或到数据库查看5. 点击重置按钮数据是否清空6. 输入编程的敏感字符（如：JavaScript,），系统是否能正常运行7. 输入重复的ID号是否有提示信息8. 要考虑输入法全角和半角所占字符问题9. 在购物系统中要考虑到防止在一段时间里重复提交表单的功能 -10. 默认值的情况也应该要注意2、 删除数据1.能够正确的将数据删除，并有成功提示2.提示删除成功，数据是否真的删除3.不选择要删除的数据，应有提示请选择要删除的记录。4.有多选功能要验证是否能删除多条记录5.提示是否删除记录时，选择否，看数据是否能够保留-6 对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会。3、 查询数据1.输入正确完整的信息，能够将数据正确显示2.数据不存在时，应有提示信息或以空表显示3.输入特殊的或超长字符，负数，必填项不填是否有提示信息（特殊系统）4.有日期输入框的时候，要考虑开始日期不能大于结束日期。若做月末报表查询时要考虑，开始日期和结束日期在同一月内（特殊系统）5.输入编程的敏感字符（如：JavaScript），系统是否能正常运行6.要考虑输入法全角和半角所占字符问题4、 修改数据1.能够自动将要修改的数据提到修改数据框中2.要保证编号不能修改3. 修改的数据应符合添加数据的规则4. 修改完数据后要进入数据库或输入编号看数据是否真的修改5、 导出数据1.不输入要导出的路径，应有提示信息2.输入的路径是一些不符合规则的数据，要有提示信息3.输入正确的路径能够成功导出数据，并检验数据是否导出到目标地址4.对于有些导出文件功能还要验证是否安装控件5.导出数据量比较大时要有能够检测硬盘空间够不够用6.输入的目标路径不存在要有提示7.导出的数据是否和原数据一致。6、 导入或上传数据1.没有选择上传或导入数据的路径时要有提示2.上传的路径不符合字符规则要有提示3.上传的数据或文件，图片不符合校验规则要有提示（如：数据过大，文件或图片格式不正确）4.目标路径不存在要有提示5.导入或上传的数据操作成功，有提示且要检验数据是否真的存在6导入的数据或文件是否对该系统的兼容性或稳定性造成影响。（例如导入的是一个病毒文件让系统的某些文件不能正常运行）7.导入或上传数据是否和原数据一致。7、 用户权限1.首先检验分配的权限能否使用2.检验分配的权限是否各职其责3.不同的角色有不同的权限，应该有相应的用户去验证权限。8、 数据字典1.首先检验数据字典的下发数据是否完整2.数据字典的数据是否能够正确使用3. 在用数据字典时要能够正确的校验使用数据字典的规则9、 发送邮件1.要有能够检验输入的邮件地址是否符合邮件书写规则2. 输入一个正确的邮件地址要能发送成功3.要有支持群发的功能，即输入多个邮件地址也能发送成功4.选择发送并保存的话，要能够保存5 看邮件是否能够定时发送6.验证正确的邮件地址接受到得邮件是否和发送时一致（数据和文件格式）。10、 设定定时任务1.设定定时任务时，要符合日期和时间的设置规则（如：时间范围应为00-24，月要保证是01-12，年要保证大于0）2.要检验到达设定时间，任务是否真的触发3在设定时间时看输入明显不合理的时间是否会出现提示（例如，订票时间是2015年.月.日）4 在测试时间时要保证终止日期大于开始日期。11、 登录1.输入正确的用户名和密码，要能够正确登录2.输入的密码或用户名错误时，要有提示信息3.密码要能够隐藏4.输入的用户名和密码要符合输入规则（如：长度要符合规则或符合程序设置的规则），不符时要有提示示例信息5.对于金融系统，密码输入错误次数过多要有锁定密码的功能6输入空值时是否能直接登录7.密码不能复制粘贴12、 注销或退出系统1.点击注销功能时，能够直接跳转到登录页面2.退出系统时，程序能够被关闭13、 界面1.要检验界面是否整洁，明了，布局美观2.应有的导航菜单或按键是否存在3.超链接功能键是否能正常使用，且跳转页面正确4.文字是否完整，大小是否合适5是否符合用户习惯6菜单、按钮的位置是否一致14、 安全5. 在登录框中输入登录信息后，用get方式提交时绝不能让密码显示在网址信息上6. 在长时间不操作页面时会自动跳到登录页面或用户操作时失效或自动跳转到指定页面。7. 在没有登录时，不能间接的输入主页面的网址就能显示主页面，要有过滤。8. 在金融系统中注意要有可恢复测试，自动备份或转移测试。 5.4 一个文本框要求输入10个字符的邮政编码，如何设计测试用例?答：1.考虑文本框输入长度应在大于0小于10的范围 2.要保证输入框是纯数字。 3.要考虑输入的纯数字符合邮政编码检验规则。 4.输入超出范围的字符要 有提示 5.输入一些特殊字符和非数字字符要有提示 6.注意输入法全角和半角问题5.5 怎样设计测试用例答案：在测试用例设计之前首先要熟悉客户的需求文档或需求规格说明书，以做到对被测系统的熟悉，充分了解产品的详细功能，并在熟悉过程中即使与研发人员和客户人员进行有效的沟通。然后从需求中提炼中各个模块的详细功能点编写出一个测试要点的文档。根据测试要点设计测试用例，测试要点与测试用例是一个一对多的关系，一个测试要点可能会需要几个测试用例的验证，有正常的操作和异常的操作，甚至是几个正常与几个异常的操作，这要根据实际功能的要求来具体分析具体实现。一是测试用例对需求覆盖的完整性；二是测试用例的有效性；三测试用例的可理解性四是测试用例的清晰性；五是测试用例的可维护性。一个好的方法就是用mm图把需求分解了。把基本路径分解出来，将需求归类。理顺了需求，用例写起来就顺手的多。在编写用例的过程中进行等价类的划分，最后用判定表进行评判，补充缺少的用例，剔除冗余的用例。做到对需求的100%覆盖。也就是说拿到需求文档必须进行必要的分析，不能上来就盲目的写用例，5.6 使用场景法设计测试用例通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果。场景法一般包含基本流和备用流，从一个流程开始，通过描述经过的路径来确定的过程，经过遍历所有的基本流和备用流来完成整个场景。为什么场景法能如此清晰的描述整个事件？因为，现在的系统基本上都是由事件来触发控制流程的。如：我们申请一个项目，需先提交审批单据，再由部门经理审批，审核通过后由总经理来最终审批，如果部门经理审核不通过，就直接退回。每个事件触发时的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。这一系列的过程我们利用场景法可以清晰的描述清楚。下图来展示一下网上最长见的场景法基本情况的一个实例图。 在这个图中，有一个基本流和四个备选流。每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：场景 1 基本流场景 2 基本流 备选流 1场景 3 基本流 备选流 1 备选流 2场景 4 基本流 备选流 3场景 5 基本流 备选流 3 备选流 1场景 6 基本流 备选流 3 备选流 1 备选流 2场景 7 基本流 备选流 4场景 8 基本流 备选流 3 备选流 4从上面的实例我们就可以了解场景是如何利用基本流和备用流来确定的。基本流：采用直黑线表示，是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）备选流：采用不同颜色表示，一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）下面是场景法的基本设计步骤 1. 根据说明，描述出程序的基本流及各项备选流 2. 根据基本流和各项备选流生成不同的场景 3. 对每一个场景生成相应的测试用例 4. 对生成的所有测试用例重新复审，去掉多余的测试用例，测试用例确定后，对每一个测试用例确定测试数据值好了。说了一些场景法的基本概念和设计方法。想必大家已经有了一些了解了。再举一个简单例子来讲解下。这里，我就不用网上很流行的ATM的例子了。我结合以前项目中遇到的情况。设计一个简单的例子来讲解下。有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。第一步我们来确定基本流和备选流： 第二步我们根据基本流和备选流来确定场景： 第三步我们来设计用例对于每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本例中，对于每个测试用例，存在一个测试用例ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。 第四步我们来设计数据，把数据填入上面的用例表中。 5.7 什么样的测试用例才算好的用例一个好得测试用例，需要满足16个字： 结构清晰 内容准确 易于统计 便于维护5.8 翻页的测试用例答：1、有无数据时控件的显示情况 2、在首页时，首页和上一页是否能点击 3、在尾页时，下一页和尾页是否能点击 4、在非首页和非尾页时，四个按钮功能是否正确 5、翻页后，列表中的记录是否仍按照指定的排序列进行了排序 对于“总页数，当前页数总页数，当前页数”，主要要检查的测试点有： 1、总页数是否等于总的记录数/指定每页条数 2、当前页数是否正确5.9 设计测试用例的方法有哪些，举例说明？1 等价类划分划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类2. 边界值分析法边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据3. 错误推测法基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例4 因果图方法前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况5.7 测试用例的设计方法等价类划分法：是把所有可能的输入数据，即程序的输入域划分成若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的 测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.边界值分析法：长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.因果图法判定表驱动分析法.正交实验设计法5.8 水杯测试用例测试项目：杯子需求测试：查看杯子使用说明书界面测试：查看杯子外观功能度：用水杯装水看漏不漏；水能不能被喝到安全性：杯子有没有毒或者细菌可靠性：杯子从不同高度落下的损坏程度可移植性：杯子在不同的地方、温度等环境下是否都可以正常使用兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等易用性：杯子是否烫手、是否有防滑措施、是否方便饮用用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述疲劳测试：将杯子盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等压力测试：用根针并在上面不断加重量，看压强多大时会穿透跌落测试：杯子加包装（有填充物），在多高的情况下摔下不破损震动测试：杯子加包装（有填充物），六面震动，检查产品是否能应对恶劣的铁路公路航空运输测试数据：其中应用到：场景法、等价类划分法、因果图法、错误推测法、边界值法等方法期望输出：该期望输出需查阅国标、行标以及使用用户的需求说明书测试：检查说明书书写准确性另外，这个面试题目还可以推广到其它物品，比如手机、电饭煲、电梯等。5.9 注册测试用例我们要从用户名和密码角度写了几个要考虑的测试点，如果需求中明确规定了安全问题，Email，出生日期，地址，性别等等一系列的格式和字符要求，那就都要写用例了以等价类划分和边界值法来分析1.填写符合要求的数据注册:用户名字和密码都为最大长度 （边界值分析，取上点）2.填写符合要求的数据注册 :用户名字和密码都为最小长度 （边界值分析，取上点）3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据（边界值分析，取内点）4.必填项分别为空注册 5.用户名长度大于要求注册1位（边界值分析，取离点）6.用户名长度小于要求注册1位（边界值分析，取离点）7.密码长度大于要求注册1位（边界值分析，取离点）8.密码长度小于要求注册1位（边界值分析，取离点）9.用户名是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了,如含有空格，#等，看需求是否允许吧）10.密码是不符合要求的字符注册（这个可以划分几个无效的等价类，一般写一两个就行了）11.两次输入密码不一致(如果注册时候要输入两次密码，那么这个是必须的）12.重新注册存在的用户13.改变存在的用户的用户名和密码的大小写，来注册。（有的需求是区分大小写，有的不区分）14.看是否支持tap和enter键等；密码是否可以复制粘贴；密码是否以*之类的加秘符号显示5.10 打印测试用例打印机测分1.连接测试，能否连同2.输入错误的链接路径，点击打印3.输入正确的链接路径，点击打印4.没有安装打印机驱动，进行打印5.打印的过程稳定性如何，是否不打印，或打印为空，打印机停止作业6.打印出来的字是否和文档一致，有无乱码，排列顺序错误。6 测试总结6.1 测试报告包括那些项测试用例的通过数，测试用例的未通过数，以及测试用例的通过率，未通过的功能都集中在哪几个功能模块 ，根据测试经验以及测试结果进行一个缺陷的分析和建议。7 项目整体测试流程7.1 测试工作进行到一半，突然发现时间不够，怎么办？答案：1.与客户沟通本次发布的版本什么是最重要的，什么是其次，我会安排一个优先级来对整体测试功能进行一个筛选。 2.我会和测试组原体人员一起加班7.2 如果你是测试组长你如何对项目及组员进行管理答案： 首先要从需求开始，充分了解被测系统的功能以及业务需求，并在遇到问题的时候及时有效的与开发人员以及其他项目相关人员进行沟通，做到最被测系统的十分熟悉。并了解整个测试组的成员他们的测试技能以及擅长的工作，做到测试任务的合理分配，得以让测试工作快速，稳定高效的进行！7.3 功能测试流程测试人员在编写需求分析时参与进去，了解项目的背景和客户需求，然后根据项目开发进度编写测试计划。测试计划包含以下内容：设计测试用例时间，执行测试用例时间，和回归测试时间，这个时间要按项目进度来制定，保证计划的正常执行。写完测试计划后不用急着写测试用例，首先要确定需求分析是不是已经编写完成，并经过了评审，如果评审已完成就要尽可能多了解需求分析，根据需求分析编写测试要点，所谓测试要点就是测试用例的框架，把需求分析中的用户要求和用户业务记录下来，然后区分哪些是主要需求，哪些是次要需求。便于测试的全面和测试重点突出。编写完测试要点后，再开始编写测试用例。所谓测试用例就是指测试某项功能时所作的输入数据或动作，并列出期望的输入数据或动作。编写测试用例就是用实际的操作来证明前面所写的测试要点中功能点和业务实现。测试用例编写完成后开始测试。测试完成后及时把报告反馈给开发人员，便于开发人员修改。当开发人员修改完成后，进入回归测试，回归测试的做法是把发现问题的测试用例和它有关联的测试用例重新执行一遍，如果没有问题，测试完成，否则再次提交测试报告，直到测试完成。7.4 v模型跟w模型的优缺点V模型优点：1，既有底层测试又有高层测试。底层:单元测试。高层：系统测试2，将开发阶段清楚地表现出来，便于控制开发的过程。当所有阶段都结束时，软件开发就结束了。缺点：1，容易让人误解为测试是在开发完成之后的一个阶段2，由于它的顺序性，当编码完成之后，正式进入测试时，这时发现的一些bug可能不容易找到其根源，并且代码修改起来很困难3，实际中，由于需求变更较大，导致要重复变更需求，设计，编码，测试，返工量大。W模型优点：1，将测试贯穿到整个软件的生命周期，且除了代码要测试，需求，设计等都要测试。2，更早的介入到软件开发中，能尽早的发现缺陷并进行修复。3，测试与开发独立起来，并与开发并行。缺点：1，对有些项目，开发过程中根本没有文档产生，故W模型无法使用。2，对于需求和设计的测试技术要求很高，实践起来很困难。8 功能测试与性能测试比较8.1 测试类型有哪些，它们的区别与联系测试类型有：功能测试，性能测试，界面测试。功能测试在测试工作中占的比例最大，功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。 性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。界面测试，界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。区别在于，功能测试关注产品的所有功能上，要考虑到每个细节功能，每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上，用户使用该产品的时候是否易用，是否易懂，是否规范（快捷键之类的），是否美观（能否吸引用户的注意力），是否安全（尽量在前台避免用户无意输入无效的数据，当然考虑到体验性，不能太粗鲁的弹出警告）？做某个性能测试的时候，首先它可能是个功能点，首先要保证它的功能是没问题的，然后再考虑该功能点的性能测试9 黑盒测试与白盒测试比较9.1 黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：15、 是否有不正确或遗漏的功能？16、 在接口上，输入是否能正确的接受？能否输出正确的结果？17、 是否有数据结构错误或外部信息（例如数据文件）访问错误？18、 性能上是否能够满足要求？19、 是否有初始化或终止性错误？软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：1、 对程序模块的所有独立的执行路径至少测试一遍。2、 对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。3、 在循环的边界和运行的界限内执行循环体。4、 测试内部数据结构的有效性，等等单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。（常见的联调测试）系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是验收测试的任务，即软件的功能和性能如同用户所合理期待的那样9.2 分别说明黑盒测试和白盒测试的优点和缺点?答：黑盒测试的优点有：1）比较简单，不需要了解程序内部的代码及实现；2）与软件的内部实现无关；3）从用户角度出发，能很容易的知道用户会用到哪些功能，会遇到哪些问题；4）基于软件开发文档，所以也能知道软件实现了文档中的哪些功能；5）在做软件自动化测试时较为方便。黑盒测试的缺点有：1）不可能覆盖所有的代码，覆盖率较低，大概只能达到总代码量的30%；2）自动化测试的复用性较低。白盒测试的优点有：帮助软件测试人员增大代码的覆盖率，提高代码的质量，发现代码中隐藏的问题。白盒测试的缺点有：1）程序运行会有很多不同的路径，不可能测试所有的运行路径；2）测试基于代码，只能测试开发人员做的对不对，而不能知道设计的正确与否，可能会漏掉一些功能需求；3）系统庞大时，测试开销会非常大。10 自动化测试工具10.1 对自动化才测试的看法自动化测试，主要借助于WinRunner、QuickTest Professional等自动化测试软件，进行一些诸如数据校验、增强测试、运行测试、维护测试等可自动化测试的测试内容。具有测试效率高，节约人力时间的优点。可以实现一些手工测试无法实现的测试项目，如并发访问的压力测试、极限测试等项目。但自动化测试和手工测试相比，无法实现如用户体验测试的业务性测试，更加适合一些大量的重复性测试。10.2 平时用QTP工具吗？在什么时候开始用？会不会写脚本？用的时候页面的覆盖率有多少？如何页面发生变化了，是不是要重新再录一边脚本？脚本修改的频繁吗？ 平时也用QTP，是在回归的时候用，脚本会编写，我们用的时候是一个售票系统，覆盖范围不多就是注册、登录等页面。如果页面发生变化不会去重新录，我们会加一个检查点，并进行参数化，脚本修改频率要看需求一般修改频率不是很大。10.3 QTP中的检查点是如何添加的？在录制的过程中，把页面转到QTP，选择插入菜单，不就可以插入检查点了insert 菜单 checkpoint也可能录制完后添加，在页面中选中要检查的文字，点击右键选择10.4 QTP有哪些功能？Loadrunner有哪几部分组成？分别有什么作用？参数化的作用，如何给一个登陆页面设计成100个用户登陆的参数化？关联的作用？11 个人问题11.1 为什么想进本公司？答：因为我觉的在贵公司能够学到很多东西，更有很大的发展潜力，不像那些已成规模的大公司，做工过于太细，已形成流水线化。枯燥而学不到很多知识。想发展更是艰难。在贵公司我可以不断的完善自己，挑担自己，工作会更有激情。11.2 喜欢这份工作的哪一点？ 答：我以前是做软件开发的，那种工作是枯燥的，而作测试工作，可以在一种软件未上市前先了解，还可以知道很多软件的功能，另外正因为做软件测试要懂很多，明白很多。所以我感觉做这一行更了解和学习很多知识。11.3 自己的优缺点？答：我觉得我个人的优点就是，沉着冷静，乐于助人，容易和人相处，对工作负责，做事认真，处事谨慎。我的缺点是胆子没有那么大，比如开车吧！我就不会。另外就是不善于表现自己，有一点自卑的感觉。 11.4 对公司的了解有多少？答：阿里巴巴是一家年轻的发展中的公司阿里巴巴,他是一个很注重价值观的企业,他的价值观就是六脉神剑,我知道咱们公司处于快速发展的阶段。11.5 对公司的期望与目标何在？答：我的目标是不断完善自己，能够更熟练的掌握测试技术，争取成为一名优秀的工程师。同时也希望公司不断扩大，个人在职位上也有提升的空间。11.6 为什么要离职？回答这个问题时一定要小心，就算在前一个工作受到在大的委屈，对公司有多少的怨言，都千万不要表现出来，尤其要避免对公司本身主管的批评，避免面试官的负面情绪及印象；建议此时最好的回答方式是将问题归咎在自己身上，例如觉得工作没有学习发展的空间，自己想在面试工作的相关产业中多加学习，或是前一份工作与自己的生涯规划不合等等，回答的答案最好是积极正面的。 11.7 选择这份工作的原因为何？ 这是面试官用来测试应聘者对工作理解度的问题，藉以了解求职者只是基于对工作的憧憬或是确实的兴趣来应徵这份工作，此时之前所强调的事先研究功夫又再度派上用场，建议你的回答应以个人的兴趣配合工作内容特质，表现出高度的诚意，这样才可以为自己铺下迈向成功之路。 11.8 你认为相关产业的发展为何？ 这也是事前准备的功夫，多阅读一些相关的报章杂志，做一些思考，表现出自己对此相关产业的的认识，如果是同业转职者，可强调以自己的经验为基础所做的个人见解，但若是初次接触此一行业，建议采取较为保守的方式，以目前资讯所提供的资料为主作答，表现出高度兴趣及诚意为最高指导原则。 11.9 你期望的待遇是多少？我对工资没有硬性要求，我相信贵公司在处理我的问题上会友善合理。我注重的是找对工作机会，所以只要条件公平，我则不会计较太多。11.1.0 在工作中学到了什么 这是针对转职者提出的问题，建议此时可以配合面试工作的特点作为主要依据来回答，如业务工作需要与人沟通，便可举出之