现代软件工程讲义 8 稳定阶段 (测试的计划和执行)

[来自 移山之道 第 13 章]

13.8  测试计划

测试不是在所有的开发工作完成之后才进行,而是与开发几乎同步进行的。一个软件项目的各个功能都可以有自己的测试计划,它们可以在不同的阶段发挥作用。但是针对整个项目的总测试计划(又叫测试总纲)要在计划阶段大致定下来,并指导所有测试工作的进行。

那测试总纲到底讲什么呢?

测试计划描述了一次测试活动的主要方面:为什么(Why),测试什么(What),谁来测试(Who)和什么时候测试(When),详细地说,包括以下方面:

1)测试的总体策略和方法。

2)测试日程安排:何时开始什么样的测试。

3)质量目标:测试要达到什么样的目标才能算通过——这个目标也决定了“验收测试”的标准。

4)资源:需要多少人力、物力来达到质量目标。

5)测试变量矩阵:我们的系统需要支持多少种操作系统、浏览器,以及其他影响功能的变量?

关于这一点,阿亨有一天晚上和大牛在顶球酒吧畅谈理想,讲到激动处,夜不能寐,勾画了这样的测试矩阵(见表13-4)。

阿亨把这个计划拿给大家讨论,大家在惊叹之余,纷纷怀疑我们是否有能力完成这么多种类型的测试。毕竟是184 320种组合!这时候,阿超建议大家看看团队的远景和各种情况所占实际用户的比率,来决定我们真正需要支持的测试矩阵是什么。

经过分析和讨论,大家逐条精简,结果如下:

a. 用户类型不变。

b. 屏幕分辨率降到两种,手机屏幕不要了,我们暂时不在手机上测试。

c. 屏幕DPI不测试高级DPI(屏幕 | 属性 | 高级 | DPI 中可以设置DPI以提高显示效果)。

d. 操作系统只测试3种,二柱强烈支持Linux,同时考虑到一些高收入的网民可能会用Linux操作系统,保留Linux

e. 操作系统的语言只支持3种,这并不是网站内容的语言,而是操作系统的默认语言。

f. 网络速度3种,无线网络的速度介于拨号与ADSL之间,可以忽略。

g. 浏览器的版本,经过激烈的讨论,浏览器从5种变为3种。

总计648种组合,如表13-5所示。

 

 


clip_image001[5]13-4  宏伟的测试矩阵

 

用户

类型

屏幕

分辨率

屏幕DPI

操作系统

操作系统

默认语言

网络速度

浏览器

Flash

JavaScript

Cookie

组合

总数

变量

数目

4

4

2

6

6

4

5

2

2

2

184320

 

商户

800素×600像素

正常

WindowME

中文(简体)

拨号

IE6

支持

支持

支持

 

 

用户

1024素×768像素

高级DPI

WinXP

中文(繁体)

ADSL

IE7[1]

不支持

不支持

不支持

 

 

浏览者

1280素×1024像素

 

WinVista

英语

局域网

Opera

 

 

 

 

 

管理员

手机屏幕

 

Win Server

2003

日语

无线网络

Safari

 

 

 

 

 

 

 

 

Linux/Unix

阿拉伯语

 

Firefox

 

 

 

 

 

 

 

 

Mac

西班牙语

 

 

 

 

 

 

 


13-5  精简后的测试矩阵

 

用户

类型

屏幕

分辨率

操作系统

操作系统

默认语言

网络速度

浏览器

组合

总数

变量数目

4

2

3

3

3

3

648

 

商户

800像素×600像素

WinXP

中文(简体)

拨号

IE6

 

 

用户

1024像素×768像素

WinVista

中文(繁体)

ADSL

IE7

 

 

浏览者

 

Linux/Unix

英语

局域网

Firefox

 

 

管理员

 

 

 

 

 

 

有了这样的测试矩阵,测试人员在设计与执行测试的时候就能够按照矩阵进行全面的测试。同时要指出的是,不同组合的重要性是不一样的,我们最主要的测试环境还是:用户 + 1204素×768像素 + WinXP + 中文 + ADSL + IE6。必须先保证网站在主要的测试环境下能正常运行。



[1] 这个表还没有考虑IE8/9

[来自 移山之道 第 15 章]

15.2  测试的文档

九条:测试工作是不是有很多文档要写?

阿亨:各类人员都有文档要写,但是在敏捷模式中,我们要坚决避免为了写文档而写文档。要写真正有用的、重要的文档,如下所示:

在计划阶段,我们就要制定测试计划(Test Plan),特别是测试总纲。然后还要写测试设计规格说明书TDS)、测试用例(Test Case)、程序错误报告(Bug Report)和测试报告(Test Report)。它们之间的关系如图15-1所示。

 

 
 clip_image001

 

 

 

 

 

 

 

 

15-1  测试工作中的文档

 

测试计划和测试总纲主要说明产品是什么,要做什么样的测试,时间安排如何,谁负责什么方面,各种资源在哪里,等等。这些在第14章已经讲过。

我们不是为了写文档而写文档,写文档的目的是要解决问题。到底这些文档会解决什么问题呢?

 

 

15.3  测试设计说明书(TDS

正如开发人员有功能设计说明书,测试人员也要有设计测试说明书。这就是告诉测试人员要如何设计测试。

阿毛:我们在哪里可以找到模板?有了模板就好办了。

阿亨:我们不要一味地依赖于模板,不要被模板淹没了。

对于一个功能,或者相关联的一组功能,TDS主要要描述这些重要的内容:

1)功能是什么。

2)要测试哪些方面?有没有预期的Bug比较多的地方(对于测试矩阵有没有要修改的地方)?

3)如何去测试(什么具体方法,如何做测试自动化,准备什么样的测试数据等)?

4)功能如何与系统集成,如何测试这一方面?

5)什么才叫测试好了(Exit Criteria)?

阿毛:有些功能还没有写好,我怎么能知道这些功能的具体情况?

阿亨:TDS应该在功能实现之前,就要根据功能的spec写好,并通过同事的复审[1]

 

15.4  测试用例(Test Case

有了TDS,我们就可以按照TDS 的描述,对每一个功能点进行具体的测试了。具体地说,测试用例描述了如何设置测试前的环境,如何操作,预期的结果是什么。一个功能的所有测试用例合称为这个功能的测试用例集(TEST Suite)。

九条:对于一个功能,用户可能的输入千差万别,我是不是得写成千上万个测试用例?

阿亨:没必要,我们可以把纷繁的情况归类到几个类型中。例如,用户登录时的情况,我们可以将其归为以下几类:

1)正确输入(用户输入了合法并正确的用户名和密码),预期结果是用户能够正常登录。

a. 用户名又有多种情况(数字、字母、中文)。

b. 用户登录“记得我的账户和密码(remember me)”功能可以正常使用。

c. 用户的密码是否隐式显示,转送。

2)错误输入,预期结果是系统能给出相应的提示。

a. 用户名不存在;

b. 用户名含有不符合规定的字符(控制字符、脚本语句等);

c. 用户名存在,但密码错误(具体测试时、可以输入空、超长字符串、大小写错误等)。

15.5  错误报告(Bug Report

在测试中,如果发现问题,我们就得报告,在移山过程模型中,“Bug”是第二个工作项类型。在这一阶段,我们就主要用Bug进行交流。

在以前的“二人合作”一章中,有些团队成员已经互相找过Bug,但是当时项目相对简单,对Bug的格式并未做严格要求。在一定规模的软件项目中,我们要求一个好的错误报告要能做到:

1Bug的标题,要简明地说明问题。

2Bug 的内容要写在Description中,包括

a. 测试的环境和准备工作;

b. 测试的步骤,清楚地列出每一步做了什么;

c. 实际发生的结果;

d. (根据spec和用户的期望)应该发生的结果。

3)如果需要其他补充材料,例如相关联的Bug、输出文件、日志文件、调用堆栈的列表、截屏等,都要保存在Bug 相应的附件或链接中。

4)还可以设置Bug 的严重程度Severity)、功能区域等,这些都可在不同的字段中记录。

下面是九条创建的一个Bug

标题:挂了

内容:我今天在玩移山购物网的时候,发现移山网站挂了。

这个Bug的问题在于对问题的描述不明确,让开发人员无从下手。小飞拿到这个Bug,也是哭笑不得,试了试移山的各个页面,好像也都正常。他于是把这个Bug又推给九条,“哪里挂了?”

过了一会儿,九条回复“在我的机器上是挂了”。

小飞跑到九条的座位上,想看看“犯罪现场”。

九条:我刚把机器重启动……

两人等到启动完毕,打开网页,发现一切正常。

九条:(纳闷了)昨天晚上的确是挂了。网页上还有一些错误信息。我当时正在干什么来着,好像是在留言或在论坛上发帖子,我现在也记不清了。让我再玩玩,等碰到了再叫你。

阿亨:这样九条浪费了两个人各一个小时的时间。最后什么进展也没有。一个好的Bug应该是这样的:

 

标题:购物网站的某个具体页面(URL),在回复中如果提交大于100KB的文字的时候出错。

内容有以下几点:

环境:Windows XP下,使用IE7。允许Cookie。购物网的版本是1.2.40

重现步骤:

1)用[用户名,密码] 登录。这一用户在系统中是一般用户。

2)到某一产品页面(链接为:……)。

3)选中一个帖子,例如:帖子号为579

4)回复帖子,在内容中粘贴100KB的文字内容(文本内容见附件)。

结果:

网站出错,错误信息为:[]

预期结果:

网站能完成操作,或者提示用户文本内容过大。

[在附件中加入100KB的文本文件]

测试人员还可以附上其他分析,应该鼓励测试人员追根溯源。

如果看到这样的报告,那么开发人员就能够很快地重现这一问题,从而有效地分析和解决问题。

15.6  测试修复,关闭缺陷报告

当开发人员修复了一个缺陷并签入代码后,一个新的构建就会包含这一个修复(Bug fix)。测试人员所要做的就是验证修复,并且搜寻有无类似的缺陷,验证修复有没有导致其他的问题(回归,regression),了解修复的影响(是对一个简单的显示文字的修改,还是内部算法的改变),并且检查系统的一致性是否受影响(例如:修改了默认的///取消/选择次序,要检查整个产品中其他的对话框是否遵循同一模式)。

在完成了测试之后,测试人员可以关闭缺陷报告,同时在“历史(History)”这一栏内说明是如何做的验证。

当测试人员验证了一个Bug被正确修复了之后,还要考虑是否把这一个Bug变成一个测试用例,这样可以保证以后的测试活动会包括这个Bug描述的情况。这是一个很重要的步骤。

15.7  测试报告(Test Report

在一个阶段的测试结束后,我们要报告各个功能测试的结果,这就是测试报告。移山公司不喜欢过多的文档,我们就不必写洋洋万言的报告了,只需简单地列出一些数字即可,如:

对于某一功能,我们要收集下列数据:

1)多少测试用例通过?

2)多少测试用例失败?

3)多少测试用例未完成?

4)多少在测试用例之外的Bug被发现?

所有功能的测试报告相加,我们就能得到整个项目的统计信息。这样的信息能帮助我们从宏观上了解还有多少事情没办完,各个功能相对的质量如何。

15.8  运用测试工具

前面说了这么多理论和规定,我们看看实际工作如何进行。VSTS既然是一套软件工具,它一定有一些帮助测试人员的工具。Visual Studio 2005/8 的众多套件中,有一款是:Visual Studio Team Edition for Software Tester。我们在这里也简单地介绍基本工具的使用。

15.8.1  运用工具记录手工测试

不管多少人,多少文章描述了“测试自动化”及其前景,这些自动化的东西最初还是得有人“手动”地进行。下面的步骤演示了如何创建手工测试。

1)在VSTS(有Team Edition For Tester 套件)中,新建一个项目,在Visual C# 或其他类型中,选中Test。填入适当的项目名字和解决方案的名字,可以把它加入源码控制中。我们会看到新的项目新建了不少文件(如图15-2所示)。其中有UnitTest1.cs,我们之前已经谈过。另一个文件是ManualTest1.mht

clip_image003

15-2  创建新的测试项目

2)打开ManualTest1.mht,你会看到它是模板(又一个模板),在这个文件中,你可以填入下面的内容:

a. 测试的标题(Test Title)——简明的标题。

b. 测试的详情(Test Details)——测什么。

c. 测试的对象(Test Target)——测试什么功能。

d. 测试的步骤(Test Steps)——提供详细的测试步骤和每一步期望的结果。

e. 修改的记录(Revision History)——对这一测试进行修改的历史记录。

九条:不就是这样一个简单的文件么,我自己不用写也可以记住。

阿亨:好记性不如烂笔头,当测试矩阵有上百个可能的设置,产品又日趋复杂的时候,我们需要把一些手工测试记下来。另外,如果来了个新手接班,项目移交,怎么办?

15.8.2  运用工具记录自动测试

对于网络程序,我们可以把对网页的访问和操作像录音一样录下,“录音”主要是记录HTTP请求的URL,以及headerbody中的各个参数。记录是否成功取决于服务器返回的状态码。当然,我们也可以自己定义pass/fail的条件。这样以后测试的时候重新放录音带即可。

操作:鼠标右键选中测试项目,选择 Add | Web Test(如图15-3所示)。

clip_image005

15-3  新增加一个 Web Test

Internet Explorer 就会打开,同时Web Test Recorder 也会激活[2]

 

测试人员就可以按照场景测试网站的各项功能了,同时注意到Web Test Recorder 会记录每一个网页的地址,以及可能的参数。

测试人员可以进一步增加测试的内容(如图15-4所示)。

clip_image007

15-4  进一步增加Web Test 的功能

其中值得提出来的是,测试人员可以选中Generate Code”,生成测试脚本,可以在脚本一级开发测试。测试人员可以用脚本建立循环测试,或者根据某一步测试的结果选择不同的测试分支(path),更加灵活。另外,我们还可以用C#作为测试代码的语言,这个比其他通用工具的脚本强大许多,这也是用VSTS做测试的好处之一。

不同的测试可以把不同的次序结合起来运行,测试人员可以用“Ordered Test”来管理这样的测试集合。可以用和创建Web Test 类似的方法创建 Ordered Test

15.8.3  如何测试效能

除了功能方面的测试外,我们还要测试那些“服务质量”。如效能测试、负载测试、压力测试。我们在第7章中讲到了这三种测试的区别。在Stone 项目中,以产品搜索为例,这三种测试的区别如下:

效能测试[3]100个用户的情况下,产品搜索必须在3秒钟内返回结果。

 

负载测试:2 000个用户的情况下,产品搜索必须在5秒钟内返回结果。

 

压力测试:在高峰压力(4 000个用户)持续48小时的情况下,产品搜索的返回时间必须保持稳定。系统不至于崩溃。

 

 

我们可以举一个现实生活中旅客列车的例子:

效能测试:80%上座率的情况下,期望:列车按时到达,并且乘客享受到优质服务。乘务员不要太累。

负载测试:100%上座率的情况下,期望:列车大部分按时到达,乘客享受到基本服务。乘务员的疲劳在可恢复范围内。

压力测试:在高峰压力是200%上座率,全国铁路系统增加20%列车,持续15天的情况下,期望:列车能到站,乘客能活着下车,系统不至于崩溃。乘务员也能活着下车。

 

效能、负载、压力这些方面的测试会产生很多数据,这些数据最好保存在数据库中,以便于跟踪分析。这些数据为以后做网站容量规划(Capacity Planning,又称容量规划,能力规划)提供重要的依据。

VSTS中,效能和压力测试都可以用“Load Test”来实现,Load Test 牵涉到许多因素,因此我们需要按部就班地设置,如图15-5所示。

负载测试的一个核心概念是“场景”,这和软件设计的场景有所区别,它主要包含负载测试的各种参数:

1)停顿时间(Think Time):在每次请求之间和一批测试之间的停顿。

clip_image009

15-5  创建负载测试向导

2)负载模型(Load Pattern):模拟的用户量是恒定在一个数值的(如:总是30 个用户),或者是分级进行的(如:开始是5个用户,每分钟增加10个用户,直到最高50个用户)。

3)测试混合模型(Test Mix):此次负载测试要运行多少种测试,每种测试所占的比例是多少。

4)浏览器混合模型(Browser Mix):各种浏览器的选择及比例。

5)网络混合模型(Network Mix):各种带宽的网络及比例。

设置场景后,下一步要决定我们收集什么样的效能数据(Performance Counter),这时候,我们可以收集代理机器(Agent,模拟的服务请求从这里发出)和控制机器(Controller)的效能数据,更重要的是收集网络服务器的效能数据(如图15-6所示)[4]

 

 

clip_image011

 

 

 

 

 

 

 

 

 

 

 

 

 

15-6  收集效能数据

这些效能数据会反映在负载测试中。

最后一步是设置运行负载测试中的各种参数。

15-7是一个网络负载测试运行的结果图。

九条:数据太多了,我看这个表有点头晕,比打麻将要看的数据多多了。

阿亨:的确,网络应用的负载测试是一个复杂的领域,我们要下一番苦功把它掌握。一般把所有数据都保存到数据库中,以便将来做分析。但是我们还是要明确测试的目标:看看网络服务器能否在规定时间内处理用户的请求,服务器上有没有出现错误。这两种数据都能够马上得到。

clip_image013

15-7  负载测试运行结果



[1] TDS应该在设计阶段完成,为了描述的方便,作者把大部分和测试相关的内容放到这一章。

[2]Vista系统中,可能需要以管理员身份运行VSTT

[3] 要注意,有些项目定义这里的“时限”是服务器处理的时间,不包括数据在网络传输的时间,和客户端浏览器(如:IE)显示内容的时间,移山公司使用这样的约定。

[4] Controller Agent 要安装VSTS 的特定组件后才能使用。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/500432.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

现代软件工程讲义 2 开发技术 - 效能分析

[移山之道 第九章] 9.4 VSTS 效能分析工具 啊,效能分析,Performance!这是每一个程序员都梦想的事儿,让自己的程序跑得又快又好,最好是比别的同学快一个数量级,别人的程序是O(N^2),而我的程序是…

现代软件工程讲义 2 开发技术 - 单元测试 amp; 回归测试

[移山之道 第11章] 1单元测试 你的RP是由你的程序质量决定的。 ——阿超 这一章讲的是两人合作,既然程序是两个人写的,那就会出现一个人写的模块被另一个人写的模块调用的情况。很多误解、疏忽都发生在两个模块之间。如何能让自己写的模块尽量无懈可击…

现代软件工程讲义 4 方法论 - MSF

[内容来自 移山之道]白话MSF方法论 2.1 果冻的预习果冻:超总,听说你要讲MSF,我就先预习了一下,但是MSF的名词太多了,我真是头大,能不能解释一下这两句: “MSF的一个基础原理是学习所有的经验。…

现代软件工程讲义 9 测试 关于闰年的测试

我们谈了不少测试的名词, 规范和原则 (link1, link2). 软件是人写的, 测试计划和测试用例也是人写的, 人总会犯错误。错误发生之后, 总有人问: 为什么这个bug 没有测出来啊?! 我们看看一类简单的bug是如何发生的,以及如何预防它们再度发生: 闰年 软件少不了和…

现代软件工程 来自卓越大学教师的建议 (读书笔记)

教师教学有培训和参考书么? 我从来没想到过我会在大学里教书, 而且还教了好几年, 四个学校。 当时接到任务的时候, 我把它当作实习生培训和新员工培训的”学院版”, 还是继续强调实践, 反馈, 合作, 就这么开讲了。 在微软公司, 做大部分和人相关的事情, 都得先有一个培训, …

软件工程讲义 9 创新的出路 走进作坊

我第一次注意到 “作坊”这个词和软件行业联系起来大概是这个 2004 年 11 月的报道: 标题: 信产部副部长娄勤俭:中国软件业还在手工作坊阶段 日前,信息产业部副部长娄勤俭在出席中国软件产业生态链高层论坛时表示,中国软件产业的规模还比较小…

现代软件工程 习而学的软件工程教育

茅于轼先生写了一篇博客 ( http://blog.sina.com.cn/s/blog_49a3971d0102dufj.html ) 纪念茅以升先生提出的 习而学的工程教育: 把颠倒了的工程教育顺序恢复过来,即他称之谓“习而学的工程教育”。 以桥梁建筑专业为例,大学一年级先学施工条例&#xff0…

现代软件工程 教课心得

现实世界是最好的老师, 我们这些叫 “老师” 的人, 充其量是个助教。 但是有些助教却不让学生见到老师。 **************** 老师都想把课教好, 学生都想把课学好. 但是我们常常看到一个学期过后, 老师, 学生都有很多抱怨 (例如: 各种良好愿望和计划在实施中的问题). 看了上…

微软学术搜索项目 10个版本的历程

这是我在微软亚洲研究院参与的项目之一, 从 2009 年秋天开始, 我们小组把它从一个研究原型发展为涵盖全学科的学术搜索门户。 它索引了 4千万论文, 2千万作者, 6 大实体类型, 8 种数据可视化功能, 具有开放的API 平台和手机客户端. 下面说说项目的发展: 2009/8: 内部发布 alp…

现代软件工程讲义 9 测试 QA 的角色和分工

测试的角色 (Test) 要独立出来么 ? 独立出来的测试角色怎么才能发挥作用? 有些成功人士和成功的公司号称没必要有独立的测试角色 (Test), 你怎么看? 最近又看到一些关于开发人员要不要负责测试的讨论。 例如: http://www.aqee.net/on-testers-and-testing/ 大多数的开发…

程序设计作业: 车模+数模 = ?

我上学的时候只听说过 “航模”, 没听说过“数学建模”这门学问. 这几年在简历里看到过不少人号称数模得过什么奖之类的, 我都没好意思问太仔细。 在帝都开车经常遇到堵车, 我于是想到了一个车模的问题。 我想请大家帮着给这个车模搞个数模, 求个解法: 想象帝都北四环或北五…

计算机考研的调查和改进建议

几星期前, 我在微博上讨论考研的事, 有专家建议不如把意见整理出来, 说不定可以转告给相关方面。 我没有考过研, 问了公司的同事们, 绝大多数都是保研的, 也没考过。 我从网上下了一份模拟题, 好像还挺难,有一种要翻书的冲动。 全国有多少学生为了考研而奋斗? …

2012 夏季高校微软俱乐部活动 - 开门创新

创新啊创新, 大家都在讲创新。 一般的理解, 创新就是公司内部关起门来想, 实验, 内部评审, 然后申请专利什么的, 其实也有开门创新的办法: http://www.innovationexcellence.com/blog/2012/08/13/40-examples-of-open-innovation-crowdsourcing/ it is about bringing extern…

笔记 - 高等教育的创新

教育是一个社会发展的支柱, 你和我能看到并理解这个博客, 教育功不可没。 高等教育的形式并不是一成不变的, 高等教育一直在演进, 变革中, 最近一股“online higher education” 的浪潮在美国兴起, 貌似突兀, 其实有规律可循。 在关注最近的在线教育浪潮之前, 我们看看美国高等…

现代软件工程讲义4 Scrum/Sprint

Advanced Software Engineering, Development Process, Scrum/Sprint 软件开发的流程有很多 (看 各种方法论概述), 我也写过一篇博客 (酒后的敏捷) 谈了谈最近比较时髦的开发流程。 今天我们不喝酒, 正襟危坐地说说敏捷这一路 Scrum/Sprint 开发方法. 从理论上看, 这个方法真…

现代软件工程讲义 7 设计阶段 Spec

在前一个博客里 (典型用户), 我们讲了怎么收集, 分析和验证用户的需求。 这里我们讲 spec – specification Specification, 又叫spec, 有两种: a) functional spec, 软件功能说明书, 主要用来说明软件的外部功能, 和用户的交互情况 (把软件当作一个黑盒子) b) technical spec…

现代软件工程 2012 北航 项目复审模板

这是现代软件工程课在北航的项目复审要求。 这次我们有下列 10 个团队, 他们做了一些有意思的项目: 有七个小组合作,携手打造一个叫 学霸 的网站: 100Years 网页收集和归类工具76er 网页收集和归类工具FightingSnail 网页元数据抽…

现代软件工程讲义 8 软件的血型

[这是 现代软件工程讲义 的一篇] 一个软件团队经历了计划/设计/开发等阶段, 达成代码完成 (Code Complete) 这一目标,似乎后面的事情就水到渠成了. 其实不然, 软件生命周期的最后阶段往往是最考验团队的,不但考验团队项目管理水平,应变能力…

现代软件工程讲义 6 用户调研

[现代软件工程讲义 的一部分] 软件开发的过程, 就是 “用户最需要的东西” 在下面这一链条中传送,转换,实现,扭曲或丢失的过程。 用户最需要的 > 用户表达出来的 > 软件团队能理解的 (老板/PM) 团队的商业目标 > 软件团队成员具…

软件工程讲义 0 微博上的软件工程

[现代软件工程讲义] 有舌尖上的美味, 也有微博上的软工。舌尖上的美味各有千秋, 而微博上对软工的抱怨都是相似的。 下面是我在新浪微博收集到大学生对软件工程教学的反馈: 师生关系(不限于软件工程) 教材 上课 & 老师 实践 & 作业 考试 考完…