回顾

测试用例怎么写？

测试点：不包含测试步骤，只有测试什么，只有测什么功能，预期的结果。

为了提高作业的效率 ，测试用例只写测试点。

——直接写在Xmind 或者Excel

效率会比较高

面试的时候，

就直接说测试点 是为了有限的时间；

完整的测试用例：

——————————————————————————-——————

概念篇

 

//等到春招的时候进行复习或者随时可以达到最高的效率//

1.需求：

用户需求 ：（boss、业务人员、用户、甲方 ）需求的来源（根源）；

用户的需求是需要验证和分析，去掉不合理的需求；

软件需求：由用户的需求转化而来，是用户需求的细化。是具体的实现细节。

需求是软件测试人员进行测试的依据。

什么软件测试？**

软件测试是测试人员判断系统的功能是否满足需求;

测试人员应该尽早的介入需求，有助于我们深刻的了解需求；

2.什么是bug？（软件错误）

软件需求规格书存在并且合理，软件功能的和软件需求规格说明书不相符，说明就是软件错误

软件需求规格书不存在，则判断用户需求是否合理，若不符合用户的需求就是bug

3.软件开发的五个模型

瀑布模型、螺旋模型、迭代增量模型、敏捷模型；

敏捷模型：

人员组成：PO SM ST

流程

1.发布计划会 2. 迭代计划会 3. 每日站会 4.产品演示会 5.项目总结，优化。

（轻文档、轻流程、重目标、重产出、团队小，周期短）

4.软件测试的两个模型

v模型——左边的开发的每一个阶段 与 测试的每一个阶段对应起来，是测试每一个阶段的依据 ；

——优点：特点也就是优点

——缺点：串行，瀑布模型的变体

————1）不能适应需求的变化

————2）测试在后期才介入，导致前期的错误没有办法及时纠正，风险到项目后期才会发现，失去及时修改的机会

w模型

——特点：测试在需求分析阶段就进行介入，双V模型，开发和测试是并行的。也同样是串行；

——优点：测试介入比较早项目前期的问题可以及时发现，可以在一定程度上保证产品的质量。

——缺点：串行的过程，阶段性强，不适应于敏捷开发

5.测试用例？（什么是测试用例）

测试用例解决了: 测什么 怎么测

是向被测试软件发起的一组集合，这组集合包括

——测试环境，测试数据，测试步骤，预期结果（标题、重要性、优先级、功能模块、测试方法）；

————————————————————————————————————-

软件测试的教程 第三节 基础篇

1.软件测试的生命周期？（第一个生命周期——软件开发）

软件开发的生命周期(流程）：需求分析、开发计划、设计、编码、测试、运行维护；

软件测试的生命周期（流程）：需求分析——测试计划——测试设计/开发——测试执行——报告评估

需求分析：深入了解需求 分析需求 验证需求、去掉不合理的需求、从需求之中提取出测试点

测试计划： 时间 人员 目的 测试范围

测试设计：测试用例的开发或者编写、开发人员在同步进行开发工作；

测试执行：功能已经开发完成 、测试人员要执行测试用例去验证需求是否实现 发现bug需要进行记录，开发人员进行修改——

——测试人员发现的bug是记录在另外一个系统之（管理软件开发过程）开发人员也可以登录，可以看见测试人员提出的BUG；

报告评估：测试工作结束之后、写测试分析报告、

——发现了什么BUG 修改了多少BUG 遗留BUG 上线风险

——————————————————————

当新开发功能的时候，引入了新的代码，新引入的代码很可能会影响之前的功能。

——回归测试：系统引入新的代码的时候，为了防止新代码对老功能产生影响，需要验证相关联的功能；

————————————————————————————————————、

2.如果发现一个bug，如何描述？

例如：邮箱的登录界面 BUG： 在注册功能上 需要密码的长度是 8-16个字符，注册是输入1个字符，也注册成功了？

 

使用文字进行描述该bug：

标题： 密码长度是8-16个字符，但是现在输入一个字符，也可以注册成功；

---

1）版本号：代码的版本号 V1002

2）测试环境:Chrome 浏览器 版本号 9696969696

操作系统:Windows 10 ，电脑的品牌型号

3）测试数据：

邮箱 ：15487874212@163.com

密码：1

手机号：15902955121

4）测试步骤：

1）打开邮箱注册页面

2）输入 邮箱账户，密码，手机号

3）点击 同意条框

4）点击注册

5、实际情况：注册成功

6、预期结果：注册失败，提示“密码长度不符合规格”

BUG的级别，附件（截图、错误日志）

——————————————————————————————————

关于版本号：

 

描述bug的要素：

代码的版本号；测试环境；测试数据；预期结果；实际结果；附件（错误截图，错误日志）；等级；标题

3.BUG的描述

例如：

-和别的妹子约炮（崩溃）

-和别的妹子搞暧昧（严重）

-和别的妹子吃饭饭（一般）

-多看了妹子几眼（次要）

崩溃：已经影响系统的运行，死机、崩溃、死循环 页面一级重要的菜单无法使用，数据库查询死循环，

内存泄露。

当线上出现崩溃级别的BUG，如何进行快速的修复？——回归版本，重新发布之前的稳定的版本；

严重：系统还可以运行，但是不稳定了，继续运行下去会产生严重的后果

例如：直播画面的失真、数据泄露、在日志当中不可以出现用户的手机号卡号等私密的信息

一般：次要，不影响系统的稳定性，但会影响用户体验

次要（建议）：

界面性，对用户使用的系统没啥影响 ，影响用户的体验使用。

————————————————————————————

抽烟区

-————————————————

4.BUG 的生命周期

不同的公司、每一个工具对bug'的生命周期的定义都是不一致的

测试人员应该紧跟每一个bug整个生命周期，从OPen-Closed的所有状态。

bug状态转换图

 

new是发现一个bug

open是确认是bug ，并且认为需要进行修改，指派给相应的开发人员。

Fixed：开发人员进行修改后标识修改状态，有待测试人员的回归测试验证

Rejected:如果认为不是bug，则拒绝修改。

Delay：如果认为不需要修改或者暂时不能修改，则进行延后修改；

Closed:修改的=状态的=的BUG经过测试人员的回归检测验证通过，则关闭BUG

Reopend：如果验证后BUG仍然存在，则需要重新打开bug，进行重新修改

5.当开发人员和测试人员产生冲突的时候改造怎么办？

沟通能力，应变能力，团队协作能力)

1） 检查自身，看是否描述清楚了这个BUG

2）站在用户使用的角度，去说服开发人员

3）BUG级别 定义要符合公司的规定，要有理有据；

4）测试人员，要不断提高自己的业务水平和技术能力。不但可以发现bug，还可以定位BUG，提出解决方案。‘

5）可以和产品经理，开发人员一起进行讨论，讨论BUG的解决方案。

last but not least ,

测试人员的目的是为了提高开发人员开发软件的质量，和软件开发人员目标是一致的

，为了交付一个高质量可用的软件。

关于上一次的qq登录界面的此时用例的练习

 

在界面上面出现的每一个元素都应该照顾到。