识别和描述缺陷
作者：互联网
识别和描述缺陷
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最好能配有截图，这样有利于开发理解。
如果有能力，尽量附上可能原因，以供开发参考。
标签：文件,识别,开发人员,二字,软件,缺陷,记事本,描述 来源： https://www.cnblogs.com/1021kim/p/11499252.html