自动化和手工测试有效的结合
这个文档描写了关于怎样将自动化和手工测试有效的合并从而推进软件新版本的发行的实践。
软件开发团队一直在寻找一个口子，既可以快速的实现产品的功能，又可以让软件维持在一个较高的水平，多数软件质量团队也意识到有效的把自动化和手工测试合并可以缩短软件的发行的周期，但是他们不知道怎样充分利用他们的测试成果
这份文档讨论怎样平衡自动化和手工测试及所需要的东西和论述优化你的成果来实现在短时间内实现高质量的发行。这份文档主要集中在一下几个要点：
一、优化你的自动化测试的计划
二、 优化你的手工测试计划
三、有效的合并自动化和手工测试
四、在测试周期里大程度优化你的测试成果
五、利用回归测试来改进你以后的测试
一、优化你的自动化测试的计划
很多公司都是手工执行他们的回归测试用例。那么什么时候开始自动你的回归测试用例？很多用例，当你不能够在每个版本都运行回归测试用例的时候，那么自动化运行测试用例是一个再好不过的想法了。比如，如果你每天或者每个星期都要为质量管理团队生成一个新的版本的时候，你不能够迅速的为每一次版本执行全部测试用例，这时候要想到自动执行了，当开始投资自动化时，要用优的时间方法来精明的分配你的时间。
实践一：雇一个有贡献的自动化测试工程师
很多团队试验自动化的时候，是通过用一位手工的测试工程师或者是一位开发人员，所以当她们自动化试验失败后，他们去问他们的上司为什么会失败。其实很简单，一个有多年经验的自动化测试工程师可以减少重复的功能和有所贡献以致不会干扰到其他的手工测试或者开发的工作。如果花费是一个问题的话，可以这样想：行业标准结果显示在用户使用过程中找到一个缺陷比测试中找到一个缺陷所需的花费多30-100倍！很多公司发现他们关注的花费相当于他们在改进软件质量时开始日常的测试系统和减少测试时间
实践二：从冒烟测试小部分做起
不要试图自动化所有的事，相反，从小做起，一个很好的开始是从冒烟测试开始，冒烟测试是基本的测试，目的是运行一个新版本来确定它没有严重的缺陷。这样一组也许只是包括20到25个测试用例，但是是从这里做起，你会很快的发现你的努力带来的影响。
实践三：自动化你的回归测试
当你已经完成了你的自动化冒烟测试，到了回归测试这一阶段，回归测试是确保新版本没有坏的功能存在，所以要用有条理的方法和主要以下红色的地方：
1、频繁执行的测试?从频繁的执行的功能开始自动化的回归测试，自动化执行一次周期和在同一个系统执行一个测试用例上百次不一样的
2、费事的测试----有些测试需要几个小时来执行。它们设计到设置数据库表的输入，接口测试，然后查询数据库来确认数据是不是被正确处理了，如果用手工测试，要花几个小时，所以自动化测试可以让你的日常测试变得轻松
3、高精确的的测试?比如有些测试需要涉及到很复杂的材料确认或者是要经过一系列复杂的步骤，当被打断时候，不得不从头开始，但是自动化测试不一样了，可以得到更多连贯的结果减少手工测试的压力
实践四：基于项目和团队的大小来聪明的组织你的自动化测试
如果你有有一个小团队和一个自动化测试工程师，几个手工测试者和一些开发人员，你需要尽可能的在小组员中分出自动化测试。在一个项目中通过用文件来管理你的自动化测试来保证结构的简单，每个文件夹保存了软件的一个功能。当然用一个通用的文件夹来保存那些会重复调用的测试用例的通用的功能也是不错的尝试。
如果你有很多产品线很很多自动化测试工程师，你将会遇到这样的问题：他们在同一个项目中既要查看测试用例又要检查源代码。为了预防这种问题，创建一个项目管理，它既包括很多个项目（一个用来保存每个产品线，一个用来保存常用的测试用例等）然后每个项目又包含很多个文件，用不同功能和常用功能来区分
实践五：用资源控制管理系统来保护你的测试
如果丢失了硬盘或者错误的覆盖了，通过资源控制管理系统你可以预防丢失数据或者把更爱的测试用例记录在系统里
规划你的手工测试的优实践
三、你需要通过手工测试来测试新的功能或者改进的功能
实践一：好的测试源于好的需求
很多重复的工作都可以被避免通过对需求的充分理解，好的需求有以下三个要点：
● 简明但要描写充分
● 明确的事物规则
● 一个具备了简要功能的模型
实践二：创建有正确输出和无预期输出结果的测试用例
在写测试计划的时候，确保有写有正确输出的测试用例（是那些确保这个功能是按要求实现）和无预期输出的测试用例（是那些确保输入任何数据或者非法操作都能够很好的处理），性能测试用例（确保这个新的版本比上一个版本执行的好）和相关的测试。
实践三：确保每个测试用例都有相关的需求描写
在写测试计划，确保每个需求都能被覆盖的好的方法是创建一个可跟踪的矩阵，这个矩阵显示了每个需求的各种测试用例的号码。通过这样，你可以很快的找出那个需求没有被覆盖到
实践四：早点把你的测试用例给开发看
一旦你的测试用例完成了，可以公布给开发看，他们可以看这些测试用例将会被怎样执行，他们要看他们的代码能否符合每个测试用例的逻辑。这一部可以减少重复性工作
四、有效的合并自动化和手工测试
实践一：在测试阶段计划好你每天的自动执行
现在你已经建立好了自动化测试用例，那么每天运行他们这样你可以快速的发现这个新的版本任何功能的缺陷了，这很重要，可以通过一些管理工具来实现控制什么时候运行测试用例
实践二：创建可重现的缺陷
不可重复的缺陷消耗着测试人员的时间，测试人员提了一个不可重现的缺陷，那么开发人员需要跟多的时间来证明它不可重现。
怎样解决这个问题？好的方法是详细描写你是怎么发现它的。
在测试周期里大程度优化你的测试成果
在测试阶段，和组员每天开15分钟的会议，评估测试进度和缺陷优先级
实践一：回顾测试用例进度
检查有多少测试用例已经被执行了，有多少通过了，有多少失败，有多少在等待执行。
实践二：每天对缺陷进行优先级划分
五、利用回归测试来改进你以后的测试成果
当系统提交后，你要通过回顾来学习
实践一：分析项目不一致的地方
比如时间的开销
实践二：分析质量保证的规律
有多少个测试用例被执行，一个版本中发现了多少个缺陷。
实践三：记录你回顾的结果
附加：
编写测试用例：
当需求已经被确认，编码工作也已经开始了，那么要着手进行测试用例的编写了，建议是在编码结束之前要写一个测试用例设计出来，这样在测试过程中不会浪费太多的时间。
为了保证测试用例的精确性，为测试用例创建以下的文件：
● 冒烟测试用例：（smoke test）（对主要功能进行测试，大概30个测试用例）
● 回归测试用例：（regression test）
● 标准的测试用例：（standard test case）
● Positive的测试用例
● Negative的测试用例
相关测试（relational testing）包括以下：
● 重复的记录：创建一个一模一样的记录
● 通过改变名字来生成一个一模一样的记录
● 删除一个记录也许会删除相关联的记录
● 删除一个记录和它的附属信息：比如有个case，它有个信息，如果你想删除这个信息，他会失去和这个信息的联系，所以如果这个case没被删除，你不允许删除这个信息。
