软件测试过程分解
拿到一个软件进行测试，需要一系列的动作、计划、文档，来完成测试任务。当然测试不是一个很简单的过程，不是说随便测测可以满足用户或者开发团队的需要。测试有一定的过程，需要采用各种测试技术、方法。下面我们说明这个过程。
测试需求阶段：
我们首先要对软件有个大体的了解：这个软件是什么行业的、涉及什么领域、采用什么技术、规模有多大、实现了什么功能等。这些问题可以通过口头的询问，也可以通过详细读取项目的用户需求说明书与用户手册来得到。
进行了这些大体的了解，我们需要根据实际的情况、限制制定测试的范围。这里我们可以先按照系统功能实现的各种角度进行业务功能模块风险等级的划分。评判标准如下：
1. 功能类型〔A高级－数据计算/验证；B中级－数据修改；C低级－数据显示〕
2. 业务影响〔A高级－合法性；B中级－错误信息；C低级－无〕
3. 使用频度〔A高级－非常频繁/大量；B中级－经常；C低级－极少〕
4. 受影响客户的数量〔A高级－大量/重要；B中级－组/群；C低级－很少
总之，对于核心流程、业务功能点，它的风险等级总是比较高的，这决定在进行测试的时候他是优先级高的。然后我们可以通过客观原因的限制终指定我们的测试的范围。这些客观原因包括：时间、资源、人员限制、成本等。当然，还有些特殊的需求会影响我们的测试范围，比如：用户或开发组要求着重测试一个不是很重要的模块等。但是一般情况下，我们都是优先所有资源对优先级高的模块进行测试，然后再测试优先级别低的模块。当然测试的充分程度也是我们需要考虑的问题，我们不可能进行完全测试，但是我们究竟要测的有多细使我们事先应该有考虑的，即使不写在文档上，也要贯彻到测试组长与测试工程师的头脑中。
在划定测试的范围后，我们需要选择测试的测试的实现方法，我们是在真实系统测试还是搭建测试环境？我们要搭建环境是需要仿真呢还是只要程序能运行不影响测试行了。这也跟实际的情况有关。当然能够在真实环境进行测试是好的了，比较真实。但是有时候往往不行，比如银行系统等。所以需要搭建环境的情况会很多。一般主要测试软件的可用性，环境不用很苛求。但是如果需要硬件很多或者测试其性能、可靠性等，需要比较接近真实的环境了。
然后我们可以根据用户手册形成我们的需求文档了。测试需求和测试案例很像，只是颗粒度粗细的问题，而且测试需求没有数据，测试案例要提供数据了。
形成基本稳定的需求文档后，测试介入需求评审，以便了解需求的相关内容以及测试工作的可行性分析（软件可测试性）。项目经理制定项目计划，测试部门测试经理/测试团队负责人制定测试计划，项目组测试人员阅读相关测试需求文档，如果存在疑问或者发现需求缺陷及时与需求人员沟通，如果是需求缺陷，可以将相关问题可以记录到bug管理工具以便进行跟踪。
设计阶段：
在设计阶段，研发部门进行软件的概要设计、详细设计以及必要的单元测试工作；测试部门进行功能、性能测试用例的设计（用例不仅仅包括用例本身，还包括测试数据），测试所需软、硬件资源申请、准备。
但是在实际上测试案例的编写是这一阶段的主要内容。首先我们要通过各种测试方法来使我们的案例的编写更加可行与有效。对于庞大的系统，我们往往无从入手。在这种情况下我们要先找到突破口。比如：象erp这种软件，流程性比较强，显然一个一个模块测试是不明智的，他的模块之间需要有数据流的流动才能运转，这是可以采用场景法确定数据流的大致情况。有些软件有明确的但是复杂的各种输入（原因），他们会导出许多复杂的输出，这个时候应用因果图方法理清因、果之间的关系。但是光用这两个方法显然是不够的，针对每一个输入，有无数种情况，我们要用等价类的方法把无限测试变为有限测试。当然边界值、错误测试都是很有用也必要的测试案例的补充。对于数字类型、日期类型等域的测试要格外注意。整个测试过程中应该检查错别字与提示的格式风格是否统一。对于一个软件，如果没有很明确的流程，也不需要使用因果图、场景法等方法。但是它依然需要等价类、边界值与错误输入等技术。对于这类软件我们可以分模块来进行功能的“扫菜单”方式组织案例的编写。
在这个测试中，查询是一个比较特殊的地方。因为如果做到完全测试，那是肯定不可能的。所以我们要分析比较常用的查询条件与查询符号的组合，并问询用户或相关人员经常使用的查询条件，来进行部分测试。
实际上设计案例也是测试内容的一部分，通过各种方法和经验可以找到可能的测试步骤，设计流程与数据。设计案例也是整个测试关键的部分，在进行测试案例的设计的时候，要贯彻我们在前期进行需求、设计的决定。而且这个测试案例库可以被复用，在测试过程中也可以不断进行补充。在设计案例的时候，还要注意各个模块之间的联系，比如有些软件模块中，进行了参数设置后，导致添加、修改模块界面中相应下拉菜单的内容消失。这是一个模块的操作影响了另一个模块。
当然在设计案例的时候易用性也要作为功能测试的一个重要部分，尤其是对于有些行业，如政府机关、金融等，易用性都很重要。还要根据行业的不同突出一些测试用例，如安全性、可靠性等。
有人提倡自由测试，是没有测试计划、测试案例随意的测试。这种测试可以测出极少数比较随意、个性化的问题，这是写案例可能达不到的。但是只进行自由测试是不可取的，因为其没有计划性，所以无法实现测试覆盖的满意程度。进行对比发现，两个不同的测试工程师，对同一模块进行测试，一个人进行自由测试，一个人按照案例测试，同样是时间，前一个人发现了12个问题，后一个测出了57个问题。
当然测试、测试案例的编写是需要动脑子的，也需要很多经验。有经验的测试工程师一看到界面会敏感的感觉到这个软件那里问题会比较大，那些输入、操作可能会导致严重错误，这是一个长期积累的过程。
如果有条件，用例编写完成以后，需求、研发的主要负责人、测试部门项目组相关成员组织对用例进行评审，以验证当前用例是否能够达到覆盖需求相应测试功能、性能点。
测试阶段：
按照测试计划，按部班的执行测试案例，是这阶段的主要工作。但是在这个阶段还是有些事情要特别注意。比如：
1. 每次开发组提交新版本时，必须提交相关的报告给测试负责人，并抄送给测试部门经理，内容包括本版本软件更新的相应功能模块，与提供部署说明性文档。这样做的目的主要是可以尽快明确测试的内容，减少程序员和测试人员间重复性的沟通，方便其他测试人员对环境的部署工作。
2. 开发人员在提交测试版本之后，测试人员需要对本次提交的功能模块做冒烟测试，即：先花很少的时间测试基本功能是否都基本实现，保证本次提交的基本功能的实现且可用。这样做可以避免测试人员在测试过程中发现版本错误、提供的相应功能模块存在严重缺陷，导致后续工作无法进行时。如果发生以上问题，测试人员有权将该测试版本打回。
3. 测试过程中按照测试用例执行测试，标记测试用例通过情况。如果进行了随机测试发现软件缺陷，需将该用例补充到案例库中。测试过程中，发现缺陷后一定要记录到bug管理工具。测试过程中，一定要有正式的bug管理工具，这样可以提高整个测试开发的工作效率、保证bug的可追踪性，也为日后进行测试结果分析提供可能。后要形成问题单，并对问题单进行确认。确认问题单的时候要注意：
● 一类问题出现在各个模块，要总结为一条，不要每一条都写；
● 对于问题的分级，可以分为“致命”、“严重”、“一般”、“建议”；
● 对于严重级别的划分标准还要根据系统的不同、相应功能的风险级别、以及一些特殊要求有所变动。
4. 回归测试也是测试过程中很重要的一部分内容。它的过程是：
● 识别出软件中被修改的部分
● 从原基线测试用例库T中，排除所有不再适用的测试用例，
● 确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0
● 依据一定的策略从T0中选择测试用例测试被修改的软件
● 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分
● 用T1执行修改后的软件
其中，第2和第3步测试验证修改是否破坏了现有的功能，第4和第5步测试验证修改工作本身。
在测试阶段主要是要注意测试的进度，控制测试风险的发生，实现测试计划的顺利执行，并保证测试质量。
测试总结：
测试工作完成后，测试负责人负责牵头对测试过程予以总结，对遗留缺陷进行评审。这个时候评审人员包括：产品部门经理、产品经理、研发经理、测试部门经理、测试主要负责人及其质控相关人员。对待有争议的缺陷应综合考虑各方意见，符合测试计划的准出条件以后，产品可以做发行工作。作为测试过程的终成果，测试总结报告是重要的表现形式。他应该包括各种测试过程和结果数据与分析、对产品质量的总结性文字等。当然在测试过程中形成的各种文档与测试结果数据，也都是我们宝贵的财富。我们需要对他们进行分析，以提高我们以后的软件开发、测试工作。
