【原】测试问题原因分析的一点思路

软件测试给我们带来的好处不仅仅是发现软件当中存在的缺陷，更重要的是，通过对测试问题的分析，找出导致问题产生的原因，并采取针对性的措施，以达到预防缺陷的目的。

下面以一个实际的例子来揭示一下分析测试问题的思路。

某项目在完成系统测试后，共发现85个错误，按程序错误、设计错误、文档错误、其他错误等分类统计，结果见下图。

其中程序错误最多，占66％；文档错误次之，占27％。按照二八原则，如果能够找到这两类错误形成的原因，消除这两类错误，软件的质量将大幅提高。

首先我们来分析下文档错误的原因。分析文档错误问题都是对需求规格说明而言的。文档错误有2种类型：需求描述错误或有歧义；需求描述与代码不一致。这两类错误的统计结果见下图。

在样本中由于“需求描述错误或有歧义”导致的文档错误占38％，由于“需求错误与代码不一致”导致的文档错误占62%。下面对造成这两种错误的可能原因进行分析。

造成“需求描述错误或有歧义”的原因可能包括：

1. 软件设计师工作疏忽：

2. 技术QA的审核效率低下：

3. 需求规格说明评审效率低下。

造成“需求错误与代码不一致”的原因可能包括：

1. 软件设计师工作疏勿忍；

2. 内部测试效率低下。

对此，建议的解决措施为：

造成错误原因	建议解决措施
软件设计师工作疏忽	通过培训，提高设计师能力
技术QA的审核效率低下	改进QA审核机制，提高QA的主动性、积极性；针对历史错误，更新QA检查单
需求规格说明评审效率低下	改进技术评审机制，提高评审人员的主动性、积极性；针对历史错误，更新评审检查单
内部测试效率低下	改进内部测试机制，提高测试人员的主动性、积极性；加强测试用例评审

原因分析有个5个“为什么”的分析方法，可以逐层深入剖析出导致问题产生的根本原因。因此，可以对上面的造成错误原因问“为什么”做进一步的原因分析。例如：

造成“需求规格说明评审效率低下”的原因可能包括：

1. 评审人员能力不够：

2. 评审人员不想做评审又不得不参加评审，出工不出力；

3. 评审的准备工作不够时间仓促；

4. 评审检查单不合用；

5. 评审过程随意，经常跑题。

针对这些深入的原因，再给出相应的解决措施：

造成错误原因	建议解决措施
评审人员能力不够	技术培训
评审人员不想做评审又不得不参加评审，出工不出力	改进技术评审机制，提高评审人员的主动性、积极性
评审的准备工作不够，时间仓促	规范评审过程；培训评审组织者
评审检查单不合用	针对历史错误，更新评审检查单
评审过程随意，经常跑题	培训主持人

以此类推。

其次对程序错误原因进行分析。从技术角度，对程序错误的类别划分如下：

• 计算错误；

• 操作错误；

• 逻辑错误；

• 需求不正确；

• 数据处理错误

• 设计错误：

• 接口错误；

• 记录错误；

• 数据库错误。

通过对程序错误的52个问题的调查统计，按错误类别的统计结果如下：

由图中可以看出，程序错误问题主要集成在设计错误（占67％）中，其次是需求不正确错误（占13％）。根据二八原则，我们将集中解决这两类错误。

对于“设计错误”，建议的解决措施：

• 技术培训，提高设计人员能力：

• 引进好的设计方法；

• 提高设计评审绩效。

对于“需求不正确”错误，建议的解决措施：

• 技术培训，提高分析人员能力；

• 引入好的需求分析方法；

• 提高设计评审绩效。

下面是对导致问题产生原因的分析，统计结果如下；

由图中可以看出，导致程序错误问题产生原因主要集中在考虑不周全（占62%）中，其次是需求理解不正确（占23%）。考虑不周全，就是设计能力不足的体现；需求理解不正确，则是需求分析的能力和质量控制出了问题。建议的解决措施参考前面。

分析问题就是这样分类分析，逐步抽丝剥茧，直至找到问题的根本原因，能够给出可行的解决方案为止。

另外，对于问题类别的设置也是个技术活，设置合理的类别才有助于分析过程的顺利进行。

对于问题分析，可能不是个人能够完成的事情，往往需要各个相关方都参与分析过程，从不同的角度给出问题的原因，这样才不会有遗漏。

微信号：IdeaofSE