5.3.1 测试系统接受条件
本节的目的说明在测试过程中测试部门在接受测试系统时应执行什么检查。
提示和技巧：
谁负责建立测试系统，如何保持测试系统和开发系统之间的同步。
在开发人员提交新程序时，如何检查代码的质量。
开发部门是否需要运行简单的用例，验证系统是否正常，如果验证失败，需要采取什么行动。
需要做什么测试验证测试系统是稳定的。
同步的间隔时间。
当项目进展到不同阶段时，是否需要更新这些规则。
5.3.2 测试时间表
在系统的不同阶段，需要计划在什么时候应得到什么样的测试系统。
提示和技巧：
测试系统多长时间更新一次（每日，每周一次或多次，在什么时间，准备好代码）？
当项目进展到不同阶段时，是否需要更新这些规则。
5.4 稳定阶段测试
5.4.1 稳定阶段摘要
在代码完成到系统最后发行之前为系统稳定阶段。在系统稳定阶段需要对系统的各个部分进行最后的检查。可以建立一个检查重点列表，逐项进行检查。
5.4.2 测试遍数
在稳定化测试阶段至少要运行一遍完整的测试和一个简短的测试。前者用于发现错误，后者用于验证发行版本。
5.4.3 项目结束
在系统投入使用的时候，最后应作的测试安排。
5.5 自动测试策略
在测试过程中，可以适当考虑使用自动测试策略。自动测试不是保证产品质量的万能药，不能保证发现软件的缺陷。自动测试有它的长处和短处，要充分考虑系统特性、时间安排、测试人员的编程经验和可以使用的自动化工具。
使用自动化技术主要目的是发现系统缺陷，提高测试用例的运行效率和对系统进行快速检测。测试自动化跟系统本身的特性相关，如果系统主要是数值运算，可以对结果进行简单判断，使用自动化技术的效率就高，否则系统主要是跟内容相关，自动化测试的效率就比较低。
提示和技巧：
自动化的目标是什么。
你如何衡量这些目标。
在测试中，是否实行代码覆盖，分支覆盖和功能覆盖。
哪些部分可以自动化？自动化程度有多高。
使用什么自动化工具？是否开发新的自动化工具？
5.6 集成测试策略
集成测试有两个范围。一个是系统内部各个功能模块的交互作用，各种可能的组合是非常多的，表现为系统有丰富多彩的表现。另外一种集成是测试系统与相关系统的集成。
提示和技巧：
用户帮助内容在何时如何与系统功能交互作用？怎样测试？
典型的用户情景是什么？
有哪些可能的逻辑组合？
类似功能的逻辑是否一致？
是否有相同的界面？
菜单命令是否一致？
5.7 内容测试
对于系统来说，总有些内容部分需要测试，例如帮助等。对于网站来说，文字说明也是相当重要的。内容测试的第一步就是将内容部分标识出来，再确定谁来实施测试。
提示和技巧
如果内容只是一些帮助文件，用户教育部门会编写和验证这些内容。如果系统是以内容为主的，拥有上百万的文字、千个链接以及不计其数的图片，在这种情况下需要使用由编辑、校对和测试人员组成的小组来负责内容测试。
与内容提供者确定“什么是内容的缺陷”。避免出现模糊的问题，比如“读起来有点问题”或者“太文绉绉”。
哪些内容需要测试。
如何将内容测试与其他工作分开。
是否使用自动测试（比如超链接测试）。
如果使用自动测试，区分那些内容无法使用自动测试，哪些部分可以保证能自动测试。
5.8 性能测试和压力测试
在性能测试中，执行不同的测试，并进行记时，然后将这些数据与以前的数据进行对比。现在的系统多是 C/S 架构或 B/S 架构，需要测试系统对多个用户的并发响应能力，一般情况下可以使用软件在一台机器上模拟几千个客户端进行压力测试来衡量这些指标。
提示和要点：
系统和竞争对手的系统相比有多快。这可能是一个质量指标，比如“比竞争对手 X 快”。
与以前的系统进行相比。比如“在增添新功能后是否跟以前一样快甚至更快些。”
如果没有可比性，可以使用合理速度来进行衡量，但这种数据必须经确认。
需要衡量哪些性能，可以在测试计划中，指定重点领域，在实际测试过程中，在进行具体确定。
是否有行业标准可在测试中使用。
在什么时候执行性能测试？如果需要进行代码优化，需要尽早进行性能测试，这样代码修改带来的负面影响比较小。
性能测试是否跟硬件平台相关。需要确定在何种硬件平台下进行性能测试。
在性能测试中，有几个指标需要注意，如 CPU 使用率内存使用率以及磁盘吞吐率等，这样能确定系统的瓶颈在哪。是否能进行优化。
5.9 兼容性测试
对于 C/S 架构的系统来说，需要考虑客户端支持的系统平台。对于 B/S 架构的系统来说需要考虑用户端浏览器的版本。
提示和技巧：
确定主流的客户端浏览器版本。
决定支持哪些版本的浏览器。
在什么平台上做开发和测试，在那些平台上进行兼容性测试。
6. 测试组织
6.1 测试团队结构
这一节说明测试团队的结构和项目测试人员的数量。
提示和技巧
查看开发计划确定那些功能需要最多资源。
确定需要多少测试人员。
多少人做自动测试，是哪些人。
6.2 功能划分
这一节说明系统可以分成那些模块，分别由谁负责。
提示和技巧：
系统的那些常用功能需要测试。
是不是需要测试系统的所有功能。
是不是需要与开发部门在功能方面对应一致。
7. 资源需求
7.1 培训需求
本节说明项目测试人员需要哪些培训。
提示和技巧：
对于新手需要先介绍测试系统，如果测试人员比较熟悉该系统，则需要说明新系统的功能。
是否进行自动测试。
测试人员要不要培训以编写自动化脚本。
7.2 硬件需求
本节说明测试人员需要的各种类型的硬件以及这个测试团队需要的硬件。
7.3 软件需求
本节说明测试人员需要使用的软件。
7.4 办公空间需求
本节说明需要多少办公空间。
8. 时间进度安排
包括主要时间点的安排
日期
代码完成时间
第一遍测试
第X遍测试
系统发行时间
9. 缺陷处理
测试过程中可衡量的是发现的缺陷的状况。因此缺陷的报告和管理必须写成书面文档。
9.1 数据库管理
提示和技巧：
谁负责创建数据库？
谁有权限增加数据库的帐号？
谁有权使用哪类帐号？
数据库使用过程中出了问题和谁联系？
谁负责数据库备份？
多长时间备份一次？
由谁使用数据库？
缺陷管理应该与开发部门的负责人一起讨论。
9.2 缺陷处理过程
提示和技巧：
解释缺陷报告和分配过程。
缺陷标题、测试环境应如何填写
解释如何输入，解决，重新打开，关闭和重新即或一个缺陷。
让测试人员清楚一个缺陷从击活到解决的全过程。
缺陷必须指定由谁负责解决。
定义优先级、严重级别等。
在项目结束时，如何解决这些缺陷。
10. 测试过程控制
在测试过程中，通过对缺陷数据库进行分析可以确定测试的状态。另外，通过让测试人员填写测试工作周报，可以对项目进展状况进行反馈。
10.1 缺陷数据分析
提示和技巧：
在开发过程和稳定阶段是否有过多的未处理缺陷，这可能说明开发的资源不够，或者有其它问题。
如何确定项目中是否有过多的缺陷。
测试人员是否积极发现缺陷，或者过分积极。
在每个时间点上，系统是否稳定。
系统哪些部分的缺陷最集中。
在系统发行时修复了多少缺陷。
哪些类型的缺陷最普遍。
10.2 测试工作周报
提示和技巧：
周报中应包括哪些信息。
如何填写工作周报。
谁负责查看工作周报。
11. 风险分析
在系统开发和测试过程中，会有各种可能导致系统发布延迟，在计划中需要预先估计这些风险，并且提出相应的对付办法。
12. 系统发布
确定系统在什么情况下可以发布，由谁决定。
_软件测试面试必备