测试用例的准备，都是为了执行测试准备的。
测试环境的搭建
（1）测试数据：有些测试需要使用大批量的数据，例如容量测试、压力测试等。根据产品的具体测试要求，可能需要在数据库表插入大量的数据，准备大量的文件，生成大量的Socket包等。
（2）有些测试需要专门的外部硬件设备，比如打印机，条码识别器，读卡机，指纹仪等。
如果是手机应用测试，可能要把所有支持的型号的手机都准备好。这些设备有些可以使用模拟器来模拟，有些则不能。模拟器比如夜神安卓模拟器。经常遇到在手机模拟器上可以执行的程序，在真正的手机上运行则会出现问题，或者在pc上报表格式正确，但是真正打印出来则会移位，走样。
（3）有些产品需要支持多种操作系统，那么在做兼容性测试之前就需要准备好各种操作系统的计算机，或者可以考虑虚拟机来安装，如vm ware,virtual PC等。
（4）有些测试需要部署到多台机器，并且需要设置各种参数，那么就需要在测试之前准备好各种安装包。
（5）有些测试需要用到网络，设置需要考虑网络的路由设置、拓扑结构等，那么在测试之前就需要准备好这样的网络设备和网络环境配置。
BVT测试与冒烟测试
BVT测试（Build Verification Test)），编译检查测试，主要检查源代码是否能正确编译成一个新的，完整可用的版本。如果BVT不通过，测试人员不能拿到新的版本进行测试。
冒烟测试，该概念来源于硬件生产领域，一般通过给制造出来的电路板加电，看电板是否通电，如果设计不合理，则可能在通电的同时马上冒出烟，电路板不可用，因此没有必要进行下一步的检测。
那么该概念应用于软件测试，其实意义也一致。就是主要验证主功能，如果主功能都行不通，那就没有验证下去的必要，直接把编译版本退回给开发人员修改。
需要注意的是，冒烟测试的测试用例应该是随着开发的深入而不断演进的。
每日构建的基本流程
程序模块的集成问题是一个导致开发进度受阻的常见原因。缺陷也往往在集成阶段才集中出现的，尤其是那些接口设计不够好的软件。
那么解决集成问题的最后办法就是尽早集成，持续地集成，小版本集成。通过每日构建可以达到持续集成，小版本集成以及版本集成验证的目的。
每日构建就是每天定时把所有的文件编译，连接，组成一个可执行的程序的过程。
通常把每日构建放在晚上，利用空余时间自动进行，因此也叫每晚自动构建。简单的流程如下图
通过每日构建来规范代码管理
每日构建除了可以解决部分版本集成的问题外，还可以对程序员的源代码签入签出行为做出规范性约束。
大家都知道，如果程序员没有遵循一定的规范签入，签出源代码，就很可能导致其他程序员的代码模块失效或者混乱。一个正确而谨慎的做法应该是每次签入自己修改的代码之前，先获取所有新版本并把所有代码编译通过，确保不会影响别人的代码时才签入，否则必须先把问题解决掉。
每日构建是一个提高士气的机制，每天项目组的所有人都能看到构建出来的新版本增加了哪些新特性，看到能工作的产品，并且每天都比前一天多一些，增强一些，就像看到自己的孩子在茁壮地成长着，给所有人一种信心和鼓舞。
测试的记录和跟踪
bug的质量：所谓质量，是指测试人员录入bug描述的清晰度，越容易理解的bug，质量越高。开发跟测试之间也不用花费大量时间去理解该bug如何修改合适。
如何录入一个合格的bug
发现问题的版本
一般来说，在不同版本发现同一个Bug,有可能是由于不同原因产生的。所以如果在版本1.1修改完该Bug后，在版本1.2又发现了该bug，不应该把版本1.1的bug激活，而应该重新录入一个bug，版本改为1.2。因为这是一个新增的Bug,测试人员需要重新验证，统计。如果激活上一个bug也可能造成质量统计时的漏算。
问题出现的环境
问题出现的环境包括操作系统环境、软件配置环境，有时候还需要包括系统资源的情况，因为有些错误只有在资源不足时才出现。
由于开发环境与测试环境存在差异，往往导致有些问题只有在测试环境下才能出现。例如开发环境中使用的某些第三方组件在测试环境没有注册。这时测试人员应该把这些差异写清楚，以便开发人员在重新问题和进入调试之前把环境设置好。
问题重现步骤
描述问题出现的操作步骤。要尽量把操作步骤缩减到必须执行才能重新错误的几个步骤。别浪费步骤在无关问题上面，影响重现进度。
预期行为的描述
需要让开发人员知道什么才是正确的。有些描述不清的，如“编辑单据时，列表中不出现日期信息”，那么你是希望他出现日期呢，还是不出现日期呢？一般描述就加上XX应该XX或者SS不应该SS。
错误行为的描述
描述问题的现象。例如“程序抛出异常信息如下。。。”，如实反映，不要夸大。
除了以上，还有严重程度，优先级别，出现模块，缺陷类型，发现日期等等，一般在缺陷管理系统中都会提示填写。
BUG描述中应该注意的几个问题
1、不要出现错别字
我们是做测试的，就是要把错误找出来，我们是找BUG而不是创建BUG。
2、不要把几个BUG录入到同一个ID
最好一个问题一个ID，比如创建一个客户，没有做非空校验，保存也出现异常。这时候需要分为2个ID录，虽然在同个模块同个界面，但是分开录有利于后面可以清晰地跟踪所有BUG的状态，并且有利于缺陷的统计和质量的衡量。
3、附加必要的截图和文件
有截图或者文件，并且在截图上框出出错的位置，标记上问题，能让开发更快速地定位到错误，高效率地修改。
4、录入完一个BUG后自己读一遍
如果一个BUG录完之后连自己都读不通，那么别想开发人员能修改高质量的产品，所以录完之后自己读一遍，读通了之后再进行其他的测试。
如何跟踪一个BUG的生命周期
创建-打开-修复（拒绝/延期）-关闭-激活
如何与开发人员沟通一个BUG
能让开发人员解决最多的BUG的测试人员是最优秀的测试人员，如果能正确地，高质量地录入一个BUG，那已经跟开发人员沟通了一大半关于BUG的信息，但是有些BUG字面会说不清楚，所以我们就得自己找开发谈，最好演示一遍给开发看。注意的是，跟开发讲BUG的时候一定要语气平和，千万不要趾高气扬，指责开发等语气，因为每个人都是不喜欢收拾烂摊子的，所以我们需要用技巧地跟开发沟通，比如说麻烦了，辛苦了之类的，这样的话，开发会更乐意修改这个BUG，心情好修改当然质量高了。
回归测试
一般如果系统有做其他的改动时，可能会影响到其他功能的使用。
比如我创建一个客户,发现了保存功能有异常，于是提了个BUG。开发修改完成，我们验证的时候，保存功能可能正常了，但是输入功能可能因为此次的修改而影响了。
但是一般回归测试不可能整个系统的功能都全部回归，所以一般采用风险性的测试策略进行。
测试总结和报告
如果说测试用例是测试人员的工作直接反应方式，那么测试报告就是该项任务所有测试组的一个工作直接反应。
阅读测试报告的人包括产品部，开发部，测试部，以及各个部门的老大。
测试报告是可以直接提现测试工作的一种表现形式，而且简单易懂，不像缺陷列表又多又细又专业。通过测试报告，不仅可以反应近期软件的状态，还有利于分析系统的开发趋势。
缺陷分类报告
缺陷分类报告是测试报告的重要组成部分，主要分为以下几类。
缺陷类型分类报告
主要描述缺陷的类型分布情况，比如界面规范性，功能缺陷，数据显示等等。一般使用饼图或者柱状图画出。
缺陷区域分布报告
主要描述缺陷在不同功能模块出现的情况。有助于开发分析为什么缺陷集中在某个功能模块，如果某个功能模块存在大量的BUG，就得分析是否这个功能的某个工作流接口设计不合理。也可用柱状图或者饼图表示。
缺陷状态分布报告
主要描述缺陷中各种状态的比例情况，例如open,fixed,closed,reopen,rejected,delay的BUG分别占了百分之几。这些信息有助于评估测试和产品的现状。
- 如果open的BUG比例太高，则可能要考虑让开发人员停止开发新功能，先集中精力修改BUG。
- 如果fixed状态的BUG很多，则考虑让测试人员停止测试新功能，先集中精力做一次回归测试把修改的BUG验证完。
- 如果closed的BUG比较多，则意味着功能模块趋于稳定。
- 如果reopen的BUG比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不彻底。
- 如果rejected的bug比例高，则要看开发人员与测试人员是否对需求存在理解上的分歧。
- 如果Delay的BUG比例过高，则要考虑这个版本是否满足客户的要求，是否缺少了太多应该这个版本出现的功能特性。
缺陷状态分布报告一般使用饼图或柱形图表示。
还有其他的缺陷分类报告可以写在测试报告中，例如，严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但是要注意这些分类报告是用来说明问题的，而不是用来指责别人。
缺陷趋势报告
缺陷趋势报告主要描述一段时间内的缺陷情况，如果项目管理比较规范，缺陷管理和测试流程比较正常，从缺陷趋势报告还可以估算出软件可发布的日期。
典型缺陷和BUG模式
软件开发有设计模式，测试其实也有模式存在，需要测试人员进行总结和归纳。从经常重复出现的BUG中学习，总结出BUG模式。
要成为经典缺陷，必须满足以下条件：
- 重复出现、经常出现
- 能代表某种类型的错误
- 能通过相对固定的测试方法或手段来发现这些错误
总结这些典型缺陷出现的现象、出现的原因以及测试的方法，就成为一种BUG模式。
提炼BUG模式的一般步骤：
1、分析缺陷报告，找出经常出现的BUG类型。
2、分析BUG的根源，找出BUG产生的深层次原因。
3、分析找到BUG的方法，总结如何才能每次都发现这种类型的BUG。
客观全面的测试报告
测试需要以一个完美的方式结束，编写一份出色的测试总结报告可为一个完美的测试过程划上一个完美的句号。
一份测试报告应该包括测试的资源使用情况：投入了多少测试人员，多长时间，执行了多少测试用例，覆盖了多少功能模块等等。