《产品测试管理》学习心得体会

上周5月27、28日两天参加《产品测试管理》，以下几点印象比较深刻：

我国研发现状及对国家的影响。

1. 国外软件好，但需求变更慢甚至不允许变更。国内软件差，但需求变更快，服务好。即质量不好，服务来补。这也导致中国研发普遍特点：追求快，把质量当口号。
2. 国内高端产品少，低端产品又不想做。中国高端品牌仅有少数种类，比如：华为，大疆等。大多数品牌质量不行。而一般制造业中国人又不想做了，比如工厂招不到人，年轻人不想进厂，工人工资高等问题日益突出。中国迫切需求经济转型，而质量问题是直接关乎国家利益。质量做好了，中国才能从一个三流国家华丽转变成世界一流国家。

测试怎么做，做得好又最便宜。

质量与成本是相互影响、相互矛盾的关系。过高的追求质量会提高成本;反过来说，质量不合格而进行修复或整改，也必然造成成本上升，是最终达不到成本控制的目的。如何解决质量与成本之间的矛盾关系，学术界上在在一百年前的1905年早已有人回答了这个问题，他就是质量管理名人美国人威廉.爱德华滋.戴明。以下是戴明与丰田故事的一小段。

当年，丰田公司（Toyota）决定把质量放在第一位，它的这步棋在当时并没有像今天看起来那样吸引眼球。当时的公司深陷困境。在20世纪50年代末，公司将第一批汽车发往美国市场，却因为质量低劣而遭到嘲笑。身处危机之时，公司的总裁石田退三（Taizo Ishida）决定做一件对任何公司——尤其是日本公司——来说都是最难做到的事情。丰田采纳了一位外部人士——质量大师威廉·爱德华兹·戴明（W. Edwards Deming）的创意，为了改善自己，对组织进了一次彻底的整顿。今天，丰田的质量系统被称为“丰田之道”（Toyota Way），一直被世界各地的制造业公司甚至是服务机构奉行。举例来说，丰田之道能帮助丰田比竞争对手更快地设计出汽车，表明这一流程对于脑力工作的重要性与对于体力工作的重要性是一样的。然而，执行这个流程要比看上去困难许多，即使是丰田自身在近年来也受困于质量问题。通过重新拾起对丰田之道的热忱，这家汽车公司现在再次回到了正轨。

 

 “测试做得好又最便宜”的办法只有一个：那就是尽早开始。从需求、设计开始测试。好比女人怀孕。孕前健康体验、孕中产检，尽可能避免先天不足的孩子出世。假如：”孩子“先天就不足怎么办？还要不要它？有些公司不但要，还要它变得牛。这本身就是观念的错误。需求评审是产检的一个过程，产检准不准确，产检水平高不高好不好，直接影响到孩子的先天质量。

测试人员，如何“需求评审“

时机：与产品包需求分析同步进行。正式评审会议上，测试人员根据各方产出的文档进行需求评审，并将评审结果填入到评审报告相关材料中。

 

第一步：提取测试原始需求。特别注意测试验验库、用户需求、继承产品需求、协议和规范。巴士在线测试人员在经验库、继承产品需求和协议、规范上做得远远不够。经验库比如上一个版本遗漏的问题点。协议和规范，例如国际标准、国内标准、法律法规等。

第二步：产品测试规格分析。重点审核需求描述的准确性、二义性、可测试性DFT等。例如：摄像头升降快。需定义快是多少秒。摄像头升降坏了，需提出快速解决故障的办法，摄像头坏了，软件如何提醒等这类属于DFT范畴。该步可以提出测试相关工具需求。具体如何审核DFT，可参照《可测试性需求操作指导书.doc》

第三步:继承性分析。继承产品需求和协议、规范。继承产品的问题历史经验属于继承性分析。例如：摄像头升降快。摄像功能为软件继承性功能，升级杆的结构设计等硬件继承性功能。通过继承性分析，一来减少测试用例撰写的工作量，二来也是一种很好利用现成经验的办法。

第三步：测试重点分析。该需求特性使用的频率，特性的重要性进行评审。成熟度分析，可通过客户反馈的问题点，测试人员经验分析等评审其成熟度。测试重点分析，可得到测试策略，即在有限的资源下，尽可能保证质量的一种手段。

第四步：测试类型分析。根据以上三步的操作后，基本可以得到测试类型分析表。测试类型分析表，将决定测试类型主要的组成部分，以及各测试阶段的测试重点。

第五步：功能交互分析：交互关系。此处重点分析与其他数据和资源共享的影响。比如：打电话影响摄像头工作，配置影响摄像头工作等。

第六步：关联图分析。本环节确认不同的用户对象、各子系统、各软硬接口的影响关系等。

第七步：测试规格整合。将以上六步骤等到的结果进行建模归档，形成测试计划、策略。

总结:需求评审是有一定技术难度且工作量较大。通常普通测试人员难以胜任。而当前巴士在线研发测试团队的人员结构及数量都不足于支撑该模式开展。国内著名芯片厂商展讯通信有限公司专职测试人员专注于需求评审设计，工具开发，技术研发。而用例的执行由学校大三学生兼任。该模式下，即能解决人力资源成本问题，还能解决用例执行不足问题。

只有测试人员的测试，没有开发的测试是做不好质量

 

从上图可以明显看出，UT（单元测试）测试基本上能找到最细粒度的缺陷。而ST（系统测试）却不行。故只有测试的测试，没有开发的测试其产品质量不会太高的原因就在于此。在规避开发未自测的流程规则下，一般公司会要求在打包发给测试之前，开发需出示自测报告。甚至更严格时，要求开发在报告时附件单元测试用例结果。目前巴士在线在开发自测方面做得远远不够，在2016年上半年有要求开发人员在日记上写(自测)，甚至上了静态代码分析工具。但现在基本已不再使用。开发自测，已全靠自觉。

 

最难的不是怎么测，而是如何做到人人都有质量思维

此处省略…

转载于:https://www.cnblogs.com/hisweety/p/11001946.html