送测单

多年前，在传统的开发模型下，为了规范开发活动有了送测单这种方式。规则和执行总是存在差距，究其原因：清晰的目标+良好的沟通+简单有效
--------------------------------------------------------------------------------------
把事情做简单而不是做复杂。

 

1.送测中的人的问题
有三类人：1）谁来提交测试；2）谁来接收测试；3）谁来做仲裁；
1）和2）两类分别是测试的出口守护者和入口守护者。
1)关心的是哪些需要提交测试，哪些是需要明确指出需要着重关注的（测试是独立的工作，有自己的执行策略，这是在整个项目执行中就达成一致的，因此指出的内容只能是测试的重点或是优先级较高而不能打乱测试执行的原有计划。）
2）关心的是哪些是本轮测试的对像，这就需要提交测试人员将提交的内容做出详细有效的说明，保证测试人员可以有效的执行测试用例。
这里有一处遗露的地方：
开发人员提交代码到仓库，生成相应的是TAG（一个不稳定的版本不应当打基线，其中的原因大家都明白，打了基线的代码，如果没有相关负责人的同意和相应的基线变更申请，是不允许做check in操作的。）而测试人员所取的代码不是直接来自仓库（跟据TAG），而是由开发人员提供的部署文件，谁能保证开发提供的部署文件和仓库中文件一致性（操作出现不衔接）
3）的存在是为了保证如果开发和测试出现争议，3）来做出对问题的裁定，因为项目不能因为争议而停止不前，必须迅速找到解决方案。一般来讲，这个仲裁是由PM或PM＋项目级QA来充当的。

 

2.测试的时间问题
测试执行的时间是体现在项目整体的计划中的，任何的计划变动，相应的测试计划也会做出变动，特别是测试执行的时间和策略。如果需要别人指明测试执行的时间，那么没有必要再让测试人员写测试计划了，按项目经理的要求做就好了。那么也就不要强调测试独立性的问题了，时间都需要别人分配，有什么独立性可言，听项目经理的调配也就好了。

 

3.为什么要写送测试单
目的应当很明确，要对测试的每一个模块的完成情况和相应责任人有明确描述，保证所有提交的代码都经过严格的开发自测，保证如果有问题，可以与之沟通。
只要送测的内容和责任人明确了，接下来就是按测试组制定的测试流程进行测试。
首先是验证上一版本的问题，没有按要求修改完，是不允许进行新一轮的测试的。
如果是新提交的模块，没有完成即定的大的功能要求，也不应进行深入测试。
这应当是冒烟测试的真正含议。
测试的时间也是时间，测试的执行是完全独立不受项目组其它人控制的。

 

4.关于送测的类型
任何的代码修改都来自于需求，不论是新项目的开发还是旧项目的维护。
任何的需求变化都应当被维护，都会在相应的计划中体现。
因此测试的类型应包括两类
1）计划型；2）维护型
1）是针对新开发的项目的，所有的测试计划时间都有制定，跟据整体的计划调整也会做出相应调整，这是整个项目组达成共识的一个计划。
因些所有的测试都应当按计划执行，所有的送测试单也是固定的。
2）维护型项目是针对客户反馈进行的，特点是应当及时响应，因些送测单包含修改人和修改的需求。如果测试人员能够进行代码级的测试，需要明确修改了哪些文件（不过仓库是具有不同版本间的比较功能的，只要测试人员用点心就行了）

 

5.关于开发的自测
开发人员必须进行自测，如果不能自测，无法保证测人员的正常执行，但测试人员不能要求开发人员搭建一个跟测试人员一样的环境进行测试，这样是不现实的，开发人员的自测，一般集中在单无测代码和模块间联调上。
测试可以通过冒烟测试对开发提交的代码的可测试性进行验证，不符合标准不再做进一步的测试。
如果开发多次出来不通过现像，我想我们的PM和QA对整体的开发人员需要做相应的淡化了，是什么原因，那不再是测试关心的事，而是由开发人员解决。
这其间浪费的时间，不能占用测试的时间，也不应缩短测试的时间。