|
软件测试过程中的质量控制
我做过一点,呵呵,也来说两句
首先软件测试是软件质量控制的一种方法,它贯穿整个软件生命周期。
我不知道你说的是指需求测试/设计(概要&详细)测试/单元测试/结合测试/回归测试/系统测试中的哪部分。
如果你是说全过程,呵呵,carmela说的已经很多很好了,我也只能泛泛的说。
如果分阶段来说,那不同的阶段有不同的方法进行质量控制
1.对于需求和设计阶段测试效果的质量控制,由于国内的很多公司都是只负责编码,开发过程中根本没有这个阶段,甚至于有些公司的测试知识按照国外公司发过来的(非中文版的)测试用例进行测试,所以zig_cui才不知道有这些的。呵呵,对于这个阶段的质量控制我的经验也不是很多,主要是参加评审(需求和设计)会议和check仕样书,站在客户的角度提出的合理建议,比如易用性,美观性等。
2.测试用例的编写:这个也是在需求和设计阶段需要做的,也是QC比较重要的工作(包括的比较多,呵呵,最主要的就是遍历,还有测试正常和异常功能用例的比例)。比较好的流程是每天固定时间提交,由小组内部review,由测试组长抽查,全部完成后要经过同级评审,和开发人员的确认,才能应用。
3.单元测试:这个工作一般是由开发人员来做的,如果由于时间紧,也可能由其他开发人员或测试人员来完成。这是非常重要的测试阶段,可能发现很多隐藏很深,或影响很大的bug,很多项目结合测试时发现的bug过多,导致不能按期提交,都是由于单元测试做得效果不好。这个阶段质量控制可以针对提交的bug数对代码(包括测试代码)做抽查,是否发现修改后的代码仍然存在很多问题,并且,测试代码没有遍历。
4.结合测试:可以通过并行测试和抽查来做质量控制。这是检查测试效果的最主要途径。还有是否按照用例进行测试,测试中记录下来的新增用例的数量等等
5.回归测试:其实是结合测试的一部分,是对开发人员修改后的软件产品,进行的bug确认和基本功能的测试,因为大家都知道,修改bug,很可能对其他代码造成影响。往往是修改一个bug,能引起更多更大的bug。这一阶段,主要还是抽查,看看是否有的bug没有修改,是否有以前没发现的bug被提出等等。
6.系统测试:这里的质量控制就要按照基本用例测试一下,是否有基本功能为实现。
7.产品的用户手册:这里就要对用户手册进行检查,是否做到了简单,易懂,风格一致等。
以上如发现问题应该立即提出督促修改,并对修改结果进行确认,如果严重要重新进行这个阶段的测试。
呵呵,一点心得。
[ Last edited by illusion on 2005-10-25 at 15:30 ] |
|