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

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

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

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

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

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

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

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

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

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

阿蒙博客：http://www.vchome.net/blog/blog.asp?name=harrymeng

水之真谛：http://blog.csdn.net/FantasiaX

张晓军ID：arcow：http://blog.csdn.net/arcow/archive/2007/08.aspx

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

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

文档编写要求：

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

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

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

摘抄于《软件测试浅悟妄语》

发布时间: 2008-5-08 13:15   作者: 水之真谛    来源: 水之真谛的博客

　　一个民族最伟大的东西是什么？是文化和思想。那么我们能不能用中国的文化和思想去重新审视软件测试的方法，创新出自己的思路来呢？ 
　　西方人善于推理，因此他们的测试流程是——
　　1. Test Plan　　2. Test Case　　3. Find Bug　　4. Review fixed bug
　　以上这4个环节是用推理的办法逐步细化，并随着软件版本的更新而迭代前行的。
   中国人善于归纳，按照上面的这个流程做测试时，最大的困难是第一步到第二步的跨越——依Test Plan去正推Test Case是件很痛苦的事情，很容易陷入两个误区：一个误区是写了一大堆不疼不痒的Case，把测试变成了跑龙套；另一个误区是过分追求要抓到Bug，结果产生很多疏漏。
　　为什么会出现这种情况呢？原因在于文化。Test Plan本身是按“逻辑”将软件的功能分组，然后进行测试，老外的逻辑思维能力是比较强的，基本上能够比较轻松地把符合Test Plan中某个分枝的操作都挑出来、Fill进Test Plan里，而这在我们中国人看来，这是对软件操作的一种“割裂”，因此心里会感觉很乱、无从下手——于是测试就成了一个怎么也走不出去的迷宫。
    一个民族的文化能够得以保存，是因为有了语言和文字。其中尤以文字最为厉害。特别是中国的方块字，那就是一座宝藏。古人在造字之初的含义就蕴含在这方寸之间，几乎一点不变地穿越时空，把祖先想表达的意思直接带到我们面前。

    把Test翻译成“测试”。测，水+则。则最早是用“刀”把章法刻在“鼎”上让人们遵守的——后引申为“尺度”。拿尺子伸到水里，不就是测量水的深度吗？这就是“测”的本意——亘古未变。再进一步，其实测量不光能测水深吧，凡是与被测对象的属性打交道、进行量化的行为，都应该算作“测”。秦始皇下大力气统一“度”（长度）“量”（体积）“衡”（货币），不都是为了方便测试行业在全国的统一发展吗。请大家注意，“测”字为我们传递了一个非常重要的信息，那就是“静态”。基本上可以说，如果被测对象不是相对静态的，那么就无法测量了。量子物理中的“测不准原理”中的测，也正是说明这一点。再看“試”字。“言”+“式”，口试。既然是考试，那么问答就是必要的了，所以会有一个言字，其实这一“问”和一“答”就是软件的“输入”与“输出”。

   软件的Build从拿到我们手里开始，就是处在“动”与“静”的交替状态。既然是动静交替，我们非要先把静的挑出来写成Case、再把固定某一种“动”挑出来写成Case（而不管它在什么时候出现），当然是件很麻烦的事情。那么我们应该怎么办呢？
 
   上文提到，静者为测。让我们想想软件都在什么时候是“静”的。
　　我们看一个自然的流程：Build下载、下载完成、安装、安装完成、开启、使用、关闭、卸载。哪些是静？哪些是动？让我们一一剖析。
1.下载：全部属性处在动态而不可测中。
2.完成：静态。此时可测量软件的大小、Hash验证码等。
3.安装：全部属性处在动态而不可测中。
4.完成：静态。此时可测量软件各文件大小，目录，COM注册情况，注册表情况等属性。
5.开启：动态。全部属性处在动态而不可测中。
6.使用：半动态。哈！怎么是半动态呢？因为这时候软件已经从硬盘Load进内存了，在内存中是相对静态的。你可以观察内存占用是否稳定、有否泄漏。这就叫“静中有动，动中有静”，这才是咱们中国人的哲学。
7.关闭：静态。检查运行后的生成物（如聊天记录、Log文件、temp文档）是应该存在还是被删除。
8.卸载：静态。检查有没有遗留物，硬盘、注册表，都找找看。
 
　　看，这样理顺下来，是不是写Case就轻松多了？如果要是按照Test Plan的架构来写Case，这些Case应该分布在至少是“内存检验”“注册表检验”“安装测试”“文件完整性测试”……等等分支里。总之，在软件处在相对静态的时候，你能深入想出软件的多少属性，那么就能写多少Case。进而，你能想出多少直接和间接影响软件这些属性的环境因素，就又有多少Case出现……然而，我们的思考能力是有限的，我们几乎不可能把软件的所有属性都想到，我们也不可能把所有可能影响软件静态属性的环境因素都找出来——即使是使用各种静态测试工具，比如内存跟踪工具等——也不可以完全做到。

   上文说过，“试”是动态的。对软件的动态测试比较复杂，一是要时刻提醒自己要识别一些相对静止的属性，把对它们的观测提出来，二是动态测试要分析的东西也比较多——但并不是没有章法。
　　软件动态测试之“道”，只有两个字，那就是——宇宙。
　　古往今来谓之“宇”，它强调一个时序关系。我们在动态测试的时候，特别要注意软件操作的时序，因为每一步的操作都在直接和间接地影响着后面的操作。
　　上下四方谓之“宙”，它强调一个空间关系。如果我们把软件看作一个系统，那么“宙”就是这个系统的环境。
　　举个简单例子，我们观察上面的测试流程中的第3步“安装”：
　　它的“宇”就是前两步和后几步，如果“宇”中的第2步出了问题——下载的时候文件出了问题，那么安装肯定要失败的。
　　它的“宙”中有一项是硬盘空间，如果硬盘空间不足，那么安装也是要失败的。
　　所以，我们在做软件的动态测试时，要把测试中的“宇”和“宙”想周全。
　　那么，怎样才能把“宇”和“宙”想周全呢？

软件测试的生命之图
 
　　如果把软件从启动到关闭看作是一次生命的话，那么软件的生命会是一张非常美丽的生命之图——这张图的起点是软件的Start，然后每一步你都有一个或者若干选择，从而让用户可以有多个达到下一步的通路，这些通路有的是可逆的，有的是单行的，有些是可跳过的……总之，我们最后会达到软件生命的另一端——关闭。
　　虽然这是一个“图”数据结构，但是对每个通路的遍历却是一条线（我是说线性的步骤），其中包含一些可以回溯的步骤。而每条线又是由有限个线段构成的。
每条线段由两个端点和一条连线构成。两个端点，一个是起点（我称它为“起点场景”），一个是终点（我称它为“终点场景”），中间的连线是从起点到终点的“动作”。（目前CSDN没法上传图片，过几天我补上图）
　　那么有个问题：这条小线段有几种走法？OK，让我们来分析一下——
1.起点、正确操作、终点。（基线测试）
2.起点、错误操作、终点。
3.起点、正确操作、终点、正确操作、起点。
4.起点、错误操作、终点、正确操作、起点。
5.起点、正确操作、终点、错误操作、起点。
6.起点、错误操作、终点、错误操作、起点。
7.起点、部分正确操作、放弃、起点。
8.起点、部分错误操作、放弃、起点。
　　别忘记还有“宇”的问题，操作的上一步、下一步组合起来会如何？如果这一线段之前的“宇”都是正确的，那么这样的测试是常规的。如果此前的“宇”已经在某步出了问题（我称之为“错误传递”）那这对软件的质量就是考验了：我认为，凡是能在“宇”中传递下来的数据，都是正确的；如果有错误被在“宇”中传递，那么这就是软件的缺陷。有了这一点，情况似乎简单多了——我们只需要检查这几项就足够了：
1.起点状态的正确性。
2.操作输入的正确性（小到简单的鼠标点击，大到多项数据的组合输入，边界检验，默认值等）。
3.终点的正确性（如果有错误，软件是否通过报错而阻止错误在“宇”向下中传递）。
4.可返回性。
5.返回操作的输入。
6.返回起点后状态正确性的检查。

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

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

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

    从事软件测试工作以来，一直很喜欢在51testing上逛，喜欢看大家的原创。但自己的日志不多，有点惭愧。来这里写日志，一是为了感谢大家，二是记录自己所思考的问题，待以后回味。

    刚毕业那会，不知道自己应该找什么样的工作。偶然的得到了一个软件测试实习岗位，然后进入了软件测试领域。从来没有象现在这样会开始独立思考一些问题，很想知道自己现在是什么水平。

软件测试部门的核心职能是什么?

1.协助项目团队高质量完成软件,以节省开发成本[丰富的业务领域知识+项目经验];

2.产品发布前,发现尽可能多的缺陷,减少维护成本,保持用户信心[在尽量真实的测试环境中运行高覆盖率的测试用例];

3.正确评价软件,建立用户信心[软件测试报告];

4.而软件质量最终是需要良好的流程来保证。

公司更看重员工的工作态度,技术高的人,如果不能让企业觉得塌实,会得不到提升;相反,工作踏踏实实,技术能力平平的人,容易得到提升.一个人的技术可以在实际工作可以无形地得到提升.而工作态度的树立一定要靠个人的意识

经历过才会明白.要勤于向领导汇报自己的工作情况,不然很容易"吃亏".特别是在小公司里做测试的,流程等各方面的不完善,工作压力会比较大.一定要记录下自己的工作,并且汇报给领导.

在缺乏缺陷管理的情况下,如果你仅仅只是将测试得到的问题反馈给开发，开发解决问题.缺少向上级汇报的过程,领导将对你的绩效毫不知情.

所以在公司,如何让自己的工作成果体现出来极其重要,特别是在绩效考核没有标准,全凭领导印象说话的公司.

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