叮~~~,有消息过来了,一看是测试领域博主拾|贰发来的信息,如下:
大概意思是:
CSDN《2022年国内软件质量调查》正式开启,我们诚邀各位博主,特别是测试领域的各位技术er参与调查(调查地址:https://bbs.csdn.net/topics/610411036),并围绕主题,撰写《我填写“2022年国内软件质量调查问卷”的感想》,或者《我亲身经历的2022年软件质量工作》 相关内容博文,参与投稿即可获得【话题达人】勋章+【质量卫士】定制勋章,更有机会获得CSDN周边大奖!
以下是对我填写“2022年国内软件质量调查问卷”的感想,仅为个人观点,我的大概思想是这样的:
『产品诚可贵,质量价更高』
凡涉及“行为、动作、过程、活动等”均会涉及质量,质量无处不在。
所有的问题最终要落到团队、管理、流程、制度上。
质量从组织架构、质量文化、质量体系上进行牵引可能有更好的效果。
质量不等于测试,一个成功的高质量产品的质量,势必是从干系人、到团队、到客户、到公司层面的质量总和。
我们产品主要是JunPin
软件,所以是什么行业我就不明说了;
我说下这个行业我了解到的一些特点:
其次来说说我们的重点~质量,怎么说呢?要求很高:
GJB9001C内审员培训
,这个对我个人来说是真的有用,里边明确了产品从论证、研制、生产、试验、维修和服务全过程的质量要求。关于介绍可参考GJB9001C质量管理体系要求;六性 | 指标 |
---|---|
可靠性 | 失效率 |
可靠性 | 平均致命故障间隔时间(MTBCF) |
可靠性 | 平均故障间隔时间(MTBF) |
可靠性 | 可靠度 |
测试性 | 虚警率(FAR) |
测试性 | 故障检测率(FDR) |
测试性 | 故障隔离率(FIR) |
保障性 | 平均后勤延误时间(MLDT) |
维修性 | 最大修复时间 |
维修性 | 平均修复时间(MMT) |
维修性 | 平均预防性维修时间(MPMT) |
维修性 | 平均修复时间(MTTR) |
安全性 | 事故率 |
安全性 | 总损失率 |
目前行业交叉太多,并且有些集团公司也有很多的子公司,且项目可能也是很多交叉,很难明确说具体是某个行业,不确定是否应该做双选(不能大于2个),这样可能会更符合一些行业现象?哈哈
人多不一定质量好,可能更能体现公司的开发队伍和业务的庞大;
我们公司研发人员规模属于中等吧,主要质量要求是“精而强”;
这个方面,我觉得要想从质量方面去提升,最主要的还是要考虑研发人员的配比,以及角色的分工,比如需求、PL
、PM
、测试、开发、运维等人员是怎样打配合仗;
以前公司遇到过很多不太友好的现象:
人一多,更多是要在研发体系,包括管理体系、产品体系、流程体系等去约束、去规定、去规范,可能才能让一个大的团队高效运行。
不确定能否调查到研发体系重点人员比例,比如开发:测试:UI设计:需求:运维等。这样可以看到从体系结构上,如何保障产品的设计质量?
我所属测试团队,目前不超过100人,以前也在10人以下的团队呆过;
测试团队我觉得要在保障质量上有所突破,可能是:
另外还有其他在提升质量方面应该做的事情,比如通过某种质量认证、测评认证等。
不知道能否调查到团队的架构形式,比如直线制,职能制,直线-职能制,事业部制,模拟分权制,矩阵结构等?
我们开发模式比较灵活,怎么说呢?根据客户产品灵活调整,有敏捷中的Scrum
、敏捷中的BDD/FDD
、瀑布模型、V
模型等;
简单说,比如有的是课题项目,就不太适合Scrum
。从个人经历的学习过程看,合适的开发模式,是有助于提升产品质量的。但是一成不变的开发模式,可能也不太好。还是要根据团队、项目、客户、产品等各种因素适当的调整;
还有的开发模式,不一定要硬套,不然对提升质量反而是障碍,比如是CMMI3
级的过程域:
我们再来看看,某公司对CMMI3
级进行精简后的过程SPP
,即“精简并行过程”(Simplified Parallel Process)
:
SPP
是基于CMMI
以及软件工程和项目管理知识而创作的一种“软件过程改进方法和规范”,它由众多的过程规范和文档模板组成。SPP
主要用于指导企业持续地改进其软件过程能力;SPP
含义是:(1)对CMMI 3级以内各过程域的内容和要求作了“精简”处理。
(2)在产品生命周期之内,项目管理过程、项目研发过程和机构支撑过程“并行”开展。
适合自己的开发模式才是最好的开发模式?没有最好,只有更好~
产品类别不管是2B(面向企业)
还是2C(面向个人)
,个人觉得他的质量重点应该有所偏向;
比如说某些团队它本身成熟度就摆在那里,但非要让他把2C
做成2B
的质量要求:
2C
没有2B
质量要求高,而是侧重点不同;2C
可能更偏向于个人使用,用户体验程度和交互设计质量可能有所偏重;2B
的产品量级可能更大,比如性能方面等偏向(猜测)。不能眉毛胡子一把抓,针对不同的产品,质量工作重点应该有所偏向。
关于软件的主体,我们团队更多偏向应用系统的后端+应用系统的前端;
那对我们测试团队来说,我们常用的质量测试手段就是接口测试了;
我看现在比较常用的几个工具和框架为:
Jmeter
、Postman
、Robot Framework
等; Unittest+DDT+Excel+BeautifulReport/HTMLTestRunner+Request
Pytest+Yaml+Allure+Request
针对不同的软件主体,站在测试角度来说,它的质量保障手段可能会存在差异。
这个比较要命,也是直接和质量有关的一个环节;
往往在产品开发过程中,因为客户要求的节点到了,我们就为了赶时间节点,忽略了质量;
这里我们团队的软件平均交付周期是大于3个月的,长的甚至也有几年的,但是不论哪种项目,我们在评估产品交付周期的时候,个人觉得:
另外我觉得项目周期除了以上的参考外,可能需要严格的过程标准规范来约束,比如针对JunPin
我们有详细的标准参考GJB 438B-2009 军用软件开发文档通用要求
:
产品交付周期和很多因素有关,最直接的就是是否有标准化作业过程?
需求质量保障,目前主要是:
目前对团队的需求比较满意,因需求中最值得点赞的是:
需求中遇到的问题,我们目前最大的问题是需求变更频繁,主要表现在:
以上三个问题导致需求变更比较频繁,目前我们的改进是:
需求的质量直接关乎下游开发、测试等环境的质量。需求管理最为重要。
设计质量我们自己的侧重点在架构师的培养方面;
另一方面是在原型(仿真)验证方面下了很大功夫;
还有一个重点是测试人员、“天使客户”也会参与到设计评审;
这里重点说下我们测试是如何做的?
目前体验不太好的一点是功能设计方面,原因是:
设计的质量最好还是专业的人做,其他环节前移到设计工作。比如测试前移至设计评审等工作。
这个就不深入了,因为行业的特殊性,开源用的不多,基本的质量保障手法是:
这个作为测试深有体会,我们常见的因为代码质量导致的测试困扰有:
作为测试我们期望的结果是:缺陷确实分布合理和有效的消除;
code
阶段消灭,避免遗留到客户:代码质量也是直接影响测试、客户对产品体验。
这个指标目前我觉得不太合理,不过CMMI
中有对千行代码缺陷率有描述:
bug数/代码行数*1000
;CMMI
等级与千行代码缺陷率的对照关系:CMMI级 | 千行代码缺陷率 |
---|---|
1级 | 11.95‰ |
2级 | 5.52‰ |
3级 | 2.39‰ |
4级 | 0.92‰ |
5级 | 0.32‰ |
如非不得已,建议取消这个指标。
单元测试代码覆盖率,首先有个疑问,这个活动由谁来做?开发?测试?
至于这个值,目前针对不同的项目有所取舍,行覆盖可以达到90%,哈哈;
测试质量,这个又有的说了:
出了问题,老板第一句“测试是怎么测的?”
项目经理,第一句“这是谁测的?”
产品经理,第一句“你用例覆盖不全~”
是不是有以上相同的场景呢?我们如何保证质量呢,个人观点:
JunPin
软件测试来说,可以参考:GJBZ 20141-2004军用软件测试指南
,里边明确了软件在生命周期内各个阶段的测试方法、过程和准则。有标准的规范要求,我们测试工作也不会跑偏;代码质量尤其重要,测试质量不等于产品质量。
产品设计过程中,我们一定要有质量文化,她就是无形的力量,帮助每个人树立起质量意识;
质量文化不是一句口号那么简单,要融入到产品开发过程中,比如我们需要有严格的绩效考核和质量目标:
HW
的IPD
流程是非常值得学习的,像其中的TR
点的过点要求,其实就是一种质量保障;http://u.uin.com/external/publishInfo.shtml?id=6203&objectType=%CE%C4%D5%C2
我们需要设置专门的质量保障人员QA
,比如在SPP
中项目管理过程域,QA
可能需要全程关注产品生命周期的几个阶段,比如可能涉及的活动为:
我们以独立的部门形式存在,比如测试部或测试中心;
是独立开发之外的,不是归属到开发部门下管理,这样做就是为了形成监督和审查;
测试团队我更倾向的是智能型团队(前边已经提及过)
总之我觉得测试应该以独立的团队存在。不过有些开发模式并不太适合,比如敏捷开发。
目前开展的质量活动是用户体验工程:
功能测试用例数的自动化实现占比已经大于90%了,但是自动化并不是全能的;
优点 | 缺点 |
---|---|
重复执行、频繁操作 | 不能100%替代人工测试 |
模拟手动测试无法覆盖的场景 | 不能达到100%覆盖率 |
利用空闲时间执行 | 需要时间去分析结果 |
释放一部分测试人员精力 | 对软件质量依赖大(前提是软件稳定、改动小等) |
测试结果客观公正 | 需要专业的工程师投入专门的时间开发 |
/ | 投入成本可能会大一些 |
考虑做自动化最主要是清楚它的应用场景:
场景 | 说明 |
---|---|
测试周期 | 项目周期长,轮次较多的软件 |
数据量级 | 需要制造大量的测试数据 |
软件稳定性 | 使用稳定和成熟阶段的产品测试 |
回归测试 | 需要进行简单回归的测试 |
冒烟测试 | 主线功能的冒烟 |
巡检测试 | 线上环境的定期巡检 |
发布验证 | 主线功能的发布验证测试 |
不能盲目做自动化,要从团队、项目、产品等多维度综合考虑,自动化只是一种手段,一种辅助测试的手段。
目前使用的是混合方案(开源或商业第3方工具+自研)
这个不多聊了,感觉自己没资格讲,哈哈哈~
2022质量工作重点:团队人员能力建设(培训)上,因为:
2022质量问题:需求变更太频繁了,这个之前已经提及,不再赘述。
深入学习GJB
相关质量管理体系,并融入项目产品开发;
研究SPP
的四个过程域,有针对性的对部分项目进行试点:
进行团队能力成熟度认证,如CMMI
认证;
进行GJB9001C
质量管理体系学习;
成立测评实验室取得CMA、CNAS
认证等。
质量改进这是个持续的过程,也是一个漫长的过程,急不得。
主要在CI/CD
、以及UI/API
测试专项投入;
精简自动化框架,并覆盖WebUI、Http
接口、WindowsGUI、APP
、小程序等领域;
自动化平台融合,接口+性能+UI
;
自研自动化框架,目的是人人可以用,人人不用写代码;
投入专业的测开工程师或自动化工程师,专人负责;
如果说有能力,我觉得应把自动化技术进行扩展,可以从内部测试、软件测评、测试培训、测试外包方面入手去把技术深化。
对自动化又爱又恨,爱它确实带来了很多方便,恨它对它不了解的人瞎搞自动化。
《我填写“2022年国内软件质量调查问卷”的感想》
,仅仅是个人想法,不代表任何组织、团体;凡涉及“行为、动作、过程、活动等”均会涉及质量,质量无处不在。
所有的问题最终要落到团队、管理、流程、制度上。
质量从组织架构、质量文化、质量体系上进行牵引可能有更好的效果。
质量不等于测试,一个成功的高质量产品的质量,势必是从干系人、到团队、到客户、到公司层面的质量总和。