IT项目质量管理技巧应用的注意事项

软件测试的工作内容主要有哪些？

测试人员的首要职责在我们平常人看来就是“找Bug”，他们需要使用各种测试技术和工具来测试和发现软件中存在的缺陷，从而让开发者更好的优化产品，让用户更加安全顺畅的使用。具体点包括：

1、根据软件设计需求制定测试计划，测试数据和测试用例。

通过测试计划来确定测试产品所需资源，确定测试策略、测试系统、测试任务，评估和确定测试工作量。测试数据和用例是对产品进行任务描述，通过测试需求分析、业务流程分析、测试用例设计、测试用例评审以及测试用例更新及完善这几个步骤完成测试用例的设计。

2、搭建测试环境、执行测试用例。

测试用例执行的第一步就是要先搭建软件测试环境，要给出软件的安装指导书、运行的软硬件环境、以及相关的配置等等。测试执行中，要全方位观察软件产品的问题，以及确认是否和预期测试用例结果是一致的。

3、提交测试报告。

在测试完成后，测试人员需要根据测试结果对发现的问题和缺陷进行分析，包括缺陷率、缺陷分布、缺陷修复趋势等。给出软件各种质量特性包括有功能性、可靠性、易用性、安全性、时间与资源特性等的具体度量。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

4、跟踪Bug修改情况，不断测试完善产品。

5、产品的其他方面测试。

在单元测试基础上，将测试模块组装成系统，完成对产品的集成测试。以及对整个产品进行系统测试，找出需求规格等问题。可以过程中利用测试工具TestWriter对产品进行功能测试、还有一些性能及其它方面的测试，也可以选择正确的工具进行选择。

当然这还不算最后的完结工作，因为软件测试是贯穿于整个软件生命周期的，所以还需要对线上功能检查、当前版本问题反馈以及改进建议等，这样才算是比较完整的一个最终结束。

如何设计、部署和发布能够生产环境中高可靠运行的软件是每一个开发者、架构师、运维人员都需要思考的事情。接下来的一段时间我将介绍一本书：《Release It！Design and Deploy Production-Ready Software》就是介绍关于如何发布经得起生产环境考验的软件系统。

在这本书中，您将找到如何为复杂的现实世界设计、架构和构建软件(特别是分布式系统)的方法。你将面对一群不合逻辑的用户，他们会做出疯狂的、不可预测的事情。你的软件将在发布的那一刻饱受他们的攻击。它需要经受住不安全的物联网烤面包机所带来的DDoS攻击的巨大压力。您需要仔细研究未能通过测试的软件，并找到确保您的软件能够与现实世界保持和谐的方法。

网站、web服务以及分布式系统架构师、开发者。因为系统必须可用否则公司就会亏损。这些系统可能是通过直接销售产品获得收入的电子商务系统，或者是员工用于工作的企业内部系统。如果有人因为你的软件停止工作而不得不回家，那么这本书就是为你准备的。

本书包含4部分，每一部分都有案例分析。第一部分：稳定性，表明你如何保持你的系统正常运行。尽管通过冗余保证了可靠性，但分布式系统的可用性更像“两个8”，而不是令人垂涎的“五个9”。稳定是任何其他关切的必要先决条件。如果你的系统每天都崩溃，没人会关心其他功能。在这种环境下，短期的补救措施——以及短期的思考——将占主导地位。没有稳定就没有可行的未来，所以第一部分先看看如何建立一个稳定的基础。

稳定之后，下一个要考虑的就是持续 *** 作。第二部分：为生产设计，你将看到运行在生产环境意味着什么。你将处理当今软件所处的生产环境中的复杂情况包括虚拟化、容器化、负载均衡和服务发现等细节。这部分将说明物理数据中心和云环境中的控制、透明度和可用性的良好模式。

第三部分：系统发布，你将考虑软件部署。这个有很多的工具来实现，但这是问题中最简单的部分。在不损害消费者利益的情况下，频繁的修改和发布系统是很困难的。我们将研究部署以及在不停机的情况下进行部署的设计，然后我们将转向跨完全不同的服务的版本控制——这是一个棘手的问题!

第四部分：解决系统问题，作为信息系统的一部分你将检查系统的生命周期。如果10版本是系统的诞生，那么您需要考虑它之后的成长和发展。在这部分，你将看到如何构建可扩展的系统。包括架构的演进，跨系统的“知识”共享。最后，您将学习如何通过新兴的“混沌工程”学科来构建抗脆弱系统，该学科使用随机性和压测来改进系统。

IT项目开发人员普遍认为，要高质量并按时完成项目是难以实现的，项目经理们并非不想要高质量的项目成果，他们只是想在质量的基础之上，能够按时完工和低于或等于预算的情况下，实现这个项目。有些项目管理技巧虽然确实可以成功地在降低成本和开发时间的同时不会对质量造成影响，然而，必需注意的是，过度地利用这些技巧就有造成灾难性后果的潜在可能。

1、时间盒(Time boxing)

在破坏项目质量的事件列表上，时间盒的应用排在第一位，当您告诉某人在任务必须移交之前，他拥有多长时间来完成这项工作，我说“移交”而不是“完成”，因为在极端情况下，这经常意味着代码并不完善，仅仅是抓紧时间去完成这项工作。

在大多数情况下，时间盒是有效的，因为它可以做到四件事：

1 它迫使开发者能够富有创造性地在他们的预算之内发现解决方案。

2 它排除了经常添加在软件中不必要的虚饰，而这些虚饰往往并不能增加软件的价值。

3 它防止开发者过度测试。

4 目的只是要得到这件产品，在完整的质量评价(QA)阶段将会有详细的测试，希望在此阶段中能够发现代码中存在的问题。

当存在未知问题，或技术没有经受检验，或没有正确的方法来检验结果的时候，时间盒就无能为力了;当时间盒很小，而且在分配的时间之内并没有可能的办法来实现目标时，这种方法也是无效的。换句话说，时间盒可以很好地解决一些问题，比如充分理解、谨慎评估和执行类的任务;然而，也确实存在时间盒方法不能很好解决的问题，比如研究和发展，还有解决问题等等。

如果时间盒是正确使用的，那么不应当导致测试到很糟糕的代码，这些糟糕的代码可能会导致数百个小时的诊断和返工。时间盒应当适度使用来确保最低的成本、最快和最高质量的软件。

2、误期

所有人都要有奋斗的目标，里程碑是一种受到尊敬的方法，它用来激发人们向同一个目标前进，这种动力可以在很短的时间内得到重大成果。然而，每个人都必须承认里程碑所界定的时间并不是每次都能实现，这时就必须要做出新的决定。

项目经理们必须要在团队中树立里程碑的目标，以此来激励他们前进，但是，当里程碑确立的日期并不现实，而且队员们一再出错，那就应该重新评估这个计划了。如果因为某种特殊情况可以使这个日期不再重要，那么当这个重要日期真正来临的时候，整个团队就只有很小的动力来实现这个里程碑日期。当整个团队连续错过了10个日期，那么第11个日期还重要么这就像喊着“狼来了”的孩子一样。

如果在设定的时间线之后并没有任何处罚，那么当错过这个时间的时候就应该强制执行或者移动整个时间线。

长远来看，不断创造持续的压力和令人迷惑的环境并不能创造出好的软件，开发人员需要能够专心工作的环境。完成项目的日期和关于里程碑日期是否真实的混乱，经常会导致开发人员在开发过程中跳过关键步骤或者造成难以发现的问题。

3、忽视相关性

在软件开发中，我们有很多技巧可以用来延迟相关性，我们可以停用一些函数、移动相连的基本架构，或者绕开众多的错误处理，在正确使用的情况下，所有这些技巧都可以帮助推进一个项目，然而，当为了完成项目，而这些技巧的成本因素又没有被考虑到整个计划当中时，就埋下了烦恼的种子。

很多时候，在项目中排列软件开发的顺序是非常具有挑战的事情，相关性并不容易被发现，因此也就不可避免地有很多相关性因素没有被安排到计划当中。为这些不可预见的相关性安排日程表可以让人变得疯狂，因此，压制相关性的方法是经常使用的，但是，如果过度使用了这些技巧，这些费用可能经常会占据项目总成本中很重要的一部分，而且直到项目的最后才会被发现。

所以要确信您现在所做的对于管理相关性是必需的，不会添加过多的成本，而且是整个软件开发项目中必不可少的一部分。当项目经理不能在成本与降低相关性的便利中取得平衡，那么他们草率地组装的代码将会展示出质量问题。

4、假装没有错误

在项目管理中，忽视并不是一种幸福。为了成功地完成项目，除了不可阻挡的政治压力，向公司其他的员工介绍项目的风险也是必需的。几乎每个软件开发项目都有延期或超出预算或同时出现这两种情况的风险。

问题在于，当最终某一时间，这些风险真正变为现实的时候将会引起恐慌，每个人都在混乱中将项目其余的部分组装在一起，整个项目的质量将因为最终轻率的装配而遭受损失。

当然，当整个项目还没有落后于计划之前，这一问题还不会充分暴露出来，然而，大多数项目都有办法只让项目的某些部分落后一点点，而几乎每个项目都有过于仓促的风险，这是因为管理层在很长一段时间之内都在项目没有任何问题之后得知项目的真实状态。

以上就是关于IT行业中软件测试是做什么的呢全部的内容，包括:IT行业中软件测试是做什么的呢、Release It：设计并部署适应生产环境的软件、IT项目质量管理技巧应用的注意事项等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！