识别和描述缺陷

        识别和描述缺陷

1、软件缺陷的定义

满足以下5个条件之一(所有软件问题都称为缺陷)

     软件未达到产品说明书中已标明的功能。

     软件出现了产品说明书中指明不会出现的错误。

     软件功能超出了产品说明书指明的范围。

     软件未达到产品说明书中虽未指出但应达到的目标。

     软件测试员认为软件难以理解,不易使用,运行速度缓慢,或者最终用户认为该软件使用效果不好。

2、产生缺陷的原因

         人员(用户、设计、开发、测是、技术支持等)之间的沟通交流不够,交流上有误解或者根本不进行交流。

     文档不完善甚至没有文档(尤其是国内中小软件企业)。

     需求不断的变化。

     参与人员的过度自信。

     程序设计本身有错误。

     软件复杂度大,缺陷很难避免。

     工期短,任务重,时间压力大。

     软件开发工具与系统硬件的支持。

3、判断缺陷

     软件技术人员发现了问题,判断这个问题是否有缺陷的依据是什么?

     通过参考文档来确认缺陷(需求规格说明书、概要设计、详细设计、用户手册……)。

     通过了解软件行业标准、行业背景或参考同类典型软件来发现缺陷。

     通过沟通来确认和识别缺陷。

     问开发人员、问需求人员、问用户……

4、再现与优化缺陷

  再现与优化缺陷的方法:

     不要想当然的接受任何假设。

     查找依赖关系和竞争条件的问题。

     与压力和符合相关的边界条件软件缺陷、内存泄漏和数据溢出的发生有一定的前提条件(清空缓存)。

     状态缺陷仅在特定软件状态中显露(顺序)。

     考虑资源依赖性,内存、网络、硬件共享的相互作用。

     关注硬件的失效问题,硬件可能不按照预定方式工作(硬件坏道)。

     关注软件的失效问题,对缺陷的修改可能回引发新的缺陷。

     从阅读缺陷报告入手,提高编写缺陷报告的能力(借鉴别人)。

5、怎样有效记录缺陷

     判断一个缺陷报告撰写好坏的简单方法:

    让非缺陷报告撰写者(技术人员)依据缺陷报告重现缺陷,如果能简单、迅速的重现缺陷,表明缺陷报告较好。

         分析故障——使用最少步骤重现缺陷

         减少开发人员重现缺陷的时间。

         使开发人员更准确的定位缺陷。

         包含所有重现缺陷的必要步骤。

   测试人员假定常用的操作步骤开发人员不一定熟悉,省略了必要的步骤常常造成开发人员无法重现缺陷。

7、缺陷内容

     错误现象:

使用“记事本”仅保留“联通”二字后再打开该文件,出现乱码。

     操作步骤:

  1、 点击“开始”->“程序”->“附件”->“记事本”打开记事本软件;

  2、 仅输入“联通”二字后,点击“文件”->“保存”;

  3、 再打开的“另存为”对话框中保存文件后推出;

  4、 打开保存的文件,出现乱码,不是“联通”二字。

预期结果:

  使用“记事本”仅保留“联通”二字后再打开该文件,内容与输入的内容保持一致。

8、记录缺陷

  一个缺陷一个报告,为什么呢?

  举例(一个缺陷报告中两个缺陷)

  概述:使用“记事本”仅保留“联通”二字后再打开该文件,出现乱码,而且“另存为”对话框中默认文件后缀写成了“.txk”

  描述步骤:

    1、 点击“开始”->“程序”->“附件”->“记事本”打开记事本软件;

    2、 仅输入“联通”二字后,点击“文件”->“保存”;

    3、 在打开的“另存为”对话框中保留文件后推出,默认文件后缀应该是“.txt”,实际写成了“.txk”;

    4、 打开保存的文件,出现乱码,不是“联通”二字。

  这样有什么不良后果?

      步骤3出现的缺陷对于开发人员而言容易修复,而步骤4出现的缺陷很难修复,那么如果开发人员修复了步骤3出现的缺陷而没有修复步骤4出现的缺陷,这个缺陷报告是解决了还是没解决?

9、值得注意的经验

   记录bug最好能配有截图,这样有利于开发理解。

  如果有能力,尽量附上可能原因,以供开发参考。

猜你喜欢

转载自www.cnblogs.com/1021kim/p/11499252.html