三、测试理论3.1 你们原来项目的测试流程是怎么样的?
我们的测试流程主要有三个阶段:需求了解分析、测试准备、测试执行。
1、需求了解分析阶段
我们的SE会把需求文档给我们自己先去了解一到两天这样,之后我们会有一个需求澄清会议,
我们会把不明白不理解的需求在会议上说出来,包含需求的合理性还有需求的可测性等,
产品这边解答,目的是让我们测试这边和开发对需求的理解达到一致。
2、测试准备阶段
会议结束之后我们开始准备测试工作,我们测试这边会写一个测试计划,分配每个人负责的模块,
然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析,分析测试点,
以及编写测试用例,之后我们会在自己的组内先进行评审,评审修改之后还会在我们的项目组评审,
评审完后进行修改测试用例。
3、测试执行阶段
开发人员编写好代码之后,我们会把代码包通过 Jelkins部署到测试环境提测,进行SIT测试,
在正式测试之前我们会先做一个冒烟测试,冒烟测试通过之后我们才转测,在执行测试的过程中,
我们如果发现bug就会用tapd(或者禅道)记录并且提交bug,也会进行bug复测,以及回归测试,
每一轮测试结束之后我们都会写一个测试报告,一般情况下,测试4-5轮之后会达到上线要求,
当达到上线的标准后,测试报告会认为测试通过,上线前我们会做预发布测试,预发布通过后,
由项目组与产品决定时间上线,上线完成,一周左右我们会写一个项目总结测试报告,
总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进,在产品选代过程中,
我们会跑自动化用例来进行回归测试。
3.2 如果需求不明确的话你怎么办?
需求不明确的话我会在需求澄清会议上面提出来,问清楚这个需求只有明确需求,
才能更好的完成工作,后续工作中还是不清楚,可以找产品再去确认这个需求。
3.3 有哪些需要评审,哪些人在
1、 xmind思维导图评审,主要是测试人员
2、测试用例需要评审,测试人员,开发人员,产品人员
3、需求文档,项目组所有的人员,都会到场
3.4 有没有写过测试计划,具体包括哪些内容?
参考答案1:
测试计划内容:
(1)目的和范围(2)规程(3)测试方案和方法(4)测试的准入和准出
(5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排(7)交付件
参考答案2
我们公司之前按照考核要求写过测试计划,不过后面老大觉得太耽误工作进度,
后面一般都不再写测试计划,而是写版本计划,这个在版本计划,每个人的任务列出来,
负责人列出来,自己根据自己的情况分配时间,然后汇总,大家一起开个小会评审就可以了。
3.5 用例包含哪些部分,哪些用例设计方法,你一般常用哪些方法?
原来我们用例包含
测试项目,用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果
黑盒测试用例设计方法:主要是等价类、边界值、错误推测法、判定表、因果图、正交表、
流程分析法、状态迁移法、异常分析法。
常用的:等价类、边界值、判定表、流程分析法、错误推测法。
等价类是指某个输入域的子集合,在该子集合中,
各个输入数据对于揭露程序中的错误都是等效的,
并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部
输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,
就可以用少量代表性的测试数据取得较好的测试结果,
等价类划分可有两种不同的情况有效等价类和无效等价类。
边界值的话就是对等价类划分方法的补充。测试工作经验告诉我,大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部,因此的话针对各种边界情况来设计测试用例,可以查出更多的错误,使用边界值分析方法设计测试用例的话,首先应该确定边界情况,通常输入和输出等价类的边界,就是应着重测试的边界情况应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
对于错误推断法,这个是基于经验和直觉推测程序中所有可能存在的各种错误,
从而有针对性的去设计测试用例的方法的,主要就是列举出程序中所有可能有的错误和容易发生错误的特殊情况去根据这些情况来选择测试用例,例如,在单元测试时曾列出的许多在模块中常见的错误以前产品测试中曾经发现的错误等,这些就是经验的总结。还有,输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况,可选择这些情况下的例子作为测试用例。
前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的联系,相互组合等等的情况。考虑输入条件之间的相互组合,可能会产生一些新的情况,
但是要检查输入条件的组合并不是一件容易的事情,即使把所有输入条件划分成等价类,
他们之间的组合情况也相当多,因此的话可以考虑采用一种适合于描述对于多种条件的组合,
相应产生多个动作的形式来考虑设计测试用例,这就需要用到因果图(逻辑模型)。
因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。
3.6 TestLink工具使用?
(1)创建用户,并给新创建的用户指定权限。
(2)创建测试用例,对测试用例进行增、删、改、查
(3)把测试用例关联到对应的测试计划中。
(4)把测试用例指派给对应的测试人员。
(5)对应的测试人员,查看被指派的测试用例,并执行测试用例。
我们的测试流程主要有三个阶段:需求了解分析、测试准备、测试执行。
1、需求了解分析阶段
我们的SE会把需求文档给我们自己先去了解一到两天这样,之后我们会有一个需求澄清会议,
我们会把不明白不理解的需求在会议上说出来,包含需求的合理性还有需求的可测性等,
产品这边解答,目的是让我们测试这边和开发对需求的理解达到一致。
2、测试准备阶段
会议结束之后我们开始准备测试工作,我们测试这边会写一个测试计划,分配每个人负责的模块,
然后我们就根据自己负责的模块用 xmind(思维导图)进行测试需求分析,分析测试点,
以及编写测试用例,之后我们会在自己的组内先进行评审,评审修改之后还会在我们的项目组评审,
评审完后进行修改测试用例。
3、测试执行阶段
开发人员编写好代码之后,我们会把代码包通过 Jelkins部署到测试环境提测,进行SIT测试,
在正式测试之前我们会先做一个冒烟测试,冒烟测试通过之后我们才转测,在执行测试的过程中,
我们如果发现bug就会用tapd(或者禅道)记录并且提交bug,也会进行bug复测,以及回归测试,
每一轮测试结束之后我们都会写一个测试报告,一般情况下,测试4-5轮之后会达到上线要求,
当达到上线的标准后,测试报告会认为测试通过,上线前我们会做预发布测试,预发布通过后,
由项目组与产品决定时间上线,上线完成,一周左右我们会写一个项目总结测试报告,
总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进,在产品选代过程中,
我们会跑自动化用例来进行回归测试。
3.2 如果需求不明确的话你怎么办?
需求不明确的话我会在需求澄清会议上面提出来,问清楚这个需求只有明确需求,
才能更好的完成工作,后续工作中还是不清楚,可以找产品再去确认这个需求。
3.3 有哪些需要评审,哪些人在
1、 xmind思维导图评审,主要是测试人员
2、测试用例需要评审,测试人员,开发人员,产品人员
3、需求文档,项目组所有的人员,都会到场
3.4 有没有写过测试计划,具体包括哪些内容?
参考答案1:
测试计划内容:
(1)目的和范围(2)规程(3)测试方案和方法(4)测试的准入和准出
(5)测试计划(流程、时间安排、对应人员) (6)测试的环境配置和人员安排(7)交付件
参考答案2
我们公司之前按照考核要求写过测试计划,不过后面老大觉得太耽误工作进度,
后面一般都不再写测试计划,而是写版本计划,这个在版本计划,每个人的任务列出来,
负责人列出来,自己根据自己的情况分配时间,然后汇总,大家一起开个小会评审就可以了。
3.5 用例包含哪些部分,哪些用例设计方法,你一般常用哪些方法?
原来我们用例包含
测试项目,用例编号、测试标题、优先级、预置条件、操作步骤、测试数据、预期结果
黑盒测试用例设计方法:主要是等价类、边界值、错误推测法、判定表、因果图、正交表、
流程分析法、状态迁移法、异常分析法。
常用的:等价类、边界值、判定表、流程分析法、错误推测法。
等价类是指某个输入域的子集合,在该子集合中,
各个输入数据对于揭露程序中的错误都是等效的,
并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部
输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,
就可以用少量代表性的测试数据取得较好的测试结果,
等价类划分可有两种不同的情况有效等价类和无效等价类。
边界值的话就是对等价类划分方法的补充。测试工作经验告诉我,大量的错误往往是发生在输入或输出范围的边界上而不是发生在输入输出范围的内部,因此的话针对各种边界情况来设计测试用例,可以查出更多的错误,使用边界值分析方法设计测试用例的话,首先应该确定边界情况,通常输入和输出等价类的边界,就是应着重测试的边界情况应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据。
对于错误推断法,这个是基于经验和直觉推测程序中所有可能存在的各种错误,
从而有针对性的去设计测试用例的方法的,主要就是列举出程序中所有可能有的错误和容易发生错误的特殊情况去根据这些情况来选择测试用例,例如,在单元测试时曾列出的许多在模块中常见的错误以前产品测试中曾经发现的错误等,这些就是经验的总结。还有,输入数据和输出数据为0的情况。
输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况,可选择这些情况下的例子作为测试用例。
前面介绍的等价类划分方法和边界值分析方法都是着重考虑输入条件但都没有考虑输入条件之间的联系,相互组合等等的情况。考虑输入条件之间的相互组合,可能会产生一些新的情况,
但是要检查输入条件的组合并不是一件容易的事情,即使把所有输入条件划分成等价类,
他们之间的组合情况也相当多,因此的话可以考虑采用一种适合于描述对于多种条件的组合,
相应产生多个动作的形式来考虑设计测试用例,这就需要用到因果图(逻辑模型)。
因果图方法最终生成的就是判定表它适合检查程序输入条件的各种组合情况。
3.6 TestLink工具使用?
(1)创建用户,并给新创建的用户指定权限。
(2)创建测试用例,对测试用例进行增、删、改、查
(3)把测试用例关联到对应的测试计划中。
(4)把测试用例指派给对应的测试人员。
(5)对应的测试人员,查看被指派的测试用例,并执行测试用例。