SQA如何把握测试中的漏洞
公司最近的一个项目,从概要设计开始到结合测试都是横向展开的(也就是说正在进行结合测试时,概要设计还有可能修改).关键是日方这样,我们这边也没办法.可这样,对SQA的审查就很困难.因为是横向展开,不是一条线下来的,所以项目中一定会有被遗漏的地方.测试式样书不停的改,所以测试时出现了遗漏(测试时间本来就很短,大家加班加点也干不完),产生了错误.
请各位高手指点,从SQA这方面来讲,我要怎样才能更好的控制项目的这些漏洞...
先谢过了....:) :) 帮你顶起来吧，期待大家解答！
回复 2# 的帖子
谢谢你啊...:) 请能否把你想解决的问题详细描述一下.例如产生了什么问题.可能能帮上你
回复 1# 的帖子
任何项目都希望能够按照瀑布模型来进行，但无论是外包还是产品的开发，都是不停的需求变更，所以瀑布模型其实在软件开发中是很不实用的，但是很多的软件开发都是选用的瀑布模型，所以也就出现了你这样的问题。作为QA，概要的从这几个方面考虑（暂时简要的想到的）
1.在计划阶段，项目选择瀑布模型时，作为QA就应该想到这种问题的出现，以及计划中体现对应的措施。完善流程
2.如果有对应措施，那根据对应措施走，如果没有对应措施，那应该识别风险，跟踪风险
3.对应到你说的问题，首先应该保持设计书和测试式样书的一致性，察看是否有遗漏，特别是复杂度高，重要的功能点。一定不能出现错误，同时对测试的成果物也要有目的的抽查。
4.如果加班都没有完成，那为了提高客户的满意度，首先要告诉客户，我做了那些测试，那些还没有做，纳期是否可以延期等，当然如果对这个风险能够接受，那可以和客户说没有问题。呵呵
回复 3# 的帖子
因为所有东西都是同步的，在我们结合测试快结束时，又新加了几个测试项，由于人员之间的勾通少，又都很忙，是小公司．测试的人员就没发现新加这几项的存在，也没发现这几项的重要性．．．就没测，直接打的ＯＫ．结果产生了错误．．１．我们时间太少，根本没办法全测．
２．项目横向展开，在测试时，概要设计也在变，这样文档管理就比较混乱，人员之间的衔接又不好．
如果以上两点是这次项目无法避免的，但对于ＳＱＡ这一块，要怎么做才能尽量避免错误的发生呢？
先谢过了．．． 原帖由 思懿 于 2008-10-7 09:45 发表 http://bbs.51testing.com/images/common/back.gif
因为所有东西都是同步的，在我们结合测试快结束时，又新加了几个测试项，由于人员之间的勾通少，又都很忙，是小公司．测试的人员就没发现新加这几项的存在，也没发现这几项的重要性．．．就没测，直接打的ＯＫ．结果 ...
想知道是不是用迭代开发的方式可以解决呢？
对于这样的情况应该制订一个移交流程，就是要将测试和研发两个部门用移交流程贯穿起来，这样就可以避免沟通不足而产生错误。
移交流程中应规定一些文档，其中包含研发部的需求变更等，以及要求测试部测试的程度，至于要规定填写什么信息，就要看测试部门需要什么信息才能更加深入的了解该版本的具体情况了。
回复 5# 的帖子
我觉得在检查漏洞那一块，我的确做的不好，一直以来我都是只本本分分的完成ＳＱＡ的基本检查，就是对文档管理的检查多一点．主要是对产品的，没管过程．我想以后我会像你说的，对照着检查漏洞．特别在测试时，仔细检查他们的作业分担．最后再对项目进行１０％－２０％的抽查，你看这样会有一些效果吗？ 原帖由 思懿 于 2008-10-7 09:45 发表 http://bbs.51testing.com/images/common/back.gif
因为所有东西都是同步的，在我们结合测试快结束时，又新加了几个测试项，由于人员之间的勾通少，又都很忙，是小公司．测试的人员就没发现新加这几项的存在，也没发现这几项的重要性．．．就没测，直接打的ＯＫ．结果 ...
1.时间紧，没有办法全测，这个是很现实的。但是一定要和客户做好沟通，但绝不能在没有测试过测试case直接标注没有问题，这等于--，可以和客户说由于时间原因，这部分还没有测试，可能存在问题。
2.对于横向展开，配置管理工作，以及流程的定义，要搞好，项目现在结束了，要做好总结，对这部分问题要提出来，要总结。 原帖由 思懿 于 2008-10-7 10:08 发表 http://bbs.51testing.com/images/common/back.gif
我觉得在检查漏洞那一块，我的确做的不好，一直以来我都是只本本分分的完成ＳＱＡ的基本检查，就是对文档管理的检查多一点．主要是对产品的，没管过程．
我想以后我会像你说的，对照着检查漏洞．特别在测试时，仔细 ...
这里是没有问题，不过抽查10%-20%比例好像小点，根据“学院派”的指导好像比例要高点，我记得好像是30%以上，不过这个要根据项目的实际，人员的配置来。 LZ的问题我也经常遇到，好像在小公司的项目中经常因为时间的关系碰到很多遗漏的地方 防止漏测有很多种入口
1：譬如修改点积累修改，修改点的评审，修改点需求的冻结
2：测试用例的覆盖，测试的执行
3：项目里程碑控制 如果说因为时间问题而漏测了，那就是测试工程师的责任，你为什么漏测，为什么没有提出时间不足？说明整个项目里程碑时间有问题，没有计划安排好，没有评估到测试的时间投入量，更没有预留突发事情处理的时间点。
指定测试的优先级
1.识别模块或者功能的测试优先级 ，优先级高的先保证质量，同时要和相关的人员进行沟通，让大家都得到一致认可。2. 对于修改的部分 （是需求或者设计变更导致的吗？），需要做好相关方面的控制，比如文档，测试版本，计划，风险。
3. 明确各测试人员的责任 ，哪些是人负责哪些模块的，一旦这些模块出现了相关的问题，相应的会追究相关人员的责任 。
回复 11# 的帖子
那如果项目横向开发时,你们是怎么控制版本的啊?什么时候定板啊....怎么横量定板的时间啊?回复 12# 的帖子
防止漏测有很多种入口1：譬如修改点积累修改，修改点的评审，修改点需求的冻结
2：测试用例的覆盖，测试的执行
3：项目里程碑控制
修改点的冻结是怎和回事啊..要填什么表吗?
项目里程碑要怎么控制?因为是横向开发啊....真到项目发布前,概要设计等还在不停的改,我想问那要什么时候进行一次定版啊..怎么控制时间?(以前都是开发计划和要求式样定一次版,设计定一次版,编码和测试结束定一次...可这次是横向开了,要怎么进进管理啊..) 原帖由 思懿 于 2008-10-13 10:26 发表 http://bbs.51testing.com/images/common/back.gif
防止漏测有很多种入口
1：譬如修改点积累修改，修改点的评审，修改点需求的冻结
2：测试用例的覆盖，测试的执行
3：项目里程碑控制
修改点的冻结是怎和回事啊..要填什么表吗?
项目里程碑要怎么控制?因为是横向开 ... [/
像这种需求经常修改的项目，就应该采用迭代开发模式，每次制定一个短目标。采用迭代开发模式的项目有一个好处就是，项目作出来的部分可以及时得到客户的意见，不至于到项目末期才被发现。通常问题发现的越早就花费的修改成本越低。而迭代开发的项目还可以根据客户对已经做好的项目的所提出的意见来对接下来的迭代的需求和设计作相应的调整。这样，qa即可以很好的作跟踪和检查，项目也不至于一直处于修改的状态。自然这个迭代开发的项目计划还是由项目经理来做的，qa根据项目计划制定质量计划，并不断跟进，作相应的检查和跟踪。不知道回答得是否和所提问题相符，还请大家指教。::xixill::: 先顶起来，等待大家讨论。 个人感觉：
1.对需求的理解程度，talking--> detailed case.测试用例的覆盖
2.对changed requirements 的management，by software configuration tools --DevSuite 变更需求的管理--> change testing case
3.对于baseline 个人感觉不是多版本发布没有太大必要。
4.测试shallow --> complex logic 是否考虑一下做一个需求变更流程？
页:
[1]
