测试流程 典型
1、测试人员要需要何时参加需求分析？原则上，测试人员对需求了解得越深入对测试工作越有利，所以最好一开始就应该参加
需求分析工作。这样可以带来如下得好处：
测试人员全程参与需求分析，对需求了解很深刻，减少了很多与开发人员的交互，
节省了时间。测试人员参与前期开发讨论，直接掌握了不清晰的需求点；
早期确定测试用例的编写思路，为测试打好了基础；
可以获取一些测试数据，为测试用力设计提供帮助；
可以发现需求不合理的地方，降低了测试成本。
测试人员主要的工作之一就是确认系统是否正确实现了需求。测试人员不参与前期的工
作，就只能依赖最后形成的需求文档，甚至由开发人员来讲解需求，而这些缺求可能发生了
“问题”，因为这个需求是已经经过分析的需求，很多的内容可能与用户的真正要求发生了
偏差。同时如果只看最后形成的需求文档，对需求也会有理解上的偏差。因此作为测试人员
要尽可能的获取到“第一线”的需求资料，才能真正地了解用户的业务，从而更好的对系统
进行测试。
当然，如果测试人员不能参与需求环节，一定要通过其他途径保证需求的精确性，例如
和开发人员进行集中讨论需求疑问的项目会议，并且一定要加强测试案例评审，甚至于是测
试需求的评审。
2、系统测试阶段低级缺陷较多怎么办？
在系统测试阶段，如果仍有很多低级缺陷，说明测试对象是不合格的，没有达到测试标
准。如果系统阶段发现的简单缺陷（也就是不应该有的缺陷）较多，最好停止测试，转由开
发人员进行测试，发现问题立刻修改，因为这种由测试人员进行的成本较高，反复交互还会
耽误进度。
建议建立预测试制度：系统测试前对核心模块进行抽查测试，如果问题较多（例如平均
每个核心模块发现10 个以上缺陷），就可以停止本次测试，直到抽测后发现问题较少才可以
启动系统测试。
3、缺陷流落到客户那里有什么后果？
如果软件缺陷被遗落并流落到客户那里，结果就是代价高昂的电话或者现场支持费用，
还可能需要修复、重新测试和发布新的产品，更糟糕的情况是产品要被召回甚至被客户起诉。
这种成本付出非常高，几乎是在内部修改缺陷的几何级数倍。
质量之父PhilipCrosby 把质量的费用分为整合费用和非整合费用两类，整合费用是指与
一次性计划和执行测试相关的全部费用，用于保证软件按照预期方式进行。如果发现缺陷，
经过一系列的缺陷处理流程而解决缺陷，这种费用就是非整合费用。PhilipCrosby 在自己的
作品中详细论述了内部的整合费用和内部的非整合费用之和远远小于外部也就是客户引起
的非整合费用。
总之，软件缺陷一定要尽可能的在内部解决，这对节约成本、提高产品知名度都大有裨
益。 怎么下载了都不顶顶呢。。。 怎么打不开 收藏 楼主能不能传一个doc格式的啊！！！！“mou”格式，，打开是乱码，不看能啊！！！！！
[ 本帖最后由 Melindahyb 于 2009-8-31 13:16 编辑 ] mou格式是需要用WinMount解压软件打开的 :lol 下啦，谢咯 顶，我们就遇到过这种情况，测试结束了，结果产品一看，效果和他们要的不一致，然后重新打回测试 Thank you !
页:
[1]
