• 基础篇:如何做一名专业的软件测试工程师


    作为一个软件测试工程师,在面试过程中,如何表达自己的核心竞争力?如何体现自己的专业性?这是个值得思考的问题。

    1、缺陷的生命周期

    总结:是否可以准确清晰的描述缺陷的生命周期,以及每个流转过程中你应该做什么?怎么做?(敲黑板,思考!!!)

    2、对缺陷错误状态的定义

    • 新建(New):测试中新报告的软件缺陷;

    • 打开 (Open):被确认并分配给相关开发人员处理;

    • 修正(Fixed):开发人员已完成修正,等待测试人员验证;

    • 拒绝(Declined):拒绝修改缺陷;

    • 延期(Deferred): 不在当前版本修复的错误,下一版修复;

    • 关闭(Closed):错误已被修复;

    总结:软件测试工程师的职责是主动发现暴露软件存在的缺陷,并辅助开发工程师一起确保缺陷被修复,提高交付软件质量和交付速率的岗位,每个不同的软件缺陷状态,作为一个测试工程师,你应该做什么?

    3、人员角色的不同权限

    new—tester:测试工程师

    declined-not bug--Test Supervisor:测试主管/测试工程师

    declined-duplicated--Test Supervisor:测试主管/测试工程师

    open--Project Manager/Technical Manager:测试工程师/项目经理/技术主管

    fixed—programer:开发工程师

    closed—tester:测试工程师

    deferred-next build--Test Supervisor:测试主管/测试工程师

    deferred-next main release--Test Supervisor:测试主管/测试工程师

    总结:应该明确在一个项目或者一个部门里,你的权限职责,不同同事的权限职责,以及遇到问题需要协商沟通,应该找谁,怎么解决!

    4、缺陷管理流程要点

    为了保证错误的正确性,需要有丰富测试经验的测试人员验证发现的错误是否是真正的错误,书写的测试步骤是否准确,可以重复;

    每次对错误的处理都要保留处理信息,包括处理姓名,时间,处理方法,处理意见,Bug状态;

    拒绝或延期错误不能由程序员单方面决定,应该由项目经理,测试经理和产品经理共同决定;

    错误修复后必须由报告错误的测试人员验证后,确认已经修复,才能关闭错误;

    加强测试人员与程序员的交流,对于某些不能重复的错误,可以请测试人员补充详细的测试步骤和方法,以及必要的测试用例;

    总结:上述几点,其实主要思想还是围绕第一部分--在缺陷的整个生命状态流转中,应该如何管理,什么状态需要什么对应的管理方法,灵活应用!

    5、用例设计规范

    新建测试用例时要求选择对应的产品模块、用例类型、适用阶段和相关需求,用例类型一般选择功能测试,适用阶段一般选择系统测试;

    用例标题要求描述对象功能明确,并尽量做到简洁;

    根据需要填写适当的前置条件,要求在业务流程上前置条件之后可以衔接第一步操作;

    操作步骤要表述清楚具体步骤和检查点及其所在的位置,UI元素和控件需要标识清楚;

    预期结果需要明确,原则上不应有无预期结果的操作步骤;

    总结:谈到用例设计,有最基本的“八要素”,以及设计用例的2个思路(按模块还是按业务流),对业务依赖、异常如何思考处理?如何提高覆盖率?这些都可以从设计用例的规范里面思考找到答案!

    6、缺陷提交规范

    提交缺陷时要求选择对应的产品模块、所属项目、影响版本、优先级、严重程度和相关需求;

    缺陷标题要求能够确切地描述缺陷,包括缺陷出现的位置和表现,要注意避免冗长;

    重现步骤中必须包括步骤,结果和期望,情况允许的话需要提供测试数据供开发人员迅速重现问题(日志截图,报错方法);另外,比较复杂的UI要求截图;

    总结:提交缺陷,必须记住四要素:when、how、what、why!即表达一个问题必须满足的四个条件:什么时间执行了什么操作,发生了什么问题,为什么会发生(或可以理解为怎么解决的)!

    7、缺陷优先级定义

    被很多其他功能或检查点依赖,或者造成blocking issue的缺陷定义为P1,要求开发人员最高优先解决;

    被其他功能或检查点依赖的功能或检查点所属的缺陷定义为P2,要求开发人员次优先解决;

    独立的功能或检查点所属的缺陷定义为P3,要求开发人员将P1和P2级别缺陷处理完成后再着手解决;

    较小的功能缺陷或页面样式问题定义为P4,要求开发人员将P1、P2和P3级别缺陷处理完成后再着手解决;

    一些功能和样式方面的建议也可以登记到系统并标识优先级别为P4,一般可以放到后续版本中解决;

    总结:缺陷优先级和严重程度有很大的关系,以及综合考虑对上线发布,对用户的影响!

              测试结果质量评估的最低标准:测试结果最低限度的符合需求并且可以正常运行!

    8、缺陷严重程度定义

    特别严重的问题,比如严重的样式问题,数据错误,主要流程卡死等,要求标示严重级别为S1;

    比较严重的问题,比如较严重的样式问题,主要功能缺陷等,要求标示严重级别为S2;

    一般严重度的样式或功能问题,要求标示严重级别为S3;

    轻微的样式或功能问题,要求标示严重级别为S4;

    测试人员在测试过程中发现的一些可以改进优化的地方,同样应该记录下来并提交到缺陷管理工具上,可以标示严重级别为S4,一般可以放到后续版本中跟进;

    总结:关于缺陷严重程度,学会取舍,做什么和不做什么?如果做,怎么做?如果现在不做,什么时候做?

    这些内容,其实都是软件测试人员入门必须了解的知识,但如何在工作中正确的运用所学的知识,却是一门学问,纸上得来终觉浅,绝知此事要躬行!

    知识是很碎片化,又很体系化的,要学会实践总结,将其变为自己知识体系的一部分!!!

    推荐一jmeter测试教程:http://study.163.com/course/courseMain.htm?courseId=1005220010&share=2&shareId=400000000379014

    出处:

    https://www.cnblogs.com/imyalost/p/8606173.html

    版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。

  • 相关阅读:
    UnicodeEncodeError: 'latin-1' codec can't encode character 'u7801' in position 49: Body ('码') is not valid Latin-1. Use body.encode('utf-8') if you want to send it encoded in UTF-8. 请求body里面有 汉字
    pytest-allure清空上一次运行的记录(--clean-alluredir)用例重复显示
    【DPDK】谈谈DPDK如何实现bypass内核的原理 其二 DPDK部分的实现
    【DPDK】谈谈DPDK如何实现bypass内核的原理 其一 PCI设备与UIO驱动
    【Network telemetry】谈谈网络遥感技术,从主动探测与被动探测再到Netflow与INT
    【DPDK】【ring】从DPDK的ring来看x86无锁队列的实现
    【DPDK】【Multiprocess】一个dpdk多进程场景的坑
    【DPDK】【CPU usage】DPDK应用如何计算当前系统的压力
    Kubernetes client-go Informer 源码分析
    Kubernetes Job Controller 原理和源码分析(二)
  • 原文地址:https://www.cnblogs.com/xdclass/p/9121902.html
Copyright © 2020-2023  润新知