M 需求说明差 (poor requirements) ── 需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
M 不切实际的时间表 (unrealistic schedule) ── 如果在很短的时间里要求做许多事，出现错误是不可避免的。
M 测试不充分 (inadequate testing)── 只能根据客户意见或者系统崩溃来判断系统质量的高低。
M 不断增加功能 (featuritis) ── 在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
M 交流问题 (miscommunication) ── 如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
(需求说明差 不切实际的时间表 测试不充分 不断增加功能 交流问题)
针对软件开发过程中的问题，有5个解决办法：
ü 可靠的需求 (solid requirements) —— 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
ü 合理的时间表 (realistic schedules) —— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
ü 适当的测试 (adequate testing) —— 尽早开始测试；每次改错或变更之后，都应重新测试。项目计划中要为测试和改错留出足够的时间。
ü 尽可能坚持最初的需求 (stick to initial requirements as much as possible) —— 一旦开发工作开始，要准备防止修改需求和新增功能。要说明这样作的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。
ü 沟通 (communication ) —— 在适当时机进行预排和检查；充分利用团组通信工具 —— 电子邮件、群件 (groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档；进行远距离联合作业及协作；尽早使用模型，使得客户的预想是清楚的。
(可靠的需求 合理的时间表 适当的测试 尽可能的坚持最初的需求 沟通)
软件测试包括哪些内容?
以下是一些需要考虑的步骤：
ü 得到需求、功能设计、内部设计说书和其他必要的文档
ü 得到预算和进度要求
ü 确定与项目有关的人员和他们的责任、对报告的要求、所需的标准和过程 (例如发行过程、变更过程、等等)
ü 确定应用软件的高风险范围，建立优先级、确定测试所涉及的范围和限制
ü 确定测试的步骤和方法 ── 部件、集成、功能、系统、负载、可用性等各种测试
ü 确定对测试环境的要求 (硬件、软件、通信等)
ü 确定所需的测试用具 (testware)，包括记录/回放工具、覆盖分析、测试跟踪、问题/错误跟踪、等等
ü 确定对测试的输入数据的要求
ü 分配任务和任务负责人，以及所需的劳动力
ü 设立大致的时间表、期限、和里程碑
ü 确定输入环境的类别、边界值分析、错误类别
ü 准备测试计划文件和对计划进行必要的回顾
ü 准备白盒测试案例
ü 对测试案例进行必要的回顾/调查/计划
ü 准备测试环境和测试用具，得到必需的用户手册/参考文件/结构指南/安装指南，建立测试跟踪过程，建立日志和档案、建立或得到测试输入数据
长见识了,看来俺要学的还有很多......