1 测试覆盖率
计算公式：已设计测试用例的需求数/需求总数。
测试覆盖率从纬度上说包括广度覆盖和深度覆盖；从内容上说包括用户场景覆盖、功能覆盖、功能组合覆盖、系统场景覆盖。
首先说广度，是否需求规格说明书中的每个需求项都在测试用例中得到设计。其次说深度，通俗的说，是不使我们的测试设计流于表面，是否能够透过客户需求文档，挖掘出可能存在问题的地方。例如：重复点击某个按钮10次，或者依次执行新增、删除、新增同一数据的记录、再次删除该记录操作。在笔者的实际工作中碰到过这么一个例子，一个使用PL/SQL编写的系统，在某个查询界面，重复点击《查询》按钮6次后，系统就会出现查询功能失效的问题。经调试，开发人员发现是由于gdi资源未完全释放的缘故。
在设计测试用例时，我们很少单独设计广度或深度方面的测试用例，而一般是结合在一起设计。为了从广度和深度上覆盖测试用例，我们需要考虑设计各种测试用例，如：用户场景（识别最常用的20%的操作）、功能点、功能组合、系统场景、性能、语句、分支等。在执行时，需要根据测试时间的充裕程度按照一定的顺序执行。通常是先执行用户场景的测试用例，然后再执行具体功能点、功能组合的测试。
测试覆盖率数据的收集，我们可以通过需求跟踪矩阵RTM来实现。在需求跟踪矩阵，测试人员填写的“系统测试用例”列的数据，如图一所示。测试人员通过计算RTM列出的需求数量，和已设计测试用例的需求数量，可以快速的计算出测试覆盖率。通过RTM，测试人员，包括项目组成员都可以很清楚的、快速的知道当前这个项目测试的测试覆盖情况。
图一 需求跟踪矩阵例子
注：本RTM例子中，笔者将“概要设计”、“详细设计”、“编码”等列隐藏，只显示与测试覆盖率计算有关的内容。
2测试执行率
执行率，顾名思义，就是指实际执行过程中确定已经执行的测试用例比率。
计算公式：已执行的测试用例数/设计的总测试用例数。
读者肯定觉得很奇怪了，我们设计的测试用例肯定都是要执行的，即使是按模块来执行测试，那该模块的测试执行率肯定是100%，为什么还要设置这个指标？
其实不然。在实际测试过程中，经常有如下这种情况发生。一种情况是，因为系统采用迭代方式开发，每次Build时都有不同的重点，包含不同的内容；第二种情况是，由于测试资源的有限，不可能每次将所有设计的测试内容都全部测试完毕。由于这两种情况的存在，所以在每次执行测试时，我们会按照不同的测试重点和测试内容来安排测试活动，所以就存在了“测试执行率”这个指标。
通常，我们的测试目标是确保100%的测试用例都得到执行，即执行率为100%。但是，如前面所提到的，实际中可能存在非100%的执行率。如果不能达到100%的测试执行率，那么我们需要根据不同的情况制定不同的测试执行率标准——主要考虑风险、重要性、可接受的测试执行率。在考虑可接受的测试执行率时，就涉及到了测试用例执行顺序的问题。
在设计测试用例时，我们需要从广度和深度上尽可能的覆盖需求，所以我们就需要设计各种测试用例，如正常的测试用例、异常的测试用例、界面的测试用例等。但是在执行时，测试人员需要根据项目进度和测试时间的充裕程度，参考测试执行率标准，将测试用例按照一定的顺序执行。通常是先执行用户场景对应的测试用例，然后再执行具体功能点、功能组合的测试，完成这些测试后，再进行其它测试，如系统场景、性能、语句等测试。
例如，某项目共设计了280个测试用例。该项目某一阶段的测试共分四个版本，其中有一个版本执行了134个测试用例，那么该版本的测试执行率为47.9%。
3测试执行通过率
文章来源于领测软件测试网 https://www.ltesting.net/
