5,227
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
ariesduan 2003-06-18
- 打赏
- 举报
冒烟测试并不是一个方法，冒烟没什么重要的意义，重点应落在测试上。
冒烟测试总是和日创建向联系的，它们组合在一起，就是每天将开发的成果进行创建，并对创建的成果进行测试，单独谈冒烟测试没有什么意义。
冒烟测试总是和日创建向联系的，它们组合在一起，就是每天将开发的成果进行创建，并对创建的成果进行测试，单独谈冒烟测试没有什么意义。
xmzhy 2003-06-02
- 打赏
- 举报
谢谢大家！
xiaolongnv 2003-05-26
- 打赏
- 举报
google 来的，不要笑我。
a relatively simple check to see whether the product "smokes" when it runs.
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
A common practice at Microsoft and some other shrink-wrap software companies is the "daily build and smoke test" process. Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a "smoke test," a relatively simple check to see whether the product "smokes" when it runs.
It minimizes integration risk. One of the greatest risks that a team project faces is that, when the different team members combine or "integrate" the code they have been working on separately, the resulting composite code does not work well. Depending on how late in the project the incompatibility is discovered, debugging might take longer than it would have if integration had occurred earlier, program interfaces might have to be changed, or major parts of the system might have to be redesigned and reimplemented. In extreme cases, integration errors have caused projects to be cancelled. The daily build and smoke test process keeps integration errors small and manageable, and it prevents runaway integration problems.
It reduces the risk of low quality. Related to the risk of unsuccessful or problematic integration is the risk of low quality. By minimally smoke-testing all the code daily, quality problems are prevented from taking control of the project. You bring the system to a known, good state, and then you keep it there. You simply don't allow it to deteriorate to the point where time-consuming quality problems can occur.
a relatively simple check to see whether the product "smokes" when it runs.
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
A common practice at Microsoft and some other shrink-wrap software companies is the "daily build and smoke test" process. Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a "smoke test," a relatively simple check to see whether the product "smokes" when it runs.
It minimizes integration risk. One of the greatest risks that a team project faces is that, when the different team members combine or "integrate" the code they have been working on separately, the resulting composite code does not work well. Depending on how late in the project the incompatibility is discovered, debugging might take longer than it would have if integration had occurred earlier, program interfaces might have to be changed, or major parts of the system might have to be redesigned and reimplemented. In extreme cases, integration errors have caused projects to be cancelled. The daily build and smoke test process keeps integration errors small and manageable, and it prevents runaway integration problems.
It reduces the risk of low quality. Related to the risk of unsuccessful or problematic integration is the risk of low quality. By minimally smoke-testing all the code daily, quality problems are prevented from taking control of the project. You bring the system to a known, good state, and then you keep it there. You simply don't allow it to deteriorate to the point where time-consuming quality problems can occur.
xiaolongnv 2003-05-26
- 打赏
- 举报
smoking test 和acceptance test有什么区别？
说一点个人的看法,不一定对.
smoking test:是有重点的测试,不一定全面.acceptance test全面测试,测试通过,就基本满足了用户的软件需求.
说一点个人的看法,不一定对.
smoking test:是有重点的测试,不一定全面.acceptance test全面测试,测试通过,就基本满足了用户的软件需求.
jasonfu2001 2003-05-25
- 打赏
- 举报
有个问题，smoking test 和acceptance test有什么区别？
xiaolongnv 2003-05-23
- 打赏
- 举报
戴维 和 Rewen(网络变量)说的好像都有道理
在实际操作过程中，我们的测试人员用的冒烟测试的叫法，就是Rewen(网络变量)描述的那个过程。冒烟测试不通过，就PASS了。
但是，我问了一个在美国做过测试的JJ，他说的冒烟测试，和戴维 描述的是一致的。就是，加了新的功能，或者FIX BUGS 后，先有重点地测试一下，修改部分附近的功能，通过之后，再做全面测试，否则PASS。
在实际操作过程中，我们的测试人员用的冒烟测试的叫法，就是Rewen(网络变量)描述的那个过程。冒烟测试不通过，就PASS了。
但是，我问了一个在美国做过测试的JJ，他说的冒烟测试，和戴维 描述的是一致的。就是，加了新的功能，或者FIX BUGS 后，先有重点地测试一下，修改部分附近的功能，通过之后，再做全面测试，否则PASS。
小猫姐 2003-05-23
- 打赏
- 举报
第一次听说呢，请问一下，是不是跟写第一个程序“hello,world" 意思是一样的呢？
就是写一个简单的测试程序？
就是写一个简单的测试程序？
lsf82 2003-05-21
- 打赏
- 举报
就是装机器的时候，其他都全了，就缺cpu了，小二到场子里面找货去了
你闲着无聊，手痒，按了电源－这就是冒烟测试了
要是主板能起来，或者bb叫，就是好的
要是冒了烟糊了就是坏的
简单吧
---------------------------------------------
呵呵，好玩。
但是没有CPU如果还会BB叫，那就有问题了
你闲着无聊，手痒，按了电源－这就是冒烟测试了
要是主板能起来，或者bb叫，就是好的
要是冒了烟糊了就是坏的
简单吧
---------------------------------------------
呵呵，好玩。
但是没有CPU如果还会BB叫，那就有问题了
xmzhy 2003-05-21
- 打赏
- 举报
我就是看了微软公司的测试才提的问题！
iceage2000 2003-05-21
- 打赏
- 举报
打开开关让软件运行，看它是否会“冒烟” :)
lu123 2003-05-20
- 打赏
- 举报
冒烟测试要跟日创建联系，微软公司的测试可以了解一下!
mis98ZB 2003-05-20
- 打赏
- 举报
通常情况下就是疏通的意思。
taoyubao 2003-05-15
- 打赏
- 举报
可以看看以前的帖 这个问题我以前提过..
xmzhy 2003-05-15
- 打赏
- 举报
谢谢大家的答复！
longlonger 2003-05-14
- 打赏
- 举报
up
ripper 2003-05-14
- 打赏
- 举报
回忆起来《快速软件开发》里面提到了冒烟测试，大家可以去看看。
冒烟测试和每日创建用处不小。
冒烟测试和每日创建用处不小。
ripper 2003-05-14
- 打赏
- 举报
谈谈冒烟测试进行的时机吧
是不是一般都在Daily Build完成以后做呢？
是不是一般都在Daily Build完成以后做呢？
ripper 2003-05-13
- 打赏
- 举报
就是装机器的时候，其他都全了，就缺cpu了，小二到场子里面找货去了
你闲着无聊，手痒，按了电源－这就是冒烟测试了
要是主板能起来，或者bb叫，就是好的
要是冒了烟糊了就是坏的
简单吧
你闲着无聊，手痒，按了电源－这就是冒烟测试了
要是主板能起来，或者bb叫，就是好的
要是冒了烟糊了就是坏的
简单吧
zqy1999 2003-05-13
- 打赏
- 举报
冒烟测试就是在一轮测试之前，制定几个用例，用来操作一下应用程序的主要功能，看是否正常，以决定能否进行测试。
因为如果简单操作应用程序的主要功能都出现问题的话，就没必要耗费精力进行严格的一轮测试了，而是应该让开发人员完善后再来进行正规测试。
这和我们去组装电脑时，要让主要部件“亮”一下是一个道理。
因为如果简单操作应用程序的主要功能都出现问题的话，就没必要耗费精力进行严格的一轮测试了，而是应该让开发人员完善后再来进行正规测试。
这和我们去组装电脑时，要让主要部件“亮”一下是一个道理。
eman1 2003-05-13
- 打赏
- 举报
up！
加载更多回复（14）
