产品质量_产品质量模型 - CSDN
精华内容
参与话题
  • 产品质量的不同层次

    千次阅读 2018-08-12 15:36:20
     任何一种产品,都是去提供一种/几种服务,为用户解决问题是产品最本质的要求(否则产品没有存在的必要了),也属于硬质量。但作为提供同样服务的多种产品,用户为什么选择你,就取决于产品的软质量了。  具体来...

    一、质量层次模型

        任何一种产品,都是去提供一种/几种服务,为用户解决问题是产品最本质的要求(否则产品没有存在的必要了),也属于硬质量。但作为提供同样服务的多种产品,用户为什么选择你,就取决于产品的软质量了。

        具体来说,可以从下面两个方面来理解硬质量和软质量:

     

    • 硬质量。产品必须提供的质量(功能、性能、稳定性、安全性),满足了这个条件,产品才可以提供出去,才能未用户解决某种/某类问题。你的产品才成为了用户的选择(当然了,如果有很多提供同种服务的产品,用户是否选择你的产品就不一定了)
    • 软质量。产品应该提供的质量(易用性、快捷性,这里统称用户体验),满足了这个条件,才给了用户选择使用你的产品的理由。硬质量是用户选择你的入门门槛,软质量是用户使用/不使用的理由。

        将硬质量、软质量可以归结为如下的质量模型:

     

    • 用户体验。属于软质量范畴,这里指的是广义的定义,包括:UI/UE、易用性、易交互等等
    • 功能。属于硬质量范畴,这里指产品对外提供的服务,也是产品需求的定义
    • 性能。属于硬质量范畴,这里指产品可服务用户的规模、服务的快速响应等等
    • 稳定性。属于硬质量范畴,这里指产品可稳定的对外提供服务(稳定的反面:不定时/随时挂掉)
    • 安全性。属于硬质量范畴,这里指产品对外提供服务期间,用户可以放心使用,敏感性信息不会对外泄露(反面:facebook的泄密事件)

    在硬质量范畴里面,不同人员对质量的期望不同:

    • 产品测试负责人。通过各种手段来确保上线产品质量,减少上线风险,进而控制线上故障。这里的各种手段包括:完整的测试策略、项目定制的测试/上线流程、风险控制、自动化提升效率、线上监控/运营等等。当然了, 这里的各种手段是最能评估一个测试人员水平的指标了。
    • 测试组长/经理。不负责实际的项目测试,仅仅管理人员调度和流程沟通等等。除了直接的上线质量外,另一个目标恐怕就是人员的考虑了,扩大人员规模或者把合适的人放到合适的位置上。ps:这里仅仅说一点个人的理解,实际项目中,组长其实更应该培养/帮组组内成员的快速成长,独当一面的能力,毕竟项目的实际测试质量,上线质量是脱离与组长的控制的。不过目前看这块,是很多组欠缺的地方。
    • 测试总监。通常大体工作类似测试组长/经理,只是负责了更多的产品线/平台。其对测试质量的期待无外乎以下几点:1、线上故障的减少;2、测试效率的提升,于是有了一系列工具/平台的研发;3、人力产出,最大化团队产出。
    • 团队其他成员(产品、开发等等)。测试效率的提升(测试周期减少)和线上故障减少(上线质量提升),这两个看似有些矛盾的目标,通常是整个团队对测试人员的期待了。

    二、产品不同层次质量的含义

     

    • 用户体验。这部分往往需求定义/产品定义决定了大部分的用户体验,这部分往往不容易衡量好坏的。用户体验的三个层次:
    1. UI/UE。这指的是视觉部分,最直观,最直接呈现给用户的产品“形象“
    2. 交互。这指的是用户使用产品提供服务过程中,与产品交互/互动的过程的难易程度
    3. 使用感受。这指的是从接触产品,使用产品,离开产品这一过程用户的心理层面的活动(或愉悦、或挫败、或惊喜...)
    • 功能。功能部分通常直接定义与产品需求中,是通常的需求评审的重点之一。功能的层次:
    1. 最直接的需求定义功能(不同角色对产品的需求)
    2. 异常场景下的功能(产品”“)
    • 性能。属于硬质量范畴,这里指产品可服务用户的规模、服务的快速响应等等
    • 稳定性。属于硬质量范畴,这里指产品可稳定的对外提供服务(稳定的反面:不定时/随时挂掉)
    • 安全性。属于硬质量范畴,这里指产品对外提供服务期间,用户可以放心使用,敏感性信息不会对外泄露(反面:facebook的泄密事件)

    三、产品的不同层次需求

        站在不同角度,对产品会有不同的需求:

    • boss级别,产品的商业价值&给公司/部门带来的利润
    • 产品经理,产品保质保量完成&KPI完成&带来的价值
    • 技术人员,产品完成&KPI完成
    • 运营人员,产品的维护&KPI完成
    • 市场人员,产品的推广&KPI完成
    • 用户,带来的服务价值(不仅能提供服务,而且能提供“身心愉悦”的服务)

        但不同需求最本质的出发点:用户的价值/体验详见

     

    具体用户价值/用户体验是什么,请移步博客:用户体验

     

    展开全文
  • 关于如何更好的把控产品质量,一直在软件行业的圈子里面,各种观点,在这里我结合吴老的总结,从以下几点来说明: 1、 市场调查,很多创业型的公司很少有真正做成功的,原因无外乎资金、市场、人员、方向导致,那么...

            关于如何更好的把控产品质量,一直在软件行业的圈子里面,各种观点,在这里我结合吴老的总结,从以下几点来说明:

    1、      市场调查,很多创业型的公司很少有真正做成功的,原因无外乎资金、市场、人员、方向导致,那么如果你的产品符合大多数人所需要,是实际满足市场需求,那么你拉赞助,就可以解决资金,有了资金,人员就不缺,有足够的市场,正确的方向,那么公司一定会成功,所以要对你以后的产品定位、用途、市场变动情况等,都要了如指掌方可下手,不然最终结果一定会功亏一篑,创业需谨慎,倒闭价更高。

    2、      产品需求设计的合理性一个失败的产品设计上线后会经常性的变动需求,导致整个团队频繁的修改和测试,尤其是上线前还在修改产品逻辑的场景,相当的影响研发测试团队、继而影响产品质量,上线后产品设计与用户使用场景相悖、影响用户使用习惯等等,因此产品需求设计的合理性非常非常的重要,需要PM前期做很充分的需求调研,走在一线多与用户接触,深度了解用户最常用的场景、站在用户角度思考产品逻辑、解决用户痛点问题;

    3、      技术架构设计、逻辑实现(设计)要合理,如果技术大的框架设计都存在很大的问题,即使后期再往上累加功能,都会显得摇摇欲坠,技术实现逻辑的设计合理性也相当的重要,我接触到很多公司的研发小伙伴为了赶时间只是不停的实现功能,不会过多的去考虑实现逻辑的合理性或效率、性能等,等到了线上或用户量达到某个量级时,就会爆发很严重的问题;

    4、      开发编码规范,其实有些时候代码逻辑并没有那么复杂,但是bug却很多,很大的程度上都是由于代码不规范所致。比如说:对变量的定义的不规范、忘记对边界的处理,对输入输出参数的不规范,对异常处理的不规范,对日志处理的不规范等等,导致总是出现类似空指针、数组越界、崩溃这样低级的bug而且还很难找到引起bug的原因。相反,在特别规范的开发中,bug不但可以有效减少,查找bug也变得轻而易举。规范不是对开发的制约,而是更有助于提高开发效率的;规范的代码还可以降低维护成本、极大的提高团队对代码的可读性,而且还有助于代码review;            

    5、      需求评审,正确而有效的进行需求评审,不要流于形式,应提前将评审内容发给团队所有相关的小伙伴,提前查阅,记录好问题,带着问题去评审,效率更高、效果更好;

    6、      测试流程的规范,流程是为了提高效率,跨团队协同更顺畅的目的来制定的,要根据自己公司的实际情况来制定;测试流程制定合理,可以有效的提高效率,避免pm、rd、qa来回扯皮、一起更好的把控产品质量,在GSX,我们有PC、APP测试流程,大致分为测试需求分析、case编写、case评审、接口测试、冒烟测试、test4轮测试、beta测试、monkey测试、提交testin进行兼容众测,线上环境回归测试、发布版本后安装卸载升级主流程测试;每个阶段都会有相应的成果物产出和管理,每一步的策略和侧重点都大不相同,这里不再展开细说;

    7、      开发流程的规范,根据公司目前所处阶段制定,如果是多个研发同步在开发多个功能,代码需要分支开发,测试环境无bug后,再合并主干,提交代码时进行必要的review,sql上线一定要进行必要的review,避免一条sql引起全站瘫痪的问题;

    8、      上线流程的规范,有很多公司研发的分支团队很多,对公共代码库的维护很乱,随意提交代码到主干,不小心就会引发较大的线上事故,也会给测试同学带来庞大的测试工作量,需要一轮一轮的多次测试,所以很有必要约定好一个规范的上线流程,要保证分支没问题的代码才能合并到主干,再做主干整体回归;

    9、      优化功能测试的范围界定,有时候rd优化一个功能,qa在一个端测试没有问题,但是有可能会引发其他端的问题,比如支付功能,在app上测试ok,但在pc上就可能存在问题;再比如:有时候上线a功能,但是上线后b功能出现bug,底层服务端代码变动影响导致;再比如:上线一个功能对历史版本的影响,有些功能上线后需要兼容历史老版本(避免不升级的用户出现问题),我们也要对历史版本进行有效的测试,选择历史几个版本进行回归测试,要根据项目实际情况来定,所以科学准确的、恰到好处的选定测试范围也是一门很深的学问;每一次上线一定要对高频功能、核心功能、用户最关心的功能做最充分的回归测试;

    10、      进行静态代码检查(Checkstyle、FindBugs、PMD、Jtest、php depend、PHPMD等)统计证明,在整个软件开发生命周期中,30%至70%的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的;做静态代码分析无需运行被测代码,仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性,找出代码隐藏的错误和缺陷,如参数不匹配,有歧义的嵌套语句,错误的递归,非法计算,可能出现的空指针引用、错误的变量定义等等。使用静态代码分析工具自动化执行代码检查和分析,能够极大地提高软件可靠性并节省软件开发和测试成本。

    11、       接口测试、单元测试,一般情况下后端完成接口开发,就可以提前提测给QA小伙伴,开始服务端的接口测试,这样可以让隐含的Bug提前暴露出来,让开发人员在第一时间修复Bug,让功能测试人员在测试的时候更加顺手一些,最大限度得减少底层Bug的出现数量,让产品研发的流程更加顺畅,进而很大程度上缩短产品的研发周期,提高效率;

    12、   UI走查,很多时候产品上了beta,或者上了线,才发现UI与设计不一致,所以UI的检查也显得非常的重要,更需要在关键的时间点就介入走查,最好在冒烟测试时就走查一遍,在test环境测试完毕走查一遍,确保不因后期修改bug带来的UI问题;

    13、   bug的度量与预防,定期进行bug的分布分析,线上bug的分析,找到出现该bug真正的原因,bug频发的功能、场景,以及机型等;找出来一些预防避免的措施,可以提醒其他QA、RD的小伙伴,遇到这种情况可能会出现bug等;

    14、   运维监控:运维层面也要做到非常完善的监控体系,分别从网络层、操作系统层、应用层、接口层、做到端口存活、进程存活、页面级别的监控,如果能做到行为级别的监控最好,包括后期根据业务发展进行扩容,参数调优等,都需要很小心翼翼,监控测试,通过这些方面的严格监控和操作,为产品保驾护航,并适应业务快速且稳定的发展;

    15、   必要的复盘和总结,每次项目结束都要及时的进行复盘和总结,针对项目过程中出现的问题,及时的做出调整,避免团队小伙伴下次再犯同样的问题;

    16、   沟通机制的建立,有很多时候,都是沟通不到位产生的bug,比如RD和PM的沟通不到位,实现的逻辑不是PM想要的,比如跨团队rd之间沟通不畅导致的bug(a研发团队修改了公共字段未通知到所有使用该字段的其他团队成员出现的bug),PM和QA沟通不到导致的问题(PM需求变更,直接找RD修改完后上线了,没有通知到QA出现的bug)等等等等,在实际做项目过程中,会遇到很多很多,所以我们尽量要保持畅通的沟通环境和方式,可以组织每天站会的形式,快速无边界沟通,做到信息同步,遇到问题及时沟通解决,提高效率;

    17、   团队的稳定:无论是产品设计、研发,还是测试团队,人员的稳定因素也会非常影响产品质量,较稳定的团队,产品质量就非常好,人员经常调整的团队,产品质量就无法保障,新调整过来的人员,要对现有逻辑完全熟悉也是需要时间的,一般情况下是不会给员工非常充分的时间,了解清楚所有的细节再上手工作的,所以在做的时候就很难把影响范围考虑的非常全面,问题自然就会频出;

    18、   人的培养:一切问题都是人的问题,对人的培养大致需要从这些方面,技术水平、做事方式(做事考虑的周全性)、沟通协作能力(涉及到协作的各端,友好高效沟通,及时同步信息,通报问题和进度),主动沟通意识(比如修改底层字段、考虑影响范围,主动通知用到该字段的所有人注意)、责任感(对自己负责的事情跟进到底,并及时反馈进度)、执行力(有再完美的想法和计划,如果执行不到位,一切为0)、学习力、有效的时间管理、积极乐观、乐于帮助他人、乐于分享、并且从不抱怨,可以将积极向上的一面,感染带动他人,做一个正能量的使者;通常在项目团队中,积极负责的人做的产品,质量问题就较少,因为他们对自己有较高的要求,追求极致;

     

    以上影响产品质量的分析,无论从哪一方面,无论是需求缺陷、设计缺陷、软件程序bug,还是人的沟通问题,一定要尽早发现尽早提出,因为尽早暴露修复的代价是最小的;

    愿每一次上线后都能从容和轻松,提前做足了充分的准备,享受上线后一切安好带来的愉悦;

    转载于:https://my.oschina.net/alin520/blog/868910

    展开全文
  • 谈如何提高产品质量

    千次阅读 多人点赞 2018-01-02 15:14:36
    产品开发过程:需求分析、设计、编码、单元测试、集成测试、功能测试、Beta测试和发布。本文侧重于从开发者角度谈提高产品质量

        最近,我们的产品上线了,上线之后,稳定是最重要的,但是,出现了几次bug,都是不应该犯的错误,所以,避免bug特别是重大bug出现,提高产品质量,非常迫切。为此,我花了几天时间,翻一些资料来系统地学习,此文是学习的总结。


        产品开发过程

        产品开发过程:需求分析、设计、编码、单元测试、集成测试、功能测试、Beta测试和发布。在工程师开发之前,策划或产品提过来的需求、策划的配置文件或者后期的测试,都可能影响产品质量,但是,本文侧重于从开发者角度谈提高产品质量。先分享一张来自《Code Complete》的插图。


        可以看到,随着项目规模变大,架构、设计和集成测试、系统测试需要的时间会更多,而编码和开发者测试的时间更少。因此,提高效率最为明显的方法是提高产品质量, 减少测试、调试和修改所需时间。所以,设计、测试和编码同样重要,要分配更多时间,编码完 != 工作完成。


        测试的重要

        在很多大一些的IT公司,比如微软,开发职位叫Software Development Engineer,SDE,软件开发工程师;测试职位叫Software Development Engineer in Test,SDET,软件测试开发工程师,可见测试人员本质还是开发工程师。这有别于我们在公司里常常见到的QA,我是做游戏的,我见到的QA都是打开游戏,然后点点点,从表现上测试功能是否正常,这样测试是无法全面测试的,这也难怪在很多公司里QA比开发团队地位低。我觉得,对于测试这个职位,要做好,是很难的。他要能读懂策划文档和开发文档,从源头上开始着手。如果白盒测试,要能看懂别人写的代码;如果黑盒测试,要和开发人员多沟通,画出来实现的流程图,并且分析网络协议;然后,设计完备的测试用例。如果不根据需求、设计和实现,设计完备的测试流程,而只是操作一下试试功能是否正常,很多隐藏的bug是测试不出来的。

        在传统软件行业:软件的质量和稳定最重要,代表企业:IBM、微软、思科等。根据我查到的资料,开发与测试人员比例,微软1:1,思科1:1.5,普遍在1:1 - 3:1。SDET从需求文档、设计文档开始Review,SDE编码,SDET写测试用例,跟极限编程的过程类似。极限编程的基本过程:构思 -> 编写测试代码 -> 编写代码 -> 测试,编写测试和编写代码都是增量式的,写一点测一点,在编写以后的代码中如果发现问题可以较快的追踪到问题的原因,减小回归错误的纠错难度。

        而互联网行业:快很重要,有bug在线上也方便修改发布,更提倡full stack developer,代表企业:amazon、facebook、google等。开发与测试人员比例,google 10:1, MySpace 5:1。阿里资深专家,amazon前高级经理,陈皓认为:并不是互联网公司认为测试不重要,而是他们认为正因为测试很重要,所以才不应该交给只做测试的人,开发人员要对自己开发的产品质量负责。对于一个公司,“产出性”的人应该多于“支持性”的人。当你的条件受限人手不够的时候,你必然不能干所有的事,但你要去做很多自动化的事情,不管是自动化部署还是自动化运维。然而当你的人多的时候,你必然只会简单用人来解决问题。劳动密集型与知识密集型的公司差别就在这里。

        以微软和google为代表的保证产品质量的做法,都有道理,而且都是成功的。但是,我个人更倾向于full stack developer,第一,招很多SDET对大部分公司都不现实,合格的SDET薪资不会比SDE低;第二,我认为开发人员要对自己的开发的内容负责,主动的想办法提高产品质量,而不是被动的等测试。


        产品质量目标

        评估产品质量,常用的是千行代码缺陷率,以下是查到的一些业界的千行代码缺陷率数据。典型的统计表明,在开发阶段,平均50~60个,交付后15~18个;微软内部测试的产品10-20个,正式发布产品0.5个;某外包公司,A级≤ 0.5个,B级≤1个,C级≤5个;航天飞机的软件,0个/50万行。缺陷率做到平均水平的1/10是很少见的,而如果10倍以上,产品可能永远也不会完工。

        跟性能瓶颈一样,80%的错误往往出现在20%的代码中。大部分错误都是低级错误,比如,对需求或设计的误解、书写错误、赋值语句、边界错误或循环错误。大多数错误是容易改正的。另外,warning是很多错误的根源,所以工程里要禁止warning。


        发现错误

        主要通过检查和测试。检查包括:需求检查、设计检查、代码详查,测试包括:单元测试、集成测试、系统测试等。

        有统计数据表明:单元测试的平均错误检出率是25%,集成测试35%,小规模Beta测试35%,系统测试45%。而对设计和代码进行详查的错误检出率分别是55%和60%。

        检查

        阅读代码要比测试平均每小时多发现80%多的错误,代码检查和测试所获得的收效之比为8:1。这是因为,错误越早发现,解决成本越低。

        检查方法:协同编程,详查需求、设计、代码。不仅仅是检查,要提前思考怎么做?带着思考检查。

        单元测试

        1. 基于结构的测试。测试用例要覆盖每一条控制语句,if for while and or switch case等。

        2. 数据流测试,避免重复初始化、重复销毁、定义不使用、未初始化使用等情况,检测数据流变化。

        3. 错误猜测:

            1). 边界分析,>=与>的区别,null、size是0的情况,比如测试小于MAX,三种边界情况<MAX、MAX本身、>MAX,10000个好友/道具的时候会不会导致游戏卡死?
            2). 复合边界,int add(int a, int b),a和b都小于2^31,但是,如果a和b都很大,它们的和会不会出界?

            3). 坏数据,太小/大的数据,未初始化的数据,错误类型的数据,错误长度的数据等。

            4). 向前兼容和向后兼容。比如,游戏最新版本是2.5,但是有的玩家一直不更新,还是1.0,要兼容这些玩家。

        集成测试

        在单元测试的基础上,将所有模块按照设计要求组装成为子系统或系统,进行集成测试。


        执行方案

        综合考虑我们团队的实际情况,最后我制定了“详查+单元测试+集成测试+系统测试”的方案,来提高我们的产品质量。有些方法,比如协同编程、净室开发,虽然很好,但是对于我们的团队来说,执行起来太难。ps:我对净室开发很感兴趣,正在研究,研究透以后可能会试着采用。

        详查:先自己详查,从需求开始,然后是设计和编码;然后,团队中的小伙伴互查。关于详查,有两点需要注意:1. 检查前,要先制定代码规范,让开发人员不把精力耗在代码规范的争执上。2. 详查结果不作为员工表现的考核标准,考核应该基于最终的产品。

        单元测试:重点是理清流程,针对每个流程都测试到。集成测试:把单元测试的功能组合起来测试,侧重于模块的整体性。系统测试:有点像QA的普遍工作,从功能上测试,各个需求点是否都正常。

        执行:我首先制定了代码规范,并给大家讲解,然后征求大家的意见统一。然后,写了一份本文章的内部版本,并给大家详细讲解(为了让小伙伴们更容易,内部版本细节比较丰富,举了一些例子,写的比较啰嗦,稍微精简、加工之后,形成了这篇blog)。


        转载请注明出处: http://blog.csdn.net/ynnmnm/article/details/37743403。作者:夜风。
    展开全文
  • 产品质量与细节

    千次阅读 2016-04-28 09:11:03
    一个电子产品,它的质量究竟什么起主导?答案应该是通过工程师的设计与研发,产线的生产、制造出来的,这是主导,在研发过程中,检验、检测非常重要,因为这个环节更是注重细节的一个关键点。在整个电子产品的流程中...

    一个电子产品,它的质量究竟什么起主导?

    答案应该是通过工程师的设计与研发,产线的生产、制造出来的,这是主导,在研发过程中,检验、检测非常重要,因为这个环节更是注重细节的一个关键点。

    这里写图片描述

    在整个电子产品的流程中,这个产品过程细节决定一切,细节中一个关键的因素就是创新,而不是一味的模仿。创新一个很重要的点就是质量,简单解释就是,质量是创新的前提。

    我更加觉得,苹果手机的诞生,是一种注重细节的精神。
    这里写图片描述

    所以说,作为产品决策者和研发者,如果我们在设计、研发、生产中能关注到每一个细节,我们就可以实现生产出高质量的产品来。

    接下来就需要好好研究市场规律了,这个学问很大 ……

    展开全文
  • 软件工程—产品质量

    2015-05-09 15:52:35
    软件质量特性
  • 过程质量和产品质量

    2019-09-03 09:16:49
    好的过程质量不一定带来好的产品质量,其原因究竟在哪里?如何形成以结果导向的过程改进,如何真正将过程和结果更好的结合起来?这个问题是需要一直去思索的问题,也是我们都面临的需要改进的问题。 ...
  • GB/T 16260-2006 软件工程 产品质量

    千次下载 热门讨论 2020-07-30 23:31:01
    GB-T 16260-2006 软件工程 产品质量,共包括四个部分 GB-T 16260.1-2006 软件工程 产品质量 第1部分:质量模型 GB-T 16260.2-2006 软件工程 产品质量 第2部分:外部度量 GB-T 16260.3-2006 软件工程 产品质量 第3...
  • 农产品的安全问题一直是广大人民息息相关的问题,吃的好吃的放心一直是大家的期许。可是事与愿违,越来越...农产品质量安全追溯为企业实现哪些系统功能? 1.农产品安全生产管理 以农业生产者的生产档案信息为基础,...
  • 测试如何提升产品质量

    千次阅读 2018-05-14 18:00:52
    那么测试需要做哪些工作来保证产品质量呢? 单测覆盖率 对代码最细节的测试就是单测,使用单测覆盖率工具对开发的单测进行指标统计,并进行一定的指标限制 代码审查工具 使用编程语言对应的format、link等工具对...
  • 木已成舟,彼时,能为产品质量的提升所做的事情已经极为有限了。那么怎么做才是比较好的方法呢?答案是从一开始就介入产品研发,并在整个过程中都监控质量的状况。一线测试人员可能并没有机会介入产品的立项,但是从...
  • 006- 软件产品质量特性是什么?

    千次阅读 2019-06-22 16:16:39
    软件产品质量特性是什么? 功能性:适应性、准确性、互操作性、依从性、安全性。 可靠性:成熟性、容错性、以恢复性。 可使用性:易理解性、易学习性、易操作性。 效率:时间特性、资源特性。 可维护性:易...
  • 随着社会上软件产品应用的日益普及,市场对软件产品质量的要求会不断提高,致使软件测试的地位变得越来越来重要了。软件质量是指软件产品中能满足给定需求的各种特性的总和。这些特性称做质量特性,ISO/IEC
  • 研发管理:关于产品质量的一些思考

    千次阅读 热门讨论 2013-04-01 21:15:57
    1、 现状:在新产品开发和维护过程中,经常会遇到产品质量的问题。一种情况是在新产品开发时遗留的bug,还有一种情况是维护过程中引入的新的bug。2、 原因:这个现状的原因有两个方面。一是资深研发人员的流失,这...
  • 对于软件产品质量的一点看法

    千次阅读 2009-01-29 23:51:00
    高兴的是我们的企业和客户越来越重视软件产品的质量了,不管是甲方的市场驱动,还是乙方自身对产品质量的重视,都说名我国软件产业在产品质量方面的要求提高了,软件企业开始使用工程的方法和技术进行软件测试的管理...
  • 产品质量先期策划和控制计划(APQP)

    千次阅读 2010-12-14 21:48:00
    产品质量先期策划和控制计划(APQP)APQP的英文名是 Advanced Product Quality Planning and PlanAPQP是用来确定和制定确保某产品使顾客满意所需步骤的一种结构化方法。一般分为五个过程:计划和确定项目、产品设计和...
  • 一把手的态度决定产品质量

    千次阅读 2012-10-03 12:31:06
    一把手的态度决定产品质量  取这个名字时,曾想过 产品经理决定产品质量,战略决定质量等等,最后还是选择更加直接的一把手的态度决定产品质量。  无论任何产品,能决定产品质量,甚至产品本身的,只有一个...
  • Purpose 目的过程与产品质量保证(PPQA)的目的在于使项目成员与管理层客观地了解过程及相关的工作产品。Introductory Notes 简介过程与产品质量保证过程域包含以下内容: * 依据适用的过程描述、标准和程序,对已...
  • 第十一章 产品质量法律制度学时:2小时 第一节 产品质量法概述一、产品的概念和基本特征一般意义上的产品,是指人们运用劳动手段对劳动对象进行加工而成的,用于满足人们生产生活需要的物品。《产品质量法》中的...
  • 软件产品质量特性(GB/T 25000.51)

    千次阅读 2017-09-05 17:04:11
    新标准将产品质量划分为8个特性
  • 每天读一篇一线开发者原创好文 笔者作为一个经验不甚丰富的测试人员,在...同事回答:QA就是质量的把控和监督者,QA不要局限于"测试分析"、"测试设计"、"测试执行"等等,所有能够顾促进质量提高的事情都QA应该参与
1 2 3 4 5 ... 20
收藏数 378,931
精华内容 151,572
关键字:

产品质量