网页的表现形式，内容的采排，一堆版面框架网页的集成，不是需求

软件其实很简单，分析好用例，让计算机一步步实现。对场景操作过程进行描述，根据客户的业务用例建立相应的程序用例，是所有软件实现的前提，好的软件项目都有一个共同的特点，就是简单的逻辑，明确用例。

用例:假设出现某种情况,采取什么样的行动;可能会有什么样的结果;根据这个结果,要采取什么样的行动,以达到某个最终结局。

摘自51testing精选文章《做好软件需求的关键要分解用例场景》

最近阅读51testing上的文章后的摘要：

    单元测试好比房屋建筑现场的建筑监理员，他关心房屋的各个内部系统，如地基、构架、供电系统和管道设备等。房屋每部分工作都安全、正常。 单元测试是从开发者的角度来编写的。它们确保类的每个特定方法成功执行一系列特定的任务。每一个测试都要保证对于给定的一个已知的输入应该得到所期望的输出。

    功能测试类似于视察同一建筑现场的房主，他假定内部系统将正常运作，并假定建筑监理员在执行其任务。房主关心的是住在这所房子里将会怎样。他关心房子的外观如何，各个房间的大小是否合适，房子能否满足家庭的需要，以及窗户的位置是否有利于采光。

ST(System Test)主要采采用功能测试(Functional Test)，关注系统提供的功能特征及其不同的处理条件；测试功能的不同处理流程（包括正常处理的和异常处理）；一个功能测试用例仅用于测试一个功能，一个功能可能需要多个功能测试用例来覆盖。

UAT(User Acceptance Test 用户确认测试)主要采纳场景测试(Scenario Test)场景测试关注于不同场景、事务、业务流程等；跨功能；仅用到各个功能的一部分处理流程；一个场景测试用例仅测试一个场景、事务或业务流程。

三者的关系：房主对房子执行功能测试。他从用户的角度考虑问题。建筑监理员对房子执行单元测试。他从建筑工人的角度考虑问题。功能测试是场景测试的先决条件，只有功能测试已经完成并且其发现的问题得到解决，场景测试才可能较有效地得到实施；如果在场景测试中发现了大量本应在功能测试中发现的问题，那么说明功能测试急需加强。

高质量的软件文档：有助于程序员编制程序；有助于管理人员监督和管理软件的开发；有助于用户了解软件的工作和应做的操作；有助于维护人员进行有效的修改和扩充

质量差的文档：难于理解，给使用者造成不便；削弱软件管理；提高软件成本；理解错误等严重后果

文档编写要求：

针对性：确定读者对象。
精确性：行文确切，不能出现歧义
清晰性：简明
完整性：前言(一般介绍)+正文(中心内容)
灵活性：软件开发项目，决定了编制的文档的种类、复杂度等

文档编写计划：详细程度；文档编制负责人及进度要求；审查负责人及进度；文档的维护更新

测试计划可分写为：测试计划、测试设计说明、测试规程、测试用例                                项目开发计划可分写为：质量保证计划、配置管理计划、用户培训计划、安装实施计划等。
系统设计说明书可分写为：系统设计说明书、子系统设计说明书。
程序设计说明书可分写为：程序设计说明书、接口设计说明书、版本说明。
操作手册可分写为：操作手册、安装实施过程。

各类测试模型:V模型忽视了测试活动对需求分析、系统设计等活动的验证和确认的环节；W模型对此有了改进，有利于尽早地全面的发现问题。但是W模型中需求、设计、编码等活动被视为串行，上一阶段完全结束，才可正式开始下一个阶段工作，如今大型软件的开发都是迭带的，此模型不适用。H模型，将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

各测试阶段：单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

TMM：1、测试和调试没有区别，初了支持调试外，测试没有其他目的 
2、测试的目的是为了表明软件能够工作 
3、测试的目的是为了表明软件不能够能够正常工作 
4、测试的目的不是要证明什么，而是为了把软件不能正常工作的预知风险降低到能够接受的程度 
5、测试不是行为，而是一种自觉的约束，不用太多的测试投入产生低风险的软件上的

   了解事物的历史才能更好得理解事物。在google上搜索到了《软件测试的起源与发展》，看了后，对测试的理解会清晰很多。有着同样经历的人，不凡找下此文章，品位下。以下是摘要：

   70年代开始，对于测试就有了以下两种看法，测试方法一：Establish confidence that a program does what it is supposed to do;Any activities aimed at evaluating an attribute or capability of a program or system.相对应的过程：在设计规定的环境下运行软件的功能，将其结果与用户需求或设计结果相比较，如果相符则测试通过，如果不相符则视为Bug。该测试方法以需求和设计为本，有利于界定测试工作的范畴。一般大型软件在有限的时间和人力资源情况采取此测试方法。测试方法二：Excute a program or system with the intent of finding errors。相对应的过程：强调测试人员发挥主观能动性，用逆向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的边界、无效数据的输入以及系统各种的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的问题。该方法往往能够发现系统中存在的更多缺陷。但这个观点的片面性，所带来的结果是：1、 若测试人员以发现缺陷为唯一目标，而很少去关注系统对需求的实现，测试活动往往会存在一定的随意性和盲目性；2、 若有些软件企业接受了这样的方法，以Bug数量来做为考核测试人员业绩的唯一指标，也不太科学。

   80年代：人们开始为软件开发设计了各种流程和管理方法，软件开发的方式也逐渐由混乱无序的开发过程过渡到结构化的开发过程，以结构化分析与设计、结构化评审、结构化程序设计以及结构化测试为特征。人们还将“质量”的概念融入其中，软件测试定义发生了改变，测试不单纯是一个发现错误的过程，而且将测试作为软件质量保证（SQA）的主要职能，包含软件质量评价的内容。软件测试有了行业标准（IEEE/ANSI）。IEEE给软件测试下的定义是：“使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别”。定义指出软件测试与整个开发流程融合成一体，软件测试已成为一个专业，需要运用专门的方法和手段，需要专门人才和专家来承担。 

   90年代开始引入了测试工具，如今的测试工具可分为：捕获/回放工具、Web测试工具、性能测试工具、测试管理工具、代码测试工具。在大型软件中，测试工具可以进行部分的测试设计、实现、执行和比较的工作。提高测试效率的目的。测试工具的发展，大大提高了软件测试的自动化程度，让测试人员从繁琐和重复的测试活动中解脱出来，专心从事有意义的测试设计等活动。采用自动比较技术，还可以自动完成测试用例执行结果的判断，从而避免人工比对存在的疏漏问题。设计良好的自动化测试，在某些情况下可以实现 “ 夜间测试 ” 和 “ 无人测试 ”。在大多数情况下，软件测试自动化可以减少开支，增加有限时间内可执行的测试，在执行相同数量测试时节约测试时间。