软件测试流程小记

       软件测试流程小记   测试流程　

  　做测试快两年了，虽然我去年才毕业，但是在此之前我已经做了9个月的测试，毕业后才成为正式员工，之前的9个测试，我从一个测试新手进步到初级测试人员，十分感谢照顾我的老大，呵呵。

　　在我们公司，因为我们是做自己公司的产品，所以我们就不存在与用户沟通那些业务的事项啦。所以相对而言就不用折腾了，呵呵。当一个项目下来时，我们的测试 leader会参与一个meeting，这个meeting会有PE，相关的developer，其实就是一群老大了，参与此会的目的，了解该项目的起始到结束的时间，参与的人员，该项目能实现的功能，若你是参与测试这边的测试人员，那么你只带了一双耳朵是不行，你首先要想到自己测试所需要的硬件及软件这一块是否充分，测试人员是否足够，若是不够的话，你就要说出来的，因为这些都会影响你测试的进度。所以在参加这个meeting前，大家一定要提前想想我们会遇到的问题，并且在会上适时的提出。

　　接下来，我们会有一个SPEC，这上面有该项目主要的功能，比方说我，我主要是测application，那么一般给我们的SPEC上会有安装方法及路径，功能实现，UI这些。那么这就是我们获得最重要的信息了，然后你会根据SPEC开始写你的Test Plan，Test Plan是真的需要经验的，经验越丰富的leader会能cover到很多场景的，这样会减少我们的风险。

　　对于软件的测试流程，我们会有两个阶段，第一个阶段我们称为beta阶段，第二个阶段我们称为RC阶段，可能每个公司说法不一样。对于beta的阶段，我们也可以分很多阶段的，如beta1，beta2，ect。但是在beta前，我们的coverage应该cover到了很多的场景，并且软件也是相对很成熟的，basic function是能正常工作的，当然，我们可能会遇到一些比较变态的bug，这时开发人员也解不了的，那不关我们的事，至于能否进入RC，还是老大们决定的，我们想管也管不了(测试人员身份尴尬的一面)。进入RC的软件，一般都是相对稳定的，那么这时的测试着重点，就不在是basic function，这时我们的coverage要cover到我们没涉及到的场景，基本上在RC最好不要在出现很严重的bug了，在我们公司，要是在RC 出现了严重的bug，是要挨批的(明明是开发人员开发出不好的程序，但是出现问题，是我们背黑锅的，这也是大家一直争议的问题，对于这个问题，我觉得若是我们在之前遗漏的bug，并且我们也做了那块的function 测试，若没发现，这部分挨批我们是可以接受的，毕竟我们自己工作的疏忽)。若是软件很稳定了，就可以去认证了，我们公司都是拿到微软认证的。

　　拿去认证后我们的任务就大告成功了，呵呵。

原文转自：http://www.ltesting.net