浅谈软件测试过程的持续改进
随着国内软件测试行业的逐渐发展，有越来越多的软件企业更加重视软件测试，并已经形成了一套基本的软件测试流程。但是软件测试所起的作用还没有人们期望那样显著，因此，需要继续加大投入对软件测试的关注程度，对软件测试过程进行持续的改进。软件测试过程中需要注重和改进的几个环节，与大家分享。
1、 计划与风险
项目计划对项目过程的实施有着直接的指导作用，它的重要性是不言而喻的。我经历过一些成功的项目，给我感受深刻的是计划的充分性，以及根据项目过程中遇到的各种新情况，对计划的及时变更做出反应的能力；我也经历过一些失败项目，由于项目计划的不合理或混乱无序，经常会带来严重的项目风险、以及开发成本，造成项目不断延期、产品质量无法保证。对于软件测试来说，测试计划也是指导后续测试工作的基础，在测试的计划中，不仅需要明确测试的目的、测试的资源、测试的人员等等，更重要的是需要详细明确并估计出在整个测试活动的任务和风险，比如：
测试需要做哪些工作？
整个测试活动估计需要多少工作日？
充分估计测试计划、测试设计、测试执行、测试分析评估这些阶段分别需要多少个工作日？
估计的测试用例规模是多少？
估计的测试进度时间又如何？
在测试过程中，可能会遇到哪些方面的问题？
可能存在的风险又有哪些？等等......
只有对过程中各任务的进行更详细的计划，才有利于在测试过程中对项目进度的把握有一个明确的目标；同时，风险策略的制定，也有利于对及早对测试过程中可能遇到的问题做出分析，以便在问题出现时能够尽可能的减少规避风险的成本。
2、 评审
在测试过程中的每个阶段结束前，都会输出一些资源，文档、用例 等等…，这些资源往往是下一个测 试阶段或软件开发的下一个环节执行的依据，比如：测试报告，测试人员在完成测试并提交测试报告之后，测试报告里说明已经没有未解决的问题了，那么是不是应该结束测试呢？我们又如何来保证测试报告的准确性、充分性呢？这需要组织参与项目的一些重要成员，项目经理、开发负责人、测试经理、QA等等对测试报告进行评审。评和审是结合在一起的，每个角色根据自己对项目的了解，从各自角度来审核测试报告的充分性，对质量风险发表各种见解。终，对报告的规范性也要进行考察。评审也有会议评审、在线评审等等好几种方式，可以根据实际项目情况，对不同的项目、不同的文档、资源采用不同的方式评审。后一点需要补充的是，对于测试发现的问题，一般是有争议的问题，需要有评审。对于紧急的问题，一般采用在线方式由专家裁决；另外，也好根据实际情况组织会议评审来对一定规模的问题统一评审。
随着国内软件测试行业的逐渐发展，有越来越多的软件企业更加重视软件测试，并已经形成了一套基本的软件测试流程。但是软件测试所起的作用还没有人们期望那样显著，因此，需要继续加大投入对软件测试的关注程度，对软件测试过程进行持续的改进。软件测试过程中需要注重和改进的几个环节，与大家分享。
1、 计划与风险
项目计划对项目过程的实施有着直接的指导作用，它的重要性是不言而喻的。我经历过一些成功的项目，给我感受深刻的是计划的充分性，以及根据项目过程中遇到的各种新情况，对计划的及时变更做出反应的能力；我也经历过一些失败项目，由于项目计划的不合理或混乱无序，经常会带来严重的项目风险、以及开发成本，造成项目不断延期、产品质量无法保证。对于软件测试来说，测试计划也是指导后续测试工作的基础，在测试的计划中，不仅需要明确测试的目的、测试的资源、测试的人员等等，更重要的是需要详细明确并估计出在整个测试活动的任务和风险，比如：
测试需要做哪些工作？
整个测试活动估计需要多少工作日？
充分估计测试计划、测试设计、测试执行、测试分析评估这些阶段分别需要多少个工作日？
估计的测试用例规模是多少？
估计的测试进度时间又如何？
在测试过程中，可能会遇到哪些方面的问题？
可能存在的风险又有哪些？等等......
只有对过程中各任务的进行更详细的计划，才有利于在测试过程中对项目进度的把握有一个明确的目标；同时，风险策略的制定，也有利于对及早对测试过程中可能遇到的问题做出分析，以便在问题出现时能够尽可能的减少规避风险的成本。
2、 评审
在测试过程中的每个阶段结束前，都会输出一些资源，文档、用例 等等…，这些资源往往是下一个测 试阶段或软件开发的下一个环节执行的依据，比如：测试报告，测试人员在完成测试并提交测试报告之后，测试报告里说明已经没有未解决的问题了，那么是不是应该结束测试呢？我们又如何来保证测试报告的准确性、充分性呢？这需要组织参与项目的一些重要成员，项目经理、开发负责人、测试经理、QA等等对测试报告进行评审。评和审是结合在一起的，每个角色根据自己对项目的了解，从各自角度来审核测试报告的充分性，对质量风险发表各种见解。终，对报告的规范性也要进行考察。评审也有会议评审、在线评审等等好几种方式，可以根据实际项目情况，对不同的项目、不同的文档、资源采用不同的方式评审。后一点需要补充的是，对于测试发现的问题，一般是有争议的问题，需要有评审。对于紧急的问题，一般采用在线方式由专家裁决；另外，也好根据实际情况组织会议评审来对一定规模的问题统一评审。
6、 缺陷分析、度量
对测试活动过程中发现的缺陷进行分析、度量，寻找软件开发过程中存在的问题，并持续改进开发过程，提高质量。缺陷的分析、度量从时间上分为两个方面，首先是在软件开发过程中发现的缺陷进行分析、度量；然后是，对软件产品发布后，对用户提出缺陷进行统计、分析。
对测试过程中的缺陷需要分版本，并按不同模块、问题级别，对缺陷进行各种统计，并比较子版
本统计数据之间的差异，CQ在这方面已经提供了比较强大的统计功能，这里不再赘述。进行分析，是因为开发修改后导致该模块不稳定，引发大量新问题；还是因为前期测试出现漏测（设计漏测、执行漏测）；或者是版本合入新增需求的功能导致。然后根据问题原因，提供改进建议。下面对几个参数进行说明：
TFVUD 是用户发现缺陷数（ Total Field Valid Unique Defects ）：即由用户发现的经过了确认的、非重复的、非用户错误操作的、非建议类型的所有缺陷；（总数、按模块统计）
PDD 是测试发现缺陷数（ Post Development Defects ）：即在开发完成后的测试周期中发现的缺陷数，但它不包括那些向用户发布后发现的缺陷；（分别按模块、级别、时间 统计）
DDR是开发缺陷率（Developer Defect Ratio）：一定周期内缺陷总数与代码
