闲谈汽车软件测试.docVIP

闲谈汽车软件测试 因为供应商赶工期，软件释放前缺少自测环节，导致功能严重失效问题暴露到验收测试处。验收测试收到新功能软件版本后，即按照全量测试的方式测试，测到一半发现软件的许多关键功能不ok，而这时已经投入了较多的人力成本；或者，对bug修复部分功能做复测，发现原bug功能已修复后，再执行全量测试，结果测到一半，原本正常的关键功能，现在不正常了。 软件肯定是不能用的，已经投入的大量测试时间和人力就打了水漂。毕竟智能件动辄几千的测试case可不是随便闹着玩的。 在普遍赶工期的新能源车企里，我赶脚这种情况不是个例。 软件工程里有自成体系的测试方法论，但从传统汽车模式转型SDV汽车模式的过渡中，很多软件工程的方法论都还没有为汽车人所用。 比如，上面举的这个例子。后面的解决办法是，我和测试人员一起制定了功能验收测试的快速点检表。从模块化的功能里提取关键的测试用例case。这个case如果能跑通，则基本说明这个模块的功能是正常的。例如，测试BLE近场车控，从中选择了功能较为复杂的虚拟钥匙权限释放。 而在对这部分再进行深入了解后，发现这些问题完全是可以借助软件工程的标准测试流程规避的。我所谓的 “功能快速点检表”，其实就是冒烟测试用例。 类似地，还有常常出现在软件供应商或来自互联网公司同事嘴里常常蹦出来的增量测试、回归测试，增量回归测试、全量回归测试等等。 本着尽量把知识系统化的原则，我对这些行话做了些功课。整理成文，供自己常看常新，也给相关领域的朋友做抛砖引玉之用。 首先是两个关键的行话：冒烟测试、回归测试。 冒烟测试 使用场景： 冒烟测试原本是硬件测试的行话，后来引入到软件测试中，是指，完成一个新版本的开发后，先投入较少的人力和时间，对该版本最基本/核心的功能进行测试，保证基本/核心的功能和流程能走通。如果不通过，则打回开发那边重新开发；如果通过测试，才会进行下一步的测试(功能测试，集成测试，系统测试等等)。 冒烟测试理论上是要由测试人员做。但这样无法约束开发代码人员的发版质量，所以现在一般让开发代码人员做。跑通了基本/核心功能后，再提交测试人员后续测试。 优缺点： 冒烟测试的优点是节省测试时间。缺点是用例覆盖率比较低。 解决办法： 开发与测试人员充分沟通，利用冒烟的优势特点，制定合适的冒烟用例。使其既可作为版本的快速校验工具，管控提测版本质量；也可以在紧急发版的客观要求下，作为软件发版的测试用例，点检关键功能。 像我上面所述的“功能快速点检表”，就可以视为冒烟测试用例。 回归测试 回归测试主要是指修改旧代码修复bug后，重新进行测试，以确认修改有没有生效，或者有没有引进新的错误。回归测试可以分为增量回归测试（选择性回归测试）和全量回归测试。? 1、增量回归测试 定义： 新增功能开发完成，或bug修复后，回归测试时，只针对新增功能或出现问题的这些功能进行验证，没有涉及到的功能就不进行测试。 优缺点： 重点测试修改的功能，节约时间和人力成本。但非常容易出现bug修改后，潜在的关联功能可能从正常变为失效，而导致测试遗漏。 解决办法： (1)?? 前期功能充分沟通，测试用例备注关联模块。 前期在开发和测试人员功能分析时，需要充分沟通，了解功能/函数之间调用关系，了解可能的关联项。并在测试用例中注明关联项。 (2)?? 开发人员主动注明。 最了解功能之间关联项的是开发人员。因此开发人员在新增功能或修复bug时，务必注明，这个bug是由什么原因引起的、bug修复的逻辑，以及可能会对关联功能产生的影响。小小举动，事半功倍。 （3）关键功能测试。 虽然，分析下来，有些关键功能跟本次的修改没有直接关联，但出于保险起见，关键功能最好也趟一遍测试用例。因为这是用户权重占比较高的功能，一旦失效，影响会比较大。 （4）主观把控。 在测试和开发人员的长期拉锯中，对对方的能力水平心里大概都有了数。好的开发修改缺陷时，关联功能会直接就改好，提测的bug修复版本不会出现按下葫芦浮起瓢的情况。而部分能力不足的人员可能考虑的较少，解起bug来顾头不顾腚。那对于这种总会出现2次bug的开发，测试人员就要加大测试力度，如果时间充裕的话可能要对整个模块进行回归。? 2、全量回归测试 定义： 字面意思，不管之前查出多少个问题，提测后，所有功能，全，都，测，试。 优缺点： 全都测试的优点是对所有功能进行验证，尽最大可能地确保系统没有问题。缺点也显而易见，测试人力、时间成本大大提高。动辄三千多的台架测试用例，一千多的实车用例，认认真真干一遍，没个两三周下不来。? 而且，长期反复全量回归还涉及到测试心理学问题：随着测试的不断迭代，测试的心理会发生变化，从“捉虫式”测试，逐渐变成了“无罪证明式”测试。? 解决办法： （1）充分利用冒烟测试、增量测试，降低全量回归测试次数； （2）面对不