以前在这里看到一篇文章说，要积累各个常用模块的测试点，然后到需要测试的时候就根据这些测试点设计测试用例，我觉得这是一个好方法，就决定总结一下。我的实际经验不多，根据我在论坛中学到的零散的东西和自己的想象，总结出以下几点，欢迎各位继续补充。

　　1、登陆
　　2、添加
　　3、查询
　　4、删除

　　1、登陆
　　① 用户名和密码都符合要求（格式上的要求）
　　② 用户名和密码都不符合要求（格式上的要求）
　　③ 用户名符合要求，密码不符合要求（格式上的要求）
　　④ 密码符合要求，用户名不符合要求（格式上的要求）
　　⑤ 用户名或密码为空
　　⑥ 数据库中不存在的用户名，不存在的密码
　　⑦ 数据库中存在的用户名，错误的密码
　　⑧ 数据库中不存在的用户名，存在的密码
　　⑨ 输入的数据前存在空格
　　⑩ 输入正确的用户名密码以后按[enter]是否能登陆

　　2、添加
　　① 要添加的数据项均合理，检查数据库中是否添加了相应的数据
　　② 留出一个必填数据为空
　　③ 按照边界值等价类设计测试用例的原则设计其他输入项的测试用例
　　④ 不符合要求的地方要有错误提示
　　⑤ 是否支持table键
　　⑥ 按enter是否能保存
　　⑦ 若提示不能保存，也要察看数据库里是否多了一条数据

　　3、删除
　　① 删除一个数据库中存在的数据，然后查看数据库中是否删除
　　② 删除一个数据库中并不存在的数据，看书否有错误提示，并且数据库中没有数据被删除
　　③ 输入一个格式错误的数据，看是否有错误提示，并且数据库中没有数据被删除。
　　④ 输入的正确数据前加空格，看是否能正确删除数据
　　⑤ 什么也不输入
　　⑥ 是否指出table键
　　⑦ 是否支持enter键

　　4、查询
　　精确查询：
　　① 输入的查询条件为数据库中存在的数据，看是否能正确地查出相应得数据
　　② 输入正确的查询条件以前加上空格，看是否能正确地查出相应的数据
　　③ 输入格式或范围不符合要求的数据，看是否有错误提示
　　④ 输入数据库中不存在的数据
　　⑤ 不输入任何数据
　　⑥ 是否支持table键
　　⑦ 是否支持enter键
　　模糊查询：
　　在精确查询的基础上加上以下一点
　　① 输入一些字符，看是否能查出数据库中所有的相关信息

　　设计功能和界面测试用例

　　1.1 文本框、按钮等控件测试

　　1.1.1 文本框的测试
　　如何对文本框进行测试
　　a，输入正常的字母或数字。
　　b，输入已存在的文件的名称；
　　c，输入超长字符。例如在“名称”框中输入超过允许边界个数的字符，假设最多255个字符，尝试输入 256个字符，检查程序能否正确处理；
　　d，输入默认值，空白，空格；
　　e，若只允许输入字母，尝试输入数字；反之；尝试输入字母；
　　f，利用复制，粘贴等操作强制输入程序不允许的输入数据；
　　g，输入特殊字符集，例如，NUL及\n等；
　　h，输入超过文本框长度的字符或文本，检查所输入的内容是否正常显示；
　　i，输入不符合格式的数据，检查程序是否正常校验，如，程序要求输入年月日格式为yy/mm/dd，实际输入yyyy/mm/dd，程序应该给出错误提示

在测试过程中所用到的测试方法：
　　1，输入非法数据；
　　2，输入默认值；
　　3，输入特殊字符集；
　　4，输入使缓冲区溢出的数据；
　　5，输入相同的文件名；

　　命令按钮控件的测试
　　测试方法：
　　a，点击按钮正确响应操作。如，单击确定，正确执行操作；单击取消，退出窗口；
　　b，对非法的输入或操作给出足够的提示说明，如，输入月工作天数为32时，单击”确定“后系统应提示：天数不能大于31；
　　c，对可能造成数据无法恢复的操作必须给出确认信息，给用户放弃选择的机会；

　　单选按钮控件的测试
　　测试方法：
　　a，一组单选按钮不能同时选中，只能选中一个。
　　b，逐一执行每个单选按钮的功能。分别选择了“男”“女”后，保存到数据库的数据应该相应的分别为“男”“女”；
　　c，一组执行同一功能的单选按钮在初始状态时必须有一个被默认选中，不能同时为空；

　　控件文本框的测试
　　测试方法：
　　a，直接输入数字或用上下箭头控制，如，在“数目”中直接输入10，或者单击向上的箭头，使数目变为10；
　　b，利用上下箭头控制数字的自动循环，如，当最多数字为253时，单击向上箭头，数目自动变为1；反之亦适用；
　　c，直接输入超边界值，系统应该提示重新输入；
　　d，输入默认值，空白。如，“插入”数目为默认值，点击“确定”；或，删除默认值，使内容为空，单击“确定”进行测试；
　　e，输入字符。此时系统应提示输入有误。

　　组合列表框的测试
　　测试方法：
　　a，条目内容正确，其详细条目内容可以根据需求说明确定；
　　b，逐一执行列表框中每个条目的功能；
　　c，检查能否向组合列表框输入数据；

　　复选框的测试
　　测试方法：
　　a，多个复选框可以被同时选中；
　　b，多个复选框可以被部分选中；
　　c，多个复选框可以都不被选中；
　　d，逐一执行每个复选框的功能；

　　列表框控件的测试
　　测试方法：
　　a，条目内容正确；同组合列表框类似，根据需求说明书确定列表的各项内容正确，没有丢失或错误；
　　b，列表框的内容较多时要使用滚动条；
　　c，列表框允许多选时，要分别检查shift选中条目，按ctrl选中条目和直接用鼠标选中多项条目的情况；

　　滚动条控件的测试
　　要注意一下几点：
　　a，滚动条的长度根据显示信息的长度或宽度及时变换，这样有利于用户了解显示信息的位置和百分比，如，word中浏览100页文档，浏览到50页时，滚动条位置应处于中间；
　　b，拖动滚动条，检查屏幕刷新情况，并查看是否有乱码；
　　c，单击滚动条；
　　d，用滚轮控制滚动条；
　　e，滚动条的上下按钮。

　　各种控件在窗体中混和使用时的测试
　　a，控件间的相互作用；
　　b，tab键的顺序，一般是从上到下，从左到右；
　　c，热键的使用，逐一测试；
　　d，enter键和esc键的使用；

　　在测试中，应遵循由简入繁的原则，先进行单个控件功能的测试，确保实现无误后，再进行多个控件的的功能组合的测试。

　　ps：密码输入框测试时要特别注意进行字母大写输入的测试。

　　查找替换操作

　测试本功能有通过测试和失败测试两种情况

　　通过测试：
　　1，输入内容直接查找，或查找全部
　　2，在组合框中寻找已经查找过的内容，再次查找并确认文档的内容正确，如，已经查找过"测试用例"，再次进入不用重新输入查找内容，直接在文档中搜寻就可以。

　　失败测试：
　　1，输入过长或过短的查询字符串.如，假设查询的字符串长度为1到255，那么输入0，1，2，256，255和254进行测试；
　　2，输入特殊字符集，如，在word中.^g代表图片，^代表分栏符，可以输入这类特殊字符测试；

　　替换测试大体相同。

　　关于编辑操作窗口的功能测试的用例：
　　1，关闭查找替换窗口.不执行任何操作，直接退出；
　　2，附件和选项测试.假如，设定"精确搜寻"，"向后"搜索等附件选项等等来测试；
　　3，控件间的相互作用.如，搜寻内容为空时，按钮"搜寻全部"，"搜寻"，"全部替换"，"替换"都为灰色。
　　4，热键， Tab键.回车键的使用。

　　插入操作

　　1，插入文件
　　测试的情况
　　a，插入文件；
　　b，插入图像；
　　c，在文档中插入文档本身；
　　d，移除插入的源文件；
　　e，更换插入的源文件的内容；

　　2，链接文件
　　测试方法：
　　a，插入链接文件；
　　b，在文档中链接文档本身；
　　c，移除插入的源文件；
　　d，更换插入的源文件的内容。

　　3，插入对象
　　要测试的内容
　　a，插入程序允许的对象，如，在word中插入excel工作表；
　　b，修改所插入对象的内容.插入的对象仍能正确显示；
　　c，卸载生成插入对象的程序，如，在word中插入excel工作表后卸载excel，工作表仍正常使用。

　　编辑操作

　　编辑操作包括剪切，复制，粘贴操作。

　　测试剪切操作的方法
　　a，对文本，文本框，图文框进行剪切；
　　b，剪切图像
　　c，文本图像混合剪切

　　复制操作方法与剪切类似。

　　测试时，主要是对粘贴操作的测试，方法是：
　　a，粘贴剪切的文本，文本框及图文框；
　　b，粘贴所剪切的图像；
　　c，剪切后，在不同的程序中粘贴；
　　d，多次粘贴同一内容，如，剪切后，在程序中连续粘贴3次；
　　e，利用粘贴操作强制输入程序所不允许输入的数据。

界面测试用例的设计方法

　　1，窗体
　　测试窗体的方法：
　　a，窗体大小，大小要合适，控件布局合理；
　　b，移动窗体.快速或慢速移动窗体，背景及窗体本身刷新必须正确；
　　c，缩放窗体，窗体上的控件应随窗体的大小变化而变化；
　　d，显示分辨率.必须在不同的分辨率的情况下测试程序的显示是否正常；

　　进行测试时还要注意状态栏是否显示正确；工具栏的图标执行操作是否有效，是否与菜单懒中图标显示一致；错误信息内容是否正确，无错别字，且明确等等；

　　2，控件
　　测试方法：
　　a，窗体或控件的字体和大小要一致；
　　b，注意全角，半角混合
　　c，无中英文混合

　　菜单
　　进行测试时要注意
　　a，选择菜单是否可以正常工作，并与实际执行内容一致；
　　b，是否有错别字：
　　c，快捷键是否重复；
　　d，热键是否重复；
　　e，快捷键与热键操作是否有效
　　f，是否存在中英文混合
　　g，菜单要与语境相关，如，不同权限的用户登陆一个应用程序，不同级别的用户可以看到不同级别的菜单并使用不同级别的功能；
　　h，鼠标右键快捷菜单

　　特殊属性
　　1，安装界面应有公司介绍或产品介绍，有公司的图标
　　2，主界面及大多数界面最好有公司图标
　　3，选择"帮助"->"关于"命令，应 看见相关版权和产品信息

　　实际中经常用到的几个用例

　　login
　　1、链接地址是否正确。
　　2、产生输入/输出错误时，系统是否进行检测并处理.
　　3、密码输入框是否按掩码的方式显示。

menu：
　　1、各模块链接地址是否正确。
　　2、鼠标无规则点击时是否会产生无法预料的结果。

　　browse：
　　1、浏览信息是否存在文字书写错误和语法错误。
　　2、浏览信息是否和数据库中对应的字段及信息相一致。
　　3、浏览页面中的链接按钮是否可以正确链接并显示。
　　4、其他功能按钮按下后，数据是否按既定规约处理。

　　add，modify：
　　1、产生输入/输出错误时，系统是否进行检测并处理。
　　2、列表框是否能够进行选择。
　　3、单选组内是否有且只有一个单选钮可选。
　　4、多选组内是否能够进行多数据项选择。
　　5、多项列表框是否能够进行多数据项选择。
　　6、控件是否存在默认输入值，若存在，默认值是否得到显示和提交。
　　7、Cancel之类的按钮按下后，控件中的数据是否清空复原或按既定规约处理。
　　8、Submit之类的按钮按下后，数据是否得到提交或按既定规约处理。
　　9、其他页面按钮按下后，数据是否按既定规约处理。
　　10、异常信息表述是否正确。

　　search：
　　1、输入信息中是否存在和代码中的字符产生冲突的字符，系统是否进行检测并处理。
　　2、异常信息表述是否正确。
　　3、查询的结果是否正确。
　　4、列表框是否能够进行选择。
　　5、单选组内是否有且只有一个单选钮可选。
　　6、多选组内是否能够进行多数据项选择。
　　7、多项列表框是否能够进行多数据项选择。
　　8、Submit之类的按钮按下后，数据是否得到提交或按既定规约处理。

　　Statistic：
　　1、产生的文件和数据表的计算结果是否正确。
　　2、图表结果数据显示是否正确。
　　3、浏览页面中的链接按钮是否可以正确链接并显示。
　　4、其他功能按钮按下后，数据是否按既定规约处理。
　　5、产生输入/输出错误时，系统是否进行检测并处理。
　　6、列表框是否能够进行选择。
　　7、单选组内是否有且只有一个单选钮可选。
　　8、多选组内是否能够进行多数据项选择。
　　9、多项列表框是否能够进行多数据项选择。

　从网上搜索测试用例的评审，也能搜出好多，我这里把自己能想到的或是借鉴于他人的都在这里进行总结和归纳。

　　测试用例的设计很重要，无论你采用的是敏捷测试还是传统的开发模式，测试用例都应该要文档化，并且根据项目的schedule，把握好粒度。而QA lead要根据项目的实际情况，先定好模板，制定好测试用例的编写规范。测试用例设计出来，质量如何？这就需要对测试用例进行评审，这个过程非常重要，对测试人员的能力提高，测试效率的提高都有很好的作用。如果公司流程没有这个硬性要求，项目再忙，也要抽出一定时间，召集相关人员开个哪怕是非正式的评审会议，大家一起讨论用例并给出意见和建议，及时发现问题，并完善测试用例的设计。

　　何时进行用例的评审，一般情况下是在用例的初步设计完成之后进行评审，如果需要或时间允许，在整个详细用例全部完成之后还会进行二次评审，三次评审等。

　　大体分文三个级别的评审：

　　a）部门评审，测试部门全体员工参与的评审。

　　b）公司评审，这里包括了项目经理，需求分析人员，架构设计人员，开发人员和测试人员。

　　c）客户评审，包括了客户方的开发人员和测试人员。

　　测试用例的评审检查单（Checklist for Test cases）：

　　1）Has the correct template been used？（是否使用了正确的模板？）

　　2）Have all the scenarios specified in the requirement –explicit， implicit， nonfunctional and  been converted into test conditions？（是否覆盖了需求规格说明，包括内在需求和外在和非功能需求？）

　　3）Have the related areas that include possibly be affected by the implementation of the requirement been identified and included in the test cases？（case是否对需求变更的部分进行对应的调整和增加？）

　　4）Have the following details been filled up correctly？ Requirement references， test procedure， expected result， priority， author’s name， date created…（测试用例是否正确填写了测试对应的需求，测试步骤，预期结果，优先级，作者姓名，创建日期等..）

　　5）Has the test date set， if required been generated appropriate？ （测试用例是否包含测试数据，测试数据的生成是否正确？）

　　6）Have the required negative scenario between identified in the test conditions？ （是否包含了负面测试用例？）

　　7）Have the testing techniques—equivalence partitioning， boundary value analysis be used？ （是否使用了等价类划分和边界值分析的测试方法？）

　　8）Have the steps been correctly given in appropriate sequence for each test scenario？ （测试步骤是否被阐述清楚？）

　　9）Have the expected result been identified correctly？ （预期结果是否表达正确？）

　　　● Expected results should respond to the user actions given in each step/action.（每个步骤都应给出相应的测试结果）

　　　● Ensure that too many things are not included to be verified under one expected output.（给出一个预期结果的验证步骤不要太多）

　　　● Ensure that separate cases are written for multiple verifications of the application’s behavior. （每条case最好验证一个问题）

　　　● Vague statements like “Appropriate message/value/screen” etc. should not be part of expected result. Every detail should be clearly spelt out. （预期结果中不要使用模糊的语言）

　1、引言

　　测试设计遵循与软件设计相同的工程原则。好的软件设计包含几个对测试设计进行精心描述的阶段。这些阶段是：

　　● 测试策略

　　● 测试计划

　　● 测试描述

　　● 测试过程

　　上述四个测试设计阶段适用于从单元测试到系统测试各个层面的测试。

　　测试设计由软件设计说明所驱动。单元测试用于验证模块单元实现了模块设计中定义的规格。一个完整的单元测试说明应该包含正面测试（Positive Testing）和负面的测试（Negative Testing）。正面测试验证程序应该执行的工作，负面测试验证程序不应该执行的工作。

　　设计富有创造性的测试用例是测试设计的关键。本文档介绍了测试说明的一般设计过程，描述了一些结构化程序设计单元测试中采用的用例设计技术，同时也增加了面向对象编程中对类进行单元测试所采用的测试用例设计技术，这些可作为软件测试人员的参考阅读资料。

　　2、设计单元测试说明

　　一旦模块单元设计完毕，下一个开发阶段就是设计单元测试。值得注意的是，如果在书写代码之前设计测试，测试设计就会显得更加灵活。一旦代码完成，对软件的测试可能会倾向于测试该段代码在做什么（这根本不是真正的测试），而不是测试其应该做什么。单元测试说明实际上由一系列单元测试用例组成，每个测试用例应该包含4 个关键元素：

　　被测单元模块初始状态声明，即测试用例的开始状态（仅适用于被测单元维持了调用间状态的情况）；

　　被测单元的输入，包含由被测单元读入的任何外部数据值；

　　该测试用例实际测试的代码，用被测单元的功能和测试用例设计中使用的分析来说明，如：单元中哪一个决策条件被测试；

　　测试用例的期望输出结果，测试用例的期望输出结果总是应该在测试进行之前在测试说明中定义。

　　以下描述进行测试用例设计，书写测试说明的7步通用过程。

　　2.1 测试用例设计步骤

　　2.1.1 步骤1：首先使被测单元运行

　　任何单元测试说明的第一个测试用例应该是以一种可能的简单方法执行被测单元。看到被测单元第一个测试用例的运行成功可以增强人的自信心。如果不能正确执行，最好选择一个尽可能简单的输入对被测单元进行测试/调试。

　　这个阶段适合的技术有：

　　● 模块设计导出的测试

　　● 对等区间划分

　　2.1.2 步骤2：正面测试(Positive Testing)

　　正面测试的测试用例用于验证被测单元能够执行应该完成的工作。测试设计者应该查阅相关的设计说明；每个测试用例应该测试模块设计说明中一项或多项陈述。如果涉及多个设计说明，最好使测试用例的序列对应一个模块单元的主设计说明。

　　适合的技术：

　　● 设计说明导出的测试

　　● 对等区间划分

　　● 状态转换测试

2.1.3 步骤3：负面测试(Negative Testing)

　　负面测试用于验证软件不执行其不应该完成的工作。这一步骤主要依赖于错误猜测，需要依靠测试设计者的经验判断可能出现问题的位置。

　　适合的技术有：

　　● 错误猜测

　　● 边界值分析

　　● 内部边界值测试

　　● 状态转换测试

　　2.1.4 步骤4：设计需求中其它测试特性用例设计

　　如果需要，应该针对性能、余量、安全需要、保密需求等设计测试用例。

　　在有安全保密需求的情况下，重视安全保密分析和验证是方便的。针对安全保密问题的测试用例应该在测试说明中进行标注。同时应该加入更多的测试用例测试所有的保密和安全冒险问题。

　　适合的技术：设计说明导出的测试

　　2.1.5 步骤5：覆盖率测试用例设计

　　应该或已有测试用例所达到的代码覆盖率。应该增加更多的测试用例到单元测试说明中以达到特定测试的覆盖率目标。一旦覆盖测试设计好，就可以构造测试过程和执行测试。覆盖率测试一般要求语句覆盖率和判断覆盖率。

　　适合的技术：

　　● 分支测试

　　● 条件测试

　　● 数据定义－使用测试

　　● 状态转换测试

　　2.1.6 步骤6：测试执行

　　使用上述5个步骤设计的测试说明在大多少情况下可以实现一个比较完整的单元测试。

　　到这一步，就可以使用测试说明构造实际的测试过程和用于执行测试的测试过程。该测试过程可能是特定测试工具的一个测试脚本。

　　测试过程的执行可以查出模块单元的错误，然后进行修复和重新测试。在测试过程中的动态分析可以产生代码覆盖率测量值，以指示覆盖目标已经达到。因此需要在测试设计说明中需要增加一个完善代码覆盖率的步骤。

　　2.1.7 步骤7：完善代码覆盖

　　由于模块单元的设计文档规范不一，测试设计中可能引入人为的错误，测试执行后，复杂的决策条件、循环和分支的覆盖率目标可能并没有达到，这时需要进行分析找出原因，导致一些重要执行路径没有被覆盖的可能原因有：

　　不可行路径或条件——应该标注测试说明证明该路径或条件没有测试的原因。

不可到达或冗余代码——正确处理方法是删除这种代码。这种分析容易出错，特别是使用防卫式程序设计技术（Defensive Programming Techniques）时，如有疑义，这些防卫性程序代码就不要删除。

　　测试用例不足——应该重新提炼测试用例，设计更多的测试用例添加到测试说明中以覆盖没有执行过的路径

　　理想情况下，覆盖完善阶段应该在不阅读实际代码的情况下进行。然而，实际上，为达到覆盖率目标，看一下实际代码也是需要的。覆盖完善步骤的重要程度相对小一些。最有效的测试来自于分析和说明，而不是来自于试验，依赖覆盖完善步骤补充一份不好的测试设计。

　　适合的技术：

　　● 分支测试

　　● 条件测试

　　● 设计定义——试验测试

　　● 状态转换测试

　　2.2 用例设计的一般原则

　　注意到前面产生测试说明步骤可以用下面的方法完成：

　　通常应该避免依赖先前测试用例的输出，测试用例的执行序列早期发现的错误可能导致其他的错误而减少测试执行时实际测试的代码量；

　　测试用例设计过程中，包括作为试验执行这些测试用例时，常常可以在软件构建前就发现BUG。还有可能在测试设计阶段比测试执行阶段发现更多的BUG。

　　在整个单元测试设计中，主要的输入应该是被测单元的设计文档。在某些情况下，

　　需要将试验实际代码作为测试设计过程的输入，测试设计者必须意识到不是在测试代码本身。从代码构建出来的测试说明只能证明代码执行代码完成的工作，而不是代码应该完成的工作。

　　3、测试用例设计技术

　　广义地分为两类：

　　黑盒测试：使用单元接口和功能描述，不需了解被测单元的内部结构

　　白盒测试：使用被测单元内部如何工作的信息

　　灰盒测试：借助于源代码和测试工具等手段，通过黑盒和白盒测试相结合的方法进行测试的技术。

　　测试设计最重要的因素是经验和常识。测试设计者不应该让某种测试技术阻碍经验和常识的运用。

　　白盒测试用例设计：使用程序设计的控制结构导出测试用例。

　　采用白盒测试的目的主要是:保证一个模块中的所有独立路径至少被执行一次；对所有的逻辑值均需要测试真、假两个分支；在上下边界及可操作范围内运行所有循环；检查内部数据结构以确保其有效性。

　　黑盒测试用例设计：使用详细设计导出测试用例。

　　采用黑盒测试的目的主要是：检查功能是否实现或遗漏；检查人机界户是否错误；数据结构或外部数据库访问错误；性能等其它特性要求是否满足；初始化盒终止错误。

　目前国内出版的软件测试方面的书，深入讲解编写软件测试用例方法的很少，而且大多数方法都是很理论的描述。另外，最大的问题是把测试用例的确定输入数据的方法说成是测试用例的设计方法。

　　例如，关于测试用例设计方法，最常用的说法是：等价类，边界值，因果图等。实际上这些只是软件测试用例设计中如何确定测试输入数据，对于对话框中的数据控件输入值有效。如果把确定输入数据的方法，描述成测试用例的方法，那么，这样设计出来的测使用例就很有局限性。

　　实际上，编写测试用例包括两个方面：第一是编写测试用例输入数据，第二是编写测试用例实体（即包含测试目标，测试步骤，测试期望结果）。

　　为此，有必要把编写测试用例的工作分解成两个阶段：第一阶段称为“测试用例设计”，第二阶段称为“测试用例实现”。第一阶段的任务是如何确定测试用例的组织结构（模块化、阶段化），模块化即把被测软件分解成各个模块，每个模块组织成测试用例组。阶段化即按照软件开发的不同阶段分别编写软件测试用例，例如单元测试用例、系统测试用例、验收测试用例等。

　　编写软件测试用例的过程如图所示。

如下观点，只代表我个人观点，如有偏差，还望各位同行提出相应观点和意见。

　　如果网友看过我以前写过的文章，就能理解我如是如何理解定义测试的。

　　谁是测试团队中的核心技术人员

　　我个人认为对于公司测试团队中最重要的人是设计优秀测试策略和设计优秀ROI（ROI：投入产出比）测试方案的测试工程师，当然自动化测试脚本开发工程师和测试工具开发者对于测试部也是非常重要和不可或缺的。

　　为什么我认为测试部最重要的人是测试策略和测试用例的设计者？

　　首先从相关人才的来源来分析：

　　自动化测试开发工程师：可以由只毕业3－4个月或才进入项目1－2个月的工程师就能从事。测试工具开发：甚至不需要对测试了解多少也能从事。而设计测试策略和好的测试方案设计者则需要至少2－3年的相关业务黑盒测试经验的工程师，才有可能做好。

　　其次从相关人才发挥的作用分析：

　　测试策略的制定就好似公司的市场部要制定大的市场战略。例如：这个测试方案的定位是什么？这轮测试的目的是什么？有多少资源可以进行测试？应集中资源先对哪些重要又紧急的功能进行测试？如何区分重要或紧急的功能？如何安排紧急而不重要的功能与重要而不紧急功能的测试顺序？等等......

　　测试方案的设计：就好似公司的销售部针对每个具体的客户制定具体的销售计划和销售方案。例如：对于这个case我们的目标期望是什么？如何达到这个目标？是否还有更好的方法来达到这个目标？如何利用现有的有限资源取得最大化的结果？这个case的ROI是否高效？而测试工具的开发和自动化测试脚本的开发则类似于公司中的研发部，提供必须的高效武器与公司市场部，销售部一起攻城拔寨。

　　如何成为一个合格优秀的测试策略的设计者呢。我的观点是：

　　1：一切测试策略的目的是什么？是为了满足公司市场销售策略。因此我们应该设法保证测试策略既能按期完成研发计划，又能不影响销售的产品质量。

　　2：将有限的资源先用到紧急又重要的测试任务中，再评估其他任务的优先级。但一定要以市场销售计划为依据。一个脱离市场销售的测试策略是一个误国误民的策略。

　　3：测试策略不是测试计划。我的看法是：以市场销售计划为依据，先制定测试策略，再按任务的优先级和资源情况来制定测试计划。现在常有不少朋友误认为测试计划就是测试策略，测试策略就是schedule

，这种观点我个人并不认同。

　
　4：测试策略不是一个人设计出来的。它一定是先听取了市场人员的意见和要求，再结合研发的要求得出的一个平衡取舍的产物。

　　5：好的测试策略设计者是一个以公司利益为第一位，而不只局限在测试部门利益的员工。办公事政治玩多了，设计的测试策略有可能就是一个对公司利益有害的策略。

　　6：一定要最大化的接近客户的真实应用来定义重要的模块功能，而不简单依据模块的复杂度来定义。

　　7：能知己知彼。对自己的测试资源有多少，要有准确清晰的认识才能知道量体裁衣。而不要打肿脸撑胖子，最后实施时，却完成不了测试策略。

　　接下来，如何成为一个合格优秀的测试用例设计者。我的观点是：

　　好的测试用例至少要满足如下要求：（这里只讨论功能测试用例的要求）

　　1：粒度一定要细，对功能需求中的每个小点，每个数据都要覆盖到。并尽量多的想到更多的测试方法来对被测试项进行拷打。

　　2：测试方法不能过度测试。大家容易想到测试不充分对公司有害，但往往会忘记过度测试对公司也是有害的，这点在我的测试经历中感受非常深刻。例如：因为你的过度测试，浪费了你的有效测试时间，这个时间原本是可以拿来发现更多真正有意义对销售有影响的bug。因为你的过度测试发现的bug，开发人员有时必须为这些意义不大的bug花时间来修改，浪费了修改其他更有意义bug的时间，影响了项目的进度，影响了产品的销售计划。说不定公司甚至因为你的几个过度测试，延迟了1个月推出产品，导致公司在这1个月中损失1亿的订单。而这些都是真正有可能发生的。所以，要避免在不漏测的前提，走向另一个极端－过度测试。

　　3：你的测试用例是否容易转化为自动化测试。如果你在进行测试用例设计时，根本没有把将来进行自动化测试的开发做为一个考虑因素。那么，你的测试用例永远只能用手工进行回归测试，将大大浪费公司的资源并影响产品发布时间。如果回归测试的手工执行是你自己来做的话，那么以后你的苦日子可就长了。

　　4：测试用例应该考虑执行时资源和时间的安排。例如：千万不要出现有的test case执行完一遍只需要1小时，有的test case执行完一遍却需要20个小时。为了便于测试管理和计划安排，应设法让测试用例未来执行的时间保持在一个参考值左右。假设一个标准test case的执行时间为4小时，那么设计的test case应尽量保持在3－5小时内。这样非常容易量化并管理测试用例执行者的工作，更有利于测试计划的安排，测试策略的制定，研发计划的按时执行。

　　5：理想状态下，最好你的测试用例也要有好的易读性。例如：test case的执行者拿到你的case后能在半小时或1个小时左右就能读懂并执行。否则，如果执行者还需要4－5个小时才能读懂或不能完全读懂你的测试方法和测试步骤。那公司将会为这样的测试用例付出非常大的成本代价，甚至会影响测试计划的执行和产品的研发计划。

　　总结：对于部分迷茫的测试工程师，如果你希望在测试领域发展而不是在代码开发领域发展，就不要误认为只有代码才是高手，只有代码才是好的测试工程师。要做一个对公司有最大价值的测试工程师，就应该尽量往成为一个好的测试策略设计者和测试用例设计者成长和发展，但这一切工作又很依赖一个很基础的因素——工作的责任心，只有把公司的大局发展放入自己的心中，才能真正做好工作的取舍，设计出有价值的测试策略和测试用例。

Win7下配置Tomcat

Tomcat=C:\tomcat

配置好之后，进入Tomcat文件夹，双击C:\tomcat\bin\startup.bat，运行Tomcat，然后，打开IE，键入：http://127.0.0.1:8080/

如果出现：

则此时，Win7下配置Tomcat配置成功。