• 测试经验


    测试经验


     一、测试员的使命决定要做的一切:

    • 快速找出重要软件问题
    • 质量的评估者:对软件质量的总体评估
    • 质量的把关者:确认产品质量达到具体标准
    • 保证测试过程能够达到可分清责任的标准(执行测试用例,上传截图获保留订单号、流水号)
    • 成本的降低者:最小化成本、时间或尽可能减少副作用的方式完成自己的工作,快速找到软件的重大问题
    • 成本预算:帮助预测和控制产品成本
    • 满足客户的特定要求,帮助客户改进产品的质量和可测性
    • 遵循特定的方法集和规则集,帮助客户改进过程

      测试过程明确自己的使命,保证自己的测试计划;如遇到某种原因不能完成自己的使命,应及时反馈。

    二、测试内容的先后顺序

           测试员的使命之一是快速找出程序存在的重要问题。这往往决定于测试人员执行测试内容的先后顺序。

    • 首先测试经过变更的部分(修改和更新),然后测试没有变更的部分。
    • 首先测试核心功能(关键功能、常用功能、基本功能),然后测试辅助功能。
    • 首先测试功能是否能用,然后测试功能在各种条件下的表现。即先功能,后性能,再样式交互。
    • 首先测试常见情况和场景,然后测试罕见情况和场景。
    • 首先测试常见威胁(最可能出现压力和错误的情况),然后测试罕见威胁。
    • 首先测试影响大的问题,然后测试影响小的问题。
    • 首先测试明确要求的部分,然后测试没有明确要求的部分。明确要求的部分可以从规格和设计报告里面获取,没有明确要求的部分职能靠测试人员的经验以及对业务的熟悉,借鉴以往其他产品的功能来把握。

      测试人员只有对软件和相关的业务熟悉后,才能更好更迅速的找到重要的问题。所以平时加强软件使用和业务的积累。

    三、测试过程尽可能多的覆盖测试范围

    1、沟通确定测试范围(紧急项目,无需求文档)

       接到项目之后,配置测试环境和数据库,根据情况判断是否先进行一笔正常场景的测试,当成熟悉需求一种方法,当自己对需求有了大致的了解之后,就与找产品经理或开发人员进行沟通。

      1)沟通内容主要围绕以下几点:

        a.此项目修改点是什么?主要做了哪些功能?

        b.代码是如何实现的?

        比如一个对用户敏感信息的加密解密功能,当前端将用户信息传入进来时,调用加密API,将用户的敏感信息进行加密操作,然后存表数据,当再次取表数据进行其他操作时,这时调用解密api,将用户的敏感信息进行解密操作。

        这时业务流程上的实现方式,那对应到代码中代码是如何实现的?加解密API是怎么调用的?地址是多少?如何传参的等等

        c.本次项目修改的代码覆盖的范围,确实测试范围

        d.测试过程中需要注意哪些点?

        e.异常情况会有哪些?

        对照这几个问题一个一个的问清楚,理清楚。

    2、画出测试范围

      如果上面几点在沟通中能到位,那测试人员基本对整个项目有了相对清晰的认识了。这时可以整理出测试流程,测试范围,注意点等等。如遇到不明确的地方,将不确定的地方再次明确。

    3、明确测试范围--测试需求分析

      整理好的测试范围、注意点(思维导图形式)发给开发人员和产品经理确认是否覆盖完全,检查点是否设置正确等问题。其主要目的在于消灭这种因理解不同,而导致后期测试不全,出现漏测的情况。

    4、测试用户和用例评审

      如果时间宽裕可以编写测试用例,三方评审后,测试人员针对项目开始进行测试;如果项目时间偏紧的情况,省掉这一步,直接使用上面的方式开始测试,既节省时间又减少遗漏

    四、测试总结

    1、测试数据要尽量真实

    2、多思考,多参与讨论发现了不合理的地方也要指出,不要觉得测试的工作就只是找bug,要站在更高的层面上看问题

    3、搞清楚bug产生的根源,遇到问题多问为什么;

    好处在于:
      第一,你可以准确的分清该bug是前端的还是后端的,然后直接提给对应人,避免了开发之间问题转来转去。
      第二,测试人员明白了bug的原因,测的时候才会去有意的创造环境,有针对的去测试,不至于很被动。
      第三,自己可以有理有据的,不至于被开发怼。
      第四,对于测试人员本身而言,会是一个很大的提升。会有一些测试人员觉得做测试,只需要把bug找出来提上去就可以了,的确这是测试的本职工作,但是你能知道bug产生的原因,在开发面前会更有说服力,在领导面前,也是一种能力的体现,对自己将是进阶高级测试的一个过程。建议多使用开发者工具分析。

    4、描述bug时要准确,没必要的误导信息不要写,容易误导开发人员;遇到报错的时候,bug描述里可以把请求体和response里的内容一同写进去,这样开发可以很快速的定位问题

    5、心态方面:与开发沟通要掌握技巧,不要硬碰硬,站立自己的观点的同时,语气也要平和一些;如遇到提错bug的时候(可能是产品改需求未及时通知,可能是自身原因)也不要觉得很尴尬、觉得很委屈,或者是去争无畏的自尊心

    6、测试周期如果较短的话,一些偶然性问题不容易被发现,因此测试人员要尽量为自己争取测试时间,尽量不要让开发占用测试的时间

    五、测试过程中可能会遇到的问题

    1、在数据字段较多时,前后端容易取错字段

    2、格式转换容易出现问题,前后端编码不一致,导致特殊符号、括号变成乱码;在测试之前要确认都会有那些特殊字符,建议是产品在原型上体现出来,开发和测试都可以注意到。

    3、开发本地是好的,发布后测试是有bug的,一般有几种情况:开发的代码是否提交;运维发布的时候是否有更新修改点;开发本地环境与测试环境不一致;当然除了这三个原因,还会存在诸多因素,需要具体问题具体分析。

    4、每次一轮回归测试完成,第二天来了工作量不大的情况下建议上午还是要继续测试,随机性探索性测试,很可能会找到昨天没发现的bug。需要不断循环的测试,不是说一轮测完就等着回归了。

  • 相关阅读:
    Mac 键盘快捷键
    行业分析
    大数据导航
    SQL循环语句 详解
    SQL中使用循环结构
    常用 git 基础命令
    最近众包-有意思
    薪酬体系设计
    海氏评估法
    原则类
  • 原文地址:https://www.cnblogs.com/wyunuo/p/10731824.html
Copyright © 2020-2023  润新知