软件测试中如何保证软件质量

由此看来每一个阶段的质量都起着决定性的作用。 以上提及的四个阶段的质量将引出以下几个软件质量保证的关键要素。 完备的需求分析 需求分析的目的是让项目组明白要做什么，是决定所开发出来的软件应当是“长什么样的”，显然完备的需求分析是高质量软件的前提。如果所开发出来的软件与用户所希望的并不一致，那不可能让用户说“这个软件的质量很好” 。如果方向不对，软件开发得再“好”也没有意义。需求分析失误所带来的开发成本是高昂的，这一点在《软件工程》这类书籍中都会提及，因此，整个行业对于需求分析的重要性都具有足够的认识。当然，知道其重要性与如何获得完备的需求分析又是两回事，至于如何做好需求分析请读者参考相关书籍。 需求分析如果出现失误的话有一个特点—— 它一定会暴露！只不过存在是暴露在软件开发过程中还是在用户手中之别。因此，需求分析所造成的问题尽管严重，但它能被发现进而能得到项目组的重视，从而也一定能被修复，只是不同阶段发现这类问题所花费的成本将有所不同。 设计 设计阶段是通过设计方法找出软件实现更好的方法，注意这里是“更好”两个字，而不是强调最好。 不良设计并不会象需求分析失误那样很容易暴露出其本质，相反，它所暴露出的更多是表象，比如逻辑复杂、维护时举步为艰等等。如果参与者不具备一定的洞察力以发现隐藏在现象背后的不良设计本质，则很有可能身受其害却不能自拔，还以为“本来就有那么复杂”。 项目的开发是一个逐步演进的过程，项目组成员对于需求的理解也是逐步加深的，一开始合适的设计到后面看来很有可能就不够全面或显得力不从心，如果仍沿用以前的设计则自然将暴露出它的不足，进而会出现需要更高的维护成本。重构思想的提出，就是用于帮助项目演进设计的，当然，在运用重构方法时，应尽可能保证项目有足够的单元测试用例，以预防重构时又引入新的缺陷。重构不只是一个词，其核心应当是一个方法论，一个用于优化设计的方法论。 编程好习惯 设计阶段输出的结果就是蓝图，但好的蓝图并不能保证最后的质量一定就好。拿造房子打个比方，图纸设计得再好，如果建造时用的材料不过关，那最终的房子一定好不了。那软件开发中的“建筑材料”又是什么呢？就是程序员所编写的代码。如何保证其质量呢？这需要通过良好的编程习惯去保证。 在现实的项目中，设计有可能与编码会有一定的揉合，即通过进行一定的编码来辅助设计。这种实践方式并不影响这里将设计与编码分为两个质量保证关键要素。 验证 验证很容易让人想到质量保证的常用方法之一，即测试。但验证应当包含更多的内涵，比如求证软件需求是用户所希望的就是其中的一种。 对于验证的理解仍需要拿房屋的建造作为一个比方，以便加深理解。在房屋的建造过程中，当建筑材料到了工地以后，需要对其进行检验，以保证它的质量是合格的，否则不能用于建造。对应于软件开发，这个阶段就是单元测试。当软件工程师编写了代码以后如何保证代码的行为是其所希望的呢？那只能通过单元测试去验证。房子建造好了以后，还得对房子进行整体的验收以确保其最终是合格的。比如抽查墙壁所使用的水泥与沙的配比是合适的。虽然水泥和沙在进入工地时都经过了质检且是合格的，但在建造的过程中需要按一定的比例混合它们以作建筑粘合剂，而混合比例将确定粘合强度。在软件开发过程中，软件集成测试就如同房子在建造好了以后的验收。 从上面的比方能得出几个结论。第一，在软件开发过程中单元测试是必不可少的。它的缺少如同将没有检验过的建筑材料用于建造一样。第二，单元测试应当在集成测试之前完成。有的项目在一开始时并没有单元测试流程，但后来发现需要增加这个环节，于是出现了集成测试完成了以后，再进行单元测试这种情形。这种情形还是有点怪怪的，这如同房子已造好了，再将墙打掉去检查里面的砖是否是好的一样。“将墙打掉检查砖”这种行为的勇气虽然可佳，但是如果尽早地在项目中部署单元测试就能避免这种怪现象的发生。 集成（包括开发集成和系统集成）测试在软件行业被广泛采用以保证软件质量，但单元测试对于软件质量保证的重要性在整个行业还缺乏广泛的、深刻的认识，其更多地被当作是负担而不是一种有效的质量保证手段。

首先你这句话就是错的！软件测试不可能保证0缺陷，应该说尽可能找到更多的bug，或者说尽可能的避免bug。
然后回答你的问题：更好的保证软件质量有以下方面：
1、你对需求的了解程度。只有深刻的了解需求，或者更深入的挖掘客户意念上的需求，才能保证业务的更加完整性，保证软件的完整性。
2、测试用例的质量和执行覆盖率。充分了解需求后，会根据需求划分测试功能点，编写测试用例！在保证测试用例的质量前提下，测试用例的覆盖率很正则表现该软件质量。
3、bug的修复速度，如果bug的修复速度相对较快，说明软件的各个模块，各个API解耦性好！易于维护。也是软件质量的衡量标准 ！
……
当然这是从测试角度说的主要表现，还有很多其他因素影响着一个软件的质量！

1 语句覆盖指的是：代码中的所有语句都至少执行一遍，用于检测测试用例是否有遗漏。

首先画出程序流程图

为了是每个语句都执行一次，程序的执行路径应该是两条：abcefij ，abdfgij;

设计的测试用例只要覆盖这两条路径，就能将所有语句执行一遍；

a=1  b=-1  c=1

a=-1  b=1  c=1

2 条件判定覆盖指的是：设计足够的测试用例，是的判定中的每个条件的所有可能的取值至少出现一次，并且每个判定取到的各种可能的结果也至少出现一次。

由于条件判定覆盖是条件覆盖和判定覆盖的组合，所以只要取条件覆盖和判定覆盖测试用例的并集就可以。

条件覆盖：每个判断的条件的每一种可能至少执行一次。

对于判断语句 a>0 || b<0 :

条件 a>0 : 取真 T1 ，取假 -T1

条件 b<0: 取真 T2 ，取假 -T2

对于判断语句 c>0 :

条件 c>0: 取真 T3 ，取假 -T3

设计测试用例如表1所示：

判定覆盖的死性是使每个判断的真分支和假分支至少执行一次。

对于判断语句 a>0 || b<0 :  取真 M ，取假 -M

对于判断语句 c>0 : 取真 N ，取假 -N

设计测试用例如表2所示：

2 风险评估:这个能力非常重要，项目的每个阶段都可能存在风险:需求不明确、系统设计或测试设计不完善、代码编写不安全、测试用例不充足、测试人员未完全测试、测试资源不足、回归工作量估计不当、项目进度安排不妥、其他项目对本项目的影响等等，所以项目过程中要具有高度警惕性，尤其要做到开发和测试善始善终。 3 缺陷预防:个人认为做到很好的缺陷预防是需要综合素质的，如熟练的业务能力，最好能够熟知各产品间的关联，如果能够知道产品实现方法及过程最好不过。能够及时根据当前其他产品发布出现的问题预测对本项目的影响度并做好相关缺陷分析。 4 沟通能力:往往测试和开发容易处于对立面，不和谐的团队对项目的质量必然带来一定的负面影响，毕竟人的情绪在工作中对工作效率的影响力是非常大的，软件质量是靠开发测试一起保证的，记得在测试技术交流大会中郭芙老大说过开发人员的测试意识不是天生具有的，当遇到开发人员测试观念不足时需要测试人员去指导开发人员，提高开发人员的测试意识。不能把开发人员测试意识不足当作产品质量不好的理由，所以在这个过程中沟通能力是一个很好的体现。 5 时间管理:会管理时间的人往往离成功更近一步，如何利用时间解决紧急的项目问题、冲突问题、资源安排问题、测试用例的执行的先后顺序等讲究时间效率方法是保证质量的因素之一。

我的总结如下：1。用例的覆盖率很重要，特别是对主要功能点的覆盖2。用例设计的内容及步骤的详细度高，可执行性强，好的用例，是任何一个测试员都可执行测试，而无须再细看需求文档3。用例的测试结果，所测试发现的BUG数量和质量，特别是质量很重要，因为BUG的数多，可能是开发人员的问题，而能测试出很难发现的BUG就是测试用例设计的水平了4。用例能及早发现BUG，而不是很晚发现BUG5。能全面提供很连贯测试数据，就按其测试用例的顺序，及每个用例的数据可用于下一用例6。测试用例很准确描述测试期望结果；7。测试用例的归类，将测试用例分成业务类，UI类，数据逻辑类等，不同行业分类不一致，这样测试人员对其测试目的很清晰

软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：
⒈一种质量管理方法
⒉有效的软件工程技术（方法和工具）
⒊在整个软件过程中采用的正式技术评审
⒋一种多层次的测试策略
⒌对软件文档及其修改的控制
⒍保证软件遵从软件开发标准
⒎度量和报告机制
SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组。
软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。
SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SQA小组完成：
⑴为项目准备SQA计划。该计划在制定项目规定项目计划时确定，由所有感兴趣的相关部门评审。
·需要进行的审计和评审；
·项目可采用的标准；
·错误报告和跟踪的规程；
·由SQA小组产生的文档；
·向软件项目组提供的反馈数量。
⑵参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策，内部软件标准，外界标准以及项目计划的其他部分相符。
⑶评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。
⑷审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。
⑸确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。
⑹记录所有不符合的部分并报告给高级领导者。

---