“软件测试项目实战”阅读报告.docVIP

《软件测试项目实战》阅读报告 本人受部门安排学阅《软件测试项目实战》（以下简称“软测”），任务完成，现就“软测”提及的相关理论、测试用例实例及结合我们质量保证部前阶段的相关工作，特作此汇报。 “软测”是按照测试工作流程“确定测试计划——设计测试用例——执行测试——测试总结”来编排的。 在“确定测试计划”阶段，书中特别提到：要以透彻理解需求规格说明书为基础，在明确需求的前提上，再进行测试的后续工作。这一点，在我们的前期工作中贯彻的较为深入，在开发每一个模块时，我们都做了“需求评审反馈单”。后阶段工作应延续此做法。 “软测”中使用了详细的篇幅来讲述如何编制测试计划（P6——P23）。编写测试计划的目的主要有：可以有效地进行过程控制，资源配置；便于工作安排；便于其他人员（程序员）了解测试人员的相关工作，进行有关工作的配合。这一点，我们在前期的测试工作中做的很不到位，没有制定相应的测试计划。 测试用例的设计是一个动态的过程，其可因不同的测试阶段，变动的需求、资源等相关因素的影响。“软测”一书中提供了大量的测试用例实例，对其质量，本人保留自己的意见。其好的一方在于精简、明晰。其提供的测试用例按照类别将所有应测元素的同一个测试点置于一个测试用例中，如测试界面元素必填项是否可以为空，前阶段我们通常的做法是：将界面元素分开，比如“账户名”、“密码”等等，然后为每一个元素设计是否允许为空的测试用例，如此造成测试用例多而杂。而“软测”中用一个测试用例涵盖所有必填元素是否为空。这种设计方法值得我们借鉴。不好之处，我个人认为：“软测”提供许多模块的测试用例不够完整，许多应测项没有测试，如果这样做的话，数据库中可能会产生许多垃圾数据。 “软测”中提及的测试用例都是基于系统测试阶段，当然采用的是黑盒测试方法。在前阶段工作中，我们主要针对的也是系统测试阶段。在这个阶段我们暴露的问题也比较多，主要在如下几个方面：测试人员理论知识不够深厚，无法做到“理论指导实践”，在设计测试用例时，随意性、主观性较大；测试用例不够简洁清晰，无法做到让设计人员之外的其他人员在短时间内明白测试用例的意义；测试用例设计的时间控制，过程控制不够精确。 如何解决上述问题，就“软测”提供的信息来看，我个人认为：我们的测试人员应遵循“理论——实践——理论”这样的工作模式，而不要一味的钻在某个点上“出不来”。 本人提一个建议：在我们原先定的标准的测试文档中，增加“性能测试”、“安全测试”、“兼容性测试”。将原先“界面测试”中的“浏览器兼容性测试”抽出来，放到“兼容性测试”中。 还有一个值得重视的问题：我们前阶段的工作少有对程序和代码进行测试。虽然说单元测试、集成测试都由程序员完成。但实际情况是，程序员们在这一块做的很不到位（可能有，但很不规范，无规划，无记录）。我们测试人员也没有要求程序员进行相关的单元测试和集成测试。 “软测”提出的要求是：程序员创建一个工程，应创建相应的测试工程；程序写一个类或方法，应写相应的测试类和测试方法（非常简单的可以不写）。如此开发速度可能受到影响，但这是质量保证的一种重要手段，而且这两部分工作应该分开，写与测应该由不同的人员来完成。下一阶段，本人建议：测试人员配??程序员完成此工作。 测试总结，“软测”是这样阐释其意义的：可以为下一轮测试提供更好的指导。此阶段的核心任务就是撰写测试总结报告。同样“软测”使用了P142——P162长达二十页的篇幅来详细剖析此任务，可见其重要性。 而在前一阶段的工作中，我们测试工作只有开头，没有结尾。没有编写相应的测试总结报告。本人建议：下一阶段，应该借鉴“软测”的做法，测试结束时，需提交测试总结报告。 关于自动化测试就目前来讲，我们完全处于空白状态。下一阶段我们应加强这一方面的培训，力争能够使用自动化测试的地方，尽量使用自动化测试工具，减少我们的工作量。“软测”详细地讲述了自动化测试工具“LoadRunner8.0”的使用。至于我们要使用什么样的自动化测试工具，此事待决策层确定。 ——质量保证部：屈仁军 二〇一〇年九月二十六日