测试基础篇

回顾:

1,什么是需求?

满足用户的期望或者规定的文档(合同,规范，标准)所需要的条件和权限;
用户需求:简单的描述;
软件需求:具体的用户需求实现的细节;

2,什么是BUG?

当且仅当软件规格说明存在并且合理，如果软件功能和规格说明不相符，就说明是软件错误(BUG) ;
如果软件规格规格说明不存在，用户需求存在并且合理,软件的功能和用户需求不相符，说明是软件错误(BUG) ;
3,什么是测试用例?

测试人员向被测试系统发起的一组集合,这组操作集合包括：测试数据,测试平台,测试步骤，预期结果;
4,软件开发的五个模型

软件开发的生命周期:需求分析一 计划一 设计一 编码一 测试一 运行维护

瀑布模型，螺旋模型，迭代,增量模型,敏捷模型; .
敏捷模型之scrum:
三个角色: PO(产品经理) SM (scrum manager), ST (scrum team)

发布计划会议: PO负责讲解user story,根据user story的紧急程度排出本期要迭代的user story,形成sprint backlog.
迭代计划:细化user story，分配任务，每个人需要完成什么任务以及完成的时间节点;
研发期:每日站会,三件事,昨天做了什么,遇到什么困难，今天的计划;
项目演示会议:给用户演示完成的产品，用户会提出一定的意见，产品经理整理成新的user story 放到下一 次的迭代当中; .
回顾计划会议:对本期迭代进行总结。

概念篇
1,软件测试V模型

优点:左边开发的每一个阶段和右边测试的每一个阶段一 一对应， 是右边测试每一个阶段的依据。
缺点:测试介入晚，前期的错误和风险到后期才发现，会失去及时纠正的机会;
2,软件测试W模型

优点:测试阶段和开发阶段在两个独立的V模型里面，测试介入比较早,在项目初期就介入，前期的风险可以及时被发现;
缺点: W模型每一个阶段仍然是一个串行的过程,不能适应需求变化的项目，所以无法应用到敏捷开发

基础篇

1,软件测试的生命周期? (软件测试的流程)**

需求分析：分析需求，细化需求，验证需求的正确性和合理性
测试计划：规划测试人员数量，规划时间，测试范围，测试目的
测试开发：分析需求，从细化的需求中提炼功能点，设计测试用例
测试执行：执行测试用例，记录BUG
测试报告：测试的范围，有多少测试用例，执行了多少，余留了多少测试用例，发现了多少BUG，修改了多少BUG，验证遗留的BUG以及解决方案

2，如何描述一个BUG?

(1)版本号(代码版本号)
(2)测试环境(平台)
不同的浏览器对同一个系统的同一个页面解析是不一样的 浏览器对应的版本号 不同的机型
(3)测试步骤和测试数据
(4)实际结果
(5)预期结果
(6)附件：错误截图,错误日志等

3, BUG级别的定义

1,崩溃
系统运行阻断，严重的影响了开发人员和测试人员的工作，需要立马修复;
(2)严重
系统还可以运行，但是已经不稳定了，如果再运行下去，可能会产生严重的后果;
(3) 一般
系统可以稳定的运行，但是一些次要功能没有实现，可能会影响用户的体验
(4)次要(建议性)
没有严格体现在需求里面的;
影响用户的视觉体验，界面的文字提示内容，展示，图片的排版。要不要改和产品经理商量;

4，BUG的生命周期

● New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

问题:测试人员提了一个BUG,开发人员已经修改了,但是测试人员测试的时候，发现这个BUG依然存在，有哪些原因?
开发人员没修改好
开发人员没有把代码更新到测试环境(没有提交代码)
测试人员忘记拉取最新的代码到测试环境进行发布

如果碰到一个BUG，和开发人员发生冲突怎么办？

1.先检查自己的BUG描述是否清楚
2.检查BUG的定级是否按公司的标准定的
3.站在用户的角度去说服开发人员
4.不断提高自己的业务水平和技术水平
5.和开发人员，产品经理开会商量BUG的解决方案

如何开始第一次测试

作为一个菜鸟在进入测试团队开始第一次测试的时候，我们需要做很多的准备：
1、阅读所有项目有关的文档，包括：需求文档、设计文档、用户手册
2、尽可能参加各种项目会议，了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务专业性较强的项目，例如银行业务，需要了解各种业务知识，如高低柜、一二三类账户等、存款、贷款等。
3、熟悉项目所使用的测试管理工具、配置管理工具，获取对应的地址和登录方式
4、阅读已有的测试方案和测试案例
5、阅读旧有的bug库，了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
6、了解公司的规范要求，特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等
在进行了以上的准备工作之后，第一次测试工作到来了，我们需要与测试组长确认具体的工作内容：
1、测试的计划是什么？
2、测试的内容是什么？test case有多少？安排了几天执行？有没有自由测试的时间？
3、我要测试的内容开发人员是谁？需求人员是谁？
4、分配给我的测试内容是否需要特殊的测试资源？资源是否满足需要？
在我们确认了以上内容之后，就可以开始测试的执行了