软件测试之测试理论（价值2万的线下培训资料）

• 

  需求分析

 

1. 对于用户需求，你是怎么理解的

用户需求，就是描述用户希望把产品做成什么样的一个文档，一般都是产品经理写的。 有些需求会写得很全面，什么信息都有，很细； 但是，实际工作中，很多时候我们拿到的用户需求都是比较粗的，不全面的，甚至是有问题的； 这时候，我们要及时和上级，还有产品经理反馈。

1. 需求文档有无：

1)有需求文档：根据需求文档直接提取测试点，要重点考虑输入数据的约束、数据的流向等 2)没有需求文档：根据系统现有的功能进行提取测试点，也要考虑数据的约束、数据的流向等。 在需求文档不太详细的情况下，如何开展测试？ 参考答案： 1）、首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来； 2）、提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的， 然后再编写测试用例，再评审，评审通过后，再进行后续的测试。

1. 需求分析怎么做:

由产品经理召开需求澄清会议，对本次发布的功能需求进行讲解，测试人员利用思维导图工具对需求点进行细化和分解，为编写测试用例提供准备。

1. 需求分析做多久：

一般是1~2次

1. 需求分析参与者：

所有开发人员、测试人员、产品经理、项目经理等

1. 需求分析的对象：

《需求规格说明书》、《产品原型图》

1. 需求分析占比(测试周期)

一般10%左右

1. 当用户需求变更时，你会怎么做

a)常规分析 这个会经常遇到的，一般如果是小的需求变更，合理的话，能改的，经理会让开发直接改，然后测试再测一下就好了。 b)异常情况 如果是涉及到比较大的改动的话，会开会讨论一下会影响到的模块，测试经理会计算一下修改的成本，一般会建议放到下一个版本再修改，如果必须要改的话，开发就会改的，测试也会重新修改一下测试用例，把可能会影响到的模块再测一遍。

1. 怎么保证覆盖用户需求

a) 细化测试点 在项目开始前，要先熟悉需求，利用思维导图导出测试点，各个功能点有哪些限制条件，串讲及评审测试点， 防止之后编写测试用例出现遗漏； b) 加强用例评审 测试用例编写完之后，再进行用例的评审，看看测试点有没有遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

1. 需求文档包含哪些内容

（1）. 功能需求文档：包含每个版本要实现的功能、流程图、原型图、页面的交互、功能的约束等等 （2）. 接口需求文档：包含接口对应的功能、接口的地址、请求方式、请求参数、参数的约束、返回的报文、错误码解释、接口和接口有依赖的说明等等 （3）. 性能需求文档：性能测试点、、并发用户数、绝对并发用户数、通过指标：cpu 内存 IO 平均事务响应时间、事务通过率、90%事务响应时间、吞吐量TPS 等等;

• 测试计划

1. 编写者：

有经验的测试工程师(测试组长或者测试经理、协助组长收集数据整理、自己也可以独立编写)

1. 时间占比：

一般10%左右

1. 测试计划内容：

目的、测试背景、范围、测试策略、软硬件环境、开始和结束条件、进度安排、测试风险

1. 写测试计划的目的：

对项目整体进行工作量的评估(人力、进度、风险)

1. 测试计划：

参考测试模板

• 测试用例

1. 谁写的：

测试工程师

1. 测试用例设计方法：

（1）等价类 （2）边界值 （3）错误推测法(多个人同时修改同一条数据、空数据验证、SIM卡无效、时间控件)、 （4）判定表 （5）场景法

1. 测试用例的构成：

用例标题、优先级、预置条件、操作步骤、预期结果、实际结果

1. 用例的执行状态：

未执行、通过、失败、阻碍、观察中

1. 用例的颗粒度：

（1）颗粒度大,用例总数少 （2）颗粒度小，用例总数多

1. 1）如何写好用例？
2. 2）评审用例从哪些地方考虑？
3. 3）怎么从用例的角度覆盖需求？

a. 覆盖用户需求 b. 从正常和异常的用户使用场景来设计用例 c. 用例的颗粒度大小尽量均匀 d. 测试用例的要素要齐全，优先级安排合理 e. 容易被其他测试人员友好的执行

1. 1）测试人员写用例需要多久？
2. 2）团队输出用例的总数？
3. 3）一个版本写多少？

分析： web测试周期：比如 1 个月，22个工作日 1天  ---  需求分析 1天  ---  测试计划 5  6  7天  ---  测试用例 14 13 12天 ---  测试执行 1天  ---     测试报告 测试人员平均每天大概：50-60条 测试团队输出用例总数：3-4人    （3*50*7 ~ 4*60*7（1000或者1500条左右）） 你一个版本写多少用例：1*7*50 = （400条左右） app测试周期：比如: 1~2周  按照2周算，10个工作日 1天  ---   需求分析 1天  ---   测试计划 2 3天  --- 测试用例 5 4天 ---  测试执行 1天  ---   测试报告 测试人员平均每天大概：50-60条 测试团队输出用例总数：3-4人    （3*50*2 ~ 4*60*2 （300~500条左右）） 你一个版本写多少用例：1*2*50 = （100~200条左右）

• 测试用例执行---BUG管理

1. 测试用例谁执行

测试工程师

1. 执行多久或者测试用例执行一般几轮

一般三轮。第一轮用例执行，进行2-3轮的回归测试验证。

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

答:发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。

1. Bug状态

激活 -- 确认 -- 已解决 -- 关闭   new   新建(激活) open  打开 fixed    修复    rejected 拒绝 reopen  重新打开 close   关闭

1. Bug构成或者Bug要素有哪些

主要包括以下内容： Bug标题 严重级别 影响版本 所属模块 复现步骤 预期结果、实际结果 相关日志、截图、抓包

1. 提交Bug管理工具

禅道 其他工具： Jira  TD  Bugfree  Tower Bugzllia 等  了解

1. Bug生命周期(跟踪缺陷)

当发现缺陷后，我们要在禅道上提交问题单给开发， 并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理， 如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后， 要及时进行回归测试，如果回归通过，就关闭缺陷，如果不通过，就返回给开发继续修改。

1. 禅道怎么搭建

本地环境(基于windows)搭建 1.解压xampp环境包，放到任意磁盘根目录下面。 2.把禅道安装包配置到 xampp目录下面的htdocs目录 3.开启xampp目录下面的mysql和apache服务器 4.访问浏览器加上apache服务的端口即可访问。 5.如果端口被占用，就去修改端口....

1. 开发不改Bug如果解决

《见 测试执行ppt 12/41》

当我们认为某个地方是bug，但开发认为不是bug，怎么处理？ 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方； 有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理， 测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

1. 偶然性Bug怎么处理

 《见 测试执行ppt 9/41》

1)、在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据； 2)、确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位； 3)、如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷； 4)、如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！

1. 产品上线，被用户发现Bug如何处理？者漏测怎么处理

1)、测试人员复现问题后，提交问题单进行跟踪； 2)、评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能； 3)、问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试； 4)、总结经验，分析问题发生的原因，避免下次出现同样问题。

1. Bug等级如何划分---登录

致命：系统崩溃、导致程序重启,死机或非法退出、数据丢失或异常等； 严重：阻碍系统流程、金额计算错误等； 一般：删除提示、刷新没反应等； 轻微：界面错别字、按钮颜色、界面布局等；

1. （1）一天找多少Bug？ 你一个版本找多少Bug？
2. （2）你们团队一个版本找多少Bug？

这个不一定。 要看需求实现难易程度，数量多少、开发编码质量(技术水平)、设计测试用例质量。 就拿我上一个项目， 一天大概能找10-20条; 一个版本大概能找100条; 团队一个版本具体没算过。 如果要说的，大概100左右、 150左右、200左右都可以说。

1. 回归测试怎么做

分2种，一种是全量回归测试，一种部分回归测试。分别回答一下概念。
全量回归： 对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”。	部分回归： 当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响
怎么做回归测试：首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

1. (预测试) 冒烟测试怎么做

《见ppt》

当开发写完代码，编译好后，会提交到测试部进行测试时。测试人员搭建好环境，首先要对系统的基本功能进行测试，保证主要流程的能正常使用，这叫冒烟测试。如果冒烟测试不通过，就打回给开发人员修改。

1. 1）如何定位缺陷
2. 2）或者说一般测试过程中出现问题，你是怎么定位的

1、检查测试环境配置(端口、防火墙、权限等问题)是否有问题，测试数据(使用了旧版本数据去测试)是否有问题 2、用fiddler抓包，分析请求和响应数据是否存在问题 3、查看应用服务器的日志 4、然后再查看数据库的数据是否存在问题 延伸：测试数据哪里来的？ 1. 简单的数据，由测试人员手工创建 2. 涉及大量的数据情况，向数据库插入数据（可以找开发写一个存储过程） 3. 可以从生产环境上面导出到测试环境（找运维协助）

1. 开发没时间修复Bug，如何推进Bug修复

1)和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进； 2)确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。

1. 测试报告：

协助组长写过。自己也可以独立完成。 测试报告内容一般有： 人力投入 用例统计(通过数、失败数、通过率、未执行数量)、 问题单统计(缺陷类型： 需求类、设计编码、UI界面、用例问题) 遗留问题说明 测试风险 测试结论