基于V模型，针对详细设计的单元测试
1)为什么要进行单元测试：
系统测试是一种黑盒测试，也就是不需要了解系统内部结构，只关心外部实现，那么这样发现的问题将不会太彻底，而单元测试是一种白盒测试，只有深入到系统内部，才能对软件内部逻辑控制结构上的问题进行清除，对发现、定位和解决问题将是最直接，最彻底的方式;在效率方面，单元测试往往是集成测试的2倍，系统测试的3倍;成本方面，一个问题如果遗留到后期阶段解决，那么付的代价将会很高，而且是成倍递增。
单元测试有效的验证代码是否与设计相符，尽早发现设计和需求中存在的错误，以及在编码阶段引入的错误。
2)单元测试的内容：
单元测试首先要理解单元原本是要做什么的，而不是它现在实际做了什么，我们更关心的是：模块或函数是否做了它该做的事情而没有做不该做的事情。
主要依据详细设计的描述和源程序清单针对五部分内容进行测试：模块接口、局部数据结构、边界条件、出错处理、独立路径。首先模块与周围环境的接口有无差错应首先得到检验，否则其内部的各种测试工作将是徒劳;局部数据结构也是常见的错误来源，对基本控制流进行测试同样也会发现大量的错误;异常处理要给予适当的出错处理对策，以便在程序出错时，能对出错程序重新做出安排，保证其逻辑上的正确性;边界测试，对数据流的测试将是单元测试的最后一步。
单元测试评估的标准是逻辑覆盖率。
基于V模型，针对概要设计的集成测试
1)为什么要进行集成测试，
集成测试的目的是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，当一个系统还没有完成，设计相应的桩和驱动模块进行集成测试，便于早期发现接口问题以及集成后的功能问题，同时编码不是一个可以一次性通过的过程，对最初的单元测试中一些被忽略和遗漏的BUG，也将会在集成测试阶段被发现。
2)集成测试的内容。
概要设计的对象主要为系统，系统子系统，模块，子模块，函数等，通过体系结构进行模块的划分，并进行数据设计、接口设计，遵循高内聚、低耦合的原则，对其进行分解描述，依赖关系描述，接口描述等，并保持模块与需求的对应关系，因此，对集成测试的重点，将主要测试模块之间的接口和接口数据传递关系，以及模块组合后的整体功能。
确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确，验证接口是与设计相符合?发现设计与需求中存在的错误是集成测试的工作内容。
通过接口的覆盖率进行集成测试的评估。
基于V模型，针对需求规格说明书的系统测试
1)为什么要进行系统测试。
系统测试是我们传统观念的一种测试方式，也就是一般放在项目功能基本实现后的功能和性能等方面的测试，目前软件测试已由开发的后期介入扩展到了整个生命周期，由基于代码运行扩展到静态走读，由传统的发现错误为目的扩展到了对缺陷的预防。
2)系统测试的内容。
系统测试主要验证功能是否符合需求规格定义，是一种在实际环境下的测试，同时也是全面的系统级测试，其内容包括产品功能、性能指标、兼容性、可靠性、容错能力、可维护性、安全性等方面;功能方面主要检查是否有不正确或遗漏了的功能，性能测试目标是度量系统相对于预定义目标的差距，必须要有工具的支持;GUI测试界面实现与界面设计的吻合，以及界面处理的正确性，是直接面对用户的首要条件，因此相对在易用性方面显的较为重要;兼容性，可靠性的、容错性，可维护性，安全性等根据项目要求的不同，具体情况具体分析。
系统测试评估的标准是对需求规格说明书的覆盖率。
基于系统测试层面的个人经验总结：
(一)用例设计、执行、管理、沟通：
第一：测试用例的设计。在需求分析、概要设计、详细设计阶段均需要设计测试用例，测试用例设计的有效性和合理性对整个测试执行起着至关重要的作用，它将直接影响缺陷发现率。如果用例如何设计的不太合理，满足了出口准则，但在发布以后，产生的大量缺陷，将直接影响用户满意度，浪费时间和资源，那么，如何进行测试用例的设计?怎么设计出高效率的测试用例呢?
1)要明确，对于开发所关心的是功能是否可以被实现和如何具体实施，而对于测试来说，关注的是功能是否被正确实现，而不管这些功能是如何被具体实施的;
2)在设计用例的过程中，要保证每一个功能点均有相应的用例所对应，保证测试用例对需求100%的覆盖;
3)测试人员需要对被测软件的需求和业务进行全面了解，否则对被测对象了解不深，只能就被测单元的功能设计用例，而对于该功能点所要执行的流程无法正确保证，此时可与需求分析人员和客户进行交流，以获得更多的业务方面的信息;
4)采用各种测试用例设计方法，用最适合的方法来达到用尽量少的用例来发现尽量多的BUG，如针对功能测试的等价类，边界值，因果图法，状态迁移图，正交分析法，错误猜测法，场景路径覆盖;针对单元测试的语句覆盖，分支覆盖，条件覆盖，条件组合覆盖，路径覆盖，循环覆盖，针对类的功能性和结构性测试、数据流测试，异常测试，对类的方法的测试等。
用例的设计是一个长期经验积累的过程，需要我们在工作中多留心，才会有新发现、新思想。
第二：测试用例的执行。测试用例的执行过程将是缺陷产生和修复的过程，同时也是测试用例进行更新和优化的过程。
1)缺陷的提交与跟踪;
测试人员进行测试用例的执行，在执行过程中，做好每日缺陷的提交，测试主管对缺陷进行分配及对修改时限的要求，开发人员进行缺陷的修改，修改完毕后，测试人员进行回归测试，并时刻关注缺陷库缺陷的状态及严重级别较高的缺陷进行及时跟踪。我们在亦庄的项目在这点就做的不错。
2)缺陷的收集与度量;
测试人员要保证所描述的缺陷是清楚的、准确的，必要时要配有截图，开发人员修改完毕后，要保证注明原因和解决的办法，有了上述两条的保证，缺陷的收集和度量工作将变的非常容易，对缺陷进行分析如发现缺陷多位于边界值，那么可以根据此项对公司的编程规范进行相应的完善。当对几个项目进行缺陷收集和度量后，具备一定的条件情况下，将可对类似项目进行缺陷的预防工作。
3)缺陷报告：
阶段性的缺陷报告反映了项目的进展情况，利于测试主管判断是否有趋势显示需要增加测试的区域或判断项目是否符合预定发布日期的正常轨道上，并可根据缺陷报告所反映的情况进行调整未来测试任务的时间。
第三：用例的更新与管理。
在执行测试用例的过程中，由于需求或程序具体实施的变更，测试的相应步骤需要进行调整或补充测试用例，测试用例的执行过程也将是测试用例进行更新和优化的过程。
缺陷的收集是一个良好的习惯，而测试用例的规范化管理同样也是一个不错的行为，将测试用例放入项目历史用例库，可为类似项目的测试人员提供借鉴、开拓思路、节约时间，共享的数据资源，可以让测试人员有更多的时间和精力放在对测试过程的考虑和测试用例的选择方面，逐步提升整个测试团队的用例设计水平。
第四：沟通与交流。在软件开发的过程中，交流占有非常重要的地位，因为有时项目紧、时间短，文档来不及更新，那么这时就需要及时与开发进行沟通与交流，对软件功能的具体实现，最新最正确的理解也许就在开发的大脑中，只有及时交流才会获得最及时的信息，尽早测试并完善测试用例。
(二)性能测试过程：
性能测试在软件的质量保证中起着重要的作用，对于一个系统当功能满足要求以后，还要考虑它的性能问题，它是否满足需求，是否能够达到最终用户的性能要求，是否适应未来业务的增长等，这是在系统正式运行前大家都比较关心的问题，以下从性能测试的过程来说明性能测试是如何开展的，以及各阶段相关人员的配合情况。
1)测试前期准备：开展性能测试的前期阶段，要求被测对象至少具有一定的稳定性，在功能上基本满足需要，同时性能测试不仅仅是测试人员的事情，可能需要整个项目组的参与，性能测试人员需要协调相关的人员，组建成一个合适的测试团队;在制定性能测试计划之前，要充分了解需求，与相关的需求人员进行沟通。
2)测试工具的引入：性能测试工具的选择，自动化的性能测试工具不是对每一个系统都适合的，要进行一个功能符合度的评估，如所有的工具无法达到要求的功能符合度，可根据公司情况自行开发。
3)测试计划：该阶段主要由性能测试人员制定性能测试计划，重点需要了解，系统有哪些重要的功能模块，大约的用户是多少，用户的行为是如何分布的，每个模块的使用频度，大约的数据量，使用什么样的硬件，系统稳定性的要求等等制定测试计划。
4)测试设计与开发：设计性能测试场景，第一客户端性能的测试：主要考虑并发性能测试，疲劳强度测试(负载测试)，大数据量测试(压力测试)和速度测试，以并发性能测试为重点;第二网络上性能的测试：主要是利用成熟先进的自动化技术进行网络应用性能监控，如：网络带宽、延迟、负载、TCP端口的变化是如何影响用户的响应时间的;网络应用性能分析，如：哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量;网络预测：预测网络流量的变化、网络结构的变化对用户系统的影响，进行容量极限分析，预测网络设备迁移和网络设备升级对整个网络的影响。第三服务器端性能测试：实现服务器设备、服务器操作系统、数据库系统、应用服务器等的全面性能监控。
同样监控应选择用户较为关心的模块或系统中较容易出现问题的模块进行性能测试场景的设计与开发。
5)测试执行和管理：运行脚本监控，添加性能监控指标，由性能测试人员执行。
6)分析结果和优化性能：对脚本的运行结果进行收集，并查看相关的性能测试指标，将性能测试结果提交给相关人员对结果进行分析，需要性能测试人员，架构师，程序员，SA，DBA共同参与对结果进行评估，对系统进行优化后，再次执行性能测试，多次结果对比，以达到满足公司标准或规范，满足性能测试出口准则。
测试是一个不断深入的过程，由系统测试向前期的单元测试和低粒度的集成测试迈进是我们测试人员努力发展的一个方向。
结束语：软件质量的提高是一个综合的因素，需要从各个方面进行改进，同时还要兼顾成本和进度，只有对流程不断的更新和改进，才能更好的提高效率，组织的支持是保证流程有效推广的坚强后盾，加上技术的不断深入，必将质量稳步提升，流程、技术、组织是影响软件质量的铁三角。
| 
