规范软件测试流程.docx

《规范软件测试流程.docx》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、规范软件测试流程　测试计划　　做任何事情都会有输入输出，对于测试过程我们可以把输入理解为测试计划、测试环境准备、测试工具的选择等等，输出可以理解为测试结果。测试用例设计即可以理解为以测试计划为输入的输出，也可以理解为以测试结果为输出的输入，在这里咬文嚼字没有任何意义。所有的这些书籍和过程文档无外乎告诉我们一个道理，做测试需要做好准备工作，把做一件事需要做的准备工作做好，明确做这件事的目的，最终达成目的并验证结果是我们要做的事情。这要求我们有一个完善的“测试计划书”。　　输入：测试目的，测试计划，测试用例设计书，测试环境　　输出：

2、测试结果报告书，BUG票，BUG分析，追加测试用例　　测试计划的编写工作应该从以下几个方面考虑问题：　　1、要充分考虑测试计划的实用性，即，测试计划与实际之间的接近程度和可操作性。　　编写测试计划的目的在于充分考虑执行测试时的各种资源，包括测试内容、测试标准、时间资源、人力资源等等，准确地说是要分析执行时所能够调用的一切资源以及受各种条件限制，可能受到的各种影响。说的再明确一点就是要“计划”“如何”去做“测试工作”，而不是“如何编写测试计划”。　　2、要坚持“5W1H”的原则，明确测试内容与过程。　　◇明确测试的范围和内容（WH

3、AT）；　　◇明确测试的目的（WHY）；　　◇明确测试的开始和结束日期（WHEN）；　　◇明确给出测试文档和软件册存放位置（WHERE）；　　◇明确测试人员的任务分配（WHO）；　　◇明确指出测试的方法和测试工具（HOW）。　　测试用例　　为什么说测试用例重要？　　测试用例的重要性是毋庸置疑的，它是软件测试全部过程的核心，是测试执行环节的基本依据。　　测试用例主要设计方法　　●错误推测法　　●场景法　　●等价类划分法　　●边界值分析法　　●判定表法　　●因果图法　　●状态迁徙图法　　●流程分析法　　●正交分析法　　●正交实验法　

4、　如果是自己做的设计，自己PG，其实错误推测法，场景法，流程分析法收效会明显得多。因为熟悉流程，所以对可能存在问题的地方也是一目了然，不过这些对经验的要求又太高。　改进测试用例执行过程　　●项目的测试负责人和测试工程师参与软件需求调研，以测试角度分析需求的可测性，可构思将来对其测试的方法、原则等；更重要的是，对不可测或难以测试性问题要及时与客户或项目经理协调解决。　　●全面了解系统需求，从客户角度考虑软件测试需要达到的验证状态，即何些功能点需重点测试、何些无需，以便将来制定测试计划。　　●有健全且严格的体制保证测试执行者严格按照

5、测试用例执行测试。　　●如有对测试用例认识模糊或内容遗漏的地方，可暂做记录待后期解决，或经测试负责人与项目其他管理人员同意方可更新用例库。　　●测试负责人每日负责跟踪本测试子周期或阶段的测试用例执行情况，以及每日提交的缺陷报告，根据执行进展状态以及缺陷数量或严重等级与项目高层或其他人员展开交流，商议解决途径，并确定或调整未来时间的测试任务。　　●测试执行者负责执行自己区域的测试用例，还要负责跟踪该区域软件缺陷的修改进展，根据其状态不断验证软件功能点。　　●通过缺陷管理工具来管理软件缺陷；这样的集成工具都提供了清晰的报告模版及强大

6、的追踪功能，测试团队的每一成员按照自己的角色和权限访问缺陷管理工具，并不断跟踪软件缺陷的状态。　　测试过程　　测试的过程应该为五个阶段，分别是发现问题、问题解析、解决方案、执行、验收。　　发现问题　　这个步骤最重要的就是发现(Discover)问题，详述(Discribe)问题,并且正确而详细地记录(Document)下来。在进入下一步骤前，我们测试人员应该问问自已以下这些问题：　　对于问题是否已经有简明的描述。这一部分我们经常会犯的错误有2点：　　●过分熟悉流程的测试人员，这是由于目前我们的测试人员和开发人员没有独立，会直接把

7、问题解析写在问题描述中，虽然当时方便了问题解析对问题的解决节约了时间，但是当日后发生类似问题时由于没有恰当的问题描述导致问题解析无法比对，反而浪费了人力。　　●是问题描述过于含糊。如“XXXX-XX-XX发现系统死机”，这样的描述对问题解析者来说无疑大海捞针，问题记录者应详尽的描述问题发生的背景，场合，以用记录描述可以再现为要求描述问题，根据问题描述可以在实验室环境再现问题。　　严格比对测试输出，避免错过问题。　　经常会有问题明明PT甚至MT阶段就能发现却遗留到了ST阶段。这是由于我们在测试过程中没有认真比对结果造成的，协议栈测

8、试最重要的测试成果物就是LOG，是否对LOG中每一个接口，每一个参数进行了确认。如果时间紧迫不可能对每一个参数进行检查，最起码是否对我们关心的参数，对关键流程进行了检查。有时候很多问题时仔细看LOG就能发现的。所以，　　●严格比对测试结果是否为测试用例的期望。