汽车电子软件测试的脉络

在构思“汽车电子软件测试的脉络”这个主题时,我脑子里先是蹦出来三个词:哲学本质 底层逻辑 

同时转念一想,打算通过一篇文章就想探到如此深度岂非痴心妄想和不知天高地厚。实际上,诸多冠此类帽子的文章多是名不副实。算了,人近不惑,脑力渐衰,把书读薄也更甚于读厚。

不过,读薄的前提至少是要有体系和脉络。所以选用了“脉络”这个词,细想来,确实比前面想到的那三个词更合我真意。

汽车电子软件测试的脉络

在开始这条脉络之前,还是先把概念澄清,以设定一个理解基线。

什么是软件测试?

《软件测试的艺术》的作者梅耶的定义是“软件测试就是为了发现缺陷而运行程序的过程”。

尽管不同的角色在不同的角度都有不同的定义,比如有从需求入手的、有从质量着眼的,也有从一致性、风险和成本等展开的……

各有各的道理,但我从实务的角度看,选用了梅耶的定义,毕竟运行程序发现缺陷是我们日常可见的测试的最显著特点。

好,正式开始。

为了更贴近实际项目运行,我大体按照业务的运行时间线,把这条脉络的一头一尾分别定义为“测试策略”和“测试汇总”。

1、测试策略 

在企业里,我们所做的所有工作,从来不是独立的,也从来不是单一的技术问题或者管理问题,而是需要一个统筹的考虑。

测试也一样,开始之前我们要有“策略”,这是一个High-level的概念,多少有一点模棱两可,很难说清楚其准确内涵,不同干系人也有不同的期望,本文给三个参考的维度,分别是测试规则或指南测试目标测试原则

尽管实际工作中,我们基本无法清晰地拆分出隶属于不同维度的工作,而是相互混杂和渗透,但为了便于沟通和理解,暂且还是按此拆分。

1.1 测试规则或指南

测试规则或指南,我们把它定义为统领性、强制性或推荐性的一些规则、要求或建议,它们一般由公司层面整体定义,并要求执行。

比如,什么节点前应该做测试分析,应该用哪个报告模板,什么测试条目是必测项,测试用例的选择要考虑哪些,测试的准入准出规则是什么,是否必须先完成冒烟测试,什么情况下必须做压力测试,测试覆盖率怎么考虑,测试通过率怎么定义,如何区分不同层次测试的责任人,缺陷的处理方式,测试与需求的追溯性要求,单元测试必须在其他测试前完成,回归测试时测试用例如何选择,自动化测试比例及开始时机怎么定义,必须执行全量测试的标准等等。

会有很多的角度去定义,无法详述。

总之,是一些基于公司策略和历史经验等制定的纲领性的文件。

当然,多数不那么规范的公司不会定义很细,要求也不会很严格,姑且有这么个概念。

1.2 测试目标

测试目标呢,比较宽泛的理解有查找问题、确认满足需求、避免问题泄漏、保证客户满意、提升质量、降低成本、推进持续改善等等。

这些内容虽然并不难理解,但还是太泛泛而谈了。

在具体的某个客户、某个平台、某个项目、某次迭代、某次交付的组合里,会有多方面因素要考虑,这是个复杂的且需要背景信息的事,无法简单说明。

举几个可能需要思考的问题,感性感觉下。

这个客户对测试报告的提交需求是什么?这次上了哪些主要功能点?该平台或该项目是否有历史LLs?已经识别到什么潜在风险需要测试探测吗?内部有什么质量目标?本次交付变更点是什么?自动化测试台架是否可用?这次是工程车间装车,还是台架或者产线?什么功能是本次交付最关注的?是否上路,上什么路……

综合各种信息,项目经理或测试经理可以来统筹判断及调整本次测试的目标,据此再来进行后续的计划、执行等工作。

1.3 测试原则

考试有答题技巧,工作有方法论,打仗有兵法。测试原则差不多等同于这类。在整个和测试相关的工作中,是否有一些参考性的原则呢?

1、要尽可能早地测试。这是质量成本的原则,发现问题越晚,成本和影响越高越大。

2、不可能进行穷举式测试。进行完全的测试是不可能的,完全没有任何缺陷的软件也是不存在的,要根据风险评估进行测试用例设计,进行最佳的测试量定义。

3、关注缺陷群集效应。二八法则我们都听说过,在此也是适用的,少量的模块经常包含大部分缺陷。统计数据也表明,一段程序已发现的缺陷越多,则该段程序发生更多缺陷的可能性也很大.

4、杀虫剂悖论。如果同一个测试人员重复执行相同的测试,该方法将无法发现新的测试缺陷。这既有测试用例更新不及时的原因,也有测试人员的思维定势和思维懈怠的原因。所以测试用例要经常更新,测试人员也可以适时轮换。

5、测试只能证明存在缺陷,而无法证明不存在缺陷。因为测试实际上是一个样本实验,不可能涵盖所有情况。

6、没有缺陷不代表软件一定能够使用。比如测试用例本身未覆盖需求,这其实说明了测试本身的局限性,也说明了我们要进行全方位软件开发及测试管理的必要性。

7、测试最好由非软件开发人员担任。这是从心理学角度来看的,毕竟让一个人否定自己的工作是令人沮丧的,而且如果开发人员对某个功能有错误认识,再去测试可能依旧无法识别。

8、测试顺序。为了尽可能早地合理退出,要首先执行具有较高失败概率的测试。比如,最好依次进行冒烟测试(核心功能预测试)、缺陷重新测试、测试新功能、测试修改或优化的特性、测试未改变的特性(回归测试)。

实际工作中,策略更多是在项目经理或测试经理脑子里的整体谋篇布局,以上三个维度是落于纸面上的一个参考。

2、测试管理

有个通盘的策略性考量后,就可以进入管理层面的工作上了。

接下来看测试管理。

当组织结构庞大和软硬件功能复杂时,测试也同样会变得很复杂和容易混乱。

这时,就非常需要由专门的人按照特有的流程进行组织和管理。管理的范畴很大,为了避免描述混杂在一起,我们这里只谈小管理,不涉及具体工程层面的内容。

我们可以将测试管理的目标定义为:根据确定的测试范围,交付与测试相关的工作包(例如,测试规范、测试执行、评审和报告等),同时还要满足项目进度计划中定义的里程碑节点。

上一页123下一页


留言