测试基础架构经测试人员回归测试完毕后，发现该问题已经解决，应该将bug置为状态（）
A: 新建
B: 已解决
C: 关闭
D: 已延期
A: 新建
B: 已解决
C: 关闭
D: 已延期
举一反三
- 测试基础架构开发修改完bug，测试回归，回归后发现缺陷仍然存在，测试人员应该设置状态（） A: 新建 B: 已解决 C: 重新打开 D: 已延期
- 在软件缺陷的生命周期过程中，当软件的某一个版本经过测试人员回归测试完成后，确实发现该缺陷已经解决，那么该缺陷可以设置为状态（） A: 新建 B: 已解决 C: 关闭 D: 已延期
- 下面是对某公司缺陷管理流程的概括：测试人员提交新的BUG入库，缺陷状态置为1，高级测试人员验证缺陷，如果确认是BUG，分配给相应的开发人员，设状态为2，如果不是BUG，则拒绝，设置状态为“拒绝”状态，开发人员查询状态为3的BUG，做如下处理，如果不是BUG，则置状态为“拒绝”状态，如果是BUG则修复并置状态为４，如果不能解决的BUG，要留下文字说明并保持BUG为“拒绝”状态，测试人员查询状态为５的BUG，验证BUG是否解决，做如下处理：如果BUG解决了置缺陷状态为６，如果BUG没有解决则置状态为７。上述流程中１到７相对应的状态标识为： A: 新提交－打开－打开－修正－修正－关闭－重新打开 B: 打开－修正－关闭－修正－修正－关闭－打开 C: 新提交－打开－打开－关闭－修正－关闭－重新打开 D: 新提交－打开－打开－修正－关闭－修正－重新打
- 问题还没有解决，测试人员新报告的缺陷或者验证后仍然存在，这个缺陷所处的状态是（） A: 非激活状态 B: 已修正状态 C: 关闭状态 D: 激活状态
- 问题还没有解决。测试人员新报告的缺陷，或验证后缺陷仍然存在，这些缺陷所处的状态是 A: 激活状态 B: 非激活状态 C: 已修正状态 D: 关闭状态