软件测试的生命周期是？
软件测试周期分为如下的阶段：
Planning 计划阶段
Analysis 分析阶段
Design 设计阶段
Construction 书写阶段
Testing Cycles 测试阶段
Final Testing 完成阶段
Implementation 执行阶段
Planning - this is the product definition phase
这是产品测试概念定义的阶段。 我觉得这部分的工作主要是管理人员在做，然后让测试组员进入某些活动。
包含的工作是：
1。 High Level Test Plan 制定一个高级别的测试计划，应该就是测试大纲了，包含多个测试周...全部
软件测试周期分为如下的阶段：
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 testng 评估支持开发人员进行单元测试的可行性。
有些项目，需要测试人员去帮助开发人员进行单元测试。
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
本阶段是对整个项目进行总结的阶段。
收起
