产品诚可贵，质量价更高

缘起

&＃x1f49d; 叮~~~&＃xff0c;有消息过来了&＃xff0c;一看是测试领域博主拾|贰发来的信息&＃xff0c;如下&＃xff1a;

大概意思是&＃xff1a;

• 活动链接&＃xff1a;2022年国内软件质量调查问卷&＃xff1b;
• 关于活动内容&＃xff0c;以下来自活动详情页的说明&＃xff1a;

CSDN《2022年国内软件质量调查》正式开启&＃xff0c;我们诚邀各位博主&＃xff0c;特别是测试领域的各位技术er参与调查&＃xff08;调查地址&＃xff1a;https://bbs.csdn.net/topics/610411036&＃xff09;&＃xff0c;并围绕主题&＃xff0c;撰写《我填写“2022年国内软件质量调查问卷”的感想》&＃xff0c;或者《我亲身经历的2022年软件质量工作》 相关内容博文&＃xff0c;参与投稿即可获得【话题达人】勋章&＃43;【质量卫士】定制勋章&＃xff0c;更有机会获得CSDN周边大奖&＃xff01;

• 说实话&＃xff0c;我不是为奖品而来的&＃xff0c;因为多年的测试领域工作经验&＃xff0c;让我深深体会到产品的质量是多么的重要。带着感谢和好奇的心我打开链接一步步完成了问卷调查。

&＃x1f49d; 以下是对我填写“2022年国内软件质量调查问卷”的感想&＃xff0c;仅为个人观点&＃xff0c;我的大概思想是这样的&＃xff1a;

---

『产品诚可贵&＃xff0c;质量价更高』

凡涉及“行为、动作、过程、活动等”均会涉及质量&＃xff0c;质量无处不在。

所有的问题最终要落到团队、管理、流程、制度上。

质量从组织架构、质量文化、质量体系上进行牵引可能有更好的效果。

质量不等于测试&＃xff0c;一个成功的高质量产品的质量&＃xff0c;势必是从干系人、到团队、到客户、到公司层面的质量总和。

---

所属行业

&＃x1f49b; 我们产品主要是JunPin软件&＃xff0c;所以是什么行业我就不明说了&＃xff1b;
&＃x1f49b; 我说下这个行业我了解到的一些特点&＃xff1a;

• 质量要求是重中之重&＃xff0c;有严格的质量体系&＃xff1b;
• 项目周期可短可长&＃xff0c;一般情况会偏长一点&＃xff0c;平均大于3个月&＃xff1b;
• 注重交付物的质量&＃xff0c;如各种资料文档、规范等&＃xff1b;
• 所有的过程都有质量监控和严格的执行标准&＃xff1b;
• 审核和评审会多一点&＃xff0c;慎重是必须的&＃xff1b;
• 当别人还在和“周公聊天的时候&＃xff0c;你仍然在写文档”&＃xff1b;
• 需要具备很强的行业知识&＃xff0c;不然你是很难开展工作的&＃xff1b;
• 一些开源的、没有经过认证的工具、框架还是很难被项目“纳入法眼”。

&＃x1f49b; 其次来说说我们的重点~质量&＃xff0c;怎么说呢&＃xff1f;要求很高&＃xff1a;

• 刚过试用期&＃xff0c;就参加了GJB9001C内审员培训&＃xff0c;这个对我个人来说是真的有用&＃xff0c;里边明确了产品从论证、研制、生产、试验、维修和服务全过程的质量要求。关于介绍可参考GJB9001C质量管理体系要求&＃xff1b;
• 学了这个&＃xff0c;我才知道原来一个产品从0到1&＃xff0c;要想高质量交付真的很不容易&＃xff0c;但是标准已经规定了各种规范、制度、模板、流程等&＃xff0c;感觉真的是“无微不至”的考虑&＃xff1b;
• 因为我是做测试的&＃xff0c;如果想从最基本的方面保障质量&＃xff0c;那就是每个测试人员必须有扎实的行业理论基础&＃xff0c;举个简单的例子&＃xff08;我们是做可靠性的&＃xff09;&＃xff1a;

六性	指标
可靠性	失效率
可靠性	平均致命故障间隔时间&＃xff08;MTBCF&＃xff09;
可靠性	平均故障间隔时间&＃xff08;MTBF&＃xff09;
可靠性	可靠度
测试性	虚警率&＃xff08;FAR&＃xff09;
测试性	故障检测率&＃xff08;FDR&＃xff09;
测试性	故障隔离率&＃xff08;FIR&＃xff09;
保障性	平均后勤延误时间&＃xff08;MLDT&＃xff09;
维修性	最大修复时间
维修性	平均修复时间&＃xff08;MMT&＃xff09;
维修性	平均预防性维修时间&＃xff08;MPMT&＃xff09;
维修性	平均修复时间&＃xff08;MTTR&＃xff09;
安全性	事故率
安全性	总损失率

• 这些词表面上看上去没啥&＃xff0c;但是要得到它的指标值&＃xff0c;是需要各种算法计算得出&＃xff0c;且涉及了很多的其他知识点&＃xff0c;如果是外行人真的需要很长一段时间去学习和摸索。

---

目前行业交叉太多&＃xff0c;并且有些集团公司也有很多的子公司&＃xff0c;且项目可能也是很多交叉&＃xff0c;很难明确说具体是某个行业&＃xff0c;不确定是否应该做双选(不能大于2个)&＃xff0c;这样可能会更符合一些行业现象&＃xff1f;哈哈

---

研发人员规模

&＃x1f49a; 人多不一定质量好&＃xff0c;可能更能体现公司的开发队伍和业务的庞大&＃xff1b;
&＃x1f49a; 我们公司研发人员规模属于中等吧&＃xff0c;主要质量要求是“精而强”&＃xff1b;
&＃x1f49a; 这个方面&＃xff0c;我觉得要想从质量方面去提升&＃xff0c;最主要的还是要考虑研发人员的配比&＃xff0c;以及角色的分工&＃xff0c;比如需求、PL、PM、测试、开发、运维等人员是怎样打配合仗&＃xff1b;
&＃x1f49a; 以前公司遇到过很多不太友好的现象&＃xff1a;

• 开发1个人干5个人的活&＃xff0c;bug一大堆&＃xff1b;
• 测试动不动全量测试&＃xff0c;版本迭代快的超过你的想象&＃xff1b;
• 需求还没整明白&＃xff0c;大家伙就开始干了&＃xff0c;干到一半发现与客户的需求差距很大&＃xff1b;
• 架构设计压根没考虑高并发场景&＃xff0c;一到用户那动不动就崩了&＃xff1b;
• 每天开会&＃xff0c;6h会议&＃xff0c;2h工作&＃xff08;还是下班加班干的&＃xff09;&＃xff0c;上班时的2h去哪了&＃xff1f;答&＃xff1a;在开会的路上。

&＃x1f49a; 人一多&＃xff0c;更多是要在研发体系&＃xff0c;包括管理体系、产品体系、流程体系等去约束、去规定、去规范&＃xff0c;可能才能让一个大的团队高效运行。

---

不确定能否调查到研发体系重点人员比例&＃xff0c;比如开发&＃xff1a;测试&＃xff1a;UI设计&＃xff1a;需求&＃xff1a;运维等。这样可以看到从体系结构上&＃xff0c;如何保障产品的设计质量&＃xff1f;

---

所在团队规模

&＃x1f499; 我所属测试团队&＃xff0c;目前不超过100人&＃xff0c;以前也在10人以下的团队呆过&＃xff1b;
&＃x1f499; 测试团队我觉得要在保障质量上有所突破&＃xff0c;可能是&＃xff1a;

• 构建团队的架构&＃61;&＃61;&＃61;【搭建体系“灵魂”】比如&＃xff1a;
  
  
  

• 基础设施建设&＃61;&＃61;&＃61;【夯实基础保障】&＃xff0c;比如&＃xff1a;
  

• 建立测试质量管理机制&＃61;&＃61;&＃61;【质量持续改进】&＃xff0c;比如&＃xff1a;
  

• 人才梯队建设&＃61;&＃61;&＃61;【打造强业务人才】&＃xff0c;比如&＃xff1a;
  

• 组织能力和氛围建设&＃61;&＃61;&＃61;【人才的基本保障】&＃xff0c;比如&＃xff1a;
  

• 测试技术平台建设&＃61;&＃61;&＃61;【质量保障的技术手段】&＃xff0c;以下为示例&＃xff0c;不代表具体开展的方向性指引&＃xff1a;
  

• 另外还有其他在提升质量方面应该做的事情&＃xff0c;比如通过某种质量认证、测评认证等。

---

不知道能否调查到团队的架构形式&＃xff0c;比如直线制&＃xff0c;职能制&＃xff0c;直线&＃xff0d;职能制&＃xff0c;事业部制&＃xff0c;模拟分权制&＃xff0c;矩阵结构等&＃xff1f;

---

团队开发模式

&＃x1f90e; 我们开发模式比较灵活&＃xff0c;怎么说呢&＃xff1f;根据客户产品灵活调整&＃xff0c;有敏捷中的Scrum、敏捷中的BDD/FDD、瀑布模型、V模型等&＃xff1b;
&＃x1f90e; 简单说&＃xff0c;比如有的是课题项目&＃xff0c;就不太适合Scrum。从个人经历的学习过程看&＃xff0c;合适的开发模式&＃xff0c;是有助于提升产品质量的。但是一成不变的开发模式&＃xff0c;可能也不太好。还是要根据团队、项目、客户、产品等各种因素适当的调整&＃xff1b;
&＃x1f90e; 还有的开发模式&＃xff0c;不一定要硬套&＃xff0c;不然对提升质量反而是障碍&＃xff0c;比如是CMMI3级的过程域&＃xff1a;

• 它有18个过程域&＃xff1a;
  
• 那如果每个公司都严格按照这个去走&＃xff0c;不“因地制宜”&＃xff0c;适当的修改&＃xff0c;很可能它就不适合你的团队和项目&＃xff1b;

&＃x1f90e; 我们再来看看&＃xff0c;某公司对CMMI3级进行精简后的过程SPP&＃xff0c;即“精简并行过程”&＃xff08;Simplified Parallel Process&＃xff09;&＃xff1a;

• SPP是基于CMMI以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”&＃xff0c;它由众多的过程规范和文档模板组成。SPP主要用于指导企业持续地改进其软件过程能力&＃xff1b;
• SPP含义是&＃xff1a;

&＃xff08;1&＃xff09;对CMMI 3级以内各过程域的内容和要求作了“精简”处理。
&＃xff08;2&＃xff09;在产品生命周期之内&＃xff0c;项目管理过程、项目研发过程和机构支撑过程“并行”开展。

• SPP开发设计模型&＃xff1a;
  
• 从SPP的模型我们不难看出&＃xff0c;这个其实就是对CMMI3进行了精简&＃xff0c;更适合某企业自身的发展&＃xff0c;这样也许会更好的提升产品质量&＃xff0c;那它做了怎样的精简呢&＃xff1f;我们可从下图看出&＃xff1a;
  

---

适合自己的开发模式才是最好的开发模式&＃xff1f;没有最好&＃xff0c;只有更好~

---

产品类别

&＃x1f5a4; 产品类别不管是2B&＃xff08;面向企业&＃xff09;还是2C&＃xff08;面向个人&＃xff09;&＃xff0c;个人觉得他的质量重点应该有所偏向&＃xff1b;
&＃x1f5a4; 比如说某些团队它本身成熟度就摆在那里&＃xff0c;但非要让他把2C做成2B的质量要求&＃xff1a;

• 这里不是说2C没有2B质量要求高&＃xff0c;而是侧重点不同&＃xff1b;
• 2C可能更偏向于个人使用&＃xff0c;用户体验程度和交互设计质量可能有所偏重&＃xff1b;
• 2B的产品量级可能更大&＃xff0c;比如性能方面等偏向&＃xff08;猜测&＃xff09;。

---

不能眉毛胡子一把抓&＃xff0c;针对不同的产品&＃xff0c;质量工作重点应该有所偏向。

---

软件主体层次

&＃x1f90d; 关于软件的主体&＃xff0c;我们团队更多偏向应用系统的后端&＃43;应用系统的前端&＃xff1b;
&＃x1f90d; 那对我们测试团队来说&＃xff0c;我们常用的质量测试手段就是接口测试了&＃xff1b;
&＃x1f90d; 我看现在比较常用的几个工具和框架为&＃xff1a;

• 工具&＃xff1a;Jmeter、Postman、Robot Framework等&＃xff1b;
• 框架&＃xff1a;

Unittest&＃43;DDT&＃43;Excel&＃43;BeautifulReport/HTMLTestRunner&＃43;Request


Pytest&＃43;Yaml&＃43;Allure&＃43;Request


• 语言&＃xff1a;Python、Java居多&＃xff1b;
• 常见的框架流程设计&＃xff0c;如下&＃xff08;以下内容仅为举例&＃xff0c;他用请联系对应博主&＃xff09;&＃xff1a;
  软件测试小白进阶之路-自动化测试框架结构图
  
  
  fen_fen-Web接口自动化测试框架设计思路
  
  

---

针对不同的软件主体&＃xff0c;站在测试角度来说&＃xff0c;它的质量保障手段可能会存在差异。

---

软件交付周期

&＃x1f494; 这个比较要命&＃xff0c;也是直接和质量有关的一个环节&＃xff1b;
&＃x1f494; 往往在产品开发过程中&＃xff0c;因为客户要求的节点到了&＃xff0c;我们就为了赶时间节点&＃xff0c;忽略了质量&＃xff1b;
&＃x1f494; 这里我们团队的软件平均交付周期是大于3个月的&＃xff0c;长的甚至也有几年的&＃xff0c;但是不论哪种项目&＃xff0c;我们在评估产品交付周期的时候&＃xff0c;个人觉得&＃xff1a;

• 得考虑团队的能力成熟度&＃xff1b;
• 需要的详细的人力、物力等描述&＃xff1b;
• 周密的项目计划&＃xff1b;
• 准确的客户需求定位&＃xff1b;
• 巧妙减少客户需求的变更和规划&＃xff1b;
• 过程质量监督和审查&＃xff1b;
• 风险管控和预警等。

&＃x1f494; 另外我觉得项目周期除了以上的参考外&＃xff0c;可能需要严格的过程标准规范来约束&＃xff0c;比如针对JunPin我们有详细的标准参考GJB 438B-2009 军用软件开发文档通用要求&＃xff1a;

• 它明确了软件开发文档编制的种类、结构和内容等要求&＃xff1b;
• 并且有详细的文档说明&＃xff0c;这样对我们在开发过程就有了规范&＃xff0c;势必也对我们产品周期有一定的影响&＃xff0c;因为你是按标准去走&＃xff0c;它可能已经帮你规避很多的问题&＃xff1a;
  

---

产品交付周期和很多因素有关&＃xff0c;最直接的就是是否有标准化作业过程&＃xff1f;

---

软件需求质量/感受/问题

&＃x1f497; 需求质量保障&＃xff0c;目前主要是&＃xff1a;

• 有明确的的需求管理和规范&＃xff1b;
• 会进行初审、再审、终审&＃xff1b;
• 变更管理&＃xff1b;
• 质量小组的审核&＃xff1b;
• 需求管理和维护平台等&＃xff1b;

&＃x1f497; 目前对团队的需求比较满意&＃xff0c;因需求中最值得点赞的是&＃xff1a;

• 有需求跟踪矩阵&＃xff1b;
• 有需求唯一标识&＃xff1b;
• 完善的模板参考&＃xff1b;
• 需求的可追踪性&＃xff1b;
• 合格性规定&＃xff1b;
• 各种指标的明确等。
• 比如这个需求和测试唯一性标识&＃xff0c;就比较好&＃xff1a;
  

&＃x1f497; 需求中遇到的问题&＃xff0c;我们目前最大的问题是需求变更频繁&＃xff0c;主要表现在&＃xff1a;

• 客户每适用完软件都会提很多的需求&＃xff1b;
• 开发过程中突然会有别的需求加进来&＃xff1b;
• 各方对需求理解不一致&＃xff1b;

&＃x1f497; 以上三个问题导致需求变更比较频繁&＃xff0c;目前我们的改进是&＃xff1a;

• 需求管理落实到人&＃43;平台化管理&＃43;人工复核&＃xff1b;
• 客户的需求做严格的审查和筛选&＃xff1b;
• 在流程上再对需求管理做细分等措施。

---

需求的质量直接关乎下游开发、测试等环境的质量。需求管理最为重要。

---

设计质量保证及好与不好

&＃x1f496; 设计质量我们自己的侧重点在架构师的培养方面&＃xff1b;
&＃x1f496; 另一方面是在原型&＃xff08;仿真&＃xff09;验证方面下了很大功夫&＃xff1b;
&＃x1f496; 还有一个重点是测试人员、“天使客户”也会参与到设计评审&＃xff1b;
&＃x1f496; 这里重点说下我们测试是如何做的&＃xff1f;

• 以前很多时候&＃xff0c;测试只关注版本转测后的测试工作&＃xff0c;很少参与到设计工作中&＃xff1b;
• 在设计时&＃xff0c;测试会和架构师进行简单的确认和沟通&＃xff0c;了解该技术的可测试性&＃xff1b;
• 在评审时&＃xff0c;测试站在用户角度会提出一些显而易见的易用性问题&＃xff1b;
• 在评审后&＃xff0c;测试会找对应的架构进行模拟测试和演练帮助架构师进行规避问题等&＃xff1b;

&＃x1f496; 目前体验不太好的一点是功能设计方面&＃xff0c;原因是&＃xff1a;

• 有些客户的场景无法拿到&＃xff0c;只能进行猜测或模拟&＃xff1b;
• 因为业务的特殊性&＃xff0c;业务比较复杂&＃xff0c;耦合性太高。

---

设计的质量最好还是专业的人做&＃xff0c;其他环节前移到设计工作。比如测试前移至设计评审等工作。

---

开源组件

&＃x1f498; 这个就不深入了&＃xff0c;因为行业的特殊性&＃xff0c;开源用的不多&＃xff0c;基本的质量保障手法是&＃xff1a;

• 有严格审查团队进行开源组件的研究、评审和验证工作&＃xff1b;
• 不过测试这块还好&＃xff0c;主要不是组件了&＃xff0c;更多的是开源的工具可能还会用到一些。

代码质量

&＃x1f49d; 这个作为测试深有体会&＃xff0c;我们常见的因为代码质量导致的测试困扰有&＃xff1a;

• 缺陷重复打开&＃xff0c;不能闭环&＃xff1b;
• 转测版本冒烟测试不通过&＃xff1b;
• 开发没有进行自测试&＃xff0c;一键操作导致简单的报错问题&＃xff1b;
• 缺陷数量版本分布确实不合理等&＃xff1b;

&＃x1f49d; 作为测试我们期望的结果是&＃xff1a;缺陷确实分布合理和有效的消除&＃xff1b;

• 比如缺陷在产品开发中的分布&＃xff0c;我们最好能在设计阶段发现更多的问题&＃xff0c;而不是把问题遗留到测试阶段&＃xff0c;测试阶段发现的问题越多&＃xff0c;修改的地方越多&＃xff0c;隐藏的风险就越大&＃xff1a;
  
• 还有缺陷的消除矩阵&＃xff0c;所有缺陷尽量在code阶段消灭&＃xff0c;避免遗留到客户&＃xff1a;
  

---

代码质量也是直接影响测试、客户对产品体验。

---

千行缺陷数

&＃x1f49f; 这个指标目前我觉得不太合理&＃xff0c;不过CMMI中有对千行代码缺陷率有描述&＃xff1a;

• 计算公式为&＃xff1a;bug数/代码行数*1000&＃xff1b;
• CMMI等级与千行代码缺陷率的对照关系&＃xff1a;

CMMI级	千行代码缺陷率
1级	11.95‰
2级	5.52‰
3级	2.39‰
4级	0.92‰
5级	0.32‰

• 目前有其它的指标可对这个指标进行优化&＃xff0c;比如圈复杂度、平均缺陷修复时间。详细参考&＃xff1a;什么是千行代码缺陷率&＃xff1f;

---

如非不得已&＃xff0c;建议取消这个指标。

---

单元测试代码覆盖率和测试质量

&＃x1f4a5; 单元测试代码覆盖率&＃xff0c;首先有个疑问&＃xff0c;这个活动由谁来做&＃xff1f;开发&＃xff1f;测试&＃xff1f;

• 我觉得这个根据团队的人员配置和能力来定&＃xff1b;
• 测试最好能前移到单元测试这块&＃xff0c;比如白盒测试&＃xff1b;
• 开发也可以把单元测试作为自测试的一种手段&＃xff0c;避免转测时的版本质量不高。

&＃x1f4a5; 至于这个值&＃xff0c;目前针对不同的项目有所取舍&＃xff0c;行覆盖可以达到90%&＃xff0c;哈哈&＃xff1b;
&＃x1f4a5; 测试质量&＃xff0c;这个又有的说了&＃xff1a;

出了问题&＃xff0c;老板第一句“测试是怎么测的&＃xff1f;”
项目经理&＃xff0c;第一句“这是谁测的&＃xff1f;”
产品经理&＃xff0c;第一句“你用例覆盖不全~”

&＃x1f4a5; 是不是有以上相同的场景呢&＃xff1f;我们如何保证质量呢&＃xff0c;个人观点&＃xff1a;

• 像代码覆盖、功能覆盖、缺陷根因分析、用例设计等都是必要手段&＃xff0c;但这都是大家一直在说的&＃xff0c;我觉得应从测试本质上来讲&＃xff1b;
• 自动化测试是否纳入到流程中&＃xff0c;而不是为了实现自动化而自动化&＃xff1f;
• 缺陷根因分析是否落地&＃xff0c;是否有回访和检测机制&＃xff1f;
• 产品的测试技术布局如何做的&＃xff1f;是直接开始闷头干&＃xff1f;还是有目标&＃xff1f;
• 我们拿JunPin软件测试来说&＃xff0c;可以参考&＃xff1a;GJBZ 20141-2004军用软件测试指南&＃xff0c;里边明确了软件在生命周期内各个阶段的测试方法、过程和准则。有标准的规范要求&＃xff0c;我们测试工作也不会跑偏&＃xff1b;
• 另外从某网站之前看到了一个测试技术布局&＃xff0c;个人觉得不错也针对性进行整理&＃xff0c;感觉这个是基本的测试质量保障了&＃xff0c;该用到的技术手段我们不要吝啬&＃xff1a;
  

---

代码质量尤其重要&＃xff0c;测试质量不等于产品质量。

---

质量文化和QA人员

&＃x1f4a6; 产品设计过程中&＃xff0c;我们一定要有质量文化&＃xff0c;她就是无形的力量&＃xff0c;帮助每个人树立起质量意识&＃xff1b;
&＃x1f4a6; 质量文化不是一句口号那么简单&＃xff0c;要融入到产品开发过程中&＃xff0c;比如我们需要有严格的绩效考核和质量目标&＃xff1a;

• 这里我觉得HW的IPD流程是非常值得学习的&＃xff0c;像其中的TR点的过点要求&＃xff0c;其实就是一种质量保障&＃xff1b;
• 如以下IPD业务管理体系架构&＃xff08;图片来源于&＃xff09;&＃xff1a;

http://u.uin.com/external/publishInfo.shtml?id&＃61;6203&objectType&＃61;%CE%C4%D5%C2

&＃x1f4a6; 我们需要设置专门的质量保障人员QA&＃xff0c;比如在SPP中项目管理过程域&＃xff0c;QA可能需要全程关注产品生命周期的几个阶段&＃xff0c;比如可能涉及的活动为&＃xff1a;

测试团队人员配置

&＃x1f4a2; 我们以独立的部门形式存在&＃xff0c;比如测试部或测试中心&＃xff1b;
&＃x1f4a2; 是独立开发之外的&＃xff0c;不是归属到开发部门下管理&＃xff0c;这样做就是为了形成监督和审查&＃xff1b;
&＃x1f4a2; 测试团队我更倾向的是智能型团队&＃xff08;前边已经提及过&＃xff09;

• 因为专业的人做专业的事情&＃xff0c;但是有一点就是对人员要求比较高&＃xff0c;成本会比较高

---

总之我觉得测试应该以独立的团队存在。不过有些开发模式并不太适合&＃xff0c;比如敏捷开发。

---

质量工程活动

&＃x1f4ab; 目前开展的质量活动是用户体验工程&＃xff1a;

• 分内部用户和外部用户&＃xff1b;
• 内部用户主要为除了测试、研发、需求、产品等之外未使用过软件的人员&＃xff1b;
• 外部用户主要是“天使客户”&＃xff1b;
• 制定详细的问题收集和跟踪模板&＃xff0c;定期进行用户体验活动竞赛&＃xff1b;
• 当然不止这些&＃xff0c;这是个系统工程了&＃xff0c;这里不赘述了。

功能用例自动化占比

&＃x1f49b; 功能测试用例数的自动化实现占比已经大于90%了&＃xff0c;但是自动化并不是全能的&＃xff1b;

• 从他的优缺点可以看出&＃xff0c;要达到90%其实还挺难的&＃xff0c;就看业务的复杂程度了&＃xff1b;
• 如果团队有实力做自动化&＃xff0c;当然专人去做更好&＃xff0c;没有的话可能做自动化反而是投入和产出不成正比&＃xff0c;得不偿失。

优点	缺点
重复执行、频繁操作	不能100%替代人工测试
模拟手动测试无法覆盖的场景	不能达到100%覆盖率
利用空闲时间执行	需要时间去分析结果
释放一部分测试人员精力	对软件质量依赖大&＃xff08;前提是软件稳定、改动小等&＃xff09;
测试结果客观公正	需要专业的工程师投入专门的时间开发
/	投入成本可能会大一些

&＃x1f49b; 考虑做自动化最主要是清楚它的应用场景&＃xff1a;

场景	说明
测试周期	项目周期长&＃xff0c;轮次较多的软件
数据量级	需要制造大量的测试数据
软件稳定性	使用稳定和成熟阶段的产品测试
回归测试	需要进行简单回归的测试
冒烟测试	主线功能的冒烟
巡检测试	线上环境的定期巡检
发布验证	主线功能的发布验证测试

&＃x1f49b; 常见的工具&＃xff08;仅为举例&＃xff09;&＃xff1a;

---

不能盲目做自动化&＃xff0c;要从团队、项目、产品等多维度综合考虑&＃xff0c;自动化只是一种手段&＃xff0c;一种辅助测试的手段。

---

工具组合

目前使用的是混合方案&＃xff08;开源或商业第3方工具&＃43;自研&＃xff09;
这个不多聊了&＃xff0c;感觉自己没资格讲&＃xff0c;哈哈哈~

2022年质量工作重点和问题

&＃x1f496; 2022质量工作重点&＃xff1a;团队人员能力建设&＃xff08;培训&＃xff09;上&＃xff0c;因为&＃xff1a;

• 行业的特殊性&＃xff0c;业务比较难以理解&＃xff0c;主要从业务上牵引大家对产品熟悉程度&＃xff1b;
• 另外是行业内的专业开发、测试技术的学习和应用&＃xff1b;
• 团队人员对于质量体系的学习和宣贯。

&＃x1f496; 2022质量问题&＃xff1a;需求变更太频繁了&＃xff0c;这个之前已经提及&＃xff0c;不再赘述。

2023年质量改进

&＃x1f495; 深入学习GJB相关质量管理体系&＃xff0c;并融入项目产品开发&＃xff1b;
&＃x1f495; 研究SPP的四个过程域&＃xff0c;有针对性的对部分项目进行试点&＃xff1a;






&＃x1f495; 进行团队能力成熟度认证&＃xff0c;如CMMI认证&＃xff1b;
&＃x1f495; 进行GJB9001C质量管理体系学习&＃xff1b;
&＃x1f495; 成立测评实验室取得CMA、CNAS认证等。

---

质量改进这是个持续的过程&＃xff0c;也是一个漫长的过程&＃xff0c;急不得。

---

2023年自动化测试投入

&＃x1f3c6; 主要在CI/CD、以及UI/API测试专项投入&＃xff1b;
&＃x1f3c6; 精简自动化框架&＃xff0c;并覆盖WebUI、Http接口、WindowsGUI、APP、小程序等领域&＃xff1b;
&＃x1f3c6; 自动化平台融合&＃xff0c;接口&＃43;性能&＃43;UI&＃xff1b;
&＃x1f3c6; 自研自动化框架&＃xff0c;目的是人人可以用&＃xff0c;人人不用写代码&＃xff1b;
&＃x1f3c6; 投入专业的测开工程师或自动化工程师&＃xff0c;专人负责&＃xff1b;
&＃x1f3c6; 如果说有能力&＃xff0c;我觉得应把自动化技术进行扩展&＃xff0c;可以从内部测试、软件测评、测试培训、测试外包方面入手去把技术深化。

---

对自动化又爱又恨&＃xff0c;爱它确实带来了很多方便&＃xff0c;恨它对它不了解的人瞎搞自动化。

---

缘落

• 以上就是《我填写“2022年国内软件质量调查问卷”的感想》&＃xff0c;仅仅是个人想法&＃xff0c;不代表任何组织、团体&＃xff1b;
• 以上内容难免有错误或偏见&＃xff0c;欢迎指正&＃xff1b;
• 文中的部分截图已经注明来源和出处&＃xff0c;如他用请联系对应的授权人&＃xff1b;
• 做产品&＃xff0c;我们三两人坐一起&＃xff0c;推敲、熬夜很可能就能做出来&＃xff1b;但是做好产品&＃xff0c;质量为先&＃xff0c;它涉及的领域、面都非常广&＃xff0c;可谓产品诚可贵&＃xff0c;质量价更高。
• 再次说明个人观点&＃xff08;不喜勿喷&＃xff0c;嘎嘎嘎~&＃xff09;&＃xff1a;

---

凡涉及“行为、动作、过程、活动等”均会涉及质量&＃xff0c;质量无处不在。

所有的问题最终要落到团队、管理、流程、制度上。

质量从组织架构、质量文化、质量体系上进行牵引可能有更好的效果。

质量不等于测试&＃xff0c;一个成功的高质量产品的质量&＃xff0c;势必是从干系人、到团队、到客户、到公司层面的质量总和。

---