很多时候，我都比较反感写测试点：写简单点，有时自己都找不到具体功能项，领导也说你写的太粗枝大叶；写得详细一点，又成了测试用例，说你是资源浪费；为方便测试执行，将一些测试数据带入测试点吧，又说你写的点不点，用例不用例整个四不像。
哎！！！ 学习了 我也学习了1 学习了！楼上提到的和我工作提取测试点类似。 回复 8# wangs
纯新手，没做过测试，下面是我从51上下的资料里的描述，能解释一下吗，谢谢！
测试点的确定
ISO 质量体系：
在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。
CMM 质量体系：
在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程，每一个用例模型为
一个测试点，用例模型中每一个测试需求至少应有两个测试用例。 学习了 学习了 shanfeng1419 发表于 2011-6-23 10:11
公司需求做的不完善，测试组其实充当用户的角色，测试中觉得这个地方做的不恰当，提了bug。居然开发部的说 ...
开发会这么说，是因为，开发和测试的思维是一样的，开发多站在逻辑的正确上考虑，他们是正向的思维，认为只要按流程下来，逻辑结构正确，代码编写准确无误，功能就不会出错，软件就没有错误，他们的思维是正向思维。
而测试会提出这个问题，是因为测试的思维是逆向思维，是要从各个反方向去违反规则来进行测试的，是以一种把未知可以预先定义的结果去执行，将实际结果与预期结果相比较而产生的情况，测试多是站在用户角度出发，以实际发生的多种场景出发，重点是放在最后的产品在用户应用时所发生的情况，按照8020原则，更多的是测试的对象是需求。
但是不管怎么说，开发与测试的目的是一致的，都是希望当前所做的软件是没有毛病的，区别不同的就是开发与测试之间的，工作角度，工作思路，工作方法的不同罢了，既然目的是一致的，那么至于是不是bug的问题只需要平心静气，耐心的沟通就好了
首先，对于测试点这个来说，测试点是从需求文档中分析出来的，例如，某一天，一个土豪找到了某家做软件的公司，对他们说，“我是一个吃货，我要做一款有关吃的方面的软件，可以方便找到更多更好吃的美食，不但能找到美食，还要像电视里那样能看着教。”从上述话来看，这就是需求，而且按需求划分，首先是用户需求，再次是业务需求，最后是功能需求，也就是说，测试点的定位，是从需求里来的，我们不如来找下
用户需求：做一款有关吃的方面的软件，可以方便找到更好吃的美食，不但能找到美食，还要像电视里那样能看着教
业务需求：与美食有关，不是吃的方面的就是可选项（这要和客户沟通，一切需求的基础是要建立在用户之上的，况且如果谈成了，这个土豪还是投次人，你敢得罪么）
功能需求：增删改查，他要好吃的美食，所以不可能只有一种（要增），方便找到更多更好的美食，所以不会只满足当前的（要查）
还要像电视里的那样，这会是个小视频，现教的那种，说明需求种类多，但这不是二义性，能够被满足
通过上述分析，我们已经初频对这位土豪的所提出要求的做了需求分析，那么，做为一个测试来讲，这就算合格了么
不是的，好的测试，不仅是要保证需求无误，保证软件的质量，更能从当前需求中发现潜在的需求
只有这样，不断的测试需求，才能不断的完善需求，按照测试计划制定的标准，当需求被完善的差不多时，然后是业务需求，最后在是功能需求。
这只是我本人的见解，做为交流仅贡参考，谢谢 跟SRS需求文档，从应测的功能中提取测试点 提取测试点是必然的，不然我们无法得知软件需求的正确性，但如果不对需求进行分析，做出定位和确定，又怎么能提取出测试点呢，所以，在这种用户需求提出却又不是很明确的情况下，首先就是对用户需求进行分析并确定，然后再是提取测试点
页:
1
[2]
