测试理论

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)对应的测试人员，查看被指派的测试用例，并执行测试用例。

3.7 如何提交一个好的BUG¶

对BUG有一个清晰明了的描述，将预期结果与实际结果进行对比，并提交BUG相关的图片和日志;
定位好BUG的等级；
详细描述BUG环境和重现的步骤；

3.8 提bug需要注意哪些问题?¶

1) 确认：不要急着提交，先跟开发说明bug的情况，定位分析下bug。是前端问题还是后端问题，再去提交bug。在不能确认该情况是否为bug的时候，可以请教其他人。 2) 描述：简单明了的概括bug标题，清晰的描述bug重现步骤，分析bug和预期正确结果，附加bug的截图或者日志。描述bug的时候。 4) 闭环：提交完bug以后，后面还要跟踪bug修复情况。

3.9 bug怎么管理的，bug的生命周期或者是bug的状态¶

原来bug是用禅道来管理的原来我们公司bug，提交bug直接给对应的开发人员，对应开发人员修复完成，交给测试复测，复测通过关闭bug，不通过打回给对应开发。提交-开发人员(已激活未确认)-开发进行确认，状态变成已激活，已确认，开发修复完成，标注状态是已修复，测试人员复测通过，已关闭，打回给对应开发，已经激活。

3.10 提交bug包含哪些内容¶

所属产品、所属模块、所属项目、影响版本、指派人员截止日期、严重程度、优先级、bug类型、bug环境 Bug标题、重现步骤、附件

3.11 你提交的bug，开发不认可怎么办?¶

首先，我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug。如果是bug再去让其他测试人员看看听下他们的意见，然后自己先再三去复测，并目保存好截图和日志，确定这是一个bug之后我就去跟开发说明白，并且给他看bug重现的截图以及日志，如果开发还是不认可的话我就跟产品或项目经理说明白情况。

3.12 对应无法重现bug，应该怎么处理?¶

首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起，并且留意一下，看看往后的测试中，如果在后面的测试中重现bug就激活，如果经过几个版本都还没发现的话就关闭bug。

3.13 界面中的乱码可以是哪里导致的?¶

(1)数据库中的编码设置
(2)前端页面编码
(3)后台代码也会编码

3.14 bug的级别有哪些，级别如何判断¶

1、致命：对业务有至关重要的影响，业务系统完全丧失业务功能，无法再继续进行，或业务系统丢失了业务数据且无法恢复，影响公司运营的重要业务数据出错。 2、严重：对业务有严重的影响，业务系统已经丧失可部分的重要的业务功能，或业务系统丢失了业务数据且可以恢复，一般业务数据出错。 3、一般：对业务有较小的影响，业务系统丧失了较少的业务功能，例如：界面错误，打印或显示格式错误。 4、提示：对业务没有影响，不影响业务过程正常进行，例如：辅助说明描述不清楚，提示不明确的错误提示。

3.15 测试中，如何判断是前端的bug还是后端的bug呢?¶

通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口、传参数、响应。 1）请求接口un是否正确如果请求的接口ur错误，为前端的bug 2）传参是否正确如果传参不正确，为前端的bug 3）请求接口u和传参都正确，查看响应是否正确如果响应内容不正确，为后端bug 4）也可以在浏览器控制台输入js代码调试进行分析

3.16 项目上线后发现bug，测试人员应该怎么办¶

看严重级别：严重还是不严重。严重的，紧急变更上线；如果不严重：修复好后跟下个版本一起上线
测试人员：编写对应的测试用例、测试环境中重现bug、提交bug、交给开发进行修复、修复完成bug、进行bug的复测。如果测试环境无法重现，可以导入生产环境的包到测试环境中测试，还是不能复现，查看生产环境的日志去定位问题。

3.17 如何保证质量¶

(1)需求：业务要吃透，多问，多去了解。 (2)评审：严格按照测试流程去执行：多考虑用户测试场景，使用测试用例设计方法，多评审。 (3)执行：要有良好的测试执行，要求用例执行率达到100%，多轮测试，进行探索性测试，需要测试之间交叉测试，用工具来管理我们的测试工作(禅道， testlink， excel，tapd) (4)反思：不断的反思与提升。

3.18 产品是怎么上线的?¶

一般我们会选择晚上上线，开发测试还有产品全部到场，进行上线测试。首先，开发将代码打包到生产环境的服务器中，如果数据表有变化，就会运行sql文件，对表的一些操作，接着，我们测试就开始先测试主体业务功能以及新增的功能模块; 测试通过之后，我们会在界面上把上线测试的数据删除，正常上线。如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以正常上线如果发现了bug开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，如果严重就延期上线，如果我们是迭代版本的话我们还需要版本回滚。如果不严重，产品跟客户觉得可以上线，就正常上线。

3.19 你测试数据是从哪里获得?怎么获得的，假如不告诉你，你怎么处理?¶

(1) 一般都是我们测试人员在测试过程自己造的测试数据，如果大量数据，我们可以用到存储过程。 (2) 也可以让运维人员帮忙从生产环境导出相关的测试数据，如果测试数据中涉及安全性的数据，直接是不能导出。

3.20 如何测试万分之一概率问题¶

1) 用Jmeter或者其他自动化测试工具造大量数据 2) 让开发修改概率的比例

3.21 为什么要写测试用例?¶

1)提高测试效率 2)提高测试覆盖率 3)监控测试进度情况 4)也是质量的标准指标 CMM质量体系(用例数也是一个度量标准QA岗位)

3.22 那你们测试用例是怎么编写的¶

原来我们主要是用excel编写的，当然也用过用禅道， testlink去编写，禅道都是excel表格编写完成，导入禅道系统， testlink也可以Exce表格，编写，编写测试，导入 testlink

3.23 有没有写过测试报告，具体包括哪些内容?¶

参考答案1： 1)项目背景和目的 2)测试用例设计 3)测试环境 4)测试过程用到的工具 5)测试范围 6)测试用例执行情况 7)测试缺陷分析和总结 8)测试结果

参考答案2：这个是写过的，测试报告，其实就是把我们测试的整个过程情况，数据统计，做成报告，包括用例执行情况，测试了哪些模块，多少用例，会哪里模块，自动化通过率，自动化跑了多少，是否全部通过，发现了多少bug，bug的情况，是否遗漏bug，测试结论等等这些，基本就这些。

3.24 测试报告中测试的结论是什么?¶

测试报告里面有个测试结论： 1）bug的情况、bug级别、bug分布情况(分布哪些模块)、 bug产生原因(设计问题，需求问题，代码问题) 2）测试是否通过

3.25 如何写好一个测试用例¶

能够发现bug的用例就是一个好的测试用例当然我们在编写测试用例的时候，一定要步骤、场景清晰、尽量去覆盖所有的测试场景

3.26 什么是冒烟测试? 在什么时候进行冒烟测试?¶

冒烟测试一般我们是在系统测试之前，对所有主体的业务功能，测试看是否存在严重bug，如果存在严重bug，表示，冒烟测试不通过

3.27 回归测试策略¶

1）功能的回归优先测试用例级别比较高的功能模块，可以进行自动化测试如果时间够，进行全量测试 2）bug回归复测这个bug，并且相关联的模块与功能也会测试一遍，以免由于修改bug导致其他问题产生

3.28 和开发是怎么沟通的¶

一般我在提bug的时候跟开发沟通最多，比如有一些不清晰的内容会去问开发，还有提完bug后会跟踪bug的进度，提醒开发尽快修复bug，还有测接口的时候去找开发拿接口文档，其实我们的工作跟开发都是息息相关的所以都经常都会有沟通的。

3.29 测试中有哪些风险¶

1）业务：测试需求理解上面有偏差 2）技术：测试人员水平不够，测试人员覆盖点不全 3）时间：测试人员时间不够，导致测试不完全 4) 环境：测试环境上面不足，导致测试点不能完全测试完成

3.30 怎么保证测试质量或者你怎么保证你100%覆盖了需求¶

把需求了解通透，引用用例评审机制，然后编写测试用例的时候用边界值，用等价类补充一些用例，根据过往经验用错误推断法来追加一些用例，如果存在组合情况的话我会用因果图或者判断表来编写，如果业务场景清晰的情况下我会用流程分析法，如果状态有发生改变的话我就会用状态迁移法。编写用例一个极其考验耐心的事情，要考虑到各种场景，全面覆盖到会出现的场景。

3.31 一个需求，7天要上线，你怎么做？¶

先跟面试官确定，产品什么是转测； 1）如果转测时间，在最近1-2天，直接了解需求开始测试。 2）如果三天后转测，一天半时间了解需求，一天写测试点和写测试用例，一天进行评审和修改测试用例，2天执行试用例与理交bug，最后一天半进行回归测试与编写测试报告。 3）如果4-5天后进行转测试，边开发边测试，一天半时间了解需求，一天写测试点和写测试用例，一天进行评审和修改测试用例，开始执行测试，开发一部分，我们就测试一部分。

3.32 产品上线评判的标准?¶

1）测试用例执行率100%，通过率95% 2）1-2级bug修复率达到100%，3-4级bug修复率达到95%

3.33 测试过程中，发现很多用例重复的，有的人认为没必要再测，你怎么看?¶

如果是同一个横块，重复用例，我们可以考虑不再进行重复测试，如果不同模块，引用相同的测试用例，我们还是需要重复测试

3.34上线后有没有另外的测试用例在生产环境里测试¶

有：我们会去单独去编写测试用例，只是主体流程用例，新增功能的用例没有：我们会挑选原来测试用例中，级别比较高的用例去执行，或者我们建立一个checklist列表，去检查功能是否正常使用。

3.35 什么是多分支开发和单分支开发?¶

git工具相当于svn工具，分支开发每个版本或者模块，开发不同模块，分支合并，把所有的功能全部整合起来，其实就划分功能模块去开发。

3.36 兼容性测试你们是怎么测的? app与web¶

Web：不同的浏览器，E，谷歌，火狐，浏览器显示比例，浏览器前进，后退，刷新按钮。 App：不同手机厂商，型号，系统版本，内存大小，分辨率，屏幕的大小，高端机与低端机，考虑平板

3.37 功能测试重复测试比较高，怎么看待这个问题?¶

1）对于测试来说，还是良好耐心，问题无法避免事情，重复的事情还是要去执行 2）重复事情，我们用自动化测试来进行替代

3.38 项目同时发布，你怎么处理?¶

1）确定下，我们几个项目是否可以同步发布完成 2）如果确定项目不是同时发布(时间问题，人员问题) 确定下项目的优先级，跟客户这边商量优先级低一些项目推迟发布(产品跟客户)

3.39 你们开发转测试怎么转的¶

1）开发人员发邮件告知对应的测试人员：新的代码地址、最新的sql文件、需求开发完成的情况。 2）测试人员把最新的代码和sql脚本更新到测试环境中，并进行冒烟测试，要是冒烟测试不通过则转测失败。

3.40 你们的开发语言是什么？¶

java后台开发： SSM spring + springy + mybaits（数据的封装） SSH sprint +springmvc + hibernate springboot fianl极速开发框架 maven项目 pom.xml文件 ...中央仓库 python后台开发框架 Django flask

前端开发语言： JavaScript + css+ html bootstrap框架常用库：jquery简称JQ Es6/E57 php ThinkPHP框架