软件测试之---------测试基础

01.你在测试中发现了一个 bug ，但是开发经理认为这不是一个 bug ，你应该怎样解决。

• 首先，将问题提交到缺陷管理库里面进行备案。
• 然后，要获取判断的依据和标准：
  • 根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
  • 如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
  • 根据用户的一般使用习惯，来确认是否是缺陷；
  • 与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
  • 合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
  • 等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并由上级做出决定。

02.给你一个网站，你如何测试？

• 首先，查找需求说明、网站设计 m 等相关文档，分析测试需求。
• 制定测试计划，确定测试范围和测试策略，一般包括以下几个部分：
  功能性测试；界面测试；性能测试；数据库测试；安全性测试；兼容性测试
• 设计测试用例：
  功能性测试可以包括，但不限于以下几个方面：等价类划分、边界值、错误推导法、因果图法、判定表驱动法、正交法、功能图法、场景法。
• 链接测试。链接是否正确跳转，是否存在空页面和无效页面，是否有不正确的出错信息返回等。
• 提交功能的测试。多媒体元素是否可以正确加载和显示。多语言支持是否能够正确显示选择的语言等。
• 界面测试可以包括但不限于一下几个方面：
  页面是否风格统一，美观
  页面布局是否合理，重点内容和热点内容是否突出
  控件是否正常使用
  对于必须但为安装的空间，是否提供自动下载并安装的功能
  文字检查
• 性能测试一般从以下几个方面考虑：
  压力测试；负载测试；强度测试
• 数据库测试要具体决定是否需要开展。数据库一般需要考虑连结性，对数据的存取操作，数据内容的验证等方面。
• 安全性测试：
  1 基本的登录功能的检查
  2 是否存在溢出错误，导致系统崩溃或者权限泄露
  3 相关开发语言的常见安全性问题检查，例如 SQL 注入等。
  4 如果需要高级的安全性测试，确定获得专业安全公司的帮助，外包测试，或者获取支持兼容性测试，根据需求说明的内容，确定支持的平台组合：
• 浏览器的兼容性；操作系统的兼容性；软件平台的兼容性；数据库的兼容性
• 开展测试，并记录缺陷。合理的安排调整测试进度，提前获取测试所需的资源，建立管理体系（例如，需求变更、风险、配置、测试文档、缺陷报告、人力资源等内容）。
• 定期评审，对测试进行评估和总结，调整测试的内容。

03. 如何制定测试计划？

软件测试计划是对测试过程的一个整体上的设计；通过手机项目和产品的信息，对测试范围，测试风险进行分析，对测试用例，工作量，资源和时间等进行估算，对测试采用测试策略，方法，环境，资源，进度等做出合理的安排。每个公司用的测试计划的模板，测试计划要点一般包括：

1.确定测试范围

2.制定测试策略

3.测试资源安排

4.进度安排

5.风险及策略

04. 测试策略(测试方案)包含哪些？

测试策略也叫做测试方案,简单点说就是描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试，安全测试，兼容 测试，回归测试）。

测试策略制定主要包含三部分：

1) 确定测试范围

2) 测试过程中要使用的测试技术和测试工具；

3) 确定测试完成的标准，比如：测试用例全部执行，没有 M级别以上的问题单等

05. 系统测试的测试策略有哪些？系统测试范围？

16种测试策略：功能测试，性能测试，压力测试，容量测试，安全性测试，GUI 测试，可用性测试，安装测试，配置测试，异常测试，备份测试，健壮性测试，文档测试，在 线帮助测试，网络测试，稳定性测试在：正常情况下测试；非正常情况下测试；边界测试；非法，极端测试

06. 软件测试的类型有哪些？

功能测试，界面测试，安全测试，本地化/国际化测试，数据库测试，可靠性测试，集成测试，兼容性测试，自动化测试，性能测试，回归测试

07. 测试策略/方案与测试计划区别？

测试计划是管理层面的，从组织管理的角度规划测试活动，而测试方案是技术层面的，从技术的角度规划测试活动。总而言之，测试方案需要在测试计划的指导下进行，测试计划提出“做什么”，而测试方案明确“怎么做”

08. 测试报告包括哪些？

每个公司使用的测试报告模板不同，缺陷测试报告要点一般包括

1) 项目概述

背景介绍、测试目的、测试范围项目经理、需求、开发、测试等相关负责人名字

2) 数据统计

人力投入：需求分析、设计测试用例、执行测试需要多少人

用例覆盖统计：用例总数、通过用例数、未通过用例数、未测试用例数，通过率

问题单不同维度统计：按照bug严重级别统计，按bug类型分类统计，按bug状态分类统计等等

3) 测试风险，规避措施，以及优先级

测试用例覆盖不全

测试人力不足导致测试进度滞后

测试人员经验不足导致测试结果分析不全面

4）对被测试版本的一个评估给予测试结论：通过/不通过

5）最后，还可以附上当前版本问题单列表链接，方便查看

09. 测试过程中需要对两个文件进行比较，您会怎么进行测试？

测试过程中需要对两个文件进行比较，您会怎么进行测试？在测试过程中，经常需要对测试结果或者某些文件进行对比，以便检查文件之间的差异，从而判断测试是否通过。这时可以利用Beyond Compare比较工具来帮助测试人员准确快速的完成这样的测试任务。利用beyond compare比较工具比人工查找和比较要快很多，而且准确得多，因此能大大降低测试人员的工作量以及测试时间，从而提高测试工作效率

10. 软件验收测试包括哪些？

正式验收测试

非正式验收测试(α测试和β测试)正式验收测试

非正式验收测试(α测试和β测试)

11.报表测试怎么测？

报表测试需要在理解业务的基础上进行，例如需要知道报表的命名，专业术语是否贴合 用户的语言，是否能被用户理解，报表中展示的数据是否是用户最关心的数据，报表展示的方式是否符合用户的习惯等；报表测试还需要注意一些细节问题的处理，例如，数据的四舍五入，单位转换，日期格式等。报表测试也可能需要进行性能测试，要着重检查报表在大数据量的时候显示速度，展示方式是否存在问题。

报表统计的原理就是从数据库的各个表中去抽取数据，处理后展示在页面上，所以在测试中，需要去操作其它模块/部件/系统来生成测试数据，再在报表上查看数据是否准确。报表中的数据问题，很多时候是各个角色的人对字段的理解不一致。

12.你怎么判断一个问题是属于前端还是后端的?或者是属于app的?

1）可以通过fiddler/F12抓包分析前后端的交互，如果前端请求参数不对则是前端的问题，如果前端请求参数正确但后端响应不对则是后端的问题；

2）也可以通过看日志，根据日志中的提示信息来判断是前端还是后端的日志；

3）根据经验判断，常见的问题类型如下：

前端问题：界面显示、字体、对齐、展示消息等

后端问题：数据问题、业务逻辑问题等

13.你写用例的时候，怎么确保用例的覆盖度？

1）首先要分析清楚需求去提取测试点，针对需求中描述不清楚的情况，需要找相关的人员确定清楚；

2）在设计用例的时候，根据等价类、边界值、错误推测、场景分析等方法编写用例；

3）编写好的用例在小组内评审，让小组成员充分提问，最终的用例是经过大家评审后 的结果；

4）测试经验。

14.测试人员如何保证测试质量

 测试人员应该从整个测试流程来把控软件质量，在整个过程中应当与其他研发人员共同提高产品的功能质量。

可以从测试流程、缺陷统计、风险把控三个维度把控质量。

  1）首先测试流程维度有以下方面把控

1. 在需求阶段，需求有准确的定位，尽可能和开发、产品对齐需求时有大致相同的需求理解，可进行需求串讲会议。
2. 测试用例的选择，用最少的测试用例，覆盖最广的测试功能点
3. 根据开发交付的可测试产品，制定好测试执行的顺序。
4. 开发提测后，应该有对应的冒烟测试，如果提测功能没有实现，打回重新编码。
5. 回归测试，建立有效率的回归测试，对于回归测试不仅要回归目标bug,也要进行深度和广度的测试，防止开发在修复bug时引发其他问题。
6. 适当引入自动化，提高测试效率。
7. 测试分层，进行接口测试，可减少修复成本。
8. 根据产品需求，进行探索性测试和交叉测试。
9. 如有条件做beta测试，从真实使用的场景把控软件。         

 2）第二方面在跟踪测试缺陷，把握产品版本，使用缺陷管理工具，比如bugfree,记录和跟踪bug,对遗留缺陷进行分析和解决。

 3）版本控制，建立主干分支，版本有问题可以随时回退。

 4）测试评估，对测试结果进行分析，根据测试出来的问题，整理出文档，确定哪些缺陷必须解决，哪些可以下个版本解决，讨论上线的风险，制定发生问题的解决方案。

5）制定测试结束的标准：用例全部执行、覆盖率达到标准、缺陷率达到标准、其他指标达到质量标准。

最后测试人员要具备必要的测试理论和技能支持，也要不断的提升自身，以便更熟练、顺利的展开测试工作，也应和其他的研发人员有良好的沟通，软件的质量不仅仅是靠测试人员保证的，而是整个团队的责任，大家一起努力才能让产品更好。

15.描述测试用例的流程？

1. 首先熟悉并且分析项目业务需求，从而了解产品的业务和功能点
2. 根据功能模块进行细化分析，使用一些用例设计方法，比如等价类，边界值、场景法、错误推测法，因故判断等设计测试用例，用特定的模板编写好即可
3. 每个功能模块，写完测试用例之后我们可以从业务流程出发去考虑是否覆盖了所有的用例，如果没有就进行补充
4. 第四个呢，另外还需要补充UI界面测试，兼容性测试，性能测试，安全性测试等维度
5. 最后测试用例编写完账户，需要提交进行评审。

16.描述下你们的测试流程？

 1）需求评审和分析

 2）制定测试计划

 3）根据需求文档编写测试用例

4）测试用例评审

5）提测后执行冒烟测试

6）执行第一轮测试，提交bug

7）执行回归测试，验证bug

8）执行第二轮测试

9）部署项目到预生产环境

10）预生产环境测试

11）发测试报告

12）项目上线

13）线上验证和监控（主流程、主功能点的验证）

17.遇到概率性的bug怎么处理？

首先需要明确的是，该类bug也是需要提单的，描述清楚当时操作环境、操作步骤、数据、并提供必要的日志，可备注上可能产生的原因。

然后耐心一点，运用排除法、错误推测找规律，必要时找开发人员、项目经理一起定位分析讨论。

如果最终任未解决，那么需要在测试报告中体现，并分析可能造成的影响，大家一起权衡该bug是否可遗留。

18. 线上出现了bug，你的处理办法是什么？

根据之前的一些经验来看，首先和开发一起初步评估问题的严重程度和产生原因，快速恢复线上业务。

1. 如果出现影响面比较大的功能上的，且暂时不好定位原因，首先考虑进行代码回滚，恢复上一个比较稳定的版本，在测试环境进行进行复测并定位问题的原因；
2. 如果能快速的定位原因，开发会进行紧急修复，测试通过后，会申请紧急的上线；
3. 如果是性能方面的问题要进行扩盘处理或者是重启尝试解决，然后开发进行进一步的问题定位和优化；
4. 如果是不太严重的问题，通常会在下一个版本解决；

     5 .最后线上问题解决后，要进行问题的复盘，将整个过程记录下，并进行相关的分析和总结，避免后续出现同样的问题。

19.B/S架构的系统从哪些点去测？

1)功能：链接测试、导航菜单、页面的跳转、表单测试、数据测试、业务逻辑测试

2)兼容性：跟客户确认其常会用的浏览器，再加上IE、火狐和谷歌等进行兼容性的测试

3)界面：字体颜色大小、图标和字段间距等

4)性能：连接速度、负载测试、压力测试

5)安全性：权限控制、链接封装、日志记录的测试、登陆密文、修改密码后重新登陆、登陆失效时间。

20.如何测试水杯？

测试项目：一次性杯子

需求测试：查看杯子使用说明书

界面测试：查看杯子外观

功能性：用水杯装水看漏不漏；水能不能被喝到

安全性：杯子有没有毒或细菌

抗破坏性：杯子从不同高度落下的损坏程度

可移植性：杯子在不同的地方、温度等环节下是否可正常使用

兼容性：杯子是否能够容纳果汁、白水、酒精、汽油等

易用性：杯子是否烫手、是否有防滑措施、是否方便饮用

用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述

疲劳测试：将杯子盛上水放置24小时监测泄漏时间和情况；盛上汽油放置24小时监测是否有泄露时间和情况等

压力测试：用根针并在针上面不断加重量，看压强多大时会穿透

跌落测试：杯子加包装，在多高的情况摔下不破损

震动测试：杯子加包装，六面震动，检查产品是否能应对恶劣的铁路、公路、航空运输