什么时候，你会想起好好做软件测试

辛昕

什么时候，你会想起好好做软件测试 [复制链接]

为什么要软件测试——最直白的解释就是

“测试一下我们的软件代码是否如我们所愿做了我们预期的事情”。[/quote]
但是，一大堆高大上的书和网上论坛的海谈神侃，会告诉我们

其实真正的软件测试，有更多的目的[/quote]
    1.什么”软件测试不是为了证明程序是对的，而是为了发现程序是错的“了
        （《软件测试的艺术》）
    2.还是什么 ”软件测试是为了验收项目已经做完可以交付了“
       （大多数时候我们都是为了这个做测试）
   ........

        对软件测试，同样有两种很极端的态度：

1.是很直白很简单，就是只要程序下载进去，能实现当前在做的预期功能就行了。

        发现LED亮了，发现按键按了，灯亮了，或者给串口发一个0xe3,然后它回复一个 0x1d（取反回复）就可以了。
         ——结果很可能的情形就是，但有人乱按，同时按按键的时候，灯要么不亮，要么瞎亮成了一片。
[quote]2.另一种就是非常高大上

         什么 条件覆盖啊，什么白盒黑盒测试啊，最后扯了半天，也没见他怎么把 测试用例 做出来，就更别说什么天天测试了，可能他一个一个按键测试，         还要组合试试，什么两个按键一起按，三个按键一起按之类的组合。
      ——这结果很可能就是他最后一天都不愿意重复一次测试，因为太累了。
纠结和解脱
        其实 关于软件测试 这个话题纠缠了我很久（将近三年）。也看了一些书，结果经常是理论上是非常高大上，但实际干的却是非常大白菜的事情，这种巨大的落差经常让我非常痛苦，纠结不已。后来我渐渐在实践中吸取了一些经验，并采用了一些折中的方案。
       最近，我要对工作的一个项目的软件做一个比较系统的测试方案设计，我蓦然想起了我纠结了很久的测试问题，还有那些我看过的书，于是我打算从务实的角度重新整理这个话题。
这次我不想发表长篇大论
       我不想再罗罗嗦嗦一个人写一大堆心得体会，也不想收到什么
[quote]写得很好，很有启发 之类的没太大意义的回复。

     所以我想把问题分开一个一个做成投票，看看你们在这些具体的软件测试有关的问题上，都是怎么想的，怎么做的。

谢谢你们的投票，但更期待你们写下你们的具体实例，简洁点几行字都可以啊啊
      今晚太晚了，我就不具体写这九个选项中的更具体的事例，但我随后会补充。

ienglgge

我觉得第四条还是写的还是不错的。尤其是经常面对一大堆项目的时候。本来是别人做的东西，突然给你来做。而且短时间就要结果，这往往是很无奈的。为了保证稳定性。对于需要修改的部分，就要做充分的分析，可是，发现思路，逻辑什么的很复杂，很奇怪。很别扭，改的话，动大手术。就很容易牵扯到其他的东西，要对牵扯的东西，再进行充分验证。就算能验证通过，时间也不允许啊。结果，往往就是，别扭着呆着，凑合着改。尽量少改。没把握的地方尽量不碰。功能出来了。大概测了几下。没事。先这么着吧。哪有那么多时间在这耗啊。

ljj3166

甲方的诉求

辛昕

ienglgge 发表于 2015-3-17 01:36
我觉得第四条还是写的还是不错的。尤其是经常面对一大堆项目的时候。本来是别人做的东西，突然给你来做。而且短时间就要结果，这往往是很无奈的。为了保证稳定性。对于需要修改的部分，就要做充分的分析，可是，发现思路，逻辑什么的很复杂，很奇怪。很别扭，改的话，动大手术。就很容易牵扯到其他的东西，要对牵扯的东西，再进行充分验证。就算能验证通过，时间也不允许啊。结果，往往就是，别扭着呆着，凑合着改。尽量少改。没把握的地方尽量不碰。功能出来了。大概测了几下。没事。先这么着吧。哪有那么多时间在这耗啊。

是的，这种操蛋的情况我也经常碰到。
这其中包括修改一些ti st之类的半导体厂商的例程

白丁

不得不承认自己是个非常粗心的人，我坚信我写的代码没有一开始就正确的，上板调试太费时了，但是单纯用软件来进行测试就方便多了，以后出了问题还可以接着用来测试debug， 写测试例程对我有两个作用，验证我的功能或者稳定性可靠性，再有就是便于debug，两者殊途同归吧

辛昕

白丁 发表于 2015-3-18 21:50
不得不承认自己是个非常粗心的人，我坚信我写的代码没有一开始就正确的，上板调试太费时了，但是单纯用软件来进行测试就方便多了，以后出了问题还可以接着用来测试debug， 写测试例程对我有两个作用，验证我的功能或者稳定性可靠性，再有就是便于debug，两者殊途同归吧

是的，这涉及我接下来会提到的一个很重要的和 软件测试 有关的主题。


那就是区分 那些开发过程中debug性质，验证性质 的一次性测试。

比如查看某个中间函数的返回结果是否你期待的。



这种测试用完一次就丢，却不能等同于assert.



而另一种测试，则比如为了验证某个子模块的运行结果是否一直合理或者正确，这种测试需要不间断热机测试，很可能是白天开发，晚上下班就让它一直开着跑测试。

这种测试属于自动测试，或者说如果不做成自动测试是根本没法进行的。



因为有些bug和 铝这类金属具有 时延性 一样，不热机跑个几天是不会出来的。



我第一份工作，2012年7月份，我做了一年左右的一个1W行左右的项目正式完工，接下去的时间就是不断细节修改和写文档，同时是每天不分昼夜的热机测试，我还试过有些bug一个月左右才暴露出来的。

而这种bug一旦暴露，也将是最噩梦的bug,没有之一，相信我。



为了捕捉这种bug,你除了自动测试，还需要用各类条件,trap以及一套强大的 打印工具，布下天罗地网......

我记得当时我那个程序里有各类判断和数据运算，还有我那时候非常不成熟的编程经验，结果我给自己埋了N个地雷。

其中一个是涉及一个不断计算，累加的关键数据，那个错误我当时至少追查了两个月才彻底端掉。



当时我每天干的事就是 对着电脑，看用电脑打印出来，然后被我用ultraedit整理过的数据，一屏一屏的，19寸的显示屏都是数据行，后来发展到利用 格式控制符 控制格式，否则我根本没法看.......

那种感觉超像 好莱坞大片里某些神秘基地里看起来非常高大上的事情，有个人拍了张照片放在网上，结果我朋友都以为我在干什么机密工作.......



这看起来很酷吧，但相信我，那是我有史以来最怕调试的一段经历。

辛昕

@soso
姐，我这个帖子最大的意外就是你居然投票了。

所以说，你转行前是做软件测试的吧？？

白丁

辛昕 发表于 2015-3-18 23:29
是的，这涉及我接下来会提到的一个很重要的和 软件测试 有关的主题。


那就是区分 那些开发过程中debug性质，验证性质 的一次性测试。

比如查看某个中间函数的返回结果是否你期待的。



这种测试用完一次就丢，却不能等同于assert.



而另一种测试，则比如为了验证某个子模块的运行结果是否一直合理或者正确，这种测试需要不间断热机测试，很可能是白天开发，晚上下班就让它一直开着跑测试。

这种测试属于自动测试，或者说如果不做成自动测试是根本没法进行的。



因为有些bug和 铝这类金属具有 时延性 一样，不热机跑个几天是不会出来的。



我第一份工作，2012年7月份，我做了一年左右的一个1W行左右的项目正式完工，接下去的时间就是不断细节修改和写文档，同时是每天不分昼夜的热机测试，我还试过有些bug一个月左右才暴露出来的。

而这种bug一旦暴露，也将是最噩梦的bug,没有之一，相信我。



为了捕捉这种bug,你除了自动测试，还需要用各类条件,trap以及一套强大的 打印工具，布下天罗地网......

我记得当时我那个程序里有各类判断和数据运算，还有我那时候非常不成熟的编程经验，结果我给自己埋了N个地雷。

其中一个是涉及一个不断计算，累加的关键数据，那个错误我当时至少追查了两个月才彻底端掉。



当时我每天干的事就是 对着电脑，看用电脑打印出来，然后被我用ultraedit整理过的数据，一屏一屏的，19寸的显示屏都是数据行，后来发展到利用 格式控制符 控制格式，否则我根本没法看.......

那种感觉超像 好莱坞大片里某些神秘基地里看起来非常高大上的事情，有个人拍了张照片放在网上，结果我朋友都以为我在干什么机密工作.......



这看起来很酷吧，但相信我，那是我有史以来最怕调试的一段经历。

自动化测试也是debug的需要啊，我们常用的是软件仿真，自己搭建的环境，找出一些逻辑上的bug，上板跑测试追bug太难了，加打印一遍一遍复现，面对打印结果vim和beyond compare是很好用的工具，简直就是神器

辛昕

白丁 发表于 2015-3-18 21:50
不得不承认自己是个非常粗心的人，我坚信我写的代码没有一开始就正确的，上板调试太费时了，但是单纯用软件来进行测试就方便多了，以后出了问题还可以接着用来测试debug， 写测试例程对我有两个作用，验证我的功能或者稳定性可靠性，再有就是便于debug，两者殊途同归吧

另外，这里其实涉及一个问题。
你说得很对。直接上硬件调试，一般都很麻烦，而且通常有些测试是没办法做的。



比如你如何能短时间或者自动产生一堆硬件动作去触发穷举测试？



这个时候，软件模拟就会方便许多。



而说起来，所谓硬件，从软件层面的角度来看，无非就是把 硬件外设 视为外部存储器，通过内存映射的方法，或者说 做成 测试桩 的方式，用数据trap程序
.......



这种情况下，你可以做很多实际硬件可能根本没法进行，或者原来可能需要一年，好多人，很多套硬件同时进行的测试，现在通过数据，你可以在一个小时内，而可能连一个人都不需要就可以进行。



这看起来非常诱人。

但是后来我发现这样也有一些麻烦。



那就是，一般来说，测试一个独立模块，除非它是在最底层上的硬件动作，或者是最上层的应用主调发生。

否则在这中间的任何过程，你都需要构造一个它下层给它提供输入的激励源，同时，构造一个在它之上调用它的主调方。

这种情况下，有时，在 自上而下的 的原型迭代或者自下而上的尝试 的时候，这个为测试准备的 调用环境 或者 数据桩 ，会显得特别花费时间和精力，而最后一旦真实下层激励源和 上层调用 完成，这些都将一无是处，是很大的浪费。



所以在这种时候，就要考虑，干脆直接提供 输入源 和 主调环境 更好。

soso

辛昕 发表于 2015-3-18 23:32
@soso
姐，我这个帖子最大的意外就是你居然投票了。

所以说，你转行前是做软件测试的吧？？

亲爱的 @辛昕   ，昨天在查看积分规则，想起你的是投票帖，所以就试一下