软件测试_基础篇
1.软件测试的生命周期
需求分析->测试计划->测试设计、测试开发->测试执行->测试评估
2.软件测试&软件开发生命周期
(1)需求阶段:测试人员了解需求,对需求进行分解,得出测试需求
(2)计划阶段:根据需求编写测试计划/测试方案
(3)设计阶段:测试人员搭建测试用例框架,依据需求和设计编写一部分测试用例
(4)编码阶段:对已经编码的模块,白盒测试人员可以计划执行单元测试,完善、细化测试用例以及调整测试计划和方案
(5)测试阶段:依据测试用例和计划执行测试,在执行的过程中记录、管理缺陷,测试完成后编写测试报告
(6)运行维护:测试人员可以参与用户使用软件的培训,在试运行项目时收集问题并及时反馈给相关负责人
3.如何合格的描述一个bug
(1)发现问题的版本
(2)问题出现的环境
(3)错误出现的步骤(最短步骤)
(4)预期行为的描述
(5)错误行为的描述
(6)其他:故障分类、优先级分类
(7)不要把多个bug放在一起:在无法确认是同一段代码造成的故障时,不要将bug一起提交
4.如何定义bug的级别
- Blockers(崩溃):阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能 丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等(该问题 在测试中较少出现,一旦出现应立即中止当前版本测试)
- Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测 试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳 定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序接口错误,数值计算统计错误等 (该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试)
- Major(一般):功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询时间长、格 式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最多)
- Minor(次要): 界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范, 页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置不正确,用户体验感受 不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测试后期出现较少,应及时处理)
5.bug的生命周期
(1) New:新发现的Bug,未经评审决定是否指派给开发人员进行修改
(2) Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员
(3) Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证
(4) Rejected:如果认为不是Bug,则拒绝修改
(5) Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改
(6) Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug
(7) Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改
无效的bug:
- open->closed
- open-rejected-closed
bug的跟踪以及状态变更后应遵循的基本原则:
- 测试人员对每一个缺陷的修改必须重新取一个包含更改后的代码的新版本进行回归测试,确保相同的问题不再出现,才能关闭缺陷
- 对于拒绝修改和延迟修改的Bug,需要经过包含测试人员代表和开发人员代表、用户方面的代表(或代表用户 角度的人)的评审
6.如何开始第一次测试
(1)阅读所有项目有关的文档,包括:需求文档、设计文档、用户手册
(2)尽可能参加各种项目会议,了解项目的背景、人员组成、尽可能的了解需求和业务。特别针对业务专业性较强 的项目,例如银行业务,需要了解各种业务知识,如高低柜、一二三类账户等、存款、贷款等。
(3)熟悉项目所使用的测试管理工具、配置管理工具,获取对应的地址和登录方式
(4)阅读已有的测试方案和测试案例
(5)阅读旧有的bug库,了解系统功能。尤其重要的是和现有的测试团队保持一致的故障定级原则
(6)了解公司的规范要求,特别是用例编写规范、用例执行规范、bug提交规范、测试工具工具使用规范等
7.测试的执行以及bug管理
测试的执行:
(1)打开待测试的系统
(2) 打开测试管理工具用例模块,开始执行用例
(3)发现bug!进行复现并确认bug的复现步骤
(4) 记录bug
(5) 沟通bug
(6) 验证以前提交的bug
(7) 确认本次测试完成
(8)编写测试报告
如何发现更多的bug:
(1)多进行逆向思维和发散性思维
(2)不要局限于用例和需求文档
(3)尽早介入项目