软件测试基础篇

基础篇

软件测试的生命周期
如何描述一个bug
如何定义bug的级别
bug的生命周期
产生争执怎么办

软件测试的生命周期

1、需求分析
2、计划【时间，人员，功能的方向和范围】
3、设计【功能，框架，算法】
4、编码
5、测试
6、运行维护

1.需求分析： 验证需求的正确性以及合理性,并且在这个阶段就可以开始细化需求,为写测试用例来准备
2.计划：确定测试的人数、时间、环境、设备等等
3.设计/编码：测试设计就是根据需求来写测试用例
4.此时开发已经完成，执行测试用例，验证功能，
在验证功能的过程中，可能会遇到 软件功能与需求不相符的七情，也就是出BUG了。
于是，测试人员就会把这个BUG 交给 开发人员。
等到开发人员处理好了之后，我们测试人员又要对其进行验证。
5：运行维护：
1、写了多少测试用例，执行了多少测试用例。
2、剩余的测试用例，为什么不把它执行完。
?
3、BUG数量。
4、已解决的BUG数量
5、遗留的BUG，以及解决方案。
?
6、此次测试的范围和测试功能都要说清楚

描述BUG

为了给开发人员看。
文字 和 口头 描述，都是存在的。
除此之外，还有 禅道，jira，tapd。
?
但实际上，我们是有专门的 BUG管理工具。
这个工具里面，它会把 BUG需要描述的地方，讲得非常清楚

描述一个BUG需要几个具体的步骤:

测试的版本

测试数据

测试数据的正确性本身就对我们的测试进程有至关重要的影响,首先 如果一个正确的数据不能通过那么就说明存在BUG,一个错的数据能登录也说明存在BUG,这样我们可以先通过测试数据去更快的进行测试

测试步骤

通过测试步骤,快速找到某一个BUG,最好是将bug的位置或者具体信息找到与开发人员进行交流

测试结果

不看到结果，我们怎么知道验证的软件功能是否正确br> 拿着预期结果 与 实际结果 进行比较，如果匹配，表示软件功能实现完成，反之，则软件功能实现失败。
这样开发人员就知道，他需要关注的地方在哪里

附件、错误日志、错误截图等等都是能帮助我们去定位解决bu7、其他

某些公司会有一些其他的要求，例如故障的分类：功能故障，界面故障，兼容性故障等。有些有优先级的分类，严重影响测试需要开发人员优先修改的，可以设置优先级为高
?
8、不要把多个bug放到一起
在无法确认是同一段代码造成的故障时，不要将bug放在一起提交

BUG的级别 (了解)

如果因为 BUG 和 开发人员产生冲突，该如何处理 面试问题

1、检查，查看自己对BUG的描述是否清楚
?
2、从用户的角度去说服开发人员
应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员
更加积极地、高质量地修改Bug。
因为有些时候，真的有些bug可改可不改。
但是改了的，用户的体验会非常好。
而且，有些bug产生的原因是因为 在需求文档中没有描述的很清楚！
虽然 软件需求 是 用户需求 的进一步细化，但是有些时候，产品经理也考虑的不是很周全。
又或者说，没有产品经理该怎么办br> 下面我们来看一个例子
3、BUG定级要有理有据【根据公司的规范】
如果只是你自己觉得这个BUG很严重，人家开发人员肯定不干！
人家是为公司打工，又不是为你。
?
4、要不断提升 自己的 业务水平，和 技术水平。
不但能够发现BUG，并且能够定位。
还能够提出解决方案
【这些能力，工作久了，自然也就具备了】
?
5、开发人员不接受时，不要争吵,
可能你已经经过了多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。
找产品经理讨论，后面就会开展一个三方会议、
测试人员，开发人员，产品经理会一起讨论这个bug的最终解决方案。

QQ登录测试用例