如何测试一款软件
-
你自己要想清楚你的测试团队组成、使用的技术方法、功能覆盖程度、
b
ug
管理流程、不同
种类的
bug
对核算承包人业绩的影响（例如口多少分）等等，并且告知给承包人。关键的一
点是，不论你怎样严格地测试，你都要保证你有技术可以尽快验收承包人提交的产品，而不
是只知向承包人提出空洞的需求而不会验收。
软件测
试在很多人看来就是在一间黑屋子里抓黑猫，而且不知道是否真的有猫。而在微软看
来，
猫一定是有的，但测试不只是为了抓猫，而是要不断改进软件工程，使将来的猫越来越
少
，也就是今天解决明天的问题。
《微软如何测试软件
》向我们展示了微软软件测试的方
***
、工具和实践。
事实上，在微软软件测试早已成为软件工程的一部分。
然而当年的微软就像我们今天的
一些小型软件公司一样，
没有测
试工程师，
没有本地化工程师，
没有程序
（
Program
Manager
）
，
也没有可用性工程师。
好的设计与好的执行是软件开发项目成功的关键。
测试
设计与好的软件设计有很多相似之处。测试设计要求规划和解决问题以确定运行哪类测
试
以及那些类型测试最有效。如同设计模式，测试模式解决共性问题并且为测试人员设计测
试提供指导和策略。微软内部测试人员一般采用简化的
Robert Binder
测试设计模式模板作
为通用格式进行沟通。
确定
测试模式后，需要估计测试时间。估计测试所需时间是非常困难的，一个粗略的规则是
测
试时间与开发的时间相同。另外一个问题是何时开始测试。一般我们会认为编码完成后开
始测试。实际上，理想状况是在开发的起始阶段就介入。开始测试设计的一个时间点是软件
需求或功能规范审查。当然开始测试之前，我们还需要一个测试策略为测试团队提供愿景，
帮助每个人确定哪个测试活动最重要并帮助他们确定何时、何地应用不同测试类型。
在微
软，测试工作包括功能性测试、结构化测试、利用代码复杂性分析风险和模型化测试。
测
试人员采用等价类分区、边界值分析和组合分析技术进行软件功能测试。结构化测试则采
用组块测试
（
block
testi
ng
）
、
决定测试
（
decision
testing
）
、
条件测试
（
< br>condition
testing
）
和基础路径测试
（
basis
path
testing
）
的方法。
代码复杂性对于识别哪里可能存在缺陷
（
bug
）
是必不可少的度量，对于识
别可能导致维护问题的代码同样有价值。利用代码复杂性分析风
险有助于我们把有限的测
试资源集中在最恰当的区域。模型能帮助我们理解复杂事物如何工
作。将从模型中产生的
测试与测试模型配合是最有威力的。基于模型的测试比随机游走更加
有效。微软测试团队
已经采用模型化测试连同传统的测试自动化有效地测试了很多功能和应
用。
在方法论外，
测试还需要工具和系统。
微软当然拥有自
己的缺陷和测试用例管理系统。
《微软
如何测试软件》不仅向我
们介绍了微软缺陷和测试用例管理系统，还向我们介绍了基于多年
的使用而产生的经验教
训和实用的建议。
在软件测试中似乎总有另一个障碍需要克服。微软的测试工作
也是如此。微软正尝试采取一
些措施解决明天的问题。具体方法包括自动失败分析、机器
虚拟化、代码审查等。
当然，相对于软件开发，软件测试还是一个新的专业。软件测
试的大部分工作还是验证软件
功能和发现关键错误。
因此我们必
须考虑软件测试将何去何从。
这也是
《微软如何测试软件》
与我们讨论的问题。
< br>市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作，
例如用于
Java
代码
单元测试的
Junit
工具，又如用于
GUI
< br>测试的
Rational Visual
Test
工具等。
一般而言，软件测试从项目确立时就开始了，前后要经过以下
一些主要环节：
需求分析→测试计
划→测试设计→测试环境搭建→测试执行→测试记录→缺陷管理→软件评
估→
RTM.
在进行有关问题阐述前，我们先明确
下分工，一般而言，需求分析、测试用例编写、测试环
境搭建、测试执行等属于测试开发
人员工作范畴，而测试执行以及缺陷提交等属于普通测试
人员的工作范畴，测试负责人负
责整个测试各个环节的跟踪、实施、管理等。
1
、需求分析