测试用例的准备，都是为了执行测试准备的。

测试环境的搭建

　　（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，心情好修改当然质量高了。