Defect分析报告
作者：互联网
一般常用的缺陷预防有几个阶段，需求阶段，设计阶段，编码阶段
第一，在需求阶段，最重要的事情是需求验证。一般验证的几个大项是，功能是否完整，是否考虑性能，有没有模糊需求，有没有考虑安全性，有没有冗余和错误的需求，需求是不是过于苛刻，需求是不是矛盾等方面。一般常用的方法是列出需求检查表，并进一步执行需求/测试矩阵。
需求分析对照表，查需求的完整性和质量：
需求内容
系统的所有输入都定义了吗？包括它们的来源、精度、取值范围和频率？
系统所有的输出都定义了吗？包括它们的目标、精度、取值范围、频率和格式？
所有的报告格式都定义了吗？
所有的硬件与软件接口都定义了吗？
所有的通信交界面都定义了吗？包括握手、错误检查以及通信约定？
是否从用户的观点出发，定义了所有必要操作的反应时间？
是否定义了时间问题，如处理时间、数据传输率以及系统吞吐能力？
是否对用户所要求完成的任务部作出了规定？
每项任务所需用到和产生的数据都规定了吗？
规定保密级别了吗？
规定可靠性了吗？包括软件出错的后果、在出错时要保护的至关重要的信息、以及错误测试和恢复策略。
规定所需最大内存了吗？
所需最大存储容量规定了吗？
对系统的维护性是否作出了规定？包括系统对运行环境、精度、性能以其与其它软件的接口等方面变化的适应能力规定了吗？
是否规定了相互冲突的设计之间的折衷原则，例如，在坚固性与准确性之间如何进行折衷？
是否制定了系统成败的标准？
关于需求的完善性
在开发开始前暂时得不到的信息是什么？是否规定了不够完善的区域？
需求定义是否已经完善到了可以成为软件标准的地步？
需求中是否有哪一部分令你感到不安？有没有根本不可能实现，而仅仅为了取悦老板和用户才加进来的内容？
关于需求的质量
需求是否是用用户的语言制定的？用户也这样认为吗？
需求中是否每一条之间都尽量避免冲突？
需求中是否注意了避免规定设计工作？
需求在详细程度方面是否保持了一致性；有没有应该更详细些的要求？有没有应该更简略些的？
需求是否明确得可以分为一些独立的可执行部分，而每一部分又都很明了？
是否每一条都与问题和答案相关？是否每一条都可以追溯到产生它的环境中？
是否每一条需求都可以作为测试依据？是否可以针对每一条进行独立测试以确定是否满足需求？
是否对可能的改动作出了规定？包括每一改动的可能性？
需求跟踪矩阵RTM
第二，设计阶段，这个阶段主要通过技术评审测试逻辑设计。常用比较规范的作法是建立过程/数据矩阵，也就是CRUD矩阵，把过程影射到实体，把整个程序的数据的生命周期（建立，更新，读取，删除）反映出来。
CRUD矩阵以及ER的交叉验证
第三，编码阶段，这个阶段预防措施主要有统一编码规范，代码评审，单元测试。统一代码规范一般是开发经理统一要求，代码评审则是互相评审或者开发 leader进行评审，最后最重要的则是单元测试，就是一般说的白盒测试。
测试
一般来说，需要看源码的是白盒，不用看源码为黑盒，实际开发一般专门测试人员都是黑盒，开发人员负责单元测试等白盒测试，一般项目都是需要进行单元测试，压力测试，弱网测试，接口测试，当然可以自己开发自动化测试工具，有针对性进行测试
缺陷分析，现介绍一点常用的分析方法。
1、模块的缺陷分布。一般用柱状图或饼状图。就是每一个功能模块发现bug的比例，发现bug最多的模块证明在发布以后需要更多的维护。
另外，历史数据可以参照，譬如上一个版本在哪个模块发现的bug比例对这个版本就是一个参考。如果，某个模块发现bug的比例比上个版本大幅下降，则很可能说明该模块还需要更多测试。
2、缺陷的起因分布。一般用柱状图或饼状图。一般可分为架构缺陷、功能缺陷、易用性缺陷、性能缺陷、安全性缺陷、界面文字缺陷。一般如果架构缺陷占的比例较大，则说明设计有很大问题。
3、按照不同发现人员的缺陷分布，一般用柱状图或饼状图，一般分为测试人员发现，开发人员发现，beta测试发现，外部客户发现。如果测试人员发现的 bug低于某个比例，证明质量保证测试不足。
4、按照不同方式的缺陷分布，一般有需求审查，设计测试，代码走查，JAD，手工测试，自动化测试，白盒测试。一般来说，如果通过需求审查，设计测试，代码走查，JAD（Joint Application Development联合应用开发）发现的bug 比重很低则说明测试前期重视不够，另外，在手工测试和自动化测试之间的比例也能说明自动化测试的贡献度。
5、缺陷差额分析.就是已经发现的和已经解决的曲线关系，以时间为横轴，两者越接近说明产品质量越高
6、时间段的缺陷分布。一般用时间为横轴的曲线图表示。主要说明在哪个阶段发现的bug最多，对测试总结有指导意义
7、Rayleigh分析，即俗称的零缺陷追踪法。一般截至某个时间点发现的缺陷总数和时间有一个函数关系（一个复杂的数学函数），一般用这个函数来推测经过多少天测试之后软件中大概还有多少个bug，以及交付到用户手中之后大概还能出现多少个bug
附件：
1: 软件需求规格说明书评审检查单模板
2: 软件常用术语
MRD Market requirement document （市场需求文档）
PRD Product requirement document （产品需求文档）
SOW Statement of work 工作任务说明书
PHB Process Handbook (项目过程手册)
EST Estimation Sheet (估计记录)
PPL Project Plan (项目计划)
CMP Software Management Plan （配置管理计划）
QAP Software Quality Assurance Plan （软件质量保证计划）
RMP Software Risk Management Plan （软件风险管理计划）
TST Test Strategy （测试策略）
WBS Work Breakdown Structure （工作分解结构）
BRS Business Requirement Specification （业务需求说明书）
SRS Software Requirement Specification （软件需求说明书）
STP System Testing plan （系统测试计划）
STC System Testing Cases （系统测试用例）
HLD High Level Design (概要设计说明书)
ITP Integration Testing plan (集成测试计划)
ITC Integration Testing Cases （集成测试用例）
LLD Low Level Design （详细设计说明书）
UTP Unit Testing Plan （单元测试计划）
UTC Unit Testing Cases （单元测试用例）
UTR Unit Testing Report （单元测试报告）
ITR Integration Testing Report （集成测试报告）
STR System Testing Report （系统测试报告）
RTM Requirements Traceability Matrix （需求跟踪矩阵）
CSA Configuration Status Accounting （配置状态发布）
CRF Change Request Form （变更申请表）
WSR Weekly Status Report （项目周报）
QSR Quality Weekly Status Report （质量工作周报）
QAR Quality Audit Report （质量检查报告）
QCL Quality Check List (质量检查表)
PAR Phase Assessment Report （阶段评估报告）
CLR Closure Report （项目总结报告）
RFF Review Finding Form （评审发现表）
MOM Minutes of Meeting （会议纪要）
MTX Metrics Sheet （度量表）
CCF Consistance Check Form （一致性检查表）
BAF Baseline Audit Form （基线审计表）
PTF Program Trace Form （问题跟踪表）
3: 参考链接
如何理解IPD+CMMI+Scrum一体化研发管理解决方案之CMMI篇
标签：分析,需求,报告,是否,Testing,Defect,测试,缺陷,bug 来源： https://www.cnblogs.com/fourous/p/14725887.html