软件工程第三次作业——关于软件质量保障初探
关于软件质量保障的体会
想法
先说我自己的观点，在书中的
从浪漫的角度看软件开发，人们不禁想象软件团队一开始就理解了用户的需求，完美的分析文档如高屋建瓴般流出，软件工程师在次基础上开发了各种完美的功能，按时交付给用户；用户一用就觉得特别符合自己的需求，皆大欢喜！
其实我跟人还是很希望软件开发就是这样的，但我知道做到这样很难，从一开始，用户可能都无法提供出完整的需要，可能在开发过程中用户突然更改了需要，我们无法对用户期待过高，即使对用户很不满意也不能将这个项目推掉（不过还是可能下次再遇到这个用户，找个理由推掉）。但是如果用户表达的很好，但是负责需求设计的职员可能做的不够好，这很明显是内部员工的问题，关于这个会在后面继续讨论。
然后就到了文档了，如果有了一个很好的文档，对于开发是很有帮助的。不过文档可能无法一次就写出很完备的文档，如果后面发现文档出现了问题，那就需要修改文档，既然你修改了文档，那就需要让参与这个项目的所有职员知晓，包括程序员和后面要说的测试人员或者QA 人员。这就需要各个团队之间需要有沟通，但是这种沟通未必是真的到另一个部门找到专门的负责人，我认为这样效率未必会高，再一个企业中所有的员工应该有一个企业邮箱吧，在不着那就记录下所有人的邮箱，然后群发个邮件通知，至于文档可能放到共享文件夹或者活动域或者某个公司内部的网站。什么？没有看到邮件通知，瞎？像上面的一样，后面还要讨论。
然后就到了编写代码阶段了，一个项目的程序可能分成多个部门完成，每个部门可能需要完成某一个模块，或者一个类库。自然，单元测试需要相应的程序员完成，等到自己的任务完成，就需要交付给其他部门使用了。什么？其他模块没有完成，我认为这种情况发生在最终的产品上，而不会发生再开发过程中，因为对于我这个模块的输入应该是上一个功能的输出吧，这个内容可能再文档中就已经确定好了，或者由上一个模块的程序员很短的的时间就能交付一个预期的输入值吧。
然后就到了重要的阶段，测试，一个工程是否达到了预期，那就需要测试来完成，单元测试已经由程序员完成，然后是自动化测试，压力测试，测试人员还需要完成的一个工作找bug 。
软件工程的质量
然后是书中软件工程的质量。书中14.1.2 节中定义的软件工程的质量体现：
- 软件开发过程的可见性。
- 软件开发过程的风险控制
- 软件内部模块，项目中间阶段的交付质量，项目管理工具的因素
- 软件开发成本的控制
- 内部质量指标的完成情况
软件工程的质量涉及多个方面，像风险控制已经不是一个企业能够完美解决的问题了，它包括很多的无法预计的问题。但是像服务器故障还是能够通过很多安全措施解决的。
为了得到软件质量保证，发现软件工程中的问题，并且解决这些问题，才能够
软件工程的质量的衡量
如果想要达到质量保证，那自然也需要了解了软件工程的质量的衡量。书中提到了CMMI。有很多的大公司特别是国防工程项目，说明CMMI还是有很大的优势的。CMMI 的实施能够提高企业的管理水平，降低企业的成本。在写的企业中可能很大达到CMMI 标准，但是对于大型公司很有必要。在第四级中，
而且要实现数字化的管理
如果什么事情都依靠部门或者人力去完成，那就好像编写代码还在用记事本呢。一个工程的项目越大，管理越难，每一个步骤出现问题都需要去修改，那么由谁去做，做得怎么样，后面又出现了什么问题，这都是需要解决的问题。本来就是一个推一个，再加上时间的问题，人的精力问题，还有人本身就有懒惰的问题，但是如果能够使用管理工具，将各种信息录入到电脑中，由电脑分配任务，每一个部分的项目完成情况，计划等内容，待解决的问题通过电脑屏幕一目了然，也就是信息化。并且通过这种信息化、数字化，甚至能够在项目完成时分析此次出现的问题，简直就是诸葛亮的存在。
软件的质量成本
想要软件的质量，那必然需要成本。SWEEBOK 定义的软件质量成本：
预防
评审
内部故障
外部故障
流程分析改进
提高职业技能
技术投资
上到管理部门，下到每一位执行者，包括程序员，测试人员等等，面对更新的技术，或者本来还有不甚懂得的东西，需要自己学习或者公司培训等方法来使员工获得更多的能力来应对未来的或者当下的问题。比如借助于工具，像 git 工具管理源代码，这样所有人的更改对所有人的都是可见的，如果有bug 或者新功能建议也通过git 来管理，每个人的更改都是有记录的，等到出现问题时也可以责任到人,不会出现出现了问题没有人负责的情况。如果能够善于学习，未来的工作也会更加顺畅。想要质量得到保证，技术投资必不可少。
我认为在这里付出的成本是比不上项目无法完成，无法按时交付软件造成的损失大。在一个关键时期很可能因为这个问题导致公司破产，如果能够做的更好，在未来获得更高的竞争力，到那时获得的收益是远远大于这些付出的。
如果无法担负起这些成本或者不愿意，那很难得到软件质量保障。
我认为的项目的 QA 的工作职责范围
QA 是软件质量保障工作，也就是说负责软件项目的软件质量。万事开头难，如果开头不好，后面的事也很难完成，所以QA 在项目开始时就应该对这个项目有足够的了解，如果根本不了解，当项目出现问题时，那QA 又怎么以一个类似监管者的位置提出项目出现的问题。说到这里，好像QA 的职责跟管理人员好像，但是我还不太了解公司的项目经理或者主管主要负责什么项目，如果他们并不负责这些，那这些就应该由QA 负责。然后就到了项目进行中了，对于程序员开发出来的模块应该由程序员自己负责，然后交到测试人员手里，或者其他程序员手里检验，如果QA 也负责测试，那为何不并入到测试中，所以这部分的工作应该分开。等到项目完成，需要进行完整测试时，需要QA 以一个用户角度去使用完成的项目，这样才能够发现更多的问题。不过这也能够归为测试的事情，只要测试用例更好好像可以替代QA 的工作，但是实际情况中很多的软件使用了自定义框架或者自定义库，使得一般的测试工具无法进行，这是QA 的作用就体现出来了。
QA 和 Test 选择问题
在上面我只说了我认为的QA ，但是实际的QA 的工作是什么样的？
我们需要专职的QA吗？的文章中所说的QA 做的工作完全可以归为测试的工作吧。
- QA 需要制作测试用例
- 需要运行测试用例
- 性能测试
原作者做出了QA 不需要存在的论断。我先不管QA 到底应该怎么样，我只论述在此情况下的问题。
-
测试用例写的差
- 写的冗余
- 测试用例不明确
- 测试用例无法覆盖所有功能
-
连电脑的使用都不会
- 不会做性能测试
- 无法查看电脑的运行状态和资源状态
- 测试不认真
关于测试用例写的差的问题？如果一个测试人员的测试用例写的差，那应该被开除了吧，那自然，如果QA 的测试用例写的差也要开除QA。
如果这个公司的QA 就是要写测试用例，在招员工时就该对此进行筛选了吧！找了一个连工作都做不好的员工有什么意义。这已经不是这个职业或者这个部门需不需要存在，而是要不要开除工作能力差的员工的问题了。
电脑都用不明白？那理由和上面类似。
比如：安装新版本后没有重启服务，没有使用新的配置文件，网络配置，等等，等等。
如果是这样，那在这种状态下交付给用户使用会怎么样？
QA 应该负责的是质量保证，QA 应该无法管理程序员的工作状态，因为作为一个其他部门，无法知晓他们的工作任务（不过可以通过上面说的数字化解决，所以说数字化真的很重要），测试也交给测试人员就好了。我认为的QA 应该负责项目的文档，文档的修改，发现文档的问题和以一个用户的角度去使用软件。
既然QA 的工作确认了（在我认为的QA 的职责下），那就在于是否需要专职的QA ，如果这些工作交给主管或者程序员完成会怎么样？我认为这个问题很难一概回答，不过也有一个角度可以考虑，如果程序员来完成的话呢？那程序员需要花费多少时间做这些工作，是否会影响到工作进度？在这些工作上花费更多的时间的话，那完全可以把它分出去，或者QA 从此归属程序员的子部门。如果花费的时间少，那工作能完成吗？这个问题很难回答。
出现问题由谁来负责？因为最开始单元测试需要通过，那就讨论测试的问题。如果测试人员发现了问题，并提交给了程序员去解决，解决完成，皆大欢喜，按时交付。但是测试人员或者QA 没有发现问题，那就可以归为测试人员或者QA 的问题。如果他们提出异议，比如负责的太多了，我招收员工就是来做这个的，担不起责任那还干什么呢，不愿意干就辞退呗，要不就增加工资呗。但是如果项目都快要到期了，很多功能还没有完成，那就是程序员的问题。