测试定义： \亜 �2""
定义1：检查一个系统是否符合其需求，同时也试图发现可能会损害系统的成功操作或有用性的错误。 {RJ C
定义2：测试是我们考察并理解与发布的软件系统有关的利益和风险状况的过程。 �,D圱N<0
理解：以前对测试的定义理解比较僵化，一味地追求基于需求的测试，导致工作中遇到没有明确需求或文档的测试项目时一筹莫展。上面定义较全面地说明了测试的范围体现了很强的实用性。
验证和确认（verification&validation）的区别： 蚼8錺R�!2�
验证：我们正确地构造了产品吗？ m}sW_ b羜
确认：我们构造了正确的产品吗？ 哣辫蘦
理解：以前接触到验证和确认的概念比较晦涩，区别表述非常模糊，通过上面概念的学习可以非常清楚地明白，验证就是证明在AUT（application under test）的开发过程中采用了好的经验，比如遵循规范的开发过程；确认就是证明AUT必须符合它的正式需求，即基于需求的测试活动。 4P\c玘
验收测试：是由任命的用户代表在测试组的指导和监督下执行的。 駊 1d撱懽
理解：以前对验收测试的概念比较模糊，尤其是在验收测试过程中用户和测试人员的职责分工问题，上面的概念则非常清晰地说明了各自的职责。
软件测试停止的时机有哪些？ 襤廼磌眖)�
从项目周期看：1、超出了所分配的测试时间；2、用尽了分配的测试资源；3、到达了某一个固定的里程碑（如合同规定的交付日期）。 乙Hr瀌�T�
从测试角度看：1、测试需求覆盖率；2、测试代码覆盖率；3、测试用例度量；4、缺陷检查度量 样'錯`�C�
理解：熟悉上面的测试停止时机可以非常有效地管理软件测试的生命周期，从测试角度来衡量的一些指标能够更加清晰地说明停止测试可能带来的风险。
测试分析员必须精确地知道AUT的需求是什么，否则，就没有完成测试脚本和测试用例的设计的依据。不完整或维护得不好的需求可能会导致测试分析员不能为一个重要需求设计测试，也可能导致测试分析员重复耗费人力产生几个测试来验证同一个需求。
建立度量程序不是为了追究责任，而是为了改进软件开发和测试的过程。
首先要有明确的测试需求： V匟猒n�15D
1、公司要执行的软件测试有多少？测试发生的频率是多少？ ��=偞痑
2、公司中多少部门/分支机构设计到软件测试，有多少不同的测试项目？每个项目有多少人参加测试任务？ �7o<�蝭
3、测试需求的多样性程度如何？（AUT种类、各种级别的测试）
引进软件测试过程的必要性： �*c-<�3�
1、节省时间、人力和费用 泽H裢'氝 �
2、需要解决现有开发和测试过程中的严重缺陷 *韪.o��
3、作为获取某种质量认证的前提 翢醤搹穘�.
4、作为软件过程改进的起始部分
1、获得管理部门的支持和参与：得到人员和设备的保证 �8^� F4 巵
2、找到测试过程的提倡者：促进测试过程的引进和采用，要求有资格、有口才、能游说别人，职责包括去游说某个人，向管理部门汇报、主持一些谈话活动（如午餐会或讨论会）、公布活动和取得的成功，以及发现阻力点并通过工作去克服它们。 �8P2R� 曄
3、找出当前软件测试活动的基线：进行测试过程的健康检查 ?�*鏊�膋�
4、找到相关的组织化过程：找到已有的过程会对测试过程产生的影响（如开发标准、管理活动） J�ZJ缓h
5、考虑测试过程的范围和规模：由小到大、积累经验、逐步推广 平b躹8omO�
6、保证有效的培训和指导：对象为需要使用测试过程的人员（开发人员、测试人员、相关领导） 泹牟轙_韵�
7、监控进程并改进过程：管理层监控测试过层。 籊頊崹镒�
8、公告结果：宣传用。