1.B/S架构和C/S架构区别

B/S 只需要有操作系统和浏览器就行，可以实现跨平台，客户端零维护，但是个性化能力低，

响应速度较慢C/S响应速度快，安全性强，一般应用于局域网中，因为要针对不同的操作系统,

需要针对性的开发,并且维护成本高

2.HTTP协议

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、daohttp是超文本传zhuan输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

3.Cookie和Session的区别与联系

Session和Cookie的主要区别在于：
Cookie是把数据保存在浏览器端的内存中
Session把数据保存在服务器端的内存中
cookie与session的联系：
当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionId。

这样才能保证客户端发起请求后客户端已经登录的用户能够与服务器端成千上万的session中准确匹配到已经保存了

该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。

5. 测试的目的

1）软件测试是为了发现错误而执行程序的过程。

2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的） 3）一个好的测试用例在于它发现至今未发现的错误。 4）一个成功的测试是发现了至今未发现的错误的测试。

注意：

1、测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。 2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如Bev Littlewood发现一个经过测试而正常运行了n个小时的系统有继续正常运行n个小时的概率。

6. 软件测试原则

1）应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。

2）测试用例应由测试数据和与之对应的预期输出结果这两部分组成。

3）程序员应避免检查自己的程序。

4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。

5）充分注意测试中的群集现象。

6）严格执行测试计划，排除测试的随意性。 7）应当对每一个测试结果做全面的检查。

8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便

7. 软件测试分为哪几个阶段？

软件测试分类 按照阶段 单元测试：是指对软件中的最小可测试单元进行检查和验证 集成测试：集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。 系统测试：指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。 验收测试：以用户为主的测试，软件开发人员和质量保证人员参加 按照是否查看源代码划分 白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试) 黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果 功能测试 逻辑功能测试:测试应用是否符合逻辑，比如应该先注册账号之后，才能进行登录,登录之后才能看我的购物车 界面测试:窗口大小，按钮大小，点击按钮弹出什么样的提示框，是否有滚动条，下拉菜单是否有展示内容 易用测试:从软件使用的合理性和方便性等角度对软件系统进行检查,比如，软件窗口长宽比例是否合适，颜色色彩是否赏心悦目，字体大小是否合适 安装测试:安装磁盘空间不足，安装中断(关闭程序，关机，，)下次安装时是否继续上次的安装等。。。 兼容测试:硬件兼容性测试和软件兼容性测试（硬件兼容性:比如一款软件在pc机，笔记本,主机上是否兼容，软件兼容性测试:比如一款软件在window8和window10上是否兼容） 性能测试 一般性能测试 稳定测试: 负载测试: 让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。（测试载重） 压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。（测试强度） 其他 回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。 随机测试：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误

8. 单元测试与集成测试的侧重点

单元测试

   是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试，测试重点是系统的模块，包括子程序的正确性验证等。 

集成测试

    也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求，组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。 

9. 系统测试范围

指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。 系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等

10. a测试与ß测试的区别

α测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成。

β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。

它们都是验收测试！

α测试是指把用户请到开发方的场所来测试 β测试是指在一个或多个用户的场所进行的测试。

α测试的环境是受开发方控制的,用户的数量相对比较少,时间比较集中。 β测试的环境是不受开发方控制的, 用户数量相对比较多,时间不集中。

α测试先于β测试执行。通用的软件产品需要较大规模的β测试,测试周期比较长

11. 验收测试怎么做？

验收测试主要包含两个阶段：二轮测试和冒烟测试。在测试阶段的先后顺序上，二轮测试在一轮测试(需求的系统性测试)之后，在冒烟测试之前。在测试粒度上，按照由细到粗的顺序，依次为二轮测试和冒烟测试;冒烟测试，众所周知是对功能主路径的回归验证，而二轮测试则是执行较冒烟更细粒度的测试，另外也包含了一轮测试阶段中出现bug较多的场景等等。 一轮测试：系统的测试验证需求的阶段，包含全部功能点的验证、兼容性验证、性能验证等等;

二轮测试：作为一轮测试后的整体回归验证阶段，主要侧重验证功能的主流程和一轮测试中问题较多的场景的相关用例 开始标准

一、测试自身

1、一轮测试执行完毕;

2、一轮阶段的待检验bug回归完毕;

3、发起内核代码迁移邮件，确认内核开发要集成到正式发布分支的代码，且均已验证完毕。 二、配合方

1、各配合方均已上线验证完毕;

2、例如：产品配置项、服务端、前端、第三方等;

3、反例：小编最近碰到个问题，由于没有在二轮测试开始前做好上线验证工作，导致在二轮执行阶段遇到多方联调问题，影响项目进度。

4、具体表现：在二轮测试执行阶段，发现已经上线了的服务端和第三方相关功能无法顺利走通，经过定位排查发现是在上线时，服务端和第三方的接口没有联调成功。

5、三方(开发、产品、测试)确认无阻塞二轮测试的bug;

6、代码集成完毕;(视具体项目组而定)

7、新功能或有较大改动模块，产品&交互验收通过并已回复邮件;

8、新功能或有视觉改动模块，视觉走查通过并已回复邮件;

9、备注：当项目发版紧张时，开发评估一轮未结束的模块对其他模块均无影响(如，独立插件的功能模块)，可以先执行其他不受影响的模块的二轮测试

12. 白盒、黑盒和灰盒测试区别

白盒测试:指的是把盒子盖打开，去研究里边源代码和程序结构(单元测试，ui/接口自动化测试) 黑盒测试:把被测试的软件看做一个黑盒子，我们不去关心盒子里边的结构是什么样子，只关心软件的输入数据和输出结果 灰箱测试或灰盒测试(Gray-box testing):灰箱测试就像黑箱测试一样是通过用户界面测试，但是测试人员已经有所了解该软件或某种软件功能的源代码程序具体是怎样设计的。甚至于还读过部分源代码。 因此测试人员可以有的放矢地进行某种确定的条件/功能的测试。这样做的意义在于:如果你知道产品内部的设计和对产品有透过用户界面的深入了解，你就能够更有效和深入地从用户界面来测试它的各项性能

13. 冒烟测试的目的

冒烟测试：指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。 使用冒烟测试是为了正式测试前，验证是否产品或系统的主要需求或预置条件是否存在bug

14. 回归测试怎么做？

回归测试：回归测试是指修改了旧代码后，重新在新环境上进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 1、在测试策略制定阶段，制定回归测试策略 2、确定需要回归测试的版本 3、回归测试版本发布,按照回归测试策略执行回归测试 4、回归测试通过，关闭缺陷跟踪单（问题单） 5、回归测试不通过，缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员回归测试

15. 全部回归与部分回归的区别？

对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”，这是全部回归；当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响，这叫部分回归。

16. 需求分析的目的

1、把用户需求转化为功能需求：

1）对测试范围进度量    2）对处理分支进行度量   3）对需求业务的场景进行度量   4）明确其功能对应的输入、处理和输出   5）把隐式需求转变为明确。

2、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识

，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

17. 测试计划的目的

1、测试的目的是为了bai发现du尽可能多的缺陷，不是为了说zhi明软件中没有缺陷。

2、成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷

18. 什么时候开始写测试计划

在项目开始后，在前期你需要了解测试的背景，范围和工作量，以及人员的分工，所需的资源，工期等，在这些了解清楚后开始撰写测试计划

19. 由谁来编写测试计划

测试计划一般由资深的测试人员来做， 要对整zhi体的项目有非常好的掌控，有丰富的测试经验的人员来编写测试计划。

1. 测试计划一般由测试经理来编写。

2. 测试组其他人员， 会针对自己分配的任务估算自己任务的时间，统一汇总到测试经理那里

20. 测试计划的内容

测试背景 测试目标 测试范围 测试输出文档 测试策略 测试规模工作量分析 测试进程 测试进度及时间安排 测试资源 人力，设备， 风险管理

（1）测试环境：测试环境+生产环境

（2）测试范围：新增需求+全功能回归

（3）测试重点：优先级为high的

（4）注意事项：开发提供修改点

（5）测试级别：常规啥的

（6）测试方法：功能测试？性能测试

（7）测试文档：测试依据、测试条件、测试用例

（8）计划测试资源：人员以及安排的工作日

（9）是否需要外部支持：是/否

（10）测试出口：发布时间

21. 结束条件(项目上线的条件)

结束条件： 1.测试用例执行比例，一般功能测试用例全部执行完毕，非功能测试用例执行达95%以上

2.测试缺陷修改数量，一般及以上的用例全部修复并验证通过，已修复缺陷占比95%以上

3.测试覆盖需求程度，测试覆盖全部的需求且达到上线的要求或标准

上线条件： 1.编写目的：明确软件测试工作的开始和结束标准。

2.软件测试合格标准：以上比例为错误占总测试模块的比例。

3.缺陷修复率标准

　　1) A、B、C级错误修复率应达到100%

　　2) D级错误修复率应达到96%以上

4.覆盖率标准

　　测试需求执行覆盖率应达到100%（业务测试用例均以执行）。

5.错误级别 A级：不能完全满足系统要求，基本功能未完全实现；或者危及人身安全。系统崩或挂起等导致系统不能继续运行。

B级：严重地影响系统要求或基本功能的实现，且没有更正办法（重新安或重新启动该软件不属于更正办法）。使系统不稳定、或破坏数据、或产生错误结果，或部分功能无法执行，而且是常规操作中经常发生或非常规操作中不可避免的主要问题。

C级：严重地影响系统要求或基本功能的实现，但存在合理的更正办法（重新启动该软件不属于更正办法）。系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题

22. 常见的测试风险

D级：使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。界面拼写错误或用户使用不方便等小问题或需要完善的问题

23. 测试用例的要素

1. 测试用例编号 字符和数字组合成的字符串，用例编号应具有唯一性、易识别 系统测试：产品编号-ST-系统测试项名-系统测试子项名-XXX 集成测试：产品编号-IT-集成测试项名-集成测试子项名-XXX 单元测试：产品编号-UT-单元测试项名-单元测试子项名-XXX

2. 测试项目 当前测试用例所在测试大类、被测试需求、被测模块、被测单元等 系统测试用例测试项目 软件需求项 集成测试用例测试项目 集成后的模块名或接口名 单元测试用例测试项目 被测函数名

3. 测试标题 简单描述，需要用概括的语言描述用例的出发点和关注点，原则上每个用例的标题不能重复

4. 重要级别 对基本和普通测试项的区分 高级别 保证系统基本功能、核心业务、重要特性、实际使用频率比较高的用例 中级别 重要程度介于高和低之间的测试用例 低级别 实际使用的频率不高，对系统业务功能影响不大的模块或功能的测试用例

5. 预置条件 执行当前测试用例需要的前提条件，如果这些前提条件不满足，则后面测试步骤无法进行或无法得到 预期结果

6. 输入

用例执行过程中需要加工的外部信息。根据软件测试用例的具体情况，有手工输入、文件、数据库记录等

7.操作步骤 执行当前测试用例需要经过的操作步骤，需要明确的给出一个步骤的描述，测试用例执行人员可以根据该步骤完成测试用例执行 8.预期输出 当前测试用例的预期输出结果，包括返回值内容，界面的响应结果，输出结果的规则符合度等

测试用例额外的要素 1.用例设计者 能准确的找到测试用例设计人员，对用例修改时能方便找准人员 2.用例设计日期 方便检查用例设计的进度 3.用例版本号 方便用例设计人员对用例的跟踪

4. 对应的开发人员 出现BUG后能及时找到相应的人员进行修复

24. 测试用例级别的划分

优先级一般都是和缺陷的严重程度对应的。 一般可以把优先级分为三种：

高：保证功能性是稳定的，是按照需求的正常使用和实现点进行用例设计的，重要的错误和边界测试的测试用例的集合。

中：更全面的验证功能的各方面，包括流程中的各个节点出错情况、异常情况测试、中断、UI展示、用户体验等方面的测试用例设计

低：不常被执行的测试用例。比如压力和性能测试用例设计，接口测试用例设计随着时间的推移已经从低级别变化到了中级别

25. 怎样保证覆盖用户需求？

覆盖用户的需求；

从用户使用场景出发，考虑用户的各种正常和异常的使用场景；

用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；

用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；

做好用例评审，及时更新测试用例。

测试完成应找业务人员进行验收，便于发现非测试角度的问题

26. 写好测试用例的关键 /写好用例要关注的维度

测试用例：测试用例为验证某一特定软件产品准备的一组有编号，输入，预期输出的描述 //记得《软件测试过程与管理》上是这样写的,而我个人觉得应该是有编号，输入，预期输出，测试步骤，测试描述等等一些信息的描述

以下Shared by Mikhail Rakhunov 好的测试用例：一个发现Bug概率很大的用例就是一个好的测试用例

测试用例设计应该具备的以下的特点

 

Test Case ID: 用来标记测试用例的编号，这个编号必须是唯一的

测试描述: 用来描述你将要进行的测试是怎样实施的

修订历史: 为了明确测试用例由谁创建或者修改，所以每个测试用例都应该有其修订历史

功能模块: 测试功能模块的名字

测试环境: 用来描述你的测试环境，当然包括硬件环境和软件环境

测试准备: 测试之前除了你所测试的程序之外还应该准备的东西，如打印机，网络等等

测试执行: 用来详细描述你的测试步骤.

期望结果: The deion of what you expect the to do. 描述该功能所要实现怎样的结果

实际结果: 通过/失败 如果成功——纪录实际运行的过程 如果失败——描述你观察到的现象，这将有利于发现Bug的起源

–———

一个很好的测试所应具有的特征: 发现Bug的几率很大 没有多余 不是太简单也不会太复杂

–——— ps.当你的期望结果有很多的时候，测试用例就会变得很复杂

27. 测试用例的状态

排队（In Queue）：

测试用例已经指定给某个测试人，不准备在这一个测试阶段运行。

进行中（IP）：

该测试正在进行，并且会持续一段时间。（如果一个测试所需要的时间少于一天，我就不会讲一个测试标为进行中，因为我每天会跟踪测试用例的状态）

阻塞（Block）：

一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺。我通常会在测试用例总结工作表的意见栏记录下阻塞的状态。你可以把阻塞理解为：我希望运行测试，但是目前还不能运行测试。

跳过（Skip）：

你决定在当前测试阶段跳过某个测试，可能是因为它的优先权相对较低。（同样地，我会在测试用例总结工作表的意见栏记录下我跳过这个测试的原因。）你可以把跳过理解为：我现在可以运行这个测试，但是我不想运行它。

通过（Pass）：

测试运行结束，测试人得到了预料中的测试结果状态和测试行为。

失败（Fail）：

在很多情况下，测试人得到预料之外的测试结果，状态或行为，这些结果与测试目标相差甚远。这就引发了关于系统质量的疑问。一个或多个测试错误需要记录下来。

警告（Warn）：

在很多情况下，测试人得到预料之外的测试结果，状态或行为，但是这些结果与测试目标差别不是很大（我通常会在测试包总结工作表的通过一栏记为警告，而不是另加一栏）。另一种想法是，警告意味着当前的错误是无关紧要的，或者对正在测试的特征是没有意义的。系统报出了更多的错。我处理这个问题的一个标准是只和延期的或不是一定要改的错误相关的测试可以标记为警告，而不是失败。

关闭（Close）：

一个测试在第一个循环中被标为失败或警告，第二个测试发布中将第一个测试循环出现的错误修改了。重新运行了整个测试用例后，没有错误出现。将这类测试标记为关闭而不是通过，使得你可以跟踪测试在某一个测试发布中失败的实事（同标记为警告的测试一样，我在测试包总结工作表中将标记为关闭的测试也纳入成功的范畴）。

28. 常见的测试用例设计方法

用例编写步骤：

拿到测试需求 -> 分析需求（画思维导图） -> 编写用例 -> 划分用例优先级

用例编写特性：

· 一致性：主要包括用例模板一致；各同事的编写手法一致；以及用例的细粒度一致。

· 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产生影响的覆盖；对各种场景的覆盖等 。

·可执行性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。

·执行准确性：是指用例执行的准确度，本身没什么技术含量。但这里需要注意的是执行人对待执行用例的态度。不要因为用例简单或者一些外界的因素，导致部分用例未实际执行标为通过的情况。

·持续更新：要及时不断的更新，要尽量减少用例库中失效的用例 。

·复用性：主要用例可以被不断的复用，从而减少维护成本

用例设计方法：

1. 等价类与边界值**（重点方法）**

等价类：等价类划分法是把所有可能输入的数据，有无效等价类和有效等价类（即正确输入和非法输入），即程序的输入域划分策划国内若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。方法是一种重要的、常用的黑盒测试用例设计方法。

边界值：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

与等价类区别：

· 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

· 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

等价类与边界值的结合使用：

例：一个文本框的输入长度为 6-10 个字符

分析：有效等价类： >=6个字符，<=10个字符

无效等价类：<6个字符，>10个字符

边界值：5,6,7,9,10,11个字符

2. 场景法**（重点方法）**

定义：通过运用场景来对系统的功能点或业务流程的描述，从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情，通过事件来触发某个动作的发生，观察事件的最终结果，从而用来发现需求中存在的问题。

基本流：是经过用例的最简单的路径（无任何差错，程序从开始直接执行到结束）

备选流：一个备选流可能从基本流开始，在某个特定条件下执行，然后重新加入基本流中，也可以起源于另一个备选流，或终止用例，不在加入到基本流中；（各种错误情况）

场景法的运用：

例：有一个在线购物的实例，用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这时需要使用帐号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。

· 基本流

· 备选流： 1) 进入购物网站，选择物品，登录账号，付费，生成订单

2）账号不存在

3) 账户余额不足

更多的备选流。。。。。。

\3. 正交排列驱动法

定义：在界面中有多个控件，控件之间有多种组合关系，如果组合的数量巨大（一般超过20种），没有必要将所有组合都测试，可以通过正交排列法将组合中最优，最少的组合进行测试。

正交表公式：

Ln（m^k）

· L（line）行

n:表示正交表的行数

提示：正交表确定后，n值是固定的，不需要测试人员计算

m：表示正交表中数据的最大值

测试时：m表示每个控件的取值个数

K:表示正交表的列数

　　　　　测试时：k表示参与组合的控件的个数

与判定表驱动法的区别：正交表一般用于组合较多的场合（一般>20种），判定表一般用于组合较少的情况

判定表示例：https://baike.baidu.com/pic/%E6%AD%A3%E4%BA%A4%E8%A1%A8/948850/0/ac345982b2b7d0a2394108ccc9ef76094a369ad2?fr=lemma&ct=single#aid=0&pic=ac345982b2b7d0a2394108ccc9ef76094a369ad2

4. 因果图

1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

2.因果图法产生的背景：

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

3.因果图介绍

1) 4种符号分别表示了规格说明中向4种因果关系。

2) 因果图中使用了简单的逻辑符号，以直线联接左右结点。左结点表示输入状态（或称原因），右结点表示输出状态（或称结果）。

3) Ci表示原因，通常置于图的左部；ei表示结果，通常在图的右部。Ci和ei均可取值0或1，0表示某状态不出现，1表示某状态出现。

\4. 因果图概念

1) 关系

①恒等：若ci是1，则ei也是1；否则ei为0。

②非：若ci是1，则ei是0；否则ei是1。

③或：若c1或c2或c3是1，则ei是1；否则ei为0。“或”可有任意个输入。

④与：若c1和c2都是1，则ei为1；否则ei为0。“与”也可有任意个输入。

2) 约束

输入状态相互之间还可能存在某些依赖关系，称为约束。例如, 某些输入条件本身不可能同时出现。输出状态之间也往往存在约束。在因果图中,用特定的符号标明这些约束。

A.输入条件的约束有以下4类：

① E约束（异）：a和b中至多有一个可能为1，即a和b不能同时为1。

② I约束（或）：a、b和c中至少有一个必须是1，即 a、b 和c不能同时为0。

③ O约束（唯一）；a和b必须有一个，且仅有1个为1。

④R约束（要求）：a是1时，b必须是1，即不可能a是1时b是0。

B.输出条件约束类型

输出条件的约束只有M约束（强制）：若结果a是1，则结果b强制为0。

\5. 采用因果图法设计测试用例的步骤：

1)分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。

2)分析软件规格说明描述中的语义，找出原因与结果之间, 原因与原因之间对应的关系，根据这些关系,画出因果图。

3)由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现，为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。

4)把因果图转换为判定表。

5)把判定表的每一列拿出来作为依据,设计测试用例。

5. 判定表

定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

判定表的优点

· 能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

·在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。

判定表通常由四个部分组成如下图所示：

1)条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出的条件的次序无关紧要。

2)动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。

3)条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。

4)动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。

6. 错误推测法

定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法

错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例

29. 判定表用在哪些时候/哪些功能

判定表比较多用在多层条件判断组合的场景，比如嵌套的if语句这种

使用场景： 1：等价类和边界值无法覆盖到控件与控件之间的联系，此时我们需要判定表来覆盖控件与控件之间的影响 什么是判定表： 判定表是分析若干输入条件下，被测试对象根据不同的条件作出不同的响应的工具，适用于业务逻辑关系和多种条件组合情况 判定表的结构： 名词解释：

• 条件桩：被测对象所有的输入

• 动作桩：针对条件桩所有的动作

• 条件项：被测对象可能输入的真假值 T F

• 动作项：针对条件项的动作T F

使用判定表的步骤

1.列出所有的条件和动作
2.根据提取出来的条件桩和动作桩，设计判定表确定规则的个数（假如有n个条件，每个条件有2个取值 （0、1），就可以产生2的n次方种规则）
3.填写判定表
4.简化判定表【合并判定表会减小测试的充分性，8条以内的规则不建议合并】
5.一个规则就可以转成一个测试用例
12345

以登录模块为例 正确的账号密码登录成功 用户名和密码为空：提示用户名或密码不能为空 用户名输入错误：提示用户名或密码错误，用户名和密码清空 用户名正确，密码错误，提示：密码错误，用户名保留，密码清空 生成判定表如下图 判定表优点 判定表法主要针对功能需求中的处理过程，处理过程越是复杂，就越有必要使用判定表法。判定表法充分考虑了输入条件间的组合，对组合情况覆盖充分，且可得出每个组合的预期输出。其实，做测试需求分析的目的也就是得出完整的测试用例。重测试需求分析，轻测试执行过程。 判定表缺点 当被测试特性输入较多时，会造成判定表的规模很庞大。当输入条件间的约束条件不能有效区分输入是否需要进行组合测试时，有可能产生冗余。需手工剔除冗余用例。

30. 什么时候用到场景法

• 场景法适用于解决业务流程清晰和业务比较复杂的系统或功能，场景法是一种基于软件业务的测试方法。

• 使用场景法，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。例：语音通话典型业务流程就把语音通话、同振顺振、语音留言、呼叫保持、呼叫转移这些功能都串到一起来。

• 基本上每个软件都会用到场景法，因为每个软件背后都有业务的支撑。

• 场景法主要用来测试软件的业务逻辑和业务流程。当拿到一个测试任务时，我们并不是先关注某个控件的细节测试（等价类+边界值+判定表等），而是要先关注主要业务流程和主要功能是否正确实现，这就需要使用场景法。当业务流程和主要功能没有问题，我们再从等价类、边界值、判定表等方面对控件细节进行测试（先整体后细节）。

Note：场景法测试用例设计的重点是测试业务流程是否正确，测试时需要注意的是，业务流程测试没有问题并不代表系统的功能都正确，还必须对单个功能进行详细的测试，这样才能保证测试的充分性。

31. 测试环境怎么搭建的？

关于软件测试的测试环境搭建，需要根据实际的需求来进行安装特定的软件，下面就简单介绍下java+tomcat+mysql安装方法。

1.java的安装

因为很多程序的代码都是通过java编程语言进行编写的，因此为了测试需要，我们需要安装支持java编程语言的安装包，即jdk。下载好指定的安装包后双击安装包，默认下一步即可。完成这些步骤后需要配置环境变量，右键点击我的电脑-属性-高级系统设置-环境变量-系统变量(s)-选中path-编辑 将安装好的java中的bin和jre的路径添加到环境变量中即可。在cmd中输入java -version和javac -version验证是否安装成功。

2.tomcat的安装

在java安装无误的情况下，下载好tomcat安装包，直接点击下一步即可。

3.mysql的安装

下载好安装包，将其解压到想要安装的盘符中；按照1中的方法，将mysql中bin的路径添加到环境变量中；打开cmd，切换到英文，输入mysqld -install(安装命令)；输入mysqld –initialize-insecure(初始化命令)；输入net start mysql(启动数据库命令)，如果能够顺利执行这些命令无报错，则数据库安装成功。倘若已经存在旧版本的mysql想将其卸载替换可依次执行net stop mysql和mysqld -remove，然后再进行mysql的安装。

32. 偶然性问题的处理

一、一定要提交!!

1. 记得有这么个缺陷，以后再遇到的时候可能就会了解发生的原因。

2. 尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。

3. 程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。

4. 无法重现的问题再次出现后，可以直接叫程序员来看看问题。

5. 对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大。

　　二、程序不是测试人员写的，出问题也不是测试人员的原因。

　　至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。

　　测试人员的任务只是尽力重现问题，而不是必须重现!!

　　三、下次再遇到的时候，拉他们来看就可以了。

　　因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。

　　而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 : )

　　四、你可以告诉程序员，测试过程是没有错误的。

　　测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。

　　需要让程序员理解，测试人员是帮助他们的，不是害他们的。

　　客户那里发现问题比测试员发现问题结果要严重的多。

　　五、测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。

　　在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。

　　问题无法重现，也要提出，程序员那里可以回复无法再现。问题放在那里，等到再次出现的时候，就立刻叫程序员过来查看。

　　实在没有再次出现，最后可以写到报告中，说出现了什么现象，但无法再现(比较严重的问题才如此处理，小问题经理之间商量商量可能就算了)。

　　

　　这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位(哼，程序有bug，是否可以说程序员工作不到位的呀)。

　　六、测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。

　　我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过，这样就避免了很多的问题。

　　其实只要自己尽到心就可以了，管别人怎么说呢。

　　七、我们使用的状态有：

　　程序员处理的状态(由测试员提交的Action)：等待处理的，再次出现的。

　　测试员处理的状态(由程序员提交的Action)：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。

　　经理处理的状态(由测试员提交Action)：管理员处理的。经理还可以删除记录。

　　按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，统一使用了“等待处理的”。

　　最后结项的时候，缺陷的状态对我们来说有两种，“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。

　　呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

　　八、一个叫doer_ljy(可战)的网友回复了一些内容，我个人认为不很妥当，就回复了一些内容，绿颜色的是doer_ljy(可战)的内容：

　　关于“无法重现”我看是有这么个问题存在。

　　首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。

　　不清楚你是否是测试人员。“计划外”这个词，对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。

　　说说我现在测试的一个项目，有一个业务，首先查询出人员，有个“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”，至今为止一切都正常，但是这个时候再次点选人员进行业务处理，仍然会提示“没有选择人员”，这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧，因为发生的条件很苛刻：不用“全选”按钮的时候不会发生;全选后点击“取消全选”按钮再办理业务不会发生;全选全消后，先点击人员再办理业务也不会发生。

　　其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。

　　呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。

　　最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.

　　测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人当然比不做的人要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议!!测试人员的任务是发现问题，解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路;而且测试人员做的多了，程序员不但不感激，可能反而会反感(好像程序员对测试人员有好印象的不多)。

　　再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了。但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现(但是我不可能遇到问题就拉程序员来看吧)，后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox(必填)再进行Edit的录入，但一次操作我没有选择 ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现(不够成熟呀)，我就放弃了，也没有提交记录(为了避免麻烦)。

　　测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间验证“无法重现”的问题?反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就当不知道。

　　下面是其它一些人的观点：

　　doublefalse(散诸怀抱)：如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试!!!我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了。

　　liuxiaoyuzhou(蟀哥)：遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG，是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!

　　ericzhangali(另一个空间)：首先一定要提交bug;其次不要企图RD一定去解这个bug;某些时候还得关闭这个bug。如果RD认为是测试错误，(不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，)那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。

　　darkcat_c(错了重来)：没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。(编者按：这种话，不愿意去辩驳，标准开发人员的看法，也许应该让他们也来做做测试)

　　liyan_1014(雁子)：我觉得应该是这么处理：

　　1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚;这样对于再次重现也有一定的参考性。

　　2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。

3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。

33. 当我们认为某个地方是bug，但开发认为不是bug，怎么处理？

1.找到需求文档或者是原型图进行匹对 2.尝试多种测试环境和多种测试方式来确认是否为bug 3.整理bug的复现的步骤和出现的频率 4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug 5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug 6.测试人员需要将bug整理并写入测试总结中

34. 产品在上线后用户发现bug，这时测试人员应做哪些工作？

首先测试人员可以做的是重现这个问题并及时反馈给开发人员，找到解决方案进行修复。

如果问题只在线上才出现，测试环境重现不了，那么可能是版本或环境配置的问题；

如果问题不仅线上能重现，测试环境也存在，那么很有可能是测试人员在测试过程中未发现的Bug。

总之，项目组成员需要尽快修复Bug。

 

开发人员修复Bug之后，测试人员需要反思。

 

若是由于疏忽造成测试用例执行遗漏，测试人员需要在下次执行测试的过程中避免这样的情况。

 

若是由于用例评审的不严格、中途需求变更或者某些其他因素造成的测试用例覆盖不全，测试人员需要补全测试用例。

 

 

在测试过程中遇到未发现的Bug，测试人员不要自怨自艾，

 

也不要像没回事儿一样，需要正确对待“线上Bug”、汲取经验教训、不断提高测试能力。

 

测试人员需要不断学习，不断扩充，掌握测试工具、提升测试技能，从而设计出更全面的测试场景和测试用例。

35. 二八定理

80%的缺陷出现在20%的代码中，体现了软件缺陷群集现象

36. 如何跟踪缺陷

在执行用例的过程中发现了跟预期实际不符的情况，就提交缺陷,跟踪缺陷修改，跟踪缺陷流程主要有四个(一个正常的修改结束的流程，三个特殊处理流程)

1. 新建 — 开启 — 修改 — 关闭 提交缺陷后开发人员确认修改后回归通过；

2. 新建 — 拒绝 开发人员未确认缺陷拒绝修改，这个时候需要在确认需求理解正确(跟产品确认)和复现步骤(多次复现)的基础上, 跟开发人员沟通是否需要修改；

3. 新建 — 开启 — 修改 — 重开 修改后提交的版本回归不通过，这是需要重新打开缺陷,为了加快缺陷正确修改，可以跟开发人员沟通，协助开发人员定位缺陷；

4. 新建 — 开启 — 延期 部分开启的缺陷，由于无法复现, 难以修改，进度压力等原因,可能需要延期修改，这个时候，是否延期，是需要多方确认的(测试、产品、开发、领导)。

37. 缺陷的状态

1. New（新的）：bug提交到缺陷库中会自动的被设置成New状态

2. Assigned（已指派）：当一个bug被认为New之后，将其分配开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

3. Open（已打开）：开发人员开始处理bug时，他将这个bug的状态设置为“Open”，表示开发人员正在处理这个“bug”

4. Fixed（已修复）：当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

5. Rejected(被拒绝)：测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

6. Postponed（延期）：有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”

7. Closed（已关闭）：测试人员经过再次测试后确认bug已经被解决，将bug的状态设置为“Closed”

8. Reopen（再次打开）：如经过再次测试发现bug仍然存在，测试人员将bug再次开发组，将bug的状态设置为“Reopen”

38. 缺陷的等级

bug缺陷等级一般划分为四个等级，致命、严重、一般、提示

 

致命（一级bug） **通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。

 

严重（二级bug） 通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。

 

一般（三级bug）** 通常表现为：界面、性能缺陷。

比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。

 

提示（四级bug） 通常表现为：易用性及建议性问题

比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。

 

39. 缺陷单应该包含这些要素

缺陷标题，缺陷描述，重现步骤，预期结果，实际结果，缺陷优先级，缺陷严重程度，附件

40. 测试报告的主要内容

1. 概述：一般会在概述中添加项目背景、需求描述等信息。

2. 测试过程主要包含评审记录、测试范围、测试用例

3. 罗列出是否已按本次测试计划实现功能

4. 包括资源统计、执行情况、问题统计、问题列表、遗留问题

5. 主要总结本次测试测了哪些内容、用例覆盖程度、bug解决程度等，以及最终是否决定通过本次测试。

6. 测试风险没有放在测试总结里，而是单独划分为一个模块，可见其重要性。

41. 如何定位bug：

1. 查看状态码
​
2. 查看服务器日志
​
3. 查看需求文档
​
4. F12（开发者工具）
​
5. 前台UI界面，我所提到的界面，包括界面的显示，兼容性，数据提交的判断以及页面的跳转等等，这些bug基本都是一眼可见的，不太需要定位。

42. 开发没时间修复，如何推进bug的修复：

导致开发不修改bug的因素

1、 开发与测试对bug的定义理解不一致产生的问题，例如暴力操作、非常规操作出现的问题、问题路径深、服务器返回的数据不规范、竞品同样有的问题、个别机型问题等情况，开发可能会不愿意修改。

2、 工作流程方面的原因，例如开发有更高优先级的任务没有时间修改、上线时间紧急，来不及修改、开发不关注名下的bug、开发认为目前的实现比产品需求好等情况

3、 当然还有个人能力原因，例如找不到好的解决方案、影响范围大、找不到bug原因，没有解决方案、技术实现难，不知道怎么修改等等原因

4、 另外还有一些不可抗力的客观因素，例如系统问题，第三方应用问题等等

 

开发不修改bug的原因有四：bug路径较深、上线时间紧急、改动影响范围大、第三方应用问题。解决方案

1、 针对路径较深的bug，测试在推动开发修复bug时，需要注意以下几点

a) 从用户的角度分析问题的严重性，分析用户的遇到此问题的概率，引导开发站在用户角度去思考，从而使开发意识到问题的严重性

b) 可以和开发人员列举一个之前的类似问题，为开发提供参考

c) 产品是负责这个软件的人员，当测试与开发意见无法达成一致时，不要因为无法推动开发修改而放弃，一定要找产品确认，最终的决定权交给产品人员。

2、 上线时间紧张，开发来不及修改了，这个时候测试应该分析问题的严重性，和产品人员商议是否需要修改

3、 修改bug改动较大，影响范围广，没有最优的解决方案等情况在项目即将上线的节点比较忌讳这种事情的发生。面对这种情况，建议开发人员做调研工作，请教其他的同事，或者组织一个临时会议，集众人之力研究好的修改方案

4、 第三方应用问题，开发无法修改。确认原因之后需要找相关的工作人员，例如产品，联系第三方输入法的工作人员，反馈问题，尽量推动应用解决问题

43. 软件测试流程

在立项会中制定需求文档，由UI设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写测试计划，根据模块的颗粒度划分并编写测试用例以及对用例的评审，开发结束后测试对主要功能进行冒烟测试，执行测试用例，提交bug开发进行修改，修改成功后关闭bug，进行回归测试，在上线前进行测试总结。

44. 项目介绍

45. 对一支圆珠笔进行测试，要从哪些方面进行测试？三角形测试用例设计

圆珠笔

1. 能否正常书写

2. 写出来的字遇水是否会消失

3. 是否有笔油泄露

4. 笔帽是否能正常按下弹起来

5. 一支笔可以用多少时间、写出的字是否褪色

6. 笔的长短粗细是否顺手

7. 一根笔芯用尽是否方便更换

8. 外形是否美观

9. 笔油是否含有有害物质

10. 笔尖是否容易伤到人

11. 笔油或者墨水保质期多长 过期是否产生有害物质

12. 在不同的温度、气压、和重力下能否正常使用 在不同的纸质和力度下书写结果如何

13. 长时间按住弹簧，松开后看弹簧是否可以恢复

14. 笔芯弹出弹回的快慢。

15. 连续按，看弹簧能经受多少次伸缩。

16. 如果以极快的速度按压弹簧，该笔是否会崩溃？

17. 有些圆珠笔，不关掉，或者不盖盖子很容易干燥，时间久后是否可以正常使用

18. 掉在地上是否会坏掉

19. 被踩了后是否容易坏，承受最大压力

20. 笔芯的颜色

21. 是不是可擦掉的笔

22. 图案是否会掉色

23. 笔墨的气味

24. 墨水多久能干

25. 笔杆折断，材质是不是容易刮伤手

26. 误食笔墨是否引起中毒

27. 流畅度

28. 在木板或墙壁上书写，在其他物体上书写

29. 这个笔芯的笔尖/笔壳摔坏了，我换其他的笔芯的尖能不能继续用

30. 高温和低温环境下对笔芯出墨和笔壳的影响

 

三角形测试用例设计

（参考）

https://blog.csdn.net/junjunba2689/article/details/82587612

https://www.cnblogs.com/jpr-ok/p/6374742.html

 

1、构成三角形的条件：任意两边之和大于第三边；

2、构成等腰三角形的条件：任意两边相等；

3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；

4、构成等边三角形的条件：三条边都相等。

一、等价类划分：三角形三条边A、B、C的数据类型不同

我们再分析一下三角形的等价类：

有效等价类：

输入3个正整数或正小数：

1、两数之和大于第三数，如A<B+C；B<C+A；C<A+B

2、两数之和不大于第三数

3、两数相等，如A=B或B=C或C=A

4、三数相等，如A=B=C

5、三数不相等，如A！=B，B！=C，C！=A

无效等价类：

1、空

2、负整数

3、非数字

4、少于三个数

等价类表：

 

 

 

测试用例

 

 

 

46. 在项目中发现哪些经典bug？什么原因导致的？

注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的

接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到数据

47. 一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

1. 影响用户体验
2. 如果不修改，在上线时可能会引起其他bug发生
3. 如果在版本迭代在修改，时间久了对bug的认知就没有现在清楚了
4. 拖得越久越难修复
5. 不符合需求产品需求

 

48. 在需求文档不太详细的情况下，如何开展测试？

软件生命周期中，需求是整个周期的源头。良好的开端，是成功的一半。需求的重要性自然不言而喻。但是，在很多企业中，并没有对需求引起足够的重视。原因并不是PM们不知道需求的重要性，而是商业竞争中不得不裁剪某些看似不能获得很大利益的步骤。

什么是需求？很多PM和开发人员都未必真正考虑过这个问题。IEEE对需求有以下两种定义的方式。

1. 解决用户问题或达到用户目标需要具备的条件或能力

2. 遵守合同、协议、规范或其他要求

然后用规范的文档描述出来，就成了我们熟悉的SRS。

我们常说的需求，其实并不是我们认为的SRS。SRS应该叫做需求规格说明书。那需求是什么呢？与需求规格有什么区别？

需求：对要实现的功能的粗略描

需求规格：对需求的精确定义

我们知道，在软件开发过程中，只有得知了需求的精确定义，才能开展工作。比如功能方面，编辑框能支持多少位字符。性能方面，时间和容量规定等。当然还包含其他非功能，性能方面的定义。

除了以上所说的需求，对于测试人员，还必须有测试需求。这个环节，很少有企业会重视。测试需求分为2方面：

需要测试哪些方面

软件是否可测，需要增加哪些开发需求

其中第一条，很多企业都列到了测试计划中，这也可以，没有规定一定要放到哪个文档里。但是对于第二条，可以说几乎没有多少企业去做。

接下来，在没有明确需求，需求规格，测试需求的情况下，我们怎么去做测试呢？现在很多企业，其实就是在这种情况下做项目的。

当测试人员接手一个项目后，第一件事情一定是想了解这个系统的功能，背景，架构。于是，马上就会想得到需求文档。但结果往往是失望的，根本没有文档，或者文档根本不具备参考价值。此时不必太失望，因为这种情况实在是太常见啦。这时，请试着从以下几个步骤着手。

查阅文档：文档是最具权威的，也是记忆最长久的。有时，我们的项目可能是在原有产品的基础上，进行版本升级。这时，先去找找，有没有原有版本留下的需求，或者是用户手册等文档。从这些文档中，了解项目的背景，系统的基本功能。这对了解新项目是有很大好处的。并且，在产品升级的项目中，验证老版本的功能在新版本中是否正常，也是一个必要的工作。可以先参考老版本的相关文档，设计新版本中的用例。

也有时，我们的项目是一个行业项目，比如金融项目。我们可以参

 

考一些行业知识的书籍，文档。这对理解系统也有很大的好处。

实在没有文档，那只好暂时跳过这一步骤了。

在进入下一步骤之前，你可能得到了一些相关文档，也可能什么也没得到。无论如何，你可能对系统已经有了一些了解。这时，请记录下来，写成文档。无论是对自己，还是对别人，在以后都可能极有参考价值。试想一下，如果前人已经给你留下了这些文档，你是否可以轻松很多？还要注意及时更新你的文档。因为你对系统的理解，随时都在变化着，一定要保证你的文档和当前你对系统的理解是一致的。

试着使用系统，根据经验和常识猜测：既然没有需求，那可以推测，该项目的管理一定是很糟糕的，对测试也不会投入很大的成本。因此，测试人员一般都是在编码完成后才进入项目。这时，应该已经可以看到成型的系统了。在没有需求的情况下，试着先“玩”一下系统吧。在这过程中，你应该对系统有可更深入的认识，在上一阶段中，你可能留下很多疑惑或是猜测，这时应该能排除一部分了。

使用系统的同时，你应该具备行业知识。系统可能是针对某个专业领域设计的。例如一个期货交易系统。你没有基本的期货知识，比如什么是持仓，什么是平仓。那么你如何能真正理解这个系统呢？当你有了业务知识以后，你会进行更深入的思考，来全面测试系统。

你还需要具备良好的软件知识。比如某些控件的特性。单选框只能单选，不能多选。日历控件是否可以手工输入非法格式等。这些都是应具备的意识。

最后加上你的主观判断，你对系统的整体感觉怎么样？是否越用越厌烦，为什么厌烦。系统的反应速度是否可以容忍，细节处理是否圆滑，等等。

在你认识系统的时候，可以使用一些方法，来帮助你更有效率地学习。比如可以画一些流程图。一图胜万语。同时，你也留下宝贵的文档。当然，这个步骤中，你也要随时注意保留和更新文档，以备后用。

沟通：需求规格不一定非要以文档的形式表现出来。软件既然能做出来，那肯定是有需求的。而最清除需求的，一定是软件的直接制造者，开发人员。开发人员自己知道需求，但一般不会主动和测试人员沟通。因此，测试一定要主动和开发人员沟通。可以安排会议，让开发人员给测试人员介绍系统，并演示系统。让测试人员对系统有一个整体了解。然后测试人员能进行更细致的测试。在进行细致测试的时候，一定会有更多不明确的地方。这时就需要利用自己的行业知识，计算机知识等，猜测一

 

部分。不需要每个细节都去询问开发人员。因为开发人员也有自己的工作，他们不希望花太多时间来给你解释。

有些项目中，客户会直接参与到项目组来。这时，测试人员在权限允许的情况下，可以和客户进行沟通。客户那得来的需求，是最原始的需求。但是，客户未必有良好的表达能力来描述希望的功能，也未必有计算机知识，因此不能描述出一些隐式的需求。在被允许的情况下，测试人员可以和客户进行交流，不仅可以帮助客户正确描述出真实需求，测试人员也能详细了解需求。但是项目是要考虑成本的，客户的期望是无限制的。在客户提出需求以后，测试人员要先和PM或其他相关负责人协商后，才能将与客户交流得来的需求，作为测试的依据。同事，第一时间告知相关开发人员最新的信息，也记录成文档。这时，你就将非文档形式的需求，转换为文档形式了。至于文档的格式，不一定要按照标准SRS的格式。因为它本身就不是个规范的SRS。以任何容易理解的方式，组织你的文档。

有时候，会根本找不到可以沟通的人。不要奇怪，确实就是有这种时候。比如：

1. 测试一个开源软件

2. 接到一个测试外包，但又没有得到相关文档，为了追求利益，还是接下了

3. 软件项目组的部分人员已经联系不上等等

这时候，一方面需要PM协调获取相关资料，联络相关人员。另一方面，测试人员也可组织头脑风暴，利用集体的智慧，共同探讨和猜测软件中的各个环节。也可以安排Bug Bash，让尽可能多的人员参与随机测试。一定会有人提出具有创造性的意见的。

在进行以上步骤的时候，利用良好的工具，能让你事半功倍。我经常在使用的一个工具，就是Mindjet MindManager。这是一个很好的，帮助扩展思维的工具。它以分支的形式，来表现你的思维层次。你可以先列出个最基本的系统整体结构，然后逐步细化，增加分支。不要急于一次就将真个系统分析透彻，这是不可能的。你在进行以上步骤的时候，随时会细化这个结构。当项目结束后，看看这个结构图，简直可以当作SRS来参考。

49. 如何尽快找到软件中的bug?

1、尽快熟悉公司的产品业务，根据产品的业务属性来熟悉产品的业务流程，这样才能迅速找出软件中存在的一些重要的缺陷，这样发现的软件的价值才是有价值的，否则即使你能找到一些软件缺陷，那也是纯软件的缺陷，价值不大。

2、把自己当成是用户，把自己当成用户去使用该软件，比如在试用软件的过程中，思考用户是这样操作的么

3、善于怀疑 ，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生；别人认为是对的，我却认为是错的。假如一个水平很高的程序员编写的程序，不要有“他写的这个程序应该没有问题吧”这种想法，这样很容以遗漏软件中的Bug。

4、不用让程序开发员“用户不会这样操作”的观点说服自己，遇到这样的情况，你要坚持自己的正确的观点，把这种现象作为一个Bug。

5、在测试的过程中要跟踪一条数据的完整流程，比如“点击商品—收藏商品—加入购物车—订单结算—付款—消费二维码—消费—二维码失效”，如果在测试软件过程中业务流程逻辑都走不通的话，还么这个软件测试与不测试就没有什么区别的。

6、在测试的过程中要跟踪一条数据的完整程，要注意的事项 ，程序员提交新的版本后，作为测试人员应该立即与程序员沟通这个修改的功能，并了解这个新修改的功能影响那些功能。而被影响的功能，是在回归测试中优先重点测试的地方，而且也是最容易产生Bug的地方。

7、软件的边界值 ，众所周知软件最容易在边界值上出现问题，所以作为测试人员一定要在边界值上多测试，比如测试用户输入框中的数值的最大数和最小数，以及为空的情况；

8、非法容错性，比如在需要输入数字的地方输入字母，在需要输入字母的地方输入数字，在需要用户输入的文本框中拷贝字数很多的整编文章到这里测试看看软件是如何做处理的；

9、学习他人经验：三人行必有我师焉，人外有人，天外有天。

50. 什么是bug？

• 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。

• 当没有需求规格说明书时，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

• 和预期不一致的软件行为。

  一个软件行为既可能是bug也可能不是bug，那是因为预期的主体千姿百态。

  和测试员预期不一致的软件行为。 和程序员预期不一致的软件行为。 和文档预期不一致的软件行为。 和管理者预期不一致的软件行为。 和客户预期不一致的软件行为。

51. ATM机吞卡的吞卡现象是不是BUG?

1.由于保护机制，你一次取钱数额有限，需要多次操作的时候每次现出卡你会觉得麻烦无比。

2.吞卡当然是为了安全，这没有什么争论吧。

3.至今从没见过吞了的卡还能吐出来的，根据后边ATM机的构造，也不可能再退出来，是直接掉在一个小盒子里的。

4.不可能你随时去取吞卡别人就给你取，首先ATM必须双人操作才能进，第二营业厅也必须双人在场，不能一人在营业厅，所以一般都是加钞的时候顺便取出来。

5.现在在任何地方应该都不会有不核实情况直接给人吞卡的，外行卡除外，外行卡被吞，本行毫无办法核实任何信息，只能让你出示身份证信息并登记，确保是被你这个人取走的。

52. 如何减少非问题单的提交？

熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；

53. 有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？

同类型软件在你的操作系统硬件环境上运行，如果一慢一块，则是软件问题

同一软件在别人的操作系统上，如果运行速度加快，则是你的操作系统或硬件的问题

54. 你们发现bug会怎么处理。

首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。

当BUG解决且上线没有问题之后，我们再看后续的处理。

追查原因及处理方法：这个BUG出现的原因是什么。这有分为几种情况：

1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟的 情况。

 解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。

2）漏测：

 a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例
​
 解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入对优先级进行评估，避免此类事件再次发生。
 b.测试用例执行期间遗漏：由于测试人员疏忽造成测试用例执行遗漏。
​
 解决方法：调查该名测试人员的整个测试过程的工作情况，并随机抽测其他模块，对该名测试人员进行综合评估，给出结论，是因为偷懒漏测，还是因为负责模块过多漏测，还是有其他原因     ，对该名测试人员发出警告，对相关测试主     管，项目经理，产品经理发出警告。
​
 c.测试用例覆盖不全：由于用例评审的不严格造成的；中途需求变更造成的；由于某些其他因素造成的。
​
 解决方法：找到原因，并进行记录，在以后的项目或者下一版本重点关注。

最最重要的：补测试用例！