1 如何认识测试
　　测试是一个方法论而不是一个技术论；
　　2 软件测试的误区
　　* 软件开发完成后进行软件测试；
　　*软件质量问题是测试人员的错误，软件发布后如果发现问题，那是软件策划四人员的错；
　　*测试技术要求不高比编程容易，随便找一个人可以完成；
　　*测试跟着开发动，有时间多测试，没时间少测。
　　* 测试是测试人员的事，与开发人员无关；
　　软件测试从这里开始
　　* 需求测试和设计测试也是软件测试的一种；
　　* 软件测试应该涵盖整个软件生命周期。同时软件测试本身也应被测试。
　　* 测试要执行所有可能测输入；
　　在测试中，穷举测试工作量太大，实践上行不通，一般采用等价类和边界值分析等措施来进行实际的软件测试；
　　* 好的测试一定要使用很多的测试工具。
　　工具所能发挥的作用依赖于使用工具的人，因此，对工具的过分依赖将降低人的能动性，并终使测试本身受到损害。适当的使用测试工具能够减轻策划人员的机械性工作，提高工作效率，而滥用工具会降低测试的质量。并不是任何工作都适合自动化的，如何合理的自动化测试，合理的选择适当的测试工具已经是研究人员感兴趣的一个课题。
　　3 测试工程师的素质
　　3.1基本素质
　　沟通能力，自信心，幽默感记忆力，耐心，怀疑精神，自我督促，洞察力；
　　广泛的经验；
　　表达能力，问题描述能力；
　　会提问，会寻求help；
　　逻辑思维能力；
　　团队协作能力；处理日常事务的能力和处理突发事件的能力；
　　3.2基本素质
　　对于系统测试，把握需求是第一位，对产品熟练，能够快速熟悉新的产品需求，很强的需求理解能力显得很重要。
　　测试基础：明确测试流程中各个阶段的工作，对测试的认知程度，决定了测试流程管理的规范性，测试工作的质量；
　　测试方案的分析设计能力，测试案例的设计能力；
　　测试工具的使用；
　　编程你呢管理，数据库知识，网络知识，操作系统知识；
　　团队协作能力，与各个小组之间的沟通能力；
　　测试管理，管理决定了工作质量，尤其是测试经理，需要管理团队的测试能力。
　　4测试工程师的分类
　　测试工程师一般分为两类：测试工具软件开发工程师和软件测试工程师。
　　测试工具软件开发工程师主要负责编写测试工具代码，并利用测试工具对软件进行测试，或者开发测试工具为软件测试工程师服务。
　　软件测试工程师主要负责理解产品的功能要求，然后对其进行测试，检查软件有没有错误，决定软件是否具备稳定性，并写出想要的测试规范和测试案例。
　　按照测试类型分类：功能测试工程师，自动化测试工程师，性能测试工程师等。
　　按照测试对象分类：web测试工程师，数据库测试工程师，数据库测试工程师，c/s测试工程师，个人软件测试工程师；
　　5测试工作的未来
　　bug 预防和早期检测
　　因为现在把重点放在产品交付的质量上来，预防实践和静态分析仪这样的检测工具将成为主流。

　　第2章软件质量体系
　　2.1 软件能力成熟度模型：cmm
　　cmm为企业的软件过程能力提供了一个阶级式的进化框架，接替工五级。
　　第一级：初始级，第二级：可重复级；第三极：已定义级；第四级：受管理级； 第五级：优化级；
　　第二级：可重复级；第三极：已定义级；第四级：受管理级；第五级：优化级；
　　初始级：工作方式处于救火状态，不断的应对突如其来的危机；
　　工作组：软件开发组，工程组；
　　需要建立项目过程管理，建立各种计划，开展qa活动；
　　2.2可重复级
　　人们总结出软件开发的首要问题不是技术问题而是管理问题。因此第二级的焦点集中在软件管理过程上，一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括需求管理，项目管理，质量管理，配置管理和子合同管理5个方面
　　关注点：引入需求管理，项目管理，质量管理，配置管理，子合同管理；
　　引入工作组：测试组，评估组，质量保证组，配置管理组，合同组，文档支持组，培训组；
　　2.3 在可重复级定义了管理的基本过程，而没有定义执行的步骤标准。在第三极则要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去，所有开发的项目需求根据这个标准过程，剪裁出与项目适宜的过程，并且按照过程执行，过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。
　　关注点：文档化，标准的一致化；软件过程标准话文档化，质量可以得到控制；工作组：sepg软件评估组。提高：对软件过程定量分析，加强质量管理。
　　第三章  软件的生命周期
　　3.1 需求管理：
　　需求应当具备一下特点：
　　完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
　　正确性：每一项需求都必须准确滴陈述其要开发的功能。
　　一致性：一致性是指与其它软件需求或者高层需求不相矛盾。
　　可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
　　无二义性：对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量巴
　　每项需求用简洁明了的用户性的语言表达出来。
　　致二义性：所以尽量巴每项需求用简洁明了的用户性的语言表达出来。
　　健壮性：需求的说明中是否对可能出现的异常进行分析，并且对这些异常进行了容错出来。
　　必要性：可以理解为每项需求都是用来授权你编写文档的根源，要使每项需求都能回溯至某项客户的输入，如use case或者别的来源。
　　可测试性：每项需求都能通过设计测试用力或者其他的验证方法来进行测试。
　　可修改性：每项需求只应该在srs中出现一次，这样更改时易于保持一致。另外，使用目录表，索引和相互参照列表方法将使软件需求规格说明书更容易修改。
　　可跟中性：应能在每项软件需求与他的根源和设计元素，源代码，测试用例之间建立起连接连，这种可跟踪要求每项需求以一种结构化的，粒度好的方式编写单独标明，而不是大段大段的叙述。
　　3.2需求建模
　　需求的建模包括巴需求转换成图形模型或者形式语言模型。需求的图形化分析模型包括数据流图，实体关系图，状态转换图，对话图，和类图，这些图形化模型一般都需要借助一定的工具，选择好的分析工具应该有助于获得需求质量特性，包括有效性一致性可靠性 可存活性可用性 正确性 可维护行 可测试性  可扩展性 可交互性  可重用性 可携带x带性等。
　　3.3审查
　　需求必须经过产品经理，软件经理 系统测试组，软件工程组，系统工程组，质量保障组，软件配置管理组，文档支持组等小组审查。
　　通过静态手工方法进行需求测试中常用的手段是同行评审。
　　3.4执行
　　建议需求文档，分配需求文档 修改需求。
　　需求的管理需求在应用领域和软件工程方面经验比较丰富的人来担任。
　　建议使用配套的需求管理工具
　　除了建立相关的文档，还需要对所有软件工程组人员进行项目应用领域的培训。