禅道zentao==》项目管理工具，我们测试人员用它进行测试管理（用例管理、BUG管理）
禅道本地访问地址：http://127.0.0.1/index.php
编写用例的8大要素：（面试题：一条用例包含什么字段，有什么内容）
1，用例编号：用于对用例进行唯一编号的
2，所属模块：说明测试用例适用的功能模块
3，用例标题：简单描述测试用例执行的场景，要求尽量唯一
4，前置条件：执行测试用例步骤之前准备的一些动作或者准备的数据，用来简化测试步骤
5，步骤：用来详细说明测试需要执行的动作
6，预期：说明用例在执行之前的一个期望结果
7，优先级：说明测试用例的重要程度，用来区分测试用例的执行优先级
8，用例类型：说明测试用例的适用范围，如：功能测试、性能测试、安全测试、接口测试等等
面试题：当你认为这是一个bug，开发却认为不是bug，你会怎么去处理？
我会抱着电脑跑去跟开发进行复现bug，以及根据需求去说明自己对这个功能的理解。如果开发还是认为这不是bug。那么我和和开发一起去找产品经理，然后产品经理进行仲裁，如果产品经理说这是一个bug那么开发就去修改，如果产品经理说这个不是bug，那么我会关闭这个bug
面试题：说说你们的bug流程（bug的生命周期）
以下两个流程只要回答一个：
一、规范的流程
1，测试人员提交bug至测试经理进行审核
2，测试经理审核无误后，提交给到开发经理，让开发经理分配bug修改任务
3，开发人员接受并确认bug原因
4，开发人员修改bug，修改完成之后，把bug指派给到测试经理，让测试经理安排对应的bug回归任务
5，测试人员回归bug，验证通过则关闭bug；不通过则重新指派给对应的开发进行重新修改
二、常用流程：
1，测试人员直接把bug提交给到对应的开发人员
2，开发人员接受并确认bug的原因
3，开发人员修改bug，修改完成后，把bug指派给到对应的测试进行复测验证
4，测试人员验证通过则关闭bug，不通过则重新指派给对应的开发进行重新修改
bug的状态有哪些？
New:（新的）
当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New
Assigned（已指派的）
当一个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”
回归提问：
面试题：简单介绍一下"H"模型？
1，进行需求澄清会议，由产品经理进行召开，一般参加人员有整个项目的所有人（项目经理、开发经理、开发人员、测试经理、测试人员、运维人员可来可不来）。
需求澄清会议结束后，各方都觉得没什么大问题，产品经理就可以输出基线化需求文档
*基线化：不会再有大改动
2，分析开发输出的概设和详设文档
3，测试经理会输出测试计划或者测试方案
4，测试人员编写测试用例，进行用例评审，需要召开用例评审会议（一般由测试经理召开）
组内评审（交叉评审）：测试组内的成员进行互相评审
组外评审：项目成员进行评审，一般参与人员是跟当前项目相关的测试人员和开发人员、产品经理
5，评审通过之后会形成用例的基线化文档，测试经理会把用例文档提交到用例管理平台上（textlink、禅道），测试经理会把测试用例安排给到对应的测试人员
6，搭建测试环境
面试题：liux如何快速打开一个文件
vim、nl、less、more、head、tail、cat、grep、set
面试题黑盒测试、白盒测试区别
黑盒测试：功能测试，主要是对功能进行验证，不需要看代码，直接根据需求去进行测试
测试人员不需要考虑程序内部的逻辑结构和内部的特性，只需要根据需求说明书描述的功能验证软件的功能是否符合需求
白盒测试：对软件产品的内部的代码进行测试。验证每个操作（每个路径）是否符合设计的要求。把测试的对象看做透明的盒子，对程序内部所有逻辑路径进行测试，也就结构测试
灰盒测试：介于黑盒和白盒之间，既要进行功能测试也要进行代码测试，主要是接口测试
面试题：拿到需求后，怎么去设计测试用例
拿到需求文档之后，我会先分析需求中说明的基本功能，然后对这些基本功能进行业务流程的梳理,来设计测试用例。
如果设计到状态转换的场景那么也会对这些场景进行设计测试用例,用于提高业务流程的覆盖情况对涉及到边界值的场景会使用边界值来设计补充测试用例。
然后也会根据自己对业务和系统的理解来设计测试用例。
如果需求中功能涉及到系统的故障恢复，那么也会使用系统异常法进行一些系统异常情况下的测试用例
如果需求中功能涉及到性能和安全方面的测试，那么也会补充相关的性能测试用例和安全测试用例
|
|
411
0
多测师社区 
