有个做测试的同行朋友，最近跟我发牢骚，说她现在负责一个项目的测试工作，每次送测的质量都非常差，她跟项目经理反映后，项目经理意识到要对送测质量严格把关，接着又引起了另外一个问题，就是开发人员在送测前，总是需要测试人员协助测试，并且会反复很多次，这样把她的工作计划全部打乱了，并且送测的时间也延迟了很多。

    听了朋友的倾述，我感觉怎么就跟我现在的公司一样，想必不少测试同行都遇到类似的问题吧。说实在的，我们公司现状也差不多，开发人员过度依赖测试人员，都已经懒得自测了，我感觉这个现状必须得改变了，否则，测试太被动，并且对整个项目的进度都不利。现在说说自己的想法。

    一、流程规范：明确接受测试的标准，测试通过的标准；
    二、加强开发人员自测：要求送测前由开发人员执行相关的测试用例（由测试人员筛选部分重要的测试用例，这里说重要的，一般情况下是优先级最高的，以及回归测试用例），待这些测试用例执行通过再送测。（前提：测试人员在编码前，完成测试用例的设计，包括业务流程测试用例的设计；）
    三、制定赏罚制度：如果送测质量不达标，不仅仅对整个项目的绩效产生影响，更对相应开发人员的绩效产生影响。（这个赏罚制度最好是精神、物质相结合）可以鼓励送测通过率最高的开发人员，也可以对送测通过率最低的开发人员进行适当的批评；

    目前，我就想到这些，大家可以一起讨论一下，有什么好的解决办法都说说吧~~

本文作者：杨明华
转自：http://www.51testing.com/html/03/n-16903.html

---------------------

　　对于一个测试人员来说测试用例的设计与编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术，它需要你对整个软件不管从 业务还是功能上都有一个明晰的把握。如何系统、结构的对用例加以规范将直接影响到其后的测试效率和效果，同时测试用例也将用来控制软件的整体执行覆盖，对 最后的测试结果给出一种量化的评估标准。

　　一、问题：

　　许多测试类的书籍都有大幅篇 章介绍用例的设计方法，如等价类划分，边界值，错误推断，因果图，判定表等。但实际应用中这些理论却不能给我们很明确的行为指导，尤其是业务复杂，关联模 块紧密，输入标准和输出结果间路径众多时，完全的遵循这些方法只能让我们在心理上得到一种满足，而无法真正有效的提高测试效率，并且我们也没有足够的时间 和资源编写完备的用例。通常我们只能依靠以前项目的用例编写经验（或习惯），希望能在这一个项目中更加规范，但多数情况下我们规范的只是“书写的规范”， 在用例设计上以前存在的问题现在依旧。

　　当好不容易用例基本完成，我们却发现面对随之而来的众多地区特性和新增需求，测试用例突然处于一种十分尴尬的境地：

　　* 从此几乎很少被执行

　　* 已经与程序的实现发生了冲突（界面变动，功能变动）

　　* 执行用例发现的bug很少

　　* 根本没有时间为新的功能需求增补用例

　　* 有时间补充，但用例结构越来越乱

　　* 特性的用例与通性用例之间联系不明确（以新增需求为主线列出所有涉及到的更改，但特性与通行之间的数据或业务联系在用例中逐渐淡化）

　　知道怎样执行这个用例，但它要说明什么呢？（多数用例给我们的感觉是只见树木，不见森林，只说明某一功能的实现，无法串起）

　　通过上面的一系列问题可以看到，似乎测试用例给我们带来的问题远多于益处，也正是因为在实际过程中遇到的问题积累，导致我们有很充分的理由忽视或拒绝用例的应用。

　　但没有用例或简略用例的编写我们又会舒服很多么？不言自明，谁也不想倒退发展。

　　二、原因：

　　事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现，究其原因我认为有如下几点：

　　1、没有适合的规范

　　“适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题，通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、指导步骤和书本上的定义，但它适合我们当前的项目么？

　　每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语，进入公司或项目组后也会进一步学习相应的文档，例如怎样规范编写，怎样定义bug级别，软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时，又有多少人知道该怎样去写，怎样写算是好？

　 　在测试论坛中常能看到介绍用例编写方法的帖子，而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范？于是我们 只得选择从书本或之前的用例中复制，不管是结构还是方式都依赖于以往的经验，我并不是说这样就是错误的，但不能总结成文的经验无法给予测试更多帮助。我们 有太多经验，但却没有形成适合的规范。

　　2、功能与业务的分离

　　我们知道怎样列举一个输入框的用例，但却很少考虑说明这个输入框是用来做什么的，如果仔细分析不难发现，用例中这种功能与业务的分离越来越普遍也越来越明显。

　　边界值、等价类划分、因果图，这些用例方法是一种高度提纯的方法，本身就很偏向于功能及代码，所以怎样编写业务的用例我们就从理论上失去了参考。

　 　复杂的业务会贯穿于整个软件，涉及众多功能点，里面组合的分支更不可胜数。测试用例务求简洁、明确，这一点也与业务“格格不入”。功能用例依赖程序界 面，业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例，列举出众多的边界值、等价类。流程的操作只有凭借经验和理解，这时测试出的 bug是最多的，但我们却无法使这个bug对应到一个用例中（点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体），只能自己添加note向 开发人员指出可能出错的源头。正因为我们没有很好的积累业务上的用例，才使得我们感到执行用例时发现的bug不多。

　　用例结构的划分一定程度上也造成了功能和业务的分离，依照界面模块建立文件夹，并在其中新建不同用例，这使得用例从结构上就很难联通起来。

　　3、测试未能跟上变化

　　变化！想象一下，当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候，测试又有什么举措呢？当地区特性，软件版本越来越多 的时候，测试是否在积极响应呢？变化是我们面临的最大挑战，我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

　　对需求和程序的变化测试人员的感受是非常深的，测试总是跟在需求和开发后面跑，使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作：尽快投入测试，尽快发现bug，而非从整体把握软件的质量情况，统筹策略。

　　疲于应对的直接影响就是程序质量无法准确度量，进度无法控制，风险无法预估。用例与程序脱节，新增用例混乱和缺少。长此以往我们只得放弃修改、 增补用例，甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要，没有测试数据的保留，测试步骤和重点无法体现，新加功能与原来的程序逐渐“脱离”， 可能还会出现相互违背的情况，但这我们却无法及时发现。

　　永远是变化决定我们的下一步工作，这也是混乱的开始。

　　三、可能的解决办法：

　　上面的问题也许在成熟的公司和项目组内很少遇到，而遇到问题的也需根据不同的情况单独考虑。分析错误并不能给我们带来成功，而成功的特质也不会尽为相同。所以在这里我希望以探讨的方式提出一些可能的解决办法，不拘泥形式，以结果来确定，最适合的就是最好的。

　　1、测试驱动开发，用例指导结果，数据记录变化

　　“测试驱动开发”（TDD）是一个比较新的概念，在网上可以看到很多介绍文章，它主要讨论如何让开发的代码更奏效（Work）更洁净 （Clean），“测试驱动开发的基本思想就是在开发功能代码之前，先编写测试代码”。可以看到，TDD是建立在“代码”级别的驱动，但目前我们需要探讨 的问题是怎样在黑盒测试中做到“测试驱动开发”。

　　首先我们需要纠正一个态度，很多人认为黑盒测试的技术含量不高，可思考可拓展的内容不多，主要的工作就是用鼠标在那里瞎点，于是很多“高级”的 技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80％以上都是黑盒测试发现的，手工操作软件仍是目前检验软件质量最有效的一种方法。

　　如何在黑盒测试中做到测试驱动开发？我认为可以从用例级别做起，以业务用例指导实现的结果。

　　开发人员通常比较关注技术，对于业务上的理解容易忽视并出现偏差，而需求文档又不会很全面的指出应该实现怎样的结果，这就使得从业务到功能出现 一个“阅读上的障碍”，如果最后发现程序错了还需返工，这样耗费的人力物力就非常大了。测试人员和最终用户不用过分关心软件实现的细节，所以以业务用例驱 动开发，就是一个比较好的方法。给出一个明确的预期结果，指导开发人员如何界定是否达成目标，同样这也需要运用测试中的各种方法，列举出业务流程里数据的 等价类和边界值。

　　业务用例的构造要先于程序实现，与需求和开发人员沟通一致，并以此作为一个基准，保证程序实现不会出错，还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面，但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

　　我们不仅要应对变化，还要记录变化，使测试用例成为对程序持续性的监控，数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段 （业务段与程序中以窗体或页面的划分是不一样的），使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享，最理想的情况就是建立一个 “数据库”，每个业务用例都从“数据库”中取得输入数据和预期结果，这个数据只是针对业务入口和出口的，当程序内部设计变更时，保留的数据不会因此而作 废。举一个例子，例如我的程序要从某种文件中读取数据并计算结果，一段时间后程序内部字段增加了，如果是以保存的文件附件方式提供数据，则现在程序很可能 就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入，而不关心程序内部结构。

　　再进一步的话“数据库”就开始涉及到程序内部的接口，属于单元和集成测试，这需要开发人员的配合。

　　2、为用例标明时间（版本）和优先级

　　为测试用例标明时间或版本可以起到一种基准的作用，标明项目进度过程中的每一个阶段，使用例直接和需求基线、软件版本对应。同样这需要规范流 程，也是对变更的一种确认和控制。或者可以为用例增加一个状态，指明这个用例目前是否与程序冲突，当程序变更时改变用例的状态，并更新用例版本。

　　为测试用例标明优先级可以指出软件的测试重点、用例编写的重点，减少用例回归的时间，增加重点用例执行的次数，帮助项目组新人尽快了解需求，在自动化测试的初期也可以参考这个优先级录制脚本。

　　3、功能用例与业务用例分开组织

　　为业务用例单独开辟出一种分类，将功能用例与业务用例分开组织，按照不同关注点列举执行路径。业务用例应在开发前或同期编写，帮助测试人员和开 发人员明确业务，了解正确流程和错误流程。功能用例更依赖于程序界面的描述，但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重 的bug，也许与业务无关，但用户往往很容易这样操作（例如登录名，你是否考虑到很长的名字，或者用户的键盘有问题，总是敲入n多空格在里面，这与业务无 关，但程序将会怎样处理？）。

　　4、审核用例，结对编写

　　测试组长或经理对用例进行审核可以做到用例的补充和校对，但一般情况下是很难做到的，我们可以采用另一种方法，就是结对编写测试用例（前提是你有两个以上的测试人员），内部审核。

　　测试用例不是自己编写自己执行，它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”，同时也能拓展思维，加强测试重点的确认，小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理负担，提高组员的参与积极性。

　　四、发展

　　上面的这些解决方法只是一种建议，具体如何实施到项目中还需根据情况而定。同时即使我们正在积极的寻求改变，我们还是会碰到无数的新问题和新苦恼，也许会比以前更为众多，这是我们必须付出的。

　　可以看到测试的发展方向很多很广，即使传统的黑盒测试并不是毫无新意，高级的测人员必须同时在测试技巧和专业领域方面都有很高的“修为”。测试工作怎样更适合我们而发展，将给予我们更多的思考。

    项目计划变化一般分为：需求变化、资源变化、进度变化3种。

一、需求变更：
    当出现需求变更，测试负责人应该分析变更对测试进度的影响，并要求足够的资源与进度，当资源与进度得不到满足时，需要识别出项目风险，并做出风险预警。

二、资源变化：
    做好测试资源，特别是测试主管的备份，项目内的资源被调出时，可以由测试主管跟踪项目进度。

三、进度变化：
    当项目需要提前交付时，一定要做好风险管理与预警。
    在任何时候都不要让测试进度失去控制，都要知道目前测试所处的阶段，并针对目前的情况实时分析，考虑下一步的计划。
    还需要实施跟踪目前项目的风险，当临时遇到发布要求时，能尽可能的提供目前的风险，并能提前做好风险应对措施。

    1. 测试前细化需求，保证对需求理解正确，避免提交存在歧义的缺陷：
    测试人员不能在测试时仅仅凭自己的经验、想法来随意提交缺陷，每个缺陷必须有对应的需求作为支撑。如果认为是需求存在歧义，这样的情况，应该是在测试前与项目组成员进行沟通，达成一致观点。尽量减少理解上的歧义，力争尽早消除无效或争议的软件缺陷。

    2. 对于自己把握不准的缺陷，提交前进行讨论：
    在测试过程中，特别是介入项目时间较短的测试人员，由于对业务 或需求理解不深，很有可能遇到对缺陷把握不准的情况，这个bug是否该提交呢？这种情况，最好是跟有经验的测试人员或者需求人员讨论一下，在大家意见一致 时再提交。否则，项目中出现了这样的bug，不仅很难说服开发人员去修改，还有可能让开发人员怀疑你的能力。

    3. 在提交bug之前，一定要保证bug能够重现，并且在bug中清楚的描述重现步骤：
    有些测试人员在一发 现bug，就马上提交到缺陷系统，甚至连bug出现的环境，重现的步骤都没有搞清楚，结果到后来开发人员看不明白，自己也无法重现。这种情况出现多了，提 交缺陷的认可度就会大大降低。所以，在提交bug之前，最好自己多次重现这个bug，搞清楚是在什么情况下，按什么步骤会出现这个问题（最好是找出重现 bug的最简单步骤），另外，一定需要有截图，让开发人员认识到这个问题的确存在，增强说服力，并且也让开发人员更加容易定位缺陷。
对于较难重现的bug，需要截图，并且说明在什么情况下出现的概率，最好是在保留测试环境的情况下，及时找开发人员跟踪，弄清楚原因。

    4. 保证测试环境的准确性，并且做好版本的配置管理：
    有些bug只有在测试环境中才可以出现，而在开发环境下 是不能重现的。这样的缺陷很容易让开发人员认为是提交了无效的缺陷，实际上是开发与测试的版本不一致。对于这种情况，我们需要做好版本的配置管理，保证测 试环境版本的正确，测试环境部署正确，以及测试环境的独立性。只有这样，才可以减少一些不必要的沟通，轻松说服开发人员修改bug。

    报表功能的基本要求，就是通过查询、统计、分析，为用户提供准确的数据，帮助用户做出决策。在此主要是与大家分享一下报表测试的经验。

一、熟悉业务：
    对任何软件进行功能测试，都必须要熟悉业务，包括业务流程和业务规则。但是报表测试同一般的业务功能测试还 是有些区别的，比如：报表的业务很难直接通过对界面的浏览和探索性操作去了解业务。对于报表业务的熟悉，主要是两个方面：数据项的算法和数据来源，也就是 说要明白一个数据项同具体的业务有什么关系，单据的增、删、改或者状态的变化，对报表中各个数据项的计算会产生什么不同的影响。如果不知道到这些，那么就 无法验证报表中的数据是否准确，也无法通过报表去检查业务系统的正确与否。

二、准备完整、高效、专用的数据：
    1、从查询统计方法角度准备数据：尽可能覆盖到报表所提供的各查询统计方法的数据，至少保证每一种查询统计方法都应该有对应的数据，得到的结果不是0，否则等于没有覆盖到这个查询统计算法。

    2、从数据源的属性来准备数据：这里涉及到的方面比较多，都是跟数据来源有关，现举例说明：a.同样的业务数据来源于多个数据表， 则需要准备多个数据表中的数据；b.与状态相关的数据，有些状态需要纳入统计，有些不需要，但这些数据都需要准备；c.数据来源与显示数据不同时，比如在 数据库中存储的是1，显示时则需要显示为“是”。等等。。。

    3、从数据项的算法来准备特殊数据：比如：除数为0，以及与0相加，是否可以得到正确的结果；

    4、数据的优化：按上述的方法基本上可以准备比较完整的数据了，但数据也不是越多越好，为了提高测试效率，需要对数据进行优化，尽量保证用最少的数据覆盖所有可能的情况。

    5、为报表准备专用的数据：即使个人精心准备了报表数据，如果多人同时测试，或者本人在测试业务时，录入了其他数据，都会对报表的 数据产生影响；所以需要在开始测试时，团队内对数据的准备达成一致，使数据中的某一项具有特征性，例如分别使用不同的供应商，或者使用不同的商品。

    6、做好数据环境的备份和维护：
    数据文档的备份与维护：
    在测试过程中难免会因为误操作导致环境的变化，例如：不小心把一张单据变成了另外一种状态，或者某个类型的单据多做了一张。对于这种情况，一个简单的方法就是去维护数据文档。当然，前提就是需要对原始的数据文档进行备份。

    测试数据库的备份与恢复：
    如果想减少回归测试的工作量，那么应该考虑在一些关键的“点”上备份测试数据。例如所有的基础数据与单据已经输入完成，但是还都没有开始审核，那么可以备份一下，下次再测的时候可以直接在数据库中恢复这部分原始数据。

    另外：
    在准备报表数据的过程中，还需要多与开发人员进行沟通，一来可以了解开发人员采用的算法是否与需求符合；二来可以更加明确数据的来源。
    在进行业务功能的测试时，可以通过业务测试的过程，把报表测试所需要的数据输入到系统中。

三、在业务功能测试通过之后才开始：
    业务功能测试是报表测试的基础。如果业务功能本身存在缺陷，导致的数据不准，那么进行报表测试也就没有什么意义了。所以，应该在保证各项同报表有关的业务的功能测试通过之后，才开始考虑对报表进行测试。

四、尽可能覆盖报表所提供的各种查询统计方法：
    报表的使用者一般是企业的中层或高层领导，他们对于报表的要求可能会是多方 面的，例如在进销存系统中，可能需要按不同商品进行分类统计，也可能是按供应商分类统计，这些都是由用户在实际工作中的需要来决定的，所以假如一个报表提 供了多种查询统计的方法，那么在测试时，只要时间充分，就应该覆盖这些所有可能被用到的查询统计方法。

五、对存在联系的多个报表进行相互对照：这需要非常了解各报表之间存在的联系。例如：库存报表中，可以看到商品的出入库情况，而在销售报表中，可以看到商品的销售金额和销售成本金额，对业务熟悉到一定程度就会知道实际上这两种报表之间就存在着某种联系。

六、着重对那些算法复杂、与业务功能关联较多的报表的测试。

七、留意数据的显示：小数位,千位符,四舍五入等是否与报表设置一致；单位转换是否正确；组合显示的数据是否合理 ；数据的排序。等等。。。

八、保证测试人员可以通过软件功能界面找到自己所需的所有原始数据，而不是通过SQL语句来查找，因为实际用户在使用软件时，是不会到数据库中查找数据的。

九、对有些报表需要考虑权限控制和访问安全性的测试。

十、大数据量的测试。

最近测试一个项目，里面有很多地方需要由Excel导入数据的，虽然有各自不同的模板以及业务约束，但从测试用例的设计思路来说，还是差不多的，现总结如下：
一、导入成功（细分还有下面几种输入）
1、数据符合规则，并且前后无空格
2、数据符合规则，但前后有空格
3、某些行存在空格，并且无有效数据（或者将原来存在数据的单元格中的数据直接删除，Excel中对直接删除数据以及删除行之后的结果还是不一样的，有时直接删除数据会被认为该行仍存在只是数据为空）
4、数据从Word文档或者外部拷贝
5、大数据量导入（在允许范围以内）
6、仅输入必填项
7、模板最后一列后面存在多余列

二、导入失败-模板格式有误
1、模板文件的格式不正确
2、模板列名错误
3、模板列的位置不正确
4、缺少列
5、列名不正确
6、模板所在的工作表位置或名称不正确
预期结果：导入失败，并给出提示：导入失败，模板格式有误

三、导入失败-数据为空
预期结果：导入失败，并给出提示：导入失败，导入模板中无任何数据

四、导入失败-必填项为空
预期结果：导入失败，并给出提示：导入失败，并说明具体某一行的某个字段为空

五、导入失败-数据不符合规则
1、所有行均存在格式不符合规则的数据
2、所有行均存在超出长度范围的数据
3、部分符合规则，部分不符合规则

对于1、2的预期结果：导入失败，并给出提示：导入失败，并给出每一行对应的错误原因
对于3的预期结果，根据需求不同，可能存在下面两种情况：
3a、符合规则的导入成功，不符合规则的导入失败，并给出失败行对应的错误原因
3b、导入失败，并给出失败行对应的错误原因

六、导入失败-模板内的数据之间存在重复
预期结果，根据需求不同，可能存在下面两种情况：
a、除重复行之外的其他数据导入成功，重复行中的第一行导入成功，后面一行导入失败，并给出失败行对应的错误原因
b、导入失败，并给出失败行对应的错误原因

七、导入失败-模板内的数据与系统中已经存在的数据冲突
预期结果，根据需求不同，可能存在下面两种情况：
a、除存在冲突之外的其他数据导入成功，存在冲突的行导入失败，并给出失败行对应的错误原因
b、导入失败，并给出失败行对应的错误原因

八、导入失败-数据超出可以导入的范围（跟具体业务相关）
与第七点的预期一致

九、导入失败-不选择导入文件
预期结果：无法导入，提示：请选择导入文件

十、取消导入
预期结果：取消导入操作成功，并不执行导入操作

十一、导入失败-模板内的数据存在冲突（比如：截止日期小于起始日期之内）
预期结果：与第七点预期一致

--------------------------------------
除了上面对导入功能的测试以外，还需要检查模板是否正确，是否能够很好的引导用户输入数据，所以最好对模板进行一下检查：
1、模板是否正确
2、是否对必填项做了说明
3、是否对字段长度的约束做了说明
4、是否对特殊字段的格式做了说明

二、与时间相关：
修改时间：date -s "06/15/2009 01:01:01"

查看当前时间：date

关闭时间同步：echo "1" > /proc/sys/xen/independent_wallclock

开启时间同步：echo "0" > /proc/sys/xen/independent_wallclock

一、与mysql相关命令：
查看mysql版本号：mysql --version

进入mysql：mysql -u用户名 -p密码

重启数据库服务：service mysql restart  或者 sudo /etc/init.d/mysql restart

导出数据库：mysqldump -R -u用户名 -p密码 数据库名 > /导出文件夹/导出文件名.SQL

给指定用户授权：
grant all on *.* to 用户名@'%' identified by '密码';
grant all on *.* to 用户名@localhost identified by '密码';

一、安装服务端：
　　以MySQL-server-4.0.14-0.i386.rpm为例，放在/data目录下

　　cd /data
　　rpm -ivh MySQL-server-4.0.14-0.i386.rpm

　　安装完成后在/usr/share/mysql目录中会有一个mysql的启动脚本mysql.server及示例配置文件等(如my-huge.cnf、my-large.cnf、my-medium.cnf)

　　拷贝一个示例配置文件作为mysql的配置文件：
　　cp /usr/share/mysql/my-medium.cnf /etc/my.cnf

二、启动、停止、重启mysql

　　rpm包安装完后自动将mysql安装成系统服务，所以可以使用下面命令启动、停止mysql

　　启动mysql
　　/etc/init.d/mysql start 或 service mysql start

　　停止mysql
　　/etc/init.d/mysql stop 或 service mysql stop

    重启mysql
    /etc/init.d/mysql restart 或 service mysql restart

三、安装mysql客户端

　　rpm -ivh MySQL-client-4.0.14-0.i386.rpm

　　mysql安装好后目录结构如下：

　　工具程序在/usr/bin目录中－－－ls /usr/bin/mysql*

　　服务器程序/usr/sbin/mysqld

　　数据目录/var/lib/mysql

　　默认情况下mysql将错误日志文件、二进制日志文件及进程文件写在/var/lib/mysql目录中,如localhost.err、localhost.pid、localhost-bin.001等

　　要改变这些情况可以修改/etc/my.cnf文件

　　如将日志文件写在/var/log目录中，可以在my.cnf文件中加入下面两行：

　　[mysqld_safe]

　　err-log = /var/log/mysqld.log

　　有个实用程序/usr/bin/mysql_install_db，该程序可以用来初始化mysql数据库，即创建/var/log/mysql目录，及创建mysql数据库(mysql授权表等信息)及test数据库(空库),如果不小心删除了/var/log/mysql目录可以通过该程序来初始化.

四、卸载mysql

　　rpm -qa|grep -i mysql

　　rpm -ev MySQL-server-4.0.14-0 MySQL-client-4.0.14-0

　　卸载后/var/lib/mysql中的数据及/etc/my.cnf不会删除，如果确定没用后就手工删除
　　rm -f /etc/my.cnf
　　rm -rf /var/lib/mysql

    注意：当卸载包时出现同一个包出现两次，卸载提示：specifies multiple packages，此时用下面命令删除
    rpm -e --allmatches 包名



|          指定选项                  |
+--------------------------------+
|--test       | 卸载测试            |
|--nodeps     | 不检查依赖          |
|--noscripts  | 不执行脚本程序      |
|--notriggers | 不执行触发程序      |
|--allmatches | 卸载所有匹配包      |
|--justdb     | 仅修改数据库        |
+-------------+------------------+
|          通用选项                  |
+--------------------------------+
|-v           | 显示附加信息        |
|--v          | 显示调试信息        |
|--root 目录   | 指定根目录          |
|--rcfile 文件 | 指定RPM资源配置文件|
|--dbpath 目录 | 指定RPM数据库目录  |

   近期公司比较强调业务流程的测试，本人就总结一下业务流程的测试经验与大家分享，欢迎大家多提意见。

一、业务流程整理

1、充分掌握业务知识，业务流程以及业务的数据流向。
站在用户的角度思考，而不仅仅考虑在系统中如何操作业务流程；搞清楚每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。

2、从需求人员或者客户那里了解到各业务流程的重要程度和使用频率。
（这点对把握测试重点很重要）

3、了解业务流程在系统中对应的功能。
（建立业务与系统的映射，为编写测试用例做好准备）

二、编写测试用例（在需求文档以及UI原型评审之后）

1、绘制业务流程图（对于较简单的流程，也可以用文字描述的形式，但流程图比较直观，也便于进行路径的分析）。

2、根据业务流程的重要程度、使用频率为各流程设置好优先级。

3、采用场景法、路径法或其他方法（方法其实是不固定的，有时候可以综合使用多种方法）梳理出每个业务流程在系统中对应的操作步骤，形成业务流程的测试用例。
注意：
    * 这里的操作步骤没有必要像功能点测试用例的步骤那么详细，这个操作步骤可能是一个业务操作集，可以分解成多个步骤，这些业务操作集合，也可以对应具体的功能点测试用例，从而做到测试用例的复用。所以可以说这里的业务流程测试用例就像是将多个功能点的测试用例组合成一个集合，形成一个业务流。
    * 在每个步骤中需要标识出执行该操作的用户角色，因为在一个业务流程中，很可能涉及到不同的角色。
    * 需要平衡项目的进度、成本，不一定需要覆盖所有的路径。

三、测试数据设计

1、输入数据：
   测试业务流程与功能点测试的重点不一样，因此设计测试数据的时候更多需要考虑下面的因素（按重要到次要排列）：

• 关键的判断条件
• 符合业务意义的数据
• 边界数据
• 异常数据
  

   另外，对流程无任何影响的数据，我认为可以在此不考虑，放到功能点测试中更加合适，这样可以减少不必要的干扰。不过，有些功能点对流程的依赖很强，或者业务流程非常简单，也可以将业务流程测试与功能点测试结合。（实际我觉得功能点测试与业务流程测试的数据分开会好一点，因为毕竟重点不一样；但有时迫于进度的压力，也会将这些数据结合在一起）

2、输出数据：
   系统中得到的结果数据以及报表中的数据，都需要体现出来，必要的时候还需要根据报表的格式提供输出数据，以便在测试时进行核对。     

   注意：需要平衡项目的进度、成本，尽可能用少的测试数据发现多的问题。

四、测试执行

   主要在下面几个阶段执行业务流程测试：

1、最主要是在系统测试阶段进行（将优先级高的主要业务流程测试用例作为冒烟测试用例）。

2、在集成测试的后期，已经对部分业务测试流程进行了测试，可以根据系统集成的顺序，在集成测试阶段对部分业务流程进行测试。集成测试阶段重点是测试功能点，功能点测试存在严重问题，是无法进行业务流程测试的，所以一般是等功能比较稳定的时间才会进行业务流程测试。

3、验收测试。

4、个人观点：保证质量最有力的手段还是预防，如果能够将业务流程测试用于测试的前期，比如：用于开发人员进行联调、或者送测前的测试，这样可能会提高送测质量，减少测试轮次，提高编码质量。

--------------------------------------------------------
   另外，有了具体的步骤，以及测试数据，可以结合自动化测试工具进行业务流程测试。