软件测试管理心得体会

通盘考虑测试，了解测试需求，测试目标，测试时间，测试力量（对测试人员进行适当的培训），测试要提交的产品，估计测试规模，最后制定测试方案计划，采取合适的测试策略。

测试需求获取：若有需求文档，测试需求来源于软件需求规格文档，设计文档和用户手册。如果没有文档，需求来源于用户或者开发以及行业规范和用户习惯。

测试目标制定：项目测试？产品测试？如果是项目测试，而工期又比较紧张，对于测试范围和测试深度要进行合理的裁剪；如果工期比较充裕，就进行比较充分的测试。如果是产品测试，进行比较充分的多轮测试，如果着急推向市场，可进行迭代式研发，分批次的增加功能。测试充分度，有浅到深：1）基本的业务流程，基本功能操作，正常规范的输入；2）分支的业务流程，扩展的功能操作，边界的输入；3）异常的业务流程，易用的优化的操作，异常数据的输入。

测试时间安排：估计测试任务量，根据软件质量安排测试阶段，每个测试阶段的目标和完成条件，每个阶段的测试内容，多个阶段迭代时如何保证测试质量？（第一个版本测试全部可测功能，最后一个版本尽量再执行全部用例，至少要测试基本流程和基本操作，中间版本回归修复的问题并测试新增的功能，原则上在每个测试阶段不能变更软件功能和代码，避免造成测试的反复）

测试人员安排：当多个小组同时进行时，合理安排测试时间和测试人员。每个小组都要合理搭配人员，有负责人，有主力，有辅助。主要的人员组内要有备份，组长要有备份，避免个人原因影响整个小组进度，甚至导致无法进行的情况。

测试产品：在测试开始之前了解要提交的测试产品规格，避免重复劳动，测试过程中进行相应的记录。测试进行完后马上编写文档，避免日久遗忘。

测试培训：在测试开始之前，要使大家对于测试流程，测试过程中要进行的活动有正确而清醒的认识；获取测试需求，分解测试项，设计测试用例，执行测试用例，记录执行结果，报告发现的问题，理解bug的状态变化过程。测试用例要追踪到测试项，而问题报告要追踪到测试用例，在输入执行结果的时候要选择版本号和关联到发现的问题。对于判定为无效的bug，它所对应的用例执行结果要重新输入，或者等问题置为打开状态后再输入执行结果。

测试项和测试用例的标题描述要简短，清楚。避免无意义的短语动词。分解测试项时粒度要合适，每个叶子测试项对应的用例在2-5个之间。测试用例的步骤要简单、明确、清晰、且具备可操作性，bug的步骤描述也要遵循同样的要求。做到一个bug只描述一个问题，避免一个bug里描述多个问题。但对于关系密切的、现象类似的且多次发生的问题可酌情合并在一个bug里边。

测试策略：如何采取合适的策略，达到测试目标，进一步提高测试效率和测试质量。根据测试任务，测试目标，测试时间，测试类型采取合适的测试策略和测试方法。根据测试任务的多少，测试目标的高低，测试时间的长短，不同的测试类型决定不同的测试策略。重点在于适合，裁剪要适合。功能测试策略，性能测试策略。任何测试，测试的有效性都是最重要的前提。无效的测试再完美，也只是空中楼阁、无源之水。测试的有效性具体到测试中主要包含：测试环境的有效性（尽量符合实际的生成环境，包含软硬件和数据等），测试内容的有效性，测试需求的有效性，测试目标的有效性等。

测试用例设计：功能测试用例设计应考虑的问题，效益最大，不要遗漏测试点，设计最少的用例，覆盖最多的测试点。方法的目的就是事半功倍：尽可能覆盖多的测试点，尽可能发现更多的问题。设计测试用例的两种思路：场景模拟法，功能点测试法。所谓场景模拟，就是模拟用户实际使用的和可能使用的业务流程，把功能放在场景中进行测试，从流程的角度去测试软件。功能点测试法，针对功能点设计测试用例，测试操作，测试输入输出，主要还是针对软件的输入输出设计用例。常用的测试用例设计方法都是针对输入输出进行设计：等价类划分，边界值分析，因果图，判定表，正交矩阵法，错误推测法。