如何测试一款软件

你自己要想清楚你的测试团队组成、使用的技术方法、功能覆盖程度、bug管理流程、不同种类的bug对核算承包人业绩的影响（例如口多少分）等等，并且告知给承包人。

关键的一点是，不论你怎样严格地测试，你都要保证你有技术可以尽快验收承包人提交的产品，而不是只知向承包人提出空洞的需求而不会验收。

软件测试在很多人看来就是在一间黑屋子里抓黑猫，而且不知道是否真的有猫。

而在微软看来，猫一定是有的，但测试不只是为了抓猫，而是要不断改进软件工程，使将来的猫越来越少，也就是今天解决明天的问题。

《微软如何测试软件》向我们展示了微软软件测试的方***、工具和实践。

事实上，在微软软件测试早已成为软件工程的一部分。

然而当年的微软就像我们今天的一些小型软件公司一样，没有测试工程师，没有本地化工程师，没有程序（Program Manager），也没有可用性工程师。

好的设计与好的执行是软件开发项目成功的关键。

测试设计与好的软件设计有很多相似之处。

测试设计要求规划和解决问题以确定运行哪类测试以及那些类型测试最有效。

如同设计模式，测试模式解决共性问题并且为测试人员设计测试提供指导和策略。

微软内部测试人员一般采用简化的Robert Binder测试设计模式模板作为通用格式进行沟通。

确定测试模式后，需要估计测试时间。

估计测试所需时间是非常困难的，一个粗略的规则是测试时间与开发的时间相同。

另外一个问题是何时开始测试。

一般我们会认为编码完成后开始测试。

实际上，理想状况是在开发的起始阶段就介入。

开始测试设计的一个时间点是软件需求或功能规范审查。

当然开始测试之前，我们还需要一个测试策略为测试团队提供愿景，帮助每个人确定哪个测试活动最重要并帮助他们确定何时、何地应用不同测试类型。

在微软，测试工作包括功能性测试、结构化测试、利用代码复杂性分析风险和模型化测试。

测试人员采用等价类分区、边界值分析和组合分析技术进行软件功能测试。

结构化测试则采用组块测试（block testing）、决定测试（decision testing）、条件测试（condition testing）和基础路径测试（basis path testing）的方法。

代码复杂性对于识别哪里可能存在缺陷（bug）是必不可少的度量，对于识别可能导致维护问题的代码同样有价值。

利用代码复杂性分析风险有助于我们把有限的测试资源集中在最恰当的区域。

模型能帮助我们理解复杂事物如何工作。

将从模型中产生的测试与测试模型配合是最有威力的。

基于模型的测试比随机游走更加有效。

微软测试团队已经采用模型化测试连同传统的测试自动化有效地测试了很多功能和应用。

在方法论外，测试还需要工具和系统。

微软当然拥有自己的缺陷和测试用例管理系统。

《微软如何测试软件》不仅向我们介绍了微软缺陷和测试用例管理系统，还向我们介绍了基于多年的使用而产生的经验教训和实用的建议。

在软件测试中似乎总有另一个障碍需要克服。

微软的测试工作也是如此。

微软正尝试采取一些措施解决明天的问题。

具体方法包括自动失败分析、机器虚拟化、代码审查等。

当然，相对于软件开发，软件测试还是一个新的专业。

软件测试的大部分工作还是验证软件功能和发现关键错误。

因此我们必须考虑软件测试将何去何从。

这也是《微软如何测试软件》与我们讨论的问题。

市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作，例如用于Java代码单元测试的Junit工具，又如用于GUI测试的Rational Visual Test工具等。

一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：
需求分析→测试计划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评估→RTM.
在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。

1、需求分析
需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直接影响到接下来有关测试工作的开展。

可能有些人认为测试需求分析无关紧要，这种想法是很不对的。

需求分析不但重要，而且至关重要！
一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。

其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。

比如一款Smartphone包括VoIP、Wi-Fi以及Bluetooth等功能。

那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！
既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。

总得说来，做测试需求分析的依据有软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。

2、测试计划
测试计划（Test Plan）一般由测试负责人来编写。

测试计划的依据主要是项目开发计划和测试需求分析结果而制定。

测试计划一般包括以下一些方面：
1．测试背景
a. 软件项目介绍；
b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。

2．测试依据
a. 软件需求文档；
b. 软件规格书；
c. 软件设计文档；
d. 其他，如参考产品等。

3．测试资源
a. 测试设备需求；
b. 测试人员需求；
c. 测试环境需求；
d. 其他。

4．测试策略
a. 采取测试方法；
b. 搭建哪些测试环境；
c. 采取哪些测试工具以测试管理工具；
d. 对测试人员进行培训等。

5．测试日程
a. 测试需求分析；
b. 测试用例编写；
c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，α、β测试阶段等），每个阶段的工作重点以及投入资源等。

6．其他。

测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。

计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。

如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。

所以，这些就要求测试负责人能够从宏观上来调控了。

在变化面前能够做到应对自如、处乱不惊那是最好不过了。

3、测试设计
测试设计主要包括测试用例编写和测试场景设计两方面。

一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。

关于测试用例编写，请参见前面写的《也谈测试用例》一文，里面有详细阐述。

测试场景设计主要也就是测试环境问题了。

4、测试环境搭建
不同软件产品对测试环境有着不同的要求。

如C/S及B/S架构相关的软件产品，那么对不同操作系统，如Windows系列、unix、linux甚至苹果OS等，这些测试环境都是必须的。

而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。

当然测试中对于如手机网络等环境都有所要求。

测试环境很重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。

为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。

有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。

不管如何，我们的目标是测试软件问题，保证软件质量。

测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。

5、测试执行
测试执行过程又可以分为以下阶段：
单元测试→集成测试→系统测试→出厂测试，其中每个阶段还有回归测试等。

从测试的角度而言，测试执行包括一个量和度的问题。

也就是测试范围和测试程度的问题。

比如一个版本需要测试哪些方面？每个方面要测试到什么程度？
从管理的角度而言，在有限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。

当然还要考虑以下问题：
1．当测试人员测试的执行不到位、敷衍了事时该如何解决？
2．测试效率问题，怎样提高测试效率？
3．根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？
4．当测试过程中遇到一些偶然性随机问题该怎样处理？
5．当版本中出现很多新问题时该怎样对待？测试停止标准？
6．……
总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。

6、测试记录
缺陷记录总的说来包括两方面：由谁提交和缺陷描述。