版本发布和评价（原创）
在进行一个版本测试之后，作为测试人员，有没有对缺陷做一个分析，对于这个版本质量评价如何？在实践中，我发现测试人员往往乐衷于发现多少致命问题，多少严重问题等等。我认为这里存在一个严重的误区。测试为了什么，测试最终目的是什么？我觉得测试不是为了发现多少问题，而是应能判定一个交付版本的质量，稳定交付版本质量。
试想你发现了N多问题，洋洋得意，可是市场反馈产品的问题不断，此时你能说开发真烂。不要忘记了，这个版本可是从你的手下走过的。
作为一个测试项目经理，我意识到了这个问题。并力图改变这个局面。在流程上，推行下游决定上游。测试是开发的下游，客户是测试的下游。下游出了问题，上游要负责。这样一来，测试人员往往会问，“还有什么遗漏的吗？会不会出问题？”，而不是说“我发现了N个问题，可以休息一下了。”。
而且我要求在测试完一个版本之后，作为测试人员在报告要对该版本做出客观的评价。笼统的说，该版本是否稳定，她的主要问题在哪里，还有什么遗留问题，遗留问题的影响是什么？在评价我要求要客观，不能主观，不能出现如外交词汇。
那么，测试一个版本之后，你依据什么评价一个版本质量？ 我的做法是建立一个基本用例库。把这个用例库的用例给跑一遍，统计通过率，统计缺陷，追究问题的根源，可以评价一个版本的质量。
所以这个用例库的设计是关键的。在我看来如何设计用例比如何执行重要的多。这个用例库是动态的，不停的完善。
最近我在思考如何使这个用例库少而精，在一一轮又一轮版本测试中，我应该撷趣哪些用例？
有人能告诉我吗？ 这么说楼主测试的应该是同样的产品（项目）或是相似的产品了。我觉得是不是设计用例时注意一下设计时的思路，如等价类，边界值，覆盖域，正交实验，流程分析法，状态转移等等的方法进行设计，看看这些个方法哪些能适用，并设计出用例。然后再将重复的用例剔除。这样最后得到的用例应该是很精良了吧。当然设计时怎样用等价类等的方法，用到怎样的设计精度（如有效等价类的粗细度），就靠自己把握了。这样“用例库少而精”就一定能实现了。具体这个设计精度的问题，本人实在说不上来，没做过多少项目。前辈们肯定自己心里有数。
（个人看法，不到之处请指正） 我个人理解：对版本的接收要进行验证（针对集成测试和系统测试），比如说，一个版本过来后，你在某一个子模块里面就发现了多少个以上的严重缺陷，那么就可以打回这个版本 让他们重新修改后再发布过来测试，而不是任意一个版本过来我就要重新走3遍所有的测试用例。 同意楼上的。测试经理完全有权利返回版本，严重阻碍测试进度的版本，也可视为质量不过关，返回要求修改后重新转测试。 根据项目的特点，我现在一般采用功能交互和等价类的划分方法来设计用例。 功能交互---楼主能简单介绍一下吗？谢谢
页:
[1]
