近的工作需要经常和测试打交道,但我并非这个细分领域的行家,看着几千条测试用例和五花八门的测试设备与工具,以及工程师展示的繁复曲线与图表,着实有些眼花缭乱,没太看懂,不由得陷入了深深的思索...... 1 T型人才与焦利氏称 陷入思索有两个原因:一是确实没跟上节奏,只能佯装沉思,以掩饰尴尬,保持风度;二是汽车领域的知识太多了,没能力是一说,但也实在没必要事事跟上节奏,守好自己碗里的饭就不错了。 可是,我们不是要构建T型知识结构,成为综合性人才嘛。那怎么办呢? 写到这里,想到多年前的大学物理实验课,绝大多数课意料之内陆忘得干干净净,但倒是记住了一堂——焦利氏称,原因是老师说的一句话,“话我照讲,实验你们照做,但你们多年后肯定记不住我们今天做了什么,只要记住一点,焦利氏称是测微小力的......”老师的反向操作倒也是6,不肖弟子把老师是谁都忘了,还记着这句话。 这堂课的这部分,于我,是最有价值的内容,但凡我遇到测微小力的场景,我就可以快速收集整理焦利氏称的信息......否则,这么冷门的东西有几个人晓得呢? 回到我们的T型人才,这涉及一个知识结构搭建的问题,我们得把T这一横里的那些原则性、策略性、共性的东西提炼出来,完善自己的知识和认知框架,细节嘛,择需而取。 下面开始正题,概要讲几个ECU测试的小点。 2 系统与软件测试的区别 在ECU开发测试中,通常会把二者区分开来,我们从以下几个角度来看差异点:
3 测试的次序 最好呢,从V模型的最底层按次序逐层测上来,但最好的东西一般不容易得到,我们基本没有那么多时间来进行这样的瀑布式开发。 所以得考虑一些大的原则,然后,适当地并行。
4 测试准入条件 测试并不是想测就能测的,需要达到一定的条件才能交给测试团队,这就是测试准入条件。这些规则对于大团队协作非常重要。
5 测试准出条件 测试不是想来就来,也不是想走就走的,我们还需要准出条件。 准出其实是有两层含义的,第一层是正常结束,第二层是异常终止。 5.1 正常结束 一般,我们要同时满足以下条件,才可进行正常结束。
5.2 异常终止 除了流程强制外,终止的大部分原因是考虑到成本与时间,有些情况下,测试没必要继续进行。
6 测试用例的选择 开始测试之前,我们多数会有一个测试用例库,每版本都全测自然是带来高成本和长周期,因此,用例是需要被选择的,也就是我们总说的Delta测试。
除了Delta测试,全功能测试的策略也应被制定出来,比如,一年至少一次全功能,SOP前完成一次全功能,平台软件升级后进行一次全功能,发版超过5版之后进行一次全功能,硬件有变化时要进行一次全功能...... 7 测试管理 测试是一项复杂冗长的工作,必要的管理是必要的。 7.1 测试管理 测试管理的目标是,根据测试计划获取相应的测试交付物(例如,测试规范、测试执行、测试报告、测试评审、缺陷提交等),并且要保证交付能满足项目进度中定义的里程碑。 7.2 测试资源 交付物能够及时获取的一个大前提是测试资源能够得到满足,而测试资源包括人员的能力、测试设备、测试样件等。 7.3 测试调度 为了尽早确定可能的退出条件,必须首先执行失败概率更高的测试,比如,依次按照以下次序进行。
7.4 测试计划和监控 基于项目进度要求以及“测试评估”和“测试调度”的结果,我们就能够给出测试阶段完成的截止日期,从而得出详细的计划。 计划所需的详细程度取决于项目的复杂性和所涉及的测试人员的数量。 8 双向追溯性和测试覆盖率 每一条系统或软件的可测试需求都需要被至少一个测试用例强制覆盖。为了检查测试覆盖率,测试报告、测试规范和相应需求之间的可追溯性可借助相应的需求覆盖率工具,如Reqtify。 如果测试覆盖不完整,则需要将信息暴露给项目层面,并完成风险评估与偏差许可。 9 写在最后 测试是个非常庞杂的课题,值得反复研究,限于精力与时间,本文简单总结,点到为止。 另外,以前也写过一篇测试相关的文章——《汽车电子软件测试的“脉络”》,有兴趣的读者,也可以结合着看。 完 end |
|
来自: yuxiao2832 > 《测试》