漫谈质量保证者.pptVIP

漫谈质量保证者 2013-08-19 引子 互联网软件质量保证是不是必须的？ 引子 互联网软件质量保证者是不是必须的？ 互联网软件专门质量保证者是不是必须的？ * 质量控制中的各角色 * 开发过程中质量保证阶段 * 抱怨 哎，又变更需求 哪里能看到预期变化呀？！！ 连个预期都说不明白，怎么测 谁写的代码，真是惨不忍睹呀 * 三种武器 * 三种武器 * 三种武器 * 软件质量 软件质量 可移植性 （Portability） 可靠性 (Reliability) 高效性 （Efficiency） 可维护性 （Maintainability） 功能性 （Functionality） 可用性 （Usability） 谁是最适合的质量保证者? * 回顾 Thanks！ 提问方式， 明确答案是：必须的。当然可以是各种方式执行（如：用户验收） 提问方式， 明确答案是：不是必须的， 一些面对用户是小众，复杂度不高的系统，没有专门的质量保证者。 为什么 互联网软件可以没有单独的质量保证者？ 哪些工作是多角色都需要承担的？ 需求分析 -----pm 研发 ，qa （50%以上的bug 是需求阶段引入的） 测试---------研发，qa ，产品 可以看到测试这个工作，是多个角色都能承担的。 各角色的侧重又会是什么呢？ * * （回答为什么专门的质量保证者不是必须的） 当系统足够复杂，多人配合时，就是必须的。 谁更关注哪一部分： 单元-----dev 集成，确认，系统----qa 验收-----产品 实际情况是如何的呢？ * * 研发最多的抱怨是 需求变更。 每次变更都会影响现有设计和开发进度。------模式设计 易变和不易变分离。 最多的抱怨qa， qa 事儿事儿的，自己搞不定呀？ （能不能搞定，能，效率问题） 1、从需求到交付测试，是一个从素描骨架到油画人物，不断丰富的过程，交付验证的复杂度提高，----难度考虑 2、不考虑可测性的代码设计（会让测试走上一个没有回头路的小巷）--------长久的可维护性。 3、Qa阶段发现问题的滞后性会导致修复困难，会加剧这个过程。 So 在现有的软件质量控制过程中，软件质量不在是一个可用就行的单点概念，是一个有交互的平面概念。 一些聪明的工程师们，逐渐想到了一些好的经验优化他 ============================= 面对这样一些问题，怎么办？ 正如建筑一个房屋一样，我们首先要保证建筑师建筑的房屋是有质量保证的。 So我们来看看这个协作过程中的一些好的做法。 * * 重剑无锋，大巧不工------------代码规范。 方便部署的profile形式。 Spring mvc @ResponseBody public ModelAndView 代码规范上我们使用的sonar平台，动态，静态检查工具。 代码规范：准，经历过不准的过程，碰到的问题是什么，得到大家的任何和支持，运作起来。 在**，我可以查看任何的代码，进入所有**的代码库，我有权查看它们。事实上，这种权限是很少人能拥有的。但是，让我感到惊讶的却是，如此多的编码规范—缩进，命名，文件结构，注释风格—这一切让我出乎意料的轻松的阅读任意一段代码，并轻易的看懂它们。这让我震惊—因为我以为这些规范是微不足道的东西。它们不可能有这么大的作用—但它们却起到了这么大的作用。当你发现只通过看程序的基本语法结构就能读懂一段代码，这种时间上的节省不能不让人震撼！ * * 一剑多用，瑞士军刀。 剑尖两叉既可攒刺，亦可勾锁敌人兵刃，倒拖斜戳，皆可伤敌 单元测试，不要太过度使用，太依赖使用。 谈到单元测试，大家都会觉得是个一个重量级的工具，总是想着之前有人说，这块的投入需要：1:1 单元测试应该是一个轻量级的自测方式，对你最无法信任和把握的点进行测试。 我有一套自己的测试方式，在模块维度测试。 单元测试，模块测试：1、搭建环境的复杂程度，2、可复用性。3、不断验收自己的作品。 最后：4、文档的作用。 不好的方法： 有要求的时候，总是喜欢对一些简单函数来做测试， 这真是一个意识问题，很难从根上解决这个问题。 不错的做法： 1、监督补充法， ------------有不错的监督人员，架构重构类项目，在重构的概要设计阶段支出需要做单元测试的点。 2、后验监督补充法------qa，对于后续修改频繁，又较难在功能级别验证的点，做补充。【刚刚重构，且qa参与度充分的模块】