软件的质量控制

  相信搞软件的平时听的最多的就是你们的产品质量不好,你的代码质量差,缺陷多。那么凭什么说我的质量不行呢?往往就是通过代码缺陷率来作为参考的依据。缺陷率一般指的是1000行代码有多少个bug。那么bug怎么算呢?测试说了算呗。开玩笑的,他给你提了问题单而你认了,那就算了。问题单的严重程度不一样,分提示、一般、严重和致命,然后有个加权算法,比如提示按0.1算,一般按1算,最后得到一个缺陷值。

  那么再问一句,凭什么测试说是问题你就得认?那肯定得有你认同或者抵赖不了的东西是吧,这个往往就是设计方案、需求文档了。这两个东西相当于开发和测试都承认的合同了,两边都按这个合同来核对,对不上那只能自认倒霉。那要是合同本身有问题呢?找写合同的人呗,给他提单。测试可以给架构师提单,但给客户提单的是产品经理或者项目经理,由他们去跟客户沟通并发起需求变更。

  不扯了,软件质量的控制点我个人觉得就两个:一个是评审,一个是测试。而评审先于测试,重于测试。瀑布开发模式的输出件就是各阶段的文档,而其中很重的就是评审文档。如果评审缺陷率不达标还得输出例外报告。敏捷是交付软件产品并通过迭代来推进,评审文档的输出可以由各项目自己决定。评审文档主要有需求、方案设计、代码、测试用例,方案设计对于瀑布模式来说包括概要和详细,敏捷的详细设计叫story设计。测试包括开发自测试,开发转测试后有单元测试集成测试和系统测试。checklist我认为也可以归结到测试范畴里去。前期评审充分可以减少返工。测试覆盖率高可以减少漏测。而这两个问题都是比较严重的,往往会把问题带到生产环境。

  质量保证是监控过程中的质量动作,确保相应的动作做规范、做标准。比如敏捷提倡的测试驱动开发是一种很好的保证质量的手段,但开发不愿做,那么QA可以进行监督强制开发按要求做,确保该动作的实施。迭代回顾会议也是保证质量的做法,它会分析之前做的不规范的地方,总结经验,以史为鉴。

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页