确认测试怎么来做？
从软件工程来讲，确认测试是发生在集成测试之后，系统测试之前的行为，它主要目标是：确认软件可以按照用户认为合理的预期方式工作。 也就是说确认软件是否完全来自需求，还有在现阶段来看需求是否依然正确。
按照国内现状，可能测试部门做单元测试，集成测试的不多，但我觉得完全有能力做好验收测试。
如果有高人做过这方面的测试，欢迎分享具体的实施方案，也欢迎大家七嘴八舌。
讨论话题：如何来做验收测试。 我们公司并没有这样的验收测试，可能将你的验收测试放在了系统测试进行了考虑，不过现在提出了验收测试，我就当抛砖引玉一下
一个过程（流程）肯定要有它的目的，为什么要这个过程，这个过程在现有的过程中是否已经包括，它的输入，输入准则、输出、输出准则是什么，它的任务活动是什么，以及由谁去做，各自的职责是什么，如：验收测试是确认的客户需求，那么这个过程客户是否参与，职责是什么，如何和客户沟通。通过这些目标式或问题式的驱动，来定义我们的过程，如果这个过程通过相关的职责部门的确认，那定义相关的流程去执行
最后说一点个人想法，LZ所说的验收测试，其实说白了，是确认需求，是业务上的测试，如果这样说，那么集成测试，系统测试都在测试什么，难道只是技术层面的测试，而不包含业务上的测试。因为添加一个过程，会增加开发的时间，那么在产品固定的前提下，必然会影响到产品的质量和产品的资源的消耗
楼主你是如何考虑的? 我的看法和你的不同。
确认测试发生在集成测试之后，但并没有严格的规定说在系统测试之前，也就是说，可能系统测试阶段，也做了部分的确认测试工作。
在我看来，测试只分两种，一种是验收测试，一种就是我说的确认测试了。
验收测试是：我们在正确的构造产品吗？测试的是产品是否从技术的角度实现，偏业务功能
确认测试是：我们在构造正确的产品吗？测试的是产品对用户的符合度，偏需求。
我理解的确认测试，是需要用户参与的。因为无论开发还是测试人员，都不是产品的最终用户，都不能真正的代表用户的需求。
我们通常所说的a测试和b测试，其实就是确认测试阶段的工作，直接由用户参与或bata版本，由用户单独体验测试。
但目前国内软件公司急功近利，开发周期短，很少有此阶段的测试安排。
但作为测试部门，有一部分工作是可以做的，那就是回归需求。前提：如果前期的需求采集做的好，那么我们的回归需求是有意义的。
问题是这个需求回归怎么来实施呢？都应该有那些人员参与？它的标准来自什么（需求文档？规格说明书？或者其他的技术文档？）？
需要生成那些测试输出？等等
貌似乐意讨论这些理论性的东西的人不多呀，多家都集中火力攻具体技术去了。 确认测试 同意 kuailederen的说法
验收测试说的比较深奥，如下理解是否正确？
驗收測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作.經集成測試後,已經按照設計把所有的模塊組裝成一個完整的軟件系統,接口錯誤也已經基本排除了,接著就應該進一步驗證軟件的有效性,這就是驗收測試的任務,即軟件的功能和性能如同用戶所合理期待的那樣. 原帖由 懒月亮... 于 2009-2-5 18:19 发表 http://bbs.51testing.com/images/common/back.gif
确认测试 同意 kuailederen的说法
验收测试说的比较深奥，如下理解是否正确？
驗收測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作.經集成測試後,已經按照設計把所有的模塊組裝成一個完整的軟件系統,接 ...
我的理解是这样的。验收测试对软件本身负责，对技术负责；确认测试对需求负责，对用户负责。
验收测试可以容易的定义明确的度量标准来进行测试，而确认测试更重要的是寻找理解上的偏差和执行上的偏差。
这些偏差是技术人员所不能理解和不能发现的，所以一般由直接用户来做这方面的测试。
页:
[1]
