圆满完成2天的“问题驱动的软件测试设计”上海公开课的培训行程，为来自联想、用友软件、易车网、北京康斯特等公司的学员，实践了“问题驱动的软件测试设计”如何从测试设计面临的主要挑战入手，分别从质量属性、领域知识、测试输入、风险4个维度提出了解决的测试思维，为学员建立了具有实践参考意义的测试分析与设计的架构和指南。
在本次课堂中，大家提出非常多的测试问题，大家讨论的也意犹未尽，特别是多名学员下课之后，留下来与我讨论了2个小时的话题。分享在课堂中讨论的2个问题，引导学员得出的建议：
问题1：从哪些维度可以更好的监控测试执行的进度？
测试执行进度的监控，是为测试目标服务的，例如：评估是否可以及时发布？评估当前的软件产品质量等。主要可以从下面5个维度进行评估：
1.风险：假如测试过程中采用基于风险的测试策略，那么可以跟踪和评估风险减轻的趋势图。测试过程中识别的风险，会和设计的测试用例进行关联，通过测试用例执行的发现的缺陷和通过率，可以评估风险的减轻情况。另外，评估剩余风险，可以更好的评判假如发布软件产品，可能的风险有多大。
2.缺陷：缺陷是测试执行进度监控的非常重要的一个维度。例如：发现和修复缺陷的趋势图、没有修复缺陷的数目和在不同严重程度的分布、不同严重程度的缺陷在不同权重下计算的得到的缺陷因子等；
3.覆盖率：主要指的是需求的覆盖率是否达到了100%，或者不同测试类型的覆盖率是否达到了100%，并且测试用例在不同测试类型中分布是否合理等；
4.通过率：主要指的是测试用例的通过率，通常该维度指标会作为测试出口准则的一个条件之一，例如：要求选择的所有测试用例，其执行的测试用例通过率必须达到95%以上。
5.信心：信心主要来自两个层面，一方面可以参考前面4个维度的客观的度量指标进行评估，而另一方面，可以来自负责该功能测试的测试人员的主观判断。
问题2：本来测试时间就少，再这么详细的设计测试，时间怎么够？
大家都深有感触，本来测试人员的测试范围和组合就是几乎无穷的，而给测试团队的时间和资源却是非常有限的。在这两者及其矛盾的情况下，我们怎么能够再这样详细的得到测试点呢？这里的详细指的是从各个维度得到需要测试的点，而并不是说测试用例很详细。
很有挑战的一个问题。我们至少可以从下面的几个方面进行考虑：
首先，测试人员是否应该尽可能多的识别需要测试的点？这个问题的回答应该是肯定的。这个问题的本质应该是测试人员如何在有限的时间内识别尽量多的测试点，因此提升测试团队的测试分析和设计能力是关键，这也是“问题驱动的软件测试设计”公开课希望能够帮助测试人员提升培养发散性测试思维的初衷。假如测试人员提升了这方面的能力，自然而然的会发现在有限的时间内，我们可以识别的更多；
其次，覆盖率的问题。我们识别的测试点越多，相对的测试覆盖率可以更好。现在我们的状况是依赖于给定的测试时间，确定我们能做多少，有多少时间我们设计和执行多少。通过“问题驱动的软件测试设计”构建测试分析与设计架构和指南，希望达到的是尽量多的识别测试点。假如时间有限，可以通过基于风险的测试策略选出测试的重点。这比前面的策略可以更好的发现重要的缺陷，以及确保重要功能的信心；
第三，随着测试工作年限的增加，不断提升测试人员的能力是非常重要的，我们不能只是在10年的测试工作不断的重复做同一个事情，而是确确实实的积累了10年的工作经验。测试过程中的一个非常重要的输出：一个更加优秀的测试人员，而不断提升测试分析和设计发散性思维能力，就是其中的一个。
在本次课堂中，大家提出非常多的测试问题，大家讨论的也意犹未尽，特别是多名学员下课之后，留下来与我讨论了2个小时的话题。分享在课堂中讨论的2个问题，引导学员得出的建议：
问题1：从哪些维度可以更好的监控测试执行的进度？
测试执行进度的监控，是为测试目标服务的，例如：评估是否可以及时发布？评估当前的软件产品质量等。主要可以从下面5个维度进行评估：
1.风险：假如测试过程中采用基于风险的测试策略，那么可以跟踪和评估风险减轻的趋势图。测试过程中识别的风险，会和设计的测试用例进行关联，通过测试用例执行的发现的缺陷和通过率，可以评估风险的减轻情况。另外，评估剩余风险，可以更好的评判假如发布软件产品，可能的风险有多大。
2.缺陷：缺陷是测试执行进度监控的非常重要的一个维度。例如：发现和修复缺陷的趋势图、没有修复缺陷的数目和在不同严重程度的分布、不同严重程度的缺陷在不同权重下计算的得到的缺陷因子等；
3.覆盖率：主要指的是需求的覆盖率是否达到了100%，或者不同测试类型的覆盖率是否达到了100%，并且测试用例在不同测试类型中分布是否合理等；
4.通过率：主要指的是测试用例的通过率，通常该维度指标会作为测试出口准则的一个条件之一，例如：要求选择的所有测试用例，其执行的测试用例通过率必须达到95%以上。
5.信心：信心主要来自两个层面，一方面可以参考前面4个维度的客观的度量指标进行评估，而另一方面，可以来自负责该功能测试的测试人员的主观判断。
问题2：本来测试时间就少，再这么详细的设计测试，时间怎么够？
大家都深有感触，本来测试人员的测试范围和组合就是几乎无穷的，而给测试团队的时间和资源却是非常有限的。在这两者及其矛盾的情况下，我们怎么能够再这样详细的得到测试点呢？这里的详细指的是从各个维度得到需要测试的点，而并不是说测试用例很详细。
很有挑战的一个问题。我们至少可以从下面的几个方面进行考虑：
首先，测试人员是否应该尽可能多的识别需要测试的点？这个问题的回答应该是肯定的。这个问题的本质应该是测试人员如何在有限的时间内识别尽量多的测试点，因此提升测试团队的测试分析和设计能力是关键，这也是“问题驱动的软件测试设计”公开课希望能够帮助测试人员提升培养发散性测试思维的初衷。假如测试人员提升了这方面的能力，自然而然的会发现在有限的时间内，我们可以识别的更多；
其次，覆盖率的问题。我们识别的测试点越多，相对的测试覆盖率可以更好。现在我们的状况是依赖于给定的测试时间，确定我们能做多少，有多少时间我们设计和执行多少。通过“问题驱动的软件测试设计”构建测试分析与设计架构和指南，希望达到的是尽量多的识别测试点。假如时间有限，可以通过基于风险的测试策略选出测试的重点。这比前面的策略可以更好的发现重要的缺陷，以及确保重要功能的信心；
第三，随着测试工作年限的增加，不断提升测试人员的能力是非常重要的，我们不能只是在10年的测试工作不断的重复做同一个事情，而是确确实实的积累了10年的工作经验。测试过程中的一个非常重要的输出：一个更加优秀的测试人员，而不断提升测试分析和设计发散性思维能力，就是其中的一个。