（2）测试报告中，对于发现问题的环境和过程描述不细，不利于软件改正。 有些测试部门提交的测试报告，只有各软件发现的问题和缺陷列表，测试的条件和环境，尤其是发现的过程描述不细致，不利于开发部门对照改进。 在测试工具的支持下，测试过程中发现的问题应该准确复现，并提交给开发部门，以便开发部门能方便地改正问题，这是正规化测试和开发的要求。 （3）测试认定的缺陷原则不明确，又没有事前告知被测方，很容易造成测试人员与开发人员对于错误和缺陷的认定不一，引起对测试结果的误解。 测试过程中发现的问题，应该无二义性，得到测试和开发双方的认可，这点应该非常明确。测试以软件需求为依据，由于部分软件需求对于功能描述不细，使用手册对于部分细节也没有定义，当测试人员发现一个问题或疑义时，由于没有规范化的测试法规和原则，容易造成双方对于测试结论存在分歧。 例如：MIS软件中，当用户保存数据成功时，开发人员将保存的结果显示在记录列表中，而测试人员则认为应该显示提示窗口，告诉用户：“保存成功！”，这两者就存在明显的分歧。 测试人员认为开发方的软件存在缺陷，而开发方认为他们的工作方式已经可以满足用户的要求，而且，频繁的显示提示窗口，会打乱用户的处理流程。 此时，若没有事先明确的测试规范和细则认定，这类错误就无从认定。测试人员在未经认定的情况下，片面地将这类错误认定为缺陷，罗列在测试报告中，对测试结论是非常不严谨的。对于开发方也是非常不公平的。 对于这类问题，可以在测试规范中加以明确说明，事前公之于众，做到开发和测试双方的认可，避免在测试中对于问题认定的歧义。同时，对于部分无法认定的情况，应该和开发方商定后加以定性，并对测试规范和细则随时加以修订，以便开发方日后的改进和完善，共同提高软件开发和测试的水平。 （4）对于多次测试过程中发现的问题，开发方和测试方都应有倒查机制，及时发现问题的出处，以便提高软件开发和测试的规范化水平。 现在，测试人员对于同一软件的多个版本进行多次测试时，有时会发现不同的问题和缺陷，这些新的缺陷，有些是由于开发方在改正前期的错误时引起的新错误，有些是在前期版本中就已经存在的错误，只是由于测试方在早期的测试中测试不认真而遗留的问题，对于这两种情况，应该区别对待。 对于开发方后期改正引起的新错误，是开发方新产生的，应该视为开发方修改错误造成的问题，视为新的软件错误。对于前期就已经存在的问题，应该认定为由于测试部门前期测试不认真而忽视所遗漏，对于测试方应该予以警告和批评，督促其加强测试的重视和认真程度，而不应简单地认定为开发方的错误（当然，开发方还是应该认真改正这类问题）。 否则，这类问题地隐藏，会导致测试部门对测试重视不足，不利于提高测试方的测试水平。同时，倒查机制的建立，对于双方都有明显的鞭策和激励作用，于各方都有好处。 对于这些问题的确认认定，从开发方提供的各种版本的软件产品中，可以很容易地发现问题确切出处，同样，倒查机制的贯彻，也可以促进软件配置管理地实施和完善。 （5）在可能的情况下，测试部门应该将测试工具提供给开发部门，以便其在早期建立测试环境，完善测试环境，提高测试水平。 测试工具的实施，使软件测试从早期的手工方式进化到自动方式，从定性为主发展到定量为主，各种规范的测试手段不断完善，测试工具也越来越全。 在这种情况下，测试部门可以提供部分测试工具给开发部门，对开发部门实施测试培训，提高软件的前期测试水平和能力，在开发部门内部完善测试机制，减轻测试的后期压力，提高开发部门对于测试的重视程度，共同提高软件的开发水平，做到开发和测试水平的同步提高。 我们相信，随着开发和测试的不断规范，提供的软件产品将更加完善，我们提供给用户的软件产品质量不断提高，对于提高我们的软件开发能力，有非常重要的意义。同时，开发和测试水平的提高，必将创建二者双赢的局面，共同提高软件开发的水平，向着CMM的更高要求迈进，使我国的软件开发从小作坊形式，向软件产业前进，提高我国软件的产品竞争力。 |
