有人提倡自由测试，就是没有测试计划、测试案例随意的测试。这种测试可以测出极少数比较随意、个性化的问题，这是写案例可能达不到的。但是只进行自由测试是不可取的，因为其没有计划性，所以无法实现测试覆盖的满意程度。进行对比发现，两个不同的测试工程师，对同一模块进行测试，一个人进行自由测试，一个人按照案例测试，同样是一天时间，前一个人发现了12个问题，后一个测出了57个问题。

　　当然测试、测试案例的编写是需要动脑子的，也需要很多经验。有经验的测试工程师一看到界面就会敏感的感觉到这个软件那里问题会比较大，那些输入、操作可能会导致严重错误，这是一个长期积累的过程。

　　如果有条件，用例编写完成以后，需求、研发的主要负责人、测试部门项目组相关成员组织对用例进行评审，以验证当前用例是否能够达到覆盖需求相应测试功能、性能点。

　　测试阶段：

　　按照测试计划，按部就班的执行测试案例，是这阶段的主要工作。但是在这个阶段还是有些事情要特别注意。比如：

　　1. 每次开发组提交新版本时，必须提交相关的报告给测试负责人，并抄送给测试部门经理，内容包括本版本软件更新的相应功能模块，与提供部署说明性文档。这样做的目的主要是可以尽快明确测试的内容，减少程序员和测试人员间重复性的沟通，方便其他测试人员对环境的部署工作。

　　2. 开发人员在提交测试版本之后，测试人员需要对本次提交的功能模块做冒烟测试，即：先花很少的时间测试基本功能是否都基本实现，保证本次提交的基本功能的实现且可用。这样做可以避免测试人员在测试过程中发现版本错误、提供的相应功能模块存在严重缺陷，导致后续工作无法进行时。如果发生以上问题，测试人员有权将该测试版本打回。

　　3. 测试过程中按照测试用例执行测试，标记测试用例通过情况。如果进行了随机测试发现软件缺陷，需将该用例补充到案例库中。测试过程中，发现缺陷后一定要记录到bug管理工具。测试过程中，一定要有正式的bug管理工具，这样可以提高整个测试开发的工作效率、保证bug的可追踪性，也为日后进行测试结果分析提供可能。最后要形成问题单，并对问题单进行确认。确认问题单的时候要注意：

　　● 一类问题出现在各个模块，要总结为一条，不要每一条都写；

　　● 对于问题的分级，可以分为“致命”、“严重”、“一般”、“建议”；

　　● 对于严重级别的划分标准还要根据系统的不同、相应功能的风险级别、以及一些特殊要求有所变动。

　　4. 回归测试也是测试过程中很重要的一部分内容。它的过程是：

　　● 识别出软件中被修改的部分

　　● 从原基线测试用例库T中，排除所有不再适用的测试用例，

　　● 确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0

　　● 依据一定的策略从T0中选择测试用例测试被修改的软件

　　● 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分

　　● 用T1执行修改后的软件

　　其中，第2和第3步测试验证修改是否破坏了现有的功能，第4和第5步测试验证修改工作本身。

　　在测试阶段主要是要注意测试的进度，控制测试风险的发生，实现测试计划的顺利执行，并保证测试质量。

　　测试总结：

　　测试工作完成后，测试负责人负责牵头对测试过程予以总结，对遗留缺陷进行评审。这个时候评审人员包括：产品部门经理、产品经理、研发经理、测试部门经理、测试主要负责人及其质控相关人员。对待有争议的缺陷应综合考虑各方意见，符合测试计划的准出条件以后，产品可以做发行工作。作为测试过程的最终成果，测试总结报告是最重要的表现形式。他应该包括各种测试过程和结果数据与分析、对产品质量的总结性文字等。当然在测试过程中形成的各种文档与测试结果数据，也都是我们宝贵的财富。我们需要对他们进行分析，以提高我们以后的软件开发、测试工作。