理论上，在测试资源许可并且确有必要的前提下，测试的使命将是验证和确认待开发的软件及其中间产品满足需求矩阵各个需求项。(注意：为了简化讨论，这里笔者没有把需求的验证与确认纳入进来，实际上这部分工作也是软件测试工作的重要组成部分。详细论述请参阅拙文《试论软件测试学科架构建设》)然而，几乎没有几个公司或开发团队能够提供这类测试所需的诸多的资源，此时，一种可行的策略是将待测试的软件需求项按照优先关系进行排序，以帮助测试经理决策在既定资源的情况下，应该如何统筹安排测试工作。

       软件需求项是测试需求分析的起点，这一点在工程实践中并不绝对。对于不同阶段的测试(这里主要指单元测试、集成测试、系统测试和验收测试，暂不考虑验证技术和需求设计确认)，测试需求开发所涉及的工作内容和方法都会略有差异。例如，如果是一个验收测试，那么，除了个别的需求需要做进一步明确外，几乎可以将测试需求等同于用户需求和业务需求(由于该类测试是以客户为主体，因此并不需要向下追溯到软件需求);又如，如果是系统测试，除了需要对不具备可测试性的软件需求项进一步开发外，几乎可以对软件需求和测试需求不做区分。再如，如果是集成测试，测试需求应该从概要设计规格说明中导出。如果尚不存在概要设计规格说明，就需要从软件需求规格说明出发，与软件设计人员协同工作，具体定出构成系统的各个模块、子系统、分系统的功能、性能、约束性条件以及相互接口关系。根据协同工作的结果，开发出对应的测试需求。最后，如果是单元测试，测试需求应该从详细设计规格说明中导出。如果项目不存在概要设计规格说明，就需要从概要设计规格说明出发，与软件设计人员明确每个模块内部的对象属性与方法以及对象与对象间的通信关系。根据此结果，进一步开发相应的测试需求。相应地，上一节所说的对软件需求项进行优先关系排序在实践中要变通地理解为对测试需求项进行优先关系排序。

       哪些测试需求项应该先测，哪些可以延后，那些是可以并行等，都需要在测试需求开发阶段一并分析清楚。除了对软件需求项、测试需求项做优先关系排序、对不具备可测试性或不确定的需求进一步细化、明确化之外，测试需求开发阶段的工作还包括分析各测试需求项之间可能的时间关系排序。

       读者朋友可能会问，对于整周期的开发项目，以上论述是否意味着测试需求开发的依据文档是否要根据测试所处的阶段而不断调整呢?是的，笔者认为这也是完全必要的。我们不能指望软件需求项能够描述清楚集成或单元测试阶段的测试需求。

       测试需求的开发总是有赖于相应层次的软件规格说明书(只有在开发团队不能提供的情况下才确有必要循着“详细设计规格说明->概要设计规格说明->软件需求规格说明->用户需求规格说明->项目章程、合同、项目建议书、工作说明书等”的顺序往前追溯)。通常相关依据文档的可测试性越好，测试需求开发所需要的工作量越少。

       　　三、零基础如何学好软件测试，不懂测试方法怎能事半功倍?

       　　1、从测试设计方法分类

       Black box黑盒测试：把软件系统当作一个“黑箱”，无法了解或使用系统的内部结构及知识。从软件的行为，而不是内部结构出发来设计测试.

       White box白盒测试：设计者可以看到软件系统的内部结构，并且使用软件的内部知识来指导测试数据及方法的选择。

       Gray box. 灰盒测试：介于黑盒和白盒之间

       总结： 实际工作中，对系统的了解越多越好。目前大多数的测试人员都是做黑盒测试，很少有做白盒测试的。 因为白盒测试对软件测试人员的要求非常高，需要有很多编程经验。做.NET程序的白盒测试你要能看得懂.NET代码。做JAVA程序的测试，需要你能看懂JAVA的代码。 如果你都能看懂了，你还会做测试么

       　2、从测试是手动还是自动上分类

       Manual Test 手动测试：测试人员用鼠标去手动测试 (测试GUI)

       Automation 自动化测试：用程序测试程序 (测试API)

       对于项目来说， 手动测试和自动化测试同等重要，都是保障软件质量的方法。 目前大部分的项目组都是手动测试和自动化测试相结合。因为很多测试无法做成自动化，很多复杂的业务逻辑也很难自动化， 所以自动化测试无法取代手动测试。

       对于软件测试人员个人发展来说， 做自动化测试是个挑战，也是测试人员发展的一个方向， 需要测试人员学习大量的开发知识(开发的知识真是学无止境啊)。 从长远角度来看，自动化测试肯定是越来越吃香的。

       而手动测试比较适合刚工作不久的人，手动测试最大的缺点就是技术含量低，单调乏味，容易废人。

       总的来说，手工测试胜在测试业务逻辑，而自动化测试胜在测试底层架构。

       如果被测试的程序可测试性比较好， 很有必要做成自动化测试。 能做自动化的尽量做成自动化， 下面这些情形是可以做自动化的：

       1) 测试存储过程。 例如用C#去测试存储过程

       2)测试Web servies. 例如： 用SoupUI工具，或者C#,Java 去测试Web servies。

       3)界面和业务逻辑分离的系统，比如，MVC，MVP架构， 或者WPF 程序。 可以用测试脚本去测试这些程序的API。

       3、从测试的目的分类

       功能测试

       测试的范围从小到大，从内到外， 从程序开发人员(单元测试)到测试人员，到一般用户Alpha/Beta测试

       Unit Test 单元测试：在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员做的)

       Functional Test 功能测试：验证模块的功能 (测试人员做的)

       Integration Test 集成测试：验证几个互相有依赖关系的模块的功能 (测试人员做的)

       Scenario Test 场景测试：验证几个模块是否能完成一个用户场景 (测试人员做的)

       System Test 系统测试：对于整个系统功能的测试 (测试人员做的)

       Alpha 测试：软件测试人员在真实用户环境中对软件进行全面的测试 (测试人员做的)

       Beta 测试：真实的用户在真实的用户环境中进行的测试, 也叫公测 (最终用户做的)

       　非功能测试

       一个软件除了基本功能之外，还有很多功能之外的特性，这些叫“Quality of Service requirement”服务质量需求。没有软件的功能，这些特性都无从表现出来，因此，我们要在软件开发的适当阶段-基本功能完成后做这些测试。

       Stress test 压力测试：验证软件在超过负载设计的情况下仍能返回正确的结果，没有崩溃

       Load test 负载测试：测试软件在负载情况下能否正常工作

       Performance test性能测试：测试软件的效能，是否提供满意的服务质量

       Accessibility test：软件辅助功能测试-测试软件是否向残疾用户提供足够的辅助功能

       Localization/Globalization：本地化/全球化测试

       Compatibility Test：兼容性测试

       Configuration Test：配置测试-测试软件在各种配置下能否正常工作

       Usability Test：可用性测试 –测试软件是否好用

       Security Test：软件安全性测试

       　性能测试

       性能测试要求测试人员熟练性能测试工具，比如QTP, LoadRunner, Jmeter。 Visual Studio也提供了很多性能测试的工具. 要求测试人员对低层协议非常理解和编写脚本

       性能测试非常有技术含量， 很有发展前途， 是软件测试人员的一个职业发展方向4、按测试的时机和作用分类

       在开发软件的过程中，不少测试起着“烽火台”的作用，它们告诉我们软件开发的流程是否畅通。

       Smoke Test：“冒烟”–如果测试不通过，则不能进行下一步工作

       Build Verification Test(BVT)：验证构建是否通过基本测试。

       Acceptance Test：验收测试，为了全面考核某功能/特性而做的测试

       BVT测试是一种Smoke Test, 指Build生成好之后，自动运行的自动化测试脚本来检查这个Build的基本功能。 如果BVT测试失败了，需要开发人员马上修改，重新生成Buil

       　5、按测试测策略分类

       Regression Test 回归测试：对一个新的版本，重新运行以往的测试用例，看看新版本和已知的版本相比是否有退化 (regression)

       Ad hoc Test 探索性测试：随机进行的，探索性的测试。

       Santiy Test：粗略的测试， 只需要执行部分的测试用例

       Regression Test 回归测试：

       对软件测试人员来说就是重复测试，所以回归测试最好是自动化的，否则测试人员就要一遍又一遍地重复测试。

       1)开发人员做些小改动，就需要测试人员做回归测试。确保现有的功能没有被破坏;

       2)Bug Fix 也需要回归测试，确保新的代码修复了Fix, 也确保现有的功能没有被破坏;

       3) 项目后期，需要做一个完整回归测试， 确保所有的功能都是好的。

       　四、零基础如何学好软件测试?我们都知道盲区这个概念，当然它在软件测试中也是存在的，那么我们该如何避免这些测试盲区呢?

       　1、充分理解软件需求

       需求方面的如果理解有误或者分析遗漏，那么将对软件功能测试很难全面覆盖。基本功能测试有遗漏的话，那是不可饶恕的，所以在测试前以及测试过程中要多注意软件需求文档、产品规格书，尤其是没有文档化的规格更改、需求变动，这都是很容易出现误测或漏测的。这在项目进程中需要项目成员之间加强信息沟通。

       　2、制定一份完善的测试方案

       测试方案包括的内容比较多，这里我们主要指测试用例，测试前需要制定一套完善的测试用例，完善指我们的测试用例至少要覆盖所有软件需求，同时对于边界测试、中断测试、性能测试都要涵盖。测试用例编写很简单，但编写高质量的测试用例真的不容易，至少，让我称之为高质量的不多。测试方案应该要经过评审的，至少要和开发人员一起有针对性地讨论下测试内容、重点和需求。

       　3、多采取交叉测试

       也就是同一项目组的不同测试模块的测试人员互换模块，相互测试。由于每个人的测试角度、思维方式等都不太一样，所以这种互测是发现更多问题的一个有效途径。事实证明，这种效果非常棒!

       　4、多学习同类产品的bug库

       同类产品的bug库对于测试人员而言，是个非常好的资源，测试人员从那里可以了解更多产品容易出问题的地方，甚至很多问题本产品上就潜在着，还未被发现。

       　5、多沟通、交流

       每一阶段，项目测试组长都应该组织小组测试人员多多交流，分析、总结下测试中遇到的问题，由于是一些概率性以及容易被忽略的问题，单个测试人员测试时可能遇到，但并不以为意，这样，通过讨论、交流，能够加强测试人员对问题的印象，在接下来测试中加强薄弱环节的测试。

       　6、加强相关产品知识学习

       尤其是一些技术原理上的东西，只有深入了解了，测试上才能更加发现更多原来力所难及的问题，如协议层的问题。

       　7、经常测试、充分测试

       测试上有个原则：及早测试、经常测试、充分测试。要发现更多的问题、减少测试盲区，多测是少不了的。

       其实，更广义地理解，测试盲区还涉及到测试软件质量目标和针对性问题，测试还要注意把握一个度和量，我们要知道软件在生命周期内的质量目标是什么。过犹不及，将大量时间浪费在测试一些用户永远无法涉及到或者无关轻重的地方，这都是很盲目的!

       　五、零基础如何学好软件测试?我们了解了测试定义、流程、方法、盲区之后，我们还需要能写出一份完美的测试报告：

       我们要认识到软件测试报告远非一种形式，更多是一个测试活动的总结，项目是否结项的重要参考和依据。因此本文指导一些才从业不久的朋友怎么编写一份高质量的测试报告。

       　1、要有明确结论

       纵观一些软件测试报告，可能测试人员基于规避自己的责任，或者迫于软件开发经理的压力，导致在报告中尽写一些模棱两可的结论。这样的测试报告是没有任何作用的，更多体现了测试团队的懦弱和无能。一个有效的测试报告，关键是有一个建立在真实测试数据上，客观、公正的明确结论。公司领导把质量交付给你，是希望你能保证公司的软件质量，如果结论都闪烁其词，你让公司怎么相信、支持测试团队。

       　2、每一条结论都是建立在事实、数据上

       前面已经提到，测试报告中最重要的就是要有明确的结论。有可能是一组数据，也有可能是一句话。这些结论不管以何种形式展现出来，有个重要的原则：每条结论必须建立在事实、数据上。测试结论不能依照少量的不可靠的数据进行推测，更不能凭空捏造。否则，整个测试报告就真正沦为了一个形式，可能还会因此导致一些未知的负面后果。

       　3、测试报告中结果应尽可能图文结合方式展现出来

       测试报告的读者往往是项目经理，或者公司高层，更有甚者为软件买单客户。所以测试报告应尽可能以直观的形式展现出来。比如数据最好以列表的形式展现出来，测试迭代情况最好以折线图展现出来，并在图表下配以文字说明。这样的测试报告不仅仅是赏心悦目，更让高层见到了测试团队的专业性，从而更容易获得认可。

       　4、测试报告中，必须客观填写，但可以在结尾给予一定的建议

       测试报告中很关键的一点就是，必须客观真实的反应软件测试的质量检测结果。所以在报告中，应该排除过多的个人因素，客观的去填写结果、说明和报告。但是，如果你有一些想法和建议，也可以在报告结论之后进行附加说明。我一直认为测试人员除了发现缺陷，还有一些具有创造性的东西。

       　下面说下一个标准测试报告应该包含的内容信息：

       1)概述，包括本次测试的目的，测试的背景介绍。

       2)测试环境，包括测试软硬件环境及配置，以及测试环境的网络拓扑图

       3)测试的一些参考资料

       4)测试参与人员，以及投入的时间情况说明

       5)测试的进度情况，包括计划进度和实际进度

       6)测试情况介绍，包括测试的内容项说明。如功能测试具体的测试项，测试通过情况;性能测试的测试项，测试通过情况等

       7)缺陷的统计和分析，包括迭代次数，缺陷的分布情况，缺陷的覆盖情况，缺陷的发展趋势等

       8)本次测试的结论

       9)测试人员就本次测试的一些建议

       六、零基础学好软件测试是为了增加我们自身的一种技能、为了明天的一份高薪工作，学以致用，我们也应该在这里了解一下软件测试工程师日常的工作是什么?

       日常的工作流程一般是这样的(以一个版本迭代为周期):

       评审新需求，记录关键点–>编写测试点(用例)–>测试之前向开发了解部分实现–>执行测试(翻阅代码，查看主逻辑走向<可选>)–>提交BUG–>回归BUG(查看BUG代码改动)–>新需求的性能评估(可选)–>发布前的系统测试(结合自动化)–>发布–>自动化用例的补充(可选)–>业务逻辑总结归总–>休息

       在一天工作的八个小时中，有位资深软件测试工程师是这样安排的：30%的时间用于评审用例维护等准备以及后期工作;20%的时间用于执行测试用例，BUG回归;50%的时间用于自动化和新技术学习，引入!不知道你的一天会怎么安排呢?

       零基础如何学好软件测试，小编只是给你提供的是一个思路，需要在这些概况内容的基础上去深入了解、钻研，比如文中有提到测试需求，那么你还需要拓展如何收集需求、如何定位需求等内容;文中提到黑盒测试，那么你还需要拓展什么是黑盒测试、黑盒测试的特点优势是什么、在什么情况下使用以及如何使用黑盒测试等内容。如果你觉得自己没有很强的毅力，但你还想快速上手软件测试，那么你来啄木鸟学院吧，金牌讲师手把手带你入门，让你零基础学好软件测试，给自己3个月，给自己一次逆袭的机会!