软件测试|腾讯老鸟谈软件测试的完整流程( 三 )


这种高频率的迭代测试 , 可以极大地提升产品成型的速度 , bug能在最短时间内被处理 。
这种测试非常考验测试人员的抗压、责任心、领导力和沟通协调能力 。
但是敏捷测试也有很多的缺点 , 在这里我只谈自己的感受 , 如果有不对的地方可以留言和我讨论:
测试人员工作压力大 , 休息时间少 , 几乎没有喘息的时间 。
不同版本的bug管理比较混乱 , 验证起来需要梳理清楚 , 最好是借助专业的管理工具 。
bug反复性高 , 可能在短时间内甚至不会出现bug逐步下降的正常趋势 , 而是产生较大的波动 。
开发无法按照bug等级来确定工作优先级 , 因为可能在改一个中等bug , 突然来了严重bug , 也得等上一个bug改完的 。
需求改动频繁 , 可能昨天的功能或者做一半的功能突然就舍弃掉了 。 所以我们正常的测试中一般不会去做敏捷测试 , 但是有些公司比较推崇 。
四、集成测试(integration testing)、系统测试(system testing)
集成测试的重点就是测试各模块的接口 , 也就是组件或系统之间的交互 。
集成测试侧重于集成测试的目标包括:
1.减少风险
2.验证接口的功能和非功能行为是否符合设计和规定
3.建立对接口质量的信心
4.发现缺陷( 可能存在于接口本身 , 也可能存在于组件或系统内部
5.防止缺陷遗漏到更高的测试级别
与组件测试一样 , 在某些情况下 , 自动化集成的回归测试可以增强信心 , 因为即使产品有变更
也不会破坏已有的接口、组件或系统。
系统测试侧重于整个系统或产品的行为和能力 , 通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为 。
系统测试的目标包括:
1.减少风险 。
2.验证系统的功能和非功能行为是否按照设计和指定的要求进行验证系统的功能和非功能行为是否按照设计和指定的要求进行 。
3.确认已完成系统成且系统按预期工作确认已完成系统成且系统按预期工作 。
4.建立对整个系统质量的信心建立对整个系统质量的信心 。
5.发现缺陷发现缺陷 。
6.防止缺陷遗漏到更高的测试级别或生产防止缺陷遗漏到更高的测试级别或生产 。 一般情况下 , 系统测试的测试环境应该与集成测试的相同 。
我为什么把集成测试和系统测试放在一起 , 因为我们在做测试的时候 , 经常是集成测试和系统测试同时进行 。
集成测试意味着开发已经完成所有模块的开发 , 并且对产品有了一定的信心 。
所以我们通常是直接进行集成和系统测试 , 也就是全用例、全流程、全功能、全接口的测试 。 测试环境由测试人员进行搭建 , 尽量与生产环境一致 。
测试期间测试环境不允许开发人员访问 , 直到一轮测试结束 。
一轮结束后会将测试环境包括数据库移交给开发 , 用来复现相关问题 , 并查找问题原因 。 开发提交新一轮测试后 , 测试人员重新搭建环境进行测试 。
五、验收测试(acceptance testing)
验收测试通常侧重于整个系统或产品的行为和功能 。
验收测试通常是由客户、业务用户、产品负责人 或系统操作员负责 , 也可能涉及其他利益相关方。
验收测试的目标包括:
1.建立对整个系统质量的信心
2.确认系统 是否完整 且系统将按预期工作
3.验证系统的功能和非功能行为 符合规范
六、其他(确认测试、回归测试)
确认测试:修复缺陷后 ,应该在软件的最新版本上 , 重新执行之前因该缺陷而导致失败的测试用例。 为了覆盖修复缺陷所 需 的变化 ,也可以使用新的测试来测试软件 。 至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤 。

相关经验推荐