福瑞博德-软件测试生命周期.pdfVIP

软件测试生命周期 如同软件生命周期，我们也可以将软件测试阶段按照生命周期的方法去分析。 【这种思想，我是在一个国外的网站上看到的。对于如何开始和什么时候开始进行软件测试，我觉 得目前来说如果硬性的去规定按照什么什么流程来说，有点形式主义。我个人的经验来说，很多项 目都是在开人员完成大部分代码的情况下提交给测试人员测试。很多时候，都没有任何文档，即使 有也没有时间去看。这个时候如果按部就班的去制定什么测试计划，测试用例等等，不是不能，但 是基本上都因为时间和项目进度的影响而大量的缩减形成的文档的数量。 但是，不做不代表着我们不去思考。个人觉得，在当前中国软件测试水平比较低的状态下，我们应 该做到即使没有去做，但是也应该想到，而且应该不断的思考和学习，并且广泛的交流经验。为了 将来的从事测试行业的新人们能够提供足够多的借鉴。所以，尽量做到抛砖引玉吧 这篇文章是借鉴了原作者的思想，将其主要内容用中文表达出来，所以大部分是作者的思想，但是 不免带有我个人的一些主观想法，所以还请各位谅解。而且由于原作者是共享的是一个公司内部的 文档，所以我也不便将其原文贴出，不过主要思想我是能够提供给大家的。共同学习。】 软件测试周期分为如下的阶段： Planning 计划阶段 Analysis 分析阶段 Design 设计阶段 Construction 书写阶段 Testing Cycles 测试阶段 Final Testing 完成阶段 Implementation 执行阶段 Planning - this is the product definition phase 这是产品测试概念定义的阶段。我觉得这部分的工作主要是管理人员在做，然后让测试组员进入某 些活动。 包含的工作是： 1. High Level Test Plan 制定一个高级别的测试计划，应该就是测试大纲了，包含多个测试周期的 设定等等。 2. Quality Assurance Plan 制定测试的目标，质量参数，beta 测试的验收标准等等。 3. Identify when review will be held 制定各个阶段进行 review 的时间。这个 review 应该是对上阶 段的情况进行分析和总结，以调整计划。也应该有一些讨论测试覆盖率或者某些 Test case 或者人 员的不足啊之类的东西吧。 4. Problem Reporting Procedures 制定错误报告的流程。比如说那些问题要报，那些问题暂时不用 报。书写的格式，跟踪的方法等等。 5. Identify Problem Classification 制定错误报告的类型。比如说那些是 UI 的，那些是功能的，那 些是性能的等等 6. Identify Acceptance Criteria 制定软件可接受标准。比如说错误率在多少，那些错误可以暂时不 修改，测试多少轮，覆盖率多少，测试深度多少等等。 7. Identify application testing databases 制定程序测试数据库。这个可能是模仿用户需求的数据库 模型是什么，或者也可能是一个包含需要测试的数据的库 8. Identify measurement criteria 制定错误的优先级别。分为紧急啊，一般啊，较高啊之类的级别。 用来给开发人员参考，那些需要先修改。 9. Identify metrics for the project 制定项目的跟踪。比如一些跟踪文档，每周提交的 weekly report 之类的。例如在周报里面包含着本周新写多少个问题，解决了多少个问题，有多少问题是无效的， 运行了多少个测试用例，通过率是多少等等。10. Begin overall testing project schedule 制定详细 项目计划表。包括每个阶段的具体时间了，需要的人数了，需要的资源了等等。 11. Review Product Definition Document 复检产品定义文档。主要是重新对设计文档进行阅读， 对现在开发的产品进行检验，防止出现误差。并且对一些设计提出用户角度的观点等等。这个应该 不用所有测试人员参与。生成的应该是设计文档的一个修改和一个会议记录之类的文档。 12. Plan to manage all test cases in a database, both manual and automated. 设立一个数据库将 手工测试和自动测试用例放到一起管理。我觉得不如只输入编号，然后剩下得字段用于记录每个测 试用例在不