关于嵌入式系统的自动化测试工具的几点看法

婧颦

在过去二年半里，我主要从事收款机的测试工作，由刚入门的手工测试，到对自动化测试的需求中，我曾经尝试过寻找好的测试工具，但是，后来，由于各种原因，我还是将眼光投向我们的开发人员身上。
在收款机的测试中，除基本功能测试外，最重要的就是PLU链和电子日子链，这两大块的测试，而针对这两条链他们有很多关联之处，也存在一个问题，就是压力测试，如何让自己轻松的实现对这两条链的测试呢？
刚开始，我们测试组想到了用设置条码的自动销售模式来进行，后来，觉得这样还不够，我们又想到让开发人员为我们做一个自动销售软件，只是一个小小的软件，就解脱了我们手中的重复工作，而且，也实现了这两条链的压力测试，测出了许多致命问题，让我们的产品在数据保存方面更加可靠！
但是，后来，我们觉得回归测试也是一个非常重要的测试，因为，我们知道，当bug A解决之后，会由于开发者修改问题而导致另一个bug，或者更多bug，如何在有限的测试时间里，用最短的时间完成回归测试，又成了我心里的一个问题。在开发部经理的帮助下，我们又一次实现的整个收款机的自动化回归测试，保证最基本的正常功能测试。
现在，离开了原来的公司，但心里依然还有许多东西放不下，在对自动化测试的一般了解下，我知道用自创的自动化测试工具来测试本公司的产品，也会隐藏着某些危机，我甚至在想，如何看待嵌入式系统的自动化测试工具？
我个人觉得，嵌入式系统的自动化测试工具，应该做得比较小，主要针对某个重要模块进行测试，因为只有小的软件，它所存在的bug才不会影响到测试的可靠性。
但是，在关于回归测试这一方面，我始终有种莫名的担忧，有些东西一直想不明白，在规定统一的数据库中对系统进行自动化回归测试，会不会因为在编写例子欠缺而出现遗漏，在进行完回归测试后，我们还应该注意些什么？

[ Last edited by 婧颦 on 2005-8-13 at 11:49 ]

addvalue

工具不能用来解放人的工作，只是帮助提高效率。进行回归测试后将回归测试用例维护好，甚至增强至功能测试用例基线库中，同时还应该再考虑站在用户的立场上考虑他们实际使用的习惯（易用性或同类产品对比）

addvalue

由于程序的复杂性，各个模块及元素（变量、函数、类）之间存在着相互关联性，所以对于改正的错误，还要进行再测试。一方面检查此错误是否真的修改了，另一方面检查此错误的修改是否引入新的错误，这就需要将测过的测试用例拿来重新进行测试，这就是回归测试。
     回归测试可以应用于软件测试和软件维护阶段，用来验证错误修改情况，这称为改错性回归测试；同时在软件的增量式开发过程中，通过重测已有的测试用例和设计新的测试用例，来测试改动（增加或删除）的程序，这称为增量性回归测试。
     回归测试在重用已有的测试用例时，有两种方案：一是完全回归测试；另一种方法是选择性回归测试。采用选择性的方法，会大大减少时间和人员的开销，同时又能保证系统的质量。其中Rothermel的选择性回归测试方法总结的最具代表性，可查询相关专著

婧颦

好的，谢谢！
其实，我在这里说的用自动化测试软件做回归测试是已经完成了核对已修改的bug的测试工作，到了确定软件质量基本稳定，已经准备颁布了的时候，做的最后一次基本功能过一遍的回归测试，是回归测试的最后阶段吧。

deadpuppet

或许我没什么发言权，但我认为自动化测试在嵌入式领域的空白还是太多了
嵌入式软件产品大多依附于各种硬件的平台
而测试只能进行在模拟出的PC机上进行
拿功能验证来说，如果测试一些时机性的问题，就无法用工具实现
而性能测试、对内存进行监测，又无从谈起，真是郁闷

婧颦

如果进行测试时，测试的产品可以与PC机存在通讯的联系的话，那么也可以尝试使用一些外助的好的性能工具进行监控，如：串口调试工具啦，还有一个常用工具，不记得它的名字了。呵呵

飞的姿态

不错 受教 Thank U!

chehvyin

lz 说得很是，我也还是在探索， 学习中，有机会可以交流一下？

skype:moonno.1

qq:112082606 （需注明）

muerte

原帖由 婧颦 于 2005-8-13 11:43 发表
在过去二年半里，我主要从事收款机的测试工作，由刚入门的手工测试，到对自动化测试的需求中，我曾经尝试过寻找好的测试工具，但是，后来，由于各种原因，我还是将眼光投向我们的开发人员身上。
在收款机的测试中， ...

每个测试人员,都会有这样的经历,担心漏测一些东西,其实,这主要是你前期工作没有准备充分

jinux

刚刚进入这一行  也没有人带只能靠自己慢慢摸索 很辛苦

lovetestingszw

summy911

嵌入式软件可以使用的一些自动化测试工具需要了解，现在还是比较迷茫啊