软件测试就业

2.6 初识

一、软件测试理论

二、软件的生产过程

客户（需求产生）—>产品经理（需求文档）---->UI设计师（设计效果图）—>研发工程师（研发产品）---->测试工程师（检测软件）—>部署上线

三、软件测试概述

什么是软件测试？

利用技术手段，验证软件的是否有问题

四、软件测试目的

降低企业风险，提高用户体验

提高软件的质量，保证软件的安全，降低软件开发成本；

降低因软件缺陷带来的商业风险；

树立用户对软件的信心。

五、软件开发与软件测试的区别？

软件开发：开发人员写代码

软件测试：使用测试软件进行测试

六、学习内容

功能测试：功能测试，接口测试，自动化测试，性能测试，车载测试

趋势：两会

学习建议：模仿+思考

主动学习：教会同桌

及时复习：

晚自习：1.自我（感谢+介绍+祝福）2.家乡美

2.7 理解

软件测试的工作流程

扩展：公司人员（小公司）

例如：xxx科技有限公司

老板【1】

产品经理（业务员）【3】

研发人员（开发软件的(ui，前端，后端)）【20】

测试人员（检查软件）【3】

运维人员（维护软件的）【2】

研发/测试=1:8

前台，财务，人事

一、软件测试的定义

通过手工或者测试工具按照测试方案和流程对被测对象进行功能或性能的检测。从而验证实际结果与预期结果之间是否存在差异。

测试对象：软件的主体功能+使用说明书+配置数据

二、软件测试的生命周期

软件的生命周期：从无到有，再从有到无的过程

阶段：从小到大

需求分析—>测试计划—>测试设计—>测试执行—>测试评估

三、软件测试的原则

• 原则是每个人在行事中所遵循的准则

• 测试只能证明软件存在问题，不能证明不存在问题

• 测试工作要尽早的介入，降低修复成本

• 不能进行穷尽测试，要进行分类测试

• 缺陷存在集群现象，通常大部分BUG发生在一下小部分核心模块中；好测试的环境

• 杀虫剂现象，尽量多的测试手段以便发生更多的BUG

• 测试依赖环境，对软件开展测试前应先准备好测试的环境

• 不存在缺陷是谬论

四、软件测试分类

按软件产生的阶段划分：

单元测试，集成测试，系统测试，验收测试(α，β，γ，UAT)

单元测试：白盒（函数，类）黑盒（窗口，菜单，按钮）

集成测试：模块与模块之间的测试；

系统测试：对软件整体（功能，性能等）进行全面测试

验收测试：α.内测，β.公测，γ.候选版本，UAT用户测试

按代码可见度划分：

黑盒测试（看不见内部），灰盒测试（可见内容有限），白盒测试（完全能看见）

按是否运行划分：

静态测试：指不实际运行被测软件，而只是静态的检查程序代码、界面或文档中可能存在的错误过程。

动态测试：指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。

按测试手段划分：

人工测试，自动化测试

其他测试：

冒烟测试，回归测试，随机测试

冒烟测试：对核心功能按照全部正确的数据或者流程，对系统进行最基本功能的测试，保证软件最基本的功能和流程能走通。

回归测试：对已修复BUG，再次测试；软件版本更新/迭代后，对老版本的内容再次测试。

随机测试：1.挑选之前发生严重BUG的地方 2.挑选之前漏测的地方 3.挑核心模块（主业务和关于钱的）

五、软件的开发与测试模型

1.软件开发模型

瀑布模型

• 需求分析—设计—编码—实现—软件测试—完成—维护
• 瀑布模型特点：瀑布模型是一种线性的

瀑布模型的优缺点

• 优点：开发的各个阶段比较清晰，当前阶段完成后，只需关注后续阶段；强调早期的计划与需求调研；适合需求稳定的产品。
• 缺点：不适应需求的化，依赖早期的需求调研；风险延至后期才暴露，失去了及早纠正的机会。
• 改良：在前期一些重要的阶段之间加入了迭代的思想，尽量避免把风险拖至后期。

2.测试模型

1>V模型

需求分析—概要设计—详细设计—编码—单元测试—集成测试—系统测试—验收测试

• 优点：开发的各个阶段比较清晰，当前阶段完成后，只需关注后续阶段；强调早期的计划与需求调研；适合需求稳定的产品。
• 缺点：不适应需求的化，依赖早期的需求调研；风险延至后期才暴露，失去了及早纠正的机会。
• 改良：在前期一些重要的阶段之间加入了迭代的思想，尽量避免把风险拖至后期。

2>W模型

开发模型与测试模型合在一起

六、B/S与C/S架构

1.测试考虑

B/S架构（浏览器与服务器）

测试考虑：网站在各种了浏览器能打开

C/S架构（客户端与服务器）

测试考虑：软件在各种手机上都能安装使用

2.B/S与C/S架构的区别？

• B/S比C/S架构成本低，升级便利
• 但是C/S架构更安全，更效率

七、软件质量模型

ISO：国际标准

例：如何验证某系统质量呢？以微信为例

• 功能性：与需求数量一致，功能正确；
• 性能：响应快、占用资源少；
• 兼容性：不同设备平台正常使用；
• 易用性：用户体验好；
• 安全性：敏感信息无泄密存储有保障；
• 可靠性：持久运行无异常；
• 可移植性：升级迁移数据不丢失；
• 可维护性：异常恢复简单、可扩展功能、升级更新便捷。

面试问题

• 你们公司的测试流程能说一下吗？

• 你们公司的验收测试是怎么做的？

• 三选一：1.去甲方 2.甲方来 3.第三方

  你能说一下黑盒测试和白盒测试的区别吗？

• 黑盒测试：重点关注软件的功能以及性能是否满足需求

• 白盒测试：重点关注代码以及逻辑是否正确

  你们软件多久迭代一次？迭代后回归测试做多久？

• 迭代：大版本：2、3个月迭代一次；小版本：1、2周迭代一次

• 回归测试：大版本十几天；小版本几天。

2.8

一、测试用例

什么是测试用例？

测试用例（test case）是为测试项目而设计的执行文档

作用：防止漏测，重复测试，实施测试的标准，以便更好的开展测试工作。

二、测试用例编写格式（要素）

通常用Excel文档编写，要素由以下八个要素组成：

用例编号、用例标题、测试模块、优先级、前置条件、测试步骤、测试数据、预期结果。

用例编号：通常由项目_模块_编号组成；

用例标题：预期结果（测试点）；

测试模块：所属项目或模块/子模块。

优先级：表示用例的重要程度或影响力，由高至低依次为1、2、3、4（也有称P0、P1、P2、P3）；

前置条件：要执行此条用例，有哪些前置操作；

测试步骤：描述操作的步骤；

测试数据：操作软件需要的数据，没有可以不填；

预期结果：期望达到的结果（唯一性）。

三、缺陷

1.缺陷定义

软件在使用过程中存在的任何问题都叫软件缺陷，简称Bug。

软件缺陷的存在会导致软件产品在某种程度上不能满足用户需求。

2.缺陷判定标准

少功能：软件未实现需求说明书中明确要求的功能。

多功能：软件实现的功能超出了需求说明书指明的范围。

功能错误：软件出现了需求说明书中指明不应该出现的错误。

隐形功能错误：软件未实现需求说明书中虽未明确指明但应实现的要求。

不易使用：软件难以理解，不易使用，运行缓慢，用户体验不好。（隐形功能错误和不易使用，尽量不提）

3.缺陷的跟踪流程（缺陷的生命周期）

口述：

我提交BUG，通知开发人员，开发人员会先判断这个BUG是否重复，如果重复则关闭这个缺陷，如果不重复，则判断这个缺陷是否是个BUG，确认这个是BUG后，与开发，项目经理等项目相关人员进行商讨是直接修复还是推迟处理，如果推迟处理，确认推迟处理的版本和日期，如果不能直接则立即修复，修复之后由我进行再次测试，如果测试通过则关闭这个BUG，如果测试没有通过则重新提交BUG，由开发人员再次判断。

4.缺陷的核心内容

缺陷标题，缺陷的预置条件，缺陷的复现步骤，缺陷的预期结果，缺陷的实际结果，缺陷的严重程度，修复缺陷的优先级，缺陷的附件。

5.缺陷的严重程度

通常指缺陷对软件质量的破坏程度，即此缺陷的存在将对软件的功能和性能产生怎样的影响。

共分为4级，由高至低依次为1、2、3、4（P0、P1、P2、P3）。

• 1级（P0）致命：死机，非法退出，死循环，数据库发生死锁。

  如：软件死机，意外退出，操作系统崩溃。

• 2级（P1）严重：功能不符，严重计算错误，接口数据错误等。

  如：主要功能失效或未实现。

• 3级（P2）一般：界面或内容错误，异常操作未给出提示等。

  如：非主要功能失效或未实现。

• 4级（P3）轻微：格式不规范，提示窗口文字未采用行业术语等。

  如：某个控件没有对齐，某个标点符号丢失等。

• 5级（P4）建议型（如果有）

6.修复缺陷的优先级

表示处理和修正软件缺陷的先后顺序。即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

共分为4级，由高至低依次为1、2、3、4（P0、P1、P2、P3）。

• 1级（P0）紧急：立即修复。如：1天内修复。
• 2级（P1）高级：几天内修复。如：一周内修复。
• 3级（P2）中级：上线前修复。如：此版本上线前修复。
• 4级（P3）低级：时间允许时再修复。如：在不影响软件主要功能使用的前提下，可考虑在后续版本修复。

一般而言，严重程度高的缺陷修复的优先级也高。但我们还需要注意，有些BUG严重程度低修复的优先级不一定低。

7.提交缺陷注意事项

8.编写缺陷规范

9.缺陷修改补充说明

• 并不是所有缺陷都要修复；考虑性价比和时间
• 有时市场的压力使得产品最终发行有时间限制；
• 或者测试人员错误理解或者不正确操作引出的缺陷；
• 错误的修改影响的模块较多，带来的风险较大(遗留)；
• 修改性价比太低；
• 缺陷报告中提出的问题很难重现等等，这些原因导致的缺陷会视情况而定。

为什么开发人员会拒绝修改缺陷？

程序员无法重现或者现象难以捕捉；

没有明确的报告以说明重现缺陷的步骤；

程序员无法读懂的缺陷报告；

用户很少使用或者不符合用户使用习惯的操作出错；

由不受信任的测试人员提出。

10.缺陷密度计算

进行缺陷密度计算，可有效的进行软件管理。目前行业标准是每一千行代码中存在5个以上Bug。

缺陷总数÷代码行数×1000‰ = 缺陷密度（/KLOC）

如：一个1万行的源程序代码里发现了68个缺陷

则缺陷密度为：6.8/KLOC

计算方式：68÷10000×1000‰=6.8‰

小结：

1、如何描述软件的生命周期？

2、如何描述软件测试的生命周期？

3、软件测试的工作流程是什么？

4、软件测试的定义是什么？

5、软件测试的对象是什么？

6、软件测试的目的是什么？

7、软件测试的原则是什么？

8、软件测试分为哪些类？

9、瀑布模型是什么？如何改良？

10、V模型与W模型是什么？V模型如何改良？

11、B/S架构与C/S架构有什么区别？

12、软件测试的质量标准（特性）是什么？

13、测试用例的要素有哪些？

14、测试用例的作用是什么？

15、什么是缺陷？

16、发现Bug后，你是怎么确认的？

17、缺陷的要素（Bug单）有哪些？

18、缺陷的严重程度以及修复缺陷的优先级怎么划分？

19、缺陷的处理流程（生命周期）？

20、你提交的缺陷开发不认可你怎么办？

21、如何提交一条高质量的Bug？

面试问题

1、你提交的BUG开发认为不是个BUG，你会怎么做？（你提交的缺陷开发不认可你怎么办？）

首先我会看下开发是在什么情况下认为它不是个BUG，其次我会跟开发核对下需求文档，看是否理解有异（角度不同）；

若开发还是不认可，我会再次把BUG的重现步骤以及相关的截图以及运行日志一并发给开发验证；

实在解决不了我会向经理报风险，通常会在周五下午的周总结会上提出，并解决；若比较紧急，会立即开会解决。

2、测试用例的要素有哪些？

用例编号、用例标题、测试模块、优先级、前置条件、测试步骤、测试数据、预期结果。

3、发现Bug后，你是怎么确认的？

发现异常情况后，初步判断是否可能是Bug。我会检查是否是由于测试环境、数据等外部因素导致的异常。

• 复现问题：尝试按照相同的步骤重现问题，确保问题的可复现性。如果问题无法复现，我会记录下来并继续观察，看是否能在其他条件下复现。
• 排除干扰因素：检查是否是由于测试环境、数据等外部因素导致的异常。例如，检查网络连接是否正常、数据库是否正确初始化等。
• 确认问题：如果能够稳定复现且排除了外部因素干扰，基本可以确认为Bug。我会详细记录问题的重现步骤、截图、日志等信息，以便开发人员快速定位问题。

发现BUG我会先检查是不是环境的问题，然后复现BUG

4、缺陷的要素（Bug单）有哪些？

缺陷编号、缺陷标题、缺陷描述、缺陷级别、优先级、所属模块、与缺陷相关的具体需求或功能点、状态：缺陷的当前状态（如新建、已确认、已修复、已关闭等）。

5、缺陷的严重程度以及修复缺陷的优先级怎么划分？

6、缺陷的处理流程（生命周期）？

7、如何提交一条高质量的Bug？

确认，复现，附件（截图，视频等）

自己先确认这是BUG ，然后复现这个BUG，把这个BUG的复现过程写清楚

注意事项：1.一个BUG一个单 2.填写BUG单，要简明，提要

8、你一天能写多少条用例？

9、你一天能执行多少条用例？

10、如果时间紧急，没时间写用例，你怎么开展工作？

11、你一天能找几个BUG？