冒烟测试用例该如何设计？
冒烟测试用例该如何设计？正确的数据流得出正确的期望结果？ 冒烟测试准则
在软件中，“冒烟测试”这一术语描述的是在将代码更改签入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。
注意：“冒烟测试”这一术语源自硬件行业。该术语源于此做法：对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。
下面的准则描述了冒烟测试的最佳做法。遵循准则的效果会有很大的不同，从增强团队成员之间的交流，到形成特定的使用测试和调试工具的方式等。
与开发人员协同工作
由于冒烟测试特别关注更改过的代码，因此必须与编写代码的开发人员协同工作。必须了解以下内容：
· 代码中进行了什么更改。若要理解该更改，必须理解使用的技术；开发人员可以提供相关说明。
· 更改对功能有何影响。
· 更改对各组件的依存关系有何影响。
在进行冒烟测试前检查代码
在运行冒烟测试前，进行侧重于代码中的所有更改的代码检查。代码检查是验证代码质量并确保代码无缺陷和错误的最有效、最经济的方法。冒烟测试确保通过代码检查或风险评估标识的主要的关键区域或薄弱区域已通过验证，因为如果失败，测试就无法继续。
在干净的调试版本中安装私有二进制文件
由于冒烟测试必须侧重于仅对更新后的二进制文件中的功能更改进行验证，所以必须通过使用被测试文件的调试二进制文件来使测试在干净的测试环境中运行。
注意
在冒烟测试中，使用不匹配的二进制文件进行测试是一个常见错误。为了避免此错误，当两个或多个更新后的二进制文件之间存在依赖项时，请在测试版本中包括所有更新后的二进制文件。否则，测试的结果可能无效。 同意楼上的
还有就是觉得冒烟测试没有必要设计测试用例
看一下软件的主要流程能不能走通，还有就是不会出现严重的BUG，例如点到什么按钮，或是某个页面程序死掉等
[ 本帖最后由 yetties2005 于 2009-2-10 15:31 编辑 ] 谢谢2楼的详细解答。
TO：yetties2005我整理一下冒烟测试用例的设计：
（举个web的测试）
1、各个权限用户是否能够正常登陆系统
2、仅设置一个登陆比较频繁的权限用户登陆后，各个页面的功能是否正常（增、删、查、改）
3、整个系统的流程是否能正确跑通（用一个数据流跑下来）
各位看看有没有需要补充的地方？ 顶上来，让大侠们多给点建议。 2楼的精髓。
新人报道
支持 学习了，冒烟测试，感觉不错，可以借鉴，因为最近的一个项目需求不是很明确，可以试试这中方法 学习了 ！！谢谢。冒烟测试
冒烟测试一般不会设计测试用例，只是把相关的测试功能列出，重点需要测试哪些功能？哪些功能做了修改，但是保持主流程能够通过就可以了。 冒烟测试=关键功能测试 学习中很受用 原帖由 yetties2005 于 2009-2-10 15:29 发表 http://bbs.51testing.com/images/common/back.gif
同意楼上的
还有就是觉得冒烟测试没有必要设计测试用例
看一下软件的主要流程能不能走通，还有就是不会出现严重的BUG，例如点到什么按钮，或是某个页面程序死掉等
反对，冒烟测试是一定要有测试用例的，就我所在的项目中是用checklist管理的，把各个系统的主要功能点列出来进行测试，checklist中的检查点都是从测试用例中提取出来的主要功能点。如果没有用例就不无法跟踪客掌握整个冒烟测试的重点，以及各个版本之间的冒烟对比。
冒烟测试是对整个项目，那么就有两个大的方向,1.已经稳定的系统 2.新增的系统
另外，冒烟测试中能够自动化的部分，如较稳定的系统用自动化，新增功能可以人工冒烟
如果不具备自动化的条件，那就只能人工冒烟 来学习的 以前听说过冒烟测试一直没用过 谢谢各位大侠的建议，受益匪浅。
页:
[1]
