1、如何测试一款软件.txt27 信念的力量在于即使身处逆境，亦能帮助你鼓起前进的船帆；信念的魅力在于即使遇到险运，亦能召唤你鼓起生活的勇气；信念的伟大在于即使遭遇不幸，亦能促使你保持崇高的心灵。你自己要想清楚你的测试团队组成、使用的技术方法、功能覆盖程度、bug 管理流程、不同种类的 bug 对核算承包人业绩的影响（例如口多少分）等等，并且告知给承包人。关键的一点是，不论你怎样严格地测试，你都要保证你有技术可以尽快验收承包人提交的产品，而不是只知向承包人提出空洞的需求而不会验收。软件测试在很多人看来就是在一间黑屋子里抓黑猫，而且不知道是否真的有猫。而在微软看来，猫一定是有的，但测试不只是为了抓猫
2、，而是要不断改进软件工程，使将来的猫越来越少，也就是今天解决明天的问题。微软如何测试软件向我们展示了微软软件测试的方*、工具和实践。事实上，在微软软件测试早已成为软件工程的一部分。然而当年的微软就像我们今天的一些小型软件公司一样，没有测试工程师，没有本地化工程师，没有程序（Program Manager） ，也没有可用性工程师。好的设计与好的执行是软件开发项目成功的关键。测试设计与好的软件设计有很多相似之处。测试设计要求规划和解决问题以确定运行哪类测试以及那些类型测试最有效。如同设计模式，测试模式解决共性问题并且为测试人员设计测试提供指导和策略。微软内部测试人员一般采用简化的 Robert B
3、inder 测试设计模式模板作为通用格式进行沟通。确定测试模式后，需要估计测试时间。估计测试所需时间是非常困难的，一个粗略的规则是测试时间与开发的时间相同。另外一个问题是何时开始测试。一般我们会认为编码完成后开始测试。实际上，理想状况是在开发的起始阶段就介入。开始测试设计的一个时间点是软件需求或功能规范审查。当然开始测试之前，我们还需要一个测试策略为测试团队提供愿景，帮助每个人确定哪个测试活动最重要并帮助他们确定何时、何地应用不同测试类型。在微软，测试工作包括功能性测试、结构化测试、利用代码复杂性分析风险和模型化测试。测试人员采用等价类分区、边界值分析和组合分析技术进行软件功能测试。结构化测试
4、则采用组块测试（block testing） 、决定测试（decision testing） 、条件测试（condition testing）和基础路径测试（basis path testing）的方法。代码复杂性对于识别哪里可能存在缺陷（bug）是必不可少的度量，对于识别可能导致维护问题的代码同样有价值。利用代码复杂性分析风险有助于我们把有限的测试资源集中在最恰当的区域。模型能帮助我们理解复杂事物如何工作。将从模型中产生的测试与测试模型配合是最有威力的。基于模型的测试比随机游走更加有效。微软测试团队已经采用模型化测试连同传统的测试自动化有效地测试了很多功能和应用。在方法论外，测试还需要工具和
5、系统。微软当然拥有自己的缺陷和测试用例管理系统。 微软如何测试软件不仅向我们介绍了微软缺陷和测试用例管理系统，还向我们介绍了基于多年的使用而产生的经验教训和实用的建议。在软件测试中似乎总有另一个障碍需要克服。微软的测试工作也是如此。微软正尝试采取一些措施解决明天的问题。具体方法包括自动失败分析、机器虚拟化、代码审查等。当然，相对于软件开发，软件测试还是一个新的专业。软件测试的大部分工作还是验证软件功能和发现关键错误。因此我们必须考虑软件测试将何去何从。这也是微软如何测试软件与我们讨论的问题。市面上已有不少自动化工具能在测试人员的辅助下完成相应的测试工作，例如用于 Java 代码单元测试的 Ju
6、nit 工具，又如用于 GUI 测试的 Rational Visual Test 工具等。 一般而言，软件测试从项目确立时就开始了，前后要经过以下一些主要环节：需求分析测试计划测试设计测试环境搭建测试执行测试记录缺陷管理软件评估RTM.在进行有关问题阐述前，我们先明确下分工，一般而言，需求分析、测试用例编写、测试环境搭建、测试执行等属于测试开发人员工作范畴，而测试执行以及缺陷提交等属于普通测试人员的工作范畴，测试负责人负责整个测试各个环节的跟踪、实施、管理等。1、需求分析需求分析（Requirment Analyzing）应该说是软件测试的一个重要环节，测试开发人员对这一环节的理解程度如何将直
7、接影响到接下来有关测试工作的开展。可能有些人认为测试需求分析无关紧要，这种想法是很不对的。需求分析不但重要，而且至关重要！一般而言，需求分析包括软件功能需求分析、测试环境需求分析、测试资源需求分析等。其中最基本的是软件功能需求分析，测一款软件首先要知道软件能实现哪些功能以及是怎样实现的。比如一款 Smartphone 包括 VoIP、Wi-Fi 以及 Bluetooth 等功能。那我们就应该知道软件是怎样来实现这些功能的，为了实现这些功能需要哪些测试设备以及如何搭建相应测试环境等，否则测试就无从谈起！既然谈了需求分析，那么我们根据什么来分析呢？总不能凭空设想吧。总得说来，做测试需求分析的依据有
8、软件需求文档、软件规格书以及开发人员的设计文档等，相信管理一些规范的公司在软件开发过程中都有这些文档。2、测试计划测试计划（Test Plan）一般由测试负责人来编写。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括以下一些方面：1 测试背景a. 软件项目介绍；b. 项目涉及人员（如软硬件项目负责人等）介绍以及相应联系方式等。2 测试依据a. 软件需求文档；b. 软件规格书；c. 软件设计文档；d. 其他，如参考产品等。3 测试资源a. 测试设备需求；b. 测试人员需求；c. 测试环境需求；d. 其他。4 测试策略a. 采取测试方法；b. 搭建哪些测试环境；c. 采取
9、哪些测试工具以测试管理工具；d. 对测试人员进行培训等。5 测试日程a. 测试需求分析；b. 测试用例编写；c. 测试实施，根据项目计划，测试分成哪些测试阶段（如单元测试、集成测试、系统测试阶段，、 测试阶段等） ，每个阶段的工作重点以及投入资源等。6 其他。测试计划还要包括测试计划编写的日期、作者等信息，计划越详细越好了。计划赶不上变化，一份计划做的再好，当实际实施的时候就会发现往往很难按照原有计划开展。如在软件开发过程中资源匮乏、人员流动等都会对测试造成一定的影响。所以，这些就要求测试负责人能够从宏观上来调控了。在变化面前能够做到应对自如、处乱不惊那是最好不过了。3、测试设计测试设计主要包
10、括测试用例编写和测试场景设计两方面。一份好的测试用例对测试有很好的指导作用，能够发现很多软件问题。关于测试用例编写，请参见前面写的也谈测试用例一文，里面有详细阐述。测试场景设计主要也就是测试环境问题了。4、测试环境搭建不同软件产品对测试环境有着不同的要求。如 C/S 及 B/S 架构相关的软件产品，那么对不同操作系统，如 Windows 系列、unix、linux 甚至苹果 OS 等，这些测试环境都是必须的。而对于一些嵌入式软件，如手机软件，如果我们想测试一下有关功能模块的耗电情况，手机待机时间等，那么我们可能就需要搭建相应的电流测试环境了。当然测试中对于如手机网络等环境都有所要求。测试环境很
11、重要，符合要求的测试环境能够帮助我们准确的测出软件问题，并且做出正确的判断。为了测试一款软件，我们可能根据不同的需求点要使用很多不同的测试环境。有些测试环境我们是可以搭建的，有些环境我们无法搭建或者搭建成本很高。不管如何，我们的目标是测试软件问题，保证软件质量。测试环境问题，还是根据具体产品以及开发者的实际情况而采取最经济的方式吧。5、测试执行测试执行过程又可以分为以下阶段：单元测试集成测试系统测试出厂测试，其中每个阶段还有回归测试等。从测试的角度而言，测试执行包括一个量和度的问题。也就是测试范围和测试程度的问题。 比如一个版本需要测试哪些方面？每个方面要测试到什么程度？从管理的角度而言，在有
12、限的时间内，在人员有限甚至短缺的情况下，要考虑如何分工，如何合理地利用资源来开展测试。当然还要考虑以下问题：1 当测试人员测试的执行不到位、敷衍了事时该如何解决？2 测试效率问题，怎样提高测试效率？3 根据版本的不同特点是只做验证测试还是采取冒烟测试亦或是系统全面测试？4 当测试过程中遇到一些偶然性随机问题该怎样处理？5 当版本中出现很多新问题时该怎样对待？测试停止标准？6 总之，测试执行过程中会遇到很多复杂的问题，还是那句话，具体问题具体解决！本文不做过多阐述。6、测试记录缺陷记录总的说来包括两方面：由谁提交和缺陷描述。一般而言，缺陷都是谁测试谁提交，当然有些公司可能为了保证所提交缺陷的质量
13、，还会在提交前进行缺陷评估，以确保所提交的缺陷的准确性。在缺陷的描述上，至少要包括以下一些方面内容：序号标题预置条件操作步骤预期结果实际结果注释严重程度概率版本测试者测试日期以上是描述一个 bug 时通常所要描述的内容，当然在实际提交 bug 时可以根据实际情况进行补充，如附上图片、log 文件等。另外，一个版本软件测试完毕，还要根据测试情况出份测试报告，这也是所要经过的一个环节。7、缺陷管理缺陷管理方面，很多公司都采取缺陷管理工具来进行管理，常见缺陷管理工具有 Test Director、Bugfree 等。一个 bug 从提出到 close 所经过的一些流程，其他比如 keep No ac
14、tionkeep spec 等一些状态流程都未包含在内，在此仅做示范说明。8、软件评估这里评估指软件经过一轮又一轮测试后，确认软件无重大问题或者问题很少的情况下，对准备发给客户的软件进行评估，以确定是否能够发行给客户或投放市场。软件评估小组一般由项目负责人、营销人员、部门经理等组成，也可能是由客户指定的第三方人员组成。9、测试总结每个版本有每个版本的测试总结，每个阶段有每个阶段的测试总结，当项目完成 RTM 后，一般要对整个项目做个回顾总结，看有哪些做的不足的地方，有哪些经验可以对今后的测试工作做借鉴使用，等等。测试总结无严格格式、字数限制。应该说，测试总结还是很总要的。10、测试维护由于测试的不完全性，当软件正式 release 后，客户在使用过程中，难免遇到一些问题，有的甚至是严重性的问题，这就需要修改有关问题，修改后需要再次对软件进行测试、评估、发行。从事软件测试应该具备的几大思维方式1、逆向思维方式2、组合思维方式3、全局思维方式4、两极思维方式5、简单思维方式6、比较思维方式1.确定测试模型2.估计测试时间3。何时开始测试4。测试工具和系统
