软件测试生命周期

MILY: Arial">Software Testing Life Cycle
php?name=%C8%ED%BC%FE%B2%E2%CA%D4">软件测试生命周期

如同软件生命周期，我们也可以将软件测试阶段按照生命周期的方法去分析。

【这种思想，我是在一个国外的网站上看到的。对于如何开始和什么时候开始进行软件测试，我觉得目前来说如果硬性的去规定按照什么什么流程来说，有点形式主义。我个人的经验来说，很多项目都是在开发人员完成大部分代码的情况下提交给测试人员测试。很多时候，都没有任何文档，即使有也没有时间去看。这个时候如果按部就班的去制定什么测试计划，测试用例等等，不是不能，但是基本上都因为时间和项目进度的影响而大量的缩减形成的文档的数量。

但是，不做不代表着我们不去思考。个人觉得，在当前中国软件测试水平比较低的状态下，我们应该做到即使没有去做，但是也应该想到，而且应该不断的思考和学习，并且广泛的交流经验。为了将来的从事测试行业的新人们能够提供足够多的借鉴。所以，尽量做到抛砖引玉吧

这篇文章是借鉴了原作者的思想，将其主要内容用中文表达出来，所以大部分是作者的思想，但是不免带有我个人的一些主观想法，所以还请各位谅解。而且由于原作者是共享的是一个公司内部的文档，所以我也不便将其原文贴出，不过主要思想我是能够提供给大家的。共同学习。】

软件测试周期分为如下的阶段：
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. 设立一个数据库将手工测试和自动测试用例放到一起管理。我觉得不如只输入编号，然后剩下得字段用于记录每个测试用例在不同软件版本时的情况。例如，是否通过，还是阻塞了和有那些问题报告等等。

Analysis -This is external document phase
这是一个外部文档阶段。之所以说是外部文档，是因为这个阶段的工作主要都是从客户和开发组得到的文档。在这个阶段，对这些外部文档进行分析和总结。根据得到的信息，去创建测试的框架和文档。所以本阶段主要的工作是完成分析，搭出框架，书写大纲等。并不是要所有的文档工作都在本阶段内完成。

包括的主要工作是：
1. Develop Functional validation matrix based on Business requirements 制定功能验证矩阵，基于商业要求。嗯，我觉得这里应该是根据设计说明书来划分需要测试的功能区域，每个区域内要测试的元素和功能逻辑。这样就是建立了一个可以被测试用例和问题分类使用的功能验证表格。而且可以检验测试的覆盖度。
2. Develop Test Case format 制定测试用例格式。就是制定一系列的文档格式。对于UI，功能，性能，自动化测试脚本等应该都有不同的格式规范。然后给出测试优先级别，这样优先级别低，对系统影响小，一般都比较稳定的一些测试用例就可以减少测试频率和周期次数。然后最好给每个测试用例估计一个时间，这样便于统计和管理人力资源。
3. Develop Test Cycles matrices and time line 制定测试轮次和时间线。这时候应该是根据写好的测试用例估计的时间，按照对系统的不同测试点制定测试轮次。然后每个轮次之间有个时间点。例如在刚刚收到产品时，做的都是简单的功能的验证测试。这时候可以设置一个测试目标，选择一批测试用例。然后在测试目标达到后（比如，测试用例通过率达到85％）就可以进行复杂的功能测试。这个就可以称之为一个轮次。是以测试用例走完一遍为测试轮次的。当然也可以设置，一周或一个月为一个轮次。因此我们看到，找个实际上考验的是一个领导者制定计划和管理执行计划的能力。好的管理人员就能够制定有效的针对具体系统不同的计划，而不是一成不变，老是用一套方法。
4. Begin writes Test Case based on Functional Validation matrix 根据功能验证矩阵书写测试用例。 这个就没什么好说了，以前写过一个怎么写测试用例的文档。总之一句话，测试用例书写的标准就是满足需要，而不是硬套模板。
5. Map baseline data to test cases to business requirements 将用户需求中的设定测试数据和测试用例链接。有些用户，需要你对某些特殊的数据结构或者数据类型等等进行测试，这时候就需要将那些数据独立出来，以便能够复用。
6. Identify test case to automate 标示出能够使用自动工具的测试用例。将一些能够使用自动化测试的用例做一个标示，这样，在人力资源较少的时候，或者需要快速回归的时候就可以使用自动工具了。有些测试用例是直接就写成测试脚本使用测试工具测试的。有些是事先写为手工测试测试用例，可以通过使用已有的自动测试脚本快速的编制成自动测试用例的。毕竟手工测试和自动测试各有利弊。
7. Automation team begins to setup variable files and high-level scripts in Auto tester. 对于自动化测试组来说，这个时候就要做一些基本的工作了。像一些公用的文件和一些一些基础的公共函数和方法。
8. Define area for Stress and Performance testing 制定出要进行压力测试和性能测试的区域。并书写测试用例。
9. Begin setup the test cycles 根据已经完成的测试用例，开始制定测试轮次中包括的测试用例，总轮次，测试时间等等。
10. Review the documents 不断的复查文档，防止出现偏差。这个工作可以有一个固定周期，比如一个月内有几次，分别查看那些文档等等。
11. Review test environments 检查测试环境。包括软件，硬件，人力等等。

Design - This is architecture document phase

本阶段是完成测试内部文档的阶段，这些文档大部分都是在分析阶段形成了大体的组织结构和大纲的文档，像测试用例之类的都有了一些基本的描述，本阶段主要的工作就是完成这些文档的最终书写。在本阶段后，基本上测试计划，测试时间表，测试数据，各种相关文档都应该处于完成阶段。当然，仍然可以通过设计的危机处理机制进行更新。

但是特别要指出的是，测试用例并不能够在本阶段完成。由于新功能的添加，具体功能的实现方法，修改功能等因素，测试用例只能不断的更新。

包括的主要工作是：
1. Revise Test plan base on changes 根据具体的变化重新调整测试计划。
2. Revise Test Cycle matrices and timelines 根据计划的调整，调整各个测试轮次的内容和时间。
3. Revise Functional Matrix 根据变化调整功能设置。
4. Verify that test case and test data 确认已有的测试用例和测试数据仍然有效。
5. Continual write test cases and add new test cases base on changes 继续书写已经设定的测试用例和添加新的测试用例。一个测试用例，在本文中在上个阶段书写的时候可能只有一个简单的描述，具体的测试步骤需要后面填写。有的时候，有些测试用例事先没有考虑到，有些是重复的，所以需要删改。
6. Develop Risk Assessment Criteria 设置风险评估标准。通过设置风险评估，可以有效的帮助我们灵活的调整计划。比如，某个测试轮次是需要50个小时完成，而我们风险评估标准将这类测试设定为时间值应该设置为150％，也就是说，在计划中应该填写75小时为实际设定完成时间。
7. Finalize test cycles 最终完成各个测试轮次的设置。在本阶段结束后，除非有其他的特殊情况，通过预先设置的危机处理方法处理外，不再修改。
8. Finalize Test plan 完成测试计划。
9. Estimate resource to support development in unit testing 评估支持开发人员进行单元测试的可行性。有些项目，需要测试人员去帮助开发人员进行单元测试。

Construction - This is unit and model testing phase
本阶段是在开发人员编码的同时，最终完成系统预先设置的各种测试用例的阶段。本阶段的很多工作其实在上个阶段就已经涉及到了。本阶段完成后，进入测试的主要阶段，对产品进行实现设定的各种测试。

包括的主要工作是：

1. Complete unit-testing 完成单元测试
2. Complete all test case manual 完成所有的手工测试用例。随着系统不断开发，在拿到一个完整的软件版本之后，基本上手工测试用例都能够完成书写。
3. Complete auto testing tools 完成自动测试工具的开发。这个阶段可以设计编写一些专用的自动测试工具。
4. Complete Stress test case 完成压力测试用例
5. Complete performance test case 完成性能测试用例
6. Review the functional matrix 重新复检功能表
7. Complete auto test case 完成自动测试用例

Test Cycle - This is phase that to run Test Cycle(s), report bugs, verifies Bug fixes etc.
这个阶段就是最费时间的阶段了。按照实现制定好的计划，利用各种资源，工具，依循实现书写的测试用例对系统进行一轮轮的测试，直到代码冻结阶段。本阶段也包含了不断设置的回归测试。

包括的主要工作是：
1) Test Cycle 1, run first set of test cases
2) Report bugs
3) Bug Verification
4) Revise test cases as required
5) Add test cases as required
6) Test Cycle II
7) Test Cycle III
      ..............


Final testing - This is code freeze phase
本阶段是代码冻结后的测试阶段。这个时候需要进行的是最后的验证测试。本轮主要是完成最终的性能，压力，文档测试和UI等测试过程，开始形成系统说明书和用户手册。

包括的主要工作是：

Execution of all front to end test case – manual and automated

Execution of all back to end test case – manual and automated
上面是在最后进行产品gold的时候，进行的测试，主要是一些大的功能的传测，测试用例一般是对主要功能的一些验证。防止出现最终打包出错等认为因素。

Execute all Stress test
Execute all Performance test
Execute all UI test
Execute all documents test
Do the last cycle regression test
以上测试就是最终的功能测试，这个时候一般不在去修改主要的源代码，只是对外观和界面的错误进行修复。只是对现有的一些问题进行跟踪和管理，必要的时候准备出版hot fix版本。

Implementation - This is review entire project phase
本阶段是对整个项目进行总结的阶段。
主要是书写一些最终的报告。例如，错误分析报告，包括一共有多少个，有效率是多少，分布情况如何等等。这个阶段主要是将好的经验总结下来，对不足进行思考，为下个项目做准备的放松的阶段。


从上面的叙述来说，这些阶段并不完全的各自独立的阶段。划分的主要依据是根据主要的工作目标而来。各个阶段不但相互影响，而且有时候时间上还会彼此交叉和颠倒。但是，最大的好处就是能够让测试人员更好的理解各项工作的目标和作用。而不是独立的去写测试用例，不管为什么。个人认为，这样把开发的生命周期概念融合进来，尽管这样划分有待讨论，但是可以让那些不熟悉测试的开发人员和测试人员对测试工作有个整体上的感受。所以，本文就是一个入门的普及读物吧。