测试工程师之基础

1、 软件测试的生命周期？（软件测试的流程）

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

2、描述软件缺陷的要素

问题出现的版本
开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。
问题出现的环境
环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
操作步骤
描述问题重现的最短步骤
实际结果
描述错误的现象。crash等可以上传log，UI问题可以有截图
预期结果
要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的

3、如何描述一个BUG

（1）版本号（代码版本号）
（2）测试环境（平台）
不同的浏览器对同一个系统的同一个页面解析是不一样的
（3） 测试步骤和测试数据
（4） 预期结果
（5） 附件 错误截图 错误日志等
（6）不要把多个bug放到一起
例如
故障发现版本：VPS20180226_01
故障类别：兼容性
故障优先级：中
故障标题:ie下界面显示异常，界面文字有重叠
故障描述：
测试环境：win7+IE8
测试步骤：1、打开vps首页，点击“通知”链接，进入通知页面
预期结果：通知页面显示正确，一页显示10条通知，按时间顺序倒序排列
实际结果：页面显示10条通知，通知顺序正确，但是页面文字有重叠
附件：上传截图

4、 BUG级别的定义

（1） 崩溃
系统运行阻断，严重的影响了开发人员好而测试人员的工作，需要立马修复，
现在出现崩溃级别的BUG怎么办，回退到一个稳定的版本
（2） 严重
系统还可以运行，但是已经不稳定了，如果再运行下去，可能会产生严重的后果。
（3） 一般
系统可以稳定的运行，但是一些次要功能没有实现，可能会影响用户的体验
（4） 次要（建议性，没有严格体现在需求里面的）
影响用户的视觉体验，界面的问题提示内容，展示，图片的排版
要不要改和产品经理商量

5、bug的生命周期

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

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

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

7、如何开始第一次测试

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