Assignments of Software Testing course taught by Guoyang Cai, SYSU, 2017.
Assignment 1, 2, 3, 4 and 5
Assignment 1 (软件生命周期)
2017/3/21
正确理解原型方法对软件生命周期不同阶段的支持，分别给出：辅助或代替分析阶段；辅助设计阶段；代替分析与设计阶段；代替分析、设计和实现阶段；代替全部开发阶段所对应的开发活动执行时间顺序。
软件生命周期的6个阶段
- 可行性分析与计划阶段
- 确定软件开发的总体目标，给出功能、性能、可靠性以及接口等方面的要求，进行完成可行性分析
- 估计可利用的资源 (硬件、软件、人力等)、成本、效益、开发进度，进行投资-收益分析，制订开发计划。
- 提交可行性分析报告、开发计划等文档。
- 需求分析阶段
- 对用户提出的要求进行分析，给出详细定义，确定软件系统的各项功能、性能需求和设计约束，确定对文档编制的要求。
- 提交软件需求说明、软件规格说明、数据要求说明等文档和初步的用户手册。
- 设计阶段
- 概要设计：把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应。
- 详细设计：对每个模块所要完成的工作进行具体的描述，提供源程序编写的直接依据。
- 提交结构设计说明、详细设计说明和测试计划初稿等文档。
- 实现阶段
- 完成源程序的编码、编译 (或汇编) 和排错调试，得到没有语法错误的程序清单。程序结构良好、清晰易读，且与设计相一致
- 编写进度日报、周报和月报 (取决于项目的重要性和规模)。
- 提交用户手册、操作手册等面向用户的文档的编写工作，以及测试计划的编制。
- 测试阶段
- 全面测试目标软件系统，并检查审阅已编制的文档，提交测试分析报告。逐项评价所生产的程序、文档以及开发工作本身，提交项目开发总结报告。
- 在整个开发过程中 (即前五个阶段中)，开发集体需要按月编写开发进度月报。
- 运行与维护阶段
- 软件提交给用户后，在运行使用中得到持续维护，根据用户新提出的需求进行必要而且可能的扩充、删改、更新和升级。
- 软件维护包括改正性维护 (发现错误)、适应性维护 (适应运行环境变化)和完善性维护 (增强功能)。
原型方法对软件生命周期不同阶段的支持
原型开发可以应用于软件生存周期的不同阶段,也可以替代生存期的部分或全部阶段,下面两张图（中的箭头）均表示了原型方法对软件生命周期不同阶段的支持。一般而言，虚线表示辅助作用；实线表示代替作用。若原型辅助或代替了软件生命周期的某（些）阶段，则开发过程中不再经过该阶段而是使用原型方法。例如图一中蓝色箭头指示的过程为使用原型代替软件生命周期中分析与设计阶段的示意图。其他过程的分析类似。
下面以第二张图为例，分析原型方法对软件生命周期不同阶段的支持和对应的开发活动执行时间顺序
- 辅助或代替分析阶段： 初步需求 -> 原型使用 -> 需求说明 -> 设计 -> 设计说明 -> 编码 -> 程序系统 -> 编码 -> 软件产品 -> 运行维护
- 辅助设计阶段： 初步需求 -> 分析 -> 需求说明 -> 原型使用 -> 设计说明 -> 编码 -> 程序系统 -> 编码 -> 软件产品 -> 运行维护
- 代替分析与设计阶段： 初步需求 -> 原型使用 -> 设计说明 -> 编码 -> 程序系统 -> 编码 -> 软件产品 -> 运行维护
- 代替分析、设计和实现阶段： 初步需求 -> 原型使用 -> 软件产品 -> 运行维护
- 代替全部开发阶段： 原型使用
在敏捷开发方法的12条原则中挑选1条你感兴趣的原则进行风险评估。
The second principle of the 12 Principles Behind the Agile Manifesto is as follow:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. (即使在开发的后期，需求变更也是允许的)
Project Risk Management Process
Here’s the agile risk management process refered from Susan Parente’s PPT and we focus on Risk Assessment part.
(Also see: Five Simple Steps to Agile Risk Management)
- Identification Discovery of a potential risk
- Assessment Review, analysis, and prioritization
- What is the probability of the risk occurring? (or Likelyhood)
- Qualitatively (e.g., “high probability”)
- Quantitatively (e.g., “1 in 1000 chance”)
- What is the impact if the risk occurs? (or Consequences)
- Use a Risk Assessment Matrix on Probability and Impact to determine the Risk Exposure
- What is the probability of the risk occurring? (or Likelyhood)
- Response Planning To mitigate, avoid, transferor assume assessed risks
- Execution Of response strategies, as determined in response planning
- Planning, Monitoring, Documentation and Communication Foundations of the RMP, essential to all phases; Part of continuous process improvement for the RMP
This process is similar to the process of Spiral Model Boehm(1988).
Risk Assessment on ‘Welcome changing requirements’ Principle
With the Risk Assessment Matrix I came out the following risk assessment result. (Risks refer to Agile Manifesto and 12 Principles behind it: Advantages vs. Disadvantages and
Niwot Ridge Resources: Agile Alliance Principles Examined)
| Level | Risk | Probability | Impact |
|---|---|---|---|
| Extreme | Changing requirements are an indicator of big problems at the strategy level. Changing requirements may be an indication of changing business values, unstable requirements, or a lack of understanding of the desired business outcome. Without stable business success metrics, the creation of software to address unstable requirements is unlikely to be good business strategy at any level above a small group. | Likely | Major |
| High | Scope creep can create the risk of ever-lasting projects. Flexibility to change course as needed and to ensure delivery of the right product leads to potential for scope creep | Moderate | Moderate |
| High | The project is much less predictability, at the start of the project and during, about what the project is actually going to deliver, especially for large ones. | Likely | Minor |
| Moderate | Harder to define a business case for the project, and harder to negotiate fixed price projects. Even though the Agile Manifesto take the value of “Customer Collaboration over Contract Negotiation”, a contract is needed in any case. Without the maturity of a strong and clear vision, and the discipline of fixing time-scales and trading scope, this is potentially very dangerous. | Moderate | Minor |
| Low | Prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders. Typically, each stakeholder gives different priorities to different changes. | Unlikely | Minor |
Assignment 2 (测试要素)
2017/4/12
选择一个测试要素，按照你的理解在生命周期6个阶段中分别对组成该要素的测试事件的目标和内容进行讨论。
参考生命周期软件测试方法，选择测试要素中的正确性进行讨论：
| 阶段 | 测试事件 | 目标 | 内容 |
|---|---|---|---|
| 需求 | 定义功能规格说明 | 保证需求分析的正确性和充分性。具体来说，需求阶段测试的目标是保证需求正确反映出用户的需求，需求已经被定义和文档化，项目的花费和收益成正比，需求的控制被明确，有合理的流程可以遵循，有合理的方法可供选择。 | 提交了已定义的功能说明。 |
| 设计 | 设计符合需求 | 根据需求分析详细定义要交付的产品——硬件和软件的需求、操作手册说明书、数据保留的策略、输入/输出说明、过程说明、控制说明、系统流程图等。而测试的任务是对设计进行评审，分析测试要素，给测试要素打分，当需求分析发生变化，设计文档也要修改，测试要对修改的部分进行检查，以保证设计和需求的一致性。 | 设计阶段包括概要设计和详细设计。在概要设计阶段，测试人员应阐述测试方法和测试评估标准，编写测试计划，组织成立一个独立的测试小组，安排具有里程碑的测试日程；在详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例，一次来检查设计中的缺漏情况、逻辑错误、模块接口不匹配、数据结构不合理、错误I/O假定、用户界面不充分等。从而保证设计符合需求。 |
| 编程 | 程序符合设计 | 首要目标是编码和设计一致（包括编码的正确性、可用性、间接性和耦合性） | 通过测试工具如支持程序走查和检查的代码静态分析工具和支持单元“黑盒”测试和单元“白盒”测试的动态测试工具进行测试，测试程序符合设计。 |
| 测试 | 功能测试 | 运行部分或全部系统，确认用户的需求被满足。 | 这包括可靠性、文件完整性、审计追踪、功能正确性、互连等项测试，检验系统在各种环境和重复的事物条件下能否正确地执行系统的需求，控制计算机文件的完整性，追踪一个原始事物到总的控制，按用户规定的需求测试应用功能，与其他应用系统能否正确地通信。 |
| 安装 | 程序和数据安装正确 | 保证被测试系统没有问题，安装正确 | 对程序安装的正确性和完整性进行核对。如果安装失败，系统有相应的解决方案。 |
| 维护 | 修改需求 | 在软件交付使用后对软件修改需求、进行维护 | 维护人员需要开发一些测试用例，预先发现一些问题；并且要能够根据运行情况的变化和用户的反馈对软件做适当的修正。 |
Assignment 3 (程序控制流图)
2017/5/11
根据下面第一个程序流程图，
1. 画出相应的程序控制流图；
如下图所示，左边为标识了序号的程序流程图，转换成为右边的等价的程序控制流图。
- 程序流程图用来描述程序控制结构。将程序流程图映射到一个相应的程序控制流图。控制流图中的圆称为流图的结点，代表一个或多个语句。流程图一个处理方框序列或一个菱形判决框都可被映射为流图的一个结点(简化起见假设程序流程图的菱形判决框中不包含复合条件)。流图中的箭头称为边或连接，代表控制流向。流图中的一条边必须终止于一个结点。由边和结点限定的封闭范围称为区域。计算区域时应包括外部域。
- 在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。由一些边和结点包围的平面范围称为区域。对区域计数时，图形外的区域也应记为一个区域(无穷域)。
- 如果判断中的条件表达式是由一个或多个逻辑运算符连接(如OR, AND, NAND, NOR) 的复合条件表达式，则需要等价转换成一系列只含有单条件判定的嵌套的条件表达式。
2. 给出控制流图的邻接矩阵；
$\begin{bmatrix}
0 && 1 && 1 && 0 && 0 && 0 && 0 && 0 && 0 \cr
0 && 0 && 1 && 1 && 0 && 0 && 0 && 0 && 0 \cr
0 && 0 && 0 && 1 && 0 && 0 && 0 && 0 && 0 \cr
0 && 0 && 0 && 0 && 1 && 0 && 0 && 0 && 0 \cr
0 && 0 && 0 && 0 && 0 && 1 && 0 && 1 && 0 \cr
0 && 0 && 0 && 0 && 0 && 0 && 1 && 1 && 0 \cr
0 && 0 && 0 && 0 && 0 && 0 && 0 && 1 && 0 \cr
0 && 0 && 0 && 0 && 0 && 0 && 0 && 0 && 1 \cr
0 && 0 && 0 && 0 && 0 && 0 && 0 && 0 && 0
\end{bmatrix}$
3. 计算McCabe环形复杂度；
- V(G) = 5（区域数）
- V(G) = m – n + 2 = 12 – 9 + 2 = 5（m是流图中边的数量，n是流图中结点的数量）
- V(G) = d + 1 = 4 + 1 = 5（d 是流图G 中判定结点（1, 2, 5, 6）的数量）
McCabe 环路复杂度为程序逻辑复杂性提供定量测度。该度量用于计算程序的基本独立路径数目，也即是确保所有语句至少执行一次的起码测试数量。
4. 找出程序的一个独立路径集合。
独立路径：至少沿一条新的边移动的路径
- 路径1: 1-2-4-5-8-9
- 路径2: 1-2-3-4-5-8-9
- 路径3: 1-3-4-5-8-9
- 路径4: 1-2-4-5-6-8-9
- 路径5: 1-2-4-5-6-7-8-9
根据McCabe环路复杂度的计算结果，图中存在5条独立的路径(一条独立路径是指，和其他的独立路径相比，至少引入一个新处理语句或一个新判断的程序通路。V(G)值正好等于该程序的独立路径的条数)。
Assignment 4 (等价类划分法)
2017/5/17
分别构造三角形问题和NextDate问题的强/弱/一般/健壮的等价类测试用例并加以比较讨论
等价类划分法
弱/强、一般/健壮的等价类测试分类
- 弱等价类测试： 针对单缺陷的等价类测试用例设计
- 强等价类测试： 针对多缺陷的等价类测试用例设计
- 一般等价类测试： 只覆盖有效等价类的测试用例设计
- 健壮等价类测试： 同时覆盖有效等价类和无效等价类的测试用例设计
- 弱一般等价类测试用例覆盖： 针对单缺陷，只覆盖有效等价类。要求用例覆盖每一个变量的一种取值即可。
- 弱健壮等价类测试用例覆盖： 针对单缺陷，覆盖有效等价类和无效等价类。要求用例覆盖每一个变量的一种取值即可。
- 强一般等价类测试用例覆盖： 针对多缺陷，只覆盖有效等价类。要求用例覆盖每个变量的每种取值之间的笛卡尔乘积，即所有变量所有取值的所有组合。
- 强健壮等价类测试用例覆盖： 针对多缺陷，覆盖有效等价类和无效等价类。要求用例覆盖每个变量的每种取值之间的笛卡尔乘积，即所有变量所有取值的所有组合。
三角形问题
输入三个正整数作为三角形的三条边，判断三角形是等边三角形、等腰三角形还是其它三角形。
三角形的三个边长A、B和C满足A>0、B>0、C>0、A+B>C、A+C>B、B+C>A，等边三角形满足A=B=C，等腰三角形满足三个边长中的其中两边相等且不等于第三遍，既不是等边三角形又不是等腰三角形的三角形为一般三角形。
使用输出确定等价类
R1={等边三角形}
R2={等腰三角形}
R3={不等边三角形}
R4={不构成三角形}
由于变量A、B、C没有有效区间，则强一般等价类测试用例与弱一般等价类测试用例相同。
- 弱/强一般等价类测试用例覆盖：
| 测试用例 | 输入三边长 | 预期输出 |
|---|---|---|
| WN1/SN1 | 3,3,3 | 等边三角形 |
| WN2/SN2 | 3,3,4 | 等腰三角形 |
| WN3/SN3 | 3,4,5 | 不等边三角形 |
| WN4/SN4 | 3,3,6 | 不构成三角形 |
- 弱健壮等价类测试用例覆盖：
| 测试用例 | 三边长 | 预期输出 |
|---|---|---|
| WR1 | -3,3,3 | A无效，小于有效范围 |
| WR2 | 3,-3,3 | B无效，小于有效范围 |
| WR3 | 3,3,-3 | C无效，小于有效范围 |
| WR4 | 300,3,3 | A无效，大于有效范围 |
| WR5 | 3,300,3 | B无效，大于有效范围 |
| WR6 | 3,3,300 | C无效，大于有效范围 |
- 强健壮等价类测试用例覆盖：
| 测试用例 | 三边长 | 预期输出 |
|---|---|---|
| SR1 | -3,3,3 | A无效，小于有效范围 |
| SR2 | 3,-3,3 | B无效，小于有效范围 |
| SR3 | 3,3,-3 | C无效，小于有效范围 |
| SR4 | -3,-3,3 | A、B无效，小于有效范围 |
| SR5 | -3,3,-3 | A、C无效，小于有效范围 |
| SR6 | 3,-3,-3 | B、C无效，小于有效范围 |
| SR7 | -3,-3,-3 | A、B、C无效，小于有效范围 |
| SR8 | 300,3,3 | A无效，大于有效范围 |
| SR9 | 3,300,3 | B无效，大于有效范围 |
| SR10 | 3,3,300 | C无效，大于有效范围 |
| SR11 | 300,300,3 | A、B无效，大于有效范围 |
| SR12 | 300,3,300 | A、C无效，大于有效范围 |
| SR13 | 3,300,300 | B、C无效，大于有效范围 |
| SR14 | 300,300,300 | A、B、C无效，大于有效范围 |
NextDate问题
NextDate()是三个变量month,day和year的函数，输入1912‐2050期间的某一天的日期，要求输出这一天的下一天的日期。
等价类划分：
D1={日: 1<=日期<=28}
D2={日: 日期=29}
D3={日: 日期=30}
D4={日: 日期=31}
M1={月：有30天的小月}
M2={月：有31天的大月}
M3={月：该月为二月}
Y1={年: 该年为闰年}
Y2={年: 该年为平年}
- 弱一般等价类测试用例覆盖：
| 测试用例 | 输入日期 | 预期输出（下一天日期） |
|---|---|---|
| WN1（平年小月，日期=30） | 2017/4/30 | 2017/5/1 |
| WN2（平年大月，日期=31） | 2017/5/31 | 2017/6/1 |
| WN3（平年二月，1<=日期<=28） | 2017/2/28 | 2017/3/1 |
| WN4（闰年二月，日期=29） | 2016/2/29 | 2016/3/1 |
- 弱健壮等价类测试用例覆盖：
| 测试用例 | 输入日期 | 预期输出（下一天日期） |
|---|---|---|
| WR1 | -2017/4/30 | Y无效，小于有效范围 |
| WR2 | 2017/-4/30 | M无效，小于有效范围 |
| WR3 | 2017/4/-30 | D无效，小于有效范围 |
| WR4 | 2060/4/30 | Y无效，大于有效范围 |
| WR5 | 2017/13/30 | M无效，大于有效范围 |
| WR6 | 2017/4/32 | D无效，大于有效范围 |
- 强一般等价类测试用例覆盖：
数量：4（日期类）*3（月份类）*2（年份类）- 7（无效的组合）=17（个）
| 测试用例 | 输入日期 | 预期输出（下一天日期） |
|---|---|---|
| WN1(Y1 M1 D1) | 2016/4/20 | 2016/4/21 |
| WN2(Y1 M1 D2) | 2016/4/29 | 2016/4/30 |
| WN3(Y1 M1 D3) | 2016/4/30 | 2016/5/1 |
| (Y1 M1 D4) | 无效，排除该组合 | |
| WN4(Y1 M2 D1) | 2016/3/20 | 2016/3/21 |
| WN5(Y1 M2 D2) | 2016/3/29 | 2016/3/30 |
| WN6(Y1 M2 D3) | 2016/3/30 | 2016/3/31 |
| WN7(Y1 M2 D4) | 2016/3/31 | 2016/4/1 |
| WN8(Y1 M3 D1) | 2016/2/20 | 2016/2/21 |
| WN9(Y1 M3 D2) | 2016/2/29 | 2016/3/1 |
| (Y1 M3 D3) | 无效，排除该组合 | |
| (Y1 M3 D4) | 无效，排除该组合 | |
| WN10(Y2 M1 D1) | 2017/4/20 | 2017/4/21 |
| WN11(Y2 M1 D2) | 2017/4/29 | 2017/4/30 |
| WN12(Y2 M1 D3) | 2017/4/30 | 2017/5/1 |
| (Y2 M1 D4) | 无效，排除该组合 | |
| WN13(Y2 M2 D1) | 2017/3/20 | 2017/3/21 |
| WN14(Y2 M2 D2) | 2017/3/29 | 2017/3/30 |
| WN15(Y2 M2 D3) | 2017/3/30 | 2017/3/31 |
| WN16(Y2 M2 D4) | 2017/3/31 | 2017/4/1 |
| WN17(Y2 M3 D1) | 2017/2/20 | 2017/2/21 |
| (Y2 M3 D2) | 无效，排除该组合 | |
| (Y2 M3 D3) | 无效，排除该组合 | |
| (Y2 M3 D4) | 无效，排除该组合 |
- 强健壮等价类测试用例覆盖：
为每个变量加上两个无效类（大于/小于有效范围）
数量：6（日期类）*5（月份类）*4（年份类）=120（个）
覆盖了无效的组合，不用排除。不再列举全部组合。
Reference: 三角形问题的三种测试方式
Assignment 5 (黑盒测试：因果图法)
2017/5/17
设计一个处理单价为5角钱的饮料的自动售货机软件的测试用例。软件规格说明如下：
- 操作者投入5角钱或1元钱的硬币，按下【橙汁】或【啤酒】的按钮，则送出相应的饮料(不考虑饮料不足的情况)。
- 若售货机没有零钱找，则一个显示【零钱找完】的红灯亮。此时操作者投入1元硬币并按下按钮后，不送出饮料，退还1元硬币。
- 若售货机有零钱找，则显示【零钱找完】的红灯灭。此时投入1元硬币并按下按钮后，送出饮料，退还5角硬币
1. 分析需求说明，列出原因和结果清单
原因清单(输入条件)
- C1售货机可找零
- C2投入1元硬币
- C3投入5角硬币
- C4按下【橙汁】橙汁按钮
- C5按下【啤酒】按钮
结果清单(输出结果)
- E21【零钱找完】灯亮
- E22退还1元硬币
- E23退还5角硬币
- E24送出橙汁饮料
- E25送出啤酒饮料
建立中间结点，表示处理中间状态
- T11投入1元硬币且按下饮料按钮
- T12按下【橙汁】或【啤酒】按钮
- T13应当找5角零钱并且售货机有零钱找
- T14钱已付清
2. 画出因果图
- 所有原因结点列在左边
- 所有结果结点列在右边
- 所有中间结点列在中间
- 所有因果关系表示为连接图解
- 加上必要的互斥约束条件E：C2与C3、C4与C5不能同时发生
3. 因果图转换成判定表
按照上面的因果图建立规则库，对输入条件C1‐C5的全部解释计算输出结果，得到判定表
判定表中
- 阴影部分表示违反约束条件的不可能出现的情况，可以删去对应列。
- 第16列与第32列对应的输入条件C2、C3、C4、C5为0（黄色部分），表示操作者没有动作，可以删去对应列。
- 最后根据剩下的16列作为确定测试用例的依据。
4. 判定表的分析（第6列）
- 输入条件的语义陈述： 输入11010，表示C1售货机可找零、C2投入1元硬币、C4按下橙汁按钮。
表示在售货机可找零的情况下投入一元硬币并按下橙汁按钮。 - 输出结果的语义陈述： 输出00110，表示E23退还5角硬币、E24送出橙汁饮料。
表示退还5角硬币并送出橙汁饮料 - 用命题逻辑形式描述实现上述输入、输出过程所应用的判定规则，并写出获得输出结果的推理演算过程： 中间结果是1111，表示T11投入1元硬币且按下饮料按钮、T12按下【橙汁】或【啤酒】按钮、T13应当找5角零钱并且售货机有零钱找、T14钱已付清。
实现上述输入、输出过程的规则描述：
$$
C4 \cup C5 \Rightarrow T12 \\
T12 \cap C2 \Rightarrow T11 \\
T11 \cap C1 \Rightarrow T13 \\
T13 \Rightarrow E23 \\
T13 \cup C3 \Rightarrow T14 \\
T14 \cap C4 \Rightarrow E24
$$
以C1,C2,C4为前提，依次应用上述规则，可以证明逻辑结论E23和E24。如第一个式子为并关系，C4满足即可推出T12；第二个式子为交关系，C2是前提，结合第一个式子推出的T12，可推出T11；以此类推…
4. 判定表的分析（第23列）
- 输入条件的语义陈述： 输入01001，表示C2投入1元硬币、C5按下啤酒按钮。
表示（在售货机不可找零的情况下）投入一元硬币并按下啤酒按钮。 - 输出结果的语义陈述： 输出11000，表示E21售货机“零钱找完”灯亮、E22退换一元硬币。
表示售货机“零钱找完”灯亮并退换一元硬币 - 用命题逻辑形式描述实现上述输入、输出过程所应用的判定规则，并写出获得输出结果的推理演算过程： 中间结果是1100，表示T11投入1元硬币且按下饮料按钮、T12按下【橙汁】或【啤酒】按钮。
实现上述输入、输出过程的规则描述：
$$
C4 \cup C5 \Rightarrow T12 \\
T12 \cap C2 \Rightarrow T11 \\
\neg C1 \Rightarrow E21 \\
T11 \cap \neg C1 \Rightarrow E22
$$
以C2,C5为前提，依次应用上述规则，可以证明逻辑结论E21和E22。如第一个式子为并关系，C5满足即可推出T12；第二个式子为交关系，C2是前提，结合第一个式子推出的T12，可推出T11；以此类推…