一.软件测试的生命周期（软件测试的流程）
需求分析——测试计划——测试设计/开发——测试执行——报告评估
1.深入了解需求，分析需求，验证需求，去掉不合理的需求，从需求中提取出测试点
2.测试计划包括且不仅包括 时间、人员、目的、测试范围，其中测试范围和需求有直接关系
3.测试用例的编写或者开发，研发人员也在同步进行开发工作
4.此时功能已经开发完成，测试人员需要去执行测试用例验证需求是否实现，发现Bug后，需要记录，开发人员进行修改。
5.测试工作结束之后，写测试分析报告，总共执行了哪些测试用例，发现、修改、遗留了多少Bug，还要进行上线风险评估。
6.*回归测试：新开发的功能，引入了新的代码，新引入的代码很可能会影响之前的功能。系统引入新的代码的时候，为了防止新代码对老功能产生影响，需要验证想关联的功能。///测试人员发现的Bug是记录在另外一个系统（管理软件开发的过程），开发人员也可以登录，可以看到测试人员提出的Bug。
二.如果发现一个Bug，该如何去描述？
比如该注册功能，密码长度为8-16个字符，假设注册输入1个字符也注册成功，那么有了如下Bug描述：
标题：注册时密码输入1位字符，也可以注册成功
1，版本号：代码版本号 V1002
2, 测试环境：
Chrome浏览器 版本号96.0.4664.45
操作系统：Windows10
电脑品牌：联想拯救者Y7000
3，测试数据：
邮箱：123456789@qq.com
密码：1
手机号：12345678912
4， 测试步骤：
（1）打开网易邮箱注册页面：注册网易免费邮箱 - 中国第一大电子邮件服务商 (163.com)
（2）输入邮箱账户，密码，手机号
（3）点击 “同意条款”
（4）点击注册
5， 实际情况： 注册成功
6， 预期结果： 注册失败，提示“密码长度不符合规则”
描述Bug的要素：版本号，测试环境，测试数据，测试步骤，预期结果，实际结果，附件（包含错误截图，错误日志），Bug等级，标题
三.Bug的级别
崩溃：已经影响到系统的运行，司机，崩溃，死循环，（页面一级菜单无法使用，数据库查询死循环，内存泄露）
如果遇到这样崩溃级的Bug，可以通过回归版本，重新去发布之前的稳定的版本来快速修复
严重：系统还可以运行，但是不稳定了，继续运行下去就会产生严重的后果
一般：次要问题，不影响系统的稳定运行，但是会影响用户体验（次要功能没实现，某些条件下的查询错误，数据重复展示，删除一些重要文件，没有提示）
次要：界面性的，对用户使用系统没啥影响，影响用户的使用体验而已。
四.Bug的生命周期
●New:新发现的Bug，未经评审决定是否指派给开发人员进行修改。
● Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
● Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
● Rejected：如果认为不是Bug，则拒绝修改。
● Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改。
● Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
● Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。
缺陷状态变更流程每个项目团队的实际做法可能不大一样。并且需要结合实际的开发流程和协作流程来使用。
例如，测试人员新发现的Bug，必须由测试组长评审后才决定是否Open并分派给开发人员。测试人员Open的Bug 可以直接分派给Bug对应的程序模块的负责人，也可以要求都先统一提交给开发主管，由开发主管审核后再决定是 否分派给开发人员进行修改。 Bug的跟踪以及状态变更应该遵循一些基本原则：
1.测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试，确保相同的问题不再出现，才能关闭缺陷。
2.对于拒绝修改和延迟修改的Bug，需要经过包含测试人员代表和开发人员代表、用户方面的代表（或代表用户角度的人)的评审。
五. 当开发人员和测试人员由于一个Bug产生冲突的时候该怎么办？
（1）检查自身，看自己是否描述清楚了这个Bug；
（2）站在用户使用的角度，去说服开发人员；
（3）Bug级别的定义要符合当前公司的规定，要有理有据；
（4）测试人员要不断提高自己的业务水平和技术能力。不但能够发现Bug，还能够定位Bug的原因，主动为开发人员提出解决方案。
（5）可以和产品经理，项目经理，开发人员一起开会进行会议讨论，讨论Bug的解决方案。
***测试人员和开发人员的工作目的都是为了提高开发人员开发出的软件的质量，为了交付一个高质量的可用的软件。
437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
