如何在软件质量管理活动中更好地使用检查单？

　　关键字：检查单 形式 内容 分类 发现效率

　　摘要：本文总结了在软件质量管理活动中，设计与使用检查单的6个基本要点，为更好地利用检查单从事质量管理活动提供了一个实用性指南。

　　检查单（Checklists）是软件质量管理活动中最常用的工具之一，通过检查单的作用是提醒检查人员检查哪些内容，避免遗漏。在设计、使用检查单时，要注意如下的问题：

（1）2种类型的检查单要分开设计

　　检查单可以分为针对形式的检查单与对针对内容的检查单

　　针对形式的检查单是一种有法可依的检查单，他们需要依据公司的过程、规程、模板、指南等而定义，是由QA人员来使用，主要是用来检查活动、工作产品与规范的符合性问题。这类的检查单又可以区分为针对软件活动的检查单和针对软件文档的检查单。

　　针对内容的检查单是一种依靠专业经验进行判断的检查单，他们是根据历史的经验积累，针对工作产品内容的内在质量进行检查的问题列表，这些问题需要依靠检查单使用者的经验来判断得出结论，检查单是起到一种提醒及经验教训总结的作用。这类检查单一般是针对具体的某个工作产品的，如需求评审的检查单、设计评审的检查单等。

　　如果将2种类型的检查单混杂一起，要么是使用者无法得出正确的结果，要么浪费使用者的时间。比如在对代码的PPQA检查单中，有如下的检查项：

　　动态内存的申请与释放是否是匹配的？

　　该检查项实际上是在进行代码评审或者是在白盒测试时由同行专家进行判断的，从原则上来讲不是由QA人员来进行判断的。

　　再如在对需求文档的检查单，有如下的检查项：

　　用户需求是自完备的，没有遗漏的内容。

　　该检查项可以列在需求评审中给专家使用的检查单中，而不是列在给QA人员使用的检查单中。

（2）检查项要描述准确

　　一个好的检查项应该是明确的，无二义性的，易于得出结论的。例如：

　　是否平均每15行代码就有1行注释？

　　再如在某公司针对C语言的源程序的检查单中，有如下的问题：

　　头文件和定义文件的名称是否合理？

　　对同一个源程序，当不同的QA人员按照本问题去执行审计时，得出的答案可能就是不一致的，什么是合理呢？每个人的判断准则是不同。该问题更好的设计方式应该是：

　　头文件和定义文件的名称是否符合公司的命名规范？

　　问题描述的准确性是和标准和规范制定的准确程度紧密相关的。如果标准和规范定义的不明确，检查单也往往不明确。

（3）要对检查单中的检查项进行分类。

　　如果检查单中的检查项比较多的时候，可以对这些检查项进行分类，以避免遗漏和重复。

（4）要对检查项进行度量分析，依据检查项的发现效率对检查项进行排序。

　　例如在某次评审发现了100个问题,这100个问题对应到已有检查单的哪些检查项?哪些问题不在检查单上?对于不在检查单上的要增加检查项,对于在检查单上的,要统计发现效率,根据发现效率调整检查单上检查项的优先级。这样不断滚动,才会越来越实用,才会成为组织的财富

（5）QA人员使用的检查单要努力做到“从形式到本质”。

　　QA人员是检查工作产品与过程与标准和规范的符合性的，往往开发人员抱怨QA人员没有找到对他们有实质性帮助的缺陷，这是对QA人员的更高要求，需要QA人员在检查项上下功夫。这种要求并非做不到，比如如果一个企业已经建立了关于评审过程的性能基线，需求文档在正式审查的准备阶段每个评审员发现缺陷的效率为2个BUG/页，评审效率为5页/小时，则QA人员则可以将这2个检查项列入对评审过程的检查单中：

　　评审员准备阶段发现缺陷的效率是否大于等于2个BUG/页？
　　评审员在准备阶段的评审效率是否小于等于5页/小时？
　　这2个问题就是在通过形式的检查来检查过程的内在质量，只不过内在的质量还是由评审专家去完成的。

（6）要分角色设计检查单

　　在一次评审行为中，往往有多种角色的专家参与，如：设计人员、需求专家、测试人员等。对于不同类型的专家要设计不同的检查单，这样便于提高发现问题的效率。

　　上面的6条是最基本的应用技巧，在使用中还要注意不能完全依赖于检查单，也要根据使用者的经验来发现问题。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有