软件报告技术文档

一、什么是报告？

报告是指把的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。

二、执行和结束的准则

1. 执行的结束原因

1）达到预期目的后，按计划结束

2）受时间进度、资源的限制，被迫结束

2. 执行结束准则

1）在计划中明确说明结束的条件

2）Good-Enough原则

3) 结束条件的判定是在质量和成本之间的折衷

4) *的时间段内没有发现新的缺陷

5) 基于成本的考虑（不适用武器、医疗设备）

3. 执行结束条件

1）达到了覆盖率的要求

2）单元：语句覆盖、...

3）集成：API、参数组合...

4）系统：功能、用例、用例场景...

（例如：**语句覆盖 90%用例场景覆盖）

5）项目组达成一致

6）因时间进度、资源的限制必须结束

7）根据经验总结的就是当找到并将解决的缺陷占总缺陷的比例达到85%时，可终止。

三、报告目标及关注点

1. 目标

1）表示出目前项目的实际状况

2）明确什么是做的工作，什么是不作的工作。

3）给出系统的操作性能的评价

4）明确什么时候系统可以进行产品化的工作

2. 关注点

1) 报告只有真正需要的时候才有用，需要配合市场和管理

2) 的信息是不充分的（对于评价一个项目来说）

3) 状况并不能真实的反应个人的状况

四、报告组成要素

1）本次的总体策略

2）本次的准备与设计（分解）

3）的具体内容和执行情况

4）覆盖分析

5）缺陷的统计与分析

6）结论与建议

7）支撑材料

五、报告模板

1. 总结报告：

1）总结（如了什么、结论如何等等）

2）计划、用例的变化；

3）全面评估版本信息；

4）结果总结（度量、计数）；

5）项通过/未通过准则的评估；

6）活动的总结（资源的使用、效率等）；

7) 审批

2. 报告目前的软件状态

1) 功能/矩阵

2) 功能的状态报告，侧重点分析

3) 关于功能的工作时间轴

4) 期望发现 VS 实际发现的缺陷比

5) 没有发现的缺陷和改正的缺陷的差距

6) 按照类型分类，没有改正的缺陷的平均值

7) 缺陷分类报告

8) 活动报告

3. 数据收集

1）有关结果的积累数据

2）任务，和事件的描述

3) 缺陷分析

4) 由于计划的问题，导致没有发现的缺陷的数据

5) 严重的缺陷

6) 缺陷类型

7) 为什么缺陷没有发现

8) 效果

六、系统覆盖程度

1. 覆盖是对完全程度的评测。覆盖是由需求和用例的覆盖或已执行代码的覆盖表示的。

覆盖率等于覆盖面积/总面积

2.对软件需求的估算分为两部分：

2.1基于需求的覆盖估算

基于需求的覆盖在生命周期中要评测多次，并在生命周期的里程碑处提供覆盖的标识（如已计划的、已实施的、已执行的和成功的覆盖）。在执行活动中，使用两个覆盖评测，一个确定通过执行获得的覆盖，另一个确定成功的覆盖（即执行时未出现失败的，如没有出现缺陷或意外结果的）。

2.2基于代码的覆盖估算

基于代码的覆盖评测过程中已经执行的代码的多少，与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流（语句、分支或路径）或数据流的基础上。

七、报告重点

那么总结中较重要的是什么呢？

较主要的就是结果及缺陷分析。这部分主要是用图表来展现，比如所有bug的状态图、bug的严重程度状态。这里主要有一些术语要和大家交待一下。

1）项目名称

2）实测结果与预期结果的比较

3）发现的问题

4）缺陷发现率=缺陷总数/执行用例数

5）用例密度=缺陷总数/用例总数x**

6）缺陷密度=缺陷总数/功能点总数

7）达到的效果