审、测、评 ---从测试过程看软件测试
审、测、评
---- 从测试过程看软件测试
需求，是系统持续的、稳定的满足客户要求的能力。
“什么时间介入测试。”，测试人员一直在不断的思考着这样的问题：什么是软件测试介入的最佳时间。
“尽可能早的测试”，无论从测试理论，还是测试人员自身，都会这样的认为。
风险前移，尽可能早的发现问题，改正问题，减少修正问题所带来的花费，经济化原则。
软件开发是创造性活动，而软件测试是保护性活动，也就决定了软件测试活动只有在出现重大问题时才会引起大家的注意和重视。
那么，尽可能早是多早，从软件有意向时就开始吗？尽可能早的开始，那么测试早开始要做什么？采用什么方式？达到什么目的？
首先我们看一下软件开发过程和软件测试过程，典型是V模型
从需求开始，会有严格的V&V过程，可以做为测试过程。执行人员会涉及到系统开发的各个岗位和角色。
在实现过程中，会有单元测试和接口测试。由开发人员执行。
编程结束后，会有功能测试、集成测试和系统测试，然后是反复不断的回归测试。由专业的测试人员执行。
系统交付后，会有验收测试。由内部验收和外部验收人员执行，或是由第三方执行。
从整个过程来看，会将软件测试过程分为三大类：审 --> 测 --> 评
从市场调研、售前支持、需求获取、需求分析、系统计划、系统实现的整个过程，在这个过程中，软件测试完全处于准备状态。
在这个阶段，软件测试大量的在做评审工作，从不断的“审”中，发现系统存在的问题和漏洞，使系统具有可测性前题。
同时，测试人员需要通过审，完成对软件系统的了解，分解系统需求为测试需求，并估算测试工作量，完成测试计划的制定，确认测试策略。
这里推荐X模型，强调测试和开发工作的平行进行，完成测试执行前的准备工作。
一但系统成型，达到测试标准，就可以释放进行相关的测试。
这里推荐使用X模型。
我们需要完全的集成后的系统测试，但是我们仍然要贯彻尽早测试的原则。把一些系统核心业务之外的模块功能进行先期测试，保证不同阶段、不同测试类型的测试的重点。
这里提到持续集成的概念，也是敏捷的观点。越少的集成，越早的测试，把非主流问题提前解决，使问题定位花费更少的时间、更少的投入。
先保证各模块的稳定性和可靠性，其次是系统接口的稳定性和可靠性，最后是整个系统的稳定性和可靠性。
每个阶段都会有自己的测试工作重心，每个阶段都会有自己的测试工作流程，通过不断的调整工作方式和方法，达到最佳的测试效果。
这里的评分为两种：一种是内评；另一种是外评，也称为第三方评测。
无论哪种“评”，都需要采用审慎的态度，从软件过程到系统本身均需要给出明确有效的“评”结果。
这里的评，无论是内评还是外评，其实都是对测试工作的确认，从而量化分析得出系统的质量。因此建议采用“第三方”的形式。
内部组织需要项目相关负责人、相关参与者、测试人员、质量保障人员多方构成，保证系统开发的方方面面、系统实现的方方面都会有人参与和评估。
外部组织则借助第三方的力量，通过第三方严格的测试和评估，形成对原有内部测试结果的对照，从而有效评估系统质量。
这里需要指出，一个好的软件开发过程不一定能保证系统的正确性，但是一个混乱的软件开发过程则一定不会有良好的系统实现。
风险时时存在，任何的系统中都会存在问题，这也是软件测试的重要原则。
