标签：不同 量化 程序员 用户 失败 计划 包括 lin 格式
2.1 单元测试
大部分软件是由多人合作完成，不同工作人员相互有依赖关系。例如，一个人负责的模块功能被别人调用。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。怎样能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块，而且模块的质量能得到稳定的、量化的保证？单元测试是一个很有效的解决方法。
好的单元测试标准：a.单元测试应该在最基本的功能/参数上验证程序的正确性。
b.单元测试必须由最熟悉代码的人（程序的作者）来写。
c.单元测试过后，机器状态保持不变。
d.单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
e.单元测试应该产生可重复、一致的结果。
f.独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
g.单元测试应该覆盖所有代码路径。（100%的代码覆盖率不等同于100%的正确性）
h.单元测试应该集成到自动测试的框架中。
i.单元测试必须和产品代码一起保存和维护。
针对一个Bug Fix（错误修正），要做Regression Test（回归测试）。目的是：
a.验证新的代码的确改正了缺陷。
b.同时要验证新的代码有没有破坏模块的现有功能，有没有Regression（“倒退”）。
2.2 效能分析工具
可以选择两种分析方法：a.抽样；b.代码注入。
要注意避免没有做分析就过早地进行“效能提高”。如果我们不经分析就盲目优化，也许会事倍功半。
2.3 个人开发流程
1.计划：估计这个任务需要多少时间
2.开发：a.需求分析b.生成设计文档c.设计复审（和同事审核设计文档）d.代码规范（为目前的开发制定合适的规范）e.具体设计f.具体编码g.代码复审h.测试（包括自测，修改代码，提交修改）
3.报告：a.测试报告b.计算工作量c.事后总结，并提出过程改进计划
2.4 实践
实践最简单的项目：WC
1. 实现一个简单而完整的软件工具（源程序特征统计程序）。
2. 进行单元测试、回归测试、效能测试，在实现上述程序的过程中使用相关的工具。
3. 进行个人软件过程（PSP）的实践，逐步记录自己在每个软件工程环节花费的时间。
4. 使用项目管理系统，练习使用其中的事件跟踪系统。（选用TFS，Bugzilla或者Trac，了解原理）
5.进行最简单的项目管理系统的定制
WC项目要求
程序处理用户需求的模式为：wc.exe[parameter][file_name]
各个参数的意义：
基本功能列表：wc.exe-c file.c:char count
wc.exe-w file.c:word count
wc.exe-l file.c:line count
拓展功能：-s 递归处理目录下符合条件的文件。
-a 返回高级选项（代码行/空行/注释行）。
空行：全部是空格或格式控制符，如果包括代码，则只有不超过一个可显示的字符，例如“}”。
代码行：包括多于一个字符的代码。
注释行：不是代码行，并且包括注释。一个有趣的例子是有些程序员会在单字符后面加注释：}//注释 在这种情况下，这一行属于注释行。
[file_name]：文件或目录名，可以处理一般通配符。
文本文件，确定字/词/句。
高级功能：-x参数。这个参数单独使用。如果命令行有这个参数，则程序会显示图形界面，用户可以通过界面选取单个文件，程序就会显示文件的字符数、行数等全部统计信息。
如何保证质量——回归测试
1.手动测试，手工比较。
2.要做到不断地测试，可以把WC的主要功能封装成一个类，然后测试程序调用这个类的主要函数，得出结果并与标准做比较。
3.更进一步，把测试文件和正确的测试结果保存在文件中，测试驱动程序只要比较测试的输出和标准结果就能得出答案。
4.再进一步，把自动构建脚本和构建验证测试结合起来。每一次构建之后，就自动运行测试，然后记录出现的Bug。
标签：不同 量化 程序员 用户 失败 计划 包括 lin 格式
原文地址：http://www.cnblogs.com/shuaideyib/p/6719415.html
